Ein RAM/EPROM-Simulator simuliert, wie der Name schon andeutet, einen
RAM oder EPROM in der Schaltung.
Solche Simulatoren machen sich zu Nutze, dass EPROMs typischerweise
gesteckt (nicht eingelötet) werden, da man sie zum Löschen und
Programmieren zumeist ausbauen musste.
(In-System-Programmierung war damals, um 1995, noch nicht üblich.)
Man spart sich damit bei der Programmentwicklung den umständlichen
Steck- und Löschzyklus für den EPROM für jedes Programm-Update.
Mit dem Aufkommen von Flash-Speichern ist das Problem heutzutage
weitestgehend verschwunden.
Trotzdem ist RAM beim Schreiben immer noch schneller als Flash.
Weiterhin sind die unterschiedlichen EPROM-Typen trotz unterschiedlicher
Speichergröße weitestgehend pinkompatibel, was die Konstruktion
von Programmiergeräten als auch Simulatoren erleichtert.
Schließlich wurden statische RAM-Schaltkreise pinkompatibel
zu EPROMs hergestellt.
Diese haben nur einen zusätzlichen Anschluss zum Beschreiben
(WE).
Daher ist ein RAM-Simulator eine einfach realisierbare Bonus-Funktionalität
eines EPROM-Simulators.
Dynamische RAMs können damit nicht emuliert werden.
Anschluss (zum Befüllen) am Parallelport, SPP genügt
Emuliert EPROM und sRAM, von 2 KByte (bspw. 2716) bis 512 KByte
Synchron-serielle Schnittstellen-Kommunikation via Schieberegister
Batterie-Pufferung des RAM-Inhalts, kann auch ohne PC betrieben werden
Typauswahl mittels DIP-Schalterbatterie
RAM auslesbar via Parallelport
Gesonderter RESET-Ein-/Ausgang
(rote IC-Klemme; hält den Prozessor oder Controller inaktiv
solange der PC mit der RAM-Befüllung beschäftigt ist)
Untergesetzte Stecksockel für 24-, 28- und 32-beinige IC-Emulation
5-V-Speisung vom Stecksockel mit Verpolschutzdiode
Vollständig in CMOS-Technologie
Und er hat folgende Besonderheiten bzw. Kuriositäten:
RAM-Adressenauswahl mit Zähler, nicht voreinstellbar,
dadurch nur sequenzielles Adressieren, Füllen bzw. Auslesen möglich.
Voreinstellbare höhere Adressen oder getrennt steuerbare
Zählerleitungen „höherer“ Zähler erlauben einen schnellen Zugriff
auf weiter von 0 entfernte Adressbereiche.
Ein paar statische Pegel werden mit einem etwas kuriosen 74HC173
festgelegt, Wirkungsweise noch unklar.
Womöglich als Notnagel für das o.g. Problem.
Nein! Zur Emulation eines speziellen RAMs oder EPROMs mit Bänken!
Ist aber nun wirklich undokumentiert. Ich weiß ja nicht einmal, welcher Typ da emuliert werden soll.
Die serielle Anbindung ohne ECP oder EPP macht den Emulator
unnötig langsam, insbesondere bei Verwendung von USB2LPT
oder anderer Software-Virtualisierungsschichten.
Gleiches Problem beim GALEP der gleichen Firma
Umschaltung der Sendedatenleitung (D4 .. D7)
bei nicht untereinander verbundener Masse an den Pins 18 .. 21.
Zum Betrieb von bis zu vier kaskadierten und einzeln auswählbaren Simulatoren
über den 14-poligen Pfostenstecker.
Bestückungsvariante mit 32-KByte-RAM und Auswahl mittels Steckbrücke
(Jumper).
So etwas macht man eigentlich mit einer Löt- oder Kratzbrücke,
da der RAM ja auch eingelötet ist
Gattergrab, ohne GAL, ohne Mikrocontroller.
Ermöglicht immerhin die Disassemblierung.
Parallelport-Kabel mit 2 × Steckern erforderlich. Nur 8 Datenleitungen und 1 BUSY-Leitung benutzt.
Wie beim GALEP (GALLEP III, GALEP IV), Conitec eben. Alle Lesedaten wursteln sich über ein einzelne Leitung. Nix mit Nibble-Mode.
Schreibzugriffe (W) sind damit sehr schnell realisierbar, gemessen wurden 30 kByte/s.
Den ganzen 512-KByte-RAM füllen dauert 17 Sekunden.
Bei Lesezugriffen (R) ist die Geschwindigkeit mau, gemessen wurden 1 kByte/s.
Den ganzen 512-KByte-RAM auslesen dauert über 8 Minuten.
Gesamtaufbau
Eine Alternative wäre der Betrieb an einem USB2LPT (nur High-Speed sinnvoll)
mit Gender-Changer und spezialisierter Firmware.
Die Schreib- und Lesegeschwindigkeit erreicht damit über 100 kByte/s,
viel mehr als mit einem konventionellen Parallelport möglich ist.
Da USB Full-Speed für den Datentransport ausreichend erscheint,
kann man auch eine eigenständige Mikrocontroller-Anbindung mit einem
USB-Controller entwickeln, etwa mit
AT90USB162.
Die Zugriffsmöglichkeiten zusammengefasst
(Zeiten: Parameter z = 1, Celeron 2,8 GHz):
Läuft unter Linux, Win32 und Win64, aber auch noch unter Windows 98
Eingebauter Portzugriffs-Treiber für problemlosen Portzugriff unter Win32
Benutzt externen Portzugriffs-Treiber „inpout32.dll“ oder „inpoutx64.dll“ für Portzugriff unter Win64
Läuft mit USB-Paralleldrucker-Konverter und damit via USB auch auf schnittstellen-verarmten Laptops und Notebooks
130421: Der vermeintliche Linux-Fehler wurde endlich gefunden und gelöst!
Gesonderte Unterstützung von USB2LPT: Zeit sparende Zusammenfassung von 8 IN-Transfers, macht immerhin Beschleunigungsfaktor 8
Fortschrittsanzeige und sinnhaltige Fehlermeldungen
Konsolen-Programm (wie bisher) mit gemeinsamem Quelltext; korrekte Unterstützung von Kursor- und Sondertasten
Bitweise und parallel-byteweise geschwindigkeitsoptimiertes Laden des PEPS bzw. der PEPSe
(Gleiche Daten werden niemals wiederholt ins Schieberegister geschrieben.)
Schnelles Laden von HEX- und SHX-Dateien mit lückenhaften oder absteigenden Adressen
(Eine Routine ist eingebaut, die trotzdem alle zusammenhängenden Daten auffindet.)
Mehrere Dateien ladbar, einzelbyteweise per Kommandozeile überschreibbar mit Option -i
Volle Unterstützung für bis zu 4 verkettet geschaltete PEPSe (aber mangels Hardware ungetestet), auch 3 PEPSe für einen 24-Bit-Bus sind kein Problem
Stichproben-Verifizierung des Speicherinhalts als Standard (schnell und hinreichend sicher)
deutsch und englisch — auch unter Linux
Volle Unicode-Unterstützung für Funktion mit bspw. chinesischen Dateinamen
natives 32- und 64-Bit-Programm (AMD64 versteht sich)
Winzige Exe-Größe (ca. 30 kByte) ohne eingebaute oder extra notwendige Laufzeitbibliothek, läuft prompt von jedem USB-Stick oder jeder Diskette
Was noch fehlt:
Ausgiebiger Test (Ich selbst brauche das PEPS ja gar nicht!)
Natives Firmware-Schnipsel für USB2LPT (nur für High-Speed sinnvoll)
für Beschleunigungsfaktor 1000 (ja, viel schneller als ein Parallelport!)
