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
discmix bitte prüfe auch nochmal alle Leiterbahnen im Bereich des Adressbus auf Lötbrücken und kalte Lötstellen 😇
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
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:
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:
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:
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:
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
Ich versorge meinen JC-][ über den Anschluß auf der Backplane, weil ich dem Buchsenstecker auf der Basisplatine nicht recht traue 
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
2ee danke für die gute Zeit auf der VCFe und vor llem für die Unterstützung bei meinen Hardware-Wehwehchen
Dietrich
NorbertJ könntest du bitte dein Setup mit dem McBazel mal genauer beschreiben?
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
Hier noch das fehlende Bild
Update SYSINFO mit mehr Infos zum System:
Anbei noch die aktualisieren Disk Images
Dietrich
Ich habe nun das BIOS von CPM-65 an die neuen Routinen der FGC Karte angepasst und auch das Interrupt-Handling neu gestaltet. Im Ergebnis laufen - hoffentlich - jetzt alle Programme im VDU-Modus und über die serielle Schnittstelle.
Bekannte Einschränkungen und Probleme:
- In Debug wird im VDU-Modus der Cursor abgeschaltet, sobalt man die T(race)-Funktion nutzt. Die genaue Ursache dafür muß ich noch klären. Das Programm funktioniert aber trotzdem, halt nur ohne sichtbaren Cursor.
- Unter CPM-65 wird nur der Timer2-IRQ unterstützt. Davon betroffen ist mit Sicherheit die Tape-Routine im ROM, die unter CPM-65 eh nicht gebraucht wird.
Anbei die Disk Images und das angepasste BOOT.SYS. Wie immer alles auf eine mit MKBOOT vorbereitete SD kopieren und Spass haben.
Ich freue mich über jede Rückmeldung
Dietrich
Ich kämpfe gerade mit dem VDU-Teil der FGC-Karte. Tagesformabhängig kommt mal ein vernünftiges Bild, mal nur Müll (s. Foto). Auch wenn Müll dargestellt wird, läuft der JC korrekt. Man kann das mit Mühe auch erkennen. Über die serielle Schnittstelle funktioniert alles normal, auch die PS2-Tastatur.
Ich vermute ein Timingproblem bei der Ansteuerung des EEPROMs. In diesem Zusammenhang verwirrt mich das Signal PHI1 an OE/. Versuchshalber habe ich mal OE auf CE gelegt. Funktioniert, aber keine Besserung. Die Signalform auf CE sieht verschliffen aus - also R12 auf 1k geändert. Funktioniert, sieht besser aus, aber keine Änderung.
Habt ihr Ideen?
Dietrich
Prima, ich werde Sonntag ab 10.00 Uhr da sein
Dietrich
Hallo 2ee,
ich habe gerade meine letzte Version nochmal durchgesehen und eine kleine Anpassung der Forth-Stack-Nutzung auf der Zeropage vorgenommen. Die IRQs sind unter MOS-65 aktiv. Ein schneller Test auf meiner Hardware zeigt keine Probleme. Leider ist es immer noch so, daß Programme nur über die serielle Schnittstelle eingespielt werden können. Ich würde mich freuen, wenn du diese Version mal antesten könntest - mein VDU-System zickt nämlich gerade rum.
Selbstverständlich freue ich mich, wenn du auf der VCFe auf dem JC ][ CPM-65 und Fig-Forth zeigst. Wie es der Zufall so will, werde ich in der Zeit auch in München sein und natürlich auch bei der VCFe vorbeischauen.
Bis dann
Dietrich
Hallo zusammen,
nach langer Winterpause möchte ich mal wieder Fig-Forth vorholen und einen der größten Vorzüge dieser Programmiersprache für kleine Rechner besprechen - nämlich die Erzeugung von direkt ausführbaren Programmen. Das ist möglich, weil Forth ein Compiler ist. Das heißt, dass das Benutzerprogramm direkt beim Eingeben oder Einlesen in ein ausführbares Programm übersetzt (compiliert) wird. Dabei agiert das Forth-Basissystem als Kernel, der alle nötigen Routinen für das Programm bereitstellt und die Ausführung steuert. Fazinierend.
Als Forth-Kernel benötigt man nicht das komplette Forth, sondern nur ein solides Basissystem. In meinem Fall habe ich alle Routinen zum Ausdrucken von Programmen oder des Vokabulars aus dem Kern entfernt und ein rudimentäres DOS zugefügt, damit man ordentlich arbeiten kann und beim Entwickeln nicht ständig nachdenken muß, ob die Funktion, die man da aufruft, überhaupt da ist. Dazu kommt noch ein trickreicher Mechanismus der im Kernel ein vom Nutzer wählbares Wort beim Start direkt ausführt. Das ganze System ist nur 8 kB groß und da der FORTH-Code so herrlich kompakt ist, steht auch sehr großen Projekten genug Speicher zur Verfügung.
Wie geht man also vor?
1. Ein Forth-Programm ist zu entwickeln, das etwas tut, was man öfter mal braucht. Als heutiges Beispiel soll das Programm SYSINFO dienen, das wesentliche Parameter des laufenden CPM-65 ausgibt, etwa die Versionsnummern der Komponenten und die Kapazität und Organisation der Laufwerke. Diese Programm muß mit einem einzigen zentralen Forth-Wort aufrufbar sein. in unserem Beispiel ist das das Wort .SYS
SCR # 5
0 ( Sysinfo D. Lausberg 15.5.21 )
1
2
3
4
5
6 : .Sys cr cr .Header hex
7 ." BDOS V" bdosver .VER cr
8 ." BIOS V" biosver .VER CR
9 ." PROM V" .promver cr
10 .drives
11 cr 0 bdos ;
12
13 -->
14
152. Wenn das Programm fertig ist, muss man unbedingt 3 Zeilen Code anfüge, die das Ende des Programms markieren, damit man hinterher auch das vollständige Programm speichert.
SCR # 6
0 ( Sysinfo D. Lausberg 15.5.21 )
1
2
3 decimal
4 latest 12 +origin !
5 here 30 +Origin !
6
7 ;SDer so fertiggestellte und getestete Code wird nun mit SAVE SYSINFO.BKL abgespeichtert.
3. Man verlässt Forth mit BYE und stellt sicher, dass es kein Programm mit dem vorgesehenen Filenamen auf der Disk gibt, also ein SYSINFO.COM nicht vorhanden ist. Sonst kann SYSINFO.COM nämlich im nächsten Schritt nicht abgespeichert werden. Anschließemd wird das Programm FKERNEL.COM von der FORTH-Disk gestartet und man erhält eine Kernelmeldung und den üblichen FORTH-Prompt. Dann lädt man SYSINFO.BLK in den Pufferspeicher und kompiliert das Programm, wei gewohnt, mit 3 LOAD.
An dieser Stelle das Programm bitte nicht aufrufen, da es am Programmende ins CPM-65 zurückspringt und ihr die Übung unter Punkt 3 nochmal machen müsst.
4. Der Befehl AUTOEXEC .SYS SYSINFO.COM erzeugt nun das ausführbare Programm und speichert es ab - Fertig
bye
A>erase sysinfo.com
ERASE V1.5 (c) D.Lausberg
Insert disc to drive A:
and press any key
SYSINFO .COM ^C=abort (nothing deleted), E=Exit, Y/N y
ERASE finished
A>fkernel
fig-FORTH Kernel 1.0
open sysinfo.blk ok
3 load ok
autoexec .sys sysinfo.com ok
Junior Computer ][ System Status
BDOS V2.4
BIOS V1.3
PROM V1.1.4
Drive SPB SPBDIV BPD Cap kB Dir #
A: 8 3 508 1016 256
B: 8 3 508 1016 256
C: 8 3 508 1016 256
D: 8 3 508 1016 256
E: ------
F: ------
G: ------
H: ------
A>d sysinfo.*
D.COM V2.3 (c) D.Lausberg
Attr filename.ext rec kB Attr filename.ext rec kB
0000 SYSINFO .BLK 20 4 0000 SYSINFO .COM 3A 8
total diskspace used 12 kB
Directory finished
A>Viel Spass bei der Programmentwicklung in Forth
Dietrich
Hallo Jörg,
vielen Dank für deinen ausführlichen Bericht. Ich für meinen Teil bin vom JC ][ immer noch begeistert und werde ganz sicher dabeibleiben und auch weiter Input liefern. Im Moment ist die größte Baustelle das Zusammenspiel von CPM-65 mit dem nun unbedingt erforderlichen IRQ-System. Derzeit muß ich den IRQ noch abschalten, aber das ist keine Dauerlösung.
Dietrich
Ich würde erstmal ein Diagnoseprogramm bemühen, z.B. Copy II+.
Oft stimmt die Drehzahl nicht.
Dietrich