Understanding PET programming
Posted: Thu May 28, 2020 6:14 pm
Hello everyone!
This post is a bit funny, as I first learned programming on a PET 4032. And here I am again...
The first dungeon "crawler" game that I ever played was DUNGEON from CURSOR#15. I've found a .prg file of it and have been looking at in through an online PET emulator to understand the code. My goal is to recreate the program in a different language.
Some of the code is, from what my reading tells me, done up for speed, some of it is done because, I'm guessing, this is how "things were done" and some of it is a plain mystery. Like this bit that gets called very early in the program run:
50000 is 0xC350, but in looking at memory maps, this would be smack in the middle of Basic ROM territory. So I guess C350 is a magic location, but I've not been very successful in finding out just what that might be.
The reason this is important is that those QM values drive some code later on. I'm suspecting this is related to determining maximum size... but I'm not sure... this is the bit that also throws me:
# SZ is calculated to be 920 (I believe 23 rows * 40 columns, which would make sense for the game screen...)
# QM is either 134 or 52...
This is further supported by the very next line which, I believe, is setting up an empty grid in memory, where the dungeon is created. This is why I think TS is something about total size or some limit after which it can start mapping memory to represent the dungeon data structure.
Any insights in helping me understand how memory was getting set up here?
Thanks!
Michael
This post is a bit funny, as I first learned programming on a PET 4032. And here I am again...
The first dungeon "crawler" game that I ever played was DUNGEON from CURSOR#15. I've found a .prg file of it and have been looking at in through an online PET emulator to understand the code. My goal is to recreate the program in a different language.
Some of the code is, from what my reading tells me, done up for speed, some of it is done because, I'm guessing, this is how "things were done" and some of it is a plain mystery. Like this bit that gets called very early in the program run:
Code: Select all
60400 QK=525:QM=134:QP=515:CR$=CHR$(13)
60410 IF PEEK(50000) = 0 THEN RETURN
60420 QK=158:QM=52:QP=151
60430 RETURN
The reason this is important is that those QM values drive some code later on. I'm suspecting this is related to determining maximum size... but I'm not sure... this is the bit that also throws me:
# SZ is calculated to be 920 (I believe 23 rows * 40 columns, which would make sense for the game screen...)
# QM is either 134 or 52...
Code: Select all
190 TS=PEEK(QM)+256*PEEK(QM+1)-SZ:AX=32768
Code: Select all
200 FOR I = TS+40 TO TS+SZ-41 : POKE I,32: NEXT I
Thanks!
Michael