60 replies to this topic

[solidcorp]

Has anyone ever made a 32 character text display on the 2600?

I've seen the 24 character display

And I think Thomas Jentzsch did a 28 character display (used in the Harmony cart?).

I've been working on one for several weeks and just got it working last night. It's not perfect, it's off center and has a minor character spacing artifact that I'm pretty sure is insurmountable but it's acceptable. I verified it works in both Stella and on the Harmony cartridge (hats off to the Stella team, this kernel uses the hardware in a weird way but the emulation is 100% true to the real platform). It truly can display 32 character strings of any text within the 51 character font. The interleaved text it 10 lines tall and it takes a little more than that to reload the 80 byte buffer. I found an art style/theme that really works within the quirky constraints, I'm not ready to show it though. I haven't finished the Venetian blinds or have it scrolling yet either, but those are details, technically the hard part is done.

This will be part of the 64k StarCastle mega cart. By the way, the 64K cartridge hardware with 2 software programmable LEDs is working too.

Scott Williamson

[cd-w]

The Harmony cart displays 24-characters. Supercat managed to display 26 characters, but I don't think anyone has managed to top this yet. I'm interested to know how you managed it - can you post up a screen-shot?

Chris

[solidcorp]

cd-w, on Mon Apr 18, 2011 9:42 AM, said:

The Harmony cart displays 24-characters. Supercat managed to display 26 characters, but I don't think anyone has managed to top this yet. I'm interested to know how you managed it - can you post up a screen-shot?

Chris

I will, I promise, but please let me clean it up first - I'll try to post a pic in a few days.

Also, there are no HMOVE bars and missiles & ball are unused for text.

Scott

[ScumSoft]

So each letter is 4 pixels wide leaving 1 pixel space between letters? Sounds a bit scrunched to me.

[solidcorp]

ScumSoft, on Mon Apr 18, 2011 2:45 PM, said:

So each letter is 4 pixels wide leaving 1 pixel space between letters? Sounds a bit scrunched to me.

It's scrunched, the same 3x5 font I used in S.T.U.N. Runner on the LYNX - it gets a little dicey with "M", "N", and "W", they are distinguishable but context starts to become important.

Two characters per player, just like all the other text routines (except those that use players and the ball). Each letter is 3 pixels wide leaving 1 pixel space between letters - most of the time - as I said there are spacing artifacts that, so far are unavoidable due to the intricate timing required and the use of the four 6507 byte registers. I find the text display acceptable. It is not as nice as the evenly spaced 24 and 28 character text displays, but it was a feat to get all that text to just to display on a single interleaved scanline - 8 players worth for 16 characters with venetian blinds effect coming.

Scott

[solidcorp]

Re:

Quote

(except those that use players and the ball)

er... except those that use missiles and the ball

Scott

[Nukey Shay]

The solution for N is to use a tall "n" instead. So there's only M and W to worry about in a 3x5 font.

[atari2600land]

I haven't heard about the "Star Castle 64K" project yet. Are there any more details about it?

[SeaGtGruff]

solidcorp, on Mon Apr 18, 2011 3:12 PM, said:

It's scrunched, the same 3x5 font I used in S.T.U.N. Runner on the LYNX - it gets a little dicey with "M", "N", and "W", they are distinguishable but context starts to become important.

Two characters per player, just like all the other text routines (except those that use players and the ball). Each letter is 3 pixels wide leaving 1 pixel space between letters - most of the time - as I said there are spacing artifacts that, so far are unavoidable due to the intricate timing required and the use of the four 6507 byte registers. I find the text display acceptable. It is not as nice as the evenly spaced 24 and 28 character text displays, but it was a feat to get all that text to just to display on a single interleaved scanline - 8 players worth for 16 characters with venetian blinds effect coming.

Scott

It sounds like you're strobing RESP0 and RESP1 to get extra copies of the sprites. Good job! I'm looking forward to seeing the result.

Michael

[solidcorp]

Nukey Shay, on Mon Apr 18, 2011 5:59 PM, said:

The solution for N is to use a tall "n" instead. So there's only M and W to worry about in a 3x5 font.

I thought about that, the font graphics are still a little low on the list at the moment.

I really like the mixed case used in the Harmony cart, but am single case now. I have the bits and space to do mixed case... maybe later.

Thanks!

Scott

[solidcorp]

atari2600land, on Mon Apr 18, 2011 6:07 PM, said:

I haven't heard about the "Star Castle 64K" project yet. Are there any more details about it?

StarCastle will always run in 8k to be historically relevant (I know, I know, Yars Revenge was a 4k cart, but there were 8K carts at the time and I just set out to prove it was technically possible to make the game at that time and that it wouldn't suck). There are some improvements in the StarCastles game since last year.

To make StarCastle, I decided to make my own cartridge from scratch, PCB, EEPROM, PLD, LEDs and all. The maximum capacity is 64K, 16x4k banks which is working with two software controllable LEDs. I used Stella and the Harmony cart for 99% of the development though using F8 bank switching.

The StarCastle MegaCart is a 64K cartridge that is intended to "exhibition" my work on StarCastles. I'm not much for saying what I plan to do, but I guarantee I'll tell you all when I have something to show.

Scott Williamson

[solidcorp]

SeaGtGruff, on Mon Apr 18, 2011 6:23 PM, said:

It sounds like you're strobing RESP0 and RESP1 to get extra copies of the sprites. Good job! I'm looking forward to seeing the result.

Michael

Exactly right Michael. The trick is configuring the hardware (it's behavior is unexpected) and getting the writes to GRP0, GRP1, RESP0, and RESP1 in exactly the right order at exactly the right time. There are [at least] 6 configurations that I proved can not possibly work. This configuration works with some character spacing concessions. Venetian blinds introduces more headaches because there is a limit to how quickly you can retrieve the character data into the four 8 bit 6507 registers to stuff into the hardware regs AND you have to fill all 80 bytes of character data between lines. I think the image quality is totally worth it over PacMan ghost flickering though.

There are no illegal opcodes used [yet] either - but I wished for a bunch!

Well, I better get back to it...

Scott

[solidcorp]

atari2600land, on Mon Apr 18, 2011 6:07 PM, said:

I haven't heard about the "Star Castle 64K" project yet. Are there any more details about it?

.... by the way, I'm preparing it for the Video Game Summit.

[SeaGtGruff]

solidcorp, on Mon Apr 18, 2011 8:03 PM, said:

SeaGtGruff, on Mon Apr 18, 2011 6:23 PM, said:

It sounds like you're strobing RESP0 and RESP1 to get extra copies of the sprites. Good job! I'm looking forward to seeing the result.

Michael

Exactly right Michael. The trick is configuring the hardware (it's behavior is unexpected) and getting the writes to GRP0, GRP1, RESP0, and RESP1 in exactly the right order at exactly the right time. There are [at least] 6 configurations that I proved can not possibly work.

Yes, the RESP0/RESP1 trick gives different results depending on how long you wait before strobing. For example, Galaxian gives a fairly even spacing, but there are extra spaces every so often because of how it does it (it draws two copies of a player before strobing again, if I remember correctly). I'm guessing you're using a variation of that, tailored toward a flicker-blinds display.

Michael

[solidcorp]

Screenshot.

I got venetian blinds in last night, and man does that make a difference on a real TV. This screenshot is from Stella with the command line phosphor flag turned on and it's pretty representative of what you see on the TV.

The lines of text could be a few scanlines closer together - I burn extra scan lines for the edges of the green color bars and for the anti-aliased holes in the sides of the paper.

My video frame timing is really sloppy in this demo, VSync, and overscan times are perfect but I couldn't even tell you how many lines this is trying to display right now. It's close enough to 192 that it doesn't roll on my TV though - I'll sort that out later when I get vertical scrolling working. It could preload one line of text graphics into RAM in VBlank, but I don't think that would buy enough time to display another line of text - maybe if I stripped out all the decorative code - idk.

Note the character spacing, I wish I could get it perfect but I believe that's impossible. There is one other working configuration where there are two groups of 16 characters that line up perfectly, but they are separated by 6 or 7 pixels in the center of the screen, so unless I want to make it look like newspaper columns, I thought this configuration worked better.

Its a hare over 2.5k. There are no fancy tables for combined characters or anything, just 51 five pixel tall characters(256 bytes)of the font in the left 4 bits and the same in the right 4 bits.

Nukey Shays comment and looking at the Harmony menu has me thinking about spending another 260 bytes on a lower case font too (only 26 glyphs need to be case sensitive).

Questions? Comments?

Attached Thumbnails

• 

[Random Terrain]

solidcorp, on Tue Apr 19, 2011 12:34 PM, said:

Note the character spacing, I wish I could get it perfect but I believe that's impossible. There is one other working configuration where there are two groups of 16 characters that line up perfectly, but they are separated by 6 or 7 pixels in the center of the screen, so unless I want to make it look like newspaper columns, I thought this configuration worked better.
. . .

Questions? Comments?

Too bad you can't get it to always have one space between characters and a larger space between words. Kind of hard to read the way it is.

If I was making the characters, most would look like what you have, but there would be some differences. The image below shows what I might have done (my possible character replacements are darker).

[RevEng]

How about using a second font shifted over a pixel? It looks like selectively using a shifted font would allow you to smooth out some of the spacing issues.

[cd-w]

It is impressive that you managed to display so many characters. It is a pity about the spacing, but that probably can't be helped.

Chris

[SeaGtGruff]

RevEng, on Tue Apr 19, 2011 3:49 PM, said:

How about using a second font shifted over a pixel? It looks like selectively using a shifted font would allow you to smooth out some of the spacing issues.

I was thinking the same thing, but you might not need a second font, just shift/rotate the data before storing it in RAM. There might still be two or three spots where the spacing will be off, but it should look a little better.

I also like most of Random Terrain's suggestions about the character set, the only exception being for "Q." I'm thinking of this instead:



It doesn't look as good with the 3x5 character size, but is still readily recognizable as "Q." It looks better if you have another line or two for lowercase descenders, so the tail of the "Q" can be in the first (highest) descenders' row.

Michael

[Random Terrain]

SeaGtGruff, on Tue Apr 19, 2011 4:17 PM, said:

I also like most of Random Terrain's suggestions about the character set, the only exception being for "Q." I'm thinking of this instead:

Q.png

It doesn't look as good with the 3x5 character size, but is still readily recognizable as "Q." It looks better if you have another line or two for lowercase descenders, so the tail of the "Q" can be in the first (highest) descenders' row.

Yeah, that looks better. My Q kind of looks like a large lower-case a

[solidcorp]

Random Terrain, on Tue Apr 19, 2011 3:23 PM, said:

solidcorp, on Tue Apr 19, 2011 12:34 PM, said:

Note the character spacing, I wish I could get it perfect but I believe that's impossible. There is one other working configuration where there are two groups of 16 characters that line up perfectly, but they are separated by 6 or 7 pixels in the center of the screen, so unless I want to make it look like newspaper columns, I thought this configuration worked better.
. . .

Questions? Comments?

Too bad you can't get it to always have one space between characters and a larger space between words. Kind of hard to read the way it is.

If I was making the characters, most would look like what you have, but there would be some differences. The image below shows what I might have done (my possible character replacements are darker).

Thanks, I may take you up on most if not all of your suggestions.

Scott

[solidcorp]

RevEng, on Tue Apr 19, 2011 3:49 PM, said:

How about using a second font shifted over a pixel? It looks like selectively using a shifted font would allow you to smooth out some of the spacing issues.

That was the plan, I did that, it didn't work.

The timing is so exquisitely delicate that the graphics registers are being changed while they are being displayed. By adding shifted characters and using them to fill selected columns fixed the columns but bled into earlier usages of the player graphics. There are no free cycles to pull the open gaps together either.

I reiterate though, it is possible to make two perfectly spaced columns of 16 characters separated by 6 or 7 pixels. Maybe there is a use for that.

Also, there are tens of cycles free in a couple places every 2 scan lines (one venetian blind) to do free color cycling or set playfield graphics as long as you are able to change those values at the time slots you are given in the scan line.


Scott

[solidcorp]

SeaGtGruff, on Tue Apr 19, 2011 4:17 PM, said:

RevEng, on Tue Apr 19, 2011 3:49 PM, said:

How about using a second font shifted over a pixel? It looks like selectively using a shifted font would allow you to smooth out some of the spacing issues.

I was thinking the same thing, but you might not need a second font, just shift/rotate the data before storing it in RAM. There might still be two or three spots where the spacing will be off, but it should look a little better.

I also like most of Random Terrain's suggestions about the character set, the only exception being for "Q." I'm thinking of this instead:



It doesn't look as good with the 3x5 character size, but is still readily recognizable as "Q." It looks better if you have another line or two for lowercase descenders, so the tail of the "Q" can be in the first (highest) descenders' row.

Michael

As it is it takes about 11 scan lines (I think) to convert the 32 characters of text into 80 bytes of graphics data. Adding shifts would time unnecessarily and may reduce the number of scan lines displayable. In this case, if it worked, I'd gladly trade the 512 bytes of character data for the cycles saved.

Scott

[solidcorp]

SeaGtGruff, on Tue Apr 19, 2011 4:17 PM, said:

I also like most of Random Terrain's suggestions about the character set, the only exception being for "Q." I'm thinking of this instead:

Q.png

It doesn't look as good with the 3x5 character size, but is still readily recognizable as "Q." It looks better if you have another line or two for lowercase descenders, so the tail of the "Q" can be in the first (highest) descenders' row.

Michael

I really like it, that's a trouble character, I may use yours thanks.

Scott

[supercat]

solidcorp, on Mon Apr 18, 2011 9:00 AM, said:

Has anyone ever made a 32 character text display on the 2600?

Yes; my 32-character routine works as two groups of sixteen (or, more specifically, two groups of 64 pixels wide, with a 16-pixel gap, at 50% flicker. BTW, I also have a routine to do flickerless three groups of three sprites, and a specialized routine to show "ATARIAGE" at 50% Venetian blinds with 15-pixel-wide characters.