Understanding PET programming

If you want help with your PET, VIC, 128 or Plus4 programming, this is the place for you!

Moderators: wiskow, Trazan

Post Reply
User avatar
Chgowiz
Posts: 4
Joined: Tue Jun 27, 2017 2:21 pm
Are you a real person?: No... I am a spambot, delete my account!
Contact:

Understanding PET programming

Post by Chgowiz »

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:

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
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...

Code: Select all

190 TS=PEEK(QM)+256*PEEK(QM+1)-SZ:AX=32768
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.

Code: Select all

200 FOR I = TS+40 TO TS+SZ-41 : POKE I,32: NEXT I
Any insights in helping me understand how memory was getting set up here?

Thanks!
Michael
User avatar
Chgowiz
Posts: 4
Joined: Tue Jun 27, 2017 2:21 pm
Are you a real person?: No... I am a spambot, delete my account!
Contact:

Re: Understanding PET programming

Post by Chgowiz »

As an addendum, I've managed to get beyond this bit - it looks like that the idea here is to find out where memory ends. I'm assuming that the first bit of code is perhaps for a different version of PET - QM points to memory location 52, which is a pointer to the "start of memory". I believe that's screen memory.

That's what line 190 does, it gets that limit and then uses that as a way to "back up" 920 memory locations - which is the size of the dungeon. This grid then gets created in memory.

What's also fascinating is that Brian Sawyer set up a timer - sixty seconds - and generated the dungeon within that time. After sixty seconds was up, you got what you got - this explains why there were unconnected rooms! The program ran out of time. Neat stuff!

I'm noting other things I find as I go on Twitter and on Facebook, if you're interested. (If you're finding this years later, look around May, June of 2020)
https://twitter.com/chgowiz and https://www.facebook.com/michaelchgo

I'm very impressed with the tricks that programmers used to make things work on these old computers.
User avatar
Chgowiz
Posts: 4
Joined: Tue Jun 27, 2017 2:21 pm
Are you a real person?: No... I am a spambot, delete my account!
Contact:

Re: Understanding PET programming

Post by Chgowiz »

If you're curious, I have a git repository going with the original source, my annotations on that source as I go, and my python code. Right now, I'm still working on dungeon generation and using a simulator for it.

https://github.com/Chgowiz/PyDungeon
milasoft
Posts: 6
Joined: Thu Jan 31, 2019 6:07 pm
Are you a real person?: No... I am a spambot, delete my account!

Re: Understanding PET programming

Post by milasoft »

It could be to check for compatibility between PET models. I know some machines use different locations to read keyboard, etc.

Also, maybe to work on the 80 column PET? I'd have to take a look at the program code to confirm any of the above.
Post Reply