Broken 80 column display on C128

[fredrikr]

@0ldSkull reported a problem with characters missing or coming our garbled in Beyond Zork on 80 column display on C128. I think this is related to my optimization of the 80 column routines. Vice's emulation of the VDC is incomplete, and I don't have a C128 to test on.

Could you make a video of the 80 column text problems in Beyond Zork on real hardware? Alternately, describe it more. Does it happen on the first screenful of intro text in Beyond Zork, or only when text starts to scroll?

It would also be interesting to know if it happens with a z5 title which doesn't use colours, e.g. Curses, and with a z3 title.

You can reach me at fredrik dot ramsberg at gmail dot com if there's something you'd prefer to send by mail.

[0ldSkull]

Here are download links to some videos; please forgive the camerawork as I don't have an RGBI capture setup :). If needed I can try to upload them to Youtube later (let me know).

• Beyond Zork
• Mini-Zork
• Curses

And some photos I took when originally observing the issue:

• Mini-Zork
• Beyond Zork (machine 1)
• Beyond Zork (machine 2)

One thing to note is that the results are not exactly the same every time, as can be seen by comparing the Mini-Zork photo and beginning of the video which both used the same machine.

[fredrikr]

Thanks a lot!

I found a thread at https://www.lemon64.com/forum/viewtopic.php?t=64971&sid=720fd316d9a3227e0820c1465f4e042b where a user got problems from writing first lowbyte then highbyte to the VDC when setting the address, just like Ozmoo does it. I now changed this. I would expect this to at least fix part of the problem.

@0ldSkull Do you have the time to test out Beyond Zork, from the start and a few moves into the game, just like in the video you made?

[0ldSkull]

That's a good find. While there is a visible difference, the behavior is still essentially the same overall. Here's a quick photo of the Beyond Zork opening text: I did play a few moves and also checked Mini-Zork.

[fredrikr]

Thanks!

Was the upper window (statusline, map and room description) flawless after this change?

[0ldSkull]

No, they still had some missing characters as before. I also happened to notice a couple of missing characters on the Ozmoo splash screen, so my earlier statement that it is always drawn reliably was probably inaccurate.

BTW I was just scanning through Bil Herd's writings referenced in that thread (https://web.archive.org/web/20191001153915/http://homepage.hispeed.ch/commodore/c128_story.html) and the following caught my eye; not sure if there is any possibility it could be related:

the 8563 also had a problem where the 256 'bite' transfer didn't always take place properly, leaving a character behind. This ended up having the effect of characters scrolling upwards randomly. ... The 8563 designer mentioned that the block copy seemed to work better when you wrote the same command twice in a row.

[fredrikr]

Thanks for checking!

We don't seem to have a scrolling problem here, so it's not about block copying. Before optimizing the code for VDC (which began with a commit made on Sep 22 I think), we would:

• tell the VDC which address in screen memory to write to
• wait for VDC to confirm
• write a character
• wait for VDC to confirm
• tell the VDC which address in colour memory to write to
• wait for VDC to confirm
• write a colour value
• wait for VDC to confirm etc.

Now, we usually:

• Tell VDC the address of the first byte on the line in screen memory
• Write all the characters on the line except the last (1-79 characters)
• Tell the VDC the address of the first byte on the line in colour memory
• Write the colour value once
• Tell VDC to copy the last value as many times as the number of characters we've written minus one
• Set the address in screen memory of the last character
• Write the last character
• Set the address in colour memory of the last character
• Write the current colour value

So, not much waiting for confirmation, and we send the address a lot less often.

Since we get errors also in the top window, where we're always printing with the old method of writing a byte to screen memory, then writing a byte to colour memory, we have a problem in some of the basic mechanisms, not just the way we print many characters in a row without giving an address.

Perhaps we need to go back to waiting for a confirmation at least in some of these cases.

[fredrikr]

I put in code to wait for VDC to say it's ready in two places. Please test if you have a chance.

Note: If 80 column display fails with any game, you could of course use something really small for testing purposes, if that speeds up the process for you.

If this works well, it would also be interesting to see if one of these wait loops could be removed again.

[0ldSkull]

That seems to have done it! Mini-Zork, Beyond Zork, Curses, and Vacation all appear to work correctly. I tried removing each delay independently, and both seem to be required. I did see a noticeable improvement in the issue with only the delay in vdc.asm added, but it was still present.

[fredrikr]

That's great to hear! I've updated Ozmoo Online with the new version.