Bei beiden Lösungen läuft CP/M auf einem Z80, der eigenes RAM zur Verfügung hat. Der CBM-Rechner wird als Terminal verwendet und das CP/M-Dateisystem auf CBM-Floppies gespeichert.
Trotz dieser Gemeinsamkeiten ist es interessant, die beiden Geräte zu vergleichen, da die selbe Aufgabe "CP/M mit Hilfe eines CBM" tatsächlich höchst unterschiedlich realisiert wurde.
Ob Du glaubst oder nicht, ich habe allen ernstes darüber nachgedacht, einfach mal so ein kleines Fotoworkshop MIT einem Model zu machen. Sozusagen, wie fotografiere ich alte Rechner, wenn eine hübsche junge Dame sie auf dem Arm hat.
Ich bedauere immer noch, dass für 2014 kein Nerd-Dreams-Kalender mehr erschienen ist. Meiner Freundin und mir hat die 2013er Ausgabe sehr gut gefallen.
Sachlich richtige Einwände in nicht unangemessener Form möchte ich gerne auch weiterhin in diesem Forum lesen.
Der MC ist wohl ein NKC mit ECB-Bus-System. Also einfach eine andere Form der Platinen-Stecker. Quelle: http://schuetz.thtec.org/mccomputer/mcc.html
Sag mal, kann ich bei dem noch irgendwie das originale Microsoft-BASIC erreichen oder ist das komplett raus?
Das Commodore-BASIC ist nichts anderes als ein original Microsoft-BASIC, das lediglich geringfügig erweitert wurde. Details inkl. Quelltext gibt es hier: Create your own Version of Microsoft BASIC for 6502
Diese Sache mit dem "aufgescheuerten" Elko ist wirklich kurios. Das ist mir noch nie unter gekommen.
Größere Elkos werden mit Klebstoff oder auch mit Kabelbinder auf der Platine befestigt. Ob das ein Versuch war, den Elko in ganzer Breite zwecks Befestigung mit anzulöten?
OK, das Vorkommen in name.c habe ich gefunden und entfernt. In cmd.c wurde es offenbar schon entfernt.
Kann es sein, dass Du an den über ein Jahr alten Quellen des letzten Releases arbeitest? Das solltest Du nicht tun, der Code ist hoffnungslos veraltet. Bitte hol Dir gegebenenfalls einen aktuellen snapshot als zip von github oder noch besser: klone direkt.
Gehe dazu in ein Verzeichnis Deiner Wahl und gib am Terminal folgendes ein:
git clone https://github.com/fachat/XD2031.gitWozu dient eigentlich IEC_SATN_INT? Das steht auf PCINT3 (PA3), habs aber nirgends im Code gefunden.
Das ist obsolet, ich habe es zwischenzeitlich entfernt. Im Quelltext findet sich immer wieder mal auskommentierter Code, Andre scheint ganz gerne etwas für später aufzuheben, wohl um sich die Mühe zu ersparen, das wieder zu finden. Bei mir selbst bin ich natürlich blind in diesen Dingen 
command_to_name wird m.E. nur ein Debug-Ausgaben (debug_printf) verwendet. Du meintest, dass das für die
ausgeschriebenen Befehle (z.B. SCRATCH) verwendet wird. Wo finde ich das?
Das ist ein Missverständnis. Nicht command_to_name() wird für die ausgeschriebenen Befehle benötigt, sondern das von command_to_name() verwendete Array cmd_tab[], zu finden in firmware/cmdnames.c ab Zeile 36. Wenn command_to_name() wirklich nur für Debug-Ausgaben verwendet wird, könnte man auf diesen Puffer im RAM natürlich gänzlich verzichten, wenn man sich z.B. eine Art debug_printf_p baut.
In den debug_printfs mit command_to_name wird mit . == CMD_NONE ? ... : command_to_name der Fall "-" abgefangen.
Ist das nötig? Der ist doch im switch/case behandelt.
Das konnte ich nicht finden. Welche Zeile in welcher Datei meinst Du damit?
Im Schaltplan ist IEC-Reset mit PD6 verbunden, im Code find das aber nicht. Stimmt das?
Ja. Der Bus-Reset wird bislang von der Firmware gänzlich ignoriert. Schaden tut das aber nicht, da beim Reset automatisch alle Ports als Eingang verwendet werden. Schöner wäre natürlich, wenn das Gerät auch auf einen Bus-Reset reagieren würde. Ich habe #147 dafür angelegt: https://github.com/fachat/XD2031/issues/147
Sorry für die vielen Fragen. Ich versuch es zu verstehen.
Deine Fragen und Deine Mitarbeit sind sehr willkommen! Nur weiter so! 
Freut mich, dass Du unerschrocken genug bist, damit herum zu basteln! 
Mit unter 2000 Bytes bist Du da auch auf einem guten Weg! Das könnte wirklich etwas werden, und das wäre wirklich super!
Um Deine weiteren Fragen zu beantworten, sei mir erlaubt, erst etwas zur Architektur des verwendeten AVR-Controllers auszuholen:
AVRs haben Harvard-Architektur der übelsten Sorte. Es gibt also nicht einen gemeinsamen Speicher (wie bei der von-Neumann-Architektur) für Daten (RAM) und Programm (Flash), sondern der ist strikt getrennt. Bei AVR sogar so sehr getrennt, dass RAM und Flash nicht einfach an verschiedenen Adressbereichen liegen, sondern die MCU mit verschiedenen Maschinenbefehlen darauf zugreifen muss. Um passenden Code erzeugen zu können, muss zur compile-time bekannt sein, ob ein Zeiger auf das RAM oder das Flash zeigt. Die Funktionen der Standardbibliothek erwarten ihre Parameter alle im RAM. Mit strcpy() könnte man z.B. keinen String aus dem Flash in das RAM kopieren. Dafür gibt es in der avr-libc Funktionen mit angehängtem _P bzw. _p, das wäre also hier z.B. strcpy_P(). Bei anderen Prozessoren, wie z.B. PIC18 von Microchip heissen diese Funktionen, die auf das Flash zugreifen können, aber wieder anders, weshalb wir das in XD-2031 abstrahiert haben. Aufgedröselt wird das über common/archcompat.h, da wird z.B. unser IN_ROM_STR(s) in das AVR-spezifische PSTR(s) gewandelt, wenn ein AVR verwendet wird.
Die große String-Tabelle, die von command_to_name() verwendet wird, liegt schon im Flash, da kann man kein RAM mehr sparen. Siehe auch firmware/cmdnames.c. Der von command_to_name() gelieferte String liegt aber wie Du richtig erkannt hast, im RAM. Dazu gibt es in cmdnames einen Puffer von STRLEN (=10+1) Bytes RAM und command_to_name() holt den passenden Namen aus dem Flash und kopiert ihn in diesen Puffer im RAM, damit spätere Funktionen (wie z.B. strcpy) den String dort vorfinden, wo sie ihn erwarten: im RAM. Was man nun machen könnte, ist STRLEN zu reduzieren und dadurch auf die Unterstützung von langen Befehlsschreibweisen zu verzichten: bei einer echten Floppy löscht man Dateien üblicherweise mit dem S-Befehl. Man kann den Befehl aber auch ausschreiben und SCRATCH FOO sagen, so unterstützt das auch die XD-2031 firmware. Wenn Du STRLEN nun auf zwei reduzierst (z.B. für CD), könnte man damit immerhin 8 Bytes RAM sparen.
Ein return IN_ROM_STR("foo") würde nicht funktionieren, da ein Zeiger auf RAM erwartet wird, IN_ROM_STR() aber auf etwas im Flash verweist. Das compiliert nur deshalb ohne Fehler, weil der Compiler nicht erkennen kann, was erforderlich ist und was geliefert wird. Einfach gesprochen sieht der nur Adressen, kann aber nicht wissen, ob diese Adresse z.B. 0x0834 nun im Flash oder im RAM liegt.
Hast Du im xs1541-Makefile MCU angepasst? Müsste 328p für Dich sein.
In der config.h musst Du noch F_CPU auf die verwendete Takt-Frequenz anpassen.
In hwdefines.h musst Du dann noch die Port-Belegung entsprechend anpassen, falls nicht schon geschehen.
http://larswad.github.io/uno2iec/
Scheint nach gerade mal 6 Monaten aber schon wieder tot zu sein. Seit Dezember 2013 tut sich da nichts mehr.
Dezember 2013? Zuletzt wurde am 3. Juni 2014 daran gearbeitet. Vielleicht ist es ja doch noch nicht ganz tot.
Hallo Roman,
an Eclipse soll es nicht scheitern: das kannst Du durch jeden anderen Editor Deiner Wahl ersetzen. Die Taktfrequenz der MCU ist auch eher nebensächlich, solange die MCU in der Lage ist, zuverlässig bei 115200 Baud Daten zu übertragen, wovon ich bei einem Arduino-Board einfach mal ausgehe. Aber leider hat der AVR des Nano V3 nur 2 KB RAM, was für XD-2031 in seiner derzeitigen Form zu wenig ist: 2471 Bytes plus ein paar mehr für den Stack werden momentan verlangt.
Im Gegensatz zu uno2iec unterstützt XD-2031 neben dem Server (PC) auch direkt an die MCU angeschlossene Datenträger, sprich: SD-Karten. Damit nun Daten zwischen den beiden transferiert werden können, sind ein paar Puffer (sprich: RAM) auf dem Gerät notwendig. Man müsste die Software etwas skalierbarer machen (optional Einzelteile des Codes von der Firmware in den Server schieben), um am Ende auch Geräte wie das Nano V3 mit sehr wenig RAM und ohne direkt angebundene Massenspeicher zu unterstützen.
Einfacher dürfte sein, ein größeres Board wie den Arduino Mega zu verwenden, oder sich ein XS-1541 auf einer Lochrasterplatine zurecht zu basteln. Oder etwas Geduld mitbringen und auf mein neues petSD warten 
Nils
Das sind tolle Neuigkeiten! Vielen Dank!
Läuft der 8296 denn, wenn Du probehalber am EPROM Pin 1 mit Pin 28 brückst? Das muss ja nicht gleich verlötet sein, für ein Einschalttest sollte "irgendwie antüdeln" schon reichen.
Schon direkt den zum Brennen verwendeten: Fujitsu MBM27128
Gestern konnte ich ein originales MOS ROM 324746-01 mit meinem ALL-03 EPROM-Brenner einlesen. Das eingelesene Abbild habe ich dann in ein Fujitsu MBM27128 NMOS EPROM gebrannt und im 8296 getestet: der funktioniert damit einwandfrei. Andere Typen von 27128 habe ich leider zum Vergleich nicht da.
Allerdings ist mir aufgefallen, dass die Position von 4KB-Seiten innerhalb des 16KB-EPROMS sich zu dem 324746-01.bin-Abbild auf zimmers unterscheidet. Der Inhalt ist identisch, aber anders angeordnet. Wenn man also das Abbild von zimmers in ein EPROM brennen würde, würde das im 8296 nicht laufen.
Ich habe dann noch Edilberts Quelltext des 8296-Betriebssystems so angepasst, dass es direkt zwei EPROM-Images als Ergebnis der Assemblierung ausspuckt, damit kann man nun das Betriebssystem nach Herzenslust patchen:
https://github.com/Edilbert/C8296
Der schon vorbestückte Spannungsregler wurde nach einigen Sekunden Betrieb sehr heiss.
Ich finde die Spannungsregelung ohnehin recht fragwürdig. Alle, deren Datenblätter ich bislang gesehen habe, wollten immer noch Kondensatoren an Ein- und Ausgang haben, die auf der Platine in unmittelbarer Nähe zum Regler zu platzieren sind.
Auf der Platine (Lötpads) messe ich zwischen dem unteren mittleren Pad und dem einzelnen oberen Pad Durchgang. soll das so sein?
ähm... welche Pads jetzt genau? Kannst Du die mal im Bild kennzeichnen?
Weiss jemand, wo ich ein derartigen Spannungsregler herbekomme / um was für einen Typ es sich handelt?
Das könnte ein Reichelt LT 1117 CST-3.3 sein, gibt's bestimmt auch irgendwo billiger. Was steht denn auf dem verlöteten Chip?
Die Platine ist doch von sinchai.de, oder? Dann fragst Du am besten mal den Donald, was da los ist.
Die SoftROM-Webseite ist online.
Ich muss mal endlich eine Webseite für das SoftROM machen, das Christian und ich entwickelt haben. Und an dieser Stelle noch mal Werbung dafür machen!
Das ist eine kleine Platine, die nur unwesentlich größer als ein ROM ist, in einen Erweiterungs-ROM-Sockel eingesteckt wird und beide ROM-Sockel mit Inhalten versorgen kann.
Eine Bestückungsmöglichkeit ist mit batteriegepuffertem RAM. Dann legt man einen Schalter um, um Schreibzugriffe auf das SoftROM zu erlauben, gibt ein LOAD"ROMIMAGE",8 und deaktiviert die Schreibzugriffe wieder -- fertig ist das Erweiterungs-ROM! Durch die Batterie bleibt der Inhalt natürlich auch nach dem Ausschalten erhalten.
Eine andere Bestückungsmöglichkeit ist mit EEPROM, diese können über eine bestimmte Zugriffs-Sequenz schreibgeschützt werden, so dass kein Schalter zugänglich gemacht werden muss. Als Nachteil können diese allerdings nur mit einem Programm und nicht mit LOAD beschrieben werden.
Platinen habe ich noch da, falls jemand Interesse hat.
Herzlichen Glückwunsch zur erfolgreichen Reparatur!
Eine Lösung zum Austauschen von Daten zwischen Mac und CBM fehlt mir noch. Das wird dann das nächste Bastelprojekt.
Da Du ja schon einen Arduino Mega besitzt, dürfte das einfachste sein, den IEEE-Bus direkt an den Arduino zu hängen, wie das beim XS-1541 gemacht wurde. Die XD-2031-Firmware ist dann schnell angepasst. Damit könntest Du Deinen Mac wie eine CBM-Floppy am CBM-Rechner benutzen und entsprechend leicht Daten hin- und her schieben.
Glückwunsch zur erfolgreichen Reparatur!
Da hast Du ja wirklich ein Schnäppchen gemacht und handwerkliches Geschick bewiesen.
Ich schließe mich toast_rs Meinung an, dass man so mit der Platine nichts anfangen kann. Das ist nur ein Fragment, ein wesentlicher Teil fehlt.
Was es denn nun eigentlich war, kann ich leider auch nicht sagen.
Meiner Meinung nach ist diese Platine ein Bindeglied zwischen CBM und externer Hardware, die eigentliche Erweiterung bzw. das Peripheriegerät wurde offenbar extern angeschlossen.
Ich habe mich zwecks der beiden EPROMs aus meinem CBM 4032 an den einstigen Entwickler, Andreas Dripke, gewandt. Von Ihm habe ich nun die offizielle Erlaubnis, den Inhalt der ROMs auszulesen und der Community zur Verfügung zu stellen.
Der eigentlich interessante Teil wird quasi nur in einem Nebensatz erwähnt... berichte doch mal genauer! Was hast Du ihm geschrieben? Wie war seine Reaktion? Besitzt er vielleicht selbst noch Unterlagen oder Materialien aus der Zeit?
Dazu werde ich mir wohl einen kleinen Adpater für meinen EPROMER basteln, um die 2532 auszulesen.
Wenn Du eine Möglichkeit hast, Dateien zwischen CBM und PC zu tauschen, kannst Du Dir diese Mühe sparen. Mit dem eingebauten Monitor TIM lassen sich Speicherbereiche abspeichern, damit kannst Du also im eingebauten Zustand auslesen.
Schlucken die wirklich bis zu 80mA wenn die aktiv sind? Falls ja, kann ich keines der Arduino-Pins als +5V nehmen, die liefern maximal 40mA.
Nein, nicht "bis zu", sondern sogar typischerweise 80 mA laut Datenblatt. Die Maximalangabe liegt sogar bei 160 mA. Logik-Ports als Spannungsquelle missbrauchen zu wollen ist also eine ganz schlechte Idee. Selbst wenn Du da etwas ausliest, würde ich den gelesenen Daten kein Vertrauen schenken.
Die ROMs habe ich bereits ausgelesen, auch ein Scan des Handbuchs liegt vor.
Ist allerdings etwas groß, deshalb bei Interesse PN.
1. Ist der "FLASH CODE" auch für die 4040 Floppy anwendbar?
Die Maintenance-Unterlagen beziehen sich nämlich auf die 8050 bzw. 8250.
Da die beiden Floppies sich sehr ähnlich sind, würde ich aus dem Bauch heraus mit "ja" antworten.
Sicher ist das allerdings nicht, und in meinen Unterlagen habe ich keine Angaben zu 4040 flash codes gefunden. Wenn Du es genauer wissen möchtest, könntest Du den Quellcode des 4040-ROMs analysieren (hier oder hier) und dort nachsehen, was die Floppy genau testet und wie sie rückmeldet. Allerdings ist das Typenschild "4040" bei Commodore lediglich eine Aussage über eine gewisse Wahrscheinlichkeit, welches Board mit welcher ROM-Version innen verbaut sein könnte, so dass noch zu prüfen wäre, ob das bei Dir verbaute ROM das selbe ist, zu dem das Disassembly vorliegt.
2.Kann man einen defekten RAM-Baustein mit üblichen Meßmitteln - da nach dem Code 2 RAMs in Frage kommen- lokalisieren?
Es wäre zu einfach gewesen, wenn man die beiden LEDs der Laufwerke zu Hilfe genommen hätte, das defekte Nibble anzuzeigen. Du könntest versuchen, über Temperaturentwicklung oder mit der Huckepack-Methode einen defekten 2114er zu indentifizieren, allerdings hat das bei mir bei 2114 RAMs noch nie funktioniert. Wobei eine 50:50 Chance ja gar nicht soooo schlecht ist...
Zwar ist es überaus wahrscheinlich, dass eines der 2114 RAMs defekt ist, es könnte aber auch sein, dass der Fehler tatsächlich in den MUX-Bausteinen liegt, die das RAM beiden 6502/6504 zur Verfügung stellen.
Wenn Du nicht auf gut Glück Bausteine tauschen möchtest, wäre es bestimmt möglich, mit einem PETvet einen Testcode in die Floppy zu laden und dort direkt genauere Tests durchzuführen. In "fix und fertig" gibt es das aber leider noch nicht, das müsstest Du erst selbst entwickeln.
178 Euro... ohne Worte!
Normalerweise gehen diese Laufwerke für deutlich unter 100,- Euro weg. Allerdings wird es immer schwieriger, welche zu bekommen, die tatsächlich auch noch funktionieren, so dass der Preis nicht ganz aus der Luft gegriffen ist. Viel höher würde ich aber nicht gehen.
Die Anzahl des Blinkens sollte Aufschluss über die Fehlerursache geben: flash codes
