Thanks, that is correct, the +2 was there from another program that needed the offset. Forgot to remove it.
Now when I run the code with SEI, it crashes (ends up in the machine language monitor).
If I remove SEI, then it returns to normal operation, but zero input shown from the keyboard.
Not sure why issuing SEI caused the PET to bomb.
I should probably explain my goals here.
I have a connection between the PET keyboard port and something I am working on. I am, able to read PET keystrokes and even send PET keystrokes, which is required for my project. All good so far.
What I also want to do is have the PET read data being sent as fast as possible from this external device. This is the reason for wiring this PIA input capture program. What it will do is stream bytes read from the PIA into the PET's program memory starting at location 1025. So yeah... it will load programs into the PET just like the IEEE port does, but using the keyboard port instead.
So you may wonder... how does this strange little BootLoader get into memory in the first place? Well, it is poked into the cassette buffer at location 632 by the external device that temporarily hijacks the keyboard through the port. And yup, this part actually works already! The AVR covertly listens to the 74LS154 lines and then stuffs data into the VIA, simulating lightning fast input from the keyboard. It can poke the tiny bootloader into RAM in a few seconds. Once done, the command "SYS 634" is issued and then I want the PET to hurl bytes into RAM from the PIA.
Loading performance will be even faster than anything possible on the IEEE port. I expect to get at least 60 kilobytes per second!
But if I am a slave to the kernal, then I can only read bytes at 60 hertz, so that kills the entire idea dead.
In that case, I will have to go back to a plug in the option ROM socket and run my transfer from there.
I have to tap the keyboard plug anyhow, so I figure this would greatly reduce my wire count.
The only thing I can't solve is how to directly read data on the PIA PORTB, which I thought would be the easiest part of this experiment!
Oh, I am using VICE for the code tests, so I know I am not being beat by some hardware bug.
Here is my hardware rig so far...
The other ICs on the board are converting the video to the 1702 monitor. I will post this project in more detail when it gets off the ground, but here is the core idea...
https://www.youtube.com/watch?v=irBI9fVE9dYThanks,
Brad
tsky wrote:
Oneironaut wrote:
Ok, the .ORG2000+2 is to remind myself that when you load a program into the PET, it adds 2 bytes to determine the start of the basic program, even though it cannot actually be relocated like on other C= machines. This is all good - no bogus bytes are executed.
Brad
I think you might have a mismatch between the ORG address and where the code lands in memory. The SYS(2000) jumps to 2000. The JMP instruction at the end of the loop is going to jump to 2002. One of those is wrong.