Clock Signal: a Vic-20 emulator for macOS and Linux

[Mike]

The first screenshot is NTSC, the second is PAL; I'm taking it as implicit that you don't see any problems with the PAL?

No apparent issues anyhow. The position of the split at the very far left of the display area doesn't show with your display window. On real h/w, one sees a single pixel of the 'old' raster colour due to the one-pixel-late behaviour.

by what mechanism are you detecting NTSC versus PAL?

I check the first byte of the VIC init table in the KERNAL ROM. $EDE4 contains 5 for NTSC, and 12 for PAL. From the result, either "NTSC ENGINE" or "PAL ENGINE" is loaded.

Your emulation gets that right (i.e, chooses the right ROM for the TV system). Otherwise the raster routines would totally fuck up with a wrongly assumed number of cycles per line.


The same routines are used with my grey-scale displayer:

https://dateipfa.de/.Public/denial/mini ... raster.zip

Actually, the routine in COLOUR TEST just uses far simpler tables to drive the rasters.

In MG Raster, green/purple and light green/light purple are mixed (per raster, and alternating on even and odd frames) to get a dark and light grey and *also* the border/background border is split at the left and right edge of the display area. If your timing is one cycle wrong, it will show immediately.

[Tom]

Well, I found a first bug but it turns out to have been tangential: failure to wrap the raster count properly in NTSC mode. So it would allege itself to be on line 261 for the final half of the final line, before admitting it's on line 0 for the first half of the first line.

That being fixed, my reporting pattern in non-interlaced mode is: 0 for the first 33 cycles of the first line; 1—260 for 65 cycles each; 0 again for the final 32 cycles of that frame. So if you had a value of 33 stored to that portion of register 0 then pixel output would begin on relevant lines exactly when the raster count increments.

I'm reluctant to draw any conclusions from the frame as a whole because I don't think I've seen any information on where horizontal sync is actually meant to sit. So I've just thrown it in for three cycles from the 58th cycle of each line, with the back porch then occurring up to 65.

Had you been polling for line zero, this might therefore already have been fixed. That would have been nice.

You're not, so my code is still incorrect. For the record, the 6502 and VIAs are believed good through testing on other machines. So this is in all probability a 6560 issue.

(EDIT: and, sorry, I know keep ignoring the single-pixel delay in colour changes; I'm just opting to focus on my greater error first)

[Tom]

Okay, I tried the most obvious fix: just repositioning when I increment the raster counter so as to match a corresponding test. That corrected the test, corrected Capture the Flag, and seemed to correct the NTSC colour demo but very obviously broke Atlantis. It started doing all of its colour changes in the centre of the display.

So my immediate threads for further investigation:

• do I have the correct fixed point? I'm treating horizontal sync as a fixed event and left border and screen width simply place the pixel area within the line — after sync count up until you hit the left border area, start output, count columns until you hit the column count, stop output. It start of pixels were the fixed point then which column the raster increments on would be a function of your left border size. But I don't see how the idea of dictating a left border size could really make sense that way around;
• is the copy of Atlantis that I think is for NTSC really for NTSC? It's an oddly-placed display area if not, but I've seen lazier PAL adaptations.

EDIT: it's not worth the thread bump but: proper raster count change timing is now in effect. Colour-selection delays will be added, then I'll provide a new release.

[Tom]

A new release has been uploaded that corrects the timing of the raster count increment, under both NTSC and PAL. It's in the usual place.

I've declined yet to correct the failure to delay palette changes because I'd like to adjust the whole VIC 6560 loop, but would prefer to be more certain in a whole bunch of details before doing so: primarily just to know exactly when the number of rows and columns is latched for a frame, or whether they're latched at all rather than just potentially causing a faulty single frame when changed. So research to do.

In the meantime, enjoy!

It's been several pages, so to explain the most interesting components of the emulator again:

• video is composed as a real composite signal, that the GPU really decodes. All artefacts are the real composite artefacts. NTSC interlacing works. There's S-Video emulation if composite is a bit too much for you;
• video follows a very approximate camera-at-a-CRT model, with a very approximate version of phosphor persistence of vision. Which means that the output frame rate is a smooth function of your computer, not the Vic. 50Hz motion doesn't stutter;
• audio is built at the actual VIC sampling rate, then lowpass filtered to the Vic's cutoff of 1.6Khz;
• something of the same ilk as PRG Starter is built right in. Just File -> Open... a tape, disk or PRG and the emulator will attempt to pick the proper memory configuration and automatically launch the file;
• in its Mac form, it's a fully native Cocoa document-bhased application. Open as many simultaneous machines as you want, scale them however you want, put them onto separate screens or tabs, or anything else macOS normally does;
• in its Linuxy kiosk form, it's an SDL application that launches directly from the command-line. I'm sure a Qt or KDE UI is in the future, but it's not ready yet; and
• supposing you wanted to try some software for any of the other machines it implements, it has the platform-appropriate approximations of PRG Starter for all of those too. Try some titles for platforms you may not already know, without having to learn anything first!

Open source, naturally — MIT licence.

But all subject to implementation fallibility and/or my ignorance as to the proper behaviours, of course.

[Tom]

... and here it is in video.