Hast du denn schon den entscheidenden Unterschied zum R4 gefunden, warum nur der R7 im P500 korrekt läuft?
Das muss ja was mit dem Vic2 Timing zu tun haben...
Meine Vermutung ist ja das R4 und R7 nur für den P500 entwickelt wurden. Im 6xx und 7xx läuft auch ein einfacher 6509 problemlos.
Im P500 haben sie ja das kernal mit mehrfach schreib Routinen gepatcht, aber mit R7 sind diese patches nicht mehr notwendig.
Einfach ... 
- 
Eindeutig: Das ist Leidenschaft, kein Asthma! 
- DER WAHNSINN! 
Ich habe keine Ahnung, bewundere aber Problem und Ergebnis. 
Hast du denn schon den entscheidenden Unterschied zum R4 gefunden, warum nur der R7 im P500 korrekt läuft?
Das muss ja was mit dem Vic2 Timing zu tun haben...
Meine Vermutung ist ja das R4 und R7 nur für den P500 entwickelt wurden. Im 6xx und 7xx läuft auch ein einfacher 6509 problemlos.
Im P500 haben sie ja das kernal mit mehrfach schreib Routinen gepatcht, aber mit R7 sind diese patches nicht mehr notwendig.
Ich hab' was gefunden... bin aber noch unsicher; ich muß erst meinen R4 wieder finden um das nachzumessen.
Momentan habe ich nur jede Menge R7 rumliegen und finde den einzigen R4 (den ich hatte) nicht mehr: Saustall im Labor!
Aber wie sehen denn die Patches aus?
Alles anzeigenHast du denn schon den entscheidenden Unterschied zum R4 gefunden, warum nur der R7 im P500 korrekt läuft?
Das muss ja was mit dem Vic2 Timing zu tun haben...
Meine Vermutung ist ja das R4 und R7 nur für den P500 entwickelt wurden. Im 6xx und 7xx läuft auch ein einfacher 6509 problemlos.
Im P500 haben sie ja das kernal mit mehrfach schreib Routinen gepatcht, aber mit R7 sind diese patches nicht mehr notwendig.
Ich hab' was gefunden... bin aber noch unsicher; ich muß erst meinen R4 wieder finden um das nachzumessen.
Momentan habe ich nur jede Menge R7 rumliegen und finde den einzigen R4 (den ich hatte) nicht mehr: Saustall im Labor!
Aber wie sehen denn die Patches aus?
Hast du den MockA65xx auch schon mal im P500 mit meinen Spielen (Pacman / WoW ) getestet?
Die laufen nämlich nur mit dem R7!
Das Registerschreiben funktioniert im P500 vor R7 nicht richtig. Also hat Commodore im kernal patches eingebaut, die so lange schreiben, bis der Inhalt drinnen ist. Das macht den P500 in basic sehr langsam, aber es läuft.
Sobald Assembler Programme direkt in den vic schreiben, treten div Grafikfehler auf - ist völlig unbrauchbar.
Erst mit R7 ist der P500 außerhalb basic/kernal nutzbar.
Ich hab das Kernal komplett auf Rev. 4a und ohne die schreibloops gepatcht - der sys Befehl war ja auch unbrauchbar.
Im 600,700 ist der 6509 ohne Rev. Vollkommen ausreichend.
Ich bin inzw. etwas weiter am Netzlistengenerator und habe mal ein Bild von dem Teil des Chips
gemacht, das für die Dekodierung der beiden Befehle für den zusätzlichen Addressraum
zuständig ist:
Beige - Gate/Channel (oder Kondensator!)
Rot - Drain/Source
Blau - Kontakt
Cyan - Polysilizium
Links oben sieht man auch, wo MOS etwas "getrickst" hat: Da sind zwei Kondensatoren um Steuersignale
zu verzögern. Vermutlich sind diese an dem Unterschied zw. R4 und R7 verantwortlich...
Genauere Infos gibt's sobald der Netzlistengenerator fertig ist.
PS: Die Differenzierung zw. Drain, Source, Kontakt etc. findet bereits automatisch statt.
Auch hier ein kurzes Update:
-
-
-
Drain, Source und Gates der FETs im Chip werden richtig erkannt!
Die Erkennung zusammengehörender Leitungen bzw. von leitendem Material auf EINEM Layer läuft auch;
habe damit einen satten Kurzschluß zw. VCC und GND im meiner MOS6509R7 Zeichnung gefunden.
In Kürze werde ich die Leitungserkennung verbessern, sodaß dann auch VIAs und sontige Kontakte
berücksichtigt werden; d.h. leitende Verbindungen zw. den Layern. Dann steht die Netzliste! 
Alles anzeigenDas Registerschreiben funktioniert im P500 vor R7 nicht richtig. Also hat Commodore im kernal patches eingebaut, die so lange schreiben, bis der Inhalt drinnen ist. Das macht den P500 in basic sehr langsam, aber es läuft.
Sobald Assembler Programme direkt in den vic schreiben, treten div Grafikfehler auf - ist völlig unbrauchbar.
Erst mit R7 ist der P500 außerhalb basic/kernal nutzbar.
Ich hab das Kernal komplett auf Rev. 4a und ohne die schreibloops gepatcht - der sys Befehl war ja auch unbrauchbar.
Im 600,700 ist der 6509 ohne Rev. Vollkommen ausreichend.
Mein R4 ist wieder aufgetaucht! Interessant der Date/Code:
01/83 für den R4... und die R7A sind sowohl vorher (50/82) als auch später (06/83).
Ich habe auch mal den 8726R1 der REU vektorisiert und auf gebürstetes Aluminium (als Wandbild) drucken lassen:
-
-
Das generieren der Netzliste funktioniert nun... in den nächsten Tagen geht's an den Export und
Simulation der Netzliste:
Jede Frabe steht für einen eigenen Knoten in der Netzliste. 
Zufällig ist blau in den meisten Fällen tatsächlich GND in diesem Fall.
Ich habe letzte Woche angefangen die generierte Netzliste zu simulieren... lief natürlich nicht. Wäre auch zu schön gewesen.
Beim simulieren fand' ich relativ schnell kleinere Fehler beim vektorisieren (vergessene Kontakte, Kurzschluß durch VIA an falscher stelle):
Trotzdem wollte die CPU nicht so richtig anlaufen. Wer die Reset-Sequenz des 6502 kennt: Nach dem Fetch des Vektors bei $FFFC/D
sollte es direkt mit dem Usercode weitergehen. Aber bei mir war nach der steigenden Flanke Clock der PC immer kaputt.
Wie sich durch händisches (mit Notizblock und viel Geduld/Frust) simulieren der Netzliste rausstellte hat der von mir verwendete
Simulator noch eine Schwäche: Er ignoriert Timings. Beispiel: Alle FETs, die durch einen Netzknoten gesteuert werden, sind
beim nächsten Durchlauf sofort ON/OFF während die echten eben gewisse Zeit brauchen (Gate Kapazität).
Das nächste was dann noch zu beachten ist: Absichtlich von MOS/CSG eingebaute Kondensatoren, um die Clocksignale
innerhalb des Chips zu verzögern. Dies wurde beim 8501 - aber auch bereits beim 6509 gemacht:
Wie geht's nun weiter? Ich werde die Simulation nun umbauen; d.h. eine eigene erweiterte Simulation bauen, die
Timings in gewissen bereichen beachtet und den Netzlistengenerator so erweitern, das er mir ausgibt, wenn solche
Kapazitäten detektiert werden.
Kleiner Nachtrag: Wenn ich an den bekannten Stellen die Signale selbst verzögere etc. läuft die simulierte CPU!
Sowas ärgert mich. Das taucht ja nicht nur in den CPUs auf, sondern auch ausserhalb der CPUs, wenn man RAM oder ROM anbinden will oder sonstwie auf dem Bus was machen will. die neuen WDC CPUs sind da ja besondere Diven, wie du weisst.
Aber auch bei Commodore wurden oft Tricks verwendet, um Systeme mit zwei Busmastern zum Laufen zu bekommen. ich kämpfe seit Jahren mit der Erweiterung meiner SFD-1001 und es klappt nicht, sobald ich mich "parallel" einklinken will. Jetzt habe ich im Schaltplan gesehen, dass da Chipselects nicht nur auf Phi2 sondern auch auf Phi0 oder 1 laufen, was da genau passiert habe ich keine Ahnung.
In der MSD-SD2, eine single-CPU Anwendung, geht gleich noch der doppelte CPU Takt mit ins Chipselect, muss also auch schon getrickst werden.
Sowas ärgert mich. Das taucht ja nicht nur in den CPUs auf, sondern auch ausserhalb der CPUs, wenn man RAM oder ROM anbinden will oder sonstwie auf dem Bus was machen will. die neuen WDC CPUs sind da ja besondere Diven, wie du weisst.
Ja... die WDC mag' ich u.A. deswegen nicht so.
Intern im 6502 haben die auch Schweinereien gemacht:
Salopp gesagt ist ja PHI1 nur ein Invertierter PHI0/2... nur das es eben eine Zeitspanne gibt, wo beide definitiv low sind.
Aber intern haben die im Chip Anstatt PHI0/2 ein invertiertes PHI1 erzeugt, weil dies eben etwas früher auf High/low geht
als PHI2. Und die $0/$1-Register des 6510/8501/6509 werden mit im Vergleich stark verzögerten PHI1/2 Signalen gefüttert
um die internen Setup/Hold-Zeiten des Datenpfad-Eingang einzuhalten. Autsch!
Für die Simu habe ich ja den Code vom "Visual6502" hergenommen... meine Annahme war: Bei so vielen Transistoren
und nach 10 Jahren wären Probleme bekannt bzw. äußerst unwahrscheinlich, das hier ein PRoblem noch auftritt.
Aber Murphy lebt halt immer noch....
Alles anzeigenAlles anzeigenDas Registerschreiben funktioniert im P500 vor R7 nicht richtig. Also hat Commodore im kernal patches eingebaut, die so lange schreiben, bis der Inhalt drinnen ist. Das macht den P500 in basic sehr langsam, aber es läuft.
Sobald Assembler Programme direkt in den vic schreiben, treten div Grafikfehler auf - ist völlig unbrauchbar.
Erst mit R7 ist der P500 außerhalb basic/kernal nutzbar.
Ich hab das Kernal komplett auf Rev. 4a und ohne die schreibloops gepatcht - der sys Befehl war ja auch unbrauchbar.
Im 600,700 ist der 6509 ohne Rev. Vollkommen ausreichend.
Mein R4 ist wieder aufgetaucht! Interessant der Date/Code:
01/83 für den R4... und die R7A sind sowohl vorher (50/82) als auch später (06/83).
Gibts eigentlich schon Neuigkeiten?
Mich würde ja wirklich mal interessieren, was mos vom R4 zum R7 verändert hat, das die CPU im P500 ordentlich läuft!
Christian
Gibts eigentlich schon Neuigkeiten?
Mich würde ja wirklich mal interessieren, was mos vom R4 zum R7 verändert hat, das die CPU im P500 ordentlich läuft!
Christian
Timing fixes in der Banking logik.
Nächste woche veröffentlichen wir den Schaltplan mit den Änderungen gegenüber dem 6502
Alles anzeigenGibts eigentlich schon Neuigkeiten?
Mich würde ja wirklich mal interessieren, was mos vom R4 zum R7 verändert hat, das die CPU im P500 ordentlich läuft!
Christian
Timing fixes in der Banking logik.
Nächste woche veröffentlichen wir den Schaltplan mit den Änderungen gegenüber dem 6502
OK, toll, das ist wohl die Erklärung warum nur der R7 im P500 vernünftig läuft.
Ein Bekannter aus Italien hat bei Jim Brain einen NU6509 für seinen P500 bestellt, da er nur einen R4 hat.
Aber Jim hat geschrieben das er Probleme mit der "Fertigung" hat ?
Abgesehen davon hat er ihn aber auch im P500 noch gar nicht getestet...
Ich hoffe ja auf deinen 6509 Ersatz für die Zukunft 
Christian
Ich mache das Teil in Kürze fertig... liegt ja nun alles vor was ich brauche.
Hast du schon mal ein Foto als Teaser
Sobald ich dran gehe mache ich Bilder...
und dann muß ich noch jemand suchen der Bock hat das Teil zu testen
was müsste man dazu tun?
erledigt, habe keinen Solange es keinen Nachbau gibt
in einem P500 testen mit möglichst vielen Programmen
Das ist gut
Für den P500 gibt es keine Software 
Nur die beiden Spiele, die ich umgeschrieben habe, die kleine Demo von David Viner, die Demo von Commodore und das von mit vollendete cbm-Diagnose Programm.
Aber ich könnte das gern machen. Ich kann ihn dann auch im US und EU P500 testen. Die haben ja einen anderen VIC und damit Takt - wie auch im 64.
PS: Vielleicht irgendwann noch Fort Apocalypse - wenn ich die bugs finde
PS: Und natürlich muss man mit meinem schnellen Kernal 4a testen, damit man ggf. auch die vor R4 Probleme findet.
Christian
keine Programme? dann lohnt sich der Aufwand ja gar nicht
Na ja, der ist ja hauptsächlich für die 6xx und 7xx - da gibt es ja einiges an Anwendungssoftware und ein Spiel: Space Chase
Mit der 8088 Karte wird das doch direkt wieder kritisch.
