Only implemented cursor flash routine. It's 6 frames of black, 3 frames of grey, 6 frames of white, 3 frames of grey and then looping. 4-2 is too fast. Object code attached.
There are different approaches. A wrong move could give penalty on the timer. Others only check for the solution and no clue is given whether you're on right track or not. You might then end up in a situation with a solution you think is right but nothing happens. Your solution is then wrong, and often you would want to start all over. A reset option would be nice. Some adds time when you make a correct move. Some games have a progress percentage. Oh, and I should not forget the "pixel size" version suggested by matthew180 in post #7.
Maybe I should rename level and call it puzzle. I guess I'll store a puzzle in 10 words. Don't know if I'll name the puzzles - only revealed when completed. If you can't make out what the puzzle/image looks like, then the name should help you recognise. Instead of being able to go to any level, maybe you could enter the name, and then go to that puzzle or in fact the puzzle right after - a way of coming back to the game without a game state save (I don't want to save/update from assembler - too lazy - and I'm trying to keep an 8K cartridge output open as a after contest option).
I guess I'll keep the board state in VDP - on screen. A complete check against the solution - for whatever game options (see top) - would be like reading 10 rows from VDP - 100 bytes. Does not sound very efficient, but then I guess we have more than enough CPU time. Keeping in mind that I'd like to keep variables in ScratchPad (the 8K cart option). Maybe I should just keep the board state in ScratchPad ...
Place NO in DSK1. E/A-cart, 3 Load and run, file name DSK1.NO, program name S.
Edited by sometimes99er, Sat Jan 7, 2012 6:59 PM.