Milan TOS and 68060

[Rustynutt]

Does the 68060 update to the Milan update the actual ROM, or do something else when adding the 060 to the Milan?
Been awhile since I looked at the Milan setup.

If the 060 update flashes to the R0M, can someone post a Milan 060 ROM dump to look at?

Hope that makes sense, it's late

[joska]

Milan "ROM" is a bit more complicated than on real Ataris. The Milan has 512kB of flash-ROM (29F040), but unlike a real Atari this does not contain a bootable ROM image. The Milan boots something called "the bootblock", which initialise the hardware (CPU, RAM, keyboard, IDE, floppy, graphics card...) and then unpacks a packed TOS image to RAM. The RAM location is then mapped to "ROM" space and writeprotected using the MMU, and finally the bootblock jumps to TOS.

To use a 060 you need 060-support in both the bootblock and TOS. I can't remember from which version this was added, I'm using the latest beta (includes both TOS and bootblock) from Michael Schwingen on my Milan060.

[Rustynutt]

Thanks, that jogs the memory.
If as in Amiga OS, any TOS, or Milan for that matter should have to disable the 060 caches before it starts doing anything else.
Was thinking I could identify where/when this occurs on the Milan. Give me at least an idea where to patch 4.04 to test.
Or.....one of these Legends take a look at report back where I should insert it

I could try a ROM port thing, but recall using a cartridge with the AB was iffy

[joska]

On the Milan the hardware - including CPU - is set up before TOS is even started.

[Rustynutt]

That's fine, as long as I can see how it's done. When TOS starts, the CPU isn't awake yet. It's at that point, before it begins executing instructions to initialize everything is where the code to disable the cache needs to be inserted. A good point would be right after it looks to the cartridge port.
On the cold boot, the AB loads TOS into ST RAM, then does its warm reset and loads it into fast ram. Even without Doug and Magnus tool Kit.
Don't think the AB cares if TOS is patched as it loads the ROM I've made changes to now.
In theory....

[joska]

If you don't run any driver/setup-tool for the Afterburner, the Falcon will behave exactly like a stock Falcon but with a 040. The unmodified TOS is running from ROM, just like on a standard Falcon. I don't think anyone has verified exactly how the Afterburner manages to do this, but most likely the logic in the Mach-chips converts the 030 MMU/cache opcodes to NOP on the fly. The 040 caches are disabled by default, not sure if this is the case with the 060.

[ThorstenOtto]

Are you sure it is using an unmodified TOS from ROM? I think i have read that somehere that is copied to RAM, and then maybe patched there to work with 040.

[joska]

Yes, the Afterburner does not have a ROM but boots using the stock TOS on the motherboard. Then AB-driver is run from the autofolder. at first run it will set up the MMU (join fast-RAM banks, move TOS to fast-RAM and remap it, set up cache modes for the various memory regions...) and then jump to TOS. On the second boot it will Maddalt the fast-RAM, add the _FRB cookie and bend some vectors. I don't know how/if the TOS is patched - the only thing that is visible is that the Atari boot-logo is replaced to indicate that you're booting in Afterburner-mode.

[Rustynutt]

I've dumped the ROM image from ST RAM after booting the AB without drivers.
Its stored patched and different than 4.04.
When booting it, you can recognize the extra time it takes on a cold boot.
It patches it on the fly.
Even without the drivers, doing a warm reset, the AB then somehow knows this and boots from ST RAM.

Wouldn't know if or how it possible to use the dumped image in a ROM.

Centuriontech, Pavel, has a prototype programmable EPROM board, this would make test so much easier.

[Rustynutt]

Could dump the patched ROM image from ST RAM after boot. Kind-of know where it starts. Scrolling to find the end is a bit confusing for me, don't know a lot about addressing. Recall seeing many areas where the hex converted to NOP's as far as I could tell.

[Rustynutt]

Happened to think of something waiting for Santa (he never made it by ).

If code in HEX is inserted say down 5 lines, does that change the address value for everything below it?

[joska]

I've dumped the ROM image from ST RAM after booting the AB without drivers.
Its stored patched and different than 4.04.
When booting it, you can recognize the extra time it takes on a cold boot.

Where in ST-RAM do you find this image? I would not be surprised if the TOS image dumped from an AB (with no drivers running) differs from the same dump on a stock Falcon, as I suspect that the logic on the AB "NOPs" the 040-incompatible MMU/cache instructions from the TOS address range (0xe00000 - 0xe8000). If this is the case then the difference in these two images should be the occasional 0x47e1 in the AB-dumped image.

Yes, booting the AB is slower than a stock Falcon. There is atleast two reasons for that. 1, ST-RAM access on the AB is slower than on a stock Falcon, and 2, TOS will enable the 030 caches early on while it does not on the AB. So until you run the drivers an AB-equipped Falcon will be quite a bit slower than a stock Falcon.

[Rustynutt]

The slowness I'm talking about is when cold booting the AB, without drivers.

Then, do a warm reset, no drivers.
It boots ROM normal speed.

Time the difference after the Atari logo appears between cold and warm.
It's significant.

This is aside from the slower ST RAM access (~5.1/MBs)

Pretty sure, on a cold boot, it is reading the ROM and patching it into ST RAM.

It knows, without the tool kit, on warm reset, that's where it left the TOS.

I dumped that a while back with a tool.
The beginning of TOS was easy to find, but just kept dumping address until I got a file of about 600K. I'll do it again and save the file this time. Was doing house cleaning...

But that's well after where the caches need to be turned off. Those must be turned off before the cpu begins to execute any other instructions. Unlike the 040, the 060 cache is enable at power-up, according to what I've read in the Amiga world. In that case, they said the cache is corrupting the system stack before it can begin to boot. It's patched in the Amiga OS for those devices using the 68060.

An easy answer to this would be someone that knows what's going on with CT TOS, has source and understands what it's doing, not just patch it with updates

Don't get much response on that side of the Falcon

[mikro]

You must have misintepreted what they do in Amiga world. The 060 caches are, naturally, disabled by default:

cache.png

Also, having cache enabled is not some sort of evil behaviour, it matters only for memory operations. Reading instructions from ROM to CPU with cache(s) enabled can't have any catasrophic consequences unless the stack is set to memory which is yet to be configured.

For TOS dump you can always use any TOS dumping tool, patched or not, the TOS variables always point to the correct place.

[Rustynutt]

You must have misintepreted what they do in Amiga world. The 060 caches are, naturally, disabled by default:
cache.png

To quote what I read is, on the Amiga with 060, caches are enabled at boot, and thus the stack becomes corrupt. The Amiga O/S is patched to prevent this.
It's possible in this case, the 060 card for the Amiga somehow enables the caches before the O/S loads.

Also, having cache enabled is not some sort of evil behaviour, it matters only for memory operations. Reading instructions from ROM to CPU with cache(s) enabled can't have any catasrophic consequences unless the stack is set to memory which is yet to be configured.

Think there is more to it than that. It it caches reading something from ROM, and the Falcon, or AB, looks back for an address that has been cached, but no longer valid, everything stops.

Whatever is stopping the AB from loading TOS from ROM with an 060 and socket adapter occurs very early. There is some life, but don't know exactly where the hang up is.
It's well before disk initialization, or even the Falcon control registers are initialized, which is like line 19...

For TOS dump you can always use any TOS dumping tool, patched or not, the TOS variables always point to the correct place.

Forgot when one I'm using, it was in the Sparrow discussion.
For it, you need to enter an address as it's programmed to work with all machines, as I under stood the authors reply in that thread.

I finally managed to get TT Digger to work and load an image. This is the much preferred tool, however if there is a way to save the image out, I've not found it in the program.

[joska]

I dumped the ROM on my AB-Falcon just now, without any drivers running. The dumped image is identical to the 4.04 image i found here. osheader also points at 0xe00000, so I'm pretty confident that it's actually the ROM image that is running unmodified when there is no AB drivers installed.

I guess the AB is able to run stock TOS by converting the incompatible opcodes to NOP on the fly. Done by the Mach-chips on the AB, not by the CPU. The 060 is less compatible with 000-030 binaries than the 040, so the on-the-fly-adaption in the AB is not enough for a 060. You need a 060-friendly TOS in ROM. There is a 060-friendly diagnostics ROM in the CT60 ROM, maybe you could try putting this on a cartridge and boot your AB060 with it?

Btw if I dump the "ROM" when the AB-drivers are in use I get a significantly altered image. This is the image that the AB driver has copied to Fast-RAM, patched and remapped to 0xe00000.

[Rustynutt]

ill admit to shooting in the dark here.
Maybe when the AB comes up, it's doing something incompatible with the 060 itself.
Need to retest the diagnostic cart, remember it not working with the AB. Since that happens early on in TOS, maybe looking for the "magic" number is throwing something off.

Other than probe you guys for ideas, a bus analizer to see what is actually going on is in order. Might be a simple wire jump to fix it, or if in the AB logic, not fixable at all. Been a near 15 year off and on trying crap, have a lot tied up into it, not just time,effort and cost, but hope

[Rustynutt]

I dumped the ROM on my AB-Falcon just now, without any drivers running. The dumped image is identical to the 4.04 image i found here. osheader also points at 0xe00000, so I'm pretty confident that it's actually the ROM image that is running unmodified when there is no AB drivers installed.

I guess the AB is able to run stock TOS by converting the incompatible opcodes to NOP on the fly. Done by the Mach-chips on the AB, not by the CPU. The 060 is less compatible with 000-030 binaries than the 040, so the on-the-fly-adaption in the AB is not enough for a 060. You need a 060-friendly TOS in ROM. There is a 060-friendly diagnostics ROM in the CT60 ROM, maybe you could try putting this on a cartridge and boot your AB060 with it?

Btw if I dump the "ROM" when the AB-drivers are in use I get a significantly altered image. This is the image that the AB driver has copied to Fast-RAM, patched and remapped to 0xe00000.

Ok, it had been a while so stand corrected. I must of dumped the ROM with drivers installed. It surely was significantly different than 4.04.
Is the diagnostic image that is 060 compatible available? I've only seen it in use with CT TOS.

[Rustynutt]

I dumped the ROM on my AB-Falcon just now, without any drivers running. The dumped image is identical to the 4.04 image i found here. osheader also points at 0xe00000, so I'm pretty confident that it's actually the ROM image that is running unmodified when there is no AB drivers installed.

I guess the AB is able to run stock TOS by converting the incompatible opcodes to NOP on the fly. Done by the Mach-chips on the AB, not by the CPU. The 060 is less compatible with 000-030 binaries than the 040, so the on-the-fly-adaption in the AB is not enough for a 060. You need a 060-friendly TOS in ROM. There is a 060-friendly diagnostics ROM in the CT60 ROM, maybe you could try putting this on a cartridge and boot your AB060 with it?

Would the image saved out with the AB patch be bootable from ROM? Wonder what the AB would do then?

[Rustynutt]

One more thing to add, I have tried EmuTOS in ROM on the AB, and it won't boot airc.

[gstoll]

An easy answer to this would be someone that knows what's going on with CT TOS, has source and understands what it's doing, not just patch it with

There are some source from the patches for the ct60tos. Or use the ctos060.img and Digger than compare it with TOS 4.04

[Rustynutt]

Thanks for pointing that out.

Rereading the 68060UM (again).
Found another section to look into.

11.1.2.1.5 Resource Checking (Access Error Handler). Many systems use the access
error handler at some time after reset to check for the existence of I/O devices or memory.
Existing MC68040 systems already have to deal with the restart nature of the MC68040.
However, the stack frame generated by the MC68040 is significantly different from that of the MC68060. Resource checking software that relies on the stack size information must be modified appropriately.
***
When upgrading to the MC68060 from an existing MC68030 or MC68020 system, porting resource checking software may be problematic because the continuation architecture (MC68030 and MC68020) allows an operand read bus error to be ignored and not re-run the offending instruction, but a restart machine such as the MC68060 has no provisions for
doing so.
A possible work-around for this is to either increment the stacked program counter
(PC) prior to the RTE, or to use a NOP-RESOURCE_WRITE-NOP in place of the
RESOURCE_READ, in imprecise exception mode, to poke at the possible resource area.
***

[ThorstenOtto]

However, the stack frame generated by the MC68040 is significantly different from that of the MC68060. Resource checking software that relies on the stack size information must be modified appropriately.

Yes, but typically, when just probing for existence of I/O addresses, you don't look at the generated frame. Merely the fact that a buserror is generated is sufficient. Also such routines typically don't perform an RTE, so the failing instruction is never reexecuted. Look for example at the function used in EmuTOS: https://github.com/emutos/emutos/blob/2 ... rs.S#L1239

TOS normally uses a similar approach (if it does probing at all).

[joska]

Would the image saved out with the AB patch be bootable from ROM? Wonder what the AB would do then?

I don't think it will work. A few years ago I studied the sources for Doug's AB toolkit in order to understand what was needed to get EmuTOS to support the AB. IIRC there are several places where TOS is patched to call code in the toolkit driver itself, so if you booted from this modified TOS it will attempt to call non-existing code/data in RAM.

[joska]

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