Milan TOS and 68060

[Rustynutt]

Just checked the sources. GEMDOS, BIOS and XBIOS vectors points to code in RAM, so the patched ROM image can not run alone.

Ok, different approach.
Instead of using the AB Tool Kit, using the original AB programs to set the MMU and install fastram.
Allows 48MHz CPU, at a cost of Doug's trickery Memory speed is benched about 1/3 of TK5.07 in ALT RAM.

(Note if trying, the updated MMU program crashes the updated fastram program when ran from the autofolder.
These are files Doug included on the AB Took kit floppy disk.
The older versions of the driver came on a different floppy.
Replaced the ram program with the earlier version, works in autofolder below the MMU program order.
Another note using the MMU program is caches are enabled default).

Gemram is running from the autofolder with fastram flags set.
NOVA VDI (NVDI not installed)

Benchmark applications recognize TOS has been placed into fast ram (arrived by comparing test with and without Gemram installed).

How do I know the AB is reading from the Gemram installed TOS and not reading from the ROM, or the TOS in fastram on the fly?
By dumping the TOS in fastram and comparing to a TOS 4.04 binary?

Using TOSRIP.TTP found in the Sparrow thread (apologies, forgot the author).
To dump and image, or memory for that matter, you must enter a start and ending address.

What are the address values to enter?
Is there a more "click to dump" program to use?

Thanks, excuse my ignorance.

[mikro]

You can always my tool, it doesn't ask you for anything: https://github.com/mikrosk/uDump/releases/latest

[ThorstenOtto]

That tool (just like mine i wrote some time ago) only dumps the ROM, but not a TOS that was relocated to RAM. Maybe try the tool attached below (just made it up, so no guarantee).

Should give you the choice of dumping either RAM or ROM, if they differ.

[joska]

It doesn't matter when using Doug Little's AB Toolkit, as the TOS image in fast-RAM is mapped to e00000.

[Rustynutt]

Used both Mikro and Thorsten's tool.

Without GEMRAM installed, they both dump from ROM the same image as can be found in archives.

With GEMRAM installed, Thorsten's tool allows to dump the image from RAM at location $0100afba. (Thank you again!)
This image is different than standard TOS 4.04 image.

GEMRM404.ZIP.PDF

Don't know if it because what GEMRAM does when placing the image in fastram, or if the AB is patching the image on the fly.
Either way, applications that access TOS (GEMBENCH) show much faster access times using GEMRAM.

Decided to test the AB using the Atari Falcon diagnostic cartridge, where it will pass most test.
Reinstalled the 060, but it acts like it does when attempting to boot TOS, no video output or signs of life.

Because the AB with 060 doesn't seem to come up with power, and it's not even getting to the diagnostic cart.
this may be a hardware issue, not related to TOS. TOS looks at the cartridge very early on.
So if a TOS issue, it could be easy to spot.

The 060 to 040 adapter is a tested working unit, when purchased.
For me to double check this, I'd have to pull the Milan board out and see if it boots with the 060.

Another oddity discovered with the AB installed is the Exxos diagnostic cartridge doesn't work.
I've tested it on a standard Falcon before. Using one of those to put a CT60 diagnostic ROM into would
be a lot nicer than having to do split ROM 2 chip.

[Rustynutt]

One last thought on an O/S.
Has anyone burned MagiC into ROM for an Afterburner?
In the German documents, there are separate programs to set up the PMMU and install fast ram, but that's loading it from disk.

[ThorstenOtto]

Don't know if it because what GEMRAM does when placing the image in fastram, or if the AB is patching the image on the fly.

That will be hard to tell. GEMRAM at least relocates the ROM, replacing all absolute addresses to the new location. That will cause a lot of differences. You could maybe take the patch files from the TOSPATCH tool, and create a relocated version of the ROM to the same address (without applying any patches), and compare that to the dumped version.

[joska]

Used both Mikro and Thorsten's tool.

Without GEMRAM installed, they both dump from ROM the same image as can be found in archives.

This is *without* the AB toolkit running I guess? Do not run GEMRAM when using the toolkit, because the toolkit already has "GEMRAM" built-in.

With GEMRAM installed, Thorsten's tool allows to dump the image from RAM at location $0100afba. (Thank you again!)
This image is different than standard TOS 4.04 image.

As Thorsten has already pointed out, GEMRAM will relocate the TOS image, i.e. it will alter all absolute adresses in the entire TOS image so it can be run from another address than the default (which is e00000). The AB Toolkit does not do this, instead it will use the MMU to map the fast-RAM area containing the TOS image to e00000. So if you dump e00000-e8000 when the AB toolkit is running (not GEMRAM!) you will get a dump of the toolkit-patched TOS, but if you dump the same memory region *without* the toolkit you will get an exact dump of the actual ROM image.

There is no use for GEMRAM on the AB. The AB toolkit does the same thing and more. It even mimics GEMRAM, this allows WINX to work.

[Rustynutt]

Again, I'm not using Doug's and Magnus's Took Kit.

The Afterburner originally came with a PMMU and Fast Ram initialisation tool, this is what I'm currently using. It does not copy or patch TOS into RAM.

This is because I've been experimenting with a higher clock speed than TK5.07 allows.

Also, using the Tool Kit, don't think I'll be able to determine just why the 060 doesn't boot.

[Rustynutt]

Don't know if it because what GEMRAM does when placing the image in fastram, or if the AB is patching the image on the fly.

That will be hard to tell. GEMRAM at least relocates the ROM, replacing all absolute addresses to the new location. That will cause a lot of differences. You could maybe take the patch files from the TOSPATCH tool, and create a relocated version of the ROM to the same address (without applying any patches), and compare that to the dumped version.

Have to read about TOSPATCH tool.

With the TOS image in RAM after boot unmodified, think now the AB is not actually patching anything, having code in the MACH chips to get over a hardware hump until TOS can load. Be an effort to figure this out with an analyzer and no documentation.

Joska's been trying to tell me this It's probably simple, and likely hard coded. Wouldn't make sense otherwise

Then....

Be interesting to sort why EmuTOS runs to an extent as an executable, but not from ROM. A hardware discrepancy between the two.

Leaning towards the 060 not working due to a simular conflict in AB firmware. It's failing even before TOS gets started during initialisation.

Worse case, have about maximized the clock performance of the 040 throughout this, 50/25 MHz, and eliminated need for the Nemesis, and discovered a clock patch only need to be a basic 74F04, nothing special with 13MHz bus.
A bit more to squeeze out with hardware mods yet to be tested.

[joska]

This is because I've been experimenting with a higher clock speed than TK5.07 allows.

I see. But to be honest - you will get more speed and stability out of the AB at 46Mhz and Doug's drivers than at 50MHz with the original drivers. But I guess you know this already.

Leaning towards the 060 not working due to a simular conflict in AB firmware. It's failing even before TOS gets started during initialisation.

I guess the problem is that the Mach-chips on the AB does the bare minimum to boot plain TOS on a 040. The 060 differs quite a bit from the 040, so it probably crashes at some unsupported opcode early on.

If you want to find out if the 060 actually works on an Afterburner, you will probably have to replace the TOS ROM with a very, very simple piece of code just to see if the CPU is actually doing anything. The approach the problem like the Milan and CT60 does - replace TOS with some bootcode that initialise the hardware, unpacks a packed (and patched/modified) TOS or EmuTOS to fast-RAM and finally jump to it. Something like this would be very useful even on a standard AB, as it would speed up booting a lot.

[Rustynutt]

This is because I've been experimenting with a higher clock speed than TK5.07 allows.

I see. But to be honest - you will get more speed and stability out of the AB at 46Mhz and Doug's drivers than at 50MHz with the original drivers. But I guess you know this already.

Leaning towards the 060 not working due to a simular conflict in AB firmware. It's failing even before TOS gets started during initialisation.

I guess the problem is that the Mach-chips on the AB does the bare minimum to boot plain TOS on a 040. The 060 differs quite a bit from the 040, so it probably crashes at some unsupported opcode early on.

If you want to find out if the 060 actually works on an Afterburner, you will probably have to replace the TOS ROM with a very, very simple piece of code just to see if the CPU is actually doing anything. The approach the problem like the Milan and CT60 does - replace TOS with some bootcode that initialise the hardware, unpacks a packed (and patched/modified) TOS or EmuTOS to fast-RAM and finally jump to it. Something like this would be very useful even on a standard AB, as it would speed up booting a lot.

Yes, the Tool Kit settings really kick it in the ass. However, the way the caches are enabled dices with fastram above 46MHz.
Mainly wanted to get a baseline of the 040 overclock point, and work backwards.
Early on, years back, the discussion was always around RF shielding, clock patch, clock driver rating, ect.
It's not, it's the AB ram interface being too slow at those speeds the way the TK caches data. With just D and I cache set, no problem at 50MHz using the old drivers.
Has something to so with the XMMU (I think).

Been eyeballing that 32bit header.....be a good spot to stick a flashrom.

[Rustynutt]

No new 060 progress, but an Afterburner ROM report.

Was interested in WINX, it will create a patched TOS IMG from an unmodified ROM file.

Tried it with the edited ROM in the Falcon where the register is changed to keep the Blitter at 8MHz. It didn't like the ROM, said it's not a valid TOS. It could be because I've never fixed the CRC error there.

Anyway, patched a standard TOS 4.04 image with WINX, loaded into the programmer, made the register changes for the blitter speed and burned a WINX modified TOS 4.04 ROM.

The Afterburner loads it without issue, and wow, it's a nice huge improvement over standard TOS 4.04.

This "kind" of indicates something I've been suspect too using the 060 adapter. There is a hardware problem not specifically related to the AB I believe.

Solved another issue with the caches as well. Think it's in another post though, will look and follow up there.