2600 text fonts (like in Stellar Trek)?

[godzillajoe]

Do they exist for? I wanna do a quick mock screen shot of something for a guy I know. Wondering what the easiest was to get this effect is.

[candiru]

I know there is a free font out there called Atarian. Bauhaus, Blippo, Moderna, Pump, or Expressa are also similar. None of them are exactly like the Stellar Track label though.

------

*edit* Oh, screenshot. Nevermind!

Edited May 31, 2007 by candiru

[Glenn Jupp]

There was a demo text kernel for batari Basic in this thread...

 

http://www.atariage.com/forums/index.php?s...73251&st=50

 

If the screenshot isn't enough for you, then download the binary, pop it into your favourite emulator, and have fun screencapping some venetian blinds text.

Edited June 1, 2007 by Glenn Jupp

[godzillajoe]

There was a demo text kernel for batari Basic in this thread...

 

http://www.atariage.com/forums/index.php?s...73251&st=50

 

If the screenshot isn't enough for you, then download the binary, pop it into your favourite emulator, and have fun screencapping some venetian blinds text.

 

That actually might work with a cut and paste job. I think all the letters I need are there. Or close enough.

 

Now I need to make a fake cart label.

 

[SeaGtGruff]

Do they exist for? I wanna do a quick mock screen shot of something for a guy I know. Wondering what the easiest was to get this effect is.

How large do you want the letters? I have a fairly complete set of standard ASCII characters (the displayable ones, anyway) that I created for the E.T. Book Cart, but they're 4x8 rather than 8x8. If you plan to do cut-and-paste of the letters to create a mock screen shot, then I have a screen showing the full set that I created...

 

Michael

 

[SeaGtGruff]

I have a fairly complete set of standard ASCII characters (the displayable ones, anyway) that I created for the E.T. Book Cart

 

That was an early screenshot. I think I ended up changing the lowercase r slightly. Here's a small shot that shows the two r variations side by side:

 

 

Michael

[Quadhorn]

How large do you want the letters? I have a fairly complete set of standard ASCII characters (the displayable ones, anyway) that I created for the E.T. Book Cart, but they're 4x8 rather than 8x8. If you plan to do cut-and-paste of the letters to create a mock screen shot, then I have a screen showing the full set that I created...

 

Thank the almighty Scrod for that. Having discovered the E.T Book Cart in the store, I've just spent the last half hour searching through the forums trying to find out how in Hades you made that text work (I've played a little with A2600 coding; I know its limits to a degree). I found myself looking at well over 8 or even 12 characters on a line, most definitely on an Atari 2600 and thought I'd gone mad. I'd been counting pixels to see if it was some strange use of the 48-pixel graphic routine and that didn't work either. Splicing pairs of 4x8 font characters into a buffer for a 12 character display makes sense; my sanity is restored.

 

Nice job by the way; it must have been evil to code. I'd have never thought the Atari 2600 could display text that well. I am much impressed ... and may steal the idea for a small project if I ever get one underway ...

[SeaGtGruff]

How large do you want the letters? I have a fairly complete set of standard ASCII characters (the displayable ones, anyway) that I created for the E.T. Book Cart, but they're 4x8 rather than 8x8. If you plan to do cut-and-paste of the letters to create a mock screen shot, then I have a screen showing the full set that I created...

 

Thank the almighty Scrod for that. Having discovered the E.T Book Cart in the store, I've just spent the last half hour searching through the forums trying to find out how in Hades you made that text work (I've played a little with A2600 coding; I know its limits to a degree). I found myself looking at well over 8 or even 12 characters on a line, most definitely on an Atari 2600 and thought I'd gone mad. I'd been counting pixels to see if it was some strange use of the 48-pixel graphic routine and that didn't work either. Splicing pairs of 4x8 font characters into a buffer for a 12 character display makes sense; my sanity is restored.

 

Nice job by the way; it must have been evil to code. I'd have never thought the Atari 2600 could display text that well. I am much impressed ... and may steal the idea for a small project if I ever get one underway ...

 

I wrote the text-display algorithm on my own, without looking at other people's solutions, and I think I did a couple of things "the hard way," or less efficiently than they could have been done. It's probably possible to improve the algorithm a good bit to get faster execution time or smaller code. TROGDOR posted a similar text display in his blog, but his algorithm is a bit different than mine, and when I was looking at his approach, I realized that my algorithm could undoubtedly be improved:

 

http://www.atariage.com/forums/index.php?a...;showentry=2545

 

Aside from actually reading and displaying the character data, the other main issue is how to store the text data, especially if the text is distributed over two or more banks of ROM (as is the case with the E.T. Book Cart). I'm quite proud of my solution to that issue, which was to split the text data for each page (screen) into two separate tables, one for each frame, and then create indexes for the pages to store their bank numbers and lo-byte/hi-byte of their starting position in each bank. I wrote a utility in FreeBASIC to read in a "page" of text and split it into the two tables of text data for the two frames, as well as converting consecutive spaces into horizontal tabs, converting trailing spaces into line feeds, converting consecutive line feeds into vertical tabs, and converting trailing line feeds into page feeds. Then the display algorithm checks for those four control characters (HT, LF, VT, and FF), and converts them back into consecutive spaces, trailing spaces, consecutive line feeds, and trailing line feeds. I did that to help squeeze the text data into the smallest amount of space, given that there was a lot of text that needed to be stored. However, the checking and conversion process adds a lot more cycles to the display algorithm, so if the ROM needed to store the text data is less of an issue, it would be faster to just store the text "as is" instead of using the HT, LF, VT, and FF characters.

 

The actual display could have been improved in at least two ways-- by using "Venetian blinds," and by reducing the amount of contrast between the character foreground (player) and character background (playfield) colors. Doing that should have reduced the flickering a good deal.

 

Michael

[supercat]

I wrote the text-display algorithm on my own, without looking at other people's solutions, and I think I did a couple of things "the hard way," or less efficiently than they could have been done. It's probably possible to improve the algorithm a good bit to get faster execution time or smaller code. TROGDOR posted a similar text display in his blog, but his algorithm is a bit different than mine, and when I was looking at his approach, I realized that my algorithm could undoubtedly be improved:

 

Venetian blinds look nice but double up on the amount of RAM required for pointer storage; they will also generally require more processing to set up the necessary pointers.

 

Still, I'm toying with a text-adventure kernel that should allow 20 lines of 24 characters to be displayed in a scrolling window. Tthe screen could look something like:

YOU ARE IN A LARGE CAVE.
LIGHT SHINES IN FROM AN
OPENING 20 FEET UP THE
SOUTH WALL.

AN IMPASSABLE CHASM LIES
TO THE WEST.

A STEEP RAMP SLOPES DOWN
TO THE NORTH.

A SIGN READS "GET THE 3
TREASURES AND ESCAPE!"

>MOVE WEST

THE CHASM IS DEEP, AND
TOO WIDE TO CROSS.

>MOVE NORTH

YOU ARE AT THE SHORE OF
AN UNDERGROUND LAKE.

A STEEP RAMP LEADS UP TO
THE SOUTH.

>

To improve screen utilization, I'd probably allow half-height blank lines. That seem like an interesting idea? A bank-switched cart would be required for any non-trivial game, but no supplemental RAM would be required.