sondern auch noch die Spritedaten
Das steht auch so bereits in meinem Beitrag #66 drin ("den VIC (und die Sprites)").
Ah so. Das hatte ich anders verstanden... Na egal.
Und ich glaube mich zu erinnern, dass das Bank-Umschalten hässliche Artefakte am linken Rand erzeugt.
Das wäre mir allerdings neu. Eventuell sollte man nur nicht die Sprites so setzen, daß deren Fetches genau da stattfinden, wo man gerade die Bank umsetzt.
Hast recht. Ich hatte das mit der Änderung von $D011 verwechselt...
Das kann man auch beheben, ist aber deutlich komplizierter: Es gibt nämlich eine zweite Möglichkeiten, wie man den vertikalen Rahmen öffnen kann und da tritt dieser Effekt nicht auf. (Die zweie Möglichkeit besteht darin, ab der letzten Bildschirmzeile den horizontalen Rahmen in jeder Zeile zu öffnen, bis zum Anfang des Bildschirms. Braucht exaktes Rastertiming und die Sprites muss man auch beachten.)
Einfacher wäre es, es so wie jetzt zu machen, nur im IRQ die Zeit bis zum Bildschirmanfang irgendwie zu vertrödeln. Dann könnte man am Anfang des IRQ das Ghost-Byte auf 0 setzen und den Wert am Ende wiederherstellen, und weil in der Zwischenzeit nichts anderes passieren kann stört es kein Programm. Braucht leider genauso viel Rasterzeit wie Deine Lösung, aber ist wenigstens leichter zu implementieren
.
Wenn man weniger Rasterzeit verbrauchen will, kann man die Uhr auch nach unten setzen. Dann kann man direkt nach der Anzeige schon wieder alles resetten und den IRQ beenden.
Es gibt auch noch die Möglichkeit, den VIC (und die Sprites) während des Rahmens in Bank 3 zu setzen. Dann hat man das Ghostbyte bei $FFFF, wo es keinen stört. Man muß nur daran denken, daß dann die Spritepointer (und der "Textbildschirm") währenddessen auch in Bank 3 sind.
Das geht dann wieder ohne CPU-Zeit im Rahmen zu verbrennen.
Auch eine gute Idee. Es sind dann allerdings nicht nur die Spritepointer in Bank 3, sondern auch noch die Spritedaten. (Und ich glaube mich zu erinnern, dass das Bank-Umschalten hässliche Artefakte am linken Rand erzeugt. Die müsste man dann mit einem zusätzlichen Sprite auch noch ausblenden...)
Sehr schön! Jetzt noch wie oben vorgeschlagen die Hintergrundfarbe auf die Rahmenfarbe setzen am unteren Bildschirmrand und wieder zurück am oberen, dann ist es perfekt
Fast. Sobald du ein zu langes BASIC-Programm lädst, gibt es noch ein Problem. (Zu lang ist das Programm, wenn es in Speicherzelle 16383 einen Wert <> 0 hat.) Man kann das simulieren, indem man POKE16383,85 eingibt...
Das kann man auch beheben, ist aber deutlich komplizierter: Es gibt nämlich eine zweite Möglichkeiten, wie man den vertikalen Rahmen öffnen kann und da tritt dieser Effekt nicht auf. (Die zweie Möglichkeit besteht darin, ab der letzten Bildschirmzeile den horizontalen Rahmen in jeder Zeile zu öffnen, bis zum Anfang des Bildschirms. Braucht exaktes Rastertiming und die Sprites muss man auch beachten.)
Ich würde ja sagen, es gibt "HUHU" aus und in Zeile 120 fehlt nicht step-1, sondern :print"huhu":end 
Ich kenne es unter dem Namen "Ratte" mit eher kurzen Regeln.
1=100 P, 5=50 P, 111=1000, sonst 3 gleiche = 200,300,400,500,600
Ansonsten: Wer alle 6 Würfel verbraucht hat MUSS weitermachen, ab 350 darf man aufschreiben, und man hat freie Wahl, welche Würfel man herausnimmt.
Ja, das war es bei uns auch in etwa. Das mit der 350 gab es nicht. Dafür gab es was für eine Straße, aber ich weiß nicht mehr wie viel (hat man eh' nie gehabt...)
Hab mal ein wenig gecodet. Unter anderem auch ein Spiel mit Würfel, welches sich 10-Tausender nennt.
Bei meiner Oma hieß das immer Macke (oder Magge)? Allerdings durfte man sich da aussuchen, welche Würfel man behält und welche man erneut würfelt; man musste also nicht alle Würfel, die Punkte geben behalten (aber natürlich immer mindestens einen). Im Moment zock ich gerade die Computer ab...
PS: Der Endstand:
Da hat ein Computer 10000 Punkte in einem Wurf gemacht. Wie geht das? Ich hatte nicht genau geschaut. Sind 3 Einsen 10000 Punkte hier? (Bei uns waren das nur 1000...)
'ne Anleitung wäre schön... Links und rechts hab' ich raus... Feuer scheint Gas geben zu sein. Vorwärts scheint auch Gas geben zu sein, aber nur manchmal. Kann man auch bremsen? Rückwärts fahren? Gelegentlich geht man kaputt, wenn man an den Rand dotzt, gelegentlich aber auch nicht. Manchmal bleibt man auch einfach so stehen und es geht nichts mehr und man weiß dann nicht so recht, warum... Oben sind Symbole, aber mir ist nicht klar, was die bedeuten. Auf der Strecke liegt auch manchmal Zeugs rum. Wenn man gegendotzt geht man kaputt. Irgendwo war aber was, was wie eine Tankstelle aussah. Geht man da auch kaputt, oder muss man da jetzt zum Tanken drüberfahren?!? Ich hab's leider nur einmal bis dahin geschafft, sodass ich das nicht ausprobieren konnte...
Ich hatte gerade Spaß daran, meine Ideen von gestern Abend mal zu testen. Ich hoffe, das war ok. Jedenfalls hier die Zeiten (in Sekunden) für den ersten Bildschirm:
| Original | 54,6 |
| Version von EgonOlsen71 | 42,0 |
| Version 1 von mir | 26,0 |
| Version 2 von mir | 25,5 |
| Version 3 von mir | 19,2 |
Version 1:
Version 2:
Version 3:
Nachteile von allen drei Versionen (man kriegt halt nichts geschenkt 
Die ersten 6 Zeichen werden quasi sofort angezeigt, erst dann läuft es richtig. Das kann man fixen, indem man vorher händisch die ersten Zeichen poked, evtl. mit Warte-Befehlen dazwischen. (Oder man pfeift auf das SID-Problem und fängt vorne an.)
Nachteil von Version 3: Tasten werden erst am Ende des Bildschirms abgefragt. Das ist wahrscheinlich nicht mehr das, was du haben willst. Es ging mir hier auch mehr darum, zu sehen, wieviel das ausmacht. Ich hatte auch das Gefühl, dass das schon fast zu schnell ist.
Vielleicht wäre ja ein (wahlweises) speichern einer Kopie beim Öffnen eines Projekts einfacher zu realisieren?
Es wird einfach Zeit, dass GIT endlich auf den C64 portiert wird! 
Bin für jeden Tipp dankbar. Probiere es mal aus. Gegen nen Tick schneller hätte ich nichts einzuwenden.
Hatte grad mal geschaut, ob mir auch noch ein paar Beschleunigungs-Tipps einfallen: Dachte an I als erste Variable im Programm definieren, aber das machst du ohnehin (wohl eher zufällig) schon.
Weitere Ideen:
Wieviel das alles bringt, weiß ich nicht.
Ich hab' in den letzten Tagen zwei Makros für den ACME erstellt, die ich bei der Arbeit mit Rastertricks recht häufig benötige - siehe Anhang.
Die beiden Funktionen sind:
(einmal dürft ihr raten, was hier statt des Smilies eigentlich stehen sollte ) nicht.
Die Datei enthält zudem noch 3 Hilfsmakros, die evtl. auch gelegentlich nützlich sein können:
Ein kleines Beispiel zum Demonstrieren, was damit geht:
Das Programm streicht nach SYS49152 flimmerfrei das Wort "SYSTEM" in der Startmeldung durch (zumindest, wenn diese sich noch an der Originalstelle auf dem Bildschirm befindet ).
1. LET kannst du weglassen, das wird beim C64-Basic nicht benötigt (stört aber auch nicht sonderlich)
2. Die Berechnung von J$, M$ und T$ ist korrekt. Ich würde diese Werte aber gleich in Zahlen umrechnen, also 170 J=VAL(RIGHT$(G$,4)), damit kann man besser rechnen. (Aber dann musst du auch Zeile 240 entsprechend anpassen. Ich gehe im weiteren davon aus, dass du J$ und so weiter verwendest.)
3. In Zeile 200 fragst du D$ noch ein zweites mal ab, das hattest du weiter oben in Zeile 131 schon.
4. Der eigentliche Fehler ist in Zeile 240. Da machst du so, als hätte jeder Monat 100 Tage und jedes Jahr 100 Monate. Das ist aber leider nicht so, sondern deutlich komplizierter, vor allem, wenn man auch noch Schaltjahre berücksichtigen will. Was du machen könntest, wäre aber, einfach nur die Differenz der Jahre zu berechnen. Also ALTER=INT(JJ$)-INT(J$):PRINT "Du bist ungefähr ";ALTER
berni : Ist es nicht viel leichter, aus Deiner Bild-Vorlage ein Single-Color-PETSCII zu erstellen als ein Multicolor-PETSCII und ist das nicht eventuell sogar grundsätzlich so?
Das ist schon möglich. Aber mir ging es ja eher darum, mal ein Multi-Color-PETSCII zu haben. Mich würde ja schon interessieren, was Leute, die so geniale Grafiken erstellen können, mit den Standard-Multi-Color-Zeichen hinbekommen können...
P.S. 1: BTW ... von wem kam die eigentlich als Geschenk an enigma und wer hat die mitgebracht?
Die war von mir.
Hi Berni. Mir wurde bisher zweimal davon berichtet. Leider kann ich den Fehler selbst nicht nachstellen. Bei mir wird die Zeit immer sauber ausgegeben.
Ich hab's mir jetzt auch nochmal etwas genauer angeschaut. Meine Vermutung von oben war natürlich Blödsinn (du verwendest die Variablen danach noch nicht einmal). Allerdings steige ich durch deinen Code nicht ganz durch. Mir ist nicht klar, warum du mit SGN und ABS arbeitest. Die Zahl sollte doch ohnehin nie negativ werden, oder? Jedenfalls habe ich rausgefunden, dass die Sekunden nicht immer ganz exakt berechnet werden. Bei PT=3600 und bei PT=3660 kommt der selbe Wert raus, obwohl sie sich um 1 Sekunde unterscheiden. Evtl. gibt es einen bestimmten PT-Wert, der durch solche Rundungsfehler das 00:00:00 ausspuckt. Ich konnte sowas aber nicht finden.
Eine Alternative wäre mit TI$ zu arbeiten: In Zeile 53 T=TI durch TI$="000000" ersetzen und in Zeile 9501: PT$=TI$:H$=LEFT$(PT$,2):M$=MID$(PT$,3,2):S$=RIGHT$(PT$,2). Dann kannst du dir die ganzen Berechnungen in den Zeilen 9507-9519 sparen.
Mir hat das auch sehr gut gefallen. Für ein BASIC-Spiel echt super geworden. Ich hab' es im ersten Anlauf geschafft, auch wenn es ganz am Ende echt knapp war. 630 EP und 251 Goldmünzen hatte ich am Ende. Und ich habe dafür 00:00:00 Zeit gebraucht (Ich denke der Fehler ist in Zeile 9516: Muss da wohl MZ statt MX und SZ statt SX heißen. Bei den Stunden stimmt es noch, aber da war ich wohl unter einer...)
Display More
Genau, die Rasterzeile, aber auch die CIA. (rotierten am meisten, als Allen Dulles noch lebte
)
Solange der Service-Interrupt aktiv ist, gibt es Speicherstellen in der Zeropage, die von 0 bis 255 inkrementieren, also heraufzählen.
Das sind $A0 - $A2 (160 - 162), das ganze Big-Endian und im 1/60 Sekunden-Takt, $A1 also alle 4,3 Sek. und $A0 alle 18,2 Min.
Und nach 1 Tag stehen die alle wieder auf 0.
Das C64-Mapping Buch scheint an dieser Stelle nicht richtig zu sein, wie mir jetzt auffällt beim genauen Nachrechnen.
Doch, doch, das stimmt schon (fast): Die Routine prüft, ob der Wert 4F1A01 erreicht wurde und stellt dann wieder alles auf 00 zurück. Wenn man es genau nachrechnet, stellt man allerdings fest, dass das eine 1/60stel Sekunde zu viel ist. Also doch alles falsch!
kann ich diese Variable ( TC_DestinationPointerLowByte=$FA )
hier irgendwie einsetzen ...
sta $00FA,y
indem ich über den Quellcode den Datentyp umwandeln kann ?
Wenn ich dich richtig verstanden habe, dann suchst du folgendes: sta+2 TC_DestinationPointerLowByte,y (Das sta+2 gibt an, dass hier ein Befehl mit 2 Byte-Operand eingesetzt werden soll; identisch zu den beiden führenden Nullen bei direkter Angabe.)
Siehe Doku.
Ich habe Gold Quest 6, die Extended Edition compiliert. Der P-Code reicht von $0801-$A209. Deshalb hatte ich das Basic-ROM testweise von $A000-$BFFF nach $B000-$CFFF ins RAM verschoben.
Alle Adressen und Vektoren hatte ich auch angepasst. $01 ist #$36. Nur wenn ich ein Basic-Programm lade, von $8801 bis $A341, bekomme ich ein Out of Memory. Da muss man doch noch etwas
Anpassen, damit der Basic-Interpreter weiß, dass ab $AFFF erst Schluss ist. In Adresse $8800 hatte ich natürlich auch eine #$00 eigetragen und die Vektoren ab $2B, $2C, $2D und $2E richtig gesetzt.
So aus dem Bauch heraus: $33 und $34 (siehe Posting oben von 1570), sowie $37 und $38 auch noch anpassen?
PS: Und derzeit auch ohne Plan. Meine Frage nach den Uhrzeiten oben, ist wohl untergegangen. Auf der DoReCo-Webseite hab' ich dazu auch nichts gefunden... (Also ganz konkret: Wann geht das Ding los und wann wollt ihr mich wieder loswerden?)
Losgehen tut es um 10 Uhr (steht auch im 1. Bild im ersten Post)
Ich bin nicht auf die Idee gekommen, das Bild mal genauer anzuschauen... In der Vorschau sieht man es nämlich nicht... 
Danke für die Info!
