6560 FPGA Progress.

[tlr]

It looks like the FPGA is occasionally reading "bum data," as we industry professionals call it, from memory and getting $FF instead of the correct value. My current thinking is that the pull-up resistors and relatively high capacitance of the cheapo FETs I'm using as level shifters make the data bus voltage marginal in some situations, which is born out when you use either the logic analyzer (there's a lag between when a signal ought to be changing and when it is observed to change, both low-to-high and high-to-low) and with the 'scope where there is a bad slew rate. As it was working the vast majority of the time, I had assumed that it was "just good enough" and was putting off getting some better components and spinning a new board.

Be adviced that something like Impossiblator 3 relies on that when pointed to unconnected adress space the VIC-I will fetch whatever was on the bus the previous cycle. If you have permanent pull-ups that may affect this behaviour negatively.
For maximum compatibility you'll probably need proper tri-stating of the data bus.

[Mike]

For maximum compatibility you'll probably need proper tri-stating of the data bus.

Indeed, page 12 of the data sheet tells fairly TTL compatible sink/source-capability of the address and data bus pins (when they're outputs) with:

• I_OL(V_OL = 0.4 V) >= 2.4 mA,
• I_OH(V_OH = 2.4 V) >= 200 µA,

*and*

• an impedance Z of >= 1 MegOhm, when tri-stated (i.e. they're inputs).

[JonBrawn]

Be adviced that something like Impossiblator 3 relies on that when pointed to unconnected adress space the VIC-I will fetch whatever was on the bus the previous cycle. If you have permanent pull-ups that may affect this behaviour negatively.
For maximum compatibility you'll probably need proper tri-stating of the data bus.

OK, so... I'll solder a 100uF capacitor onto each of the data lines!

I've got some proper bus transceivers sitting in some "static bags" on my desk, and when I spin the new board, we'll see if they give the desired behavior.

[tlr]

OK, so... I'll solder a 100uF capacitor onto each of the data lines!

Are you sure?

[JonBrawn]

Why Orange?

I've just noticed this evening that in all the pictures, the corruption in the image is almost always a full character-width row of orange pixels.

Why Orange? Tokra / Mike, is a character row of "orange" always the same bit pattern in the tiger picture and the others of that set, such as $FF, $AA, $55, $00?

[The images in question are those in the flinale-nts2.d64 image].

Jon.

[Mike]

Why Orange?

That's likely because the image contains quite some orange colour to begin with, and the image converter correspondingly puts orange as background (or auxiliary) colour, which is then "masked off" at those places where it isn't supposed to show.

Now, if the FPGA doesn't get the colour RAM data fetch quite right, that "masking" *) wouldn't work as intended, and orange over black is a rather good signal colour, i.e. easily recognizable. This should be especially apparent where orange is set as background colour and, for whatever reason, the FPGA processes the 8x1 tile as hires where it should have been rendered as multicolour. There, a more or less solid 8x1 block in orange is then likely to "shine through". But this isn't the only type of fault in the display, only maybe the one easiest to see.

It might be helpful for debugging, if

?

could prepare debug versions of the tiger picture - the original one, and four others that only contain $00, $55, $AA, $FF in the bitmap. The $00, $55 and $FF pictures should show the distribution of background, border and auxiliary colours is right, the $AA picture should show whether the colour RAM data fetch works as supposed. Finally, a version of the picture with background, border, auxiliary colours set to 0, and colour RAM data set to 1 (white hires) should show whether the bitmap fetch is correct.

Even if these all show fine on their own, they then need to be perfectly vertically aligned. Otherwise, a mis-alignment of colour RAM data easily leads to the consequences I laid out above.


*) The image converter choses the combination of background, border and auxiliary colour for each raster line, which results in the smallest quantization error for that line. In doing so, it is free to assign any combination of foreground colour and multicolour enable to each of the 88/8 = 11 colour RAM attributes present in that raster line. If the converter takes orange as background, because it is an important colour, but most of the raster is black, it then likely sets the foreground colour to black to do that masking. That's how its working could be interpreted. The algorithm actually has no idea that method could be interpreted as such, though. It's a side effect of how it aims to minimize the quantization error.

[tokra]

It might be helpful for debugging, if

?

could prepare debug versions of the tiger picture - the original one, and four others that only contain $00, $55, $AA, $FF in the bitmap. The $00, $55 and $FF pictures should show the distribution of background, border and auxiliary colours is right, the $AA picture should show whether the colour RAM data fetch works as supposed. Finally, a version of the picture with background, border, auxiliary colours set to 0, and colour RAM data set to 1 (white hires) should show whether the bitmap fetch is correct.

Here we go:

tiger.zip

(23.55 KiB) Downloaded 51 times

[Mike]

Here we go: [...]

Merci!

[JonBrawn]

Well, that was extraordinarily useful. From looking at those, my initial reaction was something like, "My gosh! I've got the multi-color 10 and 01 colors transposed!" however, that wasn't the case. What was happening is that in a couple of places, I was using the four-bit code read from the color RAM as a color, so when in multi-color graphics mode, the "character color" displayed was the "light" version of the intended color, except black, which was replaced by orange, hence the excessive amount of orange in the pictures.

In the past week or so, I've fixed three timing errors in the bus interface (one setup violation and two hold violations), this color issue, and fixed the code with the comment "// This is a bodge. REVISIT".

And still, there are a handful of blue pixels in that tiger picture that shouldn't be there.

I'm currently using a real CRT television - Would any of you have suggestions for how I can photograph the upper and lower fields? I've tried every setting on my iPhone, making movies at 30fps and 60, making "slow-motion" movies at 120 and 240fps, and randomly taking shots in an attempt to get one of each field. None of these is particularly effective, all of them are time-consuming to get any kind of result, and none of them give a usably clear image.

[JonBrawn]

Left: 6560
Right: FPGA

A note about the image quality: my video capture dongle doesn't like the deformed NTSC signal from the 6560 and has a hard time getting itself synched up from one field to the next. This is the best capture image I obtained over many samples. The FPGA version tidies up the VSYNC mess and so it is easier for the capture device to lock into the signal from one field to the next. On a genuine analogue CRT-based television, the perceived image qualities are more or less identical (give or take a twiddle of the gain pot).

This is all well and good, except that the FPGA version has artefacts in the first character column (there's a blue horizontal line in the upper left quadrant, for example). I have been trying to work out where it is coming from for quite a while now. For a particular image, the artefacts are always in the same places, but those places vary from image to image. They are always in the first character column (so they are probably related to the first fetch of the line).

Tokra and Mike - it looks like some or all of the aux colour, background colour and border colour get set during the left margin of most lines before the display area starts. Are you twiddling anything else on a per-raster basis, such as the screen and colour bases, or are they set at the top of each field? Are you doing anything creative, like writing to the raster register? (I'd hope you couldn't do that, but if you can, I probably need to know.)

[tokra]

Tokra and Mike - it looks like some or all of the aux colour, background colour and border colour get set during the left margin of most lines before the display area starts. Are you twiddling anything else on a per-raster basis, such as the screen and colour bases, or are they set at the top of each field? Are you doing anything creative, like writing to the raster register? (I'd hope you couldn't do that, but if you can, I probably need to know.)

The mode is absolutely cycle-critical. Please see the raster-paper below. This was done using Fridgegrid which is perfect for solving these raster-cycle-puzzles Basically this is just for an area of 8 lines per field and repeated over the vertical height of the screen. The values for $900e and $900f must be set at the right time during the raster so that they take effect for the displayed line. This was done by trial and error (e.g. placing them so early that they work but don't screw up the line before). Then every two lines the $9002-register must be changed at the right moment to switch between the two possible colour-RAM areas and then the updates for the displayed colour of each char must be done before the raster displays that particular char. Any cycles left must then be used to update other color-bytes in advance (but not too early), so that the full routine fits in 8 lines by 65 cycles. There are some other tricks in there like:

- using illegal opcode SAX to save save 2 cycles (by setting the colour-RAM and the auxiliar colour with the same value loaded to the Accumulator)
- pre-setting the y-register to save 2 cycles on setting $9002 every other time.
- updating the lines 0 for the whole screen area during vblank

Looking at it now it amazes myself it all works It's a thing of beauty when you first try to set this up in Fridgegrid and then realize "it just might work".

You can also look at the source-code itself which is included in the original download for FLINALE.

Edit: Just discussed with Mike on the phone. We think you are fetching the char/colour-data one cycle too late and so my updates for the next line (UPD L1-0 and UPD L5-0) have already overwritten the original values in colour-RAM.

[JonBrawn]

I'm up to my armpits in sound generation at the moment, once I've captured what's in my head on that topic, I'll come back to fetching char/colour bytes one cycle too late, and see if I can fix this!

Thanks for all your help!

[JonBrawn]

At blooming last!

Spot on, you two - fetching one CPU cycle earlier fixes the artefacts1

Now all I've got left is sound and lightpen.

[tlr]

At blooming last!

Spot on, you two - fetching one CPU cycle earlier fixes the artefacts1

my_tiger.png

Now all I've got left is sound and lightpen.

Nice work!

VIC-I sound is kind of fiddly, especially the noise channel. Nippur72 did some previous FPGA work on this referenced somewhere here: thread. I seem to remember that there was still some discrepancies to be resolved but I'm not certain.

[JonBrawn]

Nice work!

Thanks - however, it's worth acknowledging that I'm standing on the shoulders of giants here, as I'm just the bloke with the keyboard that knows a bit of Verilog, there are quite a few folks on Denial that have contributed so far, and I dare say there'll be more before it's done! (There's also a bunch of guys local to me here in Austin that are helping with the hardware - the whole thing truly is a team effort).

Now I've got to go back through everything and make sure it all still works, on three different televisions I have, including an unhealthy number of cartridge games, and then I need to hunt down all the VIC NTSC demos that have been written and compare them 6560 vs FPGA. Finally, I need to decide if I'm going to reproduce that weird behaviour you get when you move the text area off the edge of the screen 'cos there's some interesting stuff that happens when you do that, which will be very hard to reproduce, but after all that loud-mouthing about "experimental archaeology" and this project, I guess I already know my answer.