Ich persönlich hab durch Hexzahlen eine bessere Vorstellung als mit Dezimalzahlen (bei digitaler Anwendung).
Eben. Wenn ich z.B. AND #$F8 sehe, dann weiss ich sofort, dass da die unteren 3 Bit wegmaskiert werden.
Bei AND #248 müsste ich schon nachrechnen.
Da müßtest Du jetzt aber noch schön erklären, warum das so einfach zu sehen ist und wie Du da drauf schaust ; ansonsten verstehen das nur die Eingeweihten und der TE (noch) nicht.
Kann man eigentlich mit D64 Dateien am PET was anfangen, oder hat der ein komplett anderes Diskettenformat ?
Kann man eigentlich mit D64 Dateien am PET was anfangen, oder hat der ein komplett anderes Diskettenformat ?
Das Format der CBM 3040/4040 ist identisch zum Format der 1541. Daher ist auch das D64-Format identisch.
Die Erklärung zu Hex und Binär liefere ich in den nächsten Tagen nach. 
Das Diskettenformat hängt bei Commodore an der Floppy, nicht am Rechner.
.D64 ist kompatibel zur 1541, 2031, 4031, 3040 und 4040.
Das Diskettenformat hängt bei Commodore an der Floppy, nicht am Rechner.
.D64 ist kompatibel zur 1541, 2031, 4031, 3040 und 4040.
Und 2040. Ich glaube, dann haben wir sie alle.
Wobei...stimmt ja gar nicht. Die 2040 hatte DOS 1 und das war nicht kompatibel.
Sagen wir mal so: Lesekompatibel.
Beim Schreiben könnte man das Dateisystem schrotten.
Und wenn es um's Platzsparen ginge, warum verwendet man dann nicht gleich ein Zahlensystem, das alle Buchstaben nutzt?
Wozu mehr Buchstaben, wenn man bei FF schon am Ende der 8 Bit ist?
Eben. Wenn ich z.B. AND #$F8 sehe, dann weiss ich sofort, dass da die unteren 3 Bit wegmaskiert werden.
Bei AND #248 müsste ich schon nachrechnen.
Okay, seh ich ein, dass man sich die Nibbles leichter im Kopf umrechnen kann.
Das ist aber nicht das alleinige Argument.
Da müßtest Du jetzt aber noch schön erklären, warum das so einfach zu sehen ist und wie Du da drauf schaust ; ansonsten verstehen das nur die Eingeweihten und der TE (noch) nicht.
Binär ist das Zahlensystem zur Basis 2, hexadezimal ist das Zahlensystem zur Basis 16.
16 ist eine Zweierpotenzen: 2^4 = 16
Dadurch bildet eine Stelle hexadezimal, vier binäre Stelle ab. Da ein Byte acht Bit hat, bilden zweistellige hexadezimale Zahlen genau ein Byte ab.
Wenn man jetzt lange genug das das hexadezimal Zahlensystem benutzt hat, dann weiß man irgendwann auswendig, was das Bitmuster von 8 (=1000) oder C (=1100) oder F (=1111) etc. ist. Es gibt ja nur 16 verschiedene Kombinationen. Die werden dann eigentlich nur noch zusammengesetzt. F8 wäre dann 1111 1000. Auch größere Zahlen lassen sich dann so zusammensetzen: D69A -> 1101 0110 1001 1010
Das oktale System ist das Zahlensystem zur Basis 8.
Auch 8 ist eine Zweierpotenz: 2^3 = 8 D.h., eine Stelle oktal bildet drei binäre Stellen ab. Für ein Byte mit acht Bit passt das nicht ganz. Aber es gab auch Computer, die 12, 18 oder 36 Bit CPUs hatten.
Ein Zahlensystem zur Basis 4 oder zur Basis 32, 64, .... (alles Zweierpotenzen) würde genauso funktionieren. Benutzt halt keiner.
Frohes Fest, ihr absoluten 6502-Freaks! 
Wahnsinn, für mich sind sämtliche Posts nach meinen (hilflosen) Fragen wirklich bömische Dörfer...
Da werd ich mich wohl erstmal einlesen müssen- aber natürlich dennoch DANKE für all die Tips!
Hier wird es also weitergehen! Ich hab übrigens gelesen, dass der 8296 mehrere Bildschirminhalte mittels eines Pokes umschalten kann- das geht am 4032 nicht zufällig, oder? 
Weil es hier so super passt und die Fachleute versammelt sind:
Wisst ihr, wie ich in Basic rausfinden kann, ob es ein Rechner mit 40 Zeichen, oder mit 80 Zeichen ist?
Ich frage wegen Ringpuffer, denn evtl. kann ich eine Art "automatische Umschaltung" reinprogrammieren, wenn man versucht, es auf einem 80-Zeichen-Modell zu spielen?
Bislang läuft es auf Basic 3.0 und 4.0 ab 16kB Speicher- allerdings nur auf den 40-Zeichen-Modellen.
Gibts einen PEEK-Befehl, mit dem ich zweifelsfrei die Anzahl der Zeichen pro Zeile rauslesen kann?
Viele Grüsse,
Matthias
Hi Matthias,
in Basic 2 und 4 steht an der Adresse $d5 die Anzahl der möglichen Zeilen (39 oder 79). Hex $d5 ist in Dezimal 0213. Darauf mal ein PEEK senden und schauen was Du als Antwort bekommst 😊
In meinem Beispiel erhalte ich den Wert Hex $27 was dann umgerechnet auf Dezimalzahlen 39 bedeutet. Beim 80 Zeichen Gerät sollte dann da 4f (79) stehen.
Beste Grüße
Marco
Alles anzeigenHi Matthias,
in Basic 2 und 4 steht an der Adresse $d5 die Anzahl der möglichen Zeilen (39 oder 79). Hex $d5 ist in Dezimal 0213. Darauf mal ein PEEK senden und schauen was Du als Antwort bekommst 😊
In meinem Beispiel erhalte ich den Wert Hex $27 was dann umgerechnet auf Dezimalzahlen 39 bedeutet. Beim 80 Zeichen Gerät sollte dann da 4f (79) stehen.
Beste Grüße
Marco
MARCOOO!
Danke- es funktioniert! Beim 4032 bekomme ich auf PRINT PEEK (213) eine "39", beim 8032 eine "79"!
PERFEKT! Somit kann ich weiter am Spiel basteln. Evtl. gibts dann EINE Version, welche auf jedem CBM ab 16kB Speicher läuft. Mal sehen, wie umständlich das umprogrammieren der Zeichenroutinen wird.
Viele Grüsse,
Matthias
Na das klingt doch schon gut. Ich habe Dir mal die Routine von oben in einer PET Version für 80 Zeichen zusammengebaut. Man kann die aber auch durchaus auf 40 Zeichen "umrüsten".
Das Ganze funktioniert dann so, daß man einmal den Poke Loader mit "RUN 100" startet. Danach kann man dann mit SYS30640 eine Routine aufrufen, die einen Bildschirmwechsel macht. Dabei wird der Screen gegen einen zweiten ausgetauscht. Mit "RUN" läuft ein WechselDemo.
Die woanders diskutierte Sicherheitsroutine mit Zwischenspeichern der benutzten Speicherstellen ist da jetzt noch nicht dabei, aber vielleicht klappt es auch so schon ausreichend. Mußt mal schauen, wenn es dir Kommazahlen "zerreißt" dann kann ich das noch nachrüsten.
Vielleicht animiert es Dich ja, Dir das mit den Hexzahlen und dem Assembler auch mal noch anzuschauen.
Juhu!
Erstmal wieder DANKESCHÖN!
Ich kann die Datei leider nur auf meinem 4032 testen, da ich den 8000er nicht hier habe. Da geht natürlich nix, bzw. werden wirre Zeichen im Wechsel mit dem Listing angezeigt. Aber VERDAMMT schnell! Also wirklich in einem Augenblick- genau so bräuchte ich das für den Hilfescreen.
Wie muss ich das Programm einbetten? Es ist ja ein Maschinenprogramm, muss man das dann irgendwie zum bestehenden Listing "mergen"?
Viele Grüsse,
Matthias
Na ja. Du müßtest mal sagen, ob der 4032 einen 80 Zeichenmodus hat oder nur 40 Zeichen anzeigt. Das wußte ich nicht, deshalb ist es jetzt erstmal für 80 Zeichen ausgelegt.
Die wirren Zeichen sind der Inhalt das Memory's (RAM) mit dem der Bildschirmspeicher ausgetauscht wird.
Paßt also. Das "RUN" ist auch nur, um schnell zu schauen, ob es prinzipiell klappt.
Bedient wird das eigentlich dann so:
Du baust die Zeilen ab Zeile 100 aufwärts in Dein Programm ein. Wo ist egal, nur muß natürlich einmal diese Schleife mit den POKE durchlaufen werden. z.B. gleich zu Beginn. Das PRINT, was die Zahlen ausgibt, kannst Du natürlich auch einfach löschen, dann merkt man das nur ein bißchen am Zeitverzug. Deshalb wäre ein guter Zeitpunkt den BASIC PokeLoader auszuführen evtl. auch nachdem der Startbildschirm bereits gezeichnet worden ist.
Die Routine "liegt" ( ) dann bei $77B0 und kann einzeln mit SYS30640 aufgerufen werden.
Dabei wird dann immer der Bildschirm getauscht gegen den, der schon im Speicher abgelegt ist ( ab $7800 ). Zu Beginn ist natürlich ab dort noch nichts Sinnvolles drin sondern eben nur undefinierte Zeichen.
Probier mal per Hand: RUN 100 . Dann löschst Du den Bildschirm mit ClearHome und schreibst irgendwas per Keyboard da drauf. Anschließend rufst Du SYS30640 auf. Dann sollten die komischen Zeichen kommen. Diesen Bildschirm löscht Du jetzt auch und schreibst nochmal was da drauf per Hand - was anderes. Nach einem erneuten SYS30640 erscheint der alte Bildschirm wieder. [Und wenn man ab da dann RUN eingibt wechseln die beiden selbstbeschriebenen Bildschirme ab.]
Für einen Help Text in einem Programm würde man dann z.B. SYS30640 eingeben, sofort den Bildschirm löschen und den Helptext einmal da draufzeichnen lassen ( mit PRINTs ). Wenn man dann wieder zum Originalschirm zurück will, macht man nochmal SYS30640. Bei jedem weiteren Anzeigen des Help-Screens kann man sich das mit den PRINTs sparen, es reicht dann ein einzelnes Umschalten mit SYS.
Na ja. Du müßtest mal sagen, ob der 4032 einen 80 Zeichenmodus hat oder nur 40 Zeichen anzeigt. Das wußte ich nicht, deshalb ist es jetzt erstmal für 80 Zeichen ausgelegt.
Wenn der 4032 einen 80 Zeichenmodus hätte, dann wär's ein 8032.
Ah - OK, das macht mir die doch recht seltsame Benennung dann schonmal VIEL klarer !
Ja, und die waren leider auch nicht umschaltbar. Also der 4032 nur 40 Zeichen und der 8032 nur 80 Zeichen.
In dem Fall muß dann die Disk doch gleich nochmal modifiziert werden. Kommt nachher noch.
Stell doch mal den Quelltext hier rein (wenn du möchtest). Ist sicher für den einen oder anderen interessant.
Quelltext ist oben als (pseudo) Assembler.
Ist aber kein "großer Wurf", einfaches Umkopieren. Aber sicher zum Anschauen auch schon schön. Spannnender ist aber der Nibble Kompaktor eines obendrüber. Das ist wirklich ein echt schönes old-school Teil.
Hier noch die 40Zeichen Version ( aber so, daß sie auch als 80er Variante ginge ).
Juhu!
Es geht voran, allerdings nicht fehlerfrei.
Deine Routine habe ich eingebaut- und sie würde auch funktionieren! Wenn ich jedoch ein Level lade und dann zwischen Hilfe und gezeichnetem Level umschalte, werden sechs Zeichen ausgegeben, welche vorher nicht da waren. Wiederholt man die Umschaltung, werden daneben wieder diese sechs Zeichen ausgegeben, etc... irgendwann friert der Rechner sogar ein.
Mit allen anderen Szenarien (wie von dir beschrieben) funktioniert das Umschalten jedoch fehlerfrei. Meistens auch dann, wenn noch kein Level geladen worden ist.
Hier die Zeichen unten rechts zu sehen:
Eine einmalige Umschaltung mittels SYS würde jedoch auf dauer nicht klappen, weil sich ja der Bildschirm mit dem Level ändert. Deshalb rufe ich den SYS eben VOR dem Hilfebildschirm auf, und danach wieder- um zurückzukehren.
Auch habe ich noch nicht umgesetzt, dass der Hilfebildschirm lediglich einmal gezeichnet wird (mit Print).
Aber daran sollte es ja nicht liegen.
Was könnte da noch nicht passen?
Und was mich auch interessiert: Dein Programm hat 15 Blocks Speicherbedarf. Wenn ich es aber an mein Programm ranbastle (indem ich es einfach in meinem Programm am Ende abtippe), hat dieses Programm lediglich 3 Blocks mehr (wohl wegen der DATA-Zeilen, logisch).
Es funktioniert aber? Oder liegt das Maschinenprogramm dann nicht mit dabei? Dies müsste ja aber das "gepoke" sein, richtig?
Dazu muss ich sagen, dass ich den Rechner hierzu natürlich komplett stromlos gemacht habe, damit der Speicher wirklich leer ist. Dann neu geladen: Routine klappt, aber eben mit diesem Fehler.
Viele Grüsse,
Matthias
Wegen der sechs Zeichen am Bildende ... das ist wahscheinlich schon Dein Variablenspeicher. Ich vermute, daß Du die Texte für den Hilfescreen als Stringvariablen angelegt hast ??
Die Routine klebt einfach mittendrin im BASIC Speicher. Wenn man wenige Variablen benutzt klappt das, weil hinter dem Screen ( von $7800 an bis + 40*25 Zeichen ) noch ein bißchen Platz ist. Aber eben nicht für große Mengen, sondern eher nur für das Schlangenarray gedacht und eine Handvoll kleine Zählvariablen o.ä.
Zumindest wäre das mein Tip, weshalb da sowas mit drin steht.
Die echte und besser Lösung wäre, daß man das Ende vom BASIC Speicher korrigiert. Dafür gibt es normalerweise auch eine Speicherstelle, wo man per Poke reinschreiben kann, wo der BASIC Bereich zu Ende sein soll. Wenn man das ganz zu Beginn des Programmes ändert - nämlich bevor man die allererste Variable belegt, dann sollte das eigentlich klappen. leider weiß ich beim PET dafür die Speicherstelle nicht. Da müßte man mal in ein Buch gucken.
Was Du auch machen kannst, wäre den Bereich vom Screenpuffer einfach weiter vorne hinzulegen. Aktuell beginnt der bei $7800. Wenn man das nach $6800 legt, ist auch schon mehr Platz dahinter. Dazu würde man in Zeile 201 in der Datazeile die "120" ändern. Für den Beginn bei $6800 würde man dort statt der 120 in Zeile 201 eine "104" reinschreiben.
Warum ist das so ? Beim Commodore Basic wird das Programm vorn im Speicher abgelegt und neue Zeile werden dann aufsteigend im Speicher angelegt. Die Variablen aber müssen ja spätestens wenn das Programm läuft auch irgendwohin. Und dafür könnte es auch einen extra Speicherbereich geben - tut es aber nicht. Stattdessen wird da einfach vom anderen Ende begonnen die Daten abzulegen, d.h. es wird am BASIC Speicherende - d.h. am freien Ende des gesamten Basicspeichers - begonnen, die erste Variable reinzuschreiben, dann darunter die zweite, darunter die dritte usf.
Hier ist es nun so daß quasi mittig zwischen Ende des Programmes und dem Variablenbereich diese Sceennroutine und auch der gepufferte Inhalt liegt - davon weiß das Basic aber nichts und schriebt da natürlich hemmungslos drüber.
Zu den Blocks müssen mal andere was sagen.
Das Maschinenprogramm ist da nicht mit dabei, das wird erst durch das Poken erstellt. Und auch wenn es im Speicher steht, sollte es nicht mit gespeichert werden, weil es eben das obere Ende vom BASIC Programmbereich nicht ändert. Das Ende vom BASIC Programm ist immer durch drei 0 Werte - also $00 $00 $00 - im Speicher gekennzeichnet. Bis dahin wird von SAVE alles abgespeichert, alles darüber nicht mehr. Aber 15 zu 3 ist wirklich schon ein Unterschied.
Alles anzeigenWegen der sechs Zeichen am Bildende ... das ist wahscheinlich schon Dein Variablenspeicher. Ich vermute, daß Du die Texte für den Hilfescreen als Stringvariablen angelegt hast ??
Die Routine klebt einfach mittendrin im BASIC Speicher. Wenn man wenige Variablen benutzt klappt das, weil hinter dem Screen ( von $7800 an bis + 40*25 Zeichen ) noch ein bißchen Platz ist. Aber eben nicht für große Mengen, sondern eher nur für das Schlangenarray gedacht und eine Handvoll kleine Zählvariablen o.ä.
Zumindest wäre das mein Tip, weshalb da sowas mit drin steht.
Die echte und besser Lösung wäre, daß man das Ende vom BASIC Speicher korrigiert. Dafür gibt es normalerweise auch eine Speicherstelle, wo man per Poke reinschreiben kann, wo der BASIC Bereich zu Ende sein soll. Wenn man das ganz zu Beginn des Programmes ändert - nämlich bevor man die allererste Variable belegt, dann sollte das eigentlich klappen. leider weiß ich beim PET dafür die Speicherstelle nicht. Da müßte man mal in ein Buch gucken.
Was Du auch machen kannst, wäre den Bereich vom Screenpuffer einfach weiter vorne hinzulegen. Aktuell beginnt der bei $7800. Wenn man das nach $6800 legt, ist auch schon mehr Platz dahinter. Dazu würde man in Zeile 201 in der Datazeile die "120" ändern. Für den Beginn bei $6800 würde man dort statt der 120 in Zeile 201 eine "104" reinschreiben.
Warum ist das so ? Beim Commodore Basic wird das Programm vorn im Speicher abgelegt und neue Zeile werden dann aufsteigend im Speicher angelegt. Die Variablen aber müssen ja spätestens wenn das Programm läuft auch irgendwohin. Und dafür könnte es auch einen extra Speicherbereich geben - tut es aber nicht. Stattdessen wird da einfach vom anderen Ende begonnen die Daten abzulegen, d.h. es wird am BASIC Speicherende - d.h. am freien Ende des gesamten Basicspeichers - begonnen, die erste Variable reinzuschreiben, dann darunter die zweite, darunter die dritte usf.
Hier ist es nun so daß quasi mittig zwischen Ende des Programmes und dem Variablenbereich diese Sceennroutine und auch der gepufferte Inhalt liegt - davon weiß das Basic aber nichts und schriebt da natürlich hemmungslos drüber.
Hi!
Zwischenbericht: Wenn ich den Wert von 120 auf 104 ändere, kommen die Zeichen in der Tat nicht mehr! JUHU!!!
Allerdings- und hier hab ich ein großes Problem: Nach ändern, speichern und wieder darstellen des Levels kommt nur noch Zeichenwirrwarr.
Ich verwende in der Tat viele Variablen, bzw. einiges an Platz, um die Umwandlung des Bildschirminhaltes in CHR$-Zeichen (für den String in der Leveldatei) umzuwandeln. 21 strings mit mindestens 38 Zeichen (bei inverser Darstellung entsprechend mehr, wegen der Steuerzeichen fürs Invertieren).
Und was noch auffällt: Das petSD+ Laufwerk verhält sich äußerst suspekt jetzt. Zum allerersten mal hat es das Level als "SEQ"-File abgespeichert?! Normalerweise macht es IMMER die Endung "PRG" an solche Dateien. (Wohl eine Eigenart des Laufwerks)
Also in Summe ist Einiges fischig- wohl, weil- wie du schon schreibst- der Speicher anderweitig belegt ist, und es zu Konflikten kommt. 
Schade, denn die Geschwindigkeit + die Einbindung deines Codes ist echt der HAMMER!
Na ja. Kann schon sein, daß das nicht perfekt ist. Es war ja auch mehr als Anregung gedacht sich damit mal zu befassen, weil es eben einfach beim 6502 extrem sinnvoll ist, das bißchen zu können. Es ist viel schneller und auch eigentlich relativ einfach und auch nicht wirklich schwer selbst zu lernen.
Die Routine ist i.Ü. auch eher gedacht gewesen den Hilfebildschirm einzublenden und nicht das Level abzuspeichern. Wenn der Hilfebildschirm an ist, darf dann auch z.B. die Schlange nicht weiterbewegt werden etc.
Nimm es evtl. einfach als Einstieg, sich das mit dem Assembler mal selbst anzuschauen und wenn Du denkst, daß Du ne Vorstellung hast, was da passiert hast Du schon viel neues gelernt. Der toughe Stuff ist dann das andere Listing oben. Da ist ganz viel dabei, was "BitZauberei" ausmacht.
Ich könnte Dir die Routine hier evtl. für den Plus/4 fix-und-fertig hinstellen. Beim PET bin ich aber selber nur Anfänger und auch gerade eher mal wieder am Schauen, was es da alles so gibt/gab.
Manches ist halt durchaus ähnlich, aber gerade so Sachen wie Speichereinteilung und Art der Benutzung unterscheiden sind dann doch ganz gut anders.
Wenns so gar nicht klappt, laß es einfach raus und mach es später mal selber dazu, wenn Du mit der Maschine gut warm geworden bist.
Allerdings- und hier hab ich ein großes Problem: Nach ändern, speichern und wieder darstellen des Levels kommt nur noch Zeichenwirrwarr.
Dann schrieb doch mal Deine Save Routine hier rein.
Das normale Datenspeicher Format sind schon durchaus SEQ Dateien. Das ist also eigentlich gar nicht so falsch.
Vielen herzlichen Dank für all den Wahnsinn, ThoralfAsmussen !
Kurz zur Funktionsweise des Leveleditors:
Es ist ein extra Programm und hat mit dem eigentlichen Spiel nichts zu tun.
Man hat einen Bildschirmeditor, in dem man 21 Zeilen mit je 38 Zeichen voll"pinseln" kann.
Keine Schlange, kein Ringpuffer, etc...
Dann kann man das gezeichnete Level abspeichern. Hierzu fahre ich mit einer Schleife den Bildschirm Zeile für Zeile ab und wandle mittels PEEK das an der bestimmten Speicherstelle befindliche Zeichen in ASCII-Code um, welchen ich in einer String-Variable ablege.
Der Grund ist schnell erklärt: Ohne Umwandlung müsste ich Zeichen für Zeichen als Code in der Datei ablegen, was beim Laden und dem darauffolgenden Zeichnen EEEEEWIG dauern würde. Mit Umwandlung lade ich einfach 21 Strings ein und bringe sie mit einer Schleife auf den Bildschirm- all das funzt auch perfekt soweit.
Im Spiel wird das Level einfach geladen- der Ringpuffer für die Schlange, die Kollisionsabfrage, etc... -> alles im Spiel.
Der Leveleditor ist wirklich nur das "Zeichenprogramm". Hier würde ich aber gerne einen Hilfebildschirm einblenden. Daher deine Routine, um wieder zum gezeichneten Level zurückschalten zu können.
Ohne deine Routine müsste ich das Level vorher in diese Strings umwandeln (was ca. 1,5 Minuten dauert), dann den Hilfescreen einblenden, und im Anschluss das Level wieder "laden" (bzw. in diesem Falle einfach die Strings wieder mit einer Schleife auf den Schirm bringen- dieser Schritt ist der Schnellste und dauert max. 2 Sekunden).
Selbst, wenn ich für die Umschaltung des Hilfebildschirms einfach die jeweiligen PEEK-Werte in Variablen ablege und danach erneut wieder auf den Schirm bringe -> dauert zu lange.
Was ich soeben noch rausgefunden hatte: Auch, wenn ich den Data-Wert auf 120 belasse, steigt das Programm beim Umwandeln fürs Speichern mit Zeichenwirrwarr aus.
Dein Ansatz, mit deiner Routine den Assembler, bzw. 6502 besser zu verstehen, ist echt ein GUTER! Weil es ein PRAKTISCHES Beispiel ist, an dem man auch ein wenig schrauben kann... so hoffe ich jedenfalls. Mein großes Problem (schon seit ich denken kann) ist einfach, dass Mathe und Logik nicht immer meins ist: Ich "verkopfe" dann zu sehr, und blockiere. Doof zu beschreiben... bin eher der künsterlische Typ, der technisch dennoch was gebacken bekommt (weshalb auch immer) 
Viele Grüsse,
Matthias
Allerdings- und hier hab ich ein großes Problem: Nach ändern, speichern und wieder darstellen des Levels kommt nur noch Zeichenwirrwarr.
Dann schrieb doch mal Deine Save Routine hier rein.
Das normale Datenspeicher Format sind schon durchaus SEQ Dateien. Das ist also eigentlich gar nicht so falsch.
Mach ich später- kann nur einen Screenshot vom Schirm machen, weil VICE nicht läuft.
Das normale Format ist SEQ, richtig. Ich öffne die Datei auch so "NAME"+",S,W".
ABER: Beim petSD+ werden PRG-Files daraus... irgendwo steht im Netz auch, wie das so läuft mit dem Ding.
An einer normalen Floppy werden's SEQ-Files, hier passt also alles.
Durch deine Routine jedoch wurde erstmalig auch beim petSD+ ein "echtes" SEQ" draus. Evtl. könnte man ergründen, woran dies liegt.
Na, da liegt wahrscheinlich dann einfach soviel Zeugs im Variablenspeicher, daß es auch die Routine selbst killt. Dann müßte man die evtl. auch einfach mal noch weiter "runter" verschieben. Das geht aber jetzt nicht auf Anhieb mit einer einfachen einzelnen Zahlenänderung.
Leveleditor also , ohne Snake ... OK.
Ich würde ja wahrscheinlich die PEEK Werte direkt auslesen und als ungewandelte Zahlen in ein Array schreiben. ( DIM A(1000) oder einzeln als Zeilen mit DIM Z1(40), Z2(40) .... ) Dann würd die Umwandelei komplett wegfallen. Und Array's lassen sich eigentlich auch als Daten wegspeichern.
Was da viel Zeit kostet ist doch anscheinend die Wandelei in CHR$ Codes.
Alles anzeigenNa, da liegt wahrscheinlich dann einfach soviel Zeugs im Variablenspeicher, daß es auch die Routine selbst killt. Dann müßte man die evtl. auch einfach mal noch weiter "runter" verschieben. Das geht aber jetzt nicht auf Anhieb mit einer einfachen einzelnen Zahlenänderung.
Leveleditor also , ohne Snake ... OK.
Ich würde ja wahrscheinlich die PEEK Werte direkt auslesen und als ungewandelte Zahlen in ein Array schreiben. ( DIM A(1000) oder einzeln als Zeilen mit DIM Z1(40), Z2(40) .... ) Dann würd die Umwandelei komplett wegfallen. Und Array's lassen sich eigentlich auch als Daten wegspeichern.
Was da viel Zeit kostet ist doch anscheinend die Wandelei in CHR$ Codes.
Juhu!
Die Routine funktioniert so:
Man zeichnet sein Level und geht zum Menüpunkt "SAVE". Dann beginnt die Umwandlung:
Diese Routine braucht LANGE, weil sie eben die 21 Strings aus den von PEEK gelesenen Codes macht. Eventuell ginge das auch schneller, aber ich kann's nur so.
Dann wird gespeichert (dies geht sehr flott, sind ja nur diese 21 Strings):
Beim Laden geht auch alles sehr sehr flott, weil eben wieder nur die Strings eingelesen und auf dem Schirm ausgegeben werden:
Würde man den Wandel in CHR$-Codes nicht machen, müsste man Zeichen für Zeichen speichern und im Spiel später einlesen- das dauert viel zu lange, deshalb dieser Umweg. Kleiner Nachteil: Doppelpunkt und Komma sollten ebensowenig vorhanden sein, wie gewisse Steuerzeichen.
Aber die lasse ich von vorneherein im Editor nicht zu, und sie fehlen für ein schönes Leveldesign auch nicht unbedingt.
Viele Grüsse,
Matthias
