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.