130XE Remake - ein sehr merkwürdiges Problem

[Erhard]

Hallo,

ich habe auf einem 130XE Remake versucht, das Spiel Bunny Hop aus dem ASC 2022 (MAG150C.ATR) zu starten.

Es erscheint folgende Meldung:

"This program requires 130XE!"

Das passiert bei allen Modi der RAMDISK.

Ich habe das dann auch mit meinem zweiten 130XE Remake versucht -> gleicher Fehler.

Dann habe ich das auf meinem 130XE mit Newell 1MB versucht -> Spiel läuft.

Ich bin dann hergegangen und habe das Spiel nach dem RAMDISK-Test durchsucht. Der liegt in dem Segment $2000-$20AC, was ich mir dann für weitere Versuche extrahiert und allein lauffähig gemacht habe.

Die Versuche auf einem der 130XE Remakes haben bislang wie folgt ergeben:

Wenn ich den Rechner einschalte, ein DOS lade (in meinem Fall SpartaDOS 3.3b) und dann die Testroutine starte kommt der Fehler.

Eine Kontrolle mit dem Freezer ergibt, daß in Speicherstelle $4000 bei $D301=$E7 nicht der Prüfwert drin steht.

Wenn ich dann den Rechner neu starte (das ist ein Kaltstart ohne Aus- und wieder Einschalten) und den Test nochmal laufen lasse, dann klappt er jedes mal.

Neuer Test A: ich schalte den Rechner aus, lade Bug65 nach $2000, verlasse Bug65 wieder und starte dann den Test -> Fehler
Nächster Test: wie A, aber ich schreibe im Bug65 den Wert $FF in $D301 -> Fehler
Nächster Test: wie A, aber ich schreibe im Bug65 den Wert $E3 in $D301 und dann wieder $FF -> Fehler
Nächster Test: wie A, aber ich schreibe im Bug65 den Wert $E3 in $D301, dann irgendeinen Wert nach $4000, dann $D301 wieder auf $FF -> kein Fehler

Den letzten Vorgang wiederholt, den Test nicht gestartet aber das Spiel -> funktioniert.

Nun bin ich gespannt, wer hierzu was rausfindet.

Natürlich könnte ich einfach das Spiel patchen, aber es geht ja darum herauszufinden, warum sich die Ramdisk nach einem Kaltstart mit Ausschalten so seltsam verhält.

Ach ja, und natürlich ergeben Tests der Ramerweiterung mit SysCheck, XRAM021 und SIMTEST keine Fehler.

[Erhard]

Offenbar hat außer mir niemand ein 130XE Remake?

Falls doch bitte ich darum einmal zu schauen, ob das Verhalten auch auf diesem System auftritt.

[RhoSigma]

Poste doch mal den Test, dann kann das einer ausprobieren...

[Erhard]

.

Poste doch mal den Test, dann kann das einer ausprobieren...

steht doch eigentlich im ersten Beitrag: auf einem 130XE Remake nach dem Einschalten des Rechners Bunny Hop laden. Das ist auf der ABBUC Magazindisk 150C zu finden.

Beim ersten Startversuch sollte der Fehler kommen.

Wenn man dann einen Kaltstart durchführt ohne den Rechner aus- und wieder einzuschalten und dann das Spiel noch einmal lädt tritt der Fehler nicht auf.

[Olix]

Habe das mal auf meinem 130XE Remake Board nachgestellt:

Egal welche Speichereinstellung, ich erhalte auch immer: "This program requires 130XE!"

Es liegt also NICHT an Erhard
... sondern am Board Design.

[Erhard]

Es liegt also NICHT an Erhard

Das ist gut zu wissen.

Also sieht die Forschungsaufgabe derzeit wie folgt aus:

Warum funktioniert nach dem Einschalten des Rechners und egal wie lange er eingeschaltet ist der erste Zugriff auf $4000 in Bank $E7 nicht, auch wenn automatisiert zuvor in $4000 in Bank $E3 erfolgreich geschrieben wurde, jedoch doch, wenn zuvor in $4000 in Bank $E3 MANUELL geschrieben wurde.

Und es wäre zu prüfen, ob der Fehler bei einer anderen Zugriffsfolge auf die Banken bei einer anderen Bank (z.B. der zweite Zugriff) nicht funktioniert.

[mega-hz]

Hast Du evt. das/die GAL Listings?
Vielleicht ist da ja was faul...

[Erhard]

Hast Du evt. das/die GAL Listings?

Werde ich hier einstellen.
Ist aber glaube ich von TF_HH eine überarbeitete Version, das sollte eigentlich in Ordnung sein.

Muß auch irgendwie ein Timing-Problem sein, weil wenn man manuell die Werte schreibt klappt es ja uns sonst nur nach dem Einschalten eben nicht.

[Erhard]

So,

hier mal erst das Listing des Testprogramms.

Ich habe auch einmal die Folge umgekehrt, mit denen auf die RAM-Bänke zugegriffen wird.

Wenn statt E3-E7-EB-EF die Folge EF-EB-E7-E3 genommen wird, gibt es das Problem mit Bank EB.

Es sieht also so aus, als wäre es immer die zweite Bank, in die das Testbyte nicht geschrieben wird, wenn man das Programm nach dem Einschalten des Rechners ausführt.

Code: Alles auswählen

;
; DLIST EQUATES
;
ALMS     =   $40
AVB      =   $40
AJMP     =   $01
AEMPTY4  =   $30
AEMPTY8  =   $70
;
RTCLOK   =   $12
SDMCTL   =   $022F
SDLSTL   =   $0230
SDLSTH   =   $0231
COLDST   =   $0244
COLOR1   =   $02C5
COLOR2   =   $02C6
PORTB    =   $D301
;
; Code equates
;
L4000    =   $4000
;
; Start of code
;
         *=  $2000
;
START    LDA #$00
         STA SDMCTL
         LDA #$FF
         STA PORTB
         STA COLDST
         LDA RTCLOK+2
WAIT     CMP RTCLOK+2
         BEQ WAIT
         LDA #$E3
         STA PORTB
         STA L4000
         LDA #$E7
         STA PORTB
         STA L4000
         LDA #$EB
         STA PORTB
         STA L4000
         LDA #$EF
         STA PORTB
         STA L4000
         LDA #$E3
         STA PORTB
         CMP L4000
         BNE RAM_ERR
         LDA #$E7
         STA PORTB
         CMP L4000
         BNE RAM_ERR
         LDA #$EB
         STA PORTB
         CMP L4000
         BNE RAM_ERR
         LDA #$EF
         STA PORTB
         CMP L4000
         BNE RAM_ERR
         LDA #$FF
         STA PORTB
         LDA #$22
         STA SDMCTL
         RTS 
;
RAM_ERR  LDA # <DLIST
         STA SDLSTL
         LDA # >DLIST
         STA SDLSTH
         LDA #$00
         STA COLOR2
         LDA #$0C
         STA COLOR1
         LDA #$21
         STA SDMCTL
LOOP     JMP LOOP
;
DLIST    .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY8
         .BYTE AEMPTY4
         .BYTE ALMS+$02
         .WORD TEXT
         .BYTE AVB+AJMP
         .WORD DLIST
;
TEXT     .SBYTE "   This program requires 130XE!  "
;
         *=  $02E0
         .WORD START
;
         .END 

[Erhard]

Und das hier ist glaube ich der Inhalt des GALs:

Code: Alles auswählen

CHIP	TFHHSRAM	GAL22V10

USER_ID = TFHHSRAM

CLK   A14         A15  HALT       RW  PHI2  PB4  PB5  PB7  SW1    SW2        GND
PHI0  CASINH_OUT  MAP  CASINH_IN  OE  CE    WE   A18  A16  RHALT  NPHI2_OUT  VCC

NPHI2_OUT = /PHI2;

RHALT := HALT;

A16 = PB5 */SW1;

A18 = PB7 */SW2;

/WE = A14 * /A15 * /RW * PHI2 * /PB4 * CASINH_IN * PHI0 */SW1
    + A14 * /A15 * /RW * PHI2 * /PB4 * CASINH_IN * PHI0 *  RHALT */SW2
    + A14 * /A15 * /RW * PHI2 * /PB5 * CASINH_IN * PHI0 * /RHALT */SW2 * SW1;

/CE = A14 * /A15 * PHI0 * /RW * /PB4 * CASINH_IN */SW1
    + A14 * /A15 * PHI2 *  RW * /PB4 * CASINH_IN */SW1

    + A14 * /A15 * PHI0 * /RW * /PB4 * CASINH_IN *  RHALT */SW2
    + A14 * /A15 * PHI2 *  RW * /PB4 * CASINH_IN *  RHALT */SW2

    + A14 * /A15 * PHI0 * /RW * /PB5 * CASINH_IN * /RHALT */SW2 * SW1
    + A14 * /A15 * PHI2 *  RW * /PB5 * CASINH_IN * /RHALT */SW2 * SW1;

/OE = A14 * /A15 * PHI2 *  RW * /PB4 * CASINH_IN */SW1
    + A14 * /A15 * PHI2 *  RW * /PB4 * CASINH_IN *  RHALT */SW2
    + A14 * /A15 * PHI2 *  RW * /PB5 * CASINH_IN * /RHALT */SW2 * SW1;

/MAP = /PB7 * PB4 * PB5
     + /PB7 * SW1 * SW2;
     
/CASINH_OUT = /CASINH_IN
            + A14 * /A15 * /PB4 */SW1
            + A14 * /A15 * /PB4 *  RHALT */SW2
            + A14 * /A15 * /PB5 * /RHALT */SW2 * SW1;
 

[tfhh]

Werde ich hier einstellen.
Ist aber glaube ich von TF_HH eine überarbeitete Version, das sollte eigentlich in Ordnung sein.

Muß auch irgendwie ein Timing-Problem sein, weil wenn man manuell die Werte schreibt klappt es ja uns sonst nur nach dem Einschalten eben nicht.

Nein, da habe ich diesmal nichts mit zu tun gehabt - Panos hat, vermute ich mal, direkt die Files von Hias verwendet.

Allerdings ist da ja noch dieser Dallas-Chip in der CE Leitung... vielleicht macht der Probleme? Nehme den mal raus, setze eine Brücke zwischen Pin 5 und 6 ein und teste erneut. Und wenn das RAM von Brilliance Semiconductor (BSI) ist, dann könnte es auch daran liegen.

[Erhard]

Panos hat, vermute ich mal, direkt die Files von Hias verwendet.

Es mag ja sein, daß Panos die verwendet hat, aber wenn ich mich recht erinnere habe ich die nicht verwendet ...
War da nicht irgendwas, daß mit dem Hias-GAL die Schalter irgendwie falsch funkioniert hatten, sowas wie in der ON-Stellung war die RD aus und umgekehrt?
Und weil die GAL-Sources von Hias in irgendeiner abgefahrenen Hochsprache sind hätte ich die vielleicht ändern, aber nicht kompilieren können, weshalb ich dann die o.g. genommen habe?

Jupp, sowas in der Art war es. Siehe eMails vom 16.02.2022.

Aber das GAL dürfte meines Erachtens nicht das Problem sein.

Daß das Problem genau beim zweiten STA auftritt könnte daran liegen, daß am Programmbeginn auf einen VBI gewartet wird, sonst wüßte ich nicht, was da eine Zeitreferenz verursachen könnte.

Und daß das Problem nur dann auftritt, wenn der Rechner eingeschaltet wurde fühlt sich nach irgendwas "Ge-Latch-tem" an.

Das mit dem DALLAS-Chip werde ich ausprobieren, daß mit dem RAM-Hersteller auch (wenn ich ein solches RAM von einem anderen Hersteller da haben sollte).

[Erhard]

@TF_HH,

Allerdings ist da ja noch dieser Dallas-Chip in der CE Leitung... vielleicht macht der Probleme?

Der Chip ist bei mir ein MAXIM MXD1210 und ja, ohne den Chip und mit Brücke zwischen 5+6 taucht der Fehler nicht mehr auf.

Das macht mich natürlich noch neugieriger. Ich werde da gelegentlich mal einen Logikanalysator dranhalten.

Das muß doch einen Grund haben, daß nur wenn der Rechner eingeschaltet wurde das zweite Chip-Select nicht durch kommt.

Der Fehler taucht übrigens auch dann auf, wenn der Chip mit Batterie drin ist (bei mir ist keine Batterie drin, ich bräuchte also den Chip nicht).

[Erhard]

.
Ich habe gerade einmal den Test mit einem Logikanalysator durchgeführt.

Hier ist klar zu erkennen, daß beim zweiten Schreibzyklus das Siganl zwar an Pin 5 des MXD1210 ankommt, aber nicht aus Pin 6 heraus.

Nach den 4 Schreibzyklen kommen 2 Lesezyklen und dann meldet das Programm "requires 130XE", weil eben in der zweiten beschriebenen Bank nicht das Testbyte drin steht.

XE_REMAKE_PROBLEM.png (14.63 KiB) 156 mal betrachtet

Angehängt ist noch die Datei des Logikanalysators. Ich mußte die Endung .TXT anhängen, weil das Forum eine .LPF-Datei nicht akzeptieren wollte.

Die zugehörige Software ist unter pctestinstruments.com frei erhältlich.

[HiassofT]

Hast Du da eine Batterie drin und gecheckt ob die auch OK ist?

Laut Datenblatt scheint das Verhalten die "Battery Status Warning" zu sein:
https://www.analog.com/media/en/technic ... XD1210.pdf Seite 5 rechts oben:

Battery-Status Warning: This notifies the system
when the stronger of the two batteries measures ≤
2.0V. Each time the MXD1210 is repowered (VCCI
> VCCTP) after detecting a power failure, the bat-
tery voltage is measured. If the battery in use is
low, following the MXD1210 recovery period, the
device issues a warning to the system by inhibit-
ing the second memory cycle. The sequence is
as follows:
First access: read memory location n, loc(n) = x
Second access: write memory location n,
loc(n) = complement (x)
Third access: read memory location n, loc(n) = ?
If the third access (read) is complement (x), then the
battery is good; otherwise the battery is not good.
Return to loc(n) = x following the test sequence.

so long,

Hias

[Erhard]

Tja Hias,

genau das wollte ich gerade schreiben.

Ich habe mir nämlich gerade das Datenblatt besorgt und hab mal geschaut, ob da irgendwas falsch angeschlossen ist.

Dabei bin ich dann auch auf den Passus mit der Batterie-Status-Warnung gestoßen.

Nun hatte ich den Rechner aber auch schon einmal MIT Batterie getestet und das Verhalten war geblieben, womit die fehlende Batterie vermeintlich als Ursache ausschied.

Der Fehler war aber, daß ich nur EINMAL getestet habe.

Man muß den Rechner mit (guter) Batterie mindestens ein zweites mal neu eingeschaltet haben, damit der MXD1210 keinen Warnstatus mehr produziert.

So schlau bin ich aber erst jetzt.

Also an alle mit XE-Remake: wenn keine Batterie drin ist funktioniert nach dem Einschalten des Rechners der zweite Zugriff auf die Ramerweiterung nicht.

Abhilfe:

1) wie TF_HH vorgeschlagen hat: raus mit dem Chip und im Sockel Anschluß 5 und 6 brücken oder
2) Batterie einbauen

Mit diesen Infos kann man dann auch ein Batterie-Testprogamm erstellen:

- Zugriff auf erweiterten Speicher aktivieren
- LDA $4000
- EOR $FF
- STA $4000
- CMP $4000
- PHP
- Zugriff auf erweiterten Speicher deaktivieren
- PLP
- BEQ L1
- Melung: batt_bad_or_missing
L1 - Meldung: batt_good_or_no_NVRAM_controller

Erhard

[Olix]

Super, dass du so hartnäckig an de, Problem dran geblieben ist.
Somit ist das Rätsel gelöst.

Auch ich habe zwar den Chip bestückt aber keine Batterie drin.
Somit werde ich mich für die Sockel-Brückenlösung entscheiden.

Vielen Dank für deine Mühen und Recherchen!

[Erhard]

.

Vielen Dank für deine Mühen und Recherchen!

Ist halt blöde, wenn man von diesem Verhalten nichts weiß ...

Du darfst gerne im Gegenzug herausfinden, was bei der Einrichtung einer RAM-Disk passiert (bzw welche(n) Fehler das zur Folge hat), wenn das Verhalten auftritt