Commodore static PET (early dynamic PET) video timings?

[tokra]

I've been very interested in the "racing the beam"-technique used by the HI-RES program and the recent "A Bright Shining Star"-demo. The latter one updated 10 characters in video-RAM per line in 60 cycles (LDA #$xx sta $80xx taking 6 cycles each). By my calculations one should be able to do 11-char-wide "graphics" by having the first line of each group of 8 lines updated in the VBLANK-area and only updating the following 7 lines while racing the beam. This needs very exact raster-timing, however. I have mocked this up in Fridgegrid. See image below.

I don't own a real PET (just a MiniPET by TFW8B) so I could only try this in emulation. I would appreciate if the emualtion was as exact as possible. I noticed both demos above don't work correctly on the MiniPET. This is because it does the video-generation a little differently. To check this I have written a short program that measures the cycles of the video- and VBLANK-area with a VIA-timer:

http://www.tokra.de/pet/petcycle.zip

In GTK-VICE for PETs without CRTCS this gives values of 12800 cycles for video and 3840 for VBLANK (with some jitter), while the MiniPET does about 12688 / 4008. I would appreciate if folks with real PETs could run this and report the values and also whether it was run on a CRTC or non-CRTC PET.

 

[GK2001]

Yes; brain fart/typo.

 

[rhialto]

I tried emulating "snow" by just replacing the video RAM data with the CPU read/write data during the cycle it occurs (the data goes through the character ROM). I think it was accurate but it appears much harsher than a real PET probably because the phosphor on a real PET doesn't light up much if its only driven one refresh. I would kind of like to see this on emulators because I think some people are developing programs on emulators and maybe don't realize they are getting a lot of snow on a lot of older machines.

That's just how the code that I'm playing with works... and I'd like to show you a screen shot of the result.

The desired image in the middle is pretty stable. The garbage jumps left and right rather quickly. That's not so strange, since even though the IRQ happens at a fixed time, the CPU will take a variable time to react. Not all instructions it could be executing take the same time, and it will have to finish the running instruction first.

I have used the most "obvious" timing parameters. I'm pretending that the IRQ is generated directly at the right end of the text area. To determine then at which horizontal character position the memory fetch is, is to see how many clocks have elapsed since then, and subtract 24 (the time it takes to go from the right hand side of the text area to the left again).
My debugging output tells me that in each scan line, 6 times it hits memory ahead of the beam, and 3 times it's behind the beam. Although that's not as I expected the timing to work out, the image still looks like the expected "hi-res.bitmap" file, as far as I can tell. I must be missing something.

By the way, I noticed in the code that the hi-res program loads and stores 10 values per scan line, but the last one it stores to some off-screen location. I'm not sure why. Maybe they tried a slightly bigger image first, and decided against it for some reason. Timing-wise, there would be no reason for that, since they kept the extra load and store in the code. If needed, they could have shortened the initial delay a bit...
This also explains why the "hi-res.bitmap" file shows a bigger image with a little bit of garbage. It's created from all the loads in the code, assuming they would all be stored to the screen.

 

[tsky]

That's just how the code that I'm playing with works... and I'd like to show you a screen shot of the result.

That sure looks a lot like the image I shot of my real PET. You can see the garbage to right is the three STX/STY/STA writes because they are closer together. The garbage on the left looks more like the LDA/STA/LDA/STA (6 cycles apart). Perhaps they used the STX/STY/STA writes to nudge the garbage/snow a bit over to the right and out of the "hires" block.

And, yeah, the columns of garbage jump around on the real PET for the reason you mentioned. I think the longest 6502 instructions are 6 cycles so maybe that's the maximum interrupt latency jitter.

Funny, I think I now remember this program. I had a subscription to Cursor about that time and remember being kind of freaked out by the weird flashing snow and thought it would hurt the computer!

 

[tokra]

It is interesting to look a the original CURSOR-magazine here:

Cursor Issue 01 thru 30 : Free Download, Borrow, and Streaming : Internet Archive

Cursor Issue 01 thru 30

archive.org

It actually talks about a tenth column and how the code is not fast enough. Are we sure what is in the VICE-repository is actually the code as published back in March, 1980?
In the meantime I also found out that the MiniPET can be switched to a 9" PET-video output mode and in that mode both the HI-RES program as well as the demo "A Bright Shining Star" actually work on it. The results of my PETCYCLE-program above are 3847 / 12793 adding up to a nice 16640 cycles in that mode.

Here's two pictures of the HI-RES program running on it. Actually it seems the .png in the VICE-repo is wrong since it seems to go down one line after the 4th char. Would still like results from PETCYCLE from an original non-CRTC PET.

 

[Eudimorphodon]

I don't own a real PET (just a MiniPET by TFW8B) so I could only try this in emulation

In theory at least the method the MiniPET uses to generate video (IE, faking all the timing goo with an MCU) might make it possible to do a cycle-accurate, or close to it, emulation of the Dynamic Board PET. It would for the most part be a functionality regression because it’d likely introduce some serious monitor compatibility issues, the PET’s timing is “NTSC-ish” but pretty far off standard... but I imagine most older CRTs would tolerate it. (Digital TVs and adapters, not so much.)

That the fake-CRTC code isn’t “open” would be a little bit of a stumbling block for trying to do it yourself, but the hardware is simple enough you could probably reverse engineer it.

 

[rhialto]

It actually talks about a tenth column and how the code is not fast enough. Are we sure what is in the VICE-repository is actually the code as published back in March, 1980?

I'm pretty sure, I copied it from a cursor disk image myself...

In the meantime I also found out that the MiniPET can be switched to a 9" PET-video output mode and in that mode both the HI-RES program as well as the demo "A Bright Shining Star" actually work on it. The results of my PETCYCLE-program above are 3847 / 12793 adding up to a nice 16640 cycles in that mode.

Nice!

Actually it seems the .png in the VICE-repo is wrong since it seems to go down one line after the 4th char.

Yes, it's from before my current improvements. Once I'm happy with them, I should replace it.