New Kickstart 3.9.1 68k on the way

[olsen]

No. If for example an A3000 is not detected, the scsi_3000.device inside my kickstart won't init... You really take me for a beginner in coding...

Please don't assume that I make assumptions about your abilities.

How do you detect the A3000 hardware, as opposed to the A4000 hardware? As far as I could claim to understand the specs, the A3000 hardware was not designed to support auto-detection of features, as opposed to the Gary/Gail hardware used in the A4000/A1200/A600, respectively.

[Cosmos]

How do you detect the A3000 hardware, as opposed to the A4000 hardware?

With Ramsey !

[Oldsmobile_Mike]

I want a fully system ready at power on. No more SetPatch, no more boring and slow loading on HD or CF. The goal is like the old computers : Oric, Amstrad, Atari ST...

A noble goal.  I missed that when I went from C64 to Amiga.  We've all just gotten used to requiring a disk to boot with "modern" computers.

TBH, a lot of these things get updated frequently, however.  A new version of icon.library was just released two days ago.  It's going to be hard to keep current, if you want "the latest and greatest" in your ROM.

TLSFmem would be fantastic, good luck!  

[mechy]

You are correct.

The SCSI "scsi.device" versions in the A3000 and A4000T ROMs are built to assume that the hardware required for SCSI operations (DMA controller, WD or NCR SCSI chip, respectively) is present. This built-in hardware is not placed in AutoConfig space.

The IDE "scsi.device" present in the A600HD, A1200HD and A4000/A4000T can auto-detect the presence of the required Gayle/Gary hardware, which as far as I know is not a given for the A3000/A4000T specific SCSI hardware.

The other reason why there are ROMs specific to the A3000 and A4000 models is in that the RAM controller (Ramsey) may have to be asked to support page mode for the peculiar type of DRAM that may be installed in these machines. As far as I can tell this does not seem to be necessary, though. Support for page mode (also called "static column mode") was intended to improve DRAM performance on the A3000, using the 68030 under certain circumstances. In practice the gains were not as significant. If I read my A3000T service manual correctly, Ramsey should boot with safe defaults, which makes switching to page mode unnecessary; it's also quite difficult to do without crashing, because you have to fiddle with the Ramsey configuration while not running afoul of ongoing DRAM refresh and other flaming hoops to jump through.

Finally, different types of ROMs are required by different machines, with respect to where the kernel is to look for ROMTags, how much stack space it may use, etc. If I remember correctly, the big difference here is between the machines built around the architecture of the A3000 (which includes the A4000 and A1200 models) and those which precede it (this being the A2000 and the A500; I think the A600 belongs here, too).

In a nutshell, if you're going to bootstrap the system, from the bare metal, in a real Amiga, then you will have a devil of a time getting the basic three "scsi.device" variations to work together in ROM: one of them will always crash.

Olsen, i may be reading this wrong,but static column ram and page mode are 2 different things. static column is just that static ram,and page mode ram is more akin to the fpm style ram. the ramsey revision 4 had a bug in it where when the a3000 is used with a A3640, it will not detect and use static column ram properly,hence page mode zips must be in the first bank to thwart this bug(page mode and static column can be mixed in this situation still-but all runs in pagemode). This was fixed in ramsey 7 which detects the ram correctly as i understand. This has been my real life experience using the real machines.

[Cosmos]

TBH, a lot of these things get updated frequently, however.  A new version of icon.library was just released two days ago.  It's going to be hard to keep current, if you want "the latest and greatest" in your ROM

PeterK will finish it one day !


Note : in the beta 2, I have about 300 Kb still free on the 1 Mb Kickstart... And all libraries inside are uncompressed for the moment...

For example, the workbench.library take about 192 Kb. Compressed only 95 Kb !!

[olsen]

How do you detect the A3000 hardware, as opposed to the A4000 hardware?

With Ramsey !

Hm... both A3000 and A4000 have Ramsey chips installed, no other shipping model does. There's a hardware version register at $DE0043 which can be read and should contain a specific value. Reading from the Ramsey control register at $DE0003 should be possible from supervisor mode (with trap handlers, etc. installed and armed), and if the system just came up then it probably holds a default pattern. That could work, for A3000 and A4000 detection. To discriminate between the two, the Denise/Lisa version could be used, or the presence of the Gary/Gayle chip (if this works on the A3000).

That looks plausible to me. Now, how do you discriminate between the A4000 and the A4000T?

[olsen]

Olsen, i may be reading this wrong,but static column ram and page mode are 2 different things. static column is just that static ram,and page mode ram is more akin to the fpm style ram. the ramsey revision 4 had a bug in it where when the a3000 is used with a A3640, it will not detect and use static column ram properly,hence page mode zips must be in the first bank to thwart this bug(page mode and static column can be mixed in this situation still-but all runs in pagemode). This was fixed in ramsey 7 which detects the ram correctly as i understand. This has been my real life experience using the real machines.

You must be correct. My documentation (A3000T service manual, page 2-58) on the Ramsey control register does not mention static column mode by name, it only mentions page mode prominently.

Some snooping in the A3000/A4000 bonus module suggests that "static column mode" a combination of the burst, wrap and page mode options. The bonus module enables these options and then performs a non-destructive read/write test to memory. If the data read back matches what was stored then static column mode can be left enabled, otherwise the DRAM does not support static column mode and the default control options are restored.

That test for static column mode is skipped if the Ramsey version suggests that the chip is too old.

[SpeedGeek]

This makes sense.
The ROM read physically limited to 3.5 MB/sec on classic
To fastmem on a CPU card the read speed would be over a magnitude faster.
This means for performance reasons we want to put the Kick in fastmem anyway.

So A1000 design to have a small bootrom and the KICK then placed into WOM-Ram is ideally for this.

Good sense or bad sense? The ROM speed is only limited to 3.5MB/sec on 68000 base machines. The 68020+ base machines can manage 12-20 MB/sec ROM speeds. This is much faster than most IDE or SCSI controllers could seek and load a 512KB (or even a 1MB Kickstart). Loading individual libraries and modules is even slower.

The amount of extra code and data files in OS3.9 BB1-4 already adds a significant boot delay without including any 3rd party stuff. If you want a faster Kickstart for 68000 base machines than why not remap it in to 32 bit Fast RAM?

[guest11527]

A noble goal.  I missed that when I went from C64 to Amiga.  We've all just gotten used to requiring a disk to boot with "modern" computers.

And where precisely is the problem with that? I've here a SSD in a modern system, boots up in probably ten seconds, makes no noise. You can also bootstrap the Amiga from an SD-card, much simpler, fast enough for the purpose, no noise, takes almost no space. The advantage is that is so simple to exchange system components. Read it as "flash RAM containing the kickstart files" if that makes it sound better.

[biggun]

If you want a faster Kickstart for 68000 base machines than why not remap it in to 32 bit Fast RAM?

This is what I'm saying.
In 68K CPU card you can read over 100 Mb/sec from memory.
This means you want your Kick in fastmem and not in ROM in the end.

[psxphill]

Finally, different types of ROMs are required by different machines, with respect to where the kernel is to look for ROMTags, how much stack space it may use, etc. If I remember correctly, the big difference here is between the machines built around the architecture of the A3000 (which includes the A4000 and A1200 models) and those which precede it (this being the A2000 and the A500; I think the A600 belongs here, too).

No, you can run an A500 with an A1200 kickstart. I was using Kickstart 3.0 on an A500 before 3.1 came out. There are a ton of bugs with OCS/ECS, but that was just because they didn't prioritise fixing them.

The main difference is A500/A2000/A600 uses a single 16 bit rom and later machines use two 16 bit roms to provide 32 bits. Which provides a physical reason for the difference, although the actual contents could have been the same across them all.

For Kickstart 3.1 there were different versions for different hardware because there wasn't enough time to fix all the bugs (they'd fix one and it would break something else) and also due to rom size (A4000T needing both scsi & ide for example). They could have pushed workbench.library onto disk for everybody and included all the devices with auto detection, but there wasn't a business case for it.
 
 There was also the A4000/A1200/A600 ide being different, but again that could have been handled by detecting whether you had gayle or not and handling different code paths.

[QuikSanz]

And where precisely is the problem with that? I've here a SSD in a modern system, boots up in probably ten seconds, makes no noise. You can also bootstrap the Amiga from an SD-card, much simpler, fast enough for the purpose, no noise, takes almost no space. The advantage is that is so simple to exchange system components. Read it as "flash RAM containing the kickstart files" if that makes it sound better.

Hmmm, and with an editor, you could even tailor your own. Interesting.

Chris

[carvedeye]

There are probably lots things on everyone's wish list.  The first item on mine would be the ability to boot from CD.  This would make preserving our favorite system a lot more foolproof and user friendly going forward.

I agree, think it would be so much easier to setup OS 3.5/3.9 when doing a clean install.

[Ratte]

For Kickstart 3.1 there were different versions for different hardware because there wasn't enough time to fix all the bugs (they'd fix one and it would break something else) and also due to rom size (A4000T needing both scsi & ide for example). They could have pushed workbench.library onto disk for everybody and included all the devices with auto detection, but there wasn't a business case for it.

Thats not true.

There are different hardwarespecific versions of exec, expansion and devices.
The A1200,A3000,A4000 & CD32 versions are 020+ optimized .. not working on 68000.
The A3000 is very special .. the ONLY rom with real FPU-code inside !!!
A600/A1200 includes some PCMCIA-code.
A3000/4000 includes "bonus" for onboard fastmem.

[psxphill]

Thats not true.

There are different hardwarespecific versions of exec, expansion and devices.
The A1200,A3000,A4000 & CD32 versions are 020+ optimized .. not working on 68000.
The A3000 is very special .. the ONLY rom with real FPU-code inside !!!
A600/A1200 includes some PCMCIA-code.
A3000/4000 includes "bonus" for onboard fastmem.

It's true that back in the day I ran Kickstart 3.0 from an A1200 on an A500 with a phase vi 14mhz 68000 (I didn't try 3.1 as I bought the a500 upgrade). It's true that they cherry picked different releases for each platform based on which worked at the time they submitted the 3.1 roms to manufacturing (I'm sure that years ago there was an description written by someone at commodore about why they picked each one). it's true that they could have produced one that worked in them all if there was a financial reason to.

[Oldsmobile_Mike]

It's true that back in the day I ran Kickstart 3.0 from an A1200 on an A500 with a phase vi 14mhz 68000 (I didn't try 3.1 as I bought the a500 upgrade). It's true that they cherry picked different releases for each platform based on which worked at the time they submitted the 3.1 roms to manufacturing (I'm sure that years ago there was an description written by someone at commodore about why they picked each one). it's true that they could have produced one that worked in them all if there was a financial reason to.

I assume you mean you soft-kicked this, because I don't see how you would've gotten the two ROM's from an A1200 to fit in the one socket on an A500.  

3.1 was released after C= went bankrupt.  I think it was by Village Tronic.

I'm dubious of how much "020 optimization" went into any of these releases.  Think that was more on the Workbench software side, than in the ROM's?