Verwechselst du das mit dem C= Handbuch, oder gilt das für beide.
Ne, ich meine explizit das 64 intern.
Hallo Besucher, der Thread wurde 14k mal aufgerufen und enthält 140 Antworten
letzter Beitrag von sparhawk am
C128 Portierungen
- sparhawk
- Erledigt
-
-
Wäre auch mal ein cooles (aber auch aufwendiges) Projekt, ein neues "64 intern" zu basteln, welches alle Infos über den C64 (oder eben C128) beinhaltet, aber 100% fehlerfrei, von der Community geprüft.
-
Was der 128 Intern auf jedem Fall nicht richtig erklärt, ist die Verwendung der FAR-Routinen, dem Programmierer wird erklärt, die JSRFAR/JMPFAR/FETCH/STASH über den Kernal aufzurufen. Das ist alles schön und gut, funktioniert aber nur, wenn der KERNAL sichtbar ist.
Das Schöne daran ist, dass diese Routinen im shared RAM in der Page $0200 zur Verfügung stehen, so dass man von jeder Bank aus auf jede andere Bank zugreifen kannst. Der Aufruf des KERNAL aus RAM, wo er nicht sichtbar ist, ist eine der Hauptanwendungen dieser Routinen! Doch der 128 Intern schweigt in alle Sprachen über die Existenz der $0200-Anrufpunkten...
-
Das Schöne daran ist, dass diese Routinen im shared RAM in der Page $0200 zur Verfügung stehen, so dass man von jeder Bank aus auf jede andere Bank zugreifen kannst. Der Aufruf des KERNAL aus RAM, wo er nicht sichtbar ist, ist eine der Hauptanwendungen dieser Routinen!
Dummerweise enthält JMPFAR diesen blöden "JSR $ff6b"-Aufruf. Da JSRFAR auf JMPFAR zurückgreift, ist es ebenfalls von diesem Problem betroffen.
-
Eine Korrektur für das "C128 Intern" habe ich geschrieben und sind in der Wolke. Das waren die fehlerhaften (bzw. fehlenden) Seiten.
Ich häng es gerade nochmal hier an.
Fein, habe ich mir gleich mal abgespeichert.
Was ich meine sind aber nicht die Fehler im ROM-Listing sondern im Fließtext. Und da gibt es leider mehr als genug.
Dummerweise enthält JMPFAR diesen blöden "JSR $ff6b"-Aufruf. Da JSRFAR auf JMPFAR zurückgreift, ist es ebenfalls von diesem Problem betroffen.
Und das Problem war jetzt was nochmal genau? Ich hab's grad nicht parat...
-
Der Titel der Demo ist spannend, weil es in Bezug auf "Farbspektrum" auf dem C128 ja wohl mit der Farbe 9 "dark yellow" ein Sorgenkind zu geben scheint.
Gibt es einen Konsens in der C128 User Community, was der "richtige" Farbton dieser C128 VDC Farbe ist?
Braun ist definitiv die "richtige" Farbe, da gibt's beim CSDB-Eintrag zu der Demo ja auch eine längere Diskussion dazu. Für dieses Demo braucht man aber "dunkelgelb", was technisch oft einfacher zu realisieren ist, da braun schon damals ein Hack von IBM war, als der CGA-Standard entwicket wurde: https://en.wikipedia.org/wiki/…pter#With_an_RGBI_monitor
Die Idee zu der Demo kam jedenfalls vor ca. 2 Jahren von DeeKay/Crest und ich hatte dann vor ein paar Monaten dazu ein "Proof-of-concept" erstellt. Das hatte die Jungs von Crest dann animiert das als "richtige" Demo zu veröffentlichen. Ich hatte dann, auch aufgrund der Diskussion zu Colour Spectrum in der CSDB meine "Proof-of-Concept" noch schnell um eine Dark-Yellow-Emulation erweitert, so dass auch Leute mit Brown-Fix sich die Bilder zumindest im Original ansehen können. Dank Interlace flimmert das dann mehr oder minder stark (da Gelb und Schwarz abwechselnd angezeigt werden).
Meine Version hat zudem noch einen 4-in-1-Viewer (wozu man allerdings einen 1901-Monitor oder ähnlich braucht) und eine Möglichkeit, jede normale (Standard 6912) .SCR-Datei anzuzeigen, die man z. B. von http://zxart.ee runterladen kann.
Hier jedenfalls der Link zu meiner kleinen Demo "VDC Spectrumania":
https://csdb.dk/release/?id=206013&show=summary -
Das Schöne daran ist, dass diese Routinen im shared RAM in der Page $0200 zur Verfügung stehen, so dass man von jeder Bank aus auf jede andere Bank zugreifen kannst. Der Aufruf des KERNAL aus RAM, wo er nicht sichtbar ist, ist eine der Hauptanwendungen dieser Routinen!
Dummerweise enthält JMPFAR diesen blöden "JSR $ff6b"-Aufruf. Da JSRFAR auf JMPFAR zurückgreift, ist es ebenfalls von diesem Problem betroffen.
Die Route läuft nur in dem Bereich unter $0400 und wird daher beim Reset in diesen Bereich kopiert. Unverändert geht der Rücksprung von JSRFAR immer in die Konfig $00 also ins ROM. Die Routen werden vom Tedmon benutzt und sind auch nur dafür gedacht. Um die Route selbst nutzen zu können, muß die Konfig vor dem Sprung angepasst werden und anschließend wieder hergestellt werden (sonst kann er abstürzen).
-
Ich habe jetzt gestern Abend noch etwas rumprobiert und ein HelloWorld geschrieben das einen Text auf den 40 und 80 Zeichen Bildschirm ausgibt. Den VDC zu programmieren ist schon etwas mühselig.
-
Da der VDC in erster Linie für Textanwendungen gedacht ist und schnelle zugang nicht notwendig ist, kann man erwägen, nur die KERNAL-API zu verwenden und alle Bildschirmausgaben über BSOUT und alle Tastatureingaben über BASIN zu tätigen. Deine Programm wird dann automatisch sowohl auf dem VDC als auch auf dem VIC-II funktionieren.
-
Da der VDC in erster Linie für Textanwendungen gedacht ist und schnelle zugang nicht notwendig ist, kann man erwägen, nur die KERNAL-API zu verwenden und alle Bildschirmausgaben über BSOUT und alle Tastatureingaben über BASIN zu tätigen. Deine Programm wird dann automatisch sowohl auf dem VDC als auch auf dem VIC-II funktionieren.
Da kann ich dann genausogut unter Windows programmieren.
Der Spass daran heute noch was am C64, oder jetzt eben am C128, ist ja Bare Metal. 
Ich werde vermutlich kein begnadeter Democoder mehr, aber zumindest kann ich es probieren.
-
Da der VDC in erster Linie für Textanwendungen gedacht ist
Das kann man schnell widerlegen:
Diese beiden Bilder sind Screenshots vom VDC-Bildschirm. Rechts eine Konversion, die ich mit GoDot erstellt habe. Es gibt da ein spezielles Basic für den VDC (Basic8), das genau für so etwas entwickelt wurde.
Arndt
-
Braun ist definitiv die "richtige" Farbe
Danke für die Hintergrundinfo - wusste ich bisher nicht, dass "eigentlich "Dark Yellow" richtig ist, und das "Brown" nur ein "Hack" von IBM war. Tja, damals konnten sie noch Standards setzen, wenn auch krude...
Komisch aber, dass dann überhaupt VDC Demos für das falsche "Dark Yellow" entwickelt werden.
Selbst Vice128 emuliert die Farbe ja korrekt als Brown.
Der - zugegebenermaßen sehr praktische - C128-Adapter von Sven Pook scheint ja sehr erfolgreich zu sein, und der hat den Brown-Fix leider nicht.
Könnte man das in dem evtl. nachrüsten? Ist ja im Gegensatz zum BIT-C-128 ein komplett passiver Adapter...
-
Programmiert werden kann er nur durch zwei Speicheradressen im C128 ("ich will Wert X in Register Y schreiben").
Auweia.
Insgesamt kein Chip, der sich besonders für Spiele eignen würde - aber vielleicht eine interessante Herausforderung.
Zumindest nicht für Spiele mit viel Bewegung auf dem Screen. Wobei man mit der 64K Version und dem Blockcopy, wenn geschickt genutzt, sicher auch Animationen realisieren könnte? Wahrscheinlich sind aber Puzzlespiele wie Mahjongg oder Ishido am ehesten prädestiniert für C128-Versionen.
-
Dummerweise enthält JMPFAR diesen blöden "JSR $ff6b"-Aufruf. Da JSRFAR auf JMPFAR zurückgreift, ist es ebenfalls von diesem Problem betroffen.
Und das Problem war jetzt was nochmal genau?
Dass dmantione gesagt hat, man könne mit diesen Routinen aus einer Konfiguration ohne Kernal ins Kernal springen. Genau das geht aber eben nicht, da die Routine erst die Kernalfunktion $ff6b aufruft, um die Bank-Nummer in den Wert für das Konfigurationsregister zu konvertieren. Man kann JSRFAR und JMPFAR also nur aufrufen, wenn der Kernal eingeblendet ist.
...natürlich könnte man in der Konfiguration ohne Kernal eine eigene Fake-Routine bei $ff6b ablegen, aber wenn man das tut, könnte man auch einfach eigene Alternativen zu JSRFAR/JMPFAR bauen...
-
Ich habe jetzt gestern Abend noch etwas rumprobiert und ein HelloWorld geschrieben das einen Text auf den 40 und 80 Zeichen Bildschirm ausgibt. Den VDC zu programmieren ist schon etwas mühselig.
Kommt darauf an, wieviel unnötige Arbeit man sich macht.
Register 12/13 brauchst Du nicht zu nullen, das ist eh der vom Kernal gesetzte Standardwert.
Register 30 kannst Du auch komplett ignorieren, das braucht man nur für BlockCopy/BlockWrite.
Und um reine Screencodes ohne Attribute zu schreiben, kannst Du sie einfach direkt hintereinander in Register 31 schreiben, ohne jedes Mal die Update-Adresse einzustellen - die wird nämlich intern automatisch bei jedem Lesen oder Schreiben inkrementiert.
Man kann sogar darauf verzichten, vor jedem Zeichen Register 31 auszuwählen, einmal reicht.
-
Kommt darauf an, wieviel unnötige Arbeit man sich macht.
Bis man ess besser weiss macht an da sicher viel unnötiges.
ZitatRegister 12/13 brauchst Du nicht zu nullen, das ist eh der vom Kernal gesetzte Standardwert.
Ja, ich weiss. Das war nur der erste Test und dann habe ich es drin gelassen. Dacht mir, es kann nicht schaden wenn man es selbst initialisert.
ZitatRegister 30 kannst Du auch komplett ignorieren, das braucht man nur für BlockCopy/BlockWrite.
Und um reine Screencodes ohne Attribute zu schreiben, kannst Du sie einfach direkt hintereinander in Register 31 schreiben, ohne jedes Mal die Update-Adresse einzustellen - die wird nämlich intern automatisch bei jedem Lesen oder Schreiben inkrementiert.
Man kann sogar darauf verzichten, vor jedem Zeichen Register 31 auszuwählen, einmal reicht.
Das ist gut zu wissen. Also behalten die Register ihre Werte bei (wie z.B. bei 30)?
BTW: Als ich nur ein Zeichen an die erste Stelle geschrieben habe, ist es zweimal erschienen, was mich etwas irritiert hat. Ist das ein Chipbug? Ich glaube sowas in der Art gelesen zu haben, weiss jetzt aber nicht mehr wo das war.
-
Komisch aber, dass dann überhaupt VDC Demos für das falsche "Dark Yellow" entwickelt werden.
Selbst Vice128 emuliert die Farbe ja korrekt als Brown.
Der Spectrum hat nun mal "dunkelgelb" als Farbe und das bekommt man beim VDC eben nur per Emulation hin oder wenn man bewusst ein "falsches" Kabel nimmt oder einen Monitor, der den Brown-Fix nicht hat. Ist halt einfach eine Voraussetzung für dieses eine Demo.
Der - zugegebenermaßen sehr praktische - C128-Adapter von Sven Pook scheint ja sehr erfolgreich zu sein, und der hat den Brown-Fix leider nicht.
Könnte man das in dem evtl. nachrüsten? Ist ja im Gegensatz zum BIT-C-128 ein komplett passiver Adapter...
Ich habe den BIT-C128, den Sven Pook Adapter und den C128toSCART von Tilo Dettling. Letzerer ist jetzt bei mir in Betrieb und hat den BIT-C128 abgelöst. Der Sven Pook-Adapter ist einfach und günstig, das war wohl da der Ansatz, deswegen hat der keine aktiven Komponenten und damit auch keinen Brown Fix. Bei mir macht der auch ein paar Streifen ins Bild, die ich mit den anderen (teureren) Adaptern nicht habe. Haben allesamt ihre Berechtigung, für die meisten wird der Sven Pook-Adapter ausreichen, aber man muss halt wissen, dass man damit nur Dunkelgelb und nicht das eigentlich korrekte Braun bekommt. Einen Adapter, der zwischen beiden Farbvarianten umschalten kann wäre sicher die eleganteste Lösung, ist mir aber nicht bekannt.
-
BTW: Als ich nur ein Zeichen an die erste Stelle geschrieben habe, ist es zweimal erschienen, was mich etwas irritiert hat.
Das wird daran gelegen haben, dass Du eine 1 ins BlockWrite-Register geschrieben hast, wodurch ein weiterer Schreibzugriff forciert wurde.
-
Das wird daran gelegen haben, dass Du eine 1 ins BlockWrite-Register geschrieben hast, wodurch ein weiterer Schreibzugriff forciert wurde.
OH! Dann ist das ja sogar falsch.
Ich hatte das so verstanden dass ich das CountRegister setzen muss damit das Zeichen überhaupt erscheint.Danke!
-
Und um reine Screencodes ohne Attribute zu schreiben, kannst Du sie einfach direkt hintereinander in Register 31 schreiben
Gab's da nicht eine Begrenzung (abhängig von anderen Registern) von ca. 8x direkt hintereinander bevor er sich doch verschluckt?
In einer Schleife spielt das natürlich (ohne Super CPU) keine Rolle, da dort genug Zeit zwischen den Zugriffen vergeht.
