80 column text mode at quite high resolution
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: 80 column text mode at quite high resolution
It is not totally un-readable one the 320x200 screen.
- Attachments
-
- P1010957.jpg (287.74 KiB) Viewed 8433 times
Re: 80 column text mode at quite high resolution
It'd be more readable if shaken horizontally by half a pixel ( on a 320 scale ) every frame for a bit of temporal dithering.CunningFellow wrote: ↑Sat Nov 23, 2019 4:20 am It is not totally un-readable one the 320x200 screen.
I tried with the capture card, it helped but I couldn't capture it (mpeg4 compression removed it. Thanks, motion compensation encoding! ).
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.
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: 80 column text mode at quite high resolution
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.
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.
Re: 80 column text mode at quite high resolution
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).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.
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).uze6666 wrote: ↑Sat Nov 23, 2019 1:58 am Ha, I arrived with the same solution with my last version with the attribute bit! 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).
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.CunningFellow wrote: ↑Sat Nov 23, 2019 4:20 am It is not totally un-readable one the 320x200 screen.
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.
-
- Posts: 78
- Joined: Wed Nov 02, 2022 3:57 pm
Re: 80 column text mode at quite high resolution
Hi,
is it possible to get color for such 80 char/line mode, so we can build a nice ANSI terminal?
BTW.: I don't understand the color comments in the readme. You can have default color, palettes in ROM or RAM, colorlists, display lists.
A color example would be nice. Or at least: how can I set the general foreground and background color?
is it possible to get color for such 80 char/line mode, so we can build a nice ANSI terminal?
BTW.: I don't understand the color comments in the readme. You can have default color, palettes in ROM or RAM, colorlists, display lists.
A color example would be nice. Or at least: how can I set the general foreground and background color?
Re: 80 column text mode at quite high resolution
He needs his Bluescreen!
That's as much use as I am here unfortunately.
That's as much use as I am here unfortunately.
Re: 80 column text mode at quite high resolution
For a Mode 80 example try this out:
Code: Select all
#include <stdbool.h>
#include <avr/io.h>
#include <stdlib.h>
#include <avr/pgmspace.h>
#include <uzebox.h>
#include <stdint.h>
extern m80_dlist_tdef* m80_dlist;
m80_dlist_tdef dlist[1];
int main(){
ClearVram();
dlist[0].vramrow = 1U;
dlist[0].tilerow = 1U;
dlist[0].bgc = 0b00000000; /* Background color => black */
dlist[0].fgc = 0b00101000; /* Foreground color => green */
dlist[0].next = 0U; /* End of Display List */
m80_dlist = &dlist[0];//set the pointer to our new display list
Print( 0, 1, PSTR(" <--------><--------><--------><--------><--------><--------><--------><--------> "));
Print( 0, 2, PSTR(" 00 10 20 30 40 50 60 70 80 "));
Print( 0, 12, PSTR(" "));
Print( 0, 13, PSTR(" 80 x 28 code tile display "));
Print( 0, 14, PSTR(" (??? x 224 pixels) "));
Print( 0, 15, PSTR(" "));
Print( 0, 25, PSTR(" 00 10 20 30 40 50 60 70 80 "));
Print( 0, 26, PSTR(" <--------><--------><--------><--------><--------><--------><--------><--------> "));
while(1);
}