Beiträge von Dietrich

    Das bedeutet, dass die SD zwar da ist, aber nicht korrekt im SPI Modus angesprochen werden kann. Der Speicherauszug zeigt, dass nichts von der SD gelesen wird. Wenn du verschiedene SDs probierst und alle das gleiche Resultat ergeben, liegt sehr wahrscheinlich ein Hardwarefehler an der SPI Schnittstelle vor. Bitte probiere alle SDs, die du hast.

    Hardwareprobleme sind aus der Ferne nicht leicht zu untersuchen. Bitte mache nochmal Aufnahmen deiner IO-Karte ( Vorder- und Rückseite) in möglichst hoher Auflösung. Vielleicht kann man etwas sehen. Was hast du an Hilfsmitteln verfügbar?

    Dietrich

    Kein Stress. Ich habe mir nochmal den MKBOOT-Code angesehen. Lesefehler der SD Karte werden da nicht abgeprüft. Bisher ist ein Fall, wo man die SD-Karte zwar initialisieren, aber nicht korrekt lesen kann, noch nicht vorgekommen. Ich habe das im Programm eingebaut - nun also MKBOOT_DEBUG_V2.

    Same Procedure:

    MKBOOT_Debug.bin mit LM laden und mit 2000G starten. Danach Speicher mit 600.7FF ausgeben. Vom Ergebnis brauchen wir einen Screenshot.

    Das Ergebnis wird Jörg und mich etwas beschäftigen. Bitte prüfe in der Zwischenzeit die Spannungen am SD-Slot nach dem Reset, also VSS,VDD,DAT3,DAT0 (PINs 3/6,4,1,7). Wenn du ein Speicherskop oder noch besser einen Logicanalyser (der billige Saleae tuts) hast, schau bitte mal, was auf DAT0 und DAT3 so los ist, wenn MKBOOT läuft. Mit dem Skop kannst du auch mal nach der Qualität von VDD schauen, vor allem beim Initialisieren der SD - das ist das erste, was MKBOOT macht. Schlechte Kontakte in der SD-Fassung, kalte Lötstellen und Lötbrücken sind natürlich auch ein Thema.

    Viel Erfolg

    Dietrich

    Interessant. In $600-$7FF sollte der MBR stehen. Das ist Sector 0 der SD. Offensichtlich wird die SD korrekt initialisiert und kann korrekt gelesen werden. Aber - da steht alles andere als ein MBR. Das sollte etwa so aussehen:

    Wenn du einen Binärdateien-Editor (z.B. HxD) hast, kannst du ja mal in Sektor 0 der SD schauen, was da steht. Da muss ein MBR stehen, sonst könntest du die SD nicht lesen oder schreiben, was du aber kannst.

    Warum das ROM meint, Sektor 0 der SD erfolgreich gelesen zu haben, was aber offensichtlich nicht stimmt, darüber muß ich etwas nachdenken.

    Anbei eine modifizierte Debugversion von MKBOOT. Die schreibt in den Buffer bei $600-7FF Testdaten. Damit bitte nochmal alles wiederholen:

    MKBOOT_Debug.bin mit LM laden und mit 2000G starten. Danach Speicher mit 600.7FF ausgeben. Vom Ergebnis brauchen wir einen Screenshot.


    Glück und Geduld

    Dietrich


    Dietrich

    discmix die gute Nachricht: MKBOOT läuft. Die schlechte: die SD wird nicht initialisiert.

    Ich habe dir eine Debug-Version von MKBOOT gebaut, die etwas detailliertere Fehlermeldungen ausgibt. Insbesondere kann man sehen, welcher ROM-Call nicht erfolgreich abgeschlossen wird.

    Bitte also MKBOOT_Debug.bin mit LM laden und mit 2000G starten. Danach Speicher mit 600.7FF ausgeben. Vom Ergebnis brauchen wir einen Screenshot.

    Und dann sehen wir weiter

    Dietrich

    discmix CF-card? Du meinst sicher die SD-Card. Bitte probiere nochmal mkboot (V1.1) und poste Screenshots von der Bootmeldung und vom Speicherinhalt 600.7FF sowie 2000.20FF unmittelbar nach dem Bootversuch. Ich hoffe, dass man da etwas sehen kann, wo das Problem zu suchen ist.

    Dietrich

    Der alte STM32F105 hat 64 kB RAM, der AT32F415 nur 32 kB und der neuere AT32F435 hat 384 kB RAM.

    Der Unterschied ist bedeutsam, da die Software im RAM einen Puffer hält, der erst bei Bedarf aus dem USB-Stick nachgeladen wird. Das spielt besonders beim formatieren und schreiben von Images mit sehr viel Daten pro Track eine Rolle, da es dann je nach Geschwindigkeit des USB-Sticks zu Datenverlusten und Fehlermeldungen kommen kann.

    In der Praxis sind davon nur ein paar modernere Formate, wie z.B. 2,88 MB Images oder experimentelle Emulationen von Festplatten betroffen.


    Dietrich

    Ich hab mehrere Gotek mit Flashfloppy laufen. Alle sind mit OLED Display und Drehselektor nachgerüstet. Die nächsten werde ich daher komplettiert kaufen.
    Flashfloppy ist für Retrorechner ideal, weil praktisch jedes Aufzeichnungsformat dargestellt werden kann. Die Software liegt auf Github. Dabei ist auch ein excellentes Wiki, das alles gut erklärt.


    Dietrich

    Korrekt. Manchmal hilft ein Pufferakku direkt am SD Stecksockel von ca. 100 uF oder/und ein senken der Pullups auf 3,3k …

    Außerdem kommen auch Instabilitäten auf der Spannungsversorgung beim Hochfahren in Frage. Manche Entwickler machen deshalb die Versorgungsspannung des SD Slots schaltbar und können so einen Hardware-Reset erzwingen ….


    Dietrich

    Die Initialisierung von SD Karten in den SPI Mode, der bei unseren Systemen überwiegend eingesetzt wird, ist tricky. Insbesondere deshalb, weil die Modusauswahl nur einmal bei Startup gemacht werden kann und softwaremäßig nicht rückgesetzt werden kann, auch nicht durch einen Reset. Die Karte muss zum Neustart komplett spannungsfrei gemacht werden, also z.B. Rausnehmen. Wenn also bei der Initialisierung und beim Umschalten auf den SPI Modus etwas schiefgeht - Timing der Signale, Wartezeiten o.ä. - rutscht die Karte in den nativen SD-Modus und kann über SPI nicht mehr angesprochen werden.
    Die Robustheit der Karten diesbezüglich hängt stark vom verwendeten Controller ab und der unterscheidet sich auch beim selben Hersteller von Karte zu Karte. Da hilft wirklich nur Probieren - eine generelle Herstellerempfehlung gibt es nicht. Und teurer ist hier auch nicht notwendigerweise besser.

    Viel Glück. Dietrich

    Da stimmt etwas mit der Adressdekodierung nicht. Auf $BFFA..BFFF sehe ich die IRQ/RESET/NMI-Vektoren, die auf $FFFA..FFFF liegen. Und da liegen sie auch, sonst würde der Monitor nicht funktionieren. Es ist mir auch nicht klar, wie MKBOOT.BIN korrekt gekaden werden kann, dann aber ohne wenigstens die Startmeldung auszugeben abstürzt. Das ging in #2206 doch schon ??? Dieses Problem mußt du vorrangig lösen.

    Bitte prüfe nochmal alle Schalter und Jumper. Falls das nichts bringt, wäre es gut, die für die Adressdekodierung zuständigen Dekoder und Adressbustreiber zu testen. Dein Tl 866 sollte das können.

    Dietrich

    discmix

    Weiterhin zeigt der Speicherauszug nur Zufallsdaten, d.h. die SD wird nicht gelesen und vermutlich auch nicht erkannt. Um das zu prüfen, gib im Monitor bitte 600:B0 ein, boote neu und schaue anschließend im Monitor mit 600.7FF nach, ob $B0 noch da ist.

    -Ja, der eingetragene Wert bleibt nach einem Reset im Memory an der Stelle 600 bestehen

    Bitte versuche noch 600:55 und poste einen Screenshot 600.7FF. Vielleicht kann man da was sehen.

    Poste bitte zusätzlich den Startbildschirm unmittelbar nach dem Reset.


    Deine Probleme mit der seriellen Schnittstelle erinnern mich an einen billigen China-USB-RS232 Konverter, den ich mal hatte. Der war nicht in der Lage, eine stabile Verbindung aufzubauen und die Baudrate war fast 10% daneben. Dieses Problem musst du lösen. Die RS232 ist mind. über 50 m stabil. Evtl. ist das Kabel oder die Steckverbindungen die Ursache. Am besten tauschst du das Kabel. Wenn du keine stabile Verbindung hast, bekommst du in der Regel keine XMODEM-Übertragung hin.

    Wenn die serielle Verbindung steht, wenden wir uns wieder der SD Karte zu.

    K2 ist ok. EXT_RAM_SEL $80 ist auch ok - das schaltet RAM von $8000-$9FFF frei.

    Ich bin im Moment verreist. Ab Dienstag bin ich wieder zu Hause und kann mehr tun, dir zu helfen.

    PS. Probiere mal EH-Basic und schicke einen Screenshot vom Startbildschirm.


    Gruß

    Dietrich

    discmix da stimmt etwas ganz und gar nicht. Der Monitor Output enthält offensichtlich Steuerzeichen, z.B. ab $06BC. Das deutet auf ein Problem mit der seriellen Ausgabe hin - entweder arbeitet die Schnittstelle nicht mit den korrekten Pegeln oder der MAX 323 hat einen Schlag oder das serielle Kabel/Stecker hat schlechten Kontakt. Letzteres ist am wahrscheinlichsten.

    Weiterhin zeigt der Speicherauszug nur Zufallsdaten, d.h. die SD wird nicht gelesen und vermutlich auch nicht erkannt. Um das zu prüfen, gib im Monitor bitte 600:B0 ein, boote neu und schaue anschließend im Monitor mit 600.7FF nach, ob $B0 noch da ist.

    Die SD selbst sollte korrekt sein. Bitte schau aber sicherheitshalber nach, ob sie im Finder oder Dateimanager erkannt wird und kopiere sicherheitshalber mal ein File drauf. Wenn das klappt, ist die SD ok.


    Dietrich

    discmix die SD Karten müssen FAT formatiert sein und einen MBR (Master Boot Record) haben. Das musst du beim Formatieren der SD korrekt einstellen. Könntest du bitte prüfen, ob das wirklich so ist?

    Die Meldung ‚Sd card or MBR not valid‘ kommt, wenn entweder die SD gar nicht erkannt wird oder im Sektor 0 der SD die MBR Signatur $55AA nicht gefunden wird. Bitte wechsele nach dem Versuch mit MKBOOT.BIN in den Monitor und gib mit ‚600.7FF‘ mal den Speicherbereich aus, in dem der MBR stehen sollte und poste einen Screenshot davon. Dann kann besser sehen, wo das Problem liegen könnte.


    Dietrich

    Neue Version von MKBOOT ist hier

    Änderungen:

    • wenn die SD 4 Partitionen hatte, wurde die 4. Partition nicht initialisiert und der MBR nicht korrekt geschrieben, so daß die SD nicht booten konnte
    • die Erkennung des FAT-Typs wird jetzt durch die Zahl der Cluster in der Partition bestimmt. Das ist die zuverlässigste Methode.
    • Das Textfeld für den Partitionstyp wird nun von MKBOOT mit FATxx (xx = 12/16/32) beschrieben.

    In der Anlage findet ihr den Quellcode und die MKBOOT.COM für MOS-65 sowie die MKBOOT.BIN zum Laden mit XMODEM aus dem Monitor auf die Speicherstelle $2000 - Start mit 2000g

    Dietrich

    MKBOOT V1.1

    In Zusammenarbeit mit 2ee habe ich das MKBOOT-Utility zur Vorbereitung einer formatierten SD-Card überarbeitet.

    Änderungen:

    • wenn die SD 4 Partitionen hatte, wurde die 4. Partition nicht initialisiert und der MBR nicht korrekt geschrieben, so daß die SD nicht booten konnte
    • die Erkennung des FAT-Typs wird jetzt durch die Zahl der Cluster in der Partition bestimmt. Das ist die zuverlässigste Methode.
    • Das Textfeld für den Partitionstyp wird nun von MKBOOT mit FATxx (xx = 12/16/32) beschrieben.

    In der Anlage findet ihr den Quellcode und die MKBOOT.COM für MOS-65 sowie die MKBOOT.BIN zum Laden mit XMODEM aus dem Monitor auf die Speicherstelle $2000 - Start mit 2000g

    Dietrich

    ... und bevor ich das wieder vergesse:

    Zitat

    Nun schliesse ich über die Backplane die Floppy/Graphics Platine an (Brücke gesetzt auf K3)

    Die FGC-Card muß zwingend auf K4 gejumpert werden!

    Dietrich

    Neue CPM-65-Version mit BDOS 2.5

    Nachdem mich ein netter Kollege im Internet auf einen Fehler in der BDOS-Funktion zur Eingabe einer Textzeile (BDOS function $0A) aufmerksam gemacht hat, dabe ich diese Routine gründlich überarbeitet mit folgenden Neuerungen:

    • einfacher Zeileneditor, der auch die letzte eingegebene Zeile nochmal bearbeiten kann. Alle üblichen Funktionstasten funktionieren
    • kompatibel zu TERATERM und - hoffentlich - zu allen Terminals und Terminalprogrammen

    Funktion (im Moment nur in Englisch ...):

    BDOS Function $0A Basic Input Line Editor

    The function accepts a line of input into the line buffer referenced in $EC/$ED.

    Line Format:

    Byte content

    $00 length + 1

    $01 .. $nn 7 bit ASCII text

    $nn+1 EOT chr = $00

    Maximum line length is 126 chrs including EOT


    The input line may be edited by the user with control commands. The line editor is overwrite only. No insert mode is available.

    Command function

    [->] cursor right

    [<-] cursor left

    CR carriage return, exit line input

    CTRL-A cursor to 1 chr of the line

    CTRL-D cursor right

    CTRL-F cursor to the current end of the line

    CTRL-H cursor left

    CTRL-I cursor right

    CTRL-M carriage return, exit line input

    RUBOUT cursor left – ASCII $7F must be sent

    The command checks for a valid string in the buffer. So a command string from a previous command can be directly reused or edited.

    Die Quellen gibt's wie immer auf GitHub, die Disk Images mit dem neuen BDOS hänge ich an

    Viel Spaß

    Dietrich

    Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

    Ich versorge meinen JC-][ über den Anschluß auf der Backplane, weil ich dem Buchsenstecker auf der Basisplatine nicht recht traue :wacko:

    Mein Netzteil liefert 5V/3A. Das sollte für eine halbwegs moderne 3,5 Zoll-Floppy auch noch gut reichen.

    Dietrich

    Du brauchst die IO-Card für das EH-BASIC und die SD-CARD, die derzeit der einzige Massenspeicher ist, den der JC-][ ansprechen kann.
    Aus meiner Sicht ist diese Karte dringend empfohlen, aber nicht absolut notwendig. Ohne die IO-Card musst du warten bis Jörg die Floppy-Treiberroutinen fertig hat. Dann kann die Floppy die Rolle als Massenspeicher übernehmen. Mit den Floppytreibern gibt es allerdings noch Probleme - da ist Geduld gefragt.

    Weiter wichtige Befehle im Monitor sind LM (Load xModem file) und SM (Save xModem file). Damit kanst du über Teraterm oä. files vom PC laden und zum PC speichern, z.B. die ganzen alten Übungsprogramme aus den JC-Büchern.

    Viel Erfolg

    Dietrich

    So, ich habe nun endlich das neue EH-BASIC V2.25 mit dem neuen FGC-ROM eingebaut und getestet: klappt einwandfrei und bisher keine Auffälligkeiten oder Fehler. 2ee tolle Leistung.

    Bin sehr gespannt, wie es weitergeht.


    Dietrich

    Ich habe den über 40 Jahre alten Quellcode von STARTREK.BAS an EH-Basic angepasst. In meinen - begrenzten - Tests läuft er jetzt fehlerfrei.

    Ich füge den Quelltext (STARTREK_EH.TXT) und das mit LOAD ladbare tokenisierte File (STARTREK.EHB) bei.

    STARTREK.EHB kann in EH-BASIC mit LOAD per Xmodem geladen werden.

    STARTREK_EH.TXT ist das mit LIST erzeugte Programmfile. Das kann man via TERATERM mit der Screencopyfunktion laden. Bitte unbedingt die Wartezeit auf 1000 msec/line einstellen, sonst gibt es da Müll, weil die Tokenisierung gelegentlich sehr viel Zeit braucht.

    Für die Experten: EH-BASIC verhält sich im Detail deutlich anders als Microsoft-Basic. Insbesondere ist es in EH-BASIC nicht zulässig, aus einem FOR - NEXT Loop einfach mit GOTO herauszuhüpfen. Das hat nämlich zur Folge, dass der Loop auf dem RETURN-Stack als offen liegen bleibt, was dann über kurz oder lang irgendwo im Programm zu einem Out of Memory führt. Das im Stil der 80er Spaghetti-Code-mäßig geschriebene Program auf sauberere Strukturen umzustricken war doch etwas Arbeit....

    Viel Spass mit Kirk & Co :)

    Dietrich

    Habe gerade meinen China-McBsazel Clon GBS-8200 V4.0 bekommen und in Betrieb genommen - klappt. Bildqualität ist gut auf einem normalen VGA-LCD-Monitor ACER AL1703. Ich musste allerdings neben Masse, Rot, Grün und Blau auch HSYNC anschließen.

    Danke an NorbertJ und 2ee für die Tipps.


    Dietrich

    Es gibt durchaus Gläser, die bis in den UV-Bereich durchlässig sind, je nach Rezeptur unterschiedlich weit, aber nie so weit wie Quarzsglas. Da Quarzglas teuer ist, kann es also durchaus sein, daß in einem EPROM UV-durchlässiges Glas verbaut ist. Für das Löschen mit einer herkömmlichen UV-Lampe spielt das keine Rolle, da diese Lampen breitbandig abstrahlen und immer genügent UV-Licht durchgeht. Bei UV-LEDs hat man es mit einem Laserlicht zu tun, das schmalbandig ist und durchaus so weit in Richtung UV-C liegen kann, dass das Fenster zumacht.

    Der Löschprozess beim EPROM beruht darauf, daß man mit dem UV-Licht in der Isolierschicht, die das Abfließen der beim Brennen auf das floating Gate transportierten Elektronen verhindert, Ladungsträger freisetzt. Dadurch können die Elektronen auf dem floating Gate abfließen und die Speicherstellen sind dann gelöscht. Gelöschte Speicherstellen werden übrigends immer als logisch 1 ausgelesen.

    Je höher die Speicherkapazität der EPROMs ist, desto kompakter sind die Zellen auf dem Chip und umso dünner sind die Isolierschichten und umso geringer ist auch die Zahl der gespeicherten Elektronen pro Zelle. Die Isolierschichten sind alle UV-undurchlässig. Die Zahl der zum Löschen freizusetzenden Ladungsträger in der Isolierschicht ist proportional der Zahl der gespeicherten Elektronen. Je intensiver das UV-Licht, desto mehr Ladungsträger. Es ist also nachvollziehbar, das modernere EPROMs weniger Löschzeit benötigen.

    Man kann die Isolierschicht eines EPROMs theoretisch auch mit UV-Licht ‚kaputtbraten‘. Allerdings sind die dazu nötigen Lichtmengen extrem hoch und mir sind aus der Praxis keine Fälle bekannt, wo jemand das geschafft hätte. Da wären tausende Löschvorgänge erforderlich. Eher stirbt das EPROM anderen Defekten, z.B. statischen Entladungen. EPROMs, die nach über 50 Jahren noch einwandfrei funktionieren sind durchaus normal.

    Ich kann bestätigen, dass das gut funktioniert. Ich hatte Bedenken, weil PHI1 bei mir im Skop etwas verschliffen aussieht. Testhalber habe ich mal OE/ ebenfalls an CS/ gelegt - geht auch. Entscheidend ist ja, dass die Daten auf dam Data Bus bei der fallenden Flanke von PHI2 stabil anliegen.

    Dietrich