SD-Karte ist ja auch Flash und daher in der Anzahl der Schreibzyklen begrenzt. Aber ja: Ich werde auf der Platine einen SD-Karten-Slot vorsehen, das erleichtert dann auch das Aufspielen vorbereiteter Images und hilft den WiFi-Allergikern 
Beiträge von hans
-
-
Du denkst an die begrenzten Schreib-Zyklen des internen Flash's? Ich meine gelesen zu haben, das es ca. 100K-Zyklen sein sollen
Ich schreibe eventuelle Änderungen alle 15 Sekunden ins Flash. Das kann zwar dazu führen, dass ein inkonsistenter Zustand im Dateisystem landet, aber dank Akkubetrieb halte ich das Risiko für akzeptabel.
-
Nachdem ich tagelang einen Fehler auf der zweiten Protoypen-Platine mit dem größeren CPLD gesucht und endlich auch gefunden habe, bin ich mit der Entwicklung jetzt gut weiter gekommen. Der Fehler war ein Kurzschluß auf dem PX-8-Adressbus unter dem IDC-Steckverbinder, zu 100% unsichtbar und nur mit dem Multimeter zu finden.
Ich habe nun die RAM-Disk auf dem Raspberry Pi Pico in Python implementiert. Sie ist kompatibel zur Original-RAM-Disk von EPSON, d.h. der PX-8 erkennt sie bei der Initialisierung und bietet an, sie zu formatieren. Auf dem Pico werden die Daten im Flash gespeichert, und man kann entsprechend verschiedene RAM-Disks mit je 120kB verwenden. Obwohl ich bisher noch keine nennenswerten Optimierungen implementiert habe, ist der Zugriff deutlich schneller als auf EPROM-Module.
Als nächstes möchte ich auch die Modem-Funktionalität komplett implementieren. Ausserdem braucht es ein Interface, mit dem man vom PX-8 aus die Emulation auf dem Pico konfigurieren kann.
Quellcode ist auf GitHub: https://github.com/hanshuebner/picox-8
-
hans kannn das Geraet ein Videosignal an einen externen Bildschirm geben? Wenn ja, welcher Videostandard? Vermutlich dann wohl hochkant... ?
Der Ausgang ist ein VGA-Signal, aber tatsächlich hochkant und insofern vermutlich nicht oder nur mit einem geeigneten Wandler auf dem Beamer anzeigbar.
-
Kann dieser wiederkehrende Thread über Paketdienste bitte verschoben werden?
-
Kenn ich! Das ist eine Carte Blanche!
-
Ich habe die Chips für die 128 MB-Aufrüstung meines Macintosh IIfx damals auf Aliexpress gekauft. Sie waren natürlich recycled, aber nicht neu gelabeled und für mich hat das perfekt funktioniert. Im SIMMBA-16-Repository wird ja eher Angst gemacht, was das die Verwendung aus Chips solcher Quellen angeht. Meine Erfahrungen mit Aliexpress-Recyclingchips sind überwiegend positiv und bei den wenigen Fällen, in denen die gelieferten Chips nicht funktioniert haben, habe ich mein Geld umgehend zurückerhalten.
-
Ich habe solche Kontakte bisher immer mit der Crimpzange montiert, die ich mir mal für PSK-Kontakte gekauft habe. Sie sieht so aus:
Es gibt ähnliche Zangen noch mit weiteren Durchmessern, damit kann man ggf. noch besser die jeweiligen Kontakte in ihrer Größe treffen. Das "offizielle" Crimp-Werkzeug braucht man meiner Meinung nach nur, wenn man kommerziell arbeitet und versicherungstechnisch auf der sicheren Seite sein möchte.
-
Hallo Anne,
Welche Tasten gehen denn sonst noch nicht? Für eine Eingrenzung des Problems wäre es hilfreich, das zu wissen, aber am Ende wird es sich vermutlich um ein Hardware-Problem handeln, das nur mit einem kleinen Werkstattaufenthalt zu lösen ist. Du kannst mit den Rechner schicken und ich repariere ihn Dir, bei Interesse schick mir eine PN.
-Hans
-
Mit den ROM-Modulen hatte ich auch schon meine Probleme, aber sie hatten letztlich mechanische Ursachen. Die Kontaktierung ist nicht sehr zuverlässig und die Kontakte verbiegen auch gerne mal. Ich würde mal mit dem Mikroskop prüfen, ob da vielleicht was verbogen ist, und die Sockel mit Kontaktspray reinigen.
-
Der PX-8 hat ja schon das dollste Kassettenlaufwerk, das man sich vorstellen kann, insofern ist da nichts zu verbessern:
Was fällt auf? Genau: Es gibt keine Bedienelemente. Die Kassetten werden blockweise angesprochen, und man kann sie - wenn man ausreichend Geduld hat - wie Disketten verwenden. Details im Manual.
-
Hier ist ein Blockdiagramm:
-
Geschmäcker sind verschieden. Bei mir ist es genau andersrum - mich nervt WiFi Datenübertragung. Passwörter, Verbindungsprobleme, File Server... elendiges Zeug.
OK, dann schaue ich mal, ob ich noch einen SD-Karten-Sockel vorsehe. Der Platz reicht ja.
-
Ich werde auf der Platine voraussichtlich einen LTC4085 für das Power Path Management vorsehen. Er kann LiPo- und LiIon-Akkus laden und sorgt dafür, dass der Rechner während des Ladevorgangs aus dem USB-Port versorgt wird. LiPo und LiIon sind offenbar die besten derzeit verfügbaren Akkutechnologien. Ich werde versuchen, auf der Platine eine Aussparung vorzusehen, in die auch die größeren LiIon-Zellen hineinpassen.
Heute habe ich mir einen zweiten Prototypen gebaut, denn der XC9572XL im VG44-Gehäuse hatte nicht genug Pins, um den Z80-Bus zu bedienen und mit vertretbarem Aufwand ein schnelles Interface zum Pico zu realisieren. Ich verwende nun einen XC95144XL im TQ100-Gehäuse, da ist dann reichlich Luft. Bei Preisen von 2-3 Euro pro Stück macht es keinen rechten Unterschied, welcher CPLD letztlich benutzt wird, finde ich.
Mit dem größeren CPLD werde ich in der Lage sein, die 3 Register des Modems sowie die beiden Register der RAM-Disk mit dem Pico zu verbinden. Ich bin im Moment jedoch noch nicht sicher, wie ich das mit der Pico-Software machen will. Das WiFi-Modem, welches ich zum Testen verwendet habe, funktioniert zwar, aber da es sich beim Quellcode ursprünglich um Arduino-Code handelt, ist es ein bisschen schwer integrier- und erweiterbar. Ausserdem emuliert es ja ein Hayes-Modem, bei dem die Ansteuerung über AT-Befehle auf der seriellen Schnittstelle erfolgt. Das Epson-Modem hingegen wird über I/O-Ports des Z80 angesteuert, und vielleicht ist es besser, dann ganz auf die C++-Software zu verzichten und die Firmware auf dem Pico stattdessen in MicroPython zu bauen.
In MicroPython hat man auch direkt Unterstützung von LittleFS, ohne sich mit CMake befassen zu müssen. Mit LittleFS kann man den Teil des SPI-Flash, der nicht durch die Firmware belegt ist, als Dateisystem nutzen. Die Daten der RAM-Disk könnten dann direkt in LittleFS gespeichert werden, und Batteriepufferung würde in diesem Zusammenhang nicht mehr notwendig sein.
Ob ein SD-Karten-Interface benötigt wird? Ich bin mir nicht sicher. Im QSPI-Flash bietet 2 Megabyte (abzüglich MicroPython) Platz, und weitere Daten kann man über WiFi laden und speichern. Das Gefummel mit SD-Karten finde ich eigentlich eher nervig, aber vielleicht bin ich da allein.
-
Wenn jemand Interesse an so einer Erweiterung hat, bitte gerne hier äußern.
Interesse hab ich. Muß nur den Rechner erstmal stabil zum Laufen bekommen.
Was für Probleme macht denn Dein Gerät? Vielleicht lohnt es sich, erstmal die Stromversorgung zu modernisieren?
-
Wie hat er das denn aufgebaut?
Scheinbar gar nicht: "The battery was new and not connected"
-
Gerade, als ich das hier fertig geschrieben hatte, sah ich diesen Post:
https://mastodon.social/@BoscoLab@social.tchncs.de/112745852095275915
Vielleicht will ich doch keinen LiPo-Akku nehmen? Was sind die Alternativen?
-
Hallo,
ich habe vergangene Woche von explit einen Epson PX-8 erhalten, und zu meiner Freude kam diese schöne Maschine mit einer RAM-Disk-Erweiterung ("RAM DISK UNIT 60"), die auf 120 Kilobyte aufgerüstet ist. Natürlich waren die drei Akkus (NiCd) im Eimer und ich hatte erst geplant, sie durch neue NiCd's zu ersetzen, aber dann habe ich mir die Erweiterungkiste ein bisschen genauer angesehen und überlegt, dass es doch eigentlich viel schöner wäre, einen modernen LiPo-Akku dort einzubauen und damit das ganze System zu versorgen.
Die Erweiterungsbox ist eigentlich ziemlich groß, aber die Aussparung für den Akku ist ziemlich klein, und der Rest der Box wird für die monströse RAM-Disk (mit dynamischem RAM und eigenem Z80) verbraten:
Da liegt es doch eigentlich nahe, die Platine komplett durch etwas moderneres zu ersetzen: Ladeelektronik für LiPo-Akku, ein Raspberry Pi Pico für Modem- und RAM-Disk-Emulation und vielleicht noch mehr, und ein CPLD zur Pegelanpassung und für die Adressdekodierung. Ich habe also angefangen, einen Protypen zu bauen:
Für die Stromversorgung habe ich erstmal auf Fertigmodule (Ladecontroller und Boost-Converter von 3.7V auf 5V) zugegriffen, aber das soll natürlich dann auf die neue Platine integriert werden. Eine kleine Herausforderung wird dabei, das so zu gestalten, dass der Akku im Betrieb geladen werden kann. Es scheint, dass die meisten LiPo-Ladecontroller-Chips gern keine Last auf dem Akku haben wollen, wenn geladen wird, also muss ich einen Weg finden, den Rechner während des Ladevorgangs aus dem USB-Port zu speisen und unterbrechungsfrei zwischen Lade- und Akkubetrieb umzuschalten. Wenn jemand einen Tipp für eine fertige Schaltung hat, wäre ich interessiert.
Die vorhandenen Akkus habe ich ausgebaut, und ich versorge das gesamte System nun mit +5V aus dem Boost Converter (oder zum Testen aus dem USB-Port). Die ursprüngliche Ladeelektronik wird nicht mehr verwendet, und die 5V landen direkt auf der auch auf dem Erweiterungsbus vorhandenen Batteriespannungs-Leitung (VB).
Die einfachste Funktion der Erweiterungsbox ist das WiFi-Modem. Es gab im Original auch eine Modem-Erweiterung (wahlweise auch als Kombination mit RAM-Disk), daher ist die serielle Schnittstelle auch auf den Erweiterungsbus geführt. Der UART-Empfänger im Rechner kann über einen IO-Port zwischen der herausgeführten RS232-Schnittstelle und dem Erweiterungsbus umgeschaltet werden. Die Modem-Software kann über einen Port erkennen, ob ein Modem am Erweiterungsbus hängt, und dann eben entsprechend umschalten. Ich habe das Statusregister im CPLD realisiert, und damit funktioniert dann auch das "DAK Communications ROM":
Als Modem-Software verwende ich auf dem Pico das PicoWiFiModem, wobei ich noch kleinere Anpassungen machen muss, um es mit DAK Comm kompatibler zu machen.
Die nächste Aufgabe wird dann die Implementation der RAM-Disk. Es gibt eine funktionierende Emulation, die sich vermutlich recht einfach portieren lässt. Ich bin allerdings noch nicht sicher, ob ich die RAM-Disk und das Modem in einem Pico zum Laufen kriege. Theoretisch sollte das passen, aber praktisch ist es mir vielleicht zu viel Fummelei und ich packe einfach noch einen zweiten Pico W auf das Board.
Wenn jemand Interesse an so einer Erweiterung hat, bitte gerne hier äußern. Das Projekt ist auch auf GitHub.
-
Das ist der Soundchip, oben rechts in Deinem Ausschnitt. Unwahrscheinlich, dass er das Problem ist, aber den kannst Du ja einfach mal rausziehen, der ist ja immer gesockelt.
Die CPU kann es natürlich auch immer noch sein, hatte ich auch schon.
-
... oder oben rechts U7
-
Ich hatte es ja schon erwähnt: Der Datenbus ist zweigeteilt, und die beiden Hälften reden mit unterschiedlichen Chips. Wenn eine Hälfte, so wie Du es beobachtest, nicht ordentlich auf High gezogen werden kann, spricht es dafür, dass einer der Pufferchips auf dieser Hälfte dauerhaft selektiert ist. Schau doch mal an den Chip Selects der Latches.
-
Verstehe, alles auf einer Platine ist ja lästig, aber ein Test der Versorgungsspannungen ist auf jeden Fall notwendig. Wenn Du nicht mit dem Tastkopf im angeschalteten Gerät herumtesten möchtest, löte halt ein paar Leitungen an die entsprechenden Pins, damit Du von aussen messen kannst.
Bezüglich des Komponententesters: Wie sind denn die Erfahrungen von anderen in Bezug auf die Zuverlässigkeit dieser Dinger beim Testen großer Elkos? Ich benutze auch immer so ein Teil für grundsätzliche Tests, aber ich habe jetzt ein paar Ergebnisse mit größeren Elkos in einem Netzteil denen ich nicht so ganz vertraue.
-
Ist der Digitalteil auf einer separaten Platine? Dann würde ich dort messen statt auf dem Analogboard. Mit was für einem Meßgerät hast Du die großen Sekundärelkos geprüft?
-
Was heißt denn "komisch"? Verzerrt, krächzend und länger oder kürzer als erwartet? Oder klar und deutlich, aber lang, oder mehrere Töne?
Hört sich anfangs ein bisschen an, wie beim Spiel "Breakout" und wird dann krächzend
Ich würde zunächst die Spannungen auf dem Logicboard prüfen, dort sollten sich +5V an den TTL-Chips und -12V/+12V an den RS232-Transceiverchips (typisch MC1488/MC1489) messen lassen. Krächzende Geräusche lassen Fehler in der Versorgungsspannung, häufig durch defekte Elektrolykondensatoren - vermuten. Neben einem Test mit einem Multimeter würde ich mit dem Oszilloskop auch eventuell vorhandene Welligkeit prüfen.
-
piepst komisch beim Einschalten
Was heißt denn "komisch"? Verzerrt, krächzend und länger oder kürzer als erwartet? Oder klar und deutlich, aber lang, oder mehrere Töne?
-
Meine Platinen sind in der vergangenen Woche auch gekommen, vielen Dank noch mal an feltel!
-
Und es waren sogar zwei so EPROM Karten da drinn...
Ist wohl ne CNC Maschinen Steuerung gewesen.
Hintergrund:
Wenn nicht "Standart" müsste ich wohl die Original Backplane besorgen, was aufwendig wäre. Auf der anderen Seite stellt sich natürlich auch die Frage ob das ganze Software seitig zu "irgendwas" kompatibel ist. Dann wären wir beim Komponenten "schlachten" was irgendwie schade auf Grund der Teile aber wenigstens sehr lohnenswert wäre...
Für mich sieht das nach einem Industrierechner aus, bei dem die Software komplett im EPROM untergebracht ist. Auf der CPU-Karte #1 ist ziemlich wenig RAM, was vermutlich auch nicht notwendig ist, weil die Software im ROM ist. Die Karte #2 sieht nach einem "intelligenten" Maschinen-Interface aus (D/A-Wandler, eigene 8086-CPU + RAM). Die Karte #3 ist eine Grafikkarte und über die Speicher-Karte #4 mit EPROMs und batteriegepuffertem statischen RAM wurde sich ja schon gefreut.
Es "kann sein", dass die beiden Busse einfach nur 1:1 durchverkabelt werden müssen und man dann schon etwas auf dem Monitorausgang sieht, aber ich würde vermuten, dass die Software ohne die passende Industrieanlage keinen Nutzen hat.
=> Ausschlachten
-
Oben hat man auch nicht wirklich viel Platz wegen dieser Kunststoffstreifen. Die führen doch auch irgendwie Spannung von A nach B, ähnlich der blauen Patchleitungen?
Ja, die Stromversorgung auf dem Motherboard TI-99/4A wird über diese isolierten Metallstreifen realisiert, die man keinesfalls beschädigen darf.
-
Die CPU, die ROMS, die SRAMs und die Buffer für den 16bit-zu-8-Bit-Konverter sitzen alle auf dem gleichen Datenbus, insofern kann das Problem jeder dieser Chips sein.
Meiner Erfahrung nach sterben die ROMs häufiger. Du kannst sie mit EPROMs ersetzen, brauchst aber einen passiven Adapter. RAMs habe ich noch und kann Dir welche schicken (PN).
Du kannst das PAL-Board übrigens auf NTSC umbauen, dazu muss ein Quarz getauscht und ein paar Brücken geändert werden, und der TMS9929A muss durch den TMS9918A ersetzt werden. Ausserdem brauchst Du eine passende 180°-DIN-Buchse:
TMS9918A habe ich auch noch einige, falls Du sowas brauchst.
Vollständiger Schaltplan hier: http://www.mainbyte.com/ti99/man/ti99_tech.pdf
-
Ich vermute, das ist ein Adapter, um ein Bandlaufwerk mit DIN-Ausgang an einen Verstärker mit RCA-Buchsen anzuschließen. Belegung auf der DIN-Seite ist so:
