Posts by for(;;)

    Zeit für ein Update:


    D80/D82 wird wieder unterstützt, lediglich der NEW-Befehl zum Formatieren von Disk-Images fehlt noch. Zwischenzeitlich habe ich sd2iec zu NODISKEMU geforkt. (Gibt es dafür eigentlich auch ein deutsches Wort?) Der Quelltext liegt auf https://github.com/nils-eilers/NODISKEMU, dort gibt es auch eine Wunsch- und Klageliste: issue list. Fertig compilierte Firmwares gibt es auf der nightlies-Seite.


    Dave Stevenson hat sehr viel Mühe in seine Aufbauanleitung für das petSD+ gesteckt, die mittlerweile so gut wie fertig ist: petSD+ Aufbauanleitung. Wie man sehen kann, ist schon ein Link vorbereitet für eine deutsche Fassung, da muss ich jetzt mal noch schnell übersetzen... Bis die zweite Revision fertig ist, wird es bestimmt wieder einige Wochen dauern und groß sind die Unterschiede nicht. Wer also bald ein petSD+ haben möchte, sollte Dave ggfs. noch einmal anstupsen, da der Vorrat an Platinen aus dem ersten Batch sehr begrenzt ist.


    Bei Dave Curran dagegen, also "dem anderen Dave", kann man jetzt fix und fertig aufgebaute pet microSD kaufen, beginnend bei 50 englischen Pfund, umgerechnet ca. 68,- Euro. Auf den ersten Blick erinnert es wegen der Größe und dem Format zum Aufstecken an den PET an das PETdisk von bitfixer, doch damit enden schon die Gemeinsamkeiten. Es hat den selben Controller, der auch auf dem petSD verbaut ist und ist mit diesem vollständig software-kompatibel. Darüber hinaus hat es Bustreiber für den IEEE-488-Bus, einen vernünftigen Spannungsregler für die SD-Karte, eine sehr gute 3.3V<-->5V-Pegelwandlung zur Anbindung der SD-Karte an den Controller und eine polyfuse-Sicherung: ist also kein billiger Schrott, sondern klein aber sehr fein. Und man kann alle Firmwares darauf verwenden, die auch mit dem alten petSD laufen, also sd2iec, XD-2031 und NODISKEMU.
    Der Preis könnte niedriger sein, wenn Dave nicht alles aufwändig von Hand löten müsste, sondern das nötige Kleingeld für eine maschinelle Bestückung eines hinreichend großen Batches hätte. Wer also etwas Risikokapital investieren möchte, darf sich gerne bei ihm melden.

    Murphys Gesetz hat mal wieder zugeschlagen, weshalb es erst jetzt ein Update gibt: die angepasste Version von sd2iec für die neue Hardware wollte einfach nicht funktionieren. Das habe ich dann zum Anlass genommen, endlich mal zu entrümpeln und diesen furchtbaren Hack von IEEE-488-Routinen innerhalb von sd2iec, die ich damals verbrochen habe, durch komplett neu geschriebene zu ersetzen, damit läuft's jetzt.


    Ein Paket mit den verbliebenen Prototyp-Platinen geht heute an Dave raus, damit er sie weiter verteilen kann. Wer keinen ISP-Programmierer braucht (und den brauchen nur Entwickler), kann die Platinen ohne jede Änderung verwenden.


    Dann kann ich mich jetzt daran machen, die Platinen zu überarbeiten. Die neuen Platinen der Rev. 2 sollen geringfügig größer werden, was den Zusammenbau erleichtern soll (keine Kabel-Bastelei für das Display) und zusätzlich Platz auf der Platine schaffen soll, insbesondere für einen Überspannungs-Schutz, falls jemand das 9V-Steckernetzteil statt 5 Volt angeschlossen hat, blos weil der Stecker passt.


    An der Software gibt's auch noch reichlich zu schrauben: eine Benutzerführung über Display/Tasten fehlt bislang komplett und die D80/D82-Unterstützung muss auch erst wieder gestrickt werden.

    Ich seh das "Open Source Hardware" Logo auf der Platine, aber kein Layout auf der Website - hab ich da was übersehen?


    Nein, wie Sie sehen, sehen Sie nichts. Das petSD+ wird dort ja noch nicht einmal mit einem Wort erwähnt.


    Mir geht's da nicht besser als den Jungs am Flughafen: die kriegen auch nicht alles an einem Tag fertig.


    Aber die Open-Source-Hardware (OSHW) Grundsatzerklärung ist mir natürlich wohlbekannt und die vollständige compliance folgt schnellstmöglich: alle Quellen der Design-Files inklusive fertiger Gerber-Dateien für Platinenfertiger, die Quellen im Format der freien Software KiCAD. Zusätzlich eine Stückliste mit Bestell-Nummern von Lieferanten, die ich verwendet habe, ebenso wie eine bebilderte und kommentierte Aufbauanleitung. Ach ja, und eine Liste der "known issues", da wird wohl noch mal ein weiterer Prototyp fällig.

    Heute kam in lustiger Runde die Frage auf, ob oder wie man bei sd2iec das FAT-Dateisystem korrumpieren kann. Speziell ging es dabei um die Frage, ob man die IEC-Reset-Leitung an den AVR-Reset legen darf, kann oder soll.


    Wenn man das Bus-Reset an das SD2IEC-AVR-Reset angeschlossen hat, eine offene Datei hat (also noch kein CLOSE abgeschickt) und dann den C64 resettet, was passiert dann? Datei-System korrumpiert, oder nur ungesicherter Buffer-Inhalt verloren und Datei mit zu kleiner Größe und fehlendem Inhalt oder... ?


    Hat jemand aus der Bus-Reset-an-AVR-Reset-Fraktion schon Probleme mit dem Dateisystem gehabt und musste diese auf dem PC reparieren lassen?


    Macht es einen Unterschied, ob man plain-FAT oder Disk-Images benutzt?

    Der wäre bestimmt prima, weshalb ich den fast identischen DS3231 im petSD-duo verbaut habe, wo Geld keine Rolex spielt.


    Für das low-cost petSD+ halte ich den aber für ungeeignet, denn in der günstigsten Quelle die ich finden konnte (und die zudem einen weiteren Lieferanten bedeutet, also nochmals Porto) kostet er mit 8,03 € schon beinahe so viel wie der AVR mit Bustreibern!


    Der PCF8583 in DIP, Sockel, zwei Dioden, Quarz und Trimmkondensator kosten dagegen zusammen(!) nur 1,95 und unterbieten damit sogar den DS1307 in DIP. Ich glaube, bei diesem Kompromiss bleibt es.

    Den DS1307 habe ich beim alten petSD verwendet und bin von der Genauigkeit alles andere als begeistert. Der PCF8583 ist natürlich erst einmal kein Deut genauer, bietet aber über den Trimm-Kondensator die Möglichkeit, an der Frequenz zu drehen, weshalb ich ihn bevorzugen würde.

    Der Vorgänger war nur sehr theoretisch netzwerkfähig. Die Hardware habe ich zwar als funktionierend überprüft, mit einer Software, die am CBM nicht einsetzbar war, aber in Verbindung mit dem CBM als IEEE-488-Netzwerkgerät gab es niemals Softwareunterstützung und wird es aller Voraussicht auch nicht geben. Ein solches Gerät existiert aber schon als "Flyer Modem" und niemand scheint Code dafür zu schreiben.


    Ich erinnere nicht mehr, was genau Donald damals dafür aufgerufen hat.


    Da alle Design-Files frei verfügbar sein werden, wird sich jeder selbst ein Bild machen können, was beim Händler hängen bleibt oder auch nicht. Damit kann dann auch jeder auf eigene Faust selbst bestellen und versuchen, den Händler-Preis zu unterbieten oder es selbst vertreiben und andere unterbieten.


    Ich bleibe aber dabei, keine konkreten Zahlen zu nennen, weil es da zu viele Variablen gibt, auf die ich keinen Einfluss nehmen kann.

    Was bedeutet "low-cost" in diesem Fall konkret?


    Low-cost bedeutet in diesem Fall, dass auf der Platine kein Schnickschnack drauf ist, sondern das Teil eben einfach eine SD-Karten-Speicherlösung mit LCD-Display und drei Tasten wird.


    Es ist aber kein "wäre ja schön wenn" verbaut worden, was extra kosten würde, dafür lebe ich meine Feature-itis jetzt ja beim petSD-duo aus.


    Low-cost bedeutet hier aber ausdrücklich nicht, dass das Ding kaputt gespart worden wäre! Obwohl es einfach und preiswert sein wird, gibt es trotzdem richtige IEEE-488-Bus-Treiber, einen Verpolschutz für die Spannungsversorgung und einen SD-Karten-Slot aus Metall mit push-push-Mechanismus.


    Was das nun konkret in Euros bedeutet, wird Dave beantworten können, wenn er einen Überblick hat, wie viele Platinen zusammen kommen.

    Die Weiterentwicklung des petSD zum petSD-duo steckt immer noch in der Endlos-Schleife fest. Aber ab und zu gibt es ein paar neue Bilder: https://flic.kr/s/aHsk5BfNQE


    Seit wenigen Tagen gibt es zudem eine neue Entwicklung: es wird wohl vorher eine einfachere, low-cost Variante geben: http://www.primrosebank.net/co…et/projects/pet_petsd.htm


    Dave und ich hecken gerade das petSD+ aus, das deutlich schneller verfügbar sein sollte als das petSD-duo. Dave würde sich darüber freuen, wenn sich Interessenten bei ihm kurz per Mail melden könnten, damit er etwas einschätzen kann, was da auf ihn zukommt.

    Auf den Fotos nicht, aber bei den CBMs geht gerne der Netzfilterkondensator mal fliegen.

    Oh, ja! Auf jeden Fall! Falls man keinen Austausch-Typ zur Hand hat: ohne ist besser als mit dem alten!

    Eine Kopiermöglichkeit für die Disk habe ich nicht – für das Eprom evtl. schon (AleX hat einen Eprom-Brenner).

    Falls sich auf der DoReCo nichts ergeben sollte, würde ich Dir auch gerne einen frankierten Rückumschlag inkl. Diskette zusenden.


    Das EPROM kann man im Rechner ohne Hilfsmittel (außer dem eingebautem TIM) auf Diskette schreiben:


    Code
    1. SYS 1024
    2. S "ROM-9000",08,9000,A000
    3. S "ROM-A000",08,A000,B000


    BSOS werde ich dann mal genauer ins Auge fassen. Die Bausteine, die dafür getauscht werden müssen, sind alle gesockelt?

    Ja. Du brauchst ein 27128 (BASIC + KERNAL) (ein 27256 tut's auch, wenn man den Inhalt verdoppelt) und zwei 2532 (oder statt 2532 jeweils ein 2732 wie in Deinem System modifiziert) für EDITOR und CHARSET.

    Ich habe mal etwas gebastelt: ein kleines Programm in Assembler, das im Kassettenpuffer #2 liegt und von BASIC aus mit SYS 826 aufgerufen werden kann, dann gibt es das Directory "$" aus.


    In Adresse 212 liegt die Geräteadresse des Gerätes dessen Inhaltsverzeichnis ausgegeben werden soll. Da das die zuletzt verwendete Geräteadresse ist, wird es durch LOAD"DEMO",8 automatisch auf 8 gesetzt. Will man etwas bestimmtes, hilft ein POKE 212,<DeinWertHier!> vor dem SYS 826.



    Das in der ZIP-Datei enthaltene Programm "DEMO" zeigt die Verwendung von BASIC aus. Das BASIC-Programm kann man natürlich nach Belieben verändern. Man kann das Directory-Modul auch bei bestehenden Programmen nachrüsten. Leider gibt es das Problem, dass ein SAVE"MEIN PRG MIT DIR",8 nicht das Maschinensprachmodul mit abspeichert. Man kann aber mit dem Monitor speichern, so dass ein Komplettpaket aus BASIC-Programm und Modul entsteht, dass in Folge mit nur einem LOAD-Befehl geladen werden kann.


    Exemplarisch zeige ich mal, wie man ein bestehendes Programm "DEMO" mit der Dir-Funktion nachrüstet:


    Wichtig ist, zuerst das Modul zu laden:



    LOAD"SYS*",8


    Erst danach das bestehende BASIC-Programm laden (oder selbst eines eintippen):


    LOAD"DEMO",8


    [mehr oder weniger viel Tipparbeit bis das Ergebnis gefällt]




    Zum Speichern geht's dann in den Monitor:


    SYS 1024
    M 002A 002A


    das gibt hier : 002a 62 04 62 04 62 04 00 80 aus. Wir brauchen die ersten beiden Bytes "62 04" in umgekehrter Reihenfolge als 0462 und speichern unter dem Namen "KOMPLETT" auf Geräteadresse 8:


    S "KOMPLETT",08,033A,0462


    Fertig!


    Nun kann man später mit


    LOAD"KOMPLETT",8
    RUN


    beides (BASIC+MC) in einem Rutsch laden.


    Viel Spass!

    Files

    • basic2dir.zip

      (4.19 kB, downloaded 14 times, last: )

    Von den verbauten Eproms des 8296-D lösen sich die Aufkleber. Sollte ich da mal was anderes draufkleben, damit sich die Bausteine nicht noch durch das einfallende Licht löschen?

    Das wird total überschätzt. Selbst wenn da gar kein Aufkleber drauf wäre, müsstest Du den Rechner schon tagelang im prallen Sonnenlicht aufgeklappt stehen lassen, bis sich da vielleicht mal was tut. Ich würde das originale Label einfach mit etwas Kleber wieder befestigen.

    Weiß jemand, was auf dem Textverarbeitungs-Rom (Comtext) drauf ist? (Die Software liegt auf Disk bei)

    Nö, aber haben will! Hast Du eine Möglichkeit des Datenaustauschs und kannst Diskette und ROM hier hoch laden?

    Könnte dieses ROM irgendwelche andere Software stören?

    Nein.

    Macht es Sinn, wenn der Rechner läuft, auf BSOS umzurüsten?

    Absolut! BSOS ist eine bedeutende Aufwertung, sehr kompatibel und blockiert *nicht* die Erweiterungs-ROMs. Bei auftretenden Problemen gibt's bestimmt auch schnell einen Bug-Fix: der Programmierer "BlackSmurf" ist auch hier im Forum aktiv.

    Ist das kompatibel zu 3rd-Party-Software (Anwendungen/Spielen)? Vor allem, weil man ja sogar die Tastaturbelegung ändert.

    Prinzipiell: ja, sehr. Das ist auch der erklärte Anspruch. Falls etwas auftauchen sollte, was nicht funktioniert, passiert da bestimmt was.


    Bei Spielen hängt es davon ab, wie sie die Tastatur abfragen. Wenn sie direkt die Tastenmatrix abfragen, bleibt das Spiel zwar spielbar, aber es werden eben die Tasten verwendet, wo die Cursor-Tasten "original" liegen. Wenn dagegen Editor-Routinen zum Abfragen der Tastatur verwendet werden, passt auch die Beschriftung.


    Evtl. lässt sich der schwarze Schlumpf ja auf freundliche Nachfrage dazu überreden, noch eine Version mit originaler Tastenbelegung zu erstellen.

    Ist noch irgendwas auffälliges auf den Fotos zu sehen?

    Nö.

    Ebenso weiß ich noch nicht, ob das mit dem Auslesen der maskenprogrammierten PLAs klappt, um die erforderlichen .jed-Files zum programmieren zu gewinnen...

    Das wird aller Voraussicht nach nicht gelingen. Zum Erzeugen der JEDEC-Files wollte ich die bekannten Gleichungen in den PALASM hacken. Das wird aber auch das erste mal, dass ich ein PAL PLA programmiere und ich bin ebenfalls sehr gespannt, wie viele ich zerschiesse, bis es funktioniert...