Compatibility with Ultimate II+ / freeze causes video corruption

[desaster]

Hi,

The hardware

This issue is regarding compatibility with the Ultimate II+ cartridge, which has various different features such as 1541 emulation. The cartridge has a menu system, which is utilizes a freezing method where the active CPU is switched over to that on the cartridge (FPGA implementation of 6510).

I'm not very familiar with the technical details of the freeze, but there's a document by the author written in 2008, which hopefully is still valid: https://github.com/GideonZ/1541ultimate/blob/master/doc/Safely%20freezing%20the%20C64.pdf

NOTE: maybe a bit confusing, the cartridge has buttons "Freeze" and "Menu". While both technically do some type of a freeze, the actual Menu freeze is the one with the problem. The "Freeze" button can act as a freeze button for one of the integrated freeze cartridges that the UII+ can emulate.

The problem

So the issue with the freezing when using the YPbPr mod:

• When entering the ultimate II+ menu (freezing), the menu screen is corrupted
• When exiting the menu (unfreezing), the normal c64 screen is corrupted

I've attached a picture demonstrating the problem with step-by-step pictures. This demonstrates a corruption where the screen looks a certain way, but this may actually be quite random (depending on what state the VIC ends up at, I guess).

What I've tried

I haven't done any probing of the freeze event with a scope, since I wouldn't even know where to start.

The UII+ has a couple settings, "CPU addr valid after PHI2" and "PHI2 edge recovery", but they didn't seem to have any effect when I played with them

Additionally..

While this issue is about the UII+ cartridge, a question also whether or not other freeze cartridges have similar issues. I only have this one cartridge myself.

[c0pperdragon]

As it seems to me, the way the ultimate cartridge writes into the registers of the VIC uses some different timing than when done by the CPU. The current firmware implementation relies on some very specific behaviour which I have found by measurments. I already have a guess how I could fix the issue, but for this I would either need such a cartridge myself (which I do not have and I do not want to buy either), or you could voluntier to try out various experimental firmware versions on your machine. But this could be quite a lengthy process with slow iterations.

[c0pperdragon]

I have quickly read the technical documentation for the freezer implementation. It seems to me, that this should not interfere with the overal working of the C64 video mod. So probably it is indeed just a matter of fixing the register write timing issue. Could you verify if the malfunction is truly only related to VIC register writes?
This would manifest itself in wrong colors / woring horizontal/vertical screen size settings / no visible picture at all / sprite missbehaviour. But it would never lead to any other part of the system being unstable, so even if the screen is totally screwed up you can use the rest of the system just perfectly and the video on the A/V port is perfectly normal. Also the actual manifestation of the garbled screen would probably look quite differently every time. Could you provide some more screenshots of this effect?

[desaster]

As I tested some demos and stuff, I believe I've seen all of the symptoms you described there. The system is otherwise working just fine, and the A/V output looks normal.

I can try taking more photos of these. I'd be happy to help test firmware changes too.

[c0pperdragon]

I have built an experimental firmware that could potentially fix the incompatibility. This can be found in the folder: https://github.com/c0pperdragon/A-VideoBoard/tree/firmware-development/c64mod/experimental

But besides this one tweak, it also contains a huge amount of experimental changes that are far from finished. Please do not use the firmware for anything but testing this specifc behaviour.

[desaster]

After a quick test, unfortunately it seems the problem is still there. The symptoms seem identical.

[c0pperdragon]

To scan a wider range of possible timing parameters, I have created a bunch of experimental firmware versions. These basically use a different point in time where the data bus is sampled on register writes. If you would be so kind to test each in turn with the freezer menu and report the outcome. Binaries available on same location as before.

[desaster]

I tested each of the firmwares, and to my surprise all of them seem to work fine.

My testing method:

• Reset
• Freeze, observe if UII+ menu is ok
• Unfreeze, observe if normal C64 screen is ok
• Load Super Mario Bros
• Freeze/unfreeze at least once during the demo play to see if sprites are ok

These were quick tests, and I can start doing more testing by playing some demos and stuff.

Let me know if want me to test more changes (in vhdl or .pof). I was kind of expecting one of the firmwares to break :)

[c0pperdragon]

This is indeed very nice. It seems that the freezer cartridge provides stable data on the data bus for quite a long period, but just a tiny bit later than the CPU does. Therefore my previous attempt did break, which samples the data lines on "tick" 9 (in my internal sub-clocking of the CPU clock). And everything from 10 upwards seems to be good enough. One big question still remains unanswered: At which time does the real VIC sample the data? It must be earliest at tick 10 (otherwise the freezer cartridge would not work at all), but can be anywhere up to 15 or even later. My measurements with the oscilloscope show that the CPU holds the data lines stable for a very long time. So if I set my implementation to sample data on, for example, tick 12, this may still not be the right choice for some other hardware, that relies on the VIC to sample the data on , for example tick 14. Anyway, I will use tick 12 for now, as this works at least with your device.

Thank you for this investigation.

[RobeeeJay]

I just got an Ultimate II+ as well and I've been having similarly strange issues. In fact they look the same, when I switch back to S-Video I can see the correct colours and no clipping, but the Ultimate firmware is clipped and exiting it's menu often gives the same black screen.

Which firmware would you recommend? And how do I flash it? :)

[c0pperdragon]

I have not yet finished the upcoming version 2.0 of the firmware that should then solve this issue. When I can finally provide it, you still need the programmer hardware to actually flash it to the board, together with the "Quartus Prime" tool suite (free download, but huge). This hardware is a "USB Blaster", which can be found quite cheaply if it does not have to be an original Altera part. For example: https://www.alibaba.com/product-detail/Altera-USB-Blaster-Rev-c-CPLD_60363223142.html?spm=a2700.7735675.normalList.17.5m05jF

[RobeeeJay]

Thank you, I've ordered one from ebay, I'll try not to be too impatient waiting on 2.0. ;)

[c0pperdragon]

I have now built a new release of the firmware that should be compatible with the freezer cartridge, and offers the possibility to modify the color palette if you don't like my original choice. More info about palette reprogramming in the main project page.

[c0pperdragon]

I would really like to receive feedback on the reliability of this new firmware and what you think about the palette reprogramming.

[desaster]

Great work on the firmware, I will do some testing this weekend.

[RobeeeJay]

This is wonderful! And so much earlier than I expected! I'll try it this weekend too and let you know!

[RobeeeJay]

Seems to work great so far! Can see the whole screen when in the Ultimate menu, no problems switching back to the C64, games all look how they should.

I have not tried changing the palette registers, not knowing what they are currently I'd be unsure of what to change them to.

[RobeeeJay]

Interesting issue I found with the drawing-in-the-border effects of a demo: https://csdb.dk/release/?id=11650

Here is what it should look like (and does on the same machine via s-video): https://www.youtube.com/watch?v=2jYanm4u89E

Here is what it looks like through the fpga board:

[c0pperdragon]

No need to bother about the palette, if you are fine with default settings.

About the visual glitch in the border: My emulation of the sprite rendering still seems to be a bit off, especially at the edge cases. The border engine and the bitmap rendering seems to be pretty complete though. I will do more reverse-engineering of the inner working of the VIC to improve on the sprites also. So you can expect a firmware 2.1 that will handle this better.

[RobeeeJay]

The end of the same demo may also help you debug things, if you go to 25:20ish of the video where the text is scrolling, there are some strange things occurring on the fpga output vs s-video.

[c0pperdragon]

I managed to improve on this specific issue with rendering in the overscan area. The glitch on the left side was caused by an inaccuracy on exactly when the sprite position counter has its discontinuity position. And the right glitch is caused by not allowing the bitmap to render in the overscan region at all.

I think, the second problem is fixed for good, but the first problem may pop up any time with other demos that do other funky stuff in the overscan, as I am not able to pixel-exact determine the discontinuity point.

Anyway, I have prepared and experimental firmware at https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/experimental

The first scroller of this demo seems to run without problems, but then it crashes on my system because I have no proper disk drive or emulation (just a cheap SD-card drive), so the fast-loader crashes. Maybe you can try out this firmware and tell me how it is working.

[RobeeeJay]

The 2.1 Alpha firmware definitely fixed the first part of the demo (awesome work!), but the final part still has an issue which must be something else.

If you want to load that you can catalogue the directory and just load the final PRG file on it directly, you don't need to load anything before it. Do you have the SD2IEC drive?

[c0pperdragon]

I knew it would not be easy to properly emulate the VIC in all these crazy circumstances demo coders would come up with. But I could not imagine how deep this rabbit hole actually is.

The issue with the last part of this demo was caused by an inaccurate handling of the switch between idle state and display state of the VIC (this flickering line should be hidden because the program forces the VIC into idle state, but my emulation did not recognize this).

Nevertheless, I have made another experimental firmeware (same location as before) that handles this now correctly. If you happen to stumble over other demos that also cause problems of their own, please let me know. I really appreciate your help in tracking down these issues.

[RobeeeJay]

This fixes the issue, thank you again!

I appreciate you fixing them, especially as these are probably all going to be strange edge cases from now on. ;) I will start reporting them in new issues so you can close this one and not feel like you are stuck in an endless fix-a-thon.

[desaster]

Today I experienced this issue again for ~5 minutes. As the system warmed up things started working okay again.

This is just a heads up, I'll do more testing and see if it happens often with a "cold" system.

[c0pperdragon]

I did some testing and found that the sample time for register address (not the register data which ws the problem last time) is very close to the edge of the "safe zone" . So I have shifted also this timing by 30ns and hope that this issue will indeed be gone for good. If you want to give it a try: https://github.com/c0pperdragon/A-VideoBoard/tree/master/c64mod/experimental

When this works, I will make it the official release 2.6 that also already contains the 2-bank palette settings.

[desaster]

Great that you found one more edge case like that, I was afraid my C64 was behaving bad even with good tolerances in place!

I've applied the new version, and best I can do for now is confirm that it works fine for me. But since this latest issue was super intermittent, I'll have to keep doing more testing over longer time, and re-open this ticket again if it comes back.

[c0pperdragon]

As I did not hear any more about this problem since 7 days, I consider this solved for now.