exxos's Atari, Amiga & retro forum

I certainly wouldn´t rule out the possibility of bugs in maprom. I’ll give this a go when my card arrives :)

Does it help disabling the cache in TOS2.06 ?

TOS2.06 is mostly compatible with a 030 and TT-RAM etc, but as far as I can tell it never flushes the cache like TOS 3.06 does in its floppy code (and in some other non-floppy related code)
At least according to the TOS206/306 sourcecode I have.
I notice I have cache disabled in the TOS2.06 options on my machine running the 534.

Edit: if cache is the issue I believe the issue is probably not caused by TOS being in RAM but rather because 206 doesn't fully support TT-RAM and a CPU with data cache.

Floppy access goes something like this when the destination is outside ST-RAM:
DMA -> FRB (in STRAM) -> cpu copy to actual destination (outside STRAM)
306 correctly flushes the cache after floppy DMA operations but 206 doesn't seem to do so.

Perhaps maprom should patch the 2.06 floppy code to introduce the cache flushes at the same places 3.06 does it.. could be a neat project for someone :)
Or possibly easier, set up the MMU to trigger an exception when 206 reads/writes the FRB? It could then flush the cache before letting it proceed with the FRB<->Fastram copy although I am not certain if this would be enough.

Or it's just bugs in maprom. I'll double check on my machine, and could try if it makes any difference only installing the fastram and leaving TOS in ROM etc.

agranlund wrote: 13 Jul 2020 08:35 Does it help disabling the cache in TOS2.06 ?

I tried it just .. nope.. Doesn't seem to change anything.

Looks like a bug in maprom for sure. I was able to reproduce the problem on my TF534.

maprom does a few things on 2.06:
1) Scans for and registers available tt-ram with tos
2) Allocates FRB in ST-RAM and registers it with tos
3) Sets up a default MMU table the same way as EmuTOS / Atari TOS3.06
4) Maps ROM area to fastram
5) Maps a small part of low ram to fastram (TOS internal variables)

It appears to work fine with everything except when (4) is enabled. With the rom mapped, I too get floppy issues with my Gotek. Not identical as shown earlier in the thread but read errors when loading some programs.
Sysinfo and Yartt loaded fine from my utils disk which is probably why I never noticed the problem (I don't really use the Gotek for anything anymore since getting the IDE interface, and Parcp-USB to transfer files across)

I'll take a look at this after vacation though :)

I did try some of my older programs and it looks like the floppy works fine with 2.06 patched in fastram instead of using the MMU:
https://www.exxosforum.co.uk/forum/viewt ... tos#p26716
Performance is probably quite a bit weaker due to all Tos internal variables still living in ST-RAM.

Finding faults is still progress , well done.

agranlund wrote: 13 Jul 2020 20:51 I did try some of my older programs and it looks like the floppy works fine with 2.06 patched in fastram instead of using the MMU:
https://www.exxosforum.co.uk/forum/viewt ... tos#p26716
Performance is probably quite a bit weaker due to all Tos internal variables still living in ST-RAM.

I tried that one just, but not sure if its actually loaded the TOS into RAM or not. But YAART reports no TTram installed anyway. But at least it loaded in that time.

exxos wrote: 13 Jul 2020 21:14

agranlund wrote: 13 Jul 2020 20:51 I did try some of my older programs and it looks like the floppy works fine with 2.06 patched in fastram instead of using the MMU:
https://www.exxosforum.co.uk/forum/viewt ... tos#p26716
Performance is probably quite a bit weaker due to all Tos internal variables still living in ST-RAM.

I tried that one just, but not sure if its actually loaded the TOS into RAM or not. But YAART reports no TTram installed anyway. But at least it loaded in that time.

I think this one just puts TOS at the top of TT-RAM and adjusts the top pointer down accordingly..
Which could be a problem with TF536 and the current firmware - the normal way of detecting ram finds 4MB too much so the top pointer is no good, actually wrapping back into the ST-RAM range.

If you're booting with EmuTOS in ROM then you are probably out of luck
(ttramtos.prg uses the tt-ram top pointer from the bios if available - and it is available, and wrong, if booting with emutos)

It might work if you are booting from Atari TOS ROMs.
(I can't remember how I made that fallback memory detect code. If it was just like EmuTOS the it will not work, but if it detects by writing then there is a chance it could correctly detect 64MB)


I'd try booting with TOS2.06 in ROM, and also:

* Your TOS 2.06 image file must be located in the root of the boot drive, and it must be renamed to TTRAMTOS.IMG. (also needs to be either US, UK, German or Swedish version)

* ttramtos.prg must be in the auto folder of your boot drive.
(Or well... ok, maybe it's possible to manually run it from the desktop but in that case you must run it twice.. It should soft-reset your machine first time you run it, but a second run is needed to install the tt-ram, frb, etc to the TOS that it just had soft-reset into)

* To be safe, try powering down your machine completely and let it sit for a few seconds in case some system variables are still alive since last time your machine was powered on - it could cause it to not run properly thinking it has already been installed..


You'll see if it works if the machine soft-resets after it executed ttramtos.prg from the auto folder the first time. You'll see two boots basically.

Sysinfo is showing the correct amount of tt-ram here and Gembench is able to run from it, but that is on the TF534 though.


I could add some hacks to it to work around the memory detect issue but I'm betting it'll be fixed in a firmware update at some point anyway so I rather not :)
This old thing probably needs all kinds of love if it were to be brought to "consumer" level.. it was quickly hacked together and I only used it for a short while myself.

@agranlund Aside from "ROM in RAM". Have you any idea why its not installing alt-ram ? Thats the main thing I want to get running so I can get some CPU's at 50MHZ while doing TT-RAM tests..

Got sidetracked a little bit..

I have placed a 50pF cap on DTACK to get me up and running. I have also bodge wire the scope on the CPU clock pin... Then did a quick and dirty integer division routine based on GB6's assembly routines... Typically took about three seconds to do a single pass, so I have increased the loop time so each loop now takes 60 seconds or thereabouts..This is to keep the CPU in 50MHz mode as much as possible.

@exxos what was the board doing that it needed the cap?

PhilC wrote: 14 Jul 2020 18:35 @exxos what was the board doing that it needed the cap?

It would never boot, it was just constantly resetting..