![]() |
| Eins vorweg: meine nanoPEB muss erst noch den 'Weg über den großen Teich' antreten, d.h. derzeit verfüge ich hier über keine nanoPEB, weshalb dieses 'Projekt' im Backlog ist und die Bilder nicht von mir stammen. Macht aber nix, denn es stellt manchen Anwender schon vor das eine oder andere Problem, wenn er diesen 'Sidecar' in Betrieb nehmen will, so daß ich es als angemessen betrachte, hier mal das eine oder andere Wort 'remote' von mir zu geben... | |||
Babylon? | |||
|
Von 'DER' nanoPEB zu reden ist strenggenommen nicht korrekt - es gibt insgesamt 4 Versionen dieser Erweiterung, denen nur die Eigenschaft gemein ist,
eine Compact-Flash-Karte (CF) als Floppy-Disk-Simulation zu nutzen. Angefangen hat das als 'Compact Flash Drive For The TI-99/4A Computer', was man aber bestenfalls als Studie ansehen kann, da es sich recht freizügig im Adressbereich des Sprachsynthesizers austobte, was die Koexistenz dieser beiden Erweiterungen erfolgreich ausschloss. Dann kam die 'CF7+', die neben dem CF/IDE-Port auch noch einen Parallelport (PIO) bereitstellte, aber immer noch keine 32K. Schließlich und endlich kam dann die echte 'nanoPEB-SIO', zuerst (V1) mit einem TMS9902 als UART und TI-RS232-identischen CRU-Adressen, was die volle Softwarekompatibilität zu bestehender Software sicherstellte. Die konnte immerhin schon 19200 Baud, statt der 9600 der originalen TI-RS232, aber - viel wichtiger - es war ab jetzt auch die 32K Speichererweiterung mit an Bord! Die V2 bekam dann einen 16C550 UART, der zwar 115200 Baud erlaubte, der aber anders konfiguriert wird und dessen Register memory-mapped sind statt per CRU angespochen zu werden, und damit die Softwarekompatibilität komplett aufgab - wenn man eine nanoPEB V2 kauft, muss man sicher sein, daß man das in Kauf nehmen will! Warum eigentlich CF? Die Grundidee war wohl, durch Bereitstellung einer IDE-Schnittstelle (das zeichnet CF-Karten aus) eine breite Auswahl an Massenspeichern anschließen zu können, die noch dazu 'memory-mapped' im Adressbereich der TMS9900-CPU liegt, und ohne 'Coprozessor' auskommt. Bedenkt man, daß die Anfänge der nanoPEB inzwischen (A.D. 2025) 20 Jahre in der Vergangenheit liegen, wird klar: damals war das nichts mit Arduino, RasPI und Konsorten... ... am Ende war das mit den Harddisks dann doch wohl nicht so relevant, da man schon mit einer recht knappen CF-Karte hunderte bis tausend TI-Disks bedienen kann und man eigentlich nicht mehr Platz braucht - und irgendwo hat es auch seinen Reiz, das alles nur über den Erweiterungsport mit Strom versorgen zu können, was bei Harddisk nicht so einfach geht. Im Folgenden betrachten wir nur die nanoPEB V1. |
![]()
| ||
Konzept | |||
|
Die Hardware ist schnell erklärt: am Expansion-Port der Konsole hängen das DSR-ROM (als Flash), das Xilinx CPLD, die 32K RAM sowie der TMS9902 (mit dem unvermeidlichen MAX232) und etwas 'Glue' -
und natürlich der CF-Adapter, der aber keinerlei 'Eigenintelligenz' beisteuert.
In dem DSR-Flash finden wir auf CRU >1100 die CF/Floppy-DSR (Adaption der TI-DSR) sowie auf >1300 die serielle Schnittstelle (praktisch identisch zur TI-RS232).
Die gesamte Adress- und CRU-Decodierung wird - wer hätte das gedacht - vom CPLD erledigt. Bei der Software wird es spannender, denn der Inhalt der Karte ist z.B. auf einem PC nicht ohne weiteres lesbar. Das CF-Betriebssystem unterteilt die ganze Karte in 800KB große logische Volumes, und adressiert die einzelnen Sektoren der Karte direkt - dabei verwendet es einen Offset, der sich aus der laufenden Volume-Nummer ergibt, und der anhand der virtuellen Geometrie auf die Spuren, Seiten und Köpfe umgerechnet wird. Näheres zeigt ein Blick in den Quellcode, den der Autor Jaime Maililong als 'Abschiedsgeschenk' gestiftet hat... Die Sektoren einer CF-Karte sind 512 Bytes groß, die CF-DSR verwendet davon nur die erste Hälfte, angeblich weil der Decodieraufwand der CF-Hardwareansteuerung begrenzt werden sollte... naja - am Ende wird halt nur die Hälfte des verfügbaren Platzes genutzt - siehe oben, there's plenty! Die tatsächlichen 'Disketten' sind immer 400KB groß, haben also 1600 Sektoren (es sei denn man erzeugt Volumes mit externen Tools - die DSR passt sich der Größe an), womit das TI-Filesystem voll ausgenutzt wird ohne inkompatibel zu werden. Jedes der Volumes kann auf eines der 3 Diskettenlaufwerke DSK1, DSK2, DSK3 ge'mountet' werden, wobei der 'Mount Point' von DSK1 separat auf der CF-Karte gespeichert und beim Neustart wiederhergestellt wird. Auf der Anwenderseite stehen die 3 Befehle CALL MOUNT(), CALL UNMOUNT() und CALL FORMAT() zur Verwaltung der CF-Volumes zur Verfügung, neben CALL FILES() (sowie allen bekannten Level-2-Routinen, wodurch alle Diskmanager funktionieren sollten). Die Verwendung der 'CALLs' wird im (zugegeben nicht preisverdächtigen) Handbuch erklärt - deshalb spare ich mir hier die Wiederholung. | |||
Links | |||
| Es braucht einige Tools, um mit dem Dateisystem der CF-Karte klarzukommen. Eine recht gute Quelle ist hierbei die Webseite von F.G.Kaal - man findet nützliche Tools dort unter 'Projects'. Zum Standardrepertoire der nanoPEB gehören 'Begleitdisketten', die man hier und hier herunterladen kann. Soweit ich weiß wird das CF7-Format auch von XDM99 aus der XDT99-Suite unterstützt (unter Mithilfe vom XVM99) - näheres findet man auf der Website von Ralph Benzinger. | |||
| Kontakt: {anyname}@{use_the_url}.net |
Alle Bilder auf dieser Seite wurden von Hauke H. erstellt. Findet ihr sie anderswo, wurden sie hier geklaut! |
Letzte Aktualisierung: 2025-11-05 CW |