Posts by Acorn

Leider ist das ganze nicht so einfach und schon gar nicht mit den System-IRQ. Weil das Umschalten nicht X-beliebig geschehen kann, sonst erst, wenn das letzte Zeichen komplett gezeichnet ist. Wird zu früh oder spät umgeschaltet, sieht man teile der neuen/alten Grafik im Zeichen. Dann gibt es noch die bösen Sprites, die einen beim Timing schön dazwischen funken.

Quote from kiri008

Das wusste ich gar nicht das die Farbe Grün 2 Nummer hat.

Nicht ganz richtig, das Farbram hat nur noch 8 Farben im Multicolor-Zeichenmode. Weil aus dem Farbram nur 3 Bits (%ZZZZM000) für den Farbwert %000 verwendet werden. Damit kann man halt nur 8 verschiedene Farben adressieren. Mit Bit M wird der Zeichenmode gewählt, ist das Bit M gelöscht, werden Singlecolor-Zeichen (Hi-Res) ausgegeben und bei gesetzten Bit = Multicolor-Zeichen (Lo-Res). Das ermöglicht einen Lo-Res und Hi-Res Zeichen zu mischen, dafür verliert man die oberen 8 Farben im Farbram. Leider kann man das Mischen nicht ausschalten, das ist echt nervig, blöderweise ist auch noch schwarz eine der 8 Farben. Nimmt man für die Hintergrundfarbe-0 ($D020) schwarz, verliert man eine weitere Farbe, jetzt hat man nur noch 10 verschiedene Farben gleichzeitig. Die oberen 4 Bits = ZZZZ sind scheinbar zufällige Werte.

Farbram ($D800-$DBFF) = Eine Farbe 0-7 je Zeichen.

Register:

Hintergrundfarbe-0 ($D021) = Farbe 0-15.

Hintergrundfarbe-1 ($D022) = Eine gemeinsame Farbe 0-15 für Multicolor-Zeichen.

Hintergrundfarbe-2 ($D023) = Eine gemeinsame Farbe 0-15 für Multicolor-Zeichen.

Du benutzt den Multicolor-Mode, da hat man als Zeichenfarbe nur die ersten 8 Farben zur Auswahl. Nur die Farbregister sind frei wählbar, effektive sind in diese Mode nur 11 Farben möglich.

poke646,5 : rem grün Singlecolor-Zeichen

Poke646,13: rem grün Multicolor-Zeichen

Stimmt, das Modul läuft auch mit deinen NMI, getestet mit WinVice 3.2. Mein Fehler, die Hintergrundfarbe im Basic war wohl da gerade die Schriftfarbe.

Kernal läuft jetzt, aber woran lag es denn jetzt genau.

Ich meine mit Autostart, Doppelklick auf ein File, dann macht Denise nur einen Reset. Wähle ich stattdessen Einlegen und drücke auf ″Ausgewähltes Programm in den Speicher übertragen″, startet das Programm.

Quote from AW182

Ist das nicht riskant, wegen eventuell dadurch wieder hineinkommender Inkompatibilitäten?

Da liegt ein kleines Missverständnis vor, der Kernal ist nicht als Ersatz gedacht. Es geht allein darum, das dieser nicht mit Denise läuft, das liegt aber nicht am Kernal. Wobei das nicht ganz stimmt, der Kernal läuft eigentlich ganz normal, solange man die Emulation nicht verlässt.

Es liegt am NMI-IRQ, der ist auch gar nicht nötig, wegen $FD15. Habe mal den Warmstart auf $8026 geändert, dann geht es.

Quote from PiCiJi

Beim normalen Start und manuellem Load + Play Tape funktioniert es.

Ja die Routine ist etwas langsamer durch DEC/INC und bestätigt meine Vermutung, da es ohne DEC/INC keine Probleme gibt mit dem Kernal.

Überschneidung der Antwort ja mit dem Standard-Kernal und meinen Kernal ohne DEC/INC passiert das nicht.

Hier mal ein Bild davon.

Nachdem starten von Denise wähle ich Softwareladen, dann wird ein X-beliebiges File ausgewählt, nachdem Doppelklick auf das File wird einfach nur ein Reset ausgeführt.

Vor Assembler war ich sehr vom Basic-Boss angetan, habe sogar noch das Original von Markt&Technik Verlag.

Mit den richtigen Parametern spielt der in einer ganz anderen Liga, ohne ist der aber auch viel langsamer.

Allein REM@ £FASTFOR:£SHORTIF:£WORD #, reicht um Blitzbasic zu deklassieren.

Wenn ich das richtig in der Erinnerung habe, gibt es hier ein Mitglied im Forum der auch einen Basic-Compiler entwickelt hat.

Basicboss.prg

Ich konnte das Problem stark eingrenzen, es liegt an DEC/INC $01, das heißt ohne starten die Programme normal. Meine Vermutung dazu, es könnte ein zeitliches Problem sein, die Routine ist etwas langsamer.

Quote from Mike

*) um eine Grafik-Bitmap auf dem VC-20 darzustellen, wird das Text-RAM mit einer Anordnung aller Zeichen (jedes nur einmal) gefüllt und so zu einem Adreß-Generator umfunktioniert. Die Zeichendefinitionen werden so zur Bitmap. Das geht ohne größere Tricksereien bis 160x192 Punkten (der VIC-I nutzt dazu doppelt-hohe Zeichen mit 8x16 Pixeln). Spannt man die CPU mit ein, kann die ganze anzeigbare Fläche (auf PAL, 224x283 Punkte) als Bitmap genutzt werden.

Die Technik mit der Bitmap-Matrix habe ich schon auf dem C64 verwendet, ohne zu wissen, das dies auf dem VC20 Standard ist. Wer sich das mal genauer anschauen will, kann hier mal hereinschauen. Am Ende des Textes habe ich das Verfahren erklärt, außerdem gibt es noch eine Überraschung danach.

Ganz unten: Hires Grafik scrollen möglich ?

Die Routine löscht den Speicher von $02-$FF und $0200-$3FF, danach wird der Kassettenpuffer gesetzt. Anschließen wird ein Speicher-Test von $0400-$A000 ausgeführt und am Ende werden noch der Basic Speicher Start+Ende und der Bildschirmspeicheranfang gesetzt. Meine Routine macht im Prinzip fast dasselbe, es gibt aber ein paar Unterschiede.

1. Illegale.

2. Test von $04 bis $A000.

3. RAM / ROM.

4. Zero-Page $02-$03.

Habe mal beide aus Sourcecode gepostet.

Habe eine Frage zu Denise 1.1.X, beim Testen von meinen Kernal mit diversen Emulatoren (Vice 3.2 & 3.5,Hoxs,CCS64 und sogar Micro64 gepatcht) hat bisher nur dein Emulator etwas dagegen, Programme zu laden und zu starten, es wird einfach nur ein RESET ausgeführt. Die Ursache ist eine neue RAM-Test-Routine bei $FD50.

Jetzt ist meine Neugier geweckt, springt Denise etwa direkt in diese Routine?

Man kann/sollte immer Abwegen wie relevant so ein Fehlerfall ist. Als Beispiel nehme ich jetzt mal Boulderdash, die Amöbe (für mich damals Säure) hat eine Rechtsschwäche, die Zeitlich bedingt ist. Angenommen die Amöbe hat nur noch zwei freie Felder rechts, jetzt wird ein Stein in das erste obere freie Feld bewegt, die Engine erkennt im nächsten Durchlauf, Feld belegt. Aber nach dem Test wird der Stein nach unten bewegt, dadurch wird das obere Feld wieder frei und das untere Feld belegt, die Amöbe erkennt abermals Feld belegt und erstarrt zu Diamanten, obwohl das obere Feld wieder frei ist. Jetzt muss man sich Fragen wie relevant dieser Fehler ist, da dieser eben nur äußert selten auftreten kann. Die gleiche Schwäche gibt es auch bei der Kollisionsabfrage und der Fehler ist bestimmt relevant, da man diesen aktive ausnutzen kann und trotzdem scheint es so, als wenn kaum jemand auf diesen Fehler gestoßen ist. Mein Fazit, es können Fehler auftreten die man gar nicht bemerkt, aber wenn man die bemerkt stören diese. Beim Scrollen in Boulderdash gibt es einen Fehler, bei den letzten zwei Pixelreihen oben, springen die Pixel hoch und runter, weil diese leider nicht von Sprites verdeckt werden, schon gesehen? :).

Wenn es deutlich schneller gehen soll, könnte man auch Speicher opfern und dafür Tabellen verwenden. Obwohl die Routine immer alle fünf Additionen ausführt, sind alle 65536 Werte in nur ca. 7 Sekunden ausgeben. Mir ist klar, dass es nicht direkt vergleichbar ist, da das ganze als direkte Ausgabe ohne BS und beachten der nullen ist.

bin-dez.prg

Beim debuggen von Tastatur usw. verhält sich Vice wie ein echter C64, beim Loslassen der Taste(n) oder Joystick sind diese eben nicht gedrückt, selbst wenn der Monitor schon aktive ist. Daran kann man schnell verzweifeln, da man erst mal keine Möglichkeit hat, einfach seinen Code zu debuggen. Ob Endurion da was einbauen kann, damit Studio-64 an Vice laufen die Tasten/Joy Input sendet, wäre echt super. Leider wird das bestimmt nicht einfach oder sogar unmöglich.