exxos's Atari, Amiga & retro forum

DominoTree wrote: 28 Oct 2020 22:39 I've noticed that having the cache enabled in TOS 2.06 or EmuTOS seems to affect disk-related things, both floppy and hard disk - TOS 2.06 *way* more often. The floppy (HxC emulator) will give me all sorts of errors, and hard disks (UltraSatan with HDDRIVER) will show as being empty most of the time, and reads will fail if I do manage to get a directory listing and try to open a file.

I hadn't actually noticed the floppy issue in the newer EmuTOS until you mentioned it, and I'm definitely seeing it now too, but disabling the cache seems to make it work pretty reliably - otherwise I just get messages about the drive not responding.

TOS2.06 doesn't properly account for the 68030 cache so you'll have to disable cache in the TOS options else anything DMA'ed will be all kinds of broken :)

I was thinking TOS 2.06 works fine with the 030 CPU Cache and the L2 Cache on a PAK68/3-030. So there must the TF Firmware wrong?

frank.lukas wrote: 29 Oct 2020 07:50 I was thinking TOS 2.06 works fine with the 030 CPU Cache and the L2 Cache on a PAK68/3-030. So there must the TF Firmware wrong?

Are you sure you're not thinking of TOS 3.06?

You've got this type of stuff going on in the TOS 2.06/3.06 sourcecode.. Cache flushes after Floppy/ACSI/Blitter operations are only compiled in on TOS3.06.
(P68030 is defined when building TOS3.06 but it is not defined when building TOS2.06 - why this wasn't made into a runtime check is beyond me.. after all it deals with the different stackframe sizes at runtime)
Without flushing the data cache after some other device has directly written to memory, the CPU will sometimes read old and invalid data from its cache since it has no way of knowing the memory was modified.

Can the ST run TOS 3.06 with a TF536 installed?

TOS 3.06 requires a 512MB ROM, unlike TOS 2.06, and there are no 512MB ROM adapters at the moment.

I'm trying to get my board to the point I can test to see if I've managed to get that working but I'll have to hack together a PLCC44 to DIP40 27C4096 EPROM converter before I can write a ROM.

Oh, and the video sub-system is very different too.

frank.lukas wrote: 29 Oct 2020 07:50 I was thinking TOS 2.06 works fine with the 030 CPU Cache and the L2 Cache on a PAK68/3-030. So there must the TF Firmware wrong?

I boot TOS 2.06 from Floppy with my PAK68/3-030 and it works fine ...

Also with CPU Cache enable all is fine.

You can try TOS 3.06 with the PAK patches. Use the Markus Heiden TOSpatch package.

306_REL.FIL -> It works only with a german TOS 3.06 rename to TT_TOS.IMG. Change only the two things ...


;*******************************************************************************
;* MRF:
;* Ausgabeformat des Patchprogramms:
;* >[Anzahl der TOS-Files] [Obere Ramgrenze des Rechners - .LENGTH]

;>1 01F80000 ; 16MB-TT-RAM / 1 File ;Im TT-Ram l„uft das TOS schneller!
;>1 01780000 ; 8MB-TT-RAM / 1 File ;Dies ersetzt (fast) ROMRAM
;>1 01380000 ; 4MB-TT-RAM / 1 File ;oder „hnliche TOS-Beschleuniger!
>1 00380000 ; 4MB-ST-RAM / 1 File ;(FastVar nicht implementiert)
;>1 00280000 ; 3MB-ST-RAM / 1 File
;>1 00200000 ; 2,5MB-ST-RAM / 1 File ;Mit weniger als 2MB Speicher macht es
;>1 00180000 ; 2MB-ST-RAM / 1 File ;kaum Sinn TOS 3.06 im Ram zu halten,
;>1 00080000 ; 1MB-ST-RAM / 1 File ;aužer vielleicht zum Testen der Patches.

;>1 ; 1 nicht relozierte Datei (TOS.IMG) erzeugen, z.B. fr ROMRAM.
;>2 ; 2 nicht relozierte Dateien (TOS.LO/HI) erzeugen.
;>4 ; 4 nicht relozierte Dateien (TOS.EE/EO/OE/OO) erzeugen.



;*******************************************************************************
;* SE: (eingebunden von MH)
;* PAK III-Patches Version 2 (fr 68020- und 68030-Version). Es gibt auch noch
;* ein modifiziertes Atari-Fuji mit PAK/3-Schriftzug von SE (s.u.).
;* [FRG/USA]
;*
;* >>> Einige andere Patches werden deaktiviert (s.u.).

.PAK = 1 ;1: PAK-Patches einbinden, 0: PAK-Patches nicht einbinden


In the packages there is a loadtos.prg for the auto folder ...

The firmware only marks fast ram as cacheable (CIIN). But the 030 is known to cache writes to other addresses. Its not avoidable. Unless CDIS is on.

I.e. there isnt really anything special that firmwares do for this. The only options for a cache control is CIIN and CDIS. CIIN should only be disasserted for fast ram. So i simply dont understand how an unpatched ROM will behave differently.

frank.lukas wrote: 29 Oct 2020 07:50 I was thinking TOS 2.06 works fine with the 030 CPU Cache and the L2 Cache on a PAK68/3-030. So there must the TF Firmware wrong?

I believe this is correct as well.

Culd it be that it's not telling the 030 to not cache ST-RAM address ranges?

stephen_usher wrote: 29 Oct 2020 15:21 Culd it be that it's not telling the 030 to not cache ST-RAM address ranges?

Thats done by CIIN for reads and its done in the MMU for writes. Its not possible to not cache writes otherwise.

EDIT: Basically its a software problem for writes. Reads are not cached except for fast ram which is safe.