Kickstart ROM Replacement (Phase I) Bounty Assigned

[bloodline]

It means free, as in "freedom"
Even though the road may still be long to have a full working kickstart/os replacement (it's only a proof of concept here, compatibility wasn't part of the phase 1 bounty), it's great indeed.

Compatibility not required by bounty... But HUNK loading does work already and Jason has tested this with a few shell commands, so big thumbs up there!

Seeing how fast it was since the bounty has been assigned, I'm wondering why it took so much time for someone to get assigned to the task... People weren't interested maybe ?

I think getting the AROS source to build in gcc for the 68k was both boring and difficult... Jason (and Toni), stuck with it and made it happen!

From reading the mailing list, it seems some people aren't interested at all about NG stuff, while some on the contrary are only interested in NG stuff.

Well, AROS on 68k is where NG meets classic... You really can have the best of both worlds now

[Piru]

I can't believe I've waited so long to see this... I hope everyone understands the enormity of what this means!

Frankly I don't see the enormity. It gets interesting if/when Phase II gets completed.

[bloodline]

Frankly I don't see the enormity. It gets interesting if/when Phase II gets completed.

The tyranny of Amiga Inc. is now over! This exists and it can't unexist

Toni has been instrumental in getting the 68k drivers this far, I have little doubt he will
succeed with phaseII and even if he doesn't, people will improve AROS 68k over time anyway

[Heiroglyph]

I'm sure Toni has the compatibility part covered although there are a lot of overall AROS changes that need to happen to get him there.

AROS is just somewhat source compatible, not remotely binary compatible.

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.

This is really awesome news though, it's a huge step forward.

[bloodline]

I'm sure Toni has the compatibility part covered although there are a lot of overall AROS changes that need to happen to get him there.

The latest version of gcc is being a pain, but Jason wants to replace that with LLVM... What else is there that have I forgotten?

AROS is just somewhat source compatible, not remotely binary compatible.

Careful not to FUD here, from Jason's statement:

3. Initially binary compatability isnt needed with amigaos (not until atleast you can get the thing working again)

**- Met and exceeded. AmigaOS HUNK loading appears to work for several
** *trivial 'C' compiled AmigaOS 3.x routines (ie Echo, Dir, etc)

So actually it is "remotely" binary compatible...

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.

This is really awesome news though, it's a huge step forward.

Possibly the biggest step after the MiniMig/UAE freed us from ageing hardware

[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.

[Heiroglyph]

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.

Toni wants to make a 1.3 and 3.1 ROM for use with WinUAE and old games.  Anything that is added will use more ROM space and push it further from 100% compatibility.

As much as our goals overlap, make no mistake, Toni has stated a free WinUAE ROM as his target which makes sense given his primary project.

As vidarh noted, ABI 1.0 will alleviate several of the problems I indirectly referenced, but we're not there yet.  It will take more than just the ROM to get it functional.

I'm just saying that it's still a lot of work from all involved, not just Toni, but I'm extremely confident that he can pull off his part.

[bloodline]

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.

As usual the subtleties of language are generally lost on a web forum The ABI for the graphics library does use the wrong address register at the moment so in that regard there are binary incompatibilities, but these will be fixed.

It's important not to get the wrong message across, best to stick with the facts as they stand.

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.

A bare minimum should be possible with a 1Meg rom...

Toni wants to make a 1.3 and 3.1 ROM for use with WinUAE and old games.  Anything that is added will use more ROM space and push it further from 100% compatibility.

That is up to Toni, there are plenty of ways to save ROM space if need be, as you say direct hardware control rather than using the HIDDs. But that is up to whoever is building the ROM

As much as our goals overlap, make no mistake, Toni has stated a free WinUAE ROM as his target which makes sense given his primary project.

As vidarh noted, ABI 1.0 will alleviate several of the problems I indirectly referenced, but we're not there yet.  It will take more than just the ROM to get it functional.

I'm just saying that it's still a lot of work from all involved, not just Toni, but I'm extremely confident that he can pull off his part.

I am too.

[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.

[Belial6]

I doubt many would want AROS on an unexpanded classic (Although I could be wrong), I think that it will be a big deal for systems like the MiniMig.  A lot of us want to be able to buy brand new classic Amigas.  Given how poorly AInc has behaved, many of us would rather they become a footnote denoting the dark time between Commodore and AROS.

You point out that most Amigas can take 1MB kickstarts.  Is there any case where we should not be able to use a 1MB kickstart in a MiniMig?

[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

[Belial6]

Would the extra memory from the memory upgrade make it possible to have as much free usable memory as a non-upgraded MiniMig?

[little]

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.

What is the problem if you install those to hard disk using whdload? Also, I do not think there will ever be a 1.3 compatible aros kickstart, but then again, whdload solves the problem quite nicely.

[nicholas]

What is the problem if you install those to hard disk using whdload? Also, I do not think there will ever be a 1.3 compatible aros kickstart, but then again, whdload solves the problem quite nicely.

I'm sure there will be, do not underestimate the genius that is Toni Wilen!

[bloodline]

I'm sure there will be, do not underestimate the genius that is Toni Wilen!

And Jason's dedication to getting BCPL calls working