Edge Of Disgrace demo / problem with border tricks

[desaster]

Demo:

https://csdb.dk/release/?id=72550

Running through this demo it seems to have a lot of cool tricks with the borders. Unfortunately maybe half the time the fpga implementation seems to have issues with the tricks.

I've tested at least with the latest experimental firmwares, C64mod_2_1_alpha2.pof and C64mod_2_1_alpha3.pof.

Apologies for the very hastily taken photos. It's a bit tricky taking shots of before/after, since the scenes transition fairly quickly.

It would probably be useful to find some more constrained example of this issue, but so far I haven't spotted any other instances.

[c0pperdragon]

I guess, when this demo can play correctly, the FPGA implemention could be considered done. Unluckily, I currently have not the proper hardware to run it. All those really demanding demos are using fastloaders which do not work with my simple IEC2SD drive. Do you have recommendations what to use instead? Would the Ultimate II+ solve this issue? Is the freezer facility capable of re-playing parts of the demos?

[desaster]

the UII+ is nice, but expensive. What it basically offers for this use case is:

• good 1541 emulation
• emulates a number of freezer & fastloader cartridges (such as retro replay)

And these freezer cartridges traditionally have some cheat functionality that lets you modify memory values. I haven't used those features much myself.

So alternatively to having UII+ to emulate these, you could just as well have a real disk drive and a freezer cartridge.

This is the default emulated cartridge in UII+: http://wiki.icomp.de/wiki/Retro_Replay

And I believe the functionality of these cartridges could also be evaluated in VICE.

[c0pperdragon]

I don't want to use a real disk drive, as maintaining this can become a whole nightmare of its own. I just ordered a UII+ . It is quite expensive, but if the freezer / replay option indeed works, this will be invaluable for fixing more VIC compatibility issues.

[desaster]

I went hunting for other simpler demos that might utilize some border wizardy, and found this one so far:

https://csdb.dk/release/?id=84587

This demo is a simple prg file that shows an image, and with the FPGA implementation part of the image seems to be missing at the left.

BTW with these border demos, sometimes it's noticable that with the fpga implementation the image is shifted down a few lines, so some image data is hidden beyond the crt bezels. EDIT: but I don't know if it's just my crt handling different inputs in a different way

[desaster]

Another:

https://csdb.dk/release/?id=40743

In this one, again the left border has some issues (missing scrolling text)

[desaster]

Is the freezer facility capable of re-playing parts of the demos?

I've now experimented with the "backup" features of a couple emulated freeze cartridges. Some notes:

• These cartridges were made for real hardware, so the save state is saved to disk or tape, and not flash or ram - so restoring state is not really quick
• I was able to save state of super mario - so in theory this works
• I was not able to save the state of EdgeOfDisgrace

[c0pperdragon]

The problem with the sprites in the left border is that I still do not know the exact point where the sprite coordinate system skips the 8 counts on the PAL system. As there is a 9-bit counter for the sprite positioning and 504 overall pixels per line, there must be an 8-pixel gap in numbering somewhere. Using the Brutality demo, I could limit the possibilities a bit, but I have not yet tracked it down completely. I guess this information is obvious to any hard-core demo coder who uses the border him/herself, but I could find nothing in the web.

About the different vertical alignment: The FPGA mod produces the horizontal and vertical syncs a bit differently than the original C64. I tried to get the standard start screen rectangle exactly centered on my TV. This should work for most TV sets out there, I guess.

[olliraa]

Would this tool help? https://csdb.dk/release/?id=170893

[c0pperdragon]

I have uploaded firmware 2.1 in the releases section. This fixes at least the "No borders" demo. The side-borders demo seams to be a tape file which I can not use with my setup. But may possibly work as well now. The Edge of Disgrace demo is probably still too much for the mod. I will have same better look at it when I receive the Ultimate II+ .

[olliraa]

I think this could help with the tape problem: http://wav-prg.sourceforge.net

[desaster]

This looks like an useful test program: https://csdb.dk/release/?id=137452

I notice some glitched lines during the test

[c0pperdragon]

I finally worked out the sprite coordinate sequence for PAL machines: It the most obvious choice: The counter just runs from 0 to 503 and then jumps back to 0 again. So all sprites that are placed on the locations 504 - 511 are never triggered. So now the two demos above show the left borders correctly.

For the NTSC matchines I can not guess. There must happen some repetition of numbers somewhere in the horizontal blanking or behind the border. But it is not a simple reset to 0, but some other arbitrary point.

[c0pperdragon]

I spent quite some to to make the emulation more accurate. While it can still not handle everything that is used in the "Edge of Disgrace" demo, most other things now work quite fine. You can get the firmware 2.2 in the releases section.

[bwack]

I don't know if it helps, but the Horizontal counter (X coord) in PAL is 0 - 1f4, and NTSC 0 - 1ff. First pixel (beginning of border) is at 1e0, and last is at 178 in PAL. I have mostly looked at memory access timing in the dieshots so far. http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt

[c0pperdragon]

Yes, I already know this amazing document of reverse-engineering. Unluckily it seems to be plain wrong in some respects and leaves out quite some details on others. So I had to do extensive experiments of my own. Specifically the horizontal sprite position counter on NTSC must have some repeating number range, as there are 520 pixels on the NTSC screen but only 9 bits in the counter. Still I don't know where this happens in the blanking region. Maybe I can invent some experiment that uses sprite collisions in the invisible screen part to finally get this right.

[bwack]

Ok. When you say: "As there is a 9-bit counter for the sprite positioning". Not sure if there is one. There are 8 x 24bit sprite shift registers that are loaded with sprite data after previous scanline and before next scanline. Each sprite register has a 9 bit comparator comparing the register with the X and Y counter (I'll double check this soon). The output runs down to the sprite shift registers. Where I currently just assume they start pumping data when the comparators match. Not sure yet if the pixel information go directly to the priority encoder or via something that may delay them. I'll have a look at the X position counter when I get the time. I'll look to see if there is a counter. You can see here the overview of the die. See G and I http://www.mayhem64.co.uk/c64design2.jpg

[c0pperdragon]

That is very good to know that the VIC actually uses an internal ROM to drive all the other components. So I guess this ROM is addressed using the X counter. This is straight-forward on PAL and on the very first NTSC chips which have 504 and 512 total horizontal pixels. But what is going on in the later NTSC chips? There the X-counter must somehow cover a range of 520 horizontal pixels. This can not be done with 9 bits. So there must be at least a 10th bit somewhere. So what I wounder is how this internal 10bit counter is translated to the 9 trigger lines for the sprite comparators. Just ignore the 10th bit? But this does not seem to be the case, as I could very well position a sprite at location 511 which then shows directy next to a sprite at location 0.

[bwack]

The X and Y counters are 9-bit. The X counter runs at 8 MHz, and in the X ROM, the two least significant bits are not used (mostly). Maybe this is why?

This is from the 8565R2 chip: Y counter, rom and registers

X counter, rom and registers

Highres files if you want to have a look at details https://gofile.io/?c=tdlpOP

[c0pperdragon]

I guess I already figured out how the PAL X-counter works, but the X-counter for the NTSC variants (6567, 8562 but not 6567R56A) is still a mystery. 9 bits just can not cover the 520 horizontal pixels these chips show per line. A die-shot will also not help, because I just can not figure out, what is going on here. Has anybody built a circuit diagram yet showing everything in terms of gates and flip-flops? This would be handy to actually understand the finer details for the timing and such.

[bwack]

There is no circuit diagram that I know of. There are some dieshots of the 6567, but they are not with the same quality as for the 8565R2 that I have been looking at. For example they don't show very well what is beneath the metal like this does.

[bwack]

Ops spoke too soon. I have never seen a NTSC VIC-II dieshot.

[c0pperdragon]

I have spent quite a lot of time again on improving the firmware, and the newest release (https://github.com/c0pperdragon/C64-Video-Enhancement/releases) now seems to cover all that is necessary.

I know that there are some slight incompatibilities that can be demonstrated with specific test programs, but that are more or less really just bugs in the VIC that nobody can use for any meaningful purpose anyway.

[desaster]

awesome work!

[olliraa]

This is truly a great accomplishment. Is there a way to donate? 😎

[c0pperdragon]

I have added a donation note at the end of the project main page.

[c0pperdragon]

I am closing this issue as the Edge of Disgrace demo has no more problems. Please feel free to create other issue threads as needed.

[bwack]

Hi. I think you may find this IEEE article interesting. Also regarding the difference in the NTSC chips. :)

https://spectrum.ieee.org/ns/pdfs/commodore64_mar1985.pdf

[olliraa]

If you want the complete article (11 pages), please let me know :)

[c0pperdragon]

That would be interesting to get more in-depth knowledge of the VIC.

I any case, I don't think, I will support these first versions of the VIC by the mod. It is seemingly impossible today to get one of these chips and even then I would not recommend to mod such an early C64 - it would be much better to keep it in its original condition.

[bwack]

@olliraa Hi. I would very much want it if you still got it :) I just realized you might have missed the link under the image. :)

[olliraa]

@bwack please send me your email address to olli.raatikainen@gmail.com :)