Re:Pixel graphics in terminal
by etfb on Wednesday May 21, 2014 @04:11AM
(#7777115)
I learned Turbo Pascal in an MS-DOS emulator running on old green-screen Burroughs smart terminals, circa 1987. I knew the terminals had some sort of graphics capacity because their font changed when they left VMS mode and started emulating MS-DOS, so I wrote a program to rummage around in memory until I found where the font designs were stored. Then I wrote a font editor that changed the standard font whenever I logged in, to a design based on my own handwriting. After that, I took a leaf out of the Microbee computer's books and emulated hi-res graphics: I wrote a program that printed all the ASCII characters from 33 to 255 in a rectangle, set their font definitions to all zeroes, and then selectively set individual pixels back on according to a pattern that assumed the exact layout of characters. Implemented line, circle, flood fill and a few other graphics primitives. Fun!
[ Parent
| on HN ]
Re:Pixel graphics in terminal
by elliottcarlson on Wednesday May 21, 2014 @09:57AM
(#7778218)
One of my first "public" programs that I made was written in Turbo Pascal and was a read me style app for a demo group (I wasn't anywhere near capable of doing what the rest of the group could do - but at least I found a way to contribute) - I used a custom made font, had a scrolling buffer etc - always nice to take a stroll down memory lane.
> take a scroll down memory lane
Ah, cool. You used to be able to define your own characters on Amstrads, and that's how I wrote most of my first games.
Pretty sure it was the way hi-res graphics worked on the VIC-20 too -- 22 characters by 8 pixels per character = 176 pixels wide, multi-colour mode where each block of 8x8 pixels had a background and a foreground colour. Deeply freaky.
The Vic also had a mode whereby you could make "double height" characters (halving the number of addressable rows), so when you typed "a", it would emit (iirc):
a
b
c
d
edit: formatting
On the ZX81 and ZX Spectrum, they called them "User-Defined Graphics" or UDGs. I think I wrote a pixel-flipping grid font editor for characters on every computer I had access to! The ZX81, the ZX Spectrum, the Apple II (once I noticed that one of the games I had (Taipan?) hooked the text output routines into a hires character generator), and eventually various x86 programming environments, although there you were editing bitmaps, not changing the character generator source. :-)
I used semigraphics on a CoCoII, not my video, but gives an idea of what that means ;)
> You used to be able to define your own characters on Amstrads
ah so THAT is how you could make graphics on those machines? wish I had known that back when I was 10 :-P
ah well, good times :)
Re:Pixel graphics in terminal
by Fr0styMatt on Wednesday May 21, 2014 @07:23AM
(#7777615)
Alright this is the most awesome post I've read all day :) I really need to get to work putting together the kit Microbee that's currently sitting on my other desk....
Are you old enough to remember daisy wheel printers? Basically, the computerised equivalent of a typewriter, with the individual letters on a daisy-like wheel that spun around under computer control to produce slow but "letter quality" printing. When I showed people my handwriting font, they were very impressed and asked if my printouts would be in my handwriting too. Given that the only printers we had were daisy wheels, I suggested that perhaps this would not be happening.
Some daisywheel printers could be coerced to print high-resolution graphics, by repeatable printing a few zillion periods and using the variable line spacing and tab settings.
'Fast' was not a word one would use to describe them, though, even compared to the matrix printers that took minutes for each page of high-resolution output.
Coming back to the original post, I wrote a proof-of-concept Braille output program for a daisy wheel printer. Basic idea was: take a line of text input, eg "hello". Convert to Braille ("⠓⠑⠇⠇⠕"), but reverse the dot patterns to make "⠪⠸⠸⠊⠚"). Sandwich a sheet of paper towel between two sheets of paper, feed it into the printer and print the reversed dots using "." and space, micro-positioned.
Theoretical result: raised dots punched into the paper by the daisy wheel, able to be read by a blind person.
Actual result: the proportions were wrong for reading, and most of the time the paper jammed on the roller because of the padding.
Nice idea though.