Hardware > Hardware (High-End)

EmuTOS auf PAK68/2 ...

<< < (9/11) > >>

SolderGirl:
Also wäre die Lösung eigentlich auf dem Mainboard spezielle ROMs zu platzieren, die nichts anderes als einen absoluten Sprung an den Anfang des EmuTOS enthalten?
Quasi als "Bootloader"?

Lukas Frank:
Ich kann das nicht ausprobieren aber selbst eine PAK68/3 läuft mit einem ungepatchten original TOS 2.06 meine ich ...

--- aus einem c´t Artikel ---
Atarisch
Die PAK/3-020 läuft unter TOS 2.06 problemlos, was im Prinzip auch für die 030er PAK gilt. Da TOS 2.06 jedoch nichts von der
Existenz einer MMU und eines CPU-internen Datencache weiß, kann es in bestimmten Situationen Probleme geben, so zum
Beispiel bei einigen Plattentreibern mit eingeschaltetem Datencache. Im TT fällt das nicht weiter auf, weil dort die MMU vom
TOS 3.06 entsprechend programmiert wird. Daß es aber auch anders geht, zeigt AHDI, der auch auf einer PAK/3-030 unter
TOS 2.06 ohne MMU-Unterstützung einwandfrei läuft.
Des weiteren gibt es noch einige Programme, etwa Treiber für virtuelles RAM, die die MMU verwenden, diese aber in genau
dem Zustand vorfinden möchten, wie sie vom TOS 3.06 im TT initialisiert wird. Bei TOS 2.06 kann diese MMU-Initialisierung
durch ein kleines Programm im Auto-Ordner nachgeholt werden, womit dann auch solche Programme laufen.
Leider handelt man sich damit ein weiteres (kleines) Problem ein: Ein über die Tastatur ausgelöster Kaltstart führt zum
Aufhängen des Rechners, denn TOS 2.06 löscht dabei den gesamten Speicher und mithin auch die MMU-Tabelle. Die CPU
trifft zwar in der Startup-Sequenz des TOS auf einen RESET-Befehl, womit die gesamte Hardware des Rechners (auch der L2-
Cache) zurückgesetzt wird. Der interne Status der CPU bleibt davon jedoch unberührt, die MMU und die beiden CPU-Cache
sind nach wie vor aktiv, was dann auch prompt in die Hose geht.

czietz:

--- Zitat von: Thorsten Otto am Di 14.04.2020, 19:04:37 ---Bleibt ausserdem die Frage, wenn das so einwandfrei funktioniert, warum sie es bei der PAK/3 nicht genauso gemacht haben?

--- Ende Zitat ---

Ich vermute, das hat mit der ROM-Größe zu tun.

PAK mit 512k-ROMs:
$FC0030 (binär ‭1111 1100 0000 0000 0011 0000‬)
=> umgemappt auf $E40030 (binär ‭1110 0100 0000 0000 0011 0000‬), dort muss der "magische" Sprung stehen.

PAK mit 256k-ROMs:
$FC0030 => auch umgemappt auf $E40030, aber da es die Adressleitung A18 für $4xxxx bei diesen ROMs einfach nicht gibt => weiter umgemappt auf $E00030. Funktioniert dann natürlich nur wenn man echte 256k-EPROMs nimmt, nicht wenn man 512k-EPROMs nimmt und davon nur die untere Hälfte programmiert.

@Lukas Frank : Da Du ja auf der Liste mitliest, weißt Du, dass Roger einen Vorschlag für einen Test gemacht hat. Willst Du entsprechende ROMs testen?

czietz:

--- Zitat von: SolderGirl am Di 14.04.2020, 19:08:08 ---Also wäre die Lösung eigentlich auf dem Mainboard spezielle ROMs zu platzieren, die nichts anderes als einen absoluten Sprung an den Anfang des EmuTOS enthalten?
Quasi als "Bootloader"?

--- Ende Zitat ---

Das entspricht dem Vorschlag, den auch die c't abgedruckt hatte ("durch endgültiges Ändern des Reset-Vektors in den ROMS der Hauptplatine auf $E0 0000 (an Adresse $4)"), bevor sie auf den Trick mit TOS 2.06 gekommen sind.

KarlMüller:

--- Zitat von: czietz am Di 14.04.2020, 17:43:26 ---Verhindern die GALs auf der PAK auch, dass die ROMs auf der Hauptplatine bei der Adresse 0xFC0000 usw. angesprochen werden? Sonst würden sich in diesem Adressbereich ja zwei ROMs melden.

--- Ende Zitat ---
Wird mit Jumper J2 geregelt:

--- Zitat von: Tausch mit Turbo c't 10/1991 --- - J2 offen: Die System-ROMs sind auf der Hauptplatine, auf die im verkürzten Buszyklus (fünf Takte) zugegriffen wird.

- J2 gesteckt: Es wird im GAL U6 bestimmten Speicherbereich kein cycle_00 und ROMSel erzeugt. Der 68020 erwartet einen 32 Bit breiten ROM/RAM-Bereich auf der PAK, auf den er ohne Waitstate zugreift.

--- Ende Zitat ---

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete