#composite video

[commodorez]

Bodges have been added to fix some bugs, which now means that the primary functions all seem to be working.

Check out that 6810 SRAM chip from 1975 now given purpose, probably for the first time since it was manufactured. All 128 bytes of RAM used for custom character graphics. You can see those on the second row.

The waveform looks way better than I had hoped, though it isn't perfect. Still, I'm very proud of how this turned out.

[ebajous-curves]

Shrek on russian TV

[hexmoire]

[commodorez]

We've had a breakthrough!

A big update on the Cactus Video Card Mk II Rev A:

It's not perfect, but after replacing he 74164 with a ring counter made of 7474's on a little riser board, I got the video signal to lock correctly to the screen. Hell yeah!

Look at that pretty waveform (the lower blue trace)! Every one of those yellow spikes is when the waveform shifts to another phase. The Cyan spike indicates that it's finished an entire line of video.

Here's the vertical blanking interval:

Nice. A few more video tests...

Fuck yeah. More debugging to commence!

[commodorez]

Playing around with the Cactus video card. I am easily amused.

[commodorez]

Rendered this one in BASIC.

This isn't the most clean way of doing it, but it works.

10 A=45056 20 FOR B=A TO A+1024:POKEB,32:NEXT 50 READ J,K,C 55 PRINT J;"x";K;": ";C 60 IF J+K+C=0 THEN END 70 POKE J+(K*32)+A,C 80 GOTO 50 900 DATA13,5,221,14,5,132,15,5,132,16,5,222 910 DATA 13,6,140,16,6,140 920 DATA 13,7,140,16,7,140 930 DATA 13,8,140,16,8,140 940 DATA 13,9,140,16,9,140 950 DATA 13,10,140,16,10,140,17,10,221,18,10,132,19,10,222 960 DATA 13,11,140,16,11,140,17,11,140,19,11,140 970 DATA 13,12,140,16,12,140,17,12,140,19,12,140 980 DATA 13,13,140,16,13,220,17,13,223,19,13,140 990 DATA12,12,222,11,12,132,10,12,221 1000 DATA12,13,140,10,13,140 1010 DATA10,14,140,12,14,140,13,14,140,19,14,140 1020 DATA10,15,140,12,15,220,13,15,223,16,15,221,17,15,131 1030 DATA18,15,131,19,15,223 1040 DATA10,16,140,16,16,139 1050 DATA10,17,220,11,17,131,12,17,131,13,17,222,16,17,139 1060 DATA13,18,140,16,18,139 1070 DATA13,19,140,16,19,139 1080 DATA13,20,140,16,20,139 1090 DATA 12,23,67,13,23,65,14,23,67,15,23,84,16,23,85 1100 DATA17,23,83 1999 DATA 0,0,0

[commodorez]

Okay, so I think I finally figured out why the OSI screen flickers so much when I'm reading from the keyboard.

Everything on the OSI-440 video board is memory decoded here. We have a 4K window, divided up into 3 sections:

1K for alphanumeric RAM (/CE0)

2K for graphics RAM (/CE1 and /CE2)

1K for the keyboard input (/CED)

However, any time we select ANY of these, we trigger /BE or Board Enable line, which means that we are selecting the video board as a whole.

When this happens, /BE switches the 74157 multiplexers from connecting the different banks of RAM from being accessed by the video hardware, to being accessed by the CPU.

So any time we select the keyboard in bank /CED, it still triggers /BE, which means that the video hardware is isolated from the alphanumeric RAM, and we get snow on screen.

Naturally upon seeing this, I got worried that my second generation Cactus video card was subject to the same flaw, but no. Apparently I thought ahead! The different memory banks of the Mk II all have isolated chip select logic to avoid this exact problem, and /BoardEnable is only used to activate that chip select logic.

Also, I find my method of handling address decode logic to be way more readable than OSI's, but I also have the benefit of a few newer and easier to obtain chips. The 74139's are one of those suggestions I picked up from @techav. So that's cool.

Anyway, designing video cards from scratch is hard, so I don't blame the OSI engineers for making the choices they did 50 years ago.

[commodorez]

Even if the Mk II has more flaws and complexity than the Mk I, it's surpassing so many of my expectations.