PETRock running on Blue PET displays snow. Can code be modified to avoid it?

[jimdinunzio]

Early Blue (bezel color) PETs from around 1978 are called static RAM PETs and they exhibit snow on the screen for any programs that do fast refresh FPS. This is due to a hardware limitation. Some early games worked around this problem with careful timing and reduced fps to avoid the snow.

A full description and hardware solution is nicely documented here on vcfed

My Blue PET running PETRock

I'm wondering if anybody knows how hard it would be to modify PETRock to achieve this. Not sure if I have time to get back into 6502 assembly myself, but it could be an interesting challenge.

[rbergen]

I just wanted to add some things to this discussion for the benefit of anyone reading it. In doing so, I'll apply the transparency I usually do:

• Dave and I are aware of the snow. I know I've seen some video footage of one of his PETs showing it at some point, but I don't remember if that was ever included in a Dave's Garage video.
• Personally, I don't own any authentic PET machines (I did my development and testing using a MiniPET), which provides me with a dead end when it comes to implementing and properly testing any resolution.
• In the area of managing expectations: this project is pretty niche. I love the fact you not only raised the issue but also refer to very detailed information pertaining to it, but I'll also voice the expectation that if a solution is to be provided at the PETRock source code level then I'm pretty sure you'll have to (re)sharpen the 6502 knives yourself, at some point. Unless you managed to inspire Dave to pick up this improvement to the existing code, of course. :)

That said, I obviously agree it would be nice if we would have a smoother visual experience on the hardware in question.

[jimdinunzio]

Yes, it is pretty niche. There probably aren't too many people trying to fix screen artifacts for a board # 1 PET, a design which was fixed in models built in 1979 and later. Could just find a slightly newer MB and swap it out I've been told. But that's another search and hardware work.

I found specific info on how software avoided the snow using screen blank or wait for retrace discussed here (history). If one of these work arounds is used, it's unknown whether the PETrock program would still refresh fast enough to be functional. Seems like an interesting challenge, but not sure of the effort level for value of the result. I'm consulting the experts at the VCFed forum on that discussion I referenced my first post.

[rbergen]

Looking at both workarounds I think the wait for retrace approach would be the most viable for us.

As you say, one question is how much "FPS" we lose with that, as what we have now is pretty close to the lower limit of a somewhat smooth visual experience. At a more detailed level, I'd say it depends on the amount of CPU time you lose on checking retrace status and possible context switching between doing the screen refresh and the processing of incoming serial data; the latter is something that also can't wait.

The other question is if it's still possible to perform a full screen refresh within the retrace period if one also has to do the inbound serial data processing "in parallel". Which is exactly what I think requires actual board #1 hardware to tune and test.

Please let us know what your VCFed forum discussion yields, as I'm genuinely curious!

[jimdinunzio]

A senior member, Eudimorphodon from VCFed wrote this to get me started. Maybe Dave can verify this analysis. I will try to find some time that I could work on it.

Does your program disable the normal 60hz clock interrupt of the Commodore PET? This interrupt is generated by the video circuitry when it enters the vertical refresh area and is normally used as the trigger to run the keyboard scan routine, blink the cursor, and update the real-time clock register. If the rest of your program can deal with those interrupts it would seem a relatively straightforward thing to do would be to batch screen updates to happen synchronously with that interrupt. (The description of your program in the Github repo says it happens at around 40 FPS, I suppose with this approach maybe you'd attempt to update the screen every other sync interrupt, or 30 FPS?)

... OK, I guess looking at your serial driver code you disable the vsync interrupt in favor of letting the VIA use it. So... clearly this makes life harder. (Ignorantly looking through the code, it appears you're not using the shift register, you're doing an interrupt for every bit?) It looks like the code already manages to interleave keyboard scanning with serial communication, so would it make sense to enhance this so in the in-between-bits space it would check the state of PB5 on the PIA that the Vsync line is connected to and kick off a chunked-for-the-time-available screen refresh loop that updated the screen contents with updates that were "cached" at times you're not in the vertical refresh state? This would let you tack the snow surpression onto the serial driver without having to actually re-enable the vsync interrupt?

[rbergen]

I'll comment on this myself as well, because I'm actually the guy who added the serial driver for the PET to this project (with credits to Hayden Kroepfl's earlier work on PETTERM, as mentioned in the serial driver's source file header).

Yes, the serial driver disables the VSYNC interrupt so that the VIA can use it to chase incoming bits and implements its own keyboard scanning routine. If you look closely, you can see that the driver actually includes two keyboard scanning routines: one for lower bitrates, and one for higher ones. This is what allows the driver to run at 2400 bps with enough CPU capacity left to do everything else PETRock needs to do.

It's been a while since I worked on this, but I think I remember the shift register on the PET is broken in a way that gets in the way of doing what the serial driver needs to do in the context of PETRock, at least at the speeds we're discussing.

I agree that a solution would indeed be to build-up the screen "in cache" - a cache that would first have to be created as part of this effort -, and push that out to the video RAM when the CRT beam is vertically retracing. What I'm not sure about is if the 6502 has enough clock cycles per second to be able to carry this "draw-to-cache and then chunk-copy-to-video-RAM" approach with an acceptable effective FPS. For clarity: I'm not meaning to imply it doesn't, I genuinely don't know. I am doubtful because the combination of "just" the serial handling at 2400 bps and the keyboard scanning already requires a more "economic" approach for the latter at higher bitrates.