FixBoard030 1.0 released

[SpeedGeek]

FixBoard030 1.0 ©SpeedGeek 2023

INTRODUCTION:
FixBoard030 is a MMU tool which supports the AmigaOS CPU FastROM
command. It will mark the specified Zorro2 spaces as Cache Inhibit. This tool should enable BridgeBoard users to obtain much better Amiga system performance than most previously used MMU tools provided. Most Zorro2 I/O Boards are not affected by the 68030 CIIN feature (bug) and won't need this tool but BridgeBoards are a notable exception. Also, some BridgeBoards are using the Zorro2 Fast RAM space as I/O space.

FEATURES:
- Marks $E80000 space as cache inhibit
- Marks $A00000 space as cache inhibit
- Marks unused Zorro2 Fast RAM space as cache inhibit

REQUIREMENTS:
- 68030 CPU and MMU
- AmigaOS CPU command v44.4 (or older version)

DISCLAIMER:
Use at your own risk. No warranty expressed or implied, etc.

NOTES:
68EC030 user's are not guaranteed to have a functional MMU. But sometimes they do get a MMU which seems to be at least partially functional. So another case of your mileage will vary. Always remember, the "CPU NODATACACHE" option is a good alternative to the under-performing MMU solutions. Sorry, this tool will not fix any of the rare Zorro3 I/O Boards which may be affected by the CIIN feature (bug).

OS3.1.4+ USERS:
Unfortunately, the CPU command was downgraded with these versions so you will need to use an older version (see requirements). Also, if the 68030.library was installed then you will need to disable it to use CPU [FASTROM].

HISTORY:
v1.0 - First release

[thebajaguy]

Happy to see this tool as a modern option to the elder SetCPU back in the day.

The only thing I'd like in this is a TTX-register only option. It would use the TTX registers to map the lower 16MB (motherboard) as Data NoCache. The ideal target for this option would be the Classic systems (68K native) w/68EC030 accelerators which have the non-MMU CPU, and systems with no 32-bit memory in Zorro II AutoConfig 8M land.

(A little bit of 16-bit AutoConfig Fast probably wouldn't care too much, either).

As for the Bridgecard option (with MMU), any AutoConfig board that lands in 8M space, and is not part of the memory list, is shared memory (I/O effectively), and shouldn't get cached. All 2M/4M RTG cards and possibly the Golden Gate BB fall into this category. The latter has a unique Amiga memory option that can be configured, so it's a rare and unique corner case.

[SpeedGeek]

The TTX option disables both the instruction and data caches. This will result in a performance loss similar to the LE MMU config:

http://eab.abime.net/showthread.php?t=108534

68EC030 user's can try CPU [FASTROM] to determine if they have a partially functional MMU. CPU [FASTROM] does not manage the full 32 bits of address space or use the long format MMU table setup.

Even if their MMU is completely non-functional, they are still better off (performance wise) to use the CPU [NODATACACHE] option as explained above.

[Thomas Richter]

Probably Robert's request or comment was not quite clear. The issue of the 030 is that it caches writes into Zorro-II space potentially, even though it should not. If there is no MMU for fine-grained control of the Z-II area available, you can still arrange to disable caching on writes into the 24-bit address space just by using TTx, but even *without* inflicting potentially caching reads from the same area.

TTx has an option (mask/value pair) for the function codes (set the function codes to user data, supervisor data), and an option for read/write (on the 030). Set that to "write". This way, reads from the area could be cached if the board logic decides to cache them, no matter whether instruction or data. The CIIN-logic of the board would then decide on whether caching is inhibited or not (potentially incorrect, but that is the best you can do with such a coarse granularity of 16MB). Writes would not be cached, due to TTX, and thus would work around the CIIN erratum of the 68030.

IOWs, that would use the board CIIN logic for deciding the caching mode of reads, but would override the (broken) CIIN logic for writes for the entire 24bit area due to TTX.

The only problem is that it also inhibits data write caching into board memory that appears in the Z-II area, such as of the GVP 030 Combo boards, and it does (potentially) not inhibit caching into IO areas outside of the Zorro-II area. So it is not a perfect solution, but probably the closest approximation you can get without a MMU.

[SpeedGeek]

It was not clear his request for the TTX register option was for write cycles only. He was requesting the option for the data cache which can't be managed separately from the instruction cache (except with the CACR).

Your write cycle only TTX solution should work well (but I not sure it would handle read-modify-write cycles properly). I also don't like the limited granularity of the TTX register managing the full 16MB of address space.

I don't own a BridgeBoard, so I really can't test this tool and be sure it's working properly. But at least with the MMU, I can verify it's functionality with an MMU tool.

I also think the 68EC030 itself was more of marketing policy for Motorola rather than a hardware policy. It allowed them to sell full 68030's with minor MMU defects or just full 68030's without MMU warranty.

[Thomas Richter]

For the records, the 68030.library does pretty much this, except that it disables caching for all data accesses (not only writes), but not for instruction accesses. This is a bit more conservative as it is not quite clear what happens with areas in the Z-II space that cannot be cached. For example, I would not know how a board logic would be able to determine whether an access into the Z-II area goes into graphics cards RAM, or into regular expansion RAM. The former cannot be cached in general as an accelerator (aka "Blitter") can overwrite the VRAM contents, the latter can be cached.

Instruction caching *should* in general be fine (unless someone comes up with the really silly idea of placing instructions in video RAM and using the blitter to move it around).

The only problem is that I am not aware of a 100% fool proof way of detecting an EC030, as you said, it may be that Mot just sold 030's with a partially defective MMU as EC030, or even regular 68030 they had still in stock, or just regular 030 that did not run through a full test cycle. It's currently a "access MMU registers, and check whether remapping works".

[thebajaguy]

Thor effectively explained my comment better.

This was exactly the solution that Ralph Babel's ec030 patch (an unrleased tool, although I wish it had been, hence my request here) did in testing. I know it gets done when an EC030 is (hopefully) detected correctly by Thor's 68030.library, but it's a risk for a partially-functional MMU.

A lightweight tool resulting in data non-cache of that space when an MMU is not handy, and there is no need to install full MuLibs library package where a few K-sized tool runs and simply exits. The net result is that the lower 16M skips the CIIN bug and overall data cache issue. I see another possible use case for an 68EC030 on the A3630 when there is I/O cards in ZIII space, but the card address lines might not line up well with the TTX solution (it just came to mind).

Yes, this makes any 16/32-bit AutoConfig RAM in Z2 8M space not possible to data cache, but all of those G-Force cards, the TF's, the older Microbotics and CSA cards, and a few others with 68EC030 parts - which can map most/all of their memory >16MB anyway - they skip the possible issue this way. Z2-space Bridgecards, RTG, and (as always needed) the I/O expansion spaces and ChipRAM are needing data not to be cached, all will be satisfied.

The performance hits to Z2 AutoConfig space RAM I consider low in many cases. If something like 24-bit DMA is buffering I/O through it, caching is moot for it anyway. Pulling in 4x longwords to the data cache - for use of a few bytes here and there (in 2nd to last resort memory) - is excessive wait-state overhead for the retrieval, especially if it's from 16-bit width RAM.

As for Read/Modify/Write (TAS), it's illegal on the Amiga as per the Amiga Programmer's Guide. It can't be supported in shared RAM spaces like an RTG/Bridgecard, and ChipRAM - sometimes the only RAM (Agnus DMA owns it/operates on alternate 14MHz cycles/steals from the 68K cycles). I don't think the Z2 Buster supports it, and I won't hold my breath for SuperBuster handling it. The GVP DPRC with it's hidden on-card RAM<->DMA transfers (Like the Agnus behavior operates) would also technically break it.

Thinking about TAS and caching, it would have to test a physical RAM location anyway (assuming another busmaster can change the physical memory location and this CPU needs to act on it in an atomic cycle), so I doubt it would rely on a cached value that could be stale. Section 7-30 in https://www.nxp.com/docs/en/referenc...68030UM-P1.pdf p177-~195 covers a 32-bit port. I think it's impossible to obtain the atomic moment with a converted 16-bit or 8-bit port even if the RAM/bus might support it. In any case, it's still an illegal use instruction in the Amiga.

[Thomas Richter]

If you are certain that you do have an 68EC030, you can also put the line "MMU off" into ENVARC:MMU-Configuration, and then the MMU will be considered absent, so there are solutions to the problem, just not pretty ones. That is always possible. Of course, it is also risky because everything is left to the user to setup the system correctly.