Sorry I wasn't clear, I meant an attribute bit to do arbitrary inverse per character, like in this post. ...unless your lists can do that?You can already do inverse if you start playing around with it: Set up a display list, then you can (should be able to unless I bugged it!) set any global Foreground / Background color
80 column text mode at quite high resolution
Re: 80 column text mode at quite high resolution
This is really insane and clever. My head hurts trying to understand it.
Re: 80 column text mode at quite high resolution
If you fill up the whole character set, half with the "straight" characters (0 - 127), next half with the inverted variants (128 - 255), then essentially you will have that! I attached a generated character set (21Kbytes) and a corresponding demo. Include the charset on Line 139 of videoMode80core.s instead of the cp437 one, compile, and you have it!uze6666 wrote: ↑Thu Nov 21, 2019 7:12 am This is really insane and clever. My head hurts trying to understand it.
Sorry I wasn't clear, I meant an attribute bit to do arbitrary inverse per character, like in this post. ...unless your lists can do that?You can already do inverse if you start playing around with it: Set up a display list, then you can (should be able to unless I bugged it!) set any global Foreground / Background color
At this resolution I don't see it possible to do an algorithmic swap, or the size of that could end up being much worse (even if it can be done in 2 clocks, having an "rjmp" instead of that likely pays off in tail merging).
EDIT: I assume you have a 128 character set there, I can not quite imagine it working in any other manner at the moment (where else the attribute bit could come from than the 7th bit of the character). If so, I guess the characters beyond the 96 standard ASCII are different than in CP437. If you pass me a character set, I could draw the corresponding extra 32 for the terminal emulator.
- Attachments
-
- m80demo.uze
- Mode 80 demo compiled with 7 bit + Inverted charset
- (29.74 KiB) Downloaded 495 times
-
- m80_7bitinv.zip
- Mode 80 7 bit + Inverted charset
- (12.74 KiB) Downloaded 480 times
- nicksen782
- Posts: 714
- Joined: Wed Feb 01, 2012 8:23 pm
- Location: Detroit, United States
- Contact:
Re: 80 column text mode at quite high resolution
Impressive! I look forward to seeing what comes next! I'm sure a text adventure game would be totally welcome!
Re: 80 column text mode at quite high resolution
Yeah Indeed, that's what I tried with mode9 but the roughly 110 tiles inverted set could not fit in flash so I resorted to add that flag on the 7th bit (so yes, it's a 128 max tileset). So you say you have a full 256 tileset in just 21K -- and all 80 chars are visible on a TV screen? That's pretty impressive...my crappy version needs 32K for 128 tiles. Man, I spent a couple weeks on this and you find a better method in a day or so?! Leave me a bit of thunder!If you fill up the whole character set, half with the "straight" characters (0 - 127), next half with the inverted variants (128 - 255), then essentially you will have that!
Yeah I decided to prefer the use of the box drawing chars to all the accents and other symbols from ASCII to 31. Here's what I have now. But I can make you another one with all the box chars I can fit up to 127. Btw, what's the size of tiles in your mode and how many clocks per pixel?If so, I guess the characters beyond the 96 standard ASCII are different than in CP437. If you pass me a character set, I could draw the corresponding extra 32 for the terminal emulator.
- Attachments
-
- font6x8-full.png (3.22 KiB) Viewed 12447 times
Re: 80 column text mode at quite high resolution
Here you go, a terminal character set attached.
To use it, like before, videoMode80core.s, line 138, include it. Then in videoMode80.c, also modify the appropriate line to read SetFontTilesIndex(0); as this character set has the space at position 0.
I attached the source image as well, that's how it looks like raw. The tiles are 17 cycles wide, corresponding to 17 pixels. You can have up to 7 stretches of pixels, with some limitations, depending on what sort of tile fetch code the compiler can cram between the required "out"s to achieve the appropriate display. Last "pixel" is always 3 cycles wide (ijmp), and either the first or second pixel has to also be 3 cycles wide (for an rjmp). In total the row must have at least 4x 3 cycles wide pixels (the two others are for the ld and the mul instructions), and there are also two 1 cycle instructions which have to fit. The compiler tries to fit from many possible sequences to allow for quite decent freedom.
The minimal size of this type of tileset is 16 KBytes for 8 pixels tall tiles. If you are using a Mode 9 like generation, then it is 8 KBytes for 8 pixels tall tiles, so you may get a Mode 9 like 256 character monochrome font in ~12-15Kbytes (if you used color, then there are less opportunities for tail merging, which would inflate size).
To use it, like before, videoMode80core.s, line 138, include it. Then in videoMode80.c, also modify the appropriate line to read SetFontTilesIndex(0); as this character set has the space at position 0.
I attached the source image as well, that's how it looks like raw. The tiles are 17 cycles wide, corresponding to 17 pixels. You can have up to 7 stretches of pixels, with some limitations, depending on what sort of tile fetch code the compiler can cram between the required "out"s to achieve the appropriate display. Last "pixel" is always 3 cycles wide (ijmp), and either the first or second pixel has to also be 3 cycles wide (for an rjmp). In total the row must have at least 4x 3 cycles wide pixels (the two others are for the ld and the mul instructions), and there are also two 1 cycle instructions which have to fit. The compiler tries to fit from many possible sequences to allow for quite decent freedom.
The minimal size of this type of tileset is 16 KBytes for 8 pixels tall tiles. If you are using a Mode 9 like generation, then it is 8 KBytes for 8 pixels tall tiles, so you may get a Mode 9 like 256 character monochrome font in ~12-15Kbytes (if you used color, then there are less opportunities for tail merging, which would inflate size).
- Attachments
-
- m80demo.uze
- Simple demo displaying it
- (28.74 KiB) Downloaded 488 times
-
- Source image for the character set
- charset_terminal.png (1.82 KiB) Viewed 12439 times
-
- m80_terminal.zip
- Terminal character set
- (11.77 KiB) Downloaded 488 times
Re: 80 column text mode at quite high resolution
I've also been working on an 8x8 80x25 mode for doing ports.
Each row has to end with a null byte (memory is 81x25) to jump-table out of the sequence so I only got 127 characters usable.
It's still a bit clunky and my cheap USB capture dongle doesn't line up the pixels right so making screenshot still requires going hardware I don't think I can fix that part, looks like it's just the cheap USB capture being too low-res.
4112 bytes for the charset but I got nothing in the 0-31 range and the font has lots of identical rows so a lot of them get merged.
Font from https://github.com/dhepper/font8x8
Doesn't display in the emulator tho.. I'll have to see if I can patch that.
Each row has to end with a null byte (memory is 81x25) to jump-table out of the sequence so I only got 127 characters usable.
It's still a bit clunky and my cheap USB capture dongle doesn't line up the pixels right so making screenshot still requires going hardware I don't think I can fix that part, looks like it's just the cheap USB capture being too low-res.
4112 bytes for the charset but I got nothing in the 0-31 range and the font has lots of identical rows so a lot of them get merged.
Font from https://github.com/dhepper/font8x8
Doesn't display in the emulator tho.. I'll have to see if I can patch that.
- Attachments
-
- videobench.uze
- (7.41 KiB) Downloaded 483 times
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: 80 column text mode at quite high resolution
rv6502, What CPU tricks are you using to make the emulator not work?
Re: 80 column text mode at quite high resolution
Emulator is happy with it once patched
And I need to adjust my mid-frame audio generator call it's messing up the hblank by quite a few cycles even with the recursive interrupt.
Funny enough the CRT doesn't care. I guess they used to try hard to keep the picture lined up nice even with bad RF signals. Hurray for PLLs
And I need to adjust my mid-frame audio generator call it's messing up the hblank by quite a few cycles even with the recursive interrupt.
Funny enough the CRT doesn't care. I guess they used to try hard to keep the picture lined up nice even with bad RF signals. Hurray for PLLs
Re: 80 column text mode at quite high resolution
I'm being somewhat loose with the vsync signal and the emulator has a very narrow tolerance.CunningFellow wrote: ↑Sat Nov 23, 2019 12:48 am rv6502, What CPU tricks are you using to make the emulator not work?
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.
Re: 80 column text mode at quite high resolution
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).Each row has to end with a null byte (memory is 81x25) to jump-table out of the sequence so I only got 127 characters usable.