32 character text display

[SeaGtGruff]

This is just a preliminary version [3x9]

Looks quite nice!

I kind of rushed it because I wanted to see what it looked like before tweaking it. For the most part I just made the 3x5 font taller, but did change some of the characters a bit to take advantage of the increased lines-- such as the "a," "&," and "@." I think the parentheses need to be more rounded, and maybe the letters with bars ("t" and "f") need to have the bars raised up a line so they'll match the tops of the other lowercase letters. And the "m" might look better with a gap in the top row. I'll post an updated version later tonight.

[SeaGtGruff]

This version has a few minor tweaks-- the parentheses and curly brackets are more rounded, the bars in the t and f are a line higher, and the m has a gap in the top row so it looks like an upside-down w. Not sure if some of these will look better or worse.

font3x9b.txt

[+SpiceWare]

Looks good.

 

 

I used the Cortex Camera app to take that photo. It cleans up the interlace fading that was visible in the prior images.

 

Anybody going to step up and create the 3x6, 3x7 or 3x8 fonts?

 

ROM

32x10b.bin

Edited June 23, 2012 by SpiceWare

[RevEng]

Here's 3x7 and 3x8. They're based on SeaGtGruff's 3x9 font for consistency, with some compromises.

 

font3x8.txt

font3x7.txt

[RevEng]

...and 3x6

 

font3x6.txt

[+SpiceWare]

Thanks!

 

32x11 using 3x8 font

 

32x12 using 3x7 font

 

ROMs

32x11.bin

32x12.bin

[+SpiceWare]

here's photos of the 3x5 and 3x4 fonts using that camera app.

 

 

[+SpiceWare]

...and 3x6

Thanks! There's a misalignment starting at lowercase d & e.

 

Just noticed the 3x7 font has it as well starting at the lowercase r & s.

[RevEng]

Here's the fixed files...

 

font3x7.txt

font3x6.txt

[+SpiceWare]

3x6 now has the shift at r & s.

 

3x7 looks good!

32x12b.bin

 

 

Hmm, I think for the easter egg I'll use 3x6. The additional pixel for descender use makes it more legible over 3x5.

[RevEng]

Gah... looks like the gaffe in 3x7 propagated to 3x6.

 

Third time is the charm?

 

font3x6.txt

[+SpiceWare]

Better!

 

For some reason, this font size made the display shift down on my C= 1084S. I popped it into my 7800 on an old TV and it scrolled like crazy. My 1084S is more forgiving on scanline counts, I can play PAL games w/out any problem on it.

 

I made a change so that the first 4 characters are time remaining for Vertical Blank and OverScan. In Stella the ARM emulation does not count cycles, so it runs in "0 cycles" as far as the 6507 is concerned.

 

1D = INTIM for Vertical Blank

17 = INTIM for Overscan.

 

When I run it on the Atari, I got 97 for VB - the time remaining should be less than what Stella shows, if it's more then we ran out of time as the timer wrapped past 0.

 

I did some optimizations and it came back with 2F for VB, so I suspect the 97 from before means it wrapped past 0 more than once.

 

I then turned back on the cache. While working on other projects it was discovered that there's a fatal bug in the ARM chip in the Harmony. It'll crash if the alignment of code and data is just so. To fix it you can either rearrange your code, or you can disable cache and take a performance penalty. For the other projects rearranging the code proved to be an exercise in frustration because there was so much code to worry about. For this, there's just a few routines, so I decided it would be worth the hassle for now to get the speed boost back.

 

With cache turned back on, VB now comes back with 01 so it looks like we're just under the time for displaying the screen.

 

32x14d.bin

[Pioneer4x4]

That looks really good, but are you burning an entire row of pixels just for 3 characters with descenders?

[GroovyBee]

If you publish the ARM "C" code I can take a look at optimising it when I get some time.

[+SpiceWare]

That looks really good, but are you burning an entire row of pixels just for 3 characters with descenders?

The following have descenders:

$ , ; Q g j p q y

 

If you publish the ARM "C" code I can take a look at optimising it when I get some time.

I'll post the source with the next demo.

[+stephena]

Just wanted to let everyone (that's interested) know: I'm about to go on vacation for 2 weeks or so, after which I'll start working on a fix for the garbage on the left of the snapshots above.

[+SpiceWare]

Have fun!

[+Nathan Strum]

Have a great time!

[Pioneer4x4]

 

The following have descenders:

$ , ; Q g j p q y

 

I neve noticed that $ went below, and probably isn't needed as well as Q depending on the font. and the punctuation doesn't count to me

as for g j p q y, basically I can't count. (I forgot g & y!)

[+SpiceWare]

I've done some optimizations and was able to get VB time to 07!

 

I then disabled the cache and there's still 05 time left in VB. So we're good to go with cache disabled so we don't have to worry about that ARM bug crashing our programs.

 

The optimizations were done in function RenderScreen(). Main thing I did was change from using arrays to using pointers

 

Time critical section of original code:

 

for(i=0;i<FONT_HEIGHT;i++)

TEXT_COLUMN[start + i] = (0x70 & (FONT[char_l+i] << shift_l)) + (0x07 & (FONT[char_r+i] >> shift_r));

 

 

revised code using pointers:

 

for(i=0;i<FONT_HEIGHT;i++)

*start++ = (0x70 & (*start_char_l++ << shift_l)) + (0x07 & (*start_char_r++ >> shift_r));

 

Original routines are commented out in this source. They're no longer in my current source.

 

Source

32_20120624.zip

[+SpiceWare]

Started building the C routines for updating the screen memory. My test routine prints a single character each frame. It kind of looks like calling a BBS.

 

ASCII characters 0-31 do not display a visible characters, so when the ASCII values are dropped into screen memory 32 is subtracted from them. This way the font definition table doesn't have to waste space defining graphics for positions 0-31.

 

This functions prints a single character:

void PrintChar(char text)
{
int pos;

if (text < '\n')				// chr$(x) where x=1-9 will move cursor right x positions
{
	gCurrentChar += text;
}
else if (text == '\n')		  // chr$(10)
{
	pos = gCurrentChar - TEXT_SCREEN_MEMORY;
	pos += 32;	  // advances to next line
	pos &= 0xFFE0;  // sets to 0 for X
	gCurrentChar = &TEXT_SCREEN_MEMORY[pos];		
}
else
	*gCurrentChar++ = text-32;

if (gCurrentChar >= gMaxCharacter)
{
	ShiftScreenUp();
	gCurrentChar -= 32;
}
}

 

Chr$(10) is ASCII character 10. At the moment I'm using it to start a new line of text. I'm treating anything from 1-9 as cursor right, where 1 would be a single cursor right and 9 would be 9 cursor rights. This is a minor way to compress data in my easter egg where I plan to center the text.

 

 

This is the function that prints a string of text:

void Print(char *text)
{
while (*text != 0)
{
	PrintChar(text[0]);
	text++;
}	
}

 

There are some other functions in the source (such as NewLineThenPrint) that I've been toying with that will probably go away. What I plan to provide for the 6507 code are the following functions:

• PRINT_CHAR - prints a single character. Special characters below chr$(32) will be used for:
  
  • cursor control (left/right/up/down)
    
  • clear-screen
    
  • control cursor (cursor on/off, blink on/off)
    
  • other?
    

  [*]PRINT_TEXT - prints a string of text. String is NULL terminated. (NULL = chr$(0))

  [*]POSITION_CURSOR - sets X-Y position of the cursor

  [*]READ_X_Y - returns the ASCII character at position X-Y

After any of the above you'll be able to easily read the current x-y position of the cursor.

 

 

ROM

32_20120625.bin

 

Source

32_20120625.zip

[GroovyBee]

The best optimisations I can come up with require aligned data and a fixed font height. Is that going to be a problem?

[+Gemintronic]

Could the ARM have it's own frame buffer and simply slave the 2600 to *just* spit out the screen and deal with joystick input and sound?

[+SpiceWare]

The best optimisations I can come up with require aligned data and a fixed font height. Is that going to be a problem?

aligned data isn't a problem. Unless I'm misunderstanding you, fixed font heights would defeat one of my goals - letting the programmer make the decision on character size/legibility vs number of rows of text. That way somebody making a game like NetHack could use 3x4 letters in order to get a 20 row display, while somebody else(like me) could use 3x6 letters for the increased legibility.

 

 

Could the ARM have it's own frame buffer and simply slave the 2600 to *just* spit out the screen and deal with joystick input and sound?

This is how I'm setting it up:

1. Vertical Blank - the ARM function RenderScreen() is called. RenderScreen() converts the text stored in Screen Memory to the graphics data that's ready for the Display Kernel.
   
2. Display Kernel - 6507 draws the screen by reading the graphics data.
   
3. Over Scan - 6507 does the game logic. Read the input controllers, update player actions, update sound effects, call ARM functions like Print() and PrintChar() to update Screen Memory, etc.
   

If you need more processing time then just render the screen every other frame:

• 
   
  
• Even Frame
  1. Vertical Blank - call RenderScreen()
     
  2. Display Kernel - 6507 draws screen
     
  3. OverScan - 6507 game logic section A

  [*]Odd Frame

  1. Vertical Blank - 6507 game logic section B
     
  2. Display kernel - 6507 draws screen
     
  3. OverScan = 6507 game logic section C

Edited June 26, 2012 by SpiceWare

[GroovyBee]

aligned data isn't a problem. Unless I'm misunderstanding you, fixed font heights would defeat one of my goals - letting the programmer make the decision on character size/legibility vs number of rows of text. That way somebody making a game like NetHack could use 3x4 letters in order to get a 20 row display, while somebody else(like me) could use 3x6 letters for the increased legibility.

 

Thanks for the clarification. The best way forward is for me to get a Harmony at some point and then give you back the THUMB coded version that has been debugged and tested. Getting a Harmony might also encourage me to do some 2600 stuff down the road .