Gibt er hier noch Leute mit einem C128? Was ich suche ist der Bereich wo ich meine Maschinenprogramme ablegen kann und die Aresse vom Video Ram und von Farb Ram. Bei c64 war das Video Ram bei §0400 - 07FF und das Farb Ram bei $D800- DBE7 Ablegen konnte ich die Programme ab $c000 Nur über den C128 finden ich nichts. Vielen Dank
Ingo L. schrieb: > Gibt er hier noch Leute mit einem C128? > > Was ich suche ist der Bereich wo ich meine Maschinenprogramme ablegen > kann > und die Aresse vom Video Ram und von Farb Ram. Das ist an verschiedensten Stellen im Internet dokumentiert. https://github.com/franckverrot/EmulationResources/blob/master/consoles/commodore/C128%20RAM%20Map.txt > Bei c64 war das Video Ram bei §0400 - 07FF > und das Farb Ram bei $D800- DBE7 > Ablegen konnte ich die Programme ab $c000 > > Nur über den C128 finden ich nichts. Dann betreib deinen C128 im C64 Modus ;-)
Genau das will ich ja nicht. Will bissel am 128 rumfummeln. Aber Danke für den Link.Ich werde mich mal damit befassen.
:
Bearbeitet durch User
Ingo L. schrieb: > Gibt er hier noch Leute mit einem C128? Ja, allerdings schon "etwas" länger nicht mehr benutzt. Ingo L. schrieb: > Ablegen konnte ich die Programme ab $c000 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. Ingo L. schrieb: > Nur über den C128 finden ich nichts. Da ist es 0x1c01.
:
Bearbeitet durch User
Beim C64 standen die Bereichsadressen im Handbuch. Es sollte mich wundern, wenn es beim C128 anders wäre.
Ingo L. schrieb: > Da ist es 0x1c01. ?? Der Beginn des BASIC-RAMs, wohin auch standardmässig (LOAD mit ,0 oder ohne Suffix) Dein Code geladen wird.
Ingo L. schrieb: > und die Aresse vom Video Ram und von Farb Ram. Kommt auf den Text-Modus an. 40: Geht durch den VIC (ähnlich C64) 80: Nutzt den 8563 Video Controller, welcher völlig anders funktioniert.
Norbert schrieb: > Nutzt den 8563 Video Controller, welcher völlig anders > funktioniert. Vor allem braucht man für die C128-Video-Modes einen RGBI-Monitor (z.B. Philips CM8833 oder ältere Commodore 1084), wenn man sie in Farbe sehen will.
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.
Ben B. schrieb: > 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. Ben B. schrieb: > Da man die Zieladresse frei wählen kann, kann man mit LOAD aber auch > sowas wie Bilder direkt in den Bildschirmspeicher laden. Ja, oder solche Spielereien:
1 | *=$d020 |
2 | |
3 | !byte 0, 0 |
Hmmm schrieb: > Norbert schrieb: >> Nutzt den 8563 Video Controller, welcher völlig anders >> funktioniert. > > Vor allem braucht man für die C128-Video-Modes einen RGBI-Monitor (z.B. > Philips CM8833 oder ältere Commodore 1084), wenn man sie in Farbe sehen > will. hab ich
:
Bearbeitet durch User
Ben B. schrieb: > 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"
Ingo L. schrieb: > 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: > https://www.youtube.com/watch?v=sNCqrylNY-0 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.
Ben B. schrieb: > 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. *) mehr meint eine mindestens dreistellige Zahl
Cartman E. schrieb: > 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...
Peter N. schrieb: > 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.
Peter N. schrieb: > Cartman E. schrieb: >> 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.
Hmmm schrieb: > 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.
Ben B. schrieb: > 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! https://www.youtube.com/watch?v=6tqak8xlCzY#t=13m https://www.youtube.com/watch?v=kaeFV0oZaps&t=2s > 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!
Falk B. schrieb: > 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...
Peter N. schrieb: > Falk B. schrieb: >> 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. Das Floppylaufwerk (die 1541) aber schon. Falk B. schrieb: > 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.
Cartman E. schrieb: > 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.
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.
Ingo L. schrieb: > Letztendlich ist doch alles wie bei dem > 64 was Farb- und Bildschirmbereich betrifft zumindest direkt nach dem > Einschalten des 128´ im Grafikmode 0. Ja klar, du nutzt ja auch nur den alten VIC und nur die Hälfte der möglichen Spalten/Zeichenanzahl. Wurde aber schon vor einer knappen Woche geklärt.
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.
Beitrag #7940943 wurde von einem Moderator gelöscht.
Beitrag #7940958 wurde von einem Moderator gelöscht.
Beitrag #7940971 wurde von einem Moderator gelöscht.
Beitrag #7940976 wurde von einem Moderator gelöscht.
Rbx schrieb: > Cartman E. schrieb: >> 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.
Es gibt hier Leute, die können super austeilen, aber mit dem Einstecken haben sie es dann nicht so... ;-)
Cartman E. schrieb: > Rbx schrieb: > > Vielleicht lade ich mal einen Schnipsel zum Reinhören hoch. mach mal
Cartman E. schrieb: > 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.
Ben B. schrieb: > Das steht überall mal so oder mal so, 6520 = PIA (Peripheral Interface Adapter) 6522 = VIA (Versatile Interface Adapter) 6525 = TPI (Tri Port Adapter) 6526, 8520 = CIA (Complex Interface Adapter)
:
Bearbeitet durch User
Ben B. schrieb: >> 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.
Beitrag #7941789 wurde von einem Moderator gelöscht.
Ben B. schrieb: > 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.
:
Bearbeitet durch User
Michael G. schrieb: > Commodore RAM-Erweiterungen (17xx, bis > 512 kB) 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.
M. E. schrieb: > 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. Das war die erste SSD für Homecomputer! ;-)
M. E. schrieb: > Michael G. schrieb: >> Commodore RAM-Erweiterungen (17xx, bis >> 512 kB) > > 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.
Falk B. schrieb: > Das war die erste SSD für Homecomputer! ;-) 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.
Angehängte Dateien:
-
ass.jpg
78 KB
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.
:
Bearbeitet durch User
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.
Ingo L. schrieb: > Das Programm ist aus einem Data Becker Buch. > > Nur funktioniert das nicht so richtig am c126. 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.
Angehängte Dateien:
-
Monitor_A.png
46 KB -
Monitor_B.png
2 KB
Ingo L. schrieb: > 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. Rick schrieb: > Wurde GO64 vorher ausgeführt? Ingo will im C128 Modus den Bildschirmspeicher beschreiben, nicht im C64 Modus!
:
Bearbeitet durch User
Schlag mal dort nach: 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
Vielleicht hilft dir das hier weiter: https://www.retrozone.ch/docs/c128/GrafikProgrammierungC128.pdf Ich hatte auch nach Hardwareprogrammierung nachgesehen, aber das Pdf da hatte vor allem den c64 im Sinn, trotz sehr guter Basteleinführung.
Rbx schrieb: > Ich hatte auch nach Hardwareprogrammierung nachgesehen, aber das Pdf da > hatte vor allem den c64 im Sinn, trotz sehr guter Basteleinführung. Ach so, weil ich den Link noch offen habe: https://www.retrozone.ch/docs/c128/HardwareBasteleienZumC64C128.pdf
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.