Oh - besten Dank. Das Verhalten meines Systems ist schon recht nah an dem Zitat aus der ct.
Werd mir gleich mal den Artikel anschauen.
Ich glaube nicht, dass dir das weiterhilft. TOS2.06 gilt eigentlich (im Gegensatz zu den älteren Versionen als weitgehend "warteschleifenbereinigt" - also von der CPU-Geschwindigkeit unabhängig gemacht). Dafür spricht auch, dass anscheinend (?) alles funktioniert, wenn Du die Caches ausschaltest (wie machst Du das eigentlich - TOS2.06 kann das m.E. bei einer '030 CPU nicht?).
Dein Problem ist m.E. die nicht initialisierte MMU - bei eingeschalteten Caches wird dann der gesamte Adressraum gecached. Zugriffe auf Hardware- (also z.B. die ACIA-) Register lesen so lange "alte" Werte aus dem Cache (anstatt direkt von der Hardware), bis die aus Platzmangel rausfliegen und der Cache neu befüllt wird. Anscheinend liegen die "entscheidenden" Zugriffe bei Pure C eben so dicht beieinander, dass das nicht passiert (verwunderlich, dass Du das anscheinend nur dort bemerkst).
Du brauchst (mindestens) eine rudimentäre MMU-Initialisierung, die der CPU sagt, wo im Adressraum Hardware-Register liegen (was also nicht gecached werden darf).
Zusätzlich ein Remapping, das die Hardware ab $FFF00000 auch im 24-bittigen ($F00000) Adressraum zugänglich macht (oder andersrum, je nachdem wo bei dir die Hardware sitzt).
Der Code dafür findet sich im EmuTOS - sollte nicht allzu schwierig sein, daraus ein Auto-Ordner Programm zusammenzuschustern.
Was ich nicht verstehe ist, warum das gepatchte PAK-TOS dasselbe Verhalten zeigt (aber ansonsten anscheinend läuft?). Das sollte eigentlich genau das machen?