Beiträge von HofMar

Hallo Helmut,

das sieht jetzt richtig gut aus. Dann war mein Veto nicht so verkehrt.

Ich fange mal mit den drei Gleichungen für die 139er an:

 SEL0 =   /A * /B *    E
/SEL0 = /(/A * /B * /(/E))

 SEL2 =   /A *  B *    E
/SEL2 = /(/A *  B * /(/E))

 SEL3 =    A *  B *    E
/SEL3 = /( A *  B * /(/E))

Dann ersetzen wir mal fleissig:

/CS_ROM = /(A                                        *  B      * /(/E   ))
/CS_ROM = /(/SEL2                                    *  /NOROM * /(/SELE))
/CS_ROM = /(/(/A                    *  B    * /(/E)) *  /NOROM * /(/SELE))
/CS_ROM = /(/(SEL0                  *  BA11 * / 0  ) *  /NOROM * /(/SELE))
/CS_ROM = /(/((/A   * /B   * /(/E)) *  BA11        ) *  /NOROM * /(/SELE))
/CS_ROM = /(/((/BA8 * /BA9 * /BA10) *  BA11        ) *  /NOROM * /(/SELE))

Und nun wird vereinfacht:

/CS_ROM = /(/( /BA8 * /BA9 * /BA10  *  BA11        ) *  /NOROM * /(/SELE))
 CS_ROM =   /( /BA8 * /BA9 * /BA10  *  BA11        ) *  /NOROM *    SELE

Die letzte Gleichung lauetet sprachlich: DasROM ist selektiert, wenn nicht die Adresse x8xx anliegt, kein NOROM gewünscht wird, aber der Bereich E ausgewählt wird. Perfekt, so sollte es sein.

Mir geht es manchmal genauso. Ich kann sowohl mit Bausteinen (Gatter) als auch mit Gleichungen "denken". Mal überwiegt das eine, mal das andere. Gut ist es, wenn man das in einander überführt und es weiterhin stimmig bleibt.

Nette Idee übrigens das 139 als kleine PLA zu nehmen. Entsprechend der Wahl des Ausgangs (0, 1, 2 oder 3) negiert man zwei der Eingänge dieses "NAND"s mit drei Eingängen.

Gruß Martin

Hallo joshy,

Du hast natürlich recht. Und ich versuche es mal ein wenig herzuleiten. Vielleicht kann uns CBM_Ba doch noch folgen.

Neben den Adressbussignalen BA0 bis BA15 (16 Adressbit für 64 KB) gibt es schon das /SELE-Signal, was low-aktiv ist, wenn eine Adresse $EXXX anliegt.

SELE = BA15 * BA14 * BA13 * /BA12

oder wenn wir beide Seiten negieren:

/SELE = /(BA15 * BA14 * BA13 * /BA12)

Um ein Signal zu erzeugen, daß bei der Adresse $X8XX reagiert, nutzen wir BA8 bis BA11:

X8XX = BA11 * /BA10 * /BA9 * /BA8

Jetzt kommt mein Fehler. Das ROM soll selektiert sein, wenn zwar die Adresse $EXXX (SELE) anliegt, aber nicht der IO-Bereich adressiert wird (X8XX):

 CS_ROM = SELE * /X8XX

Da das gesuchte Chip-Select Signal low-aktiv ist, negieren wir wieder beide Seiten:

/CS_ROM = /(SELE * /X8XX)

Nun kommt ein wenig boolsche Algebra. Eine Negierung am Ausgang kann zum Eingang geändert werden, wenn aus dem UND ein ODER wird und umgekehrt:

/CS_ROM = /SELE + X8XX

Das hatte Joshy schon unter #89 aufgeführt. Nun kann ich aber weiter, wie bei #88 ersetzen:

/CS_ROM = /SELE + (BA11 * /BA10 * /BA9 * /BA8)

Und wieder sehe ich das Problem, dies in ein 138 oder 139 zu bekommen. Beides sind Dekoder und haben nur Produktterme. Hier einmal der 138 mit den Eingänge C4, B2 und A1 sowie dem high-aktiven Enable-Eingang E3, den zwei low-aktiven Enable-Eingängen /E1 und /E2 und den low-aktiven Ausgängen /OUT_n:

/OUT_0 = /(/C4 * /B2 * /A1 * E3 * /(/E2) * /(/E1))
/OUT_1 = /(/C4 * /B2 *  A1 * E3 * /(/E2) * /(/E1))
/OUT_2 = /(/C4 *  B2 * /A1 * E3 * /(/E2) * /(/E1))
/OUT_3 = /(/C4 *  B2 *  A1 * E3 * /(/E2) * /(/E1))
/OUT_4 = /( C4 * /B2 * /A1 * E3 * /(/E2) * /(/E1))
/OUT_5 = /( C4 * /B2 *  A1 * E3 * /(/E2) * /(/E1))
/OUT_6 = /( C4 *  B2 * /A1 * E3 * /(/E2) * /(/E1))
/OUT_7 = /( C4 *  B2 *  A1 * E3 * /(/E2) * /(/E1))

Oder was mache ich jetzt falsch?

Gruß Martin

Hallo Helmut,

Zitat von axorp

so nun wohl die endgültigste version. wenn mir nicht noch etwas einfällt

nun wird kein x8xx signal mehr vom board extra benötigt.
es wird selbst erzeugt, von den schon vorhandenen signalen. am rom sockel.

mit zwei 74ls139 oder mit einem 74ls138 und einem 74ls00

Ich befürchte, Du hast da einen Fehler drin. Das Ausgangssignal /CS ROM + EPROM ist aktiv (low), wenn die Adressen $E800 bis $E8FF anliegen. Das Signal X8XX ist aber ein Ausschluß. Daher fehlt eine Invertierung an diesem Signal. Dann läßt sich die Gleichung aber nicht so gut vereinfachen:

X8XX    =           /BA8 * /BA9 * /BA10 *  BA11
/CS_ROM = /SELE * /X8XX
/CS_ROM = /SELE * /(/BA8 * /BA9 * /BA10 *  BA11)
/CS_ROM = /SELE *  ( BA8 +  BA9 +  BA10 + /BA11)

* = log. UND, + = log. ODER, / = Invertierung

MIt einem 138 oder 139 bekommt man das nach meiner Auffassung nicht mehr hin. Von dem weiteren Signal /NOROM mal ganz abgesehen.

Oder habe ich da einen Gedankenfehler?

Gruß Martin

Das sollte das toolkit3.zip (BASIC Programmer's Toolkit von Palo Alto ICs) sein. Hier natürlich in der Version für BASIC 3.0. Am Ende müßte "(C) 1979 PAICS" stehen. Das war eine damals gängige BASIC-Erweiterung und ich meine sogar mind. eine der Ersten dieser Art.

.:  B7E0 29 20 31 39 37 39 20 50  
.:  B7E8 41 49 43 53 0D 00 41 49
.:  B7F0 43 53 0D 00 CB 00 00 00
.:  B7F8 00 00 00 00 00 00 00 00

Beim Speichern gab ich den Bereich mit B000,C000 (Startadresse,Endadresse+1) an. Da es vermutlich ein 2716 mit 2 KB ist, sollte auch B000,B800 ausreichen.

Nun, mit dem Auslesen können wir das verbaute Erweiterungs-ROM identifizieren. Außerdem hilft es uns evtl. verlustige ROM-Images aufzuspüren.

Du kannst das ROM entweder in einem EPROM-Programmiergerät (es scheint ein 2716 mit 2 KB zu sein) auslesen, oder auch mittels dem TIM (z.B. über SYS 1024 aufrufbar) im Gerät selbst auf z.B. eine Diskette speichern:

.S "Dateiname",08,B000,C000

Da hier mit 901465-01 ($C), 901465-02 ($D), 901447-24 ($E) und 901465-03 ($F) das BASIC 3.0 zum Einsatz kam, muß der Bereich $B bereits ein Erweiterungs-ROM sein. Könntest Du das EPROM mal auslesen und verfügbar machen?

Nun die Tastatur wird im Interrupt abgefragt. Dieser wird mit 50 oder 60 Hz bedient. Als Quelle wird das vertikale Synchronisationssignal des Monitor verwendet. Ich könnte da schon einen Zusammenhang erkennen.

Um dem besser nachzugehen, wäre das verbaute Board wichtig. Der periodische Interrupt wird über Pin 18 (CB1) einer PIA ausgelöst. Dieses Signal liegt auch unter Umständen direkt am Videostecker zum Monitor an.

Erzeugt wird das Signal im CRTC am Pin 40 und durchläuft dann unter Umständen auch ein 7486, wo es mittels eines Jumpers invertiert werden kann.

Es ist auch möglich, daß der angeschlossene Monitor durch z.B. einen Kurzschluß dieses Signal stört.

Ich finde, die anfängliche Frage stellt sich nicht wirklich. Ein Vergleich mit auf eBay erzielten Preise ist in meinen Augen auch nicht zielführend.

Wir reden hier nicht von Handelsware, für die es einen richtigen Markt gibt. Wir reden hier häufig von Unikaten, deren Zustände selten vergleichbar sind. Nur weil es auf eBay einmal eine Nachfrage gab, ein bestimmter Preis gehandelt wurde, heißt das nicht zwangsweise, daß ein ähnlicher Artikel so viel wert wäre. Die Nachfrage wurde bereits durch den Kauf gestillt, der Markt hat sich also geändert. Alle weiteren Bieter waren nicht gewillt diesen Preis zu zahlen.

Das heißt nun nicht, daß neue Nachfragen entstehen können. Aber auch hier gilt es, erst einmal Käufer und Verkäufer zusammen zu bringen. Dann könnte über den Preis verhandelt werden.

Nur bei einer Gewinnoptimierung würde eine Marktanalyse hilfreich sein. Dann sind wir wieder bei Handelsware und nicht bei dem Ziel dieses Vereins.

Zitat von Toast_r

Hier etwas besser zu erkennen

Das ist ein perfektes Bild, danke. Da sollte die Brücken (0-Ohm Widerstände) gut zu erkennen sein.

Zitat von Scientist

Adapter muss man ja sowieso für den ROM(!?) bauen

Solange das Editor-ROM nur 2 KB umfaßt (z.B. 901474-04), ist kein Adapter nötig. Ein 2716 paßt hier perfekt. Ob das 2816 (EEPROM) direkt paßt weiß ich nicht, sieht aber gut aus. Ich habe es aber nie ausprobiert. Selbst bei 4 KB benötigt man beim 2532 kein Adapter. Nur wenn man die gängigeren 2732 verwenden möchte ist ein Adapter nötig.

Schaue doch mal in den Schaltplan des Netzteils vom Board. Dort findest Du den J8, der sowohl für die Speisung mit Trafo (und bestückten Dioden, Spannungsregler und Kondensator) an den Pins 1 (AC), 2 (GND) und 3 (AC) genutzt werden kann. So ist Dein Zustand aktuell. Alternativ kann auch über die Pins 2, 3 und 5 die +5V (Pin 5) und +12V (Pin 3) zugeführt werden. Pin 2 ist dabei immer GND. Die überflüssigen Bauteile müssen entfernt werden. Das betrifft mind. die Spannungsregler. Die mögen am Ausgang keine höhere Spannung als am Eingang. Aber auch die Änderung des Pin 3 muß berücksichtigt werden. Mit dem Trafo liegt doch AC, ohne Trafe wird's zum +12V-Pin. Neben dem Entfernen von Bauteilen sind auch Brücken (teilweise anstelle der Dioden) zu legen. Im obigen Schaltplan gibt es dafür drei Fußnoten. Und hier ein passendes Foto. (Ein besseres Foto fand ich auf die Schnelle leider nicht!)

Zitat von axorp

ja, mit los96 und nur für die normale reine basic programmierung.

Okay, dann ist die Welt bei mir wieder in Ordnung.

Zitat von axorp

aber fast keiner hat nur das normale basic da benutzt.

spätestens schon ab dem cbm3xxx wurden zusätliche befehle und maschiensprache routinen benutzt.

Das wäre vermutlich nicht immer nötig gewesen, da LOS-96 schon deutlich mehr mitbrachte als das BASIC zuvor.

Aber, und das dürfte das größte Manko gewesen sein, es mußte auch in den Speicher geladen werden, was nicht nur weitere 32 KB kostete, sondern auch Zeit. Ein ROM-resistentes LOS-96 wäre hier ein deutlich besserer Weg gewesen.

Übrigens Helmut, es ist immer wieder schön Deine Geschichten zu lesen. Danke dafür!

Die Lestungsklasse des Trafo 324748-01 ist mir leider nicht bekannt. Könnte man über die Blechpakete abschätzen. Ich würde mir aber mal das Netzteil auf dem Board genauer ansehen. Die Dioden sind 3 Ampere Typen. Also wird es zwischen 1 und 3 A liegen.

Aber ich würde an deiner Stelle auch die Bestückung ändern und das Board mit +5V und +12V versorgen. Da kann fast jedes PC-Netzteil verwendet werden. Dioden, Kondensator und Spannungsregler einfach entfernen und eigentlich den 3 pol. Stecker gegen eine andere Variante (waren es 4 pol.?) tauschen oder (mind. zum Testen) direkt anlöten.

Die Signale VIDEO, HSYNC und VSYNC können auf dem Board inveriert werden. Zusammen mit der Mischerschaltung aus dem 610 übernommen bekommt man dann auch ein BAS-Signal.

Die Unterschiede zum 610 sind:

• Der CRTC wird im 6x0/7x0 mit 2 MHz getaktet, im 40xx/80xx nur mit 1 MHz. Daher sind einige Register-Werte im 6x0/7x0 doppelt zu hoch wie im 40xx/80xx.
• Beim 6x0/7x0 wird immer pro CPU-Zyklus (Phi2) auch ein Zeichen dargestellt. Beim 40xx/80xx werden pro CPU-Zyklus (Phi2) zwei Zeichen ausgelesen und leicht versetzt dargestellt. Daher ist die Logik hier auch deutlich aufwendiger!
• Das Schieberegister ist im 6x0/7x0 neun Bit (Pixel) pro Zeichen (daher 18 MHz Pixeltakt), im 40xx/80xx sind es nur acht Bit (Pixel) pro Zeichen (daher 16 MHz Pixeltakt).

Unter Link siehst Du die gängigen CRTC Register-Werte der Editoren von 6x0/7x0 und 40xx/80xx. Das Excel-Blatt hilft beim Verstehen der Register und kann zum Offline-Experimentieren dienen. Dort gibt es in den Zeilen 20 und 21 die Werte eines anscheinend bereits an PAL angepaßten ROMs 901474-04, welches meines Wissens unter verfügbar ist. Ich habe das ROM aber nie selbst getestet, die Werte sehen aber vielversprechend aus.

Verwendet wurde hier der Transformator 324748-01 mit 2x 8V Wicklungen und Mittelanzapfung, daher auch der dreipolige Anschluß.

Bei der Bildröhre kam später eine abweichende Version mit 17 kHz anstelle der 20 kHz vom Vorgängermodell zum Einsatz. Hier wird aber mit dem Editor-ROM 901474-04 noch 20 kHz erzeugt. Es handelt sich dabei um KEINE DIN-Version. Häufige Fehlerquellen sind die beiden PLAs auf UE5 (8700-008, 324745-01) und UE6 (8700-009, 324744-01).

Jetzt bin ich etwas verwundert. Ich dachte bis jetzt immer, daß mit dem LOS-96 automatisch die zusätzlichen 64 KB (auch im 8296) genutzt werden. Standen im normalen 8032 nur insgesamt 32 KB für

• BASIC Programmtext,
• Variablen, Felder und Zeichenketten

zur Verfügung, wurden bei LOS-96 dafür nun zwei getrennte 32 KB Blöcke verwendet. Damit müßte bei reiner BASIC-Programmierung nichts angepaßt werden. Außerdem wurde der BASIC-Stack (für FOR-NEXT und GOSUB-RETURN) vergrößert, so daß komplexere Abläufe möglich wurden.

Schaue mal unter folgenden Post nach, dort hatte ich schon einmal in den folgenden Beiträgen versucht zu erklären, daß Speicherfehler teilweise erst nach einiger Zeit auftreten. Jede Speicherzelle ist ein Kondensator. Bei ausreichendem Leckstrom entlädt der sich erst später. Daher ist es besser, den gesamten Speicher erst zu befüllen (z.B. mit Pseudo-Zufallszahlen) und danach auszulesen und auf Korrektheit zu prüfen.

Vielleicht würde es auch ausreichen, zwischen dem POKE und PEEK eine Zeit lang zu warten. Im TIM hast Du das sicherlich zwangsweise getan.

Ich interpretiere das eher als FD 010782, was auf den 01.07.1982 hindeuten kann.

Der 901466-04 deutet auf ein DOS 2 (würde zu einer 3040 passen) hin. Leider sind die Beschriftungen (inkl. Datumsaufdruck) kaum zu lesen. Einige stammen aber vor dem Jahr 1980. Daher wäre es möglich, daß es in den Jahren 1980 und 1982 Reparaturen gab, welche mit diesen Eintragungen dokumentiert wurden.

Die Steckverbinder machten bei Commodore häufiger Probleme. Das kennt man auch von den IC-Fassungen. Aber ich kann mich da auch an Situationen erinnern, wo der Stecker zum Trafo massive Kontaktprobleme hatte. Vielfach wurden die einzelnen Leitungen dann angelötet und die Probleme verschwanden. Das war zwar nicht schön. half aber.

Ich würde hier mal das Datenblatt bemühen. Da der Gleichrichter nur aus Dioden besteht, sollten Ströme von 1,5 A eigentlich kein Problem darstellen. Wichtig ist, daß das Bauteil nicht zu nah an der Platine eingelötet wird und so positioniert wird, daß keine Hitzestau entsteht bzw. andere Bauteile unnötig erwärmt werden. Also auch die Anschlußbeine die Wärme nicht zu stark auf die Platine übertragen. Die meisten Gleichrichter können solche Leistungen auch problemlos ohne Kühlkörper umsetzen.

Ein Gleichrichter mit Schottky-Dioden hätte zwar einen geringen Spannungsabfall, dieser müßte dann aber am Spannungsregler zusätzlich abfallen. Alternativ müßte die speisende Spannung vergeringert werden (z.B. Änderung der primären Wicklung von 220 V zu 240 V). Das könnte aber wieder ganz andere Auswirkungen haben.

Man könnte die Zeilen von 1140 bis 1210 noch einmal danach wiederholen. Warum kann das entscheidend sein? Nun das DRAM ist eigentlich nur eine Reihe von Kondensatoren. Wird ein Bit gelesen, wird eigentlich eine komplette Zeile gelesen. Beim Lesen wird der Kondensator entladen. Nun muß die zuvor gelesene Zeile wieder zurückgeschrieben werden (die Kondensatoren aufgeladen), damit diese Bits nicht verloren gehen. Das alles macht das DRAM transparent. Aber da kann auch etwas schieflaufen. Also wäre es möglich, daß ein Fehler erst beim zweiten Lesezugriff auftritt. Wobei das Lesen an einer anderen Adresse unter Umständen schon dieser zweite Lesezugriff sein kann. Aber eben nicht immer.

Ich sehe gerade, daß ich einen Fehler drin habe:

...
1180 : FOR A=16368 TO 32767
1185 :   D = INT(RND(1) * 256)
1190 :   IF PEEK(A) <> D THEN PRINT "FEHLER ADRESSE: ";A;", IST=";PEEK(A);", SOLL=";D
1200 : NEXT A
...

Sonst wird ein Fehler falsch mit dem Sollwert protokolliert.

Gerne, auf die Idee mit den zufälligen Werten war ich gekommen, da Christian schon richtig schrieb, daß bereits beim Start der Speicher getestet wird. Hier wird meines Wissens mit den Werten $55 und $AA (nicht 0 und 255, wie bei Deinem Ansatz) gearbeitet. Die $AA "überleben" dann im Speicher.

Nun wäre es aber möglich, daß bestimmte Fehler dabei nicht auftreten und gefunden werden können. Mit etwas Glück zeigen sich diese Fehler bei den zufälligen Daten.

Was auch sein kann, es war nur eine "schlechte Lötstelle". Durch das Sockeln wurde diese dann "repariert". Das halte ich sogar für sehr wahrscheinlich.

Ich denke, daß Problem beim Sichern von alten Disketten ist nicht immer nur das Rekonstruieren der Datenspuren. Vielfach können Spuren nur noch n-mal gelesen werden. Da kann die Anforderung eine Spur 10-mal zu lesen schon eine größere Herausforderung werden. Mike Naberezny hatte das mit einer 8x50 formatierten Diskette mal probiert. Das war das einzige bekannte Exemplar eines Coral-Compilers. Das Ende vom Lied war, die magnetische Schicht hatte sich abgelöst und wichtige Sektoren fehlen damit vermutlich für immer.

Wenn Christian ein 100 TPI QD Laufwerk hat, haben es die Entwickler von Kryoflux das noch nicht. 100 TPI ist heute wirklich ein Exot, warum auch immer Commodore darauf setzte, obwohl sie zuvor schon 48 TPI verwendeten.

Natürlich macht es Sinn, die Daten möglichst frühzeitig nach dem Lesekopf zu sichern. Dabei kann es evtl. hilfreich sein, die Digitalisierung etwas anzupassen. Ob man damit dann die Lesefehler immer vermeiden kann, halte ich für ungewiß. Gerade etwas feuchte Lagerung ist hier problematisch. Vielleicht kann eine analoge Speicherung des Signals vom Lesekopf hilfreich sein.

Spatestens jetzt sind wir bei dem Vorgehen von professionallen Datenrettern angekommen. Teilweise nutzen diese sogar eigene Leseköpfe.

Ich bin trotzdem gespannt, was noch alles auftauchen wird. Schön, aber wieder von Dir, Helmut zu lesen.

Korrekt, Deine Annahme ist richtig:

1000 REM RESERVIERE DEN SPEICHER OBERHALB VON 16 KB
1010 POKE 52,0 : POKE 53,64 : CLR
1020 :
1030 REM VERWENDE VERSCHIEDENE ZUFALLSFOLGEN FUER 256 DURCHLAEUFE
1040 FOR S=1 TO 256
1050 :
1060 : REM INITIALISIERE DEN ZUFALLSGENERATOR
1070 : B = RND(-S)
1080 :
1090 : REM BESCHREIBE DEN SPEICHER MIT ZUFAELLIGEN WERTEN
1100 : FOR A=16368 TO 32767
1110 :   POKE A, INT(RND(1) * 256)
1120 : NEXT A
1130 :
1140 : REM INITIALISIERE DEN ZUFALLSGENERATOR ERNEUT
1150 : B = RND(-S)
1160 :
1170 : REM LESE DEN SPEICHER ZURUECK UND VERGLEICHE
1180 : FOR A=16368 TO 32767
1190 :   IF PEEK(A) <> INT(RND(1) * 256) THEN PRINT "FEHLER ADRESSE: ";A;", IST=";PEEK(A);", SOLL=";INT(RND(1) * 256)
1200 : NEXT A
1210 :
1220 NEXT S

Was mache ich oben?

Ich beschreibe den Speicher mit zufälligen Werten. RND(<positive Zahl>) liefert eine Pseudo-Zufallszahl. Diese wird abhängig von einem Startwert immer wieder gleich berechnet. Also muß ich zuvor nur noch einen Startwert setzen. Das erledigt das RND(<negative Zahl>). Das Ergebnis dieses Aufrufs wird verworfen.

Zur Vollständigkeit, RND(0) liefert wirkliche Zufallszahlen aus dem Timer eines IO-Bausteins (VIA).

Wurden die 16 KB mit den zufälligen Werten beschrieben werden diese erneut zurückgelesen. Dazu wird zuvor wieder der Startwert gesetzt. Jede Abweichung wird dabei protokolliert. Das kann man bestimmt noch geschickter machen.

Dieser Test wird mit 256 verschiebenen Startwerten (und damit auch zufälligen Folgen) durchgeführt. Die Grenze auf 256 ist willkürlich und kann auch geändert werden. Ab wann sich Zufallsfolgen wiederholen ist mir aktuell nicht bekannt.

Nun, ich sehe darin auch erst einmal keinen Verstoß. Die Änderungen am F-ROM sind in meinen Augen nicht unbedingt nötig. Aber ich muß gestehen, gerade nicht zu wissen, ob man mit BLOAD auch bis auf das letzte Byte einer Bank laden kann. Oder es sollte noch eine Option offengehalten werden bankübergreifend den IRQ auszuführen. Ich meine beim Überfliegen im Handbuch unter #1 dazu etwas gesehen zu haben.

Das Thema bleibt also spannend ...

Ich habe mir Deine Änderung am Programm "proxa 7000.prg" genauer angesehen. Du scheinst teilweise auch in das "Problem der zu kleinen" Dateien gelaufen zu sein. Warum dieser von Dir gelöschte "Kommentar" LOAD TASTATUR $E000-EFFF in Zeile 460 steht ist wirklich fraglich. Aber es fällt auch hier auf, das "Original"-Programm besitzt am Ende nur ein 00-Byte. Erwartet werden drei 00-Bytes. Daher wurde auch etwas "Schmutz" bei Deiner korrigiertem Version am Ende hinzugefügt. Deine Version hat nach dem Schmutz wieder die erwarteten drei 00-Bytes. Genau so ist es mit den ROMs für den 8032 in der Datei "8032-700.prg". HIer fehlen die Bytes an den Adressen $FFFE und $FFFF für den IRQ-Vektor. Aber ich sehe, daß es im F-ROM eine Änderung gibt:

$FD38 LDA #$00
$FD3A STA $03FC

wurde zu:

$FD38 LDA #$00
$FD3A JSR $FD5E
...
$FD5E STA $03FC
$FD61 LDA #$E4
$FD63 STA $FFFF
$FD66 LDA #$42
$FD68 STA $FFFE
$FD6B RTS

Außerdem wurden die Füllbytes an den Adressen $FFF0 und $FFF9 (Prüfsummen?) angepaßt. Demnach gibt es einen Grund für die zu "kleinen Dateien", der durch einen Patch (Änderung am Original-ROM) behoben wurde.

MEMTOP ($0034/$0035) auf $4000 setzen, CLR aufrufen (POKE 52,0 : POKE 53,64 : CLR) und die obere RAM-Bank wird nicht mehr verwendet. PRINT FRE(0) sollte dann 16 KB melden. Nun kann man sich "austoben".

Hat jemand die Proxa 7000 mit den Disketten aus #10 zum Laufen bekommen? Mir kommt es so vor, als wenn dort immer zwei Bytes zum Ende fehlen. Damit fehlt dann z.B. auch der IRQ-Vektor.