Warum da oben? Das BASIC-RAM (0x0801) hat den Vorteil, dass LOAD Deinen Code auch ohne ",1" dorthin lädt und Du noch das SYS20xx reinpacken kannst, um es mit RUN starten zu können.
Vom C128-80col in den C128-40col Modus wechseln: graphic 0
Dann liegt der Bildschirmbereich bei $400…$7e7, Farbe bei $d800…$dbe8
Das ist gleich wie beim 64er.
Wenn du den C128-80col Modus nutzen möchtest, da wird alles durch zwei Register des 8563 Video Controller gemacht.
VDCADR:$d600
VDCDAT:$d601
Hinter denen verbergen sich weitere 16KiB(?) Video-RAM. welche nur durch dieses Nadelöhr adressiert werden können.
Kann man mal sehen, wie weit sich das Denken an heutige PCs angepasst hat.
:)
Beim C64/C128 ist man noch absoluter Herrscher über die Maschine, man kann sein Programm überall dort ablegen, wo keine IO-Adressbereiche sind. Die meisten Spiele (oder auch Demos) auf dem C64 schalten als erstes die ROMS ab, um das RAM darunter nutzen zu können.
Die Adresse, wohin das Programm bei LOAD "X",8,1 geladen werden soll, lässt sich frei wählen. Für Programme sollte das der Beginn des Basic-RAMs sein (dann entsteht dort ein SYS <Startadresse>), mit dem das Programm gestartet werden kann. Es gibt aber auch Programme, die sich nach dem LOAD selbst gestartet haben. Da man die Zieladresse frei wählen kann, kann man mit LOAD aber auch sowas wie Bilder direkt in den Bildschirmspeicher laden.
Es gibt aber auch Programme, die sich nach dem LOAD selbst gestartet
haben.
Das waren aber üble Hacks: Man nimmt als Startadresse nicht das BASIC-RAM, sondern überschreibt System-Vektoren, so dass beim nächsten Aufruf der eigene Code gestartet wird.
Kann man mal sehen, wie weit sich das Denken an heutige PCs
angepasst
hat.
:)
Beim C64/C128 ist man noch absoluter Herrscher über die Maschine, man
kann sein Programm überall dort ablegen, wo keine IO-Adressbereiche
sind. Die meisten Spiele (oder auch Demos) auf dem C64 schalten als
erstes die ROMS ab, um das RAM darunter nutzen zu können.
Die Adresse, wohin das Programm bei LOAD "X",8,1 geladen werden soll,
lässt sich frei wählen. Für Programme sollte das der Beginn des
Basic-RAMs sein (dann entsteht dort ein SYS <Startadresse>), mit dem das
Programm gestartet werden kann. Es gibt aber auch Programme, die sich
nach dem LOAD selbst gestartet haben. Da man die Zieladresse frei wählen
kann, kann man mit LOAD aber auch sowas wie Bilder direkt in den
Bildschirmspeicher laden.
Meine ersten Gehversuche in Maschinensprache waren auf dem C64 (6502).
Das hat mir alles mehr Spaß gemacht als mit einen PC oder mit den AVR´s.
Am dem Rechner konnte mann noch rumbasteln. Da war noch irgendie alles "offen"
Meine ersten Gehversuche in Maschinensprache waren auf dem C64 (6502).
Das hat mir alles mehr Spaß gemacht als mit einen PC oder mit den AVR´s.
Am dem Rechner konnte mann noch rumbasteln. Da war noch irgendie alles
"offen"
Was ist an einem AVR nicht offen? Was kann man da nicht rumbasteln? Klar, ein AVR ist ein kleiner Mikrocontroller, der bestenfalls über UART oder SPI mit der Außenwelt redet. Ein C64 hat einen echten Monitor(anschluß), Tonausgabe, Tastatur, Diskettenlaufwerk etc. Und nahezu alles im Direktzugriff, wenn man denn will und kann.
Beim C64 hat man halt sehr offene Hardware und man kann Veränderungen, die man an irgendwelchen Hardware-Registern macht, direkt sehen. Die hat in Sachen Audio und Video (also die direkten Kanäle zum Menschen) deutlich bessere Möglichkeiten als ein AVR, und wenn man nur die Grundfunktionen benutzt, alles in Hardware (z.B. die Sprites und HiRes-Modes des VIC-II und die Stimmen des SID).
Leider sind die meisten Sachen, die auf dem C64 echt toll aussehen und klingen, das Ergebnis ausgesprochen trickreicher Programmierung. Da muss man schon wissen, wie die Bildausgabe z.B. zeitlich abläuft, bevor man überhaupt versteht, wie das funktioniert. Als Beispiel, man kann die Sprites innerhalb eines Bildes mehrfach verwenden, wenn man sie nachdem man sie einmal oben im Bild verwendet hat, unten im Bild einfach nochmal verwendet. Das Sprite erscheint dadurch doppelt im Bild (und muss nicht einmal das gleiche Sprite sein, sondern man kann beim Umschalten alles verändern), Stichwort Rasterzeileninterrupt.
Oder viele Bilder, die so aussehen als würden sie die sehr limitierte Farbdarstellung in den HiRes-Modi umgehen, tun dies in Wirklichkeit gar nicht. Die Farbdarstellung ist dabei nur exakt an den 8x4-Kästchen (glaube ich, nagelt mich nicht auf exakte Zahlen fest, ist zu lange her) ausgerichtet, daß innerhalb dieser Kästchen immer nur 4 Farben (glaube 4 waren möglich) verwendet werden. Das kann man auf die Spitze treiben, indem man mit Hilfe der Sprites weitere Möglichkeiten schafft und weiter steigern, indem man Sprites mehrfach benutzt. Das Bild sieht dabei statisch aus, in Wahrheit läuft aber ein sehr trickreiches Programm, welches das Bild ständig immer wieder neu zusammenbaut.
Mit dem Sound ist es das Gleiche... der SID in Basic programmiert klingt ... naja bescheiden sage ich mal. Der Sound, der das Ding berühmt gemacht hat, basiert auf ständiger schneller Neuprogrammierung und Mehrfachnutzung der Stimmen, sogar auf Ausnutzung von Bugs des SID (Sounderzeugung durch Änderungen des Lautstärke-Registers).
So, und wer nun denkt, mit einem AVR bekommt man
nichts Vergleichbares hin:
Das ist nur ein kleiner ATMega88 in dem Video. Fragt mich aber nicht, wie das intern funktioniert, habe ich mir nicht mehr angeschaut... Ich vermute sehr extravagante Spielereien mit den Timern und Taktzyklenzählerei wie beim C64. Dazu kommt, viele dieser Grafikspielereien sind nicht so programmiert wie sie aussehen. Also da läuft kein 3D-Renderer, der Controller macht nur genau passende Ausgaben, damit das so aussieht wie es aussehen soll. Der Typ in dem Video kennt sich auch extrem gut mit dem C64 aus, hat z.B. den ersten Fastloader gebastelt, der das GCR-Decoding auf der 1541 in Echtzeit schafft und das basiert ebenfalls auf sehr ausgefeilter Programmierung bis zur Ausnutzung von undokumentierten Funktionen des 6502.
Mit dem Sound ist es das Gleiche... der SID in Basic programmiert klingt
... naja bescheiden sage ich mal. Der Sound, der das Ding berühmt
gemacht hat, basiert auf ständiger schneller Neuprogrammierung und
Mehrfachnutzung der Stimmen, sogar auf Ausnutzung von Bugs des SID
(Sounderzeugung durch Änderungen des Lautstärke-Registers).
Mit SIDs kann man schon interessante Klänge erzeugen.
Je mehr* SIDs, umso beeindruckender das Ergebnis.
Es können auch /emulierte/ SIDs sein.
Deren Vorteil ist die wesentlich präzisere Steuerung der
Parameter gegenüber dem Original.
Die obigen Programmierspielereien des C64 muss dazu noch
nicht einmal benutzen.
Mit SIDs kann man schon interessante Klänge erzeugen.
Je mehr* SIDs, umso beeindruckender das Ergebnis.
Es können auch emulierte SIDs sein.
Ich finde, bei den Amigas konnte man wesentlich einfacher und flexibler den Sound erzeugen:
Die Soundkurve lag im Speicher und wurde einfach einfach abgespielt.
Kein rumgefummel mit Anstiegs- und Abfallzeiten, Filtern usw...
Ich finde, bei den Amigas konnte man wesentlich einfacher und flexibler
den Sound erzeugen:
Die Soundkurve lag im Speicher und wurde einfach einfach abgespielt.
Und die "Soundkurven" aka Samples wachsen bei Dir im Garten?
Ein flexibel konfigurierbarer Audio-DAC wie im Amiga ist zwar eine schöne Sache, erzeugt aber von sich aus keine Töne, sondern spielt sie nur ab.
Mit SIDs kann man schon interessante Klänge erzeugen.
Je mehr* SIDs, umso beeindruckender das Ergebnis.
Es können auch emulierte SIDs sein.
Ich finde, bei den Amigas konnte man wesentlich einfacher und flexibler
den Sound erzeugen:
Die Soundkurve lag im Speicher und wurde einfach einfach abgespielt.
Kein rumgefummel mit Anstiegs- und Abfallzeiten, Filtern usw...
Der Hüllkurvenformer (aka ADSR+VCA) ist ein Added-Bonus.
Genauso der VCF.
Die emulierten SIDs sind nichts anderes als /gesamplete/ SIDs
(PAL/NTSC/SID-Derivate) und einer GigaSampler-Engine unten drunter.
Als Einzelstimme ist gegenüber einem SID auch /kein/ Unterschied
auszumachen. Sie ist aber z.B. polyphon spielbar.
Als IC würde man da schon mehr als einen SID brauchen.
Allerdings kann der Gigasampler noch einiges mehr mit dieser/n
Stimme/n anstellen.
Vor allen Dingen braucht man keine C64er dafür auseinanderrupfen.
Einen Amiga-Sound-Chip muss man wahrscheinlich gar nicht emulieren.
Da kann man ja gleich den Sampler (Emu/...) bemühen.
Und die "Soundkurven" aka Samples wachsen bei Dir im Garten?
Ein flexibel konfigurierbarer Audio-DAC wie im Amiga ist zwar eine
schöne Sache, erzeugt aber von sich aus keine Töne, sondern spielt sie
nur ab.
Das ist korrekt. Aber man kann sie natürlich "vorab" auch mit dem Amiga erzeugen, also mit dem 68k-Prozessor. Oder mit was ganz anderem.
Im Prinzip ist es nur eine Frage des verfügbaren Speichers, ob man zwingend zur Runtime einen bestimmten Sound erzeugen muss oder ob man das auch vorab machen kann. Wobei noch nicht mal gesichert ist, dass die "Handlungsanleitung" (also das Programm) für die Runtimegenerierung tatsächlich kleiner ist als das vorab in Samples gegossene Ergbnis so einer Generierung. Dann wird es nämlich endgültig sinnlos, die Sache zur Runtime erzeugen zu wollen.
Es sei denn, man kommt an die Ausgabe garnicht so einfach heran, um dort einfach nur Samples abspielen zu können. Beim Amiga kein Problem...
Naja, wenn es um Multimedia-Inhalte geht, ist der C64 in zwei Bereichen sehr stark limitiert, nämlich in Rechenleistung und Speicher. Die CPU läuft nur mit ~1Mhz und die 64k RAM sind weder für große Audio-Samples, noch für einen Video-Framebuffer groß genug. Gäbe es einen Framebuffer - für 320x200 x4 Bit Farbtiefe bräuchte man knapp 32kB RAM, die bekäme man zwar ins RAM hinein, aber die CPU hätte niemals genug Leistung, um den zwischen zwei Frames zu füllen. Deswegen generieren VIC und SID das alles in Echtzeit, wenn man so will ist das eine frühe Form von Hardwarebeschleunigung.
Als Vergleich dazu, der Amiga 500 mit seinem Motorola 68k hat etwas über 7Mhz CPU-Takt und 512kb RAM (1MB beim Amiga 500 plus).
Und selbst das führt noch zu Einschränkungen bzw. ist ein Grund dafür, warum die Datentransferrate der C64 Floppy (ohne Fastloader) so unbrauchbar niedrig war. Der VIC teilt sich das RAM mit der CPU, beide greifen abwechselnd darauf zu, daher steuert der VIC alle Timings in der Kiste und das RAM läuft effektiv mit doppelter CPU-Geschwindigkeit. Zusätzlich holt sich der VIC in der ersten von 8 Bildlinien die Zeichendaten aus dem RAM, das sind die sogenannten Badlines, in denen die CPU angehalten wird weil für sie keine Zeit für RAM-Zugriffe übrig bleibt. Letzteres ist zusammen mit einem Bug im seriell/parallel-Schieberegister der VIA (womit die serielle Datenübertragung der Floppy eigentlich seit dem VIC20 in Hardware erledigt werden sollte) der Grund für die extrem langsame Datentransferrate. Infolge des Hardwarefehlers musste das Busprotokoll in Software ausgeführt werden und dann müssen die einzelnen Bits lange genug am Bus anliegen, damit die CPU sie auch während einer Badline noch zuverlässig mitbekommt. Beim VIC20 (VC20 in Deutschland) mit seinen 5kB RAM und ohne Badlines war das noch verschmerzbar, beim C64 mit seinen 64kB RAM und den Badlines wurde es zum großen Problem. Dieser Bug wurde erst beim C128 gefixt.
Es gibt eine sehr eingeschränkte Möglichkeit, Audio-Samples abzuspielen, indem man einen Bug bzw. unerwünschten Effekt des SID benutzt. Der SID erzeugt beim Verändern des Lautstärke-Registers ein unerwünschtes Ploppen und z.B. das Spiel Ghostbusters nutzt das, um damit ein kurzes Sample abzuspielen. Allerdings ist dieser Bug des SID über seine verschiedenen Revisionen verschieden stark ausgeprägt, richtig gut funktioniert das nur auf der ersten Revision, bei späteren Revisionen erscheint das Sample deutlich leiser.
Und selbst das führt noch zu Einschränkungen bzw. ist ein Grund dafür,
warum die Datentransferrate der C64 Floppy (ohne Fastloader) so
unbrauchbar niedrig war. Der VIC teilt sich das RAM mit der CPU, beide
greifen abwechselnd darauf zu, daher steuert der VIC alle Timings in der
Kiste und das RAM läuft effektiv mit doppelter CPU-Geschwindigkeit.
Ja, aber das war nicht der Grund des arschlangsamen Floppylaufwerks beim C64. Ein paar Deppen bei Comodore haben es versaut! Es waren schon die richtigen ICs (VIAs) drin, aber irgend ein Idiot hat ein paar Leitungen im Layout entfernt. So zumindest die Legende. Für den Schnitzer hätte man mehrere Leute verprügeln müssen! Das Laufwerk erreicht nur ca. 400 BYTES/s! Wenn amn es richtig gemacht hätte, wären es 4kB/s gewesen!
Zusätzlich holt sich der VIC in der ersten von 8 Bildlinien die
Zeichendaten aus dem RAM, das sind die sogenannten Badlines, in denen
die CPU angehalten wird weil für sie keine Zeit für RAM-Zugriffe übrig
bleibt. Letzteres ist zusammen mit einem Bug im
seriell/parallel-Schieberegister der VIA (womit die serielle
Datenübertragung der Floppy eigentlich seit dem VIC20 in Hardware
erledigt werden sollte) der Grund für die extrem langsame
Datentransferrate.
Nö. Der Bug war in den neuen VIAs (MOS6526) des C64 gar nicht mehr drin. Trotzdem haben sie es versaut den sie Floppy SCHNARCHLANGSAM gemacht! Es ist ein Wunder, daß der C64 TROTZDEM so ein Erfolg wurde!
Ja, aber das war nicht der Grund des arschlangsamen Floppylaufwerks beim
C64. Ein paar Deppen bei Comodore haben es versaut! Es waren schon die
richtigen ICs (VIAs) drin, aber irgend ein Idiot hat ein paar Leitungen
im Layout entfernt. So zumindest die Legende.
Der C64 hat keine VIAs (6522), sondern CIAs.
Wenn die Geschwindigkeit nur durch fehlende Leiterbahnen begründet war, wären die ganz einfach nachverdrahtet worden, und spätestens bei der nächsten Leiterplattenversion integriert worden.
Und die neuen Busleitungen beim C128/1571 wären nicht nötig gewesen...
Ja, aber das war nicht der Grund des arschlangsamen Floppylaufwerks beim
C64. Ein paar Deppen bei Comodore haben es versaut! Es waren schon die
richtigen ICs (VIAs) drin, aber irgend ein Idiot hat ein paar Leitungen
im Layout entfernt. So zumindest die Legende.
Es ist ein Wunder, daß der C64 TROTZDEM so ein Erfolg wurde!
Vielleicht gerade deswegen. Der Antrieb für Hacker ist ja, auch mit beschränkter Hardware etwas Großes zu reißen. Und übliche Software- Speedloader (SuperDOS2.0, Gigaload) haben ja das Optimum rausgeholt.
Die Begrenzung war fortan nicht mehr die Datenübertragung, sondern die dämliche GCR-Codierung. Und sogar da hat Gigaload noch was gerissen, indem es einen Sektor teils von der CPU in der Floppy, teils von der CPU im C64 decodieren ließ.
Es waren also vielleicht gerade die "low hanging fruit", die den C64 zu einem so begehrten Ziel für Hacker und Nerds machten.
Vielen Dank euch für eure Tips. Letztendlich ist doch alles wie bei dem 64 was Farb- und Bildschirmbereich betrifft zumindest direkt nach dem Einschalten des 128´ im Grafikmode 0.
Als Start-Adresse für die Programme habe ich $c000 genommen.
Nochmal vielen Dank. Hab nicht damit gerechnet, dass sich noch so viele für diesen Rechner interessieren.
Solltest du mal mehr als 40col brauchen (und tausend andere Dinge ebenfalls)), empfehle ich das gute, alte
›Commodore 128 Programmers Reference Guide‹ bzw. das ›Commodore 128 Intern‹
Beide wohl auch als pdf im Interweb.
ich habe mittlerweile schon paar Bucher bei E.Bay bezogen das Inern, Tips und Tricks von Data Becker war dabei und Commodore 128 Programmieren in Maschinensprache. Aber ich schau mir deinen Vorschlag auch nochmal an.
Mit SIDs kann man schon interessante Klänge erzeugen.
Die Musikband Welle Erdball benutzt den C64 als Hauptinstrument. So
konnte man die Möglichkeiten ausreizen, und Schwerpunkte setzen.
Ich sehe das eher als Ergänzung des musikalischen Werkzeugkastens.
Wer würde schon vermuten, dass man mit hinreichend vielen SIDs
auch orchestrale Klänge hervorbringen kann.
Ganz abseits vom typischen /Vintage-Retro-Programmier-Gedudel/. ☺
Man darf /orchestral/ aber nicht mit herkömmlichen Instrumenten
als Massstab messen. Das klingt schon eher recht eigenständig.
Vielleicht lade ich mal einen Schnipsel zum Reinhören hoch.
Vielleicht lade ich mal einen Schnipsel zum Reinhören hoch.
Fände ich auch toll.
Hör dir aber auch mal ein Welle Erdball Album (z.B. Wunderwelt der Technik https://www.youtube.com/watch?v=fuq8bVgkuhw) an. Die meinten mal im Interview, dass sie so auf den Kaufhype damals verzichten konnten - und von den Ergüssen damals auch nicht abgelenkt wurden. (hatten die natürlich etwas anders verklickert, aber das klang ein wenig "fachchinesisch").
Wer würde schon vermuten, dass man mit hinreichend vielen SIDs
auch orchestrale Klänge hervorbringen kann.
Das liegt entweder daran, daß orchestrale Klänge einfach nur beschissen klingen oder es geht in Bereich dieser Unendlichkeits-Theorien, wie daß man mit einer unendlichen Anzahl zufällig auf einer unendlichen Anzahl Schreibmaschinen tippenden Affen jedes Buch der Welt tippen kann oder daß jede natürliche Zahl auch mit ihren Primfaktoren dargestellt werden kann. So ist es bestimmt auch möglich, eine beliebige Audio-Schwingung mit einer hinreichenden Menge anderer addierter Schwingungen darzustellen bzw. sich ausreichend anzunähern.
Der C64 hat keine VIAs (6522), sondern CIAs.
Das steht überall mal so oder mal so, vor allem im englischen Sprachraum. Es sind jedenfalls die gleichen ICs, und wenn beim C64 die schon gefixten ICs eingesetzt werden, dann ist das zwar schön (falls man das mal braucht), würde das Ding aber zu bisherigen Diskettenlaufwerke inkompatibel machen und soweit ich weiß, war Commodore diese Kompatibilität recht wichtig. Wahrscheinlich war das ein Verkaufsargument.
Wenn man möchte, kann man seinen C64 auf JiffyDOS umbasteln, dafür müssen die ROMs des C64 und des Diskettenlaufwerks getauscht werden. Commodore hätte bei späteren Versionen des C64 ebenfalls schnellere Datentransfer-Routinen einsetzen können, die ganzen Schnelllader zeigen ja, daß auch die unmodifizierte Hardware dazu fähig war. Haben sie aber nicht getan, wahrscheinlich ebenfalls aus Kompatibilitätsgründen.
Wer würde schon vermuten, dass man mit hinreichend vielen SIDs
auch orchestrale Klänge hervorbringen kann.
Das liegt entweder daran, daß orchestrale Klänge einfach nur beschissen
klingen oder es geht in Bereich dieser Unendlichkeits-Theorien, wie daß
man mit einer unendlichen Anzahl zufällig auf einer unendlichen Anzahl
Schreibmaschinen tippenden Affen jedes Buch der Welt tippen kann oder
daß jede natürliche Zahl auch mit ihren Primfaktoren dargestellt werden
kann. So ist es bestimmt auch möglich, eine beliebige Audio-Schwingung
mit einer hinreichenden Menge anderer addierter Schwingungen
darzustellen bzw. sich ausreichend anzunähern.
Du redest von Farben, bist aber praktisch blind.
Den versprochenen Link schicke ich per PN.
Das erspart mir dein Genöle.
Gäbe es einen Framebuffer -
für 320x200 x4 Bit Farbtiefe bräuchte man knapp 32kB RAM
Ein C-64-Grafikbildschirm sind immer 8,5 kB: 8 kB Bild (320x200 "monochrom" oder 160x200 "vierfarbig") + 0,5 kB Farb-RAM (als 1024x4), das für je 8x8 Pixel Vordergrundfarbe (im monochrom-Modus) bzw. Farbe 1 (im Vierfarbmodus) festlegt.
die bekäme man
zwar ins RAM hinein, aber die CPU hätte niemals genug Leistung, um den
zwischen zwei Frames zu füllen.
Die CPU nicht, aber: Die MMUs der Commodore RAM-Erweiterungen (17xx, bis 512 kB) konnten per DMA Daten mit dem vollen CPU-Takt zwischen Rechner und RAM-Erweiterung verschieben - das sind 9ms pro Bild. Der VIC wiederum kann instantan zwischen zwei Framebuffern umschalten. Damit geht das ‒ eine Demo (drehender Globus) war auf der Diskette zur RAM-Erweiterung dabei, 1987 sehr beeindruckend.
Da gibt es auch noch eine Erweiterungsplatine für, mit der konnte man dann 2048 kB nutzen. Dafür wurden bis zu 4 Stück an Speicher IC übereinander gestapelt gelötet, ich habe davon noch 2 solcher maximal bestückten REU hier liegen.
Da gibt es auch noch eine Erweiterungsplatine für, mit der konnte man
dann 2048 kB nutzen. Dafür wurden bis zu 4 Stück an Speicher IC
übereinander gestapelt gelötet, ich habe davon noch 2 solcher maximal
bestückten REU hier liegen.
Da gibt es auch noch eine Erweiterungsplatine für, mit der konnte man
dann 2048 kB nutzen. Dafür wurden bis zu 4 Stück an Speicher IC
übereinander gestapelt gelötet, ich habe davon noch 2 solcher maximal
bestückten REU hier liegen.
Ich hätte hier einen in dieser Hinsicht völlig unversorgten C128D. ☺
Würdest du gegen Entgelt eine abtreten wollen?
Nein, ich glaube die lasse ich lieber in meinem Fundus liegen. Wenn ich 3 hätte, würde ich darüber nachdenken. Aber bei 2 kann schon mal eine kaputt gehen und dann hab ich noch eine auf Reserve :-)
Da gibt es ein tolles Kopierprogramm für, mit dem man in erstaunlich kurzer Zeit Disketten kopieren kann, wenn man ein Parallelkabel vom VIA der Floppy zum Userport zieht. Lange nicht mehr genutzt. 12 Sekunden pro Diskettenseite. Oder waren es 20? Nur einmal zum Einlesen und einmal zum Schreiben die Disk einlegen. Dafür hätte aber vmtl. die 1764 mit 256 kB gereicht.
Seit gestern nenne ich auch einen PET 2001-8C aus 1978 Mitglied meiner Sammlung. Aber ich schätze, dass der erst mal nur eingelagert und nicht betrieben wird.
Nicht wirklich. Das waren zwar unvorstellbare Datenmengen, aber sobald Strom weg, waren sie weg...
Als ich den Speicher aufgerüstet hatte, war gerade eine Zeit in der man Mainboards von PC mit gigantischen Gräbern an gesockelten 41256 DIL16 Speichern auf Computer Flohmärkten so gut wie geschenkt bekam. Damit konnte man dann den Umbau vornehmen. Immer 4 Stück übereinander, jeweils ein Beinchen raus gebogen und extern mit der Zusatzplatine verbunden.
Ich trau mich schon gar nicht diese Frage zu stellen.
Ich habe dieses Programm eingegeben um mal Farb- und Video RAM zu testen.
Das Programm ist aus einem Data Becker Buch.
Nur funktioniert das nicht so richtig am c126.
Als Startadresse habe ich es einmal mit $c000 probiert das wird der Zeichensatz nur teilweise dargestellt und nicht in weiß und einmal im Bereich $1300 da passiert gar nichts. Das Programm aber funktioniert im C64 so wie es soll, weiße Schrift mit Kompletten Zeichensatz.
Grafic Mode 0 beim C128.
Eigentlich würde ich ja gerne helfen.
Aber im Augenblick scheint ein Löschclown sein Ritalin abgesetzt zu haben. So macht das hier keinen Spaß.
Anderes Forum – gerne.
Ist das Programm denn (laut Data Becker Buch) für den C128 geeignet? Das Speicherlayout im C128-Modus ist deutlich komplexer - irgendwie muss man einer CPU mit 16 Bit Adressbus ja 128K RAM + noch einiges an ROM verkaufen. Vermutlich muss man die MMU vorher konfigurieren, und / oder das Color RAM ist an anderer Stelle eingeblendet.
ich habe gleiches Programm mal mit POKE´s in Basic gemacht. Die Adressen
für Video und Farb RAM passen.
Das täuscht und ist eine Besonderheit. Ein POKE in den Bereich der Farb-RAM Adressen macht (hinter den Kulissen) viel mehr als nur den Wert an die Adresse schreiben. Stichwort:Bankumschaltung.
Direkt nach einem Reset:
Im MONITOR kann man zum Bleistift eine $01 in $00400 schreiben und man bekommt ein 'A'.
Wenn man dann aber eine $01 in $0D800 schreibt, wird der Buchstabe nicht wie erwartet weiß. Denn dazu muss man den $01 Wert in $4D800 schreiben.
Internet Archive
https://archive.org
Das Maschinensprache Buch zum C64 und C128 : Lothar Englisch
03.07.2020 — Ein DATA BECKER Buch. "Dieses Buch bietet eine leicht verständliche Einführung in die Maschinenspracheprogrammierung für alle, denen BASIC ...
Internet Archive
https://archive.org
Data Becker Führer Commodore 128 : Heinz Wrobel
25.08.2020 — Dieser Führer soll weder ein Handbuch noch eine Einführung zu Ihrem Commodore 128 sein, sondern ein Nachschlagewerk, in dem Sie schnell die ...
retrozone.ch
https://www.retrozone.ch
PDF
COMMODORE für Einsteiger
stungsmerkmale des C128: 64- aufwärts-kompatibel, 3 Betriebs systeme (eins ... bei DATA BECKER. Seine fundierten Kenntnisse in der Pro grammierung ..
Das Das Maschinensprache Buch zum C64 und C128 und das Maschinensprache für Einsteiger bezieht sich meist nur auf den c64. Der 128 wird da kaum behandelt.
Führer Commodore 128 mus ich mal googeln ob ich das als PDF finde.
Danke dennoch
Viele der Bücher fangen beim /Urschleim/ an, und man muss viel
unnötiges und redundantes lesen.
Wo etwas im Adressraum liegt, verraten die Anhänge im Systems Guide/
Bedienhandbuch des C128. Das sollte es zum C128 dazu gegeben haben. ☺
Was man mit einem 6502-Derivat anstellt, kann man im Leventhal 6502
nachlesen. Wenn es um die Bits der Peripherie geht, dann noch deren
Datenblätter.
Ein kommentiertes ROM-Listing ist für den 6502-Novizen ganz sicher
auch eine empfehlenswerte Lektüre. Leider nur so spannend wie ein
Telefonbuch.