I don't know the intricacies of PET programming, but it looks to me like @tsky is trying to show that not only are you SYSing to the wrong address, you're JMPing to the wrong address too. The LDA #0 never gets executed in the sample shown, and is probably $FF for the duration of the test. I don't know the best way to fix it, but it needs to be fixed somehow.

The sloppiest way might be to just tuck another SEI and LDA #0 right before the JMP ... it's so crazy, it just might work!

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Thanks!

To get around this issue, I have assembled and then examined the output of this...



Which becomes this...

173,18,232,215,0,128,76,122,2,0

I am going to poke those values right to location 634 (tape buffer ram) and try running it there.
.... when I have time!

I do also think this odd offset thing is messing me up. I just know I have to work around it somehow.

Brad

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:

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.



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

Problem Solved!!

Just as I was about to give up, I decided to take the assembled binary and run it through my IEEE simulator and loaded it onto the real PET.
Whadda ya know. it works as expected!

Must be a Vice thing with the keyboard or screen refresh. The program shown above displays keypresses just as I would have expected.
Ok, back to the project. Now I need to see how fast I can actually stream data to the PIA externally.
I still may be beat by the 60Hz interrupt, but only real testing will prove this true or false.

My next code / hardware test will toggle bit 0 on the 74LS145 row select using INC $E810, making it act as a "Clear to Send" line. The external device will then send the next byte to the PIA through the cable I have attached. The PET keyboard data port will be temporarily disconnected form the PET hardware by the 2 74HC245 buffers I have on my board. The PET will grab the data and hurl it to the Basic Memory starting at location 1025. Once loading is complete, the external device reconnects the keyboard and goes invisible to the PET.

If I get decent speed from reading the PIA, then I should be able to load a 32K program into the PET in under a second.
Will report back when the testing is complete (with video of course)!

Thanks for the help, I am certainly straight with how to assemble a PET program now.

Cheers,
Brad

Just to properly close this thread, here is the assembled binary that now works. You can just drop this over a Vice window.
This is not a zip file, just a binary (getting around forum upload limitations).

The 74LS145 is set to ROW.2, which allows these 8 keys to be displayed (97^OUTEQ).
I chose those because they are ascii, and I need at least 8 keys to represent an 8 bit value (makes life easier).
Pressing any of those keys will change the first screen character.

As a speed test, I am also streaming 256 characters to the screen, and it does seem to show that the PET Kernal is not stealing much CPU time at all. Rough tests show that I should be able to get around 30 kilobytes per second into the PIA! Real hardware will prove this soon.

Oh, and on the Vice thing, seems it is maybe a Win11 bug. I eventually did get this code to work in Vice, but only after starting Vice fresh and then clicking twice in its window. Seems it does not get keyboard focus all of the time!!!! That messed me up for a day! Does this on some game programs too.

Anyhow, case closed, thanks for the help.
Brad

Noticed one more thing today as I tried some code changes in the emulator...

Vice keyboard handlining is definitely buggy under Windows11!
It works for a while and then randomly looses focus. You have to click the window tab again to regain keyboard control.
This happens with all machines - PET, VIC, C64, etc.

That quirk was the main reason for thinking my code was failing, so be aware if you are using Vice in WIN-11!
Normally I never touch an emulator, but it was easier for this initial code testing.

Later,
Brad

Sorry to chime in so late, busy work times right now. Glad you were able to solve it!

What version of VICE did you use? Did you file this as bug report to the VICE team here https://sourceforge.net/p/vice-emu/bugs/ ?
Can you check with the current version (from their svn repo)?

They are preparing for a release and this can then hopefully fixed before that date (if it isn't already).

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/