Kickstart ROM Replacement (Phase I) Bounty Assigned

[vidarh]

People need to stop thinking that what is to them "pointless" things to work on will somehow take away development from other parts of AROS! this is one guy who wanted to do this particular bounty, if he didnt work on this one, chances are he wouldn't work on anything else in AROS either, and this is true with a lot of bountys and other AROS related work. People come or join in to work on stuff they want and quite a few stop contributing to AROS once they reached they're goals whatever they may be.

Not only this, but a working, binary compatible version of AROS on real Amiga's is pretty much the holy grail for determining how compatible AROS is with real AmigaOS.

I did a bunch of work to the console.device and console handler in AROS recently, and to debug incompatibilities with AmigaOS I had to spend a lot of time getting really old AmigaOS example code compile with AROS on x86. With AROS running fine on m68k Amiga's, I could've gone straight to running Amiga apps as test cases.

Getting it running should help us fix a lot of bugs and incompatibilities that will benefit AROS as a whole

[vidarh]

@vidarh
Thanks for updating the console handler, it was very much needed.

Thanks. I was desperate There's still lots to do there, though - I'm hoping to get some time to do more with it later. Work + ironing out bugs in the AROS FrexxEd port is holding me up at the moment.

[vidarh]

Then you are talking of some Amigas, a new os oriented for rtg people isnt the real world talking of classic amigas.

Why do you think it would be "oriented for rtg people" just because it'll make it possible to replace drivers for those who want it?

The point of AROS being open source is that it means people can take it in whatever direction they want - those that want just original hardware can stick with that and still get enhancements; those that want to use all kinds of expansions can get them better integrated with the core. And those who want different hardware altogether can still enjoy an AmigaOS like OS.

It's not either/or.

[vidarh]

It's awesome work by Jason (and Toni)... As soon as I get some time I'll start optimizing some of my code for it. Hope we will start seeing a flurry of updates from various other people now that it's possible to test.

[vidarh]

I'm pretty sure we'll end up with 1.3 and 3.1 compatible ROMs plus AROS ROMs if we want any added functionality from AROS.  I just don't see how both in one ROM could work.

Do you have anything specific in mind? For the most part care has been taken to keep structures the same etc., and the only really major incompatibility I'm aware of that impacts "normal" user-level apps is the dos packet vs. device interface incompatibility which is slated to be fixed for 1.0; other than that there's a bunch of bugs and currently unimplemented bits and pieces of course, but that's a different matter.

Of course any code that relies on specific ROM offsets etc. to work will fail miserably, but most of that type of code started failing already with 1.3.

[vidarh]

I wasn't trying to FUD, I'm a huge supporter of AROS on both 68k and x86.

I suppose I was a bit too harsh in saying "not remotely binary compatible", but having just a few cli commands is far from loading up a real application.  Those haven't even touched the UI yet.

There is a lot in AROS that wasn't in OS3.1, for example the HIDD, that are required to be in the ROM.  I'm not sure what the plan is, to support HIDD in ROM or have an OS3.1-like hardware banging arrangement, but shrinking it all down to 512k with HIDD seems unlikely.

I don't think the HIDD adds all that much - the code to bang the hardware needs to go somewhere. The HIDDs just adds a tiny bit of indirection. Some work might be needed to allow excluding generic versions of the code paths, though, and I'm sure there'll be other optimization work along similar lines to selectively reduce the code generated.

Also it doesn't necessarily all need to fit in 512k. First of all most Amigas can take 1MB kickstarts if you're first going to replace the ROM (and for Toni's needs this works fine for most uses anyway, as UAE handles 1MB ROMs). Secondly for most purposes it only needs to bootstrap and load the rest from a device, though of course this wouldn't be great for Minimig's or classics with just a floppy (but how many would leave their classic unexpanded and still want to use AROS on it?) and not ideal for UAE either.

The current x86 kickstart is 1.5MB, so 1MB doesn't seem too impossible, worst case by pushing various AROS-specific functionality to on disk modules. 512k might be a stretch. I might agree with you that if specific software has problems with that, then creating a custom 1.3 compatible kickstart might be worthwhile but I don't think you'll need to split 3.1 vs. "full AROS" as I don't think much software that works on 3.1 will make assumptions that can't be accommodated.

In terms of compatibility, there are some bits I know will cause minor problems (AmigaOS ConClip for example won't work with AROS console handler, and uses undocumented library calls, - but it'll be easy enough to prevent it from doing any damage by stubbing them out for cases where it's included on boot floppies etc.). I'm sure there are many others that I'm not aware of, so of course it'll be a lot of work, but since AROS is by no means set in stone and everything is set up for quite a bit of API breakage in AROS for 1.0 anyway, I think it'll get fixed.

The nice things about having the m68k port now is that we can start using real AmigaOS apps as test cases - that alone will probably make things progress a lot faster. For my console changes for example I wasted a lot of time cleaning up old console example code to get it to compile under AROS to compare with how it behaved under UAE, while with the m68k port I can hopefully soon run this code directly, side by side with two different UAE configs.

[vidarh]

Not all Minimigs have enough memory to be very usable that way. Also the current firmware doesn't support 1MB kickstarts AFAIK, but that ought to be easy enough to fix (or work around by having a 512KB kickstart that loads the rest as part of bootstrapping.

The FPGA Arcade cards or Natami are probably better suited... But we'll see how far down in size Toni and Jason manage to squeeze the ROMs..

It also depends on what you want to use it for. For trackloading hardware banging games a minimal kickstart would likely be enough. For system friendly harddisk images it won't matter too much if it'd need to load additional modules from disk. ADF images for games that are sort-of system friendly might be the biggest hassle, as they might rely on more of the kickstart and not have enough space to start messing with them to add additional modules.

EDIT: Despite the lack of 1MB kickrom support at least on my Minimig, I tried to just load the first 512K ROM anyway to see how far it got in the boot process - unfortunately it just went to a blank purple screen. Not too surprising, but I just had to give it a go anyway