Kickstart ROM Replacement (Phase I) Bounty Assigned

[Gulliver]

More details from the AROS dev mailing list:

Finally, after 3 weeks, first light on my m68k port of AROS to m68k-amiga.
 
Doesn't work, crashes pretty soon, but I have gotten path the 'compile it',
'compile it with Amiga ABI', and 'get into Exec Init' phases. Very happy.
 
Other than the giant pile of AROS patches I'll be committing as soon as I
get SVN access, I also have a (tiny) GCC patch that is needed to match
the Amiga ABI, and a e-uae patch to enable serial.

Against current AROS tip, gcc v4.5.1, and e-uae tip:
 
http://www.evillabs.net/AROS/AROS-2010-10-09-m68k.tar.gz
 
Also includes a pre-compiled A1200 ROM image, which boots
(and crashes).
 
---------- ROM Layout -------------------
 
400K Text, 34K Data, 78K Unused
 
(You can ignore the .sysbase, .stack, and .bss placeholders,
  they take up no ROM space, they're just there for linking)
 
~/private/AROS $ m68k-elf-objdump -h bin/amiga-m68k/AROS/aros-amiga-m68k.elf
 
bin/amiga-m68k/AROS/aros-amiga-m68k.elf:    file format elf32-m68k
 
Sections:
Idx Name          Size      VMA      LMA      File off  Algn
  0 .sysbase      00000008  00000000  00000000  00002000  2**0
                  ALLOC
  1 .stack        0000fff8  00000008  00000008  00002000  2**0
                  ALLOC
  2 .bss          000013d0  00010000  00010000  00002000  2**4
                  ALLOC
  3 .text        0006363a  00f80000  00f80000  00002000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .rodata      00008b80  00fe363a  00fe363a  0006563a  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 
 
---------- From my UAE session ----------
(NOTE: This is a stock Amiga 1200 (2M) simulation,
  the output below the '=======' is from the UAE
  simulated serial port)
 
Building CPU function table, 45674 opcodes (2 0 0).
Resetting frame rate hack
Using 24 bit visual, 32 bits per pixel
Using MIT-SHM extension.
reset at 0
PAL mode, 50Hz (h=227 v=312)
chipmem cleared
SERIAL: period=368, baud=9600, hsyncs=16 PC=f80d2e
====================================================
[reset]
[bss clear]
gdb stub[prep SysBase]
peb SysBase: 0004040e
PrepareExecBase [ret]: 0004040e
[init SysBase]
RomTagScanner: Start = 00f80000, End = 01000000
Resident modules (18) (addr: pri version name) at 0x40870:
+ 0x00feae1e: 127  3 "kernel.resource"
+ 0x00fe3ade: 105  41 "exec.library"
+ 0x00fe8822: 103  41 "utility.library"
+ 0x00fe6006: 102  41 "aros.library"
+ 0x00feb08e:  99  2 "processor.resource"
+ 0x00feabde:  92  1 "hiddclass.hidd"
+ 0x00fe72ba:  65  41 "graphics.library"
+ 0x00fe9c0a:  50  41 "timer.device"
+ 0x00fead6e:  45  41 "battclock.resource"
+ 0x00fe9f12:  44  41 "keyboard.device"
+ 0x00fe95fe:  40  41 "keymap.library"
+ 0x00fe9d3e:  30  41 "input.device"
+ 0x00fe89de:  15  50 "intuition.library"
+ 0x00fea062:  4  41 "console.device"
+ 0x00fe611e: -120  41 "dos.library"
+ 0x00fe675a: -123  41 "LDDemon"
+ 0x00fea4ee: -124  41 "con.handler"
+ 0x00feaabe: -125  41 "nil.handler"
[start] InitCode(RTF_SINGLETASK, 0)
[start] InitCode(RTF_COLDSTART, 0)
[libcall Exec Init]
[exec] GO GO GO!
################################################################################
#                              Software Failure!                              #
#                      Task 00000000 - --task not found--                      #
#                Error 81000005 - Corrupt memory list detected                #
################################################################################
reset at f80ec0


And more news:

- Jason McMullan has now SVN access to the AROS tree
- ABI issues appear to be fixed (native)
- library init successful up to graphics.library and intuition.library
- working on OCS single-plane HIDD

[Gulliver]

No, it's for real Amigas.  The point is to run AROS in 68k Amigas without having to rely on the Commodore licensed ROMs and to have an AROS user interface.

And to take advantage of a system that is being still developed, and has some neat modern features that AmigaOS for classics never had.

[Gulliver]

I'm not sure why everything must go in ROM anyway, it seems very limiting if you aren't stuck with double-density floppies only.

Get the machine reading the drives, then load the rest from disk.

It's much more flexible and it's more easily fixed in the field, especially if CDRoms and USB are supported as boot media.

ROM usage for storing OS components was a good idea back in the times of slow and constrained space storage media, like floppies, early harddrives, and tapes (do you remeber tapes dont you?). As they were slow, rom was "the very best thing" they could use, and having portions of the OS over there, not only allowed faster operation, but they also enabled you to save precious storage space.

Times have changed: Rom is not that fast now compared to actual hardrives that are pretty quick and efficient. So a kickstart today, has really no sense to be in rom, it should be on a drive.
Only the bootstrap code should still be kept in rom.

[Gulliver]

>So a kickstart today, has really no sense to be in rom, it should be on a drive

?!???!??!??

Yes, definately, on a modern system.

Another advantage is that rom is of course read-only. You may use an eeprom, but then you will have to add complexity to the system for just reprogramming it.
To modify a file on a harddrive it is pretty easy and fast.

But hey, if you are still using floppies on an A500, then just keeping your old rom there, as it makes sense, as mentioned in my other post.

[Gulliver]

kickstart rom has an advantage that the system critical files cannot be easily deleted or modified by malicious software or simple oversight.
i am totally happy with the huge flash the deneb provides that can be used for this. the only complaint was that i would prefer to have all single modules loose in a plain directory instead still have to include a bootable kickstart image along. updating would be simple then.

I agree that the Deneb is an elegant solution for having a rewritable kickstart rom. But then it is only available for Zorro Amigas! And it is not a cheap or simple solution (technically speaking) and what about the other non Zorro Amigas?

[Gulliver]

@deadwood
Great!
Thank you for the updates, keep them coming.

[Gulliver]

Update:
______________________________________________________________________

I have successfully loaded my first disk block using Frankenrom with KS 3.0!
 
With Toni's help, I realized that I needed to enable DMA (DUH!) early
on after IRQs have been enabled, and KS 3.0 + AROS Exec will now get
to the point where it *sucessfully* loads the first disk block.
 
However, the screen is still black.
______________________________________________________________________

BTW when he mentions Toni, he is speaking of Toni Wilen, the author of WinUAE, who is now cooperating with Jason on this bounty.

[Gulliver]

More updates from Jason:

Toni has had me put in the following M68K drivers while he waits for SVN access:

* keyboard HIDD
* mouse HIDD
* trackdisk.device
* cia/cib resource
* drive.library (supports trackdisk.device)
* potgo.resource

Also, I've un-unmaintained the M68K ASM utility.library functions.

I'll start bringing in stuff from the M68K 'unmaintained' exec and layers
libraries tonight.

[Gulliver]

Update:


Nov 12, 2010: AROS Shell

Yep, that's right. The AROS Shell prompt. Whee!

Capable of running:

    * AROS Shell
    * A number of trackloading games

Not yet:

    * DOS loading games (no in-ROM shell to run their startup scripts)

What's horrible:

    * Had to change the ABI to the Graphics/*LayerRom routines to use A4 instead of A5, due to GCC issues. That's in the EVIL.patch
    * Doesn't boot if we're not strobing the serial port.
    * It's a 1M ROM set.

ROMs + E-UAE configs + AROS System Floppy + EVIL.patch

AROS-r35388-EVIL.tar.gz