Beiträge von Toast_r

Die vermutlich komfortabelste Lösung dürfte das von for(;;) entwickelte petSD sein.

Datenträger ist dabei eine SD-Karte mit FAT32, Anschluß an den CBM erfolgt über den IEEE-Bus.

Es emuliert eine CBM Floppy am Bus.

Allerdings läuft das mit einem PET 2001 nicht, benn da sind die IEEE-Bus Routinen im ROM karpott.

Ab dem 2001N (CBM 30xx) funtioniert das.

Um Software auf eine Kassette für den PET 2001 zu kriegen gehe ich immer den Weg petSD => CBM 8032 => Datassette.

Es gibt aber gerade für die Anbindung von PET /CBM Rechnern an die 'neue Welt' eine Vielzahl von Lösungen.

Zitat von Dianqi Gongchengshi

welchen Einfluss hat die niedrigere Versorgungsspannung auf das Bauteil?

Wie/warum das genau funktioniert weiß ich leider nicht, nur daß die Methode in vielen Fällen klappt.

Es kann sicher nicht schaden, wenn wir eine kleine Software-Sammlung für CP/M auf dem MFA zusammentragen.

Ich mache mal den Anfang:

Gestern habe ich eine Diskette mit MBASIC und den bekannten Creative Computing Spielen zusammengestellt.

Die Sammlung war zuvor auf zwei Disketten mit jeweils eigenem Menü-Programm aufgeteilt.

Ich habe alles auf eine Diskette zusammengefasst, und das Menü so geändert, daß alle Programme eingetragen sind.

Das Menü ist als MENU.BAS abgelegt und kann vom CP/M aus direkt mit MBASIC MENU gestartet werden.

Im Menü müssen die Programmnamen komplett in GROßSCHRIFT eingegeben werden.

Gibt man im Menü SYSTEM ein, wird das Basic wieder verlassen.

Da es ich um über 100 Dateien handelt, wäre es sehr mühsam, die alle einzeln zu übertragen, also hier als Diskimage.

Das CBM-Gehäuse ist wirklich schön - und für mich das normalste Computergehäuse überhaupt.

Schließlich war der Rechner, auf dem ich 'laufen gelernt' habe ein CBM 8032-SK.

Den PC als den Rechner herzunehmen, der IT-Knowhow produziert hat, ist schon argh abwegig.

Eine noch verkorstere Architektur ist mir bisher eigentlich begegnet.

Das ganze basiert auf einem verkrüppelten Prozessor, und dessen eingeschränkte Möglichkeiten wurden dann auch noch beschnitten.

Damit erzeugt man bestenfalls Know-How-Not.

Achso... da habe ich sie auf die Schnelle nicht gefunden.

Wenn's um das archivieren geht, ist dann vermutlich das Kryoflux die bessere Lösung, weil man da nicht auf bestimmte Laufwerke angewiesen ist, sondern beliebige mit Shugart-Bus anschließen kann.

Außerdem ist das Kryoflux inzwischen wirklich ausgereift, und biuetet auch die Möglichkeit, RAW Images zu erstellen. Damit kann man auch Disketten archivieren, deren Format in der Software noch nicht eingepflegt ist. Die RAW Images kann man dann später, wenn das Format bekannt ist, mit der Software dekodieren. Somit kann man unbekannte Disketten sofort einlesen, und dem endgültigen Zerfall zuvorkommen.

EPROMs, deren Datenerhalt man nicht mehr traut, bzw. die bereits teilweise veränderte Daten liefern,

liest man gewöhnlich mit niedrigerer Versorgungsspannung aus, um möglichst noch die richtigen Daten zu erhalten.

Das macht man meist mit einer Diode in der Vcc Leitung, damit senkt man die Spannung um 0,7V.

Einige Eprommer bieten die auch die Möglichkeit, einen Vergleich mit Nenn-, Über- und Unterspannung durchzuführen.

Sind bestimmt umgelabelte 12V...

Sieht ja preislich auch noch halbwegs brauchbar aus:

https://www.ebay.de/itm/323657247023

Ob es wirklich die beste Idee ist, ausgerechnet die originalen Laufwerke zu verwenden, darf man bezweifeln. Die ollen Shugart Dinger waren von Anfang an nicht gerade high-end Ausrüstung, und die dürften auch größtenteils inzwischen ziemlich runtergerockt sein.

Das FINDBAD.COM habe ich jetzt mal auf der kaputten Diskette ausprobiert.

Es hat auch defekte Sektoren gefunden, allerdings dachte ich erst, es hätte garkeine Datei angelegt.

Die Datei ist aber da, allerdings liegt die unter USER 15.

Jawoll, das hat geklappt.

Überprüft habe ich es, indem ich das CP/M mit der Videokarte im MFA als Terminal gestartet habe, dabei die zweite serielle Schnittstelle mit dem Terminalprogramm auf dem PC verbunden.

Dann die Konsole mit STAT CON:=UC1: umgeschaltet ... und zack, die Konsole lebt auf dem PC.

Der Weg zurück mit STAT CON:=TTY: klappt auch.

Besten Dank!

Jetzt muß ich mich nochmal einlesen um zu kapieren, was ich da eigentlich gemacht habe.

Ui ... Leicht eingedeutscht.

Mal sehen, ob ich das hinbekomme ...

Wie man einzelne Bytes im BIOS patcht steht in der BIOS.TXT von Mike ja ebenfalls beschrieben.

Aber es muß doch auch einen Weg mit dem Assembler geben ...

Wie ich ja bereits erwähnte, möchte ich das CP/M BIOS an meine abweichende Portadresse für die zweite serielle Schnittstelle anpassen.

Ich habe also in der Datei BIOS.ASM die entsprechenden Änderungen vorgenommen.

Wenn ich diese Datei assembliere (ASM BIOS) erhalte ich wie erwartet den Objektcode als HEX-Datei (BIOS.HEX) und die PRN-Datei.

Aber wie geht es dann weiter? Wenn ich die BIOS.HEX mit LOAD lade und mit SYSGEN auf die DIsk zurückschreibe, ist das Ergebnis nicht bootfähig.

Außerdem ist die von LOAD erzeugt BIOS.COM dann 60KB groß.

Ich habe die ganze Prozedur mit SYSGEN und MOVCPM noch nicht verstanden ...

Guck mal hier:

GAL Programmer

Die Software für den EPROM Brenner ist im MAT85 enthalten.

Sie kann mit GO 1E06 gestartet werden, oder, wenn SP1 vorhanden ist, über das Zusatzmenü (KMD+).

Doku zum EPROM Programmierer

Seit kurzem gibt es eine sehr gut aufgeräumte um umfangreiche Seite für PET/CBM-Spiele: Commodore PET Gamebase

Würde ich gerne beide nehmen.

Selbst gefädelte Karten kommen bei mir öfter vor.

Sauber - Es geht voran!

Was hat es mit dem Chip Select für die oberen 512KB RAM auf dem Lötnagel auf sich?

Reicht der Platz auf der Platine nicht mehr für ein zweites SRAM aus, und das soll dann huckepack draufgepappt werden?

Auch eine Idee, die schlechten Sektoren einfach einer Datei zuzuordnen. Danke, Fritz!

Ich werde die betroffene Diskette aber wohl besser entsorgen.

Man kann schon an der Oberfläche weggefräste Magnetschicht an der betroffenen Spur sehen ...

Hallo Jürgen,

es freut mich, mal wieder von Dir zu hören.

Ich wünsche Dir im neuen Heim alles Gute!

vG

Christian

Da mein zweiter serieller Port nicht an 0x90h liegt, sondern an 0xA8H,

möchte ich mir Monitor, CP/M BIOS und die Transferprogramme passend kompilieren.

Also habe ich die .ASM Daterien entsprechend editiert.

Assemblieren möchte ich das auf dem MFA, also muß ich erstmal die Dateien dahin übertragen.

Erster Versuch:

A>PCGET B:BIOS.ASM

Bleibt mittendrin stehen. Noch zwei mal versucht: Bleibt reproduzierbar nach 153 XModem-Paketen hängen.

Abbruch mit CTRL-C ist möglich.

Nächster Versuch: Datei auf Laufwerk A speichern, also:

A>PCGET BIOS.ASM

Läuft ohne Probleme durch.

Daß das auf dem einen Laufwerk klappt, und dem anderen nicht, deutet auf ein Diskettenproblem hin.

Also die Diskette in Laufwerk B: mit Verify im COPY-Programm überprüft.

Und siehe da: Auf der Disk sind tatsächlich ein paar Sektoren fehlerhaft.

Kann man im PCGET Programm eine bessere Fehlerbehandlung einbauen?

Gut wäre, in so einem Fall den XMODEM Transfer erst abzubrechen,

und danach eine entsprechende Fehlermeldung auszugeben,

damit diese auch auf dann dem Terminal erscheint, wenn man über den Konsolenport überträgt.

Wenn man den Transfer vorher nicht abbricht,

würde das XMODEM der Gegenstelle die Fehlermeldung sonst vermutlich verschlucken.

Solange noch genug Platz im 2KB EPROM ist, kann man das mit dem Logo ja durchaus machen.

Wenn uns für den Monitor aber noch sinnvolle Erweiterungen einfallen sollten, kann das aber vielleicht wieder eng werden...

Das wäre ja noch garkein Fehler, sondern ganz normal...

Das Problem ist offenbar schon einen Schritt früher aufgetreten:

Ich hatte beim ersten Versuch die Diskette mit Teledisk zurückgeschrieben.

Jetzt habe ich das mit ImageDisk nochmal neu gemacht und was soll ich sagen - jetzt funktionierts.

Auch eine mit COPY.COM auf dem MFA erstellte Kopie der Systemdiskette funktioniert.

Ein TM100 mit defektem Riemen ist mir auch noch nie untergekommen.

Ich würde erstmal den Riemen runternehmen, und prüfen, ob der Motor und das Laufwerk selbst leichtgängig sind, wenn es in der Richtung irgendwelche Probleme gibt.

Bei mir stellt sich das Problem ganz anders dar.

Die Tastatur wird nicht erkannt und blinken tut da auch nix.

Wenn ich mit dem Oszilloskop direkt an der Tastaturmatrix messe, sehe ich, daß die Tastatur gescannt wird, und Tastendrücke auch Kontakt auslösen.

Siehe erster Beitrag in diesem Thread, ich habe das von Mike Douglas angepasste CP/M verwendet.

Also mit 80 Track (720K) Disks.

Ahrrg... Das ist ein Henne-Ei Problem.

Ich kann das BIOS nicht patchen, weil ich ja gerkeine Progrmme laden kann (DDT, MOVCPM, SYSGEN).