Thanks, your example helped jog my memory as to why I needed this -2 offset. It has been a year since I did any PET assembly, and it all came back to me. Once loaded, the PET tosses the 2 location bytes and all of your assembly shifts in memory by -2.
Code:
; ******************************************************************
; ********** PET BASIC PROGRAM STUB
; ********** SAVE CODE STARTING @ 1025
; ********** JUMPS NEED -2 DUE TO LOADING OFFSET
; ******************************************************************
; START OF BASIC RAM
.ORG 1025
; BASIC LOCATION BYTES
.WORD 1025
; ADD BASIC LINE : 0 SYS1037
.BYTE 11,4,0,0,158,49,48,51,55,0,0,0
; DISABLE PET INTERRUPT (does nothing!)
SEI
; ******************************************************************
; ********** MAIN LOOP
; ******************************************************************
MAIN:
; ALIVE TEST
INC 32769
; SET KBD.ROW
lda #0
STA $E810
; READ KBD.COL
LDA $E812
STA 32768
; LOOP
JMP MAIN-2
I found my original stub, which worked perfectly in the assembler use, so I am back on track with the jump addresses and such. I also found a bug in the latest Vice that was tossing me for a loop as well. Seems the "ALT-F12" hard reset works only for so many times if you write code that locks up the PET. The reset "seems" to work, but after about 4 times it will somehow cache the last code that ran. This really threw me for a few hours. I now just exit Vice fully and then drop my PRG onto the window rather than relying on the built in Hard Reset function. No problems since.
Ok, back to the original problem. In no way can I read the PIA data register, which should show some data no matter which line of the 74LS145 is set. Since the 145 ALWAYS has at least one line low (row selected), some key data should show on the PORTB input. I have tried every key, and nothing.
Here is my adjusted code, dealing with the -2 offset in a way that makes most sense to me. For sure, this code is working, and the INC 32768 (first instruction) is working fine, showing me that my code is in a tight loop. As before, no keypress alters the value read on the PIA input port. SEI also has zero effect on code execution or speed, so I am convinced now that you can't actually stop the PET from running the Kernal code (editor). It must be taking over and clearing the data before my code gets a chance. Nothing else makes any sense here.
I am now out of ideas. On the VIC, this was so easy... just autoboot at that cartridge port address, stop interrupts, and have total control of the machine.
I guess those that coded games in assembly for the PET must have had to use the Kernal routines to read the keyboard, and damn that is going to be slowwwwww! Since the IRQ only fires 60 times per second, that will reduce my goal of 60+ kilobytes per second transfer speed down to 60 bytes per second. In that case, I am not going to continue with this method, and will have to make a second plug to tap into the option ROM socket.
I was hoping to reduce my plug count, but I guess this project is going to end up looking like the beastly board in my Super PET.... plugs all over the place!
Here is my cheat sheet showing the PET keyboard hardware in case anyone is curios as to how the PET Keyboard is connected....
Thanks,
Brad
tsky wrote:
Oneironaut wrote:
Removing the basic "location bytes" makes the PET fail to load the program completely.
If I remember correctly when I wrote this, you have to account for the 2 byte "shift" because after loading, the PET offsets the program, removing those 2 bytes, which is why originally I used .ORG2000+2
The first two bytes are the start address and are almost always 0x01 0x04 and are not loaded into memory. The next byte after those two will land at 0x0401 in memory but in your case the address counter in the assembler will be 0x0403. That's why I suggested .ORG 0x3FF (or 1023 if you like) before the .WORD 1025 (0x401). After the .WORD, the assembler's address counter will be 0x0401, the location where those BASIC bytes will land in memory. Then everything is lined up and you can use .ORG 2000 for the beginning of assembly.
Here is a snippet of the intro to a typical assembly language program I have been tinkering with:
Code:
000000r 1
000000r 1 .code
000000r 1 ;;; BASIC Intro
000000r 1 .org $03FF
0003FF 1
0003FF 1 01 04 .word * + 2 ; Two byte start location for .PRG files
000401 1
000401 1 0D 04 .word bline1 ; pointer
000403 1 0A 00 .word $000A ; 10
000405 1 9E .byte $9E ; SYS
000406 1 28 31 30 33 .byte "(1039)"
00040A 1 39 29
00040C 1 00 .byte 0 ; eol
00040D 1 00 00 bline1: .byte 0, 0 ; eop
00040F 1
00040F 1 ;;; Entry (XXX: assert this is $040F?)
00040F 1
00040F 1 entry:
0040F 1
00040F 1 A9 93 lda #$93 ; clear screen
000411 1 20 D2 FF jsr CHROUT
000414 1