Saturday, September 05
Daily News Stuff 5 September 2020
You Keep Using That Word Edition
You Keep Using That Word Edition
Tech News
- There really is no news at the moment. Everyone is on repeat on the Tiger Lake and RTX 3000 launches, but no-one has anything to benchmark so there's no new information to be had.
- So here's some more olds: Bullfrog after Populous. (The Digital Antiquarian)
Powermonger, Theme Park, and a little game called Syndicate.
- Since we're in the 21st century now and not 1987 how about text-editing your podcasts? (Six Colors)
Descript is a tool that transcribes your podcasts into text - and then lets you edit the audio by editing the transcript. You can't change the words, but you can remove or rearrange sentences.
And this being the 21st century it's a monthly subscription, not something you can just buy.
- This is the Holtek HT48C06.
It's an 8MHz 8 bit microcontroller with up to 96 bytes of on-chip RAM and an IF instruction like the Imagine's A108 DSP. It's used in disposable digital pregnancy tests.
Which, it turns out, contain the classic paper strip and a little circuit that reads the paper strip.
- So, speaking of the Imagine, I figured out a nice additional graphics mode. I mentioned that text modes are actually harder to do than graphics, because on every scan line it needs to read the text information, and then the bitmap data for the font.
The basic text map has two bytes per character: One to specify which of 1024 characters to display, and one to specify which of 32 colours to use for the foreground and background. The video controller can read those two bytes in one cycle, and then spends the next cycle reading one line from the font bitmap, before processing the next character.
So, instead, let's try this: Store the colour information, then the bitmap data, and repeat. We can display one character width per memory access, half as much as in genuine text mode.
Then, rather than directly interleaving the colour and bitmap data, we can have them in two separate banks. Read two colour bytes in one cycle, then two bitmap bytes the next. We can easily buffer a couple of bytes of colour data while we read the bitmap.
That means we can have a 1296 byte array for colour data, and a 12,960 byte array for the bitmap, and have 32 colour text with no fuss at all, using 40% of the available memory cycles. We have 120 cycles available in the visible section of each scan line, and we're display 48 (or maybe 60) characters per line. Since we can read two successive bytes per cycle, and we need two bytes per character, that works it to a very simple 48 (or maybe 60) cycles used.
We can step that up in two ways: First, with four-colour mode like the C64. The C64 didn't let you freely assign the third and fourth colours, but we can. We now need two bytes of colour data (four five-bit values) and two bytes of character data (ten two-bit pixels). Now we're using 96 cycles out of 120 in 48-column mode, and all 120 in 60-column mode. But on the other hand we're using half the memory of standard 32-colour mode and can change the colour of text by changing one byte rather than rewriting the entire character.
Finally, we can provide 10-bit colours directly rather than using the colour registers, for 1024 colour text. In two-colour mode that uses 3 cycles per two characters, so 72 in 48-column mode and 90 for 60 columns. In four-colour mode it...
Wait, that doesn't work, does it? I'm an idiot. Three cycles per column times 48 columns is 144 cycles used out of 120 available. Well, it can be made to work if you move the colour map data over to system RAM. That's perfectly fine; it only takes up 5k and only uses, oh, 50% of available bandwidth. In fact, if you move the colour map to system ram this mode will work for 60 columns, though that will use 100% of the available cycles during the visible phase of each scan line.
- One small problem with all that - this uses two memory maps, one for colour data and the other for pixel data, so effectively both playfields are combined to produce a single layer. That means you can't use it and also overlay graphics, and you can't use it with the dual-monitor trick I mentioned. Not unless I add in more playfield registers anyway.
If you use the interleaved mode it does use just one playfield and can be overlaid on any other single playfield mode, bandwidth permitting. That mode uses nearly twice as much memory - but it does allow colour selection per scan line rather than just per character cell.
Disclaimer: Who designed this stupid thing anyway?
Posted by: Pixy Misa at
11:21 PM
| No Comments
| Add Comment
| Trackbacks (Suck)
Post contains 813 words, total size 6 kb.
53kb generated in CPU 0.0129, elapsed 0.1989 seconds.
56 queries taking 0.1899 seconds, 344 records returned.
Powered by Minx 1.1.6c-pink.
56 queries taking 0.1899 seconds, 344 records returned.
Powered by Minx 1.1.6c-pink.