TeamAROS Bounty #23 AROS Kickstart Replacement ROM

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

[bloodline]

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.

Great idea!


4 colours, 640*512 :-D

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.
 

Not really sure what you mean here :-(

The AROS graphics library is just a wrapper to the graphics.hidd which is the actual graphics driver... the AROS cybergraphics.library is also a wrapper to the graphics.hidd.

The Graphics hidd is basicly an exec library with extra bits to allow for a nice OOP design.

AROS has support for both planar and chunky graphics... as it's default mode is the 4 colour planar VGA mode that all PC gfx boards support.

[DFergATL]

To Everyone:

I still think the wording for this and what I intended are not quite the same.  It does not have to be a 3.1 Amiga OS compatiable rom.  Just an Aros "rom" that boots on UAE.

If any dev who wants to take this on but feels that the "requirements" on the Team Aros website are not stated in a pratical way.  Let me know, I do belive (could be wrong) that because I started the blasted thing I can have the wording changed....

Remember that the end goal is to be able to run Amiga software (as much as pratically possiable) run on Aros UAE (or E-UAE) without requiring an actual Amiga Rom... Recreating the entire Amgia 3.1 rom is not a requirement...Porting the entire Aros OS is not a requirement...Just the end goal......

Once again if someone wants to take this on but needs the "requirements" changed in order to make it doable...That can be done....

Dave Ferguson (DFergATL)

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

[Doobrey]

jdiffend wrote:
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.

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.

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

[bloodline]

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.

 

My Stupid brain :-(

I should have said 4 bitplanes planar, which is 16 colours :-) But that is supported by the Amiga hardware anyway so no problems :-D

[Doobrey]

jdiffend wrote:

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.

Yup..I`m building a GAL programmer now to get it all done and do the final testing.

It works pretty much as you`ve described, a jumper/switch to select either real rom or flash,another to select which is programmable at @$e00000 , and one last jumper to select either 1mb of flash or select the high or low 512k of flash if you want 2 different rom images.

The only other thing I`ve done is invert A19, so $f80000 is mapped to the lower 512kb etc, cos that way I can use the 16kb parameter block of the flash using my own nonvolatile.library for storing things like boot settings.

Get well soon, hope it wasn`t through enjoying the new year too much..
[/quote]

[bloodline]

For those using real Amigas, I have the AROS logo bootpic iff file to download Here.

I have squeezed it into 16 colours and optimized it to look correct at 640*256, looks great on my A500 :-) The file size is 24k, enjoy.

[dammy]

AROS ROM bounty has been split up to Phase I and Phase II.  Feel free to donate to both of them.

Dammy
TeamAROS

[whabang]

This actually is move towards the possibility of an Amiga-version of the C1. A coldfire-based board with AROS, running OS 3.x applications natively would be really cool.

I'm dreaming, i know, but admit it would be cool! :-D

[bloodline]

whabang wrote:
This actually is move towards the possibility of an Amiga-version of the C1. A coldfire-based board with AROS, running OS 3.x applications natively would be really cool.

I'm dreaming, i know, but admit it would be cool! :-D

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

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

[FrankBrana]

I wish I could do something in order to give a hand, but sadly coding its not my best.

It would be great load a AROS 3.1 ROM compatible in my real amiga and then load AROS instead Workbench.
Since its opensource, the new features and progs will appear from under the stones!  

it surely will give new bloodline ;-) to all the classics systems, and well, if you manage to get it working on the coldfire...as far as you go, the greatest the whole thing is.

Go ahead guys!

-FrankB

[whabang]

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

Well, there's this wee little detail of actually designing a Coldfire-board, making a Coldfire-version of AROS, make it trap the non-supported instructions (which would be limited to non-MMU, and possibly non-FPU applications),  and then write proper hardware drivers for the board, and any clones. But yes, it's doable.