Es gibt inzwischen für den C128 RGBI/VDC-zu-HDMI eine Hardware-Lösung mit einem "RGBtoHDMI"-Adapter mit Raspberry (für 99 USD):
[Link: Please login to see this link.]
Die Hardware-Lösung wurde auch auf github.com veröffentlicht unter:
[Link: Please login to see this link.]
Es gibt inzwischen einen Replica-Chip für die Chips Please login to see this link..
Dieser Replica-Chip ist mit diversen 8-/16-Bit Computern und Peripherie-Geräten kompatibel.
Please login to see this attachment.
Diesen kann man für 27,95 USD (+Versand) unter dem folgenden URL bestellen:
Please login to see this link..
glaube aber mal die Story gehört zu haben, das C= irrtümlich einen Sockel zuviel im 128er eingesetzt hatte, und da das entfernen zu aufwendig war, knallte man da den Z80 rein..
Als "Story" oder Z80-Bashing nett.
Was gegen diese Geschichte spricht:
- Mainboards werden nach einem Schaltplan geroutet. "Bauteile zu viel" kann es nicht geben.
- Derjenige, bzw. bei CBM diejenige, die das Layout machte, war am Schaltungsdesign nicht beteiligt. Das war reine "Zeichenarbeit": Wieso sollte sie einen zusätzlichen Sockel einplanen, noch dazu genau so, dass alle Busleitungen usw. dort ankommen?
- Der Aufwand, den Sockel rauszuzeichnen, ist minimal gegenüber dem Zusatzaufwand, den Z80 in das System einzubringen. Man sehe sich nur den ganzen TTL-Kram an, der dazu notwendig war. Das macht man nicht, nur weil ein Sockel "übrig" ist.
- Der übrige Sockel muss gar nicht "rausgezeichnet" werden, einfach nicht bestücken. Siehe TTL-IC beim 250466, das dann nicht bestückt wurde.
- CBM hat sicher kein Bauteil zu viel (noch nicht mal einen Kondensator) irgendwo eingebaut.
Es gibt aber eine weitere Story, nach der die Australische Niederlassung angedroht hat, persönlich jeden einzelnen Z80 aus den C128 rauszureißen, bevor sie verkauft werden würden. Das wäre kein Problem gewesen - Z80 raus, Pin 43 der MMU durchkneifen - C128 rennt ohne Z80.
Soweit ich das beim C128 verstanden habe gibt es zur Z80 CPU noch ein BIOS ROM, das dann nach der Deaktivierung/Entfernung vom Z80 auch nicht gebraucht würde...
Super ! Und Danke für die Info's/Hinweise.
Also tatsächlich ein Pre-C128 Computer (ohne Z80 / CP/M).
Also, ein C128 ohne Z80 / CP/M wäre wirklich viel besser gewesen, denn für die meisten Anwender war Z80 / CP/M ein wirklich unnützer Ballast , der wirklich (fast) nie sinnvoll genutzt wurde.
Gut wäre es, wenn man einen C128-Mod ohne Z80 / CP/M machen könnte....
Sozusagen einen "C128 Lite" (ohne Z80 mit Hardware- und ROM-Patch).
Vieleicht hat hier jemand Ideen dazu, wie man das (mit einem neuen C128 Replica-Board) machen könnte...
Das scheint ein erweiterter C64 mit SID/CIA 6526/abwärtskompatibler CPU 7502 zu sein.
Auffällig ist zusätzlich zum normalen Basic-Rom das deutlich erweiterte Basic-Roms mit 2x zusätzlichen Roms mit 2x 16 Kb.
Auch der Grafik-Chip 6545 (CTRC) für die 80-Zeichen-Anzeige ist speziell. Der VIC II ist nicht auf den 5 von 6 vorhandenen Schaltpläne vorhanden.
Es fehlt bei den Schaltplänen leider noch der Teil 5 von 6...
Es gibt von Verbatim die Spezial-BD-R-Medien mit dem Namen "Verbatim Archival BD-R 25 GB".
Gemäß dem Hersteller soll bei diesen Medien die erwartete Lebensdauer 1.332 Jahre betragen !!!
Also gut geeignet für Langzeitarchvierung...
[Link: Please login to see this link.]
Eine Windows 10 Iot LTSC Installation, für die man zum aktivieren ein Aktivator-Programm braucht, kann nie legal sein.
Wenn jemand wirklich, so wie ich, weiterhin mit Windows 10 ganz legal und stabil bis 2023 nutzen oder professional arbeiten will, so kommt man am Kauf einer offiziellen Lizenz nicht vorbei...
Das günstigste Angebot, das ich gerade entdeckt habe ist das folgende:
Microsoft 10 IoT Enterprise LTSC 2021 für 2x PC (124,85 €)
Hallo,
Hier gibt es noch weitere, wenige Info's zu Commodore Computer und Chip-Releases mit Angabe des jeweiligen Produktions-Erscheinungsjahres:
Please login to see this link.
Viele Dank für die zahlreichen Rückmeldungen.
Ich werde mir wohl die WUSDN IDE anschauen, da ich Eclipse als Entwicklungsumgebungen generell vorziehe...
Nein, Notepad++ ist nicht der falsche Editor. Den nutze ich auch für meine umfangreichen Projekte.
Viele sind Fans von folgenden Editoren/Entwicklungsumgebungen:
Der erste Editor gefällt mir überhaupt nicht, so wie er konstruiert ist, - und - die beiden weiteren Entwicklungsumgebungen haben zwar hilfreiche integrierte Tools, aber sind sehr proprietär (kein Open-Source) mit unschönen Limitierungen.
Von daher nehme ich als erfahrener Entwickler aktuell nur Notepad++ zusammen mit acme.
Ideal für mich wäre die Eclipse Ide mit C64/6502 Plugins (Professionelle Entwicklungs-Ide mit Plugins für C/C++, Java, ... / Open Source).
Wichtig aber für erste Test-Programme ist eher, dass man eine Standard Basis Code-Vorlage verwendet (Basis BASIC-Code mit "Sys xxx") mit Übergang von BASIC- auf Assembler-Code, sodass man dein Testprogramm sehr einfach addieren kann.
So wird das Testen von experimentellen Code wirklich sehr einfach.
Und das mit acme und den Fehlermeldungen ist ein komplett anderes umfangreiches Kapitel, womit ich am Anfang nach über 30 Jahren C64/6502 Assembler-Abstinenz auch diverse Probleme hatte.
[Wegen weiterer Fragen zu acme/6502 bitte direkt PM an mich schreiben.]
Zum Thema "1541 Andruckfilz Reparatur" gibt es bereits einen älteren Beitrag von 2017, wo jemand einen sehr soften Möbelgleiterfilz von Obi gekauft hat. Dieser wurde dann von der Größe angepasst und dann mit Heißkleber in der Filzhalterung in der Floppy 1541 fixiert: [Link: Please login to see this link.]
Nun. Die A1500 Plus Gehäuse werden wohl nicht so oft verkauft, sodass es keinen Bestand auf dem Lager gibt. Aber Dragonbox ist der offizielle Distributor für diese Produkte in Deutschland, sodass man bei Dragonbox direkt eine individuelle Bestellanfrage bei Interesse stellen muss.
Da ist bei den Abstimmungs-Optionen wohl ein kleiner Fehler mit der Speichergröße unterlaufen !!!
Die Blizzard 1260 unterstützt nur RAM-Speicher im MB-Bereich.
RAM-Speicher im GB-Bereich, so ab 32 GB, unterstützen nur modernere PC's.
Aber hier die Info's zu meiner Blizzard 1260:
Display More
Eine Datei zum Schreiben kann per OPEN "<filename>,p,w" geöffnet werden.
Eine solche Datei sollte zweckmäßigerweise als SEQ-Datei mit "<filename>,S,W" abgelegt werden, da es sich eben - mangels Ladeadresse am Anfang - nicht mehr um eine PRG-Datei handelt!
RND Zufallszahlen mit den C64 CIA's funktionieren nicht gut ?!?!?!?
Doch !!! Es geht mit dem richtigen Code !!!!Anhand eines mit Zufallszeichen gefüllten Bildschirms läßt sich das nicht beurteilen. Klar: wenn da schon augenfällig eine nicht zufällige Verteilung sichtbar ist, kann der Generator nichts taugen; umgekehrt, wenn das scheinbar zufällig aussieht, heißt das noch lange nichts.
Im Thread hatte ich zuvor ja bereits geschrieben, daß es in Ordnung ist, wenn der Seed eines Generators einmalig timerbasiert und möglichst mit menschlicher Interaktion ermittelt wird. Damals sollte der Generator allerdings deterministisch arbeiten. Ansonsten kann die "Güte" des Generators überhaupt nicht garantiert werden, sie kann sich je nach zeitlichem Abstand zwischen zwei Aufrufen subtil ändern. Wenn das Anwenderprogramm den Generator in konstanten zeitlichen Abständen aufruft und diese (in Zyklen gerechnet) sogar in einem kleinen ganzzahligen Verhältnis zu den gewählten Timer-Perioden stehen, kann ein timerbasiertes Verfahren sehr schnell ins Auge gehen.
Zu [1.] - Speicherung der gepatchten ROM's:
In der aktuellen Beta4 Version vom "C64-ROM-Patch" speichere ich die gepatchten ROM's auf der Disk Please login to see this link./1541 seriell als .seq-Dateien ab.
Zu [2.]: - RND(0)-Implementierung:
Das Resultat der neuen RND(0)-Implementierung (RND CIA++) ist im Vergleich zur Original RND(0)-Funktion sehr viel deutlich besser. Die deutlich verbesserten Resultaten der gepatchen Version sind echt ein recht guter Kompromiss - im Vergleich zur Original RND(0)-Funktion. Beim Auslesen der Timer-Register (8-Bit Werte) werden außerdem die schlechten Timer-Register-Werte durch zusätzliche (1.) Exklusiv-Oder- / (2.) Shift-Operationen sowie (3.) Addition / (4.) Subtraktion weitgehend kompensiert. im "Spoiler" nochmal der aktuelle Code der gepatchten RND(0)-Implementierung zur Info:
ldx #$04
- lda $dc04
eor $dc05
eor $dc06
eor $dc07
adc $dc06
asl
rol
eor $dc07
sta $61,x
dex
lda $dc07
eor $dc06
eor $dc05
eor $dc04
sbc $dc05
lsr
ror
eor $dc04
sta $61,x
dex
bne -
Falls jemand eine Idee hat, wie man dieser neuen RND(0)-Implementierung die Zufallszahlen-Qualität mit einem Stress-Test überprüfen kann, so bin ich für Vorschläge sehr dankbar....
Ok, alles klar.
Danke.
Ich habe eine Frage zum Speichern beim C64 vom gepatchten ROM-im-RAM auf Disk in Assembler.
Beim Speichern vom RAM-Speicherbereich auf Disk (Please login to see this link./1541) über die Kernal-Routine wird FFD8 (=> save ram to device) wird immer in den ersten beiden Bytes als erstes die RAM-Startadresse des RAM-Speicherbereich [00 a0 ... / 00 e0 ...] gespeichert, sodass die finale Dateigröße 8kb + 2 Bytes ist.
Wie kann man einen RAM-Speicherbereich auf Disk (Please login to see this link./1541) ohne vorlaufende RAM-Startadresse (Dateigröße nur 8kb) speichern ?!?!?!
Endlospspier mit A4 hoch (12" x 240 mm) mit 2000 Blatt gibt es für 33,34 € hier:
Please login to see this link.
Vielen Dank für die Hinweise und Referenzen, die die Anpassung vom Fließkomma-Arithmetik-Patch sehr vereinfachen werden.
Danke für die umfangreichen und wirklich sehr hilfreiche Info's.
Ich werde also dieROM-Kistings sehr intensiv studieren.
Für die Fehler in den Posts Please login to see this link. [POS()], Please login to see this link. [PEEK()], Please login to see this link. [max. Zeilennummer] und Please login to see this link. [Fließkommazahlen-Arithmetik] gibt es schon Patches, die auf das BASIC 3.5 (C16 / Plus/4) angepasst werden müssen.
