The original TF536 project did not cache ST-RAM. This was done deliberately to make the CPU basically run at the same speed as a 68000. But also it would malfunction horribly with DMA access because the CPU had no way to know when to invalidate the ST-ram caches.
In light of the cache issues, I patched TOS206 to include the TOS306 cache control routines which dealt with the 030 cache correctly. It basically fixed the DMA and other weird cache related problems.
The current release version of the ST536 firmware does not cache ST-RAM. It is still unknown about compatibility issues in this respect. However, the experimental firmware also caches ST-RAM.
- Capture.PNG (30.56 KiB) Viewed 13645 times
Last year I used frontbench to test the caches. IIRC, there was absolutely no difference between ST cache only or TTram cache only. The scores ended up basically the same.
The problem being when we cache STram, we speed up the ST-RAM stuff a bit, but then starve TTram of it cache. So if running frontbench in TTram, you lose the cache hits to TTram. The same in reverse, that if you run TTram cache only, you sacrifice the STram cache speeds. The whole point of the experiment was to see if enabling ST-ram would work better than using the cache with TTram only. But the results were surprising and disappointing.
Now the experimental firmware enables ST & TT ram cache. Though to my knowledge nobody has done any tests between the 2 methods. I am basically assuming that if you are running in STram *or* TTram then the CPU cache would favor the relevant RAM more. However when enabling ST & TTram cache, you are basically trying to cache more RAM, so it increases the likelihood of cache misses, which can then overall make the system run slower.
So there are basically three methods of using the cache.
ST-RAM cache only - No firmware.
TT-RAM cache only - Release firmware.
ST & TT RAM cache - Experimental firmware.
In any scenario you need my patched TOS206 to work properly with the 030 CPU (or EMUTOS) .
Later firmware used what I dubbed "slow ROM". Originally I had used the normal 55ns ROMs and run them at maximum speed for ROM access. Though people requested the ability to use the 100ns EPROMS. So I deliberately slowed down the ROM access to allow that and abandon the "Fast ROM" code brach. Fast-ROM was not really needed because people should be using MAPROM which copies TOS to TTram which runs faster than the actual ROM anyway.
ACSI wire for IDE AUTOBOOT - This was also deemed obsolete in the latest versions of the firmware. It went on pin 10 of the ACSI port to allow IDE autobooting (INTR). Connecting this wire will likely cause malfunctions with the latest firmware as I believe I used the same pin as a debug output at some point and never removed the code. So under no circumstances connect this wire with the latest firmware! The interrupt is now emulated within the firmware.
Also I should stress (again) that the blitter cannot be used with TTram. This is why you should use NVDI (or remove the blitter). This does not mean the ST536 is not compatible with the blitter. You can still run games which use the blitter providing you are only running them from STram.
I also need to stress that there are many versions of MAPROM floating about and you should always use the ones in the official release files. I'm not able to compile or edit MAPROM myself in the later builds. Indeed later versions (if any) than in my release files are assumed to be experimental and untested. I'm assuming nobody is actively maintaining MAPROM anymore. I'm not aware of any issues with the released build anyway.
I also need to point out that my build of TOS206 (english) was thoroughly tested by myself and it was the other language versions which I have not tested. Though I did make some changes from the english only version, but I think this was just adding some debug type messes on TOS startup just to indicate what it was initialising during boot up. I think I may have also fixed some weird RAM problems as well.
