letzter Beitrag von tnt am
hehehe... ich machs aufm echten c64... und der sagt bei DIR oder LS: syntax error 
(und bei load"$",8 sagt er: 1 !!!! (1 block) )
naja...meistens mache ich das aber nur auf einem blatt papier.... und das sagt bei einem DIR garnix!
Da hilft nur opcodes zählen.... 
Dann zähl Opcodes oder schmeiss nen AR/RR/FC3 an 
Und vergiss beim Zählen die, falls vorhanden, vorgefertigten Daten nicht.
(Hat das EndlicheModulDrei überhaubt nen Monitor Programm?)
Ja, und der ist sogar verhältnismäßig brauchbar...
eigentlich ist der monitor das einzig brauchbare an dem cartridge :=P
<90 bytes anyone?
Als ob ich schon angefangen hätte . 
ZitatOriginal von tnt
<90 bytes anyone?
maybe 
....so...ich glaube ich bin nun am ende meines lateins...
ich kann meine routine nicht mehr verkleinern...
jetzt heist es abwarten... 
90 < deine routine < 100?
90 < nicht meine routine < 100! ![:]](https://www.forum64.de/wcf/images/smilies/pleased.gif "Freude"){kind=small}
Does it have to be exactly like the example code, ie. top right pixel is always white?
It doesn't matter with my current code, but if I try different approach then relaxing that rule might help a bit (or even a byte!:)).
Mich würde mal interessieren, was genau alles erlaubt ist.
- Darf man Illegal Opcodes benutzen?
- Kann man davon ausgehen, dass Speicherstellen außerhalb des Programmcodes bestimmte vorbelegte Werte besitzen? Darf man insbesondere vorraussetzen, dass die Register A,X und Y mit 0 vorbelegt sind?
- Ich benutze eine Scrollroutine ab $e8ea, die den Schirm normalerweise eine Zeile nach oben schiebt. Man kann jedoch vor dem Programmstart den Bildschirm so durcheinanderbringen, dass die Routine den Schirm manchmal zwei Zeilen nach oben schiebt. Dies würde mein Schachbrettmuster durcheinanderbringen. Kann man vorraussetzen, dass das zu schreibende Programm einfach von Floppy oder Tape geladen wird und mit RUN gestartet wird, ohne dass noch irgendwelche Aktionen durchgeführt werden?
Ich habe mein Programm jetzt praktisch so weit optimiert, dass ich es nur noch mit den oben genannten Tricks verkürzen kann. Ich entwickle normalerweise unter Windows mit dem Emulator Vice. Zum Ausprobieren habe ich mein Programm auf eine Speicherkarte geschrieben und mit MMC64 auf meinem C128 gestartet. Dort läuft das Programm leider nicht wie erwartet, da die Speicherstellen teilweise anders vorbelegt sind. Das X-Register steht dort standardmäßig nicht auf 0. Deshalb frage ich lieber nochmal genauer nach.
also,
ich bin der Meinung, dass das Programm unter folgenden Voraussetzungen laufen muss:
1. Der Computer (ein standard C64 ohne Erweiterung oder Modul) wird angeschaltet.
2. Das Programm wird geladen (mit LOAD"FILENAME",8,1)
3. Das Programm wird mit RUN gestartet...
...das wars.
So hat jeder die gleichen Voraussetzungen und einen definierten Startzustand...
Ps: was illegale Opcodes oder ROM-Routinen betrifft.... warum nicht? Sind auch ein Teil des C64...
ZitatOriginal von BastetFurry
@tnt:
Where do you see a white pixel?
Screenshoot maybe?
BastetFurry: tnt means:
does the chessboard have to start with a white field in the upper left corner,
or could it also start with a black field?
(something I was thinking about, too.... but I managed to do it both ways...)
BastetFurry2: Also können wir von den von mir oben genannten Voraussetzungen ausgehen?
ZitatOriginally posted by Roland
Ps: was illegale Opcodes oder ROM-Routinen betrifft.... warum nicht? Sind auch ein Teil des C64...
So, can I assume first NTSC kernal version, where jsr $e544 sets $d800 to #1 no matter what $d021/$0286 are?
ZitatOriginally posted by Roland
BastetFurry: tnt means:
does the chessboard have to start with a white field in the upper left corner,
or could it also start with a black field?
Yes, and top right pixels always being white means "step 0" of character animation being 8*FF,8*00 (or vice versa) instead of for example 8*f0,8*0f which gives the same effect in the middle of the screen, but corners look different.
I guess I've hit my limit with the current method, but then I thought that yesterday and got it one byte shorter today
ZitatOriginal von tnt
So, can I assume first NTSC kernal version, where jsr $e544 sets $d800 to #1 no matter what $d021/$0286 are?
hhmmmmm.... tough to answer....
...cause I didn't start this competition....and don't set up the rules....
PAL or/and NTSC ??.... or Vice standard-setup...
EDIT: after checking the original code example, I have noticed, that the upper-left field is BLACK at the initial state (#00/#FF) ....so... I have changed my routine....
For the KERNAL, assume nothing, this should run on every PAL-C64 you could get hand on.
Its the same as with coding games for todays machines (PCs..).
You cant assume anything, so code for the normal and if you, as the coder, come accross special cases, think of them.
As long as i can run your entries on my real C64-I (transported via MMC64 to a real disk, if you care) its all fine. If they crash ill try them in Vice, to ensure that its my or your fault, ie, hard or software
ich denke so wie bastetfurry das geschrieben hat ist es ok..oder?
damit können wir alle leben...(denn ein VICE hat ja zur not jeder...)
ZitatOriginally posted by BastetFurry
For the KERNAL, assume nothing, this should run on every PAL-C64 you could get hand on.
So one can't use $e544 to set colors (and clear screen) as the color depends on kernal version - $d021 in early PAL C64, $0286 in later ones.
(Damn, NTSC kernal would have saved me four bytes... ;))
