6560 FPGA Progress.

[groepaz]

I believe the $9000 and $9001 set to zero-effects are not emulated as well.

so where is the bug report with testcases?

[beamrider]

I believe the $9000 and $9001 set to zero-effects are not emulated as well.

so where is the bug report with testcases?

didn't you add it here?

https://sourceforge.net/p/vice-emu/code ... _9000test/

[tokra]

I believe the $9000 and $9001 set to zero-effects are not emulated as well.

so where is the bug report with testcases?

didn't you add it here?

https://sourceforge.net/p/vice-emu/code ... _9000test/

That's not the one, this is the one talked about in the other thread (Raster split and $9002).

For the $9001 set to zero-effect see here:

https://sourceforge.net/p/vice-emu/code ... vic_vert0/

I think there is not testcase for $9000 set to zero. However I feel this effect is connected to the thread above as well.

[JonBrawn]

I wouldn't get too hung up trying to replicate this behaviour

The thing is, if I don't replicate the behavior then I haven't understood the device, and that is what this is about - I'm not creating an FPGA for fame and fortune, I'm creating it so I really grok what's going on inside - I think I've mentioned elsewhere the phrase "experimental archaeology", and that is definitely where I'm coming from.

For example, I've run CHARFLOW-TOKRA on my 6560 and my FPGA, and I've observed the behavior and my FPGA does something completely different, but I can see why the 6560 is doing what it's doing, and I'm going to make sure the FPGA does the same thing in the same circumstances. See a later post about Tokra & Mike's hi-res graphics - there are some fantastic pictures coming!

[JonBrawn]

I assume the details of the 6560 is very similar, if not identical to the details of the 6561.

Some things will be similar, some things will be different, and based on the 6560, some things will just be plain wild'n'whacky (Exhibit A: 'raster' incrementing half way along a display line)

[JonBrawn]

Who wants to see a picture of a picture of a tiger?! Everybody LOVES pictures of cats on the Internet, so a picture of a BIG cat must be so much more popular!

Here is a TIGER:



And here is the sad and sorry mess when it's rendered by my FPGA:



In a similar vein, here is a face of a woman (or a bloke in spectacular drag makeup):



And here she is, standing behind some blinds introduced into the picture by the FPGA:



Mike, Torsten, are you willing to give me some guidance as to how you are generating the images and so how I might be getting it wrong?

Things I can guess are that I've got raster 0 in the wrong place (hence the blinds in the black and white image), and that you're changing something like the screen base or character generator base mid-character, and my timing is wrong.

Looking at the black-and-white image, there are something like 23 "bad lines" on the screen, so that's one per character row, and each "bad line" appears to be two interlaced rasters high. I'm guessing you're flipping screen base or chargen base at the end of each row of characters, based on raster 0 + 8 x R, and so if I've got zero in the wrong place by one line, the wrong data will be displayed at the end (or beginning) of each row. As the bad line is two rasters high, raster 0 is only off by one. Or the position I'm starting the top raster of the display is off by one. More blue tape on the TV screen is needed to check where things line up, and a couple of experimental changes to the alignment of raster 0 and/or the top line of the display area.

[Mike]

Jon,

one thing beforehand: I replaced your attached photos with new versions that only take 1/1000th of storage footprint. Using up ~60 MB for each of the original photos is completely over the top given what they are just supposed to convey! Please use IrfanView or a similar tool to bring images and photographs into a more palatable size before uploading them here.

Mike, Torsten, are you willing to give me some guidance as to how you are generating the images and so how I might be getting it wrong?

Things I can guess are that I've got raster 0 in the wrong place (hence the blinds in the black and white image), and that you're changing something like the screen base or character generator base mid-character, and my timing is wrong.

In general, all those screenmodes dynamically update character generator data and colour RAM data as the beam races the screen, ensuring that the necessary data is right 'there' in internal RAM when the VIC chip wants to fetch it. Sometimes the correct data arrives in RAM in the cycle before VIC does the fetch, so indeed these modes are all time critical.

tokra and I are doing it this way, because that is the only measure to extend usable screen sizes for a screen bitmap beyond what would only be possible with the internal RAM alone, which then is on the order of 32768 pixels. MINIGRAFIK for example does 160x192 = 30720 pixels but also aims to be OS compliant - therefore it only uses the upper 4K internal RAM for display and no interrupts. The new modes shuffle bitmap data from external RAM into the internal RAM with high-speed transfer code (unrolled loops, etc.). Likewise the colour RAM data is dynamically updated so VIC-I can fetch new attribute data (i.e. foreground colour and multicolour enable state) for each raster. In effect, this gives attribute cells which are not anymore 8x8 (single height characters) or 8x16 (double height characters), but 8x1 pixels!

As you've guessed right, these methods also employ changes of character generator base, and sometimes also of the screen base address.

Looking at the black-and-white image, there are something like 23 "bad lines" on the screen, so that's one per character row, and each "bad line" appears to be two interlaced rasters high. I'm guessing you're flipping screen base or chargen base at the end of each row of characters, based on raster 0 + 8 x R, and so if I've got zero in the wrong place by one line, the wrong data will be displayed at the end (or beginning) of each row. As the bad line is two rasters high, raster 0 is only off by one. Or the position I'm starting the top raster of the display is off by one. More blue tape on the TV screen is needed to check where things line up, and a couple of experimental changes to the alignment of raster 0 and/or the top line of the display area.

You should check whether the change from non-interlaced to interlaced mode is done right. In that time, tokra and I used a method to sense the type of field (top or bottom), which ultimately was proven wrong. It actually "works", but because of wrong reasons. Even on original hardware, the blinds in the B/W picture can be made to appear with a 50% chance by activating interlace mode already before activating the new screen mode - i.e. the original method to sense the type of field assumes it starts from non-interlaced mode.

Some time ago I had prepared tests that check the behaviour of the transitions between non-interlaced and interlaced mode, but I hadn't published the results thus far. I know you already asked about that. I'll prepare a follow-up post, stay tuned ...

Greetings,

Michael


P.S.

[...] here is a face of a woman [...]

That's Avril Lavigne.

You should set the picture aspect ratio to 4:3 instead of 16:9.

[tlr]

In general, all those screenmodes dynamically update character generator data and colour RAM data as the beam races the screen, ensuring that the necessary data is right 'there' in internal RAM when the VIC chip wants to fetch it. Sometimes the correct data arrives in RAM in the cycle before VIC does the fetch, so indeed these modes are all time critical.

The timing_ntsc.prg program referred in this post should give a measure of the graphics fetch latency which is crucial for this to work. It does not measure color ram fetch latency though.

[Mike]

Some time ago I had prepared tests that check the behaviour of the transitions between non-interlaced and interlaced mode, but I hadn't published the results thus far. I know you already asked about that. I'll prepare a follow-up post, stay tuned ...

Here we go (download).

Generally, the tests check the behaviour of $9004/$9003 upon changes to the interlace enable bit in $9000 in raster line 261. It appears there's a single cycle during which the state of $9000 bit 7 is latched, which happens to be between cycles 31 and 32 (counted from 0 as per appearance of that raster number in $9004/$9003 combined). With synchronisation to the start of a raster line, 8 cycles around that 'critical area' are probed - which incidentally is also the period of the LDA $900x:STA $xxxx transfer loops that immediately follow behind to record the values of $9003 and $9004 for 256 cycles.

Here's my interpretation of the screen shots (see ~/results in the *.zip file):

• "4N?XX" and "3N?XX", no-lace to ? (unknown before tests!): If interlace-enable (bit 7 of $9000) is changed from 0 to 1 up to cycle #31 of raster 261 (as of $9004/$9003 combined, and cycle #.. counted from 0):
  
  • raster 261 is extended from 33 to full 65 cycles,
  • raster 262 appears with full 65 cycles,
  • raster 0 appears with full 65 cycles, and
  • raster 1 appears with full 65 cycles ...
  Note raster 262 satisfies the "field type test" in "test8a.prg" with C=1, i.e. a non-interlaced field, upon successful transition to laced, is made to appear as "top"-field at the end and thus is followed by the "bottom"-field.
  
  If interlace-enable is changed from 0 to 1 in cycle #32 or later of raster 261:
  
  • raster 261 terminates with 33 cycles in total,
  • raster 0 appears with 32 cycles,
  • raster 1 appears with 65 cycles,
  • raster 2 appears with 65 cycles,
  i.e. the next field still displays as standard non-interlaced, and the transition to interlaced is deferred to the next VSync.

• "4TNXX" and "3TNXX", top to no-lace: If interlace-enable (bit 7 of $9000) is changed from 1 to 0 up to cycle #31 of raster 261 (as of $9004/$9003 combined, and cycle #.. counted from 0):
  
  • raster 261 terminates with 33 cycles in total,
  • raster 0 immediately appears with 32 cycles,
  • raster 1 appears with 65 cycles,
  • raster 2 appears with 65 cycles, ...
  i.e., effectively an immediate transition to no-lace happens.
  
  If interlace-enable is changed from 1 to 0 in cycle #32 or later of raster 261:
  
  • raster 261 retains 65 cycles length,
  • raster 262 does not(!) appear,
  • raster 0 appears with 65 cycles,
  • raster 1 appears with 65 cycles, ...
  i.e. the "top"-field is shortened by one line, then followed by another "bottom"-field, which then finally transitions into non-interlaced.

• "4BNXX" and "3BNXX", bottom to no-lace: If interlace-enable (bit 7 of $9000) is changed from 1 to 0 up to cycle #31 of raster 261 (as of $9004/$9003 combined, and cycle #.. counted from 0):
  
  • raster 261 terminates with 33 cycles in total,
  • raster 0 immediately appears with 32 cycles,
  • raster 1 appears with 65 cycles,
  • raster 2 appears with 65 cycles, ...
  i.e., effectively an immediate transition to no-lace happens (as with top->...)
  
  If interlace-enable is changed from 1 to 0 in cycle #32 or later of raster 261:
  
  • raster 261 retains 65 cycles length,
  • raster 262 does not(!) appear,
  • raster 0 appears with 65 cycles,
  • raster 1 appears with 65 cycles, ...
  i.e. the "bottom"-field is shortened by one half line, followed by yet another "bottom"-field, which then finally transitions into non-interlaced.

Changes of interlace-enable from 1 to 0 in raster 262 have not been tested as described here, but as already noted elsewhere, seem to muck up the raster-counter, big time.

Greetings,

Michael

[tlr]

In general, all those screenmodes dynamically update character generator data and colour RAM data as the beam races the screen, ensuring that the necessary data is right 'there' in internal RAM when the VIC chip wants to fetch it. Sometimes the correct data arrives in RAM in the cycle before VIC does the fetch, so indeed these modes are all time critical.

The timing_ntsc.prg program referred in this post should give a measure of the graphics fetch latency which is crucial for this to work. It does not measure color ram fetch latency though.

And when you get to PAL you have the option to test something like this which relies heavily on the exact fetch latency or else the graphics will be misaligned: Impossiblator 3

[Mike]

It does not measure color ram fetch latency though.

The colour RAM shares its address pins with the lower 10 bits of the VA address bus. The colour RAM data thus is fetched exactly in the same cycle as the screen codes, in parallel. VIC-I reads the screen codes over BD0..BD7 (pins 16..9) and the colour RAM data over VD8..VD11 (pins 8..5).

Unlike the VIC-II, neither screen codes nor colour information are cached, and VIC-I re-reads them on every raster line. FLI on the VIC-20 is thus possible without the need to "force" a bad-line condition, as effectively every line already is a bad-line. OTOH, as there's enough memory bandwidth available, that bad-line does not need to stop the CPU.

And when you get to PAL you have the option to test something like this which relies heavily on the exact fetch latency or else the graphics will be misaligned:

Note the modes tokra and I designed do not rely on accesses to open memory! All data is fetched by VIC-I from regular internal RAM. The transfer routines ensure the data is there when VIC-I wants to fetch it, sometimes with just a single cycle leeway left. Should a VIC-I replacement want to fetch data from a critical address too early, the display will not just be misaligned, but wrong.

[tlr]

It does not measure color ram fetch latency though.

The colour RAM shares its address pins with the lower 10 bits of the VA address bus. The colour RAM data thus is fetched exactly in the same cycle as the screen codes, in parallel. VIC-I reads the screen codes over BD0..BD7 (pins 16..9) and the colour RAM data over VD8..VD11 (pins 8..5).

Yes, my assumption is that the latency is the same but I never measure it directly with that program.

[JonBrawn]

I have fixed Avril's horizontal stripes - when deciding where the top of the text display area should start, you take 2 * $9001 +/- fudge, where fudge can be -1, 0, or 1, and it's essentially a case of "install VIC chip, start the computer, put masking tape on the TV at the transition from cyan border to a white screen, shutdown, install FPGA, see how close you are to the masking tape position, adjust the source code, rebuild, try again. As it's a squint at the screen and judge decision, I was off by one.

[JonBrawn]

one thing beforehand: I replaced your attached photos with new versions that only take 1/1000th of storage footprint. Using up ~60 MB for each of the original photos is completely over the top given what they are just supposed to convey! Please use IrfanView or a similar tool to bring images and photographs into a more palatable size before uploading them here.

OK, I fully intended to do that, but it was late at night and I forgot Sorry about that, and thanks for fixing it.

[JonBrawn]

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.