Aros m68k (Kickstart substitute) - Page 15

AmigaFriend · 01 February 2012, 15:03

I know that the A600 supports 1M roms. There are other models that support this?

Toni Wilen · 01 February 2012, 15:43

Quote:

Originally Posted by xpect

I know that the A600 supports 1M roms. There are other models that support this?

A500 (later revisions), A1200, CD32. A600 and A1200 support max 2M ROMs. (second 1M at 0xa80000-0xb7ffff)

Toni Wilen · 01 February 2012, 21:01

Quote:

Originally Posted by mark_k

Commodore's Andy Finkel published example code using that technique (http://aminet.net/dev/src/Window.lha), but CBM removed support for it in Kickstart 2.0.

This example is quite bad because it assumes dos jump vectors are using BCPL-style code (moveq #vectorid,d0; bra.w bcpl_magic). Only way to support this kind of code is to "emulate" BCPL jump vectors.

It wouldn't be too difficult but problem is that all low level system programs (like snoopdos) made/updated after 2.0+ was introduced most likely expects "normal" dos jump vectors and would crash..

NovaCoder · 02 February 2012, 01:06

Quote:

Originally Posted by Toni Wilen

What is AROS "3.1"?

http://aros.sourceforge.net/download.php amiga-m68k-boot, included adf image contains both image and softkick loader but you can also use ACA's rekick option.

Hiya,

Ok I download loaded the package and found two ROM files (standard + extended), I assume I need to 'stick' these together (eg using Remus) to create a 1MB ROM for my ACA?

Ezrec · 02 February 2012, 03:16

Quote:

Originally Posted by NovaCoder

Ok I download loaded the package and found two ROM files (standard + extended), I assume I need to 'stick' these together (eg using Remus) to create a 1MB ROM for my ACA?

It's even easier - you just concatenate them together.

ACATune will detect the 1M rom and put everything in the right place - it's how I test on my A1200.

I think its ext-then-rom... or maybe rom-then-ext.

One of them will work.

mark_k · 02 February 2012, 20:44

Quote:

Originally Posted by Toni Wilen

This example is quite bad because it assumes dos jump vectors are using BCPL-style code (moveq #vectorid,d0; bra.w bcpl_magic). Only way to support this kind of code is to "emulate" BCPL jump vectors.

It wouldn't be too difficult but problem is that all low level system programs (like snoopdos) made/updated after 2.0+ was introduced most likely expects "normal" dos jump vectors and would crash..

ABasiC, the Window example and the example code in the Amiga Guru Book (p288-295 in the English version) all use the technique of jumping to offset _LVOOpen+2 from DOSBase. Probably Ralph Babel just copied the ABasic/Window technique!

I guess it's kind of academic now, but if a program attached a CON: handler to its window by calling the BCPL routines in the correct way (like the 1.x CLI commands must do), it probably wouldn't be much trouble to support that BCPL technique in AROS.

As it is, since those programs all jump to _LVOOpen+2, it might be feasible to hack the Open vector so it consists of a BRA.B to code which calls the "real" Open routine, followed by a BRA.W to the BCPL setup routine. I'm not suggesting the AROS M68K ROM itself should do that, but it would be possible to write such a program which the end user could run, before running ABasiC or whatever. Maybe with support from AROS dos.library in the form of a couple of free longwords in DOSBase, which the patch program could use for JMP instructions.

The "correct" way for those programs to call BCPL routines would (I think?) have been to reproduce the BCPL routine setup code, which looks like this (assuming DOSBase is in A6). The BRA.Ws in the Kickstart 1.x DOSBase point to code like this (the code is at offset $4E from DOSBase; the code in 1.x DOSBase references dl_A2 PC-relative, not based on A6):

Code:

MOVEM.L D2-D7/A2-A6,-(SP)
SUBA.L  A0,A0
SUBI.L  #1500,D5
BCLR    #1,D5
MOVEA.L D5,A1
MOVEM.L (dl_A2,A6),A2/A5/A6
ASL.L   #2,D0
MOVEA.L (A2,D0.L),A4
MOVEQ   #12,D0
JSR     (A5)
MOVE.L  D1,D0
MOVEM.L (SP)+,D2-D7/A2-A6
RTS

In fact... if AROS DOSBase has that code or equivalent at offset $4E, as probably all Kickstart 1.x versions do, then an easy 4-byte patch to the unmodified ABasiC executable should be enough to get it working, once there is support for attaching a CON handler to an existing window. The patch would just change instances of JMP (-$1C,A6) to JMP ($4E,A6).

brett71 · 02 February 2012, 23:42

Quote:

Originally Posted by Toni Wilen

A500 (later revisions), A1200, CD32. A600 and A1200 support max 2M ROMs. (second 1M at 0xa80000-0xb7ffff)

What about A3000's?

mark_k · 03 February 2012, 22:49

I've noticed a couple of bugs with the AROS boot ROM as included in WinUAE 2.4.0 beta 14 2012.02.03, hope this is the right thread to report them.

See http://bitworld.bitfellas.org/demo.php?id=29403 and download disk 1.

There are several issues which show up:

1. The startup-sequence uses a program called Runback by Microsmiths. (That's supposed to give similar functionality to Run progname >NIL: but allowing the CLI window to be closed.)

RunBack doesn't work with the AROS boot ROM. It shows some error text which actually appears before the "AROS - The AROS Research...." banner.

The error text is this: "RunBack: Error starting background task!',$0aYou must have the program 'Run' in your C: directory"
[The ,$0a is obviously an error by the RunBack developer.]

2. When the startup-sequence is interrupted because of the RunBack problem, typing "dir c" results in an error: "No free store for filenames - list incomplete" (this is with the emulated Amiga having 5MB RAM). This actually may be a problem with the AROS OFS filesystem code, see below.

3. There may be a problem with some ROM string formatting routine. Doing "type c:runback opt h" to get a hex dump of the RunBack program, the output is wrong. Bytes with values $00 to $0F are shown with a space instead of the leading zero.

Back to point 2. Boot the disk with Kickstart (1.3 say) and press Ctrl-D to interrupt the startup-sequence. Type "dir" or "list". You get a normal directory listing. Now boot the disk using the AROS boot ROM. At the CLI type "list". Notice that the entry for SetDown repeats over and over. That's probably the cause of the dir error message mentioned above.

PS: Can someone test the intro on that disk on a real Amiga? Is the white COSMIC PIRATES text at the left side supposed to be in front of the scrolling text?

Toni Wilen · 04 February 2012, 12:27

Quote:

Originally Posted by brett71

What about A3000's?

AFAIK it also has 512K limit (Fat Gary limitation)

Quote:

Originally Posted by mark_k

3. There may be a problem with some ROM string formatting routine. Doing "type c:runback opt h" to get a hex dump of the RunBack program, the output is wrong. Bytes with values $00 to $0F are shown with a space instead of the leading zero.

Fixed.

Quote:

Back to point 2. Boot the disk with Kickstart (1.3 say) and press Ctrl-D to interrupt the startup-sequence. Type "dir" or "list". You get a normal directory listing. Now boot the disk using the AROS boot ROM. At the CLI type "list". Notice that the entry for SetDown repeats over and over. That's probably the cause of the dir error message mentioned above.

Fixed. BCPL SendPacket() didn't return correct dos return code. (Kept looping forever when ACTION_EXAMINE_NEXT returned ERROR_NO_MORE_ENTRIES)

Runback calls mysterious Shell stuff.. Not that simple to fix, I think..

btw, do not use WinUAE included ROM, it is always too old. Use the link above which is updated nightly.

btw2, these kinds of easy to duplicate small programs are perfect for bug fixing!

mark_k · 08 February 2012, 19:53

The AROS boot ROM (2012-02-08 version) doesn't seem to support the EBF_SILENTSTART flag in ExpansionBase.

Booting any floppy disk under Kickstart 1.x causes the initial CLI window (and Workbench screen) to open, even if no commands in the startup-sequence output any text.

With Kickstart/Workbench 2.0 (V36+), the default bootblock code installed by C:Install sets a flag in ExpansionBase (EBF_SILENTSTART) which tells the machine not to open the CLI window until it is needed. If no programs in the startup-sequence output any text, the Workbench screen only opens when LoadWB is run.

For backward compatibility, when Kickstart V36+ boots a disk with the old type of bootblock, the Workbench and CLI window are always opened before the startup-sequence is executed.

Not supporting EBF_SILENTSTART could cause many existing disks to fail to boot. For example, disks which run a program which resizes the initial CLI window (common because under Kickstart 1.x the initial CLI doesn't fill the whole screen on PAL machines). Or a program which reduces the Workbench screen depth to 1. [Of course, programs which change the Workbench depth are likely to fail on AROS for other reasons.

]

With AROS boot ROM 2012-02-08: Boot with no startup-sequence. (For example, configure a bootable shared folder which is empty, or I guess boot from an empty installed floppy.)
At the CLI window type: Resident
Get a recoverable alert reqester saying:

Code:

Program Failed
Task : 0x002807C8 - resident
Error: 0x0100800D - unknown unknown problem with exec.library
PC   : 0x00F87A2C

On clicking continue, the list of resident commands is printed, then get another alert at the end.
Many/all other resident commands have the same problem, e.g. you could type commands like

Code:

Fault 103
Echo "hello"
CD

and get the alert requesters.

Toni Wilen · 08 February 2012, 20:20

Quote:

Originally Posted by mark_k

The AROS boot ROM (2012-02-08 version) doesn't seem to support the EBF_SILENTSTART flag in ExpansionBase.

It did in some older version, probably got broken..

Leffmann · 08 February 2012, 21:14

Silent start is forced actually, and at least since Jan-28 it will skip invalid boot blocks and enter AmigaDOS by itself and run startup-sequence.

mark_k · 08 February 2012, 22:33

[Would the AROS bugtracker be a better place to report bugs than this thread? I have more I could include here, but don't want to clutter up this thread too much if it would be better posted there.]

The latest boot ROM insert disk screen is looking quite cool. On NTSC machines though, the lower part is cut off.

Here are a couple of bugs relating to RAW: window handling.

With the latest boot ROM, AROS can run the patched version of ABasiC, woohoo! ABasiC attaches a RAW: console handler to its window on a custom screen. That seems to work. But some aspects of the console handler seem a bit broken.

To see what I mean:
- Download the ABasiC patch from Aminet. The readme file lists various URLs where you can get ABasiC itself from. Then apply the patch (which allows ABasiC to work with Kickstart 2.0 and later).
- For reference/comparison, run ABasiC under Kickstart (probably any version will work).
- Type in this program

:

Code:

10 print "Mark is skill ";
20 goto 10

- Type run. The screen fills up with text. You can press Ctrl-C to break, ABasiC does a DisplayBeep() so the screen flashes. Then type cont to continue. Press some letter keys, then press Ctrl-C again. Notice that the letters you pressed before pressing Ctrl-C appear after the Br prompt.

Now do the same, but running under the AROS boot ROM. Notice how the cursor in the ABasiC window flashes/flickers. The console handler seems to be redrawing the cursor over and over.
- Type in the program above and run it. Pressing Ctrl-C does nothing, you can't stop the program.

Edit: A couple more... In AmigaDOS (3.1):

Code:

> echo "hello
argument line invalid or too long
>

In AROS:

Code:

> echo "hello

>

[blank line printed instead of error message]

Boot an empty (installed) disk. At the CLI, type resident to list the resident commands. Pressing Ctrl-S should suspend output and Ctrl-Q continue it. With AROS boot ROM, pressing Ctrl-S prints a box symbol and output continues. Pressing Ctrl-C should interrupt the output but it has no effect in AROS. (Same problem as the ABasiC problem above?)
Typing some letters when resident output is being displayed should stop its output until you delete the letters or press return. With AROS, the resident command output continues as you type.

vidarh · 09 February 2012, 12:25

Quote:

Originally Posted by mark_k

Here are a couple of bugs relating to RAW: window handling.

With the latest boot ROM, AROS can run the patched version of ABasiC, woohoo! ABasiC attaches a RAW: console handler to its window on a custom screen. That seems to work. But some aspects of the console handler seem a bit broken.

Lots of stuff in the console handler still doesn't work the way it should. AFAIK it's not gotten much love by anyone in the last year or so since I last did a bunch of stuff to it. I keep hoping to get time to work on it again, but life keeps interfering...

There's a bunch of escapes that don't work perfectly, and event reporting etc. is at least partially broken, probably a bunch more details. This is not AROS m68k specific, btw.

Ezrec · 09 February 2012, 15:42

Quote:

Originally Posted by vidarh

Lots of stuff in the console handler still doesn't work the way it should. AFAIK it's not gotten much love by anyone in the last year or so since I last did a bunch of stuff to it. I keep hoping to get time to work on it again, but life keeps interfering...

Yes, the AROS bug tracker would be the place to put them.

Please assign them to me (ezrec, or j a s o n (dot) m c m u l l a n (at) g mail dot com) so that I can attend to them.

Toni Wilen · 09 February 2012, 18:35

EBF_SILENTSTART fixed. It was broken when dos packet based shell startup was introduced.

Ezrec · 09 February 2012, 20:25

Quote:

Originally Posted by Toni Wilen

EBF_SILENTSTART fixed. It was broken when dos packet based shell startup was introduced.

Oops! My bad!

Thanks to Toni for fixing this!

Mequa · 21 February 2012, 03:10

Quote:

Originally Posted by Toni Wilen

It means what it says on the main page

Working m68k C++ crosscompiler exists. Mesa (and other C++ projects) can be compiled now.

Now I have a small AROS program working on AROS/x86, where can I get this cross-compiler for AROS/68k?

Ezrec · 21 February 2012, 03:31

Unfortunately, AROS m68k is on the ABIv1 branch (it requires the new DOS Packets support), so you'll have to build your toolchains yourself:

1) git clone git://repo.or.cz/AROS.git
2) mkdir AROS.build
3) cd AROS.build
4) ../AROS/configure --target=amiga-m68k
5) make -s crosstools linklibs
[wait.... takes quite a bit]
6) Crosstools are now in bin/linux-{arch}/tools/crosstools/
Libs and headers are in bin/amiga-m68k/AROS/Development/
7) Just 'make -s' to build everything.

Bug termillus - I think he's working on an automated build-toaster for AROS (submit sources in a .lha file, get back compiled binaries for all current AROS architectures).

I think he's just waiting for some more demand.

28 February 2012, 09:47

Where do find this Termillus to bug him? :-)

08 February 2012, 19:53	#290
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,344	The AROS boot ROM (2012-02-08 version) doesn't seem to support the EBF_SILENTSTART flag in ExpansionBase. Booting any floppy disk under Kickstart 1.x causes the initial CLI window (and Workbench screen) to open, even if no commands in the startup-sequence output any text. With Kickstart/Workbench 2.0 (V36+), the default bootblock code installed by C:Install sets a flag in ExpansionBase (EBF_SILENTSTART) which tells the machine not to open the CLI window until it is needed. If no programs in the startup-sequence output any text, the Workbench screen only opens when LoadWB is run. For backward compatibility, when Kickstart V36+ boots a disk with the old type of bootblock, the Workbench and CLI window are always opened before the startup-sequence is executed. Not supporting EBF_SILENTSTART could cause many existing disks to fail to boot. For example, disks which run a program which resizes the initial CLI window (common because under Kickstart 1.x the initial CLI doesn't fill the whole screen on PAL machines). Or a program which reduces the Workbench screen depth to 1. [Of course, programs which change the Workbench depth are likely to fail on AROS for other reasons. ] With AROS boot ROM 2012-02-08: Boot with no startup-sequence. (For example, configure a bootable shared folder which is empty, or I guess boot from an empty installed floppy.) At the CLI window type: Resident Get a recoverable alert reqester saying: Code: Program Failed Task : 0x002807C8 - resident Error: 0x0100800D - unknown unknown problem with exec.library PC : 0x00F87A2C On clicking continue, the list of resident commands is printed, then get another alert at the end. Many/all other resident commands have the same problem, e.g. you could type commands like Code: Fault 103 Echo "hello" CD and get the alert requesters. Last edited by mark_k; 08 February 2012 at 20:12.

08 February 2012, 22:33	#293
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,344	[Would the AROS bugtracker be a better place to report bugs than this thread? I have more I could include here, but don't want to clutter up this thread too much if it would be better posted there.] The latest boot ROM insert disk screen is looking quite cool. On NTSC machines though, the lower part is cut off. Here are a couple of bugs relating to RAW: window handling. With the latest boot ROM, AROS can run the patched version of ABasiC, woohoo! ABasiC attaches a RAW: console handler to its window on a custom screen. That seems to work. But some aspects of the console handler seem a bit broken. To see what I mean: - Download the ABasiC patch from Aminet. The readme file lists various URLs where you can get ABasiC itself from. Then apply the patch (which allows ABasiC to work with Kickstart 2.0 and later). - For reference/comparison, run ABasiC under Kickstart (probably any version will work). - Type in this program : Code: 10 print "Mark is skill "; 20 goto 10 - Type run. The screen fills up with text. You can press Ctrl-C to break, ABasiC does a DisplayBeep() so the screen flashes. Then type cont to continue. Press some letter keys, then press Ctrl-C again. Notice that the letters you pressed before pressing Ctrl-C appear after the Br prompt. Now do the same, but running under the AROS boot ROM. Notice how the cursor in the ABasiC window flashes/flickers. The console handler seems to be redrawing the cursor over and over. - Type in the program above and run it. Pressing Ctrl-C does nothing, you can't stop the program. Edit: A couple more... In AmigaDOS (3.1): Code: > echo "hello argument line invalid or too long > In AROS: Code: > echo "hello > [blank line printed instead of error message] Boot an empty (installed) disk. At the CLI, type resident to list the resident commands. Pressing Ctrl-S should suspend output and Ctrl-Q continue it. With AROS boot ROM, pressing Ctrl-S prints a box symbol and output continues. Pressing Ctrl-C should interrupt the output but it has no effect in AROS. (Same problem as the ABasiC problem above?) Typing some letters when resident output is being displayed should stop its output until you delete the letters or press return. With AROS, the resident command output continues as you type. Last edited by mark_k; 08 February 2012 at 23:04.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
ChipQuik and substitute	kipper2k	Hardware mods	18	27 September 2013 10:55
AROS m68k Bug Reports	Ezrec	Amiga scene	1	03 October 2011 22:40
AROS m68k running on WinUAE	turrican3	Amiga scene	1	01 January 2011 04:07
Kickstart substitute	gilgamesh	request.UAE Wishlist	19	17 January 2009 15:37
New Bounty-Project started for AROS: Kickstart replacement	Paul	News	0	26 December 2004 12:12

01 February 2012, 15:03	#281
AmigaFriend Registered User Join Date: Sep 2008 Location: Sesimbra/Portugal Posts: 1,462	I know that the A600 supports 1M roms. There are other models that support this?

03 February 2012, 22:49	#288
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,344	I've noticed a couple of bugs with the AROS boot ROM as included in WinUAE 2.4.0 beta 14 2012.02.03, hope this is the right thread to report them. See http://bitworld.bitfellas.org/demo.php?id=29403 and download disk 1. There are several issues which show up: 1. The startup-sequence uses a program called Runback by Microsmiths. (That's supposed to give similar functionality to Run progname >NIL: but allowing the CLI window to be closed.) RunBack doesn't work with the AROS boot ROM. It shows some error text which actually appears before the "AROS - The AROS Research...." banner. The error text is this: "RunBack: Error starting background task!',$0aYou must have the program 'Run' in your C: directory" [The ,$0a is obviously an error by the RunBack developer.] 2. When the startup-sequence is interrupted because of the RunBack problem, typing "dir c" results in an error: "No free store for filenames - list incomplete" (this is with the emulated Amiga having 5MB RAM). This actually may be a problem with the AROS OFS filesystem code, see below. 3. There may be a problem with some ROM string formatting routine. Doing "type c:runback opt h" to get a hex dump of the RunBack program, the output is wrong. Bytes with values $00 to $0F are shown with a space instead of the leading zero. Back to point 2. Boot the disk with Kickstart (1.3 say) and press Ctrl-D to interrupt the startup-sequence. Type "dir" or "list". You get a normal directory listing. Now boot the disk using the AROS boot ROM. At the CLI type "list". Notice that the entry for SetDown repeats over and over. That's probably the cause of the dir error message mentioned above. PS: Can someone test the intro on that disk on a real Amiga? Is the white COSMIC PIRATES text at the left side supposed to be in front of the scrolling text?

08 February 2012, 21:14	#292
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	Silent start is forced actually, and at least since Jan-28 it will skip invalid boot blocks and enter AmigaDOS by itself and run startup-sequence.

09 February 2012, 18:35	#296
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,534	EBF_SILENTSTART fixed. It was broken when dos packet based shell startup was introduced.

21 February 2012, 03:31	#299
Ezrec Registered User Join Date: Jan 2011 Location: Pittsburgh, PA Posts: 31	Unfortunately, AROS m68k is on the ABIv1 branch (it requires the new DOS Packets support), so you'll have to build your toolchains yourself: 1) git clone git://repo.or.cz/AROS.git 2) mkdir AROS.build 3) cd AROS.build 4) ../AROS/configure --target=amiga-m68k 5) make -s crosstools linklibs [wait.... takes quite a bit] 6) Crosstools are now in bin/linux-{arch}/tools/crosstools/ Libs and headers are in bin/amiga-m68k/AROS/Development/ 7) Just 'make -s' to build everything. Bug termillus - I think he's working on an automated build-toaster for AROS (submit sources in a .lha file, get back compiled binaries for all current AROS architectures). I think he's just waiting for some more demand.

28 February 2012, 09:47	#300
jakov Posts: n/a	Where do find this Termillus to bug him? :-)

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)