Welcome, Guest. Please login or register.

Author Topic: Kickstart ROM Replacement (Phase I) Bounty Assigned  (Read 17915 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Heiroglyph

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show all replies
Re: Kickstart ROM Replacement (Phase I) Bounty Assigned
« on: October 15, 2010, 04:14:25 AM »
I'm not sure why this isn't exciting to Real Amiga owners.

New Kickstart
Potential for CD-Rom boot
Potential replacements for all outdated OS parts
Standards for drivers
Standards for RTG
Standards for PCI access

Most importantly, developers can finally develop RTG and other drivers, bypassing the assholes in control of Picasso, Cybervision and proprietary PCI buses.  (If anyone has hurt the 68k cause, it's those guys)

And nobody can sue this project out of business, it's open source so it can live forever.

Once it is ABI compatible, this will be the biggest thing for Amiga since OS3.1!
 

Offline Heiroglyph

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show all replies
Re: Kickstart ROM Replacement (Phase I) Bounty Assigned
« Reply #1 on: October 15, 2010, 05:43:30 AM »
That's yet to be seen.

There is more to Aros than OS3.1, but then most of us don't run 3.1 as it shipped either.

I'm sure it will take more RAM, but with care there is no reason it can't have similar speed.

I'm sure initially it will be slower, but that can be fixed with enough skill and time.

It's incredibly hard to make binary patches for an OS you don't have the source code for, yet people have patched many improvements into the older AmigaOS.

It's possible that with the source code readily available to more developers, Aros could even be faster than 3.1 someday.
 

Offline Heiroglyph

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show all replies
Re: Kickstart ROM Replacement (Phase I) Bounty Assigned
« Reply #2 on: October 15, 2010, 06:14:31 AM »
Between using C instead of assembly and having many more (sorely needed) features, I'd bet on more RAM.

Probably less RAM than 100 different third party additions, but certainly more than 3.1 used.
 

Offline Heiroglyph

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show all replies
Re: Kickstart ROM Replacement (Phase I) Bounty Assigned
« Reply #3 on: October 15, 2010, 04:19:48 PM »
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.
 

Offline Heiroglyph

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show all replies
Re: Kickstart ROM Replacement (Phase I) Bounty Assigned
« Reply #4 on: October 15, 2010, 04:30:46 PM »
I didn't think of it that way, but yes, that could definitely work.

I was thinking more like my 4000T that has workbench.library on disk for a similar reason.
 

Offline Heiroglyph

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show all replies
Re: Kickstart ROM Replacement (Phase I) Bounty Assigned
« Reply #5 on: November 15, 2010, 03:12:19 PM »
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.
 

Offline Heiroglyph

  • Hero Member
  • *****
  • Join Date: Jun 2010
  • Posts: 1100
    • Show all replies
Re: Kickstart ROM Replacement (Phase I) Bounty Assigned
« Reply #6 on: November 15, 2010, 04:23:36 PM »
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.