PAK/3-020

[Lukas Frank]

Der 1.17 ist irgendwie Fehlerhaft. Hatte das früher auch schon bemerkt und immer den 1.14 benutzt. Michael Schwingen hat den Treiber programmiert, oder? Den müsste man mal fragen ...

[tuxie]

nur mal eine Dumme frage, was hast du auf deiner Pak für einen GAL satz drauf ?

[ditto]

Tuxie, ich habe echt keine Ahnung welcher GAL-Satz dort verbaut ist!   
Mit ein bischen Zeit werde ich die Dinger mal auslesen, wenn möglich.

Michael Schwingen könnte den Treiber sicherlich an die PAK angleichen, aber ich fürchte, der Bedarf ist nicht sonderlich groß und der 1.14er funktioniert. Was sollte der 1.17er Treiber besser machen?

[Lukas Frank]

Ich meine damals mal mit einer PAK68/2 machte die Magnum ST nur Probleme. Weiss aber nicht mehr genau, ist schon so lange her ...

[1ST1]

Es gibt für die PAK/3 TOS 3.06. Dieses braucht meines Wissens nach kein Start-TOS auf dem Board.

Doch auch das TOS 3.06 auf der PAK braucht das Onboard-TOS. Denn der 680x0 springt bei Reset immer an Adresse 00000000h, TOS liegt aber am obeneren Ende der 16 MB Adressraum (physischer Adressraum des 68000ers, und das wurde auch beim TT und Falcon so beibehalten). Im TOS-ROM befindet sich an der niedrigsten Adresse ein Sprungbefehl, der ins TOS hüpft. Meines Wissens ist die Sprungadresse in allen TOS-Versionen gleich. Die MMU oder Glue (weiß nicht mehr genau) sorgt nun dafür dass diese paar Bytes des ROMs mit dem Sprungebfehl an Adresse 00000000h des Adressraums eingeblendet werden. Da kommt auch TOS 3.06 nicht drumherum. Auf vielem TOS-Erweiterungen mag solch eine Logik wie in der MMU auch drauf sein, die PAK hat das aber nicht. Deswegen braucht die PAK das Onboard-ROM (Oder eins auf einem Zwischensockel, was auch den Remapping-Trick beherrscht)

[ditto]

MIST!   
Aber schönen Dank für die Erläuterung.

[Arthur]

Kann mir jemand erklären wieso sich die TOS-Version auf dem Mainboard und auf der Pak nicht in die Quere kommen, welcher Mechanismus steckt dahinter?

[mfro]

Beim Systemstart liest die CPU erst von Adresse 0 den initialen Stackpointer (SP) und anschliessend von Addresse 4 den initialen Program-Counter (PC)
Es gibt bei vielen (Selbstbau-) m68k-Systemen relativ simple Schaltungen, die bei einem Reset einen Zähler starten, der Buszyklen mitzählt und einfach zur richtigen Zeit den Bus mit den richtigen Werten füttert. Es reicht ja, beim jeweils zweiten Buszyklus einfach die ROM-Startadresse auf den Bus zu legen (den SP kann man auch später setzen).
Anschliessend kann sich die Schaltung wieder schlafen legen und auf den nächsten Reset warten.

Es ist also nicht unbedingt notwendig, tatsächlich ROM einzublenden.

[1ST1]

Kann mir jemand erklären wieso sich die TOS-Version auf dem Mainboard und auf der Pak nicht in die Quere kommen, welcher Mechanismus steckt dahinter?

Die PAK hat eine Adressdekodierung für das PAK-TOS drauf. Wenn das PAK-TOS angesprochen wird, werden die entsprechenden Adressen des 68020/30 von der PAK nicht auf den 68000er-Bus durchgeschaltet.

[Arthur]

mfro, danke für deine Antwort, doch wir reden, glaube ich, aneinander vorbei. Ich versuche mal zu erklären was ich nicht verstehe.

Angenommen auf dem Mainboard ist ein TOS 1.04 und auf der Pack irgendein gepatchtes TOS 1.04 das den selben Adressbereich einnimmt. Die Eproms sind doch alle mit dem Daten-, Adress-BUS, ROM1-x etc. verbunden. Wieso gibt das keinen Daten-Kuddelmuddel? Wie werden die ROMs selektiert oder weshalb wird nicht von beiden TOS-Versionen gleichzeitig gelesen?

[Arthur]

Kann mir jemand erklären wieso sich die TOS-Version auf dem Mainboard und auf der Pak nicht in die Quere kommen, welcher Mechanismus steckt dahinter?

Die PAK hat eine Adressdekodierung für das PAK-TOS drauf. Wenn das PAK-TOS angesprochen wird, werden die entsprechenden Adressen des 68020/30 von der PAK nicht auf den 68000er-Bus durchgeschaltet.

Also liegen die TOSse in jeweils separaten Bereichen und an das TOS auf der PAK kommt nur die CPU. Ok das klingt einleuchtend. Danke 1ST1. 

[1ST1]

Nein, sie liegen schon an der selben physischen Adresse, aber in der PAK ist quasi ein Schalter drin, der die Adressignale auf das PAK-TOS umleitet.

[ditto]

PAKman erklärte es in einer PM folgendermaßen:

Auf dem Mainboard muss ein TOS installiert sein!
Beim Bootvorgang liest der 680xx zwei Langworte (zusammen 8 Bytes) ab Adresse 0 (das werden dann der Stackpointer und der Program Counter).
Die Logik auf dem Mainboard sorgt dafür, dass dort die ersten 8 Bytes des ROMs eingeblendet werden.. allerdings die des ROMs auf dem Mainboard!
Fehlen diese ROMs, dann liest die CPU nur Schrott, und weiss dann nicht mehr weiter..

[Arthur]

Nein, sie liegen schon an der selben physischen Adresse, aber in der PAK ist quasi ein Schalter drin, der die Adressignale auf das PAK-TOS umleitet.

Schon klar sonst müßte es neu reloziert werden damit es läuft. Ich meinte eher elektrisch- oder besser  adresssapariert... was ein Wort. 

[Arthur]

PAKman erklärte es in einer PM folgendermaßen:

Auf dem Mainboard muss ein TOS installiert sein!
Beim Bootvorgang liest der 680xx zwei Langworte (zusammen 8 Bytes) ab Adresse 0 (das werden dann der Stackpointer und der Program Counter).
Die Logik auf dem Mainboard sorgt dafür, dass dort die ersten 8 Bytes des ROMs eingeblendet werden.. allerdings die des ROMs auf dem Mainboard!
Fehlen diese ROMs, dann liest die CPU nur Schrott, und weiss dann nicht mehr weiter..

Ist natürlich ärgerlich die Gurken, nur wegen einiger Bytes mit Strom durch zu futtern, wo das Netzteil ja eh nicht das stärkste ist.

[1ST1]

PAKman erklärte es in einer PM folgendermaßen:

Auf dem Mainboard muss ein TOS installiert sein!
Beim Bootvorgang liest der 680xx zwei Langworte (zusammen 8 Bytes) ab Adresse 0 (das werden dann der Stackpointer und der Program Counter).
Die Logik auf dem Mainboard sorgt dafür, dass dort die ersten 8 Bytes des ROMs eingeblendet werden.. allerdings die des ROMs auf dem Mainboard!
Fehlen diese ROMs, dann liest die CPU nur Schrott, und weiss dann nicht mehr weiter..

Nichts anderes habe ich oben geschrieben.

[ditto]

Und so war es offenbar auch goldrichtig! 

[1ST1]

Hab nochmal im Schaltplan nachgesehen, das Remapping der ersten Bytes des ROMs an die Adresse 0 wird von der GLUE gemacht, nicht von der MMU. Da findet eine Adressdecodierung auf Adresse 00000xxxh statt (also die 5 höchstwertigen Nibbles der Adresse sind 0, das ist ganz einfach mit einem NAND-Gatter mit entsprechend vielen Eingängen zu prüfen, oder man nimmt einen 32-Bit-Volladdierer und lässt den das Complement (also eine Subtraktion) von 09h addieren und bei Ergebnis=Negativ hat man das auch), wo dann kein RAM, sondern das TOS-ROM selektiert wird. Streng genommen haben unsere Rechner daher garnicht 512 kB, 1, 2, 2,5, 4, ... MB RAM, sondern immer 8 Bytes weniger... Betrug! 

Aber Apple und Commodore und alle anderen Hersteller von 68K-Systemen dürften den selben Beschiss abgezogen haben.

[Arthur]

Nirgends wird so viel beschiPieeeeep wie beim Speicher.

[mfro]

Betrug! 

Nix Betrug, das RAM ist ja drin. Du kommst nur nicht dran.