Programming resources for the Commodore Pet?
Posted: Mon Jan 18, 2021 12:01 pm
Wasn't sure where to ask this, thought this is likely the most appropriate place.
I've recently built one of the Mini Pet kits from Tynemouth Software. Always intrigued by the Pet, came across them a lot but mostly in short bursts, a bit of a go with BASIC or watching someone else load something up.
I'm looking to make something on it, with Turbo Rascal of course, but that doesn't factor in as it could easily be with BASIC or a conventional assembler. The problem I have is finding some solid and consistent documentation. I realise I'm so spoilt with Denial and its abundance of information. Plus loads of books. Not finding the same for the Pet.
The Mini Pet can use BASIC ROM's 1 through 4 plus a tweaked BASIC 4 and the documentation says it is close to the 2001 with a 40 column display (9" screen), 32k RAM and the speaker modification. I'll be sticking with the BASIC 4 ROMS and not going to worry about compatibility with others, at least for now.
Found it fascinating digging in, how the 1k video memory just wraps round in the whole of the $8000 - $8fff space. The compatibility issues between BASIC 1, 2 and 4 and can see where the emphasis of vectors probably came from.
There are two areas I am wondering if there are any Pet experts around to point me in the right direction (or have an answer)?
1. Keyboard
I have so far found the byte where I can read one key being pressed that I can check ($97), but that is no good for detecting multiple key presses. On the Vic 20, I can use $9120 and $9121 to select a row and work out what keys are held down. Assume there must be the same on the Pet. Any ideas?
2. Raster / VBL synchronisation
Not sure if the Pet has access to where the raster beam is like the Vic 20 or C64, or if it can detect when a vertical blank is occurring? Initial purpose is just to keep a steady pace in the timing of a game loop so it can run at a consistent speed. The best I have worked out is to read part fo the TI$ variable (the part at $8f) which appears to increment every frame. Looking at example code I do not spot any evidence of how this can be best done. I see a lot of FOR loops to create a delay and relying on a BASIC game's code to enforce an estimated steady pace.
Any ideas for a better way, preferably if I can sync somehow with the vertical blank?
I've recently built one of the Mini Pet kits from Tynemouth Software. Always intrigued by the Pet, came across them a lot but mostly in short bursts, a bit of a go with BASIC or watching someone else load something up.
I'm looking to make something on it, with Turbo Rascal of course, but that doesn't factor in as it could easily be with BASIC or a conventional assembler. The problem I have is finding some solid and consistent documentation. I realise I'm so spoilt with Denial and its abundance of information. Plus loads of books. Not finding the same for the Pet.
The Mini Pet can use BASIC ROM's 1 through 4 plus a tweaked BASIC 4 and the documentation says it is close to the 2001 with a 40 column display (9" screen), 32k RAM and the speaker modification. I'll be sticking with the BASIC 4 ROMS and not going to worry about compatibility with others, at least for now.
Found it fascinating digging in, how the 1k video memory just wraps round in the whole of the $8000 - $8fff space. The compatibility issues between BASIC 1, 2 and 4 and can see where the emphasis of vectors probably came from.
There are two areas I am wondering if there are any Pet experts around to point me in the right direction (or have an answer)?
1. Keyboard
I have so far found the byte where I can read one key being pressed that I can check ($97), but that is no good for detecting multiple key presses. On the Vic 20, I can use $9120 and $9121 to select a row and work out what keys are held down. Assume there must be the same on the Pet. Any ideas?
2. Raster / VBL synchronisation
Not sure if the Pet has access to where the raster beam is like the Vic 20 or C64, or if it can detect when a vertical blank is occurring? Initial purpose is just to keep a steady pace in the timing of a game loop so it can run at a consistent speed. The best I have worked out is to read part fo the TI$ variable (the part at $8f) which appears to increment every frame. Looking at example code I do not spot any evidence of how this can be best done. I see a lot of FOR loops to create a delay and relying on a BASIC game's code to enforce an estimated steady pace.
Any ideas for a better way, preferably if I can sync somehow with the vertical blank?