Beiträge von t.schlumpf

Hallo Frank

Ja, hast Du. Der VK1 (der mit dem Z80) läuft auch einwandfrei. Den Ersatzkontroller hab ich nur mal testen wollen. Leider gibt die Doku keine Auskunft darüber, welcher Controller für welche Tastatur/CPM-Version benötigt wird.

Zum VK1 hab ich (noch) keine Dokumentation gefunden. Weisst Du eine Quelle? Ich hätte gerne Schema und Beschreibung.

lg Tony

Hallo fishermansfriendtoo und fanhistorie. Besten Dank für Eure Antworten. Inzwischen habe ich die Testanleitung etwas genauer durchgelesen (hätte ich schon früher tun sollen...). Derzufolge muss es ein Kompatibilitätsprobem zwischen Tastatur, Adapter und Betriebssystem sein.

Ich werde weitere Versuche durchführen. Vermutlich ist es aber so, dass der oben gezeigte Adapter nur die Standard-Tastatur unterstützt, ich habe aber eine Textverarbeitungs-Tastatur.

lg Tony

Hallo miteinander!

Kürzlich habe ich den ITT3030 von fhw72 erstanden, läuft eigentlich einwandfrei. Es war auch, nebst der eingebauten Grafikkarte, der Original

Video/Keyboard Controller dabei. Ich wollte den mal in Betrieb nehmen, doch der verhielt sich reichlich merkwürdig. Nach dem Booten wird ununterbrochen die zuletzt eingegebene Taste ('b') abgezeigt, bis der Buffer voll ist, dann von neuem. Beim Drücken einer anderen Taste wird diese endlos angezeigt. Keine Möglichkeit, ein Kommando einzugeben. Der Strobe-Input an Pin1 des Controllers ist ruhig (low), solange keine Taste gedrückt ist. Die Zeichen erscheinen auch, wenn die Tastatur ausgesteckt wird. Das System läuft mit der Grafikkarte ok, ich vermute deshalb den Fehler im Original-Keyboard Controller.

Nun meine Frage: Hat jemand so eine Karte, ev. auch leihweise, übrig, damit ich den Fehler durch Vergleichsmessungen besser einkreisen könnte?

Eine weitere Frage: Hat es jemand geschafft, den Editor von dBaseII auf dem ITT zu konfigurieren? Ich habe festgestellt, dass bei der Curosr-Positionierung für den Zeilen-Offset 33 anstelle der üblichen 32 verwendet werden muss, damit die Positionierung funktioniert. Das klappt bestens bei Turbo-Pascal und dem DevPac80 Editor, hier kann der Offset für Zeile und Spalte separat definiert werden, nicht so bei dBase. Gibt's hier eine Lösung?

Danke schon mal...

Tony

Hallo funkenzupfer, die hab' ich aus dem Netz, nicht nachbearbeitet.

Die Dateien sind beinahe 10MB, darum der Link

Ich hoffe das passt so.

lg Tony

Holger, danke für den Hinweis, habs korrigiert.

... und vom Marktplatz zu mir ...

Ich hab den ITT von fhw72 gekauft, kam in eiwandfreiem Zustand an. Erst jetzt habe ich ihn in Betrieb genommen, läuft alles einwandfei, ausser den Floppies. Es waren 4(!) Stück dabei, 1x48TPI, 3x48TPI (so waren sie jedenfalls angeschrieben, es stellte sich aber heraus, dass es von jeder Sorte zwei sind). Das eine 48TPI lief (fast) auf Anhieb, bootet CP/M 2.2 5.33T ST nach z.T mehrmaligen Versuchen. Der Spindelmotor lief zu schnell, nach Korrektur mit Hilfe der Stroboskopscheibe wars dann ok. Die anderen liefen auch, aber mit sehr nervigem Geklacke, der Head-Load Magnet zieht und fällt mit jedem Selekt des Laufwerks, und der ITT de/selektiert innerhalb eines Zugriffs viele Male, vermutlich während der Verarbeitung der gelesenen Daten (eher ungwöhnlich). Zudem stellte der Sindelmotor, einmal gestartet, nie mehr ab, solange die Diskette im Laufwerk war.

Der Vergleich des ruhigen mit den klappernden zeigte etliche Unteschiede. Nach erfolgtem Patch

Die kalte Löstelle ist inzwischen bereinigt...

funktionierten zwei der drei wie gewünscht, das dritte klapperte frisch fröhlich weiter. Verantwortlich dafür war der Treiber 7438 in der Selbst-Halteschaltung des Load-Magneten, der Ausgang blieb immer high (im Schema grün).

Wieder ein Schätzchen vor der Müllhalde gerettet. Jetzt gehts weiter mit dem Testen der verschiedenen Interfacekarten,..

In dem ITT ist ja auch eine Grafikkarte (diese hier) eingebaut, sie funktioniert bestens. Nur habe ich keine Dokumentation dazu finden können. Hat jemand eine Anleitung und/oder technische Infos dazu?

Hallo tomtom

Du liegst richtig, es ist die Z80-Karte. Wenn diese fehlt, dann läufts. Es ist ein Clone, ist aber kompatibel mit der von Micosoft.

Ich habe ja auch noch die Apple2-IO-RPI Karte drin. Diese läuft, nachdem Indentify in Betieb war, nicht mehr. Die erste Adresse im EEPROM ($C500, Slot5) wird mit null überschrieben, ein Booten vom RPI ist nicht mehr möglich. Ein C500:E0 im Monitor schafft Abhilfe.

lg Tony

Hallo tomtom

Danke für die Antwort.

Der Fehler tritt immer auf, die Adresse im Monitor ist jedoch nicht immer gleich. Je nach Art des Fehlers wird die CPU noch unkontrollierte Instruktionen ausführen, bis dann mal ein BRK auftritt, und das kann irgendwo sein. Hab ich schon viel erlebt, z.B. bei uninitialisierten Pointern...

Das mit den Karten werd ich mal probieren, obwohl es ja Sinn und Zweck des Programms ist, eben diese Karten zu erkennen.

Ich melde mich dann wieder.

Tony

Hallo in die Runde

Ich hab mir das Programm gekauft und übersehen, dass es für Mitglieder gratis wäre. Ist ja nicht ein Riesenbetrag.

Nur, das Programm meldet sich bei mir so:

Es ist ein 64k AppleII+ mit RAM-Card, Printer Interface, Apple SSC, Videx 80-Zeichen Clone, Z80 Karte, Apple2-IO-RPI von JPT und DiskII Controller. Alles andere (DOS/ProDOS/Apple-Pascal/CP/M) läuft einwandfrei, auch die Apple-Dealer-Diagnostik gibt keine Fehler aus. Deshalb nehme ich an, dass es kein Hardware-Problem ist.

Hat jemand eine Lösung dafür?

Danke schon mal

Tony

Jan, danke, gute Idee.

Ich versuche aber weiterhin ein 27C64 aufzutreiben, Wenn dies dann funktioniert, ist das Problem gelöst.

Zu Deiner Frage: Ja, die HELLOs und STARTUPs, läuft gut, ausser CP/M wird mit dem Netzschalter beendet...

 10  REM  =============== STARTUP
 12  REM  PRODOS SYSTEM WORK
 14  REM  =======================
 19 :
 20  HOME 
 22  PRINT "PRODOS BASIC 1.6"
 29 :
 30  REM  ----- FIX IO-RPI EEPROM
 32  REM  AFTER CP/M HAS BEEN RUN
 34  REM  THE IO-RPI EEPROM IS
 36  REM  CORRUPT (C500=02 VS E0)
 38  REM  -----------------------
 40  LET EA=50432 : REM $C500
 42  LET ED=224   : REM $E0
 49 :
 50  LET EP = PEEK(EA)
 52  IF (EP = ED) THEN 90 
 54  POKE EA,ED
 59 :
 60  FOR CT = 0 TO 200
 62 :: EP = PEEK(EA)
 64 :: IF (EP = ED) THEN CT=200
 66  NEXT CT
 69 :
 70  IF (CT > 200) THEN 90
 72  PRINT "RPI EEPROM TIMEOUT"
 79 :
 90  NEW 
 99  REM  =========== EOF STARTUP

lg Tony

Hallo Jan

Die Idee mit dem Wegbiegen des /WR Pins hatte ich auch schon. /WR muss dann aber auf +5V liegen, wäre mit einem Widerstand lösbar. Ich habe aber nicht gerne so Bastleien, zudem müsste für einem Update der Originalzustand wieder hergestellt werden.

Ich habs auch mit einem EPROM 2764 probiert, läuft, aber unzuverlässig. Warscheinlich mit 200nS Zugriffszeit zu langsam, ein 27C64 konnte ich (noch) nicht auftreiben, dieses hätte 150nS.

Im Moment hab ich es so gelöst, dass BOOT.COM vom CP/M 0E0H nach 0C500H (Slot5) schreibt, bevor der Bootvorgang ausgelöst wird. Zudem tun die STARTUPs auf den DOS3.3 und ProDOS Disketten dasselbe, sofern nicht bereits 0E0H dort steht (um Scheibzylen möglichst gering zu halten).

Tony

Hallo Apple-Freaks

Ein Problem(chen) mit dem Apple2-IO-Rpi im AppleII+:

Nach dem Booten von CP/M wird das erste Byte des Apple2-IO-Rpi EEPROM überschrieben, ProDos vom RPi kann danach nicht mehr gestartet werden. PR#x hängt.

Der Apple2-IO-Rpi ist in Slot 5

Original: C500: E0

Nach Booten von CP/M: C500: 02

Nach einem Firmware-Update oder im Monitor C500:E0 funktionierts wieder.

Kann das EEPROM schreibgeschützt werden? Wenn ja, wie?

Besten Dank schon mal

Tony

Ein Hallo in die Runde

Ich hab ein Apple2-IO-Rpi von JPT gekauft, läuft prima, auch auf dem AppleII+! Danke für Dein grossartiges Projekt, Terence!

Ein kleiner Wehrmutstropfen, die Shell lässt sich mit nur Grossbuchstaben schlecht bzw. gar nicht bedienen.

Obwohl ich ein absoluter Neuling in Sachen 6502 Assembler bin (bis jetzt nur Z80), habe ich versucht, den Code des Shell-Programms zu verstehen und so zu ändern, dass die Shell auch auf dem II+ bedienbar wird. Das Resultat ist im Anhang.

So meldet sich Shell2P auf dem 40-Zeichen Bilschirm

Nach dem Umschalten auf 80 Zeichen

Mit CTRL-A lässt sich, wie von CP/M und DOS gewohnt, zwischen Gross- und Kleinschrift umschalten.

Noch eine Frage zum ProDos-Utility: Ich hab es nicht geschafft, eine Datei in einem Image zu löschen. Das Kommando

prodosutil -d <imagedatei> -c rm -i <dateiname> -p /

beendet ohne Fehlermeldung, die Datei wird jedoch nicht gelöscht. Das gleiche passiert, wenn eine nicht existierende Datei mit -i angegeben wird. Hinzufügen funktioniert, sofern die gleiche Datei nicht schon vorhanden ist. Mache ich hier etwas falsch?

Grüsse aus der Schweiz

Tony

Eine tolle Sache, CP/M auf dem Apple II+

Der Dateitransfer mit ADT unter DOS funktioniert zwar einwandfrei, es ist allerdings etwas mühsam, für jede Datei ein ganzes Diskimage zu transferieren. Im Manual der Z80-Softcard ist ein Programm abgedruckt, das den Dateitransfer via serielle Schnittstelle zu einem anderen CP/M System ermöglicht. Leider vermiss ich bei diesem Programm eine Abbruchmöglichkeit, auch das Dateiende wird nicht erkannt. Es muss immer manuell beendet werden...

Ich habe die Programme UPLOAD und DOWNLOAD so modifiziert, dass diese Mängel behoben sind. Im Anhang sind die Sourcen für Apple CP/M und Kaypro II, jeweils Up- und Download. Das AppleII Programm unterstützt allerdings nur die SuperSerialCard.

Die Sourcen sind im HiSoft DevPac80 Format, sollten aber mit M80/L80 kompatibel sein.

Viel Spass damit!

Tony

Ein Hallo in die Runde

Das mit den 2V am Ausgang des Netzteils hab ich auch schon gesehen. Bei mir trat es auf, wenn am 5V Ausgang keine Last vorhanden war. Der interne Regelkreis funktioniert dann nicht. Vielleicht mal den 5V Pfad prüfen. Sind Stecker und Buchse in Ordnung?

Betreffend RAM Test, da habe ich im Netz eine Dealer-Diskette gefunden, mit der alle Komponenten des AppleII+ getestet werden können. Hat mir weitergeholfen, als mein Baby so alle paar Minuten mal abstürzte und als das Bank-Switching der 16k Karte nicht funktionierte. Das Disk-Image 011-DIAG-UTL.ZIP ist angehängt.

Und jetzt noch eine Frage an Schroettel: Ich habe die gleiche 16k RAM Karte, nur leider keine Unterlagen dazu. Hast Du ein Schema? Uebrigens hat mir Deine Foto der Karte geholfen, ein IC zu identifizieren, dessen Bezeichnung beim meiner Karte nicht mehr lesbar ist. Danke vielmals!

MfG Tony

Neuer Status: Das Ding läuft

Ich hatte die Traces vom und zum IC9 verfogt, um herauszufinden, welches Ein- und Augänge sind. Die ersten 10 Pins deuteten auf einen 7400 hin, doch Pin 11, ein Ausgang des 7400, führt auf einen Ausgang eines 7411, kann also kein 7400 sein.

Nach weiteren Recherchen im Web habe ich eine etwas bessere Foto des Prints gefunden, auf der sich erahnen liess, dass es DOCH ein 7400 sein könnte.

Also, Chip wechseln, testen, läuft!

Möglicherweise ist der Chip wegen der gegeneinander treibenden Ausgänge kaputt gegangen und wird es vielleicht wieder tun...

Auf jeden Fall laufen jetzt ProDos, LISA und PIE Editor im 64k Modus, vermutlich auch Pascal, habs noch nicht getestet.

Nochmals danke für Eure Tips!

Tony

Erst mal danke für Eure Antworten.

@cybernesto: Ich habe verschiedene Versionen probiert, unter anderem auch die 2.4.2, keine funktioniert, ich lande im Monitor...

Ich habe die Karte inzwischen etwas genauer untersucht. Es sind Mostek 4115 RAM Chips drauf, die sind 8kx1. Nach dem Wechsel auf 4116 ist das Verhalten allerdings immer noch gleich.

Der Tip von deleted_06_24 scheint zuzutreffen. Ich habe das Bankswitching mit kleinen Assembler-Programmen zu testen versucht. Nach dem Schreiben von verschiedenen Werten an Adresse D000 (55 in Bank1, AA in Bank2) erhalte ich beim Lesen aus beiden Banks immer den zuletzt geschriebenen Wert. Demzufolge ist die Bankumschaltung feherhaft, oder die Karte ist nicht dafür vorgesehen. Eine Fehlersuche ohne Schema gestaltet sich allerdings schwierig...

Ich habe auch versucht, verschiedene ICs zu wechseln, hat aber nichts gebracht. Dummerweise ist bei zwei ICs die Bezeichnung nicht mehr lesbar, es sind dies IC3 und IC9. IC9 könnte den Fehler verursachen, das Signal A6, welches auch für das Bankswitching gebraucht wird, führt auf dieses IC...

Falls jemand eine Foto oder gar ein Schema hätte, wäre schon super!!

Tony

Hallo aus der Schweiz

In meinem Apple ][ Plus steckt diese 16k RAM Karte

CP/M 56 läuft damit einwandfrei, auch die Dealer-Diagnostik meldet keine defekten Chips. Das Integer-Basic lässt sich ebenfalls auf die Karte laden und funktioniert. Es hakt allerding bei verschiedenen anderen Programmen, so stürzen z.B. Apple-Pascal und ProDos wahrend des Boot-Vorgangs ab, beim PIE Writer funktioniert der Editor, FORMAT hingegen startet erst gar nicht. Meine Vermutung ist, dass diese Programme das Monitor-ROM, das auf der Original-Language-Card verbaut ist, benötigen. Kann das jemand bestätigen? (Ich möchte keinen Fehler suchen, wo keiner ist)

Ich habe zu dieser Karte keine Unterlagen (Manual, Schema) finden können. Einzig diese Broschüre

Hat jemand Unterlagen zu dieser Karte?

Schon mal vielen Dank!

Tony

Hallo hubidrei

Hat's denn mal eine 7-Bit Karte gegeben? Hab ich noch nie gesehen...

Ich will eigentlich nur Listings aus dem Monitor und Basic auf Papier bringen, Grafik- und Textverarbeitungsprogramme habe ich keine (brauche ich auch nicht). Wie oben schon erwähnt, mit CP/M funktionierts.

Ich habe den Vorschlag von deleted_06_24 probiert. Funktioniert fast...

Mit 7N2 hat das Bit7 die falsche Logik, es kommt immer eine 1 an. Das kann mit fixem Paritätsbit anstelle eines der Stoppbits umgangen werden. Der Initstring ist demzufolge '7M1', wobei M für MARK steht.

Nach Initialisierung der SSC mit

PR#2:IN#2    (die SSC ist in Slot 2)
<CTRL-A>12B  (4800 BpS)
<CTRL-A>1D   (7 Databits, 1 Stopbit)
<CTRL-A>5P   (Parität MARK)

läufts wie geschmiert. Bei höheren Bitraten als 4800 kommt der Apple allerdings ins Stottern, weil keine Interrupts verwendet werden. Aber für up-und download von Sourcen rechts auch so. Möglicherweise gehts nach Ausschalten des lokalen Echo (CTRL-A E D) etwas schneller, hab ich aber noch nicht gestestet.

Könnte funktionieren, gute Idee. Werde ich probieren.

Ist doch kein Problem...

Das gleiche Verhalten habe ich inzwischen auch bei serieller Kommunikation festgestellt. Wenn die SSC aktiv ist (PR#x) sendet diese auch immer mit Bit7 gesetzt, empfangen hingegen funktioniert korrekt.

Es ist offensichtlich so, dass die Apple-Firmware für alle Ausgaben das Bit 7 setzt, warum auch immer. In der technischen Dokumentation habe ich nichts darüber gefunden.

Lg Tony

Salü Oliver, danke für Deine Antwort!

Deine Aussage, die standard Ausgaben haben Bit7 gesetzt, erklärt mir das Verhalten. Zu Deinem Listing-Auszug:

Der Code (AND 7F) wird nur erreicht, wenn das vorherige Zeichen ein ESC (standard CTRL-I) war, danach wird das Kommando geparst und ausgewertet. Im Normalfall (BPL ESCTEST springt) rutscht Bit 7 bis zum Drucker durch.

Uebrigens: unter Apple-CP/M tritt das Problem nicht auf.

Das einfachste wird sein, Bit 7 im Druckerkabel zu unterbrechen oder schaltbar auszuführen. Oder gibt's einen Softswitch, mit dem sich das steuern lässt?

Liebe Grüsse

Tony

Hallo Apple-Freaks

Ich versuche momentan, meinen Apple ][ Plus widerzubeleben. Bisher recht erfolgreich, der Rifa-Knallfrosch ist ausgetauscht. Beim Versuch zu drucken habe ich nur Müll bekommen. Der Epson-FX80 lässt sich ja auf HEX-Augabe schalten, auf diese Weise habe ich festgestellt, dass Bit7 immer gesetzt ist, was natürlich nichts Vernünftiges ergibt.

Eine Direkt-Ausgabe mittels POKEs auf Adresse 0xC890 (Karte ist in Slot 1) funktioniert einwandfrei, scheint also kein Hardwarefehler zu sein.

Das Unterbrechen von DP7 durch Rausbiegen des IC-Pins15 brachte den gewünschten Erfolg.

Ich habe daraufhin den Code im PROM der Printerkarte analysiert, aber nichts gefunden, was Bit 7 setzen würde. Folglich muss dieses Bit bereits im Betriebssytem gesetzt werden. Das Verhalten ist im Monitor wie auch im Basic gleich.

Hat hier jemand Erfahrung? Ist dieses Verhalten systemdedingt oder steht mir schlicht irgendwer auf dem Schlauch???

Vielen Dank schon mal

Tony

@zitruskeks: Ja, habe ich. Die Wechselspannung am Elko ist nur etwa 1Vss, sollte kein Problem für den Regler sein. Es bleibt nur noch die Temperaturversion.

lg Tony

Mein Sony MSX zeigte nach etwa 30 Minuten Betriebszeit immer stärker werdende Brummstreifen auf dem Bildschirm, funktionierte aber sonst einwandfrei. Scheint ein Wärmeproblem zu sein, also mal den Kältespray zücken.

Ein kleiner Spritzer auf den 12V Regler (links), und das Bild ist wieder einwandfrei. Also, den Regler tauschen. Nur, woher nehmen? Keiner der mir bekannten Distris hat ihn im Angebot, und ich möchte das Gerät möglichst im Originalzustand behalten, also nicht irgend was anderes einbauen.

Eine Möglickeit wäre, die Eingansspannung (jetzt 19.4V) und damit die Verlustleisung des Reglers zu reduzieren. Ein Blick ins Schema zeigt, dass der Netztrafo einen Anschluss für 240V hat. Das könnte doch schon mal was bringen, zumal die Netzspannung so um die 235V beträgt.

Nach dieser Aenderung hat sich die Regler-Eingangsspannung um 2V reduziert und es hat sich ausgebrummt...

Tony

Mathias, das ist super!! Vielen Dank!

Tony

Zitat von DerSatelitt

t.schlumpf Hi, freut mich total einen MSX zu sehen...

kennst Du dieses hier ? https://github.com/rolandvans/msx_softserial

Vielleicht siehst dort im code etwas sinnvolles, was Dir hilft.

Ich muss noch suchen, hab noch einen Link irgendwo gehabt .... vielleicht finde ich diesen auch noch.

Hallo Satelitt

Danke für den Link, ist tatsächlich hilfreich.

Tony

Beim meinem Sony-MSX sind beide Slots belegt, trotzdem hätte ich gerne serielle Kommunikation mit der Aussenwelt. Darum bin ich dran, den Joystickport für diesen Zweck zu missbrauchen. Das ganze soll im EPROM mit ZEN und MONS sowie als BLOADbare Version entstehen.

Hier beim Abgleichen der Bit-Zeiten für 2400 bps.

Ich habe eine Frage, vielleicht ist ja jemand von Euch schon mal drübergestolpert. Für die seriellen Signale verwende ich die Parallel-Ports des PSG (Sound-Chip). Leider wird der Setup des Chips bei jeder Rückkehr ins Betriebssystem neu initialisiert, selbst bei augeschaltetem Tastatur-Click. Es ist mir nicht möglich, Portzugriffe mit dem Debugger nachzuvollziehen, es werden immer die Default-Werte zurückgelesen und die Ausgänge werden ebenfalls auf default gesetzt. Wenn keine BIOS-Calls ausgeführt werden, funktionierts wie erwartet.

Hat jemand eine Idee?

Danke

Tony

Auf dem Sharp MZ-80K habe ich den ZEN Assembler kennengelernt. Komfortabel für kleine Projekte, Editor, Assembler und Debugger in einem Programm. Beim Durchstöbern verschiedener MSX Webseiten habe ZEN auch für den MSX gefunden. Also, EPROM brennen und loslegen...

Denkste...

Editor und Assembler funktionieren, aber was nützts, wenn man nichts speichern kann? Nicht mal das Motor-Relais schaltet. Weitersuchen, vielleicht gibt´s eine andere Version. Und, tatsächlich, eine Disk-Version gefunden. Bei näherem Hinschauen stellt sich heraus, es ist ausser ein paar Bits Unterschied die gleiche Version. Diese schaltet aber immerhin das Motor-Relais (die Disk-Version!). Testprogämmchen schreiben, speichern, laden.

Denkste...

Laden unmöglich, es escheint nur Müll. Timing Problem? Um sicher zu gehen, habe ich aus Basic und ZEN Dateien mit gleichem Inhalt (lauter 0x55s) gespeichert und die Ausgangssignale verglichen. Dabei habe ich festgestellt, dass die Pausen zwischen den einzelnen Bytes unterschiedlich sind, bei ZEN ca 100uS länger. Gemäss dem MSX Technical Manual muss aber das Timing des BIOS eingehalten werden.

Also, die verantwortlichen Routinen suchen und analysieren. Dabei hilft das Source-Listing des MZ-80K-ZEN (für MSX habe ich keins gefunden). Dabei habe ich gesehen, dass ZEN nach jedem Byte die Checksumme für das Verify aktualisiert. Dies braucht Zeit. Das würde doch auch ohne Checksumme funktionieren. Und, siehe da, ZEN und Basic können die so geschriebenen Daten problemlos lesen.

Ist noch das Problem mit dem Verify. Ich habe die Verify-Routinen für Text- und Binärdateien so geändert, dass ein direkter Speichervergleich während dem Lesen vom Band durchgeführt wird. Dies bringt noch den Vorteil, dass sofort nach Erkennen eines Fehlers abgebrochen wird, nicht erst nach dem Lesen bis zum Dateiende.

ZEN akzeptiert zur Kommando-Eingabe nur Grossbuchstaben. Deshalb wird beim Start CAPS-LOCK aktiviert. Die beiden Kommandi 'd' (disassemble) und 'u' (unscramble) wurden auf 'J' und 'Y' (die einzigen noch verfügbaren Zeichen) gelegt.

Der Debugger des ZEN ist rudimentär verglichen mit MONS (Teil von GEN80 von HiSoft). Diesen gibts als BLOADbare Version für Basic. MONS würde sogar noch ins EPROM passen. Da habe ich versucht, dies zu implementieren.

Das Starten von MONS in ZEN geschieht durch einen Sprung ins EPROM, die Befehlssequenz dazu ist auf Funktionstaste F1 gelegt.

Der Init-Code im EPROM kopiert den MONS Code ins RAM und führt ihn aus. Nach Beenden von MONS wird wieder ZEN geladen und gestartet.

MONS überschreibt jedoch den Textbereich von ZEN, der Source müsste nach jedem Umschalten neu geladen werden. Um dies zu verhindern, erfolgt bei jedem Wechsel von ZEN zu MONS ein Backup des benutzten Textbuffers in den ungenutzten Bereich 8000 bis 9FFF (leider nur diese 8k, mehr ist nicht verfügbar). Nach Beenden von MONS wird der Text wieder zurückgeladen.

ZEN und MONS...

im gleichen EPROM

Im Anhang sind das EPROM-Image, die Sourcen für den Init-Code sowie die der ZEN-Patches im ZEN-Format (was sonst??)

Tony