80 column text mode at quite high resolution

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
CunningFellow
Posts: 1190
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: 80 column text mode at quite high resolution

Post by CunningFellow » Sat Nov 23, 2019 4:20 am

It is not totally un-readable one the 320x200 screen.
Attachments
P1010957.jpg
P1010957.jpg (287.74 KiB) Viewed 325 times

rv6502
Posts: 55
Joined: Mon Feb 11, 2019 4:27 am

Re: 80 column text mode at quite high resolution

Post by rv6502 » Sat Nov 23, 2019 5:32 am

CunningFellow wrote:
Sat Nov 23, 2019 4:20 am
It is not totally un-readable one the 320x200 screen.
It'd be more readable if shaken horizontally by half a pixel ( on a 320 scale ) every frame for a bit of temporal dithering.
I tried with the capture card, it helped but I couldn't capture it (mpeg4 compression removed it. Thanks, motion compensation encoding! :roll: ).

And it was really annoying on the CRT.

And it'd need a user-adjustment setting to match the display's half-resolution.

The other option would be to have a different font version with 3 colors for the half pixels @320 or @360 for low-res capture/LCDs

I don't think sub-pixels would be achievable reliably. Lining-up sub-pixels would be impressive on an NTSC signal and would need timing adjustment on every screens.

CunningFellow
Posts: 1190
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: 80 column text mode at quite high resolution

Post by CunningFellow » Sat Nov 23, 2019 6:11 am

That is already doing temporal dithering. However the dither pattern is optimized to make T2K look good on the screen.

I could maybe get some slight improvement by optimizing the dithering for the 640 pixel mode. I'm not sure how well it would work though given different letters in the font have different pixel timings.

User avatar
Jubatian
Posts: 1404
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: 80 column text mode at quite high resolution

Post by Jubatian » Sat Nov 23, 2019 12:20 pm

rv6502 wrote:
Sat Nov 23, 2019 1:10 am
I'm being somewhat loose with the vsync signal and the emulator has a very narrow tolerance.

Analogue hardware only cares if past a certain threshold of sync time with a simple capacitor charge/discharge and digital hardware only cares if it's more than 50% duty ratio (or some other arbitrary threshold) of sync then it's a vsync.
Yes, that's it with the emulator, since it doesn't actually emulate how a CRT would operate, rather strives to match the signal by some cheap rules (so it can be fast), it is not as tolerant as a good old analog CRT could be. However on the other end of the scale, my SCART LCD TV would choke on the signal even if I added just a few clocks to one of the lines (I tried that to improve NTSC, see this: http://uzebox.org/forums/viewtopic.php?f=3&t=9396 ). So it is actually important to get it checking out clean in the emulator as it ensures that it should work OK on all sorts of televisions (at least as good as any retro microcomputer's picture would look like).
uze6666 wrote:
Sat Nov 23, 2019 1:58 am
Ha, I arrived with the same solution with my last version with the attribute bit! :ugeek: But I will trash it and use Jubatian's, looks pretty good and the size of the tileset is nothing less than impressive. I didn't look but I assume the vram layout and tile indexes are plain standard (no weird scheme like I used).
Thanks! There are no subtle tricks, it is all plain standard, just look at the simple demo code: https://github.com/Jubatian/uzebox/blob ... emo/main.c . It works just like any other "normal" character mode we had before in this regard. A trick here is that this is a Timer terminated mode, which in general is a very efficient way to end scanlines (it saves instructions and it also simplifies horizontal scrolling in modes which are capable to do that). The 7 cycles wide pixel at the end is not that much apparent for such a text mode like this as the last "pixel" is normally a blank (to serve as spacing between the characters).
CunningFellow wrote:
Sat Nov 23, 2019 4:20 am
It is not totally un-readable one the 320x200 screen.
That screen actually seems capable to display 80 tiles of Mode 90, which could potentially look better on it. Unfortunately it doesn't seem too feasible to me to design such a mode which could be adjusted on the fly (especially not to switch between 17 cycles / tile and 18 cycles / tile, code tiling in this way is already a crazy enough thing). How wide the pixels are, or whether pixel widths are even doesn't matter when the input is NTSC, as it is a completely analog signal which the logic of the display has to sample and scale onto its surface. Catching pixel boundaries is not possible on NTSC. On coponent input like VGA, I see that displays are pretty much capable to do it as there would be clear edges to sync to. But for example my computer monitor recognizes 320x200 double-scan as 640x400. The height is trivial (double-scan), the width is apparently that the monitor have a few presets (640, 720, 800, 1024 etc. common horizontal resolutions) which it attempts to match onto the incoming analog signal. On Uzebox, 4 cycles / pixel would likely be what would be picked up as a 320 pixels wide mode if came from an analog source (as that's the typically used pixel clock). Maybe a Framemeister might catch the NTSC C64's pixel clock as well (3.5 cycles / pixel on Uzebox) if it operated on such principle.

Anyway, the point is that when the source is NTSC, what remains after removing the color carrier (more or less successfully) is not very clear in this regard. So it is just scaled onto the phyical pixels of the panel. Algorithms for this usually are okay, in case of CunningFellow's display it could be somewhat better, however it is still the matter of displaying a character in a sligthly less than 4 pixels wide stretch.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests