TeamAROS Bounty #23 AROS Kickstart Replacement ROM

[jdiffend]

I'm interested it doing this (have been for some time).  I've written ROM code including part of the OS for a 68020 based embedded system in the past and this would not be difficult if the pieces are there I'd need.

Boot how?  Floppy?  Hard drive?  And for which machine?
How much of the OS has to be in the ROM to qualify?  Just enough to boot from ROM or move everything possible to ROM?  Initially I'd say keep the ROM to a minimum.  That makes it easy for the bootstrap code to be compatible with all CPUs (Hint, Coldfire, Hint) and reduce the number of updates till the OS is more mature.

Just how much of the existing Amiga ROM does the Amiga version of AROS make use of (I've never looked at it)?  It has to be ZERO after it's loaded for this to work!

The Amiga needs a graphics library to even print text on the screen.  It has no hardware character generator.

Does AROS have an Amiga compatible trackdisk.device for use with the Amiga floppy drives/interface?  If not, booting from that is out of the question.

Does AROS have a scsi.device that is compatible with the 3000 or 1200 hard drive interfaces?  If not, that's out of the question.

The bootstrap code, interrupt tables, tables for libraries & devices, auto config, RAM setup, etc... are not really difficult, just time consuming.  Add on boards with their own ROM drivers could be problematic.

This is what I KNOW the ROM needs initially (unless you just have a minimal bootstrap like the 1000 did).
680x0 code to set up interupt table (and coldfire 68K emulation , stack, some hardware, auto config, etc...
exec.library
timer.device
trackdisk.device and or scsi.device
graphics.library (so we can display errors)
dos.library
some sort of file system
and I'm sure many other things

Anyone ever release a FLASH memory Kickstart board for the Amiga?  It would be a lot easier with that.  I have a bunch of Flash memory but I'd have to design/build an adapter board and program the chips.  The board isn't difficult to design but a professionally printed sample board, setup costs, FLASH chips, shipping... would amount to more than the bounty.  At least the last time I had a board printed initial setup wasn't cheap.

[jdiffend]

WinUAE ROM... didn't think of that. (Duh)  That would be the easy way to do it.  CPU independant code though (not just 68020).  Coldfire would require additional code so that would be a future option.

I'd say some libraries would have to stay on disk since the C code won't generate as small of binaries as the hand made assembly that's already there.

I'll have to see what the cross development tools are like and take a serious look at building this.

[jdiffend]

I spent some time looking at this and here is what I found.

The current 68K port that was in the works isn't available for download and was for the Palm anyway.  That in itself is no big deal but it means there are no AROS scsi.device driver, trackdisk.device or graphics drivers for the Amiga hardware.

I seem to remember a replacement ide driver for the 1200/4000 that was open source but I'm not certain.  That could be the basis for a driver to boot from the hard drive.

I once worked on a program to read COCO 5 1/4" disks on the Amiga 5 1/4" drives and I really don't want to write a trackdisk.device.  That's just too much work.  If anyone knows of a replacement that's open source then it might be possible.

As for graphics... that alone would be as much work as everything else combined.  After all, your talking about supporting all video modes, sprites, etc... for full 3.1 compatability.  

I sat down last night and wrote some C code that was the functional equivalent of the initial exec startup code.  It still needs stack pointer set and cache contral set but it does set up some hardware, set the LED, check for first time startup, set up interrupt table (partially complete) etc...  Only around 100-150 lines so far with comments but it's pretty easy.

Getting the machine to boot from IDE wouldn't really bother me... but I'm not thrilled about writing the trackdisk.device and graphics.library.  

[jdiffend]

MskoDestny wrote:
There is an amiga folder in the unmaintained folder of the AROS source, but from the looks of things it's all quite old and incomplete.  Might be easier than starting from scratch though.

If it's old it would probably require as much work to get it in sync with the latest release (not that AROS has ever really had an official release version) as it would to do it over.  Besides, most of what I'd have to do probably isn't in there at all.

A bootable Amiga AROS is one thing... a 3.1 REPLACEMENT implies a lot more work.  Booting AROS means porting enough of AROS to boot and some startup code to set up the hardware.  A 3.1 replacement means it has to support ALL graphics modes from the Amiga.  That alone may be a larger project than many of the other bounties combined and then there are other hardware drivers that need to be written.

Remember, on PC's most graphics are chunky... on the Amiga most use bit planes and the AROS graphics lib isn't likely to support that.

[jdiffend]

I'm looking through the AROS source now and I keep finding things that need to be written to build an Amiga version.

At this point I think it's safe to say that a fully 3.1 compatible ROM is NOT practical.

What is practical:
Bootstrap code
exec.library
Timer.device
keyboard
ide driver
Fixed mode graphics display not using hardware blitter/sprites
existing AROS file systems
And as many of the AROS libs as the ROM will hold.

This should allow any program that works when recompiled under AROS to work and even some games that directly bang the hardware... but 100% compatibility is something that would require way too much work.

[jdiffend]

Dr_Righteous wrote:

Practical or not, it MUST be 100% compatable.

REALITY CHECK

Not only is it impractical... it's impossible.  100% compatability means that everything in the Amiga 3.1 ROM has to be in the AROS ROM.  The Amiga ROM was hand written assembly with many tricks to squeeze everything into the ROM which only has a few bytes of unused free space.  AROS is written in C and would take much more space.  There's no way everything would fit in the ROM.

[jdiffend]

The Amiga memory map has a fixed amount of space reserved for ROMs, go over that and you'll hamper compatability.  The OS 3.1 ROM is 512K if I remember right.  Anything that doesn't fit the ROM can be loaded from disk, but that still means it's not 100% compatible.

The expansion ROM is for applications like the CDTV.  The CDTV interface sat in the expansion ROM area and I'm guessing that's how the video games based on the Amiga 500 worked as well.

Now, no matter what solution you come up with to the ROM space issue you're not going to change the amount of work this project requires.

[jdiffend]

dammy wrote:
Does the AROS ROM replacement have to be the same size as the orginal kickstart for the use of the kick.rom in E-UAE/UAE?  If it doesn't, it's not an issue that I can see for the bounty.  We're just wanting E-UAE/UAE to be happy and boot is all so it can run most apps.

Dammy
TeamAROS

The AROS ROM only has to fit in the reserved area in the Amiga memory map.  If you go over 512K it won't work in a real Amiga.  With UAE you can take advantage of extra ROM space without problems.  For a real ROM you'd need an adapter that plugs into the ROM socket and adds the extra address line for the 2nd half of the ROM address space... if there is 1MB reserved for ROM that is.  I honestly don't remember.

If space were the only issue, the least used stuff could be placed in the upper 512K of the ROM space and the remaining code could be built for a 2nd ROM and disk versions.  It's not that big of deal to have the make files build both.  The main difference between the ROM and disk versions of an Amiga library or device and the ROM one is that the disk version has to add a little code at the start to return in the event someone tries to execute it.

[jdiffend]

Dr_Righteous wrote:
Cramming everything needed to boot AROS on to 1MB of ROM space is impossible? Gee, can no one here write in assembler? Has everyone forgotten that back in then we did this kinda $#!% all the time?

The Amiga 3.1 ROM is 512K, not 1MB.  I know most if not all Amigas don't have an address line to the ROM for a 1MB ROM.  I know, I designed a commercial ROM switcher for the Amiga back in the day.  And adding that address line would AT LEAST require an adaptor board and possibly soldering to a surface mount part on some machines.  Something I doubt everyone here can do.  

Yes, I have written in assembler a lot, but AROS is written in C and I'm not writing an OS from scratch for less than what I earn from a day's work at consulting.  Hell, I could make more in a few days at McDonalds.  This isn't just about the bonus but it certainly needs a reasonable scope for the project to be worth taking on.

Oh, and anyone who thinks writing the core OS features necessary to boot AROS within 1MB of space has completely forgotten about the QNX demo floppy. Impossible?? I think not.

The current ROM in hand optimized assembly that Commodore spent years developing and it FILLS 512K.  We were talking about a replacement ROM... which would be 512K.  I wasn't talking about 1MB.  Take the limits on ROM size away and I could put the entire AROS project in there.  But that isn't what was originally stated.

Cut out the GUI and I'm sure it'd be less than 512K.

Ok genious... just how the heck do I cut out the GUI?  The Amiga hardware has no character generator, only graphics (didn't I already say this?).  The Amiga HAS to open the graphics library to even print text.

Do I really need to say that of all the things you could have suggested to leave out of the ROM you picked one of the last things you could possibly leave out?  If you are talking about Workbench, it has always loaded from disk... but it's not that big since the GUI is in ROM.

we did this kinda $#!% all the time?

We?  This from the guy that suggests the GUI should be left out of the ROM?  Oh please.

Look, I used to be a partner in a couple companies that developed Amiga software and hardware.  I spent years developing software and hardware for it.  I've also spent years developing for embedded systems and I even reverse engineered the Amiga 3.1 exec back to source code form including comments as to what everything does.  Even though it's been a long time since I worked with the Amiga, I still have a better idea of what's involved in this than you EVER will.

[jdiffend]

bloodline wrote:
I think what is needed, first off, is simply a bootstrap ROM that POSTs the Hardware, gets the hardware to a known state and starts the AROS Exec.library up and running...

That's pretty close to what I was thinking.  Initializing hardware, identifying/setting up the CPU and starting the exec are probably the most mysterious to programmers and has probably held people back from doing this before.  Initially I'd aim at supporting one CPU and go back and support others later.

Once that and a boot device driver is complete and the machine is capable of loading other libs/devices from disk, other people can work on whatever they want and it can be integrated into the ROM over time.

jdiffend, do you think you could get that far?

I have an old machine I'm setting up under Linux as a dev box for this.  Once it's going I can install the AROS development tools and sources and get a better idea of what's involved.

This isn't really so much difficult as it is time consuming and I'll only undertake it if I know I have the time for the job.  I'm worried about possible endian issues and all the OS routines I'd need to write for the AROS exec.

Once we get to that point, we should be able to use parts of the original OS to test how compatible the AROS exec and Bootstrap is with the original system.

Without a graphics.library clone your going to find that only DOS commands and RTG compatible programs are going to work.

I suppose I could write a utility to extract devices like the trackdisk.device from the current ROM and turn it into a disk based version until someone writes a replacement.  That way we could focus on other issues at first.  I can't promise that will work since the ROM code may skirt a few rules to save space.  The graphics.library is a prime candidate for this as well.

Once that is done, an IDE driver will be needed to load the rest of the OS :-)

I think I'll need that before I can say it actually boots.  If you mean starts the exec and prints the AROS logo on the screen then I agree.  (ok, there's still a graphics lib issue)  

If someone wants to work on a boot logo/screen for the Amiga version that would be one less job to undertake.  Think of a simple 4 color AROS logo bitmap rather than the kitty mascot.  Whatever ROM space it takes up leaves less for something else.  Look at the current boot screen that comes up on a 1200 to get an idea of what to do.  No animated or fancy stuff till we start filling up the ROM and see where were at.  There are more important things.

As for an Amiga hardware graphics.library, well that is going to be a headache, and one could probably ignore (send any debug info to the serial) it and use Cybergfx/picasso96 natively instead... at least until someone bothers to write a new graphics.library... though AROS is better suited to Amiga's with Gfxboards anyway. AROS intuition and layers libraries were written to work with a cybergfx interface anyway :-D

Yeah, I have no intentions of writing a 100% compatable graphics.library at this time.  What I thought of doing was setting the display to a fixed AGA mode and copying a logo to it for testing.

Tweaking AROS graphics.library to RUN RTG on it.  Ugh... chunky vs planar grapics.  I forgot about that.  Does AROS support planar graphics or is it chunky only?  That could be a major problem.  I suppose we are forced to use cybergfx to do anything or temporarily borrow the Amiga graphics lib for development.

I think at least some of us are on the same page as to what can/needs to be done.  At least what you are saying is reasonable and possible.

[jdiffend]

While I'm asking for stuff like the logo there are a couple other things that would be nice to have.  If anyone knows where to find this stuff post a link here please.

I know there is sample source code for identifying different 68K cpus.  I need some public domain source to base this on.  I only need it to set the cpu flags and initialise registers and I don't want to be looking at any of Amiga's code when I write it.  I want to make absolutely sure there are no copywrite issues.  Reverse engineering is legal for compatibility... but the less I have to use it the safer we are.

I'm also looking for scsi.device and or ide.device source code, serial.device source code, etc... if they exist they would probably be on Aminet but the less time I have to look for them the better and the less I have to write myself.

[jdiffend]

LOL, I knew I'd get a full screen bitmap with the cat on it.  

Looks great... but what does it compress down to as an ILBM image.  I can clear the screen to black and just load the logo portion to save some space but that is still bigger than I planned since we're going to end up short on ROM space.  Purrrrrhaps (sorry... couldn't resist) the AROS, Kitty and text could be separate bitmaps.  (If you know the font of the insert disk text I could just put the font in the ROM if it's not too big :-D )  Just keep track of the offsets from the top/side of the image where your cuts take place so I know where to blit them onto the screen.

Not really sure what you mean here

I just wasn't sure if the AROS graphics supported bitplanes.  Been a long time since I looked at it.  If it didn't, it would be a real PITA to make it work.  Since it supports a 4 color planar mode as default, that's a great start.

[jdiffend]

Doobrey wrote:
I`ve already got that far with Remus.
 Unfortunately, it`s the {bleep}ing extraction that I`m rewriting at the moment !
Lemme know what 3.1 Kickstart you`ve got, and I can send you something split it up for you.

I already have it split up in the disassembly myself and can just assemble it if needed.  I'm thinking more for the 1st distro version which will be pretty limited.

BTW, I went to your web page... what a rat's nest of wires! Gotta love prototypes!  LOL

I'd be happy to do a board layout if I have time.  Are you addressing the additional ROM space at the same location as UAE has it?  I could make a new board design based on the ROM switcher I already made and add the address decoding logic and a wires for the extra address line etc.  I figure one PAL would hold all the logic.  

The ROM switcher could position the AmigaOS ROM as the default and put the first AROS FLASH at the expansion address.  Then when the ROM switcher is activated the first AROS ROM is at the normal ROM space and the expansion ROM space holds the other 512K of Flash.

That would let people install the finished board without having to program the FLASH memory first.  It could just be programmed from the AmigaOS.

This is the basic logic and assumes there are two flash chips of 512K and one ROM.  This is not Verilog or VHDL... just the basic logic.  Signals on the board are in CAPS and it does not account for inverted logic levels.

SWITCH = (RESET and SWITCH_TRIGGER ) it's a simple flip flop  that is tied to reset (so it can't change unless RESET is active and the switch trigger is active) and another signal (switch trigger) which can be a 555 timer chip (holding RESET for a preset time activates the switcher) or a wire to some button (Joystick button for example)    

HIGH_ROM_SELECT = high address decode logic (and/or of address lines stuff)

CHIP_SELECT_OUT_ROM = (CHIP_SELECT_IN and !SWITCH)

CHIP_SELECT_OUT_FLASH1 = (CHIP_SELECT_IN and SWITCH) or (HIGH_ROM_SELECT and !SWITCH)

CHIP_SELECT_OUT_FLASH2 = (SWITCH and HIGH_ROM_SELECT)

I hope that's right... I'm sick and kinda groggy.

[jdiffend]

bloodline wrote:

What do you mean dreaming? It's prefectly feasable, and only really needs this bounty to be completed.

It may be feasable but more work needs done than this bounty requires.

The coldfire has some major differences in how some things in the supervisor mode work and it would require a lot more changes to the exec and boot code than just adding the instruction emulation code.

[jdiffend]

I should also point out that the Coldfire has built in hardware that must be set up or programmed so that it doesn't conflict with the Amiga Memory map.