Mega STE mit PAK68/3 ...

[Lukas Frank]

EmuTOS 1.1.1 PAK Epromsatz auf der PAK68/3 auf dem MSTE ...

[Lukas Frank]

Manchmal mit Panic und ein anderes Mal läuft es. Ich kann keinen Grund finden weshalb ...

[Thorsten Otto]

Exception number 68 sieht seltsam aus. Wenn ich mich nicht verrechnet habe, müsste das Timer-D sein, der von EmuTOS für kurze Delays verwendet wird.

[czietz]

Du hast Dich nicht verrechnet.

Timer D dient im Normalbetrieb zur Generierung der RS232-Bitrate. Dabei ist dessen Interrupt aber deaktiviert, sodass die Exception 68 nicht auftreten kann. Die einzige Stelle, an der nach meinem Dafürhalten der Timer-D-Interrupt aktiv ist, ist die schon angesprochene einmalige Kalibrierung der Delay-Loop beim Booten. Währenddessen zeigt der Exception-Vektor natürlich woanders hin. Ich frage mich, ob Frank hier eine Race-Condition innerhalb des MFP beobachtet. Also, ob der MFP einen Interrupt erst an die CPU meldet, nachdem sein Timer schon angehalten ist und der Exception-Vektor wieder auf die Fehlermeldung zeigt.

Dazu muss ich ein paar Experimente machen ... wenn ich mal Zeit habe.

[Lukas Frank]

Bin verwirrt da alles am Anfang garnicht lief mit EmuTOS 1.1.1, beim zweiten Versuch mit Panic Meldungen und dann ging es. Mir ist nicht klar was der Grund war.

[Thorsten Otto]

Kann man nur Vermutungen anstellen. Offensichtlich wird da manchmal der Interrupt zu spät ausgelöst, wenn er eigentlich schon wieder deaktiviert wurde. Vlt. wärme-abhängig?

[czietz]

Es mag eine Latenz innerhalb des MFP geben, ja. Das Datenblatt schweigt sich dazu aus. Ich habe die einzige Person kontaktiert, von der ich mir vorstellen kann, dass sie so ein Detail wissen könnte. Sonst muss ich selbst Experimente machen ... wenn ich mal Zeit habe.

[mfro]

Es mag eine Latenz innerhalb des MFP geben, ja.

Ich habe mir den Code in cal_loop (delayasm.S, Z61ff) angeschaut und da ist mir ein Fehler ins Auge gestochen (der aber wahrscheinlich nicht Franks Problem ist): da werden im Timer D Control Register 4 Bits gelöscht, um den Timer zu stoppen, das Register hat aber nur 3 Bits (es wird also auch das LSB des Timer C Control Registers gelöscht).

[czietz]

da werden im Timer D Control Register 4 Bits gelöscht, um den Timer zu stoppen, das Register hat aber nur 3 Bits (es wird also auch das LSB des Timer C Control Registers gelöscht).

Hm, nein, wird es nicht:

[mfro]

Mein Fehler - Profibuch falsch interpretiert. Danke.

[czietz]

Ferndebugging ist immer schwer (denn der Fehler trat ja nur(?) bei Frank auf), aber hoffnungsvoll sollte diese "Exception 68" ab diesem Snapshot gelöst sein: https://sourceforge.net/projects/emutos/files/snapshots/20220521-145556-a12f214f/

[Lukas Frank]

Vielen Dank

[Lukas Frank]

@czietz ... funktioniert. Der Fehler war am Anfang da mit der Version 1.1.1 und dann lief es immer ohne Probleme. Bei einem Tastatur Reset kam der Fehler nochmal vor aber nicht immer. Dank der vier AT29C010A ging der Wechsel schnell ...

[Lukas Frank]

Funktioniert alles sehr gut mit der PAK im Atari MegaSTE bis auf Probleme mit der Floppy. Läuft zur Zeit mit der EmuTOS 512kB Version für die PAK.

Muss mal nochmal mit dem TOS 3.06 probieren was die Floppy betrifft ...

;*******************************************************************************
;* 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 = 0            ;1: PAK-Patches einbinden, 0: PAK-Patches nicht einbinden

.StaticRAM = 0      ;1: TOS fr Static-RAMs, 0: TOS fr ROMs/EPROMs
.Grafik_Bombs = 0   ;1: Bomben auf Grafikkarten/Grafikerweiterungen ausgeben,
                    ;   funktioniert bei allen Systemen mit Bitplanes.
                    ;0: Nicht-Grafikkartenbesitzer oder Grafikkartenbesitzer
                    ;   mit angeschlossenem ST-Screen sollten diesen Patch
                    ;   herauszunehmen, da die Bomben dort sichtbar sind.
.BootJMP = 1        ;1: PAK-Trick, um mit FC-TOS auf Mainboard in die
                    ;   PAK-ROMs hochzukommen, einbinden. Falls Probleme
                    ;   mit diesem Patch auftauchen, sollte man den RSC-
                    ;   Patch aktivieren.
                    ;0: PAK-Trick nicht einbinden.
.Blitter = 0        ;1: Blitter erkennen, 0: Blitter nicht benutzen (Default)
.HasTTMfp = 0       ;1: Dieser ST hat einen nachgersteten TT-Mfp,
                    ;0: Kein TT-Mfp vorhanden.
.MSTE = 0           ;1: MSTE/TT-HD-Umschaltung nicht eleminieren (fr MSTEs).
                    ;0: MSTE/TT-HD-Umschaltung fr normale STs wegpatchen.
.Alt_Sync = 1       ;1: Alternative Bildschirmsynchronisierung benutzen
                    ;   (fr NEWVIDEO-Patch erforderlich!).
                    ;0: Normale Synchronisierung benutzen.

_IF .PAK
 +PAK3_TP.FIL
_ENDIF

;*******************************************************************************

... vielleicht bringt es was den MSTE patch zu setzen?

[Lukas Frank]

Der Plan ist eine LightningVME zu ergänzen zum Datenaustausch über USB Sticks da die Floppy ja nicht läuft. Als Gehäuse ein original MSTE Gehäuse mit original Netzteil. Der PAK Turm baut so hoch das an der Stelle ein Ausschnitt ins Gehäuse rein muss mit Abdeckung. Als Abdeckung kann ich was bauen mit Hilfe von Kunststoffplatten aus dem Modellbau. Ataris in PC Tower Gehäusen habe ich schon zwei.

[neualtuser]

Moin
@Lukas Frank
Hast du ein Gehäuse?
Ansonsten kommt meins mit in den Karton.

[Lukas Frank]

Nein noch nicht.

[tuxie]

Mach doch einen Ring , eventuell mit 3D Drucker der zwischen Ober und Unterschale sitzt, so musst du kein Gehäuse kaputt machen.

[Lukas Frank]

Gute Idee aber so einen großen Drucker oder zusammen kleben oder machen lassen bei einer Firma?

[jeloneal]

Wieviel Abstand musst du denn gewinnen?