Sooo schlimm sieht die Platine gar nicht aus - sollte sich eigentlich ganz gut reingineeren lassen... (...wenn ich nur mehr Zeit hätte...)
Hab ich mir auch gedacht, das wäre machbar.
Das Schaltbild habe ich ja auch.
Aber da ich ja ein funktionierendes Modul habe, ist die Motivation nicht so besonders groß. 
Vor Jahren habe ich mir bei PCBWAY eine Platine fertigen lassen: C64 Expert Cartridge Replica
Leider habe ich die Gerber Datei nicht archiviert.
Es war so ein "shared Project" bei PCBWAY.
Da kann man mit einem Klick Platinen bestellen.
Das hat auch gut funktioniert, die Cartridge funktioniert heute noch tadellos.
Nun fragen mich Forums Mitglieder nach dieser Platine.
Den Link auf das PCBWAY Projekt habe ich noch.
Leider wurde das Projekt gelöscht.
Den User RETROTINKER gibt es noch.
Aber es gibt keines seiner PCB Projekte mehr!
Alle Spuren bei PCBWAY wurden auch gelöscht, da kann ich nichts mehr finden!
Google habe ich auch schon bemüht.
Es findet sich aber nur noch minimale Infos und zumindest ein Schaltbild.
Hat einer von euch bitte diese Gerber Datei?
Ich finde es schade, wenn tolle Projekte einfach verschwinden!!
Zumindest habe ich noch Fotos.
So sieht die Platine aus:
Vielleicht sollten wir hier alle Replica PCB Dateien sammeln?
Es ist ein SpeedDOS+, ein sehr guter Speeder.
Aber man muss im C64 einen passenden Kernal haben.
Wenn ich mir das allerdings mit EPROM's vom anfangs verfügbaren Typ 1702 (256x8) vorstelle (ab 1971), dann müssten das 48 Stück gewesen sein und die waren damals auch nicht so günstig.
Mal davon abgesehen ist die Ansteuerung der EPROMs ja ganz anders. Da braucht es wohl zusätzlich Hardware um das anzupassen.
Aber schon so mit Tasten und Schaltern, als eigenständiges Gerät. Wenn ich auf dem Seziertisch dann wieder einen Laptop brauche um ein Laufwerk Steppen zu lassen, ist das Thema verfehlt
Wenn man es mit einem Arduino umsetzt, dann würde ja das Eine nicht das Andere ausschließen.
Man könnte ein paar Taster und Schalter und LED für den standalone Betrieb haben. Und zusätzlich einen Zugriff per Laptop, wo man etwas mehr machen kann und bessere Diagnose Infos erhält.
Der Prototyp des Fädel-ROM wurde angeblich aus über 1.500 m Fädeldraht hergestellt, was 6,5 Wochen dauerte...
Was für eine Verbesserung da ein PROM dargestellt hat.
Und erst recht eine EPROM!
Konkret geht es um 6510 Assembler (C64).
Die Motorola 6809 hat mit relokatiblen Code kein Problem.
Insofern kann ich da Code schreiben, der an jeder Adresse laufen kann.
Mich interessiert, was man in dieser Richtung mit der 6502/6510 machen könnte, trotz aller Einschränkungen dieser Architektur.
Sagen wir mal, da ist ein Maschinen Programm, das an die falsche Adresse geladen und da gestartet wird.
Was für Möglichkeiten hat der Code?
Es ist für eine 6502 CPU ja nicht mal möglich herauszufinden, an welcher Adresse ich gerade laufe.
Oder doch?
Vorschlag 1:
Geht es irgendwie anders vielleicht besser oder einfacher?
Dabei handelt es sich um einen programmierbaren Tischrechner in DTL-/TTL-Logik mit 2-zeiliger Nixie-Röhrenanzeige, Kernspeicher und handgefädeltem Microcode-ROM.
Hat die TTL CPU den Microcode direkt aus dem Fädel ROM ausgeführt???
Oder ist das eher als "Massenspeicher" zu verstehen.
So dass der Microcode quasi erst in ein RAM geladen wurde?
Und es ist ein prinzipiell leicht änderbares ROM, da die Drähte nicht wie bei manchen Fädelroms durch Ringkerne gesteckt sind.
An Wang als "Erfinder" des Ringkernspeichers hat da schon wirklich immer einen "Plan" gehabt.
Nun ja ...
Schlagzeile: Mitarbeiter haut einem Programmierer eine Fädel Baugruppe um die Ohren!
Wow, coole Sache.
Nicht nur, dass man eine Ersatzlösung hat für den V9958.
Man hat auch noch eine HDMI Lösung für Computer die diesen Chip einsetzten.
Ob man sowas auch machen kann mit dem VIC?
Dann hätte man endlich eine einfache und saubere Lösung den C64 an moderne Bildschirme anzuschließen.
Der VIC ist halt sehr komplex mit den Sprites und all dem.
Oder für den 6545?
Gut das geht sicher relativ simpel.
Super Leistung, wirklich klasse!
Aber die OS9 MMU, - nun ja, das hat mit MMU nix zu tun.
Das ist einfach nur ein simples Banking.
Dieses Konzept hätte man konsequent weiter führen müssen.
Eine MMU 6829 mit 2MB physikalischem Adressraum.
Der PET Adressraum ist dann einfach ein Fenster im physikalischen Adressraum.
Die Funktionen die der PET bietet, wären dann device driver.
Nun ja, das 6502 Badge liegt schon viel zu lange herum ...
Aufgebaut, funktioniert auf Anhieb!
Als Badge etwas klobig ...
Aber sonst ein richtig nettes Spielzeug:
Fraglich bloß, weshalb es beim 64er damals nicht ging?
Nun ja der C64 hat einen LOAD Befehl, der etwas anders arbeitet als beim PET
Das Listing besteht aber nur aus einer Zeile mit dem SYS-Befehl:
Das macht nichts.
Auch wenn da nur eine BASIC Zeile ist.
Das BASIC schützt das GESAMTE Programm das geladen wurde.
Und beim SAVE wird auch das gesamte Programm wieder geschrieben.
Du kannst es ja mal laden von Disk und wieder speichern auf Disk.
Dann siehst du, dass zwei idente Dateien da sind.
Man darf nur kein UNNEW machen.
Denn dann setzt dies den Programm Ende Pointer auf das Ende der letzten BASIC Zeile,
Nun, wenn der AllProg die Lösung ist, - prima.
Aber eine Adapter Platine wäre an sich nie ein Fehler.
Wer weiß wie lange die PROM noch erhältlich sind.
Ich könnte mir vorstellen, dass man hier ein GAL einsetzen könnte.
Nun ja, die Dinger sind ziemlich schnell ... 50nS
Selbst moderne Flash Speicher sind mit 70nS zu langsam.
Was bedeutet bipolar?
Vielleicht kann man sich einen Adapter basteln und damit die PROM ersetzen durch ein gängiges EPROM?
Da die Adresse ja $0401 ist (BASIC Start beim CBM), müsste auch ein einfaches
genügen, um das File "PROG" von Diskette auf Kassette zu kopieren.
Das geht natürlich nicht, wenn die Ladeadresse nicht gleich $0401 ist.
Und selbst, wenn es dann funktioniert- wie lade ich das Programm dann?
Über LOAD"NAME" oder nur im TIM?
Du kannst alles was du im TIM speicherst ganz normal mit LOAD wieder rein laden.
Und umgekehrt auch.
Der Unterschied liegt nur im SAVE.
Beim TIM kann man einen Adress Bereich angeben, beim SAVE nicht.
Nimm ExMon, der kann Assembler Programme auf Tape speichern.
Ich denke sogar der interne TIM kann das.
Coole Sammung! Beim Anblick der Lautsprecher so nah an den Rechnern wird mir allerdings ganz komisch im Bauch.
Die Nähe zu Rechner macht nichts.
Aber Floppy Laufwerke nehmen das u.U. schon krumm, weiß ich aus eigener Erfahrung ...
Cool wäre eine Hardware die FORTH unterstützt.
Eine Stack CPU ...
Die aktuelle Release Version v1.13 ist verfügbar:
Die fertige Version hat nun noch folgende Features:
Die Idee hinter den UCF Dateien ist, es enthält alle Infos, damit ein Programm korrekt geladen und ausgeführt wird.
In etwa wie eine CRT Datei für den VICE.
Die CSV Datei wird dadurch ganz einfach.
Menüname und Pfad zur UCF Datei, und gut ist.
Sogar der Menüname ist optional, weil in der UCF Datei steht drin wie das Programm heißt.
Man muss sich also keine Gedanken machen, wie das Programm geladen wird und wie es gestartet wird.
Es sind auch die optionalen Level nicht schlecht.
Zum Beispiel der Barrel Shifter.
Meine ersten Versuche sind gleich ausgeartet und unübersichtlich geworden.
Aber dann habe ich die "Custom Components" entdeckt.
Da sieht die Sache gleich besser aus:
Mmh. Ich habe früher viel Reverse Engineering auf 8-Bit-Systemen gemacht und ich würde spontan sagen: Sehr, sehr aufwändig.
Liegt denn wenigstens ein Schaltplan der Steuerung vor?
Ich gebe dir recht, reverse Engineering ist extrem aufwendig.
Aber solche Sachen können mit etwas Intuition sehr einfach sein:
Ich möchte die Arbeit nicht klein reden.
Aber die Bedingungen finde ich günstig.
Ist das bei euch auch so?
Nee, die LED funktionieren tadellos.
Inzwischen geht auch der Code.
Ist allerdings nicht meiner.
Hab jetzt irgendwo gelesen, der Emulator kann nicht mit selbst modifizierenden Code umgehen.
Deswegen ist mein Code wohl nicht gelaufen.
Network Code - Achtung Spoiler:
# Allocate space for variables.
DEFINE sync 50
DEFINE counter 51
DEFINE y 52
DEFINE currentLine 53
DEFINE networkWire 0x6001
# (There's no particular reason
# I chose slots 50–53.
# More detailed descriptions below)
# Initialize sync variable.
# This variable will hold the
# most recently measured value of
# the sync bit, not the sync bit
# (which is at address 0x6001)
# itself. That means that between
# the time that the real sync bit
# changes and the time that this
# variable is updated to reflect
# that, their values will
# be different
A=0b10
D=A
A=networkWire
D=D&*A
A=sync
*A=D
# Initialize y.
# This variable will hold the
# y-coordinate of the line on the
# display screen on which we will
# next print
A=0x4000
D=A
A=y
*A=D
# This code reads and prints lines
# until message has terminated
#~~~~~~~~~~
LABEL LineReaderPrinter
# Wait for control bit. If sync bit
# changes whilst waiting for
# control bit, the message
# has terminated
#----------
LABEL WaitingForControlBit
# Check sync bit
A=0b10
D=A
A=networkWire
D=D&*A
# Jump to end if different
# from most recent sync bit value
A = sync
D=D-*A
A=End
D;JNE
# Check data bit
A=0b1
D=A
A=networkWire
D=D&*A
# Begin when data bit is 1
A=WaitingForControlBit
D-1;JNE
#----------
# Initialize line to 0 (blank).
# After 16 bits have been read,
# the line will be printed
A=currentLine
*A=0
# Initialize counter to 0.
# This variable will count how
# many bits of the current line
# have been read thus far.
A=counter
*A=0
# The code below reads 16 bits
#••••••••••
LABEL notFinishedLine
# Wait for sync bit to change
#…………………………
LABEL syncStillSame
# Get sync bit
A=0b10
D=A
A=networkWire
D=D&*A
# Compare to current sync variable
A=sync
D=D-*A
# Check whether it has changed
A=syncStillSame
D;JEQ
#…………………………
# Once sync bit changes,
# update sync variable
A=0b10
D=A
A=networkWire
D=D&*A
A=sync
*A=D
# Read data bit
A=0b1
D=A
A=networkWire
D=D&*A
# Add bit to line
A=currentLine
*A=D+*A
# Shift all bits in current line
# one space to left to make room
# for next bit (this is equivalent
# to doubling the binary value of
# the current line)
D=*A
*A=D+*A
# Increment counter and check
# whether all 16 bits have
# been read
A=16
D=A
A=counter
*A=*A+1
D=D-*A
A=notFinishedLine
D;JGE
#••••••••••
# Set value of display address
# specified by y to the value of
# the line that was just read
A=currentLine
D=*A
A=y
A=*A
*A=D
# Set y-coordinate of next line
A=0x20
D=A
A=y
*A=D+*A
# Start next line
A = LineReaderPrinter
JMP
#~~~~~~~~~~
LABEL EndBis auf "Network" hab ich jetzt alle Level.
Den letzten krieg ich irgendwie nicht gebacken.
Oh Mann, ein Prozessor mit nur zwei Registern ist echt anstrengend
Ja das ist echt herausfordernd ...
Speziell da ein Register eigentlich nicht zählt, man braucht es ja immer sobald Adressen im Spiel sind.
Hinzu kommt 'immediate' geht auch nur mit dem Adress Register.
Aber die Stack Machine hebt dann alle Beschränkungen auf.
Ne, noch bei Levels - Processor - Computer.
Ah das Ding ...
Sieht nicht gut aus, funktioniert aber. 
Bis Computer bin ich auch gekommen.
Irgendwie komme ich mit dem Edit ROM nicht klar. Und beim Check kommt eigentlich immer die gleiche Fehlermeldung.
Kannste mir da ein Tipp geben?
An du meinst Levels -- Software -- Low Level -- Machine Code??
Ganz ehrlich?
Ich hab einfach nur herum probiert.
Solange bis es geklappt hat.
Aber das kannst du auch getrost überspringen.
Interessant wird es eh erst danach.
Mit dem Assembler.
Die Bit Ebene des Microcode ist sogar mit zu hart.
Danach wird es richtig gut!
Der baut eine Stack Machine auf.
Eine Art FORTH.
Genial!
Es gibt sogar einen Tokenizer und einen Syntax Ruler.
