32 character text display

[+Nathan Strum]

EDIT: This is now my number one thing to work on for the next release, since the bug is over a year old. Anyway, I'd like to get all remaining TIA bugs fixed by the end of the summer.

 

There's still this one in Yahtzee (the leftmost die is duplicated):

 

 

I don't have a way to test this on real hardware, however, so I don't know what it's doing there.

[+stephena]

There's still this one in Yahtzee (the leftmost die is duplicated):

 

Yep, I'm guessing it's the same issue. Always good to have another test ROM.

[+SpiceWare]

odd frames are in place, along with the lower case 3x5 letters.

 

They'll work perfectly for what I'm after, though I'll set up the routines to let you select your font size from 3x4 on up.

 

ROM

32x16_20120620.bin

[+Gemintronic]

Seems like a tradeoff. Personally, I'd take the funky every-other-line look of the earlier 32x16.bin than the jitters in the latest binary. The work behind it still boggles the mind, whatever my visual preference

[+SpiceWare]

That could always be under user control.

 

Do you have any polarized sunglasses? Put them on and the jitter goes away. I discovered that back in the 80s. I set up my C= 128 to use interlaced to get 80x50 display, it was great for editing BASIC programs but it flickered even worse than this text display does. One day I came in and glanced at the screen before I took off my sunglasses and was surprised that there wasn't any flicker.

[RevEng]

That's fascinating, and I'll definitely give that a try sometime!

 

I suspect it would only be good with CRTs, given that LCDs have polarising screens built-in...

 

http://www.youtube.com/watch?v=dUA6nyvy-LY

[+SpiceWare]

32x16 using 3x5 font. Full character set shown. Additional characters can be added.

 

32x20 using 3x4 font

 

The datastreams are now generated by the C code(they were hard coded in the prior builds). It first fills in screen memory with the text to display (basically outputs ascii characters 32-127 every 3 rows). It then converts screen memory contents to DPC+ datastreams.

 

To generate these 2 binaries I only had to change a single line in the 6507 code - setting the FONT_HEIGHT constant to 4 or 5. The C code automatically adjusts the number or rows to display.

;----------------------------------------
; FONT_HEIGHT
;	   Selects size of font.  
;	   All are 3 pixels wide with 1 pixel spacing.
;	   All have 1 pixel vertical spacing, so if height is 5 then
;		   6 scanlines will be used per character.
;	   Supported sizes are 4 - 9.  Resulting screen layouts are:
;	   4 = 32x20
;	   5 = 32x16
;	   6 = 32x14
;	   7 = 32x12
;	   8 = 32x11
;	   9 = 32x10
;----------------------------------------
FONT_HEIGHT	 = 4

 

I've only created fonts for sizes 4 and 5. Anybody care to lend a hand and create the font for sizes 6, 7, 8 or 9? The font data is packed to save space, 2 characters are defined at a time. digits 0-3 in the 3x5 font are defined like this:

	.byte zz_XXX__X_	; 0 1
.byte zz_X_X_XX_
.byte zz_X_X__X_
.byte zz_X_X__X_
.byte zz_XXX_XXX

.byte zz_XX__XX_	; 2 3
.byte zz___X___X
.byte zz__X___X_
.byte zz_X_____X
.byte zz_XXX_XX_

 

This is the font definition for the 3x5 characters. You can just modify it and post the new version online. It would probably be good to say which size you're doing so we don't have a duplication of effort.

font3x5.txt

 

ROMs

32x16_20120621.bin

32x20_20120621.bin

Edited June 22, 2012 by SpiceWare

[SeaGtGruff]

I've only created fonts for sizes 4 and 5. Anybody care to lend a hand and create the font for sizes 6, 7, 8 or 9? The font data is packed to save space, 2 characters are defined at a time. digits 0-3 are defined like this:

We don't need to leave a line blank, right, because you're inserting a blank line beteween the rows? So 3x9 means all 9 lines can have pixels lit up? I'll work on the 3x9 font.

[+SpiceWare]

We don't need to leave a line blank, right, because you're inserting a blank line beteween the rows? So 3x9 means all 9 lines can have pixels lit up? I'll work on the 3x9 font.

That is correct. Thanks!

[SeaGtGruff]

This is just a preliminary version; I imagine some of the characters will need to be tweaked. I'm also doing another version where most of the lowercase letters are only 4 tall, so their top lines line up with the middle lines of the capitals-- but then the tops of certain lowercase letters (such as e) don't line up with the others.

font3x9b.txt

[Omegamatrix]

It looks good, but I have trouble distinguishing the capital "G" and "Q". I edited a row in a screenshot. Does this look better? My test is to quickly scan the line left to right to see if I can identify every digit without thinking about it. For some reason the old "Q" stops me every time (and "G" to a lesser extent).

 

 

Edited June 22, 2012 by Omegamatrix

[iesposta]

SpiceWare: Your post on 6-20 runs fine on my Stella, but the builds on 6-21 cause Stella to choke (max out). That's an @ before the capital A, right? What is between the # and %? I set type and it's not apparent. Dollar sign! I just got it... In context that would be no problem.

 

Omegamatrix: G Q

[+stephena]

First of all, please ignore the garbage data at the left of the screen when running in Stella. It has been reported in this thread already, and I know what the problem is (but it will take some time to fix it).

 

Confirmed on the 'choking' issue for the 6-21 builds. It looks like the ARM emulation is working much harder; CPU usage on my system goes from 6% to 22-24%, which is a fairly significant jump considering that it can only go to 50% on my system (one core of a dual-core CPU).

 

Keep in mind that the ARM processor in the Harmony is running at 70MHz, so emulating it will be slow (the CPU in the Atari is 3.58MHz, so emulation is much faster). Also, the ARM emulation isn't optimized at all. I think this is the first ROM to really stress that part of the code.

[Thomas Jentzsch]

... considering that it can only go to 50% on my system (one core of a dual-core CPU).

Maybe time to switch to multi-threading?

[+SpiceWare]

This is just a preliminary version [3x9]

Looks quite nice!

 

32x10 using 3x9 font

 

I edited a row in a screenshot. Does this look better?

I'm not too worried about it as the font will be accessible to change (ie: it's not stored in the C code). I did like the new Q though and it's in place.

 

32x16 using 3x5 font

 

ROMs

32x10_20120622.bin

32x16_20120622.bin

[+SpiceWare]

SpiceWare: Your post on 6-20 runs fine on my Stella, but the builds on 6-21 cause Stella to choke (max out). That's an @ before the capital A, right? What is between the # and %? I set type and it's not apparent. Dollar sign! I just got it... In context that would be no problem.

 

Omegamatrix: G Q

The 6-20 build didn't have any ARM code in it, the display data was pre-rendered by hand. Yes on the @ and $.

 

 

 

Confirmed on the 'choking' issue for the 6-21 builds. It looks like the ARM emulation is working much harder;

I have a 2.8 GHz Core 2 Duo. The 32x## ROMs are running at 55% on 4 threads. I suspect 1 of those threads is the main emulation thread maxed out at 50%. I'll try to improve the performance as this is just the first draft of the code. Another possibility would be to rewrite the routines in ARM assembly instead of C, though I'm not familiar with ARM assembly. Somebody else may be able to help with that once I've posted the source.

 

Frantic is at 25% (just the initial round, don't have time to check later levels right now). I know the later rounds of Frantic cause the Atari to jitter, so it increases ARM usage as the game progresses.

 

Space Rocks is at 22% - likewise, just the initial round.

 

 

 

the CPU in the Atari is 3.58MHz

I thought it was more like 1.19 MHz?

[potatohead]

It is, just a typo I am sure. Bet he boggled up the color burst with the CPU frequency.

[+stephena]

I have a 2.8 GHz Core 2 Duo. The 32x## ROMs are running at 55% on 4 threads. I suspect 1 of those threads is the main emulation thread maxed out at 50%. I'll try to improve the performance as this is just the first draft of the code. Another possibility would be to rewrite the routines in ARM assembly instead of C, though I'm not familiar with ARM assembly. Somebody else may be able to help with that once I've posted the source.

 

Frantic is at 25% (just the initial round, don't have time to check later levels right now). I know the later rounds of Frantic cause the Atari to jitter, so it increases ARM usage as the game progresses.

 

Space Rocks is at 22% - likewise, just the initial round.

 

Due to the graphics library that Stella is using (SDL), the video and main emulation is single-threaded. Sound may be in another thread, but it depends on the OS. As for the way forward, I'd say don't worry for now. Perhaps your code could be made more efficient with assembly vs. C, but I'll bet there are many improvements to be made in the actual ARM emulation too. And going multi-threaded won't really fix that. If the emulation code isn't as efficient as it could be, throwing more cores at it isn't going to fix anything.

 

the CPU in the Atari is 3.58MHz

I thought it was more like 1.19 MHz?

It is, just a typo I am sure. Bet he boggled up the color burst with the CPU frequency.

 

Yes, I'm in the middle of working on the TIA code (to fix the garbage you see on the left of the screen), so I'm thinking of things from that POV. But that only proves my point even more. Normal emulation is ~1Mhz and now we also have to emulate a 70MHz CPU. All other things being equal, CPU usage is definitely going to increase.

[iesposta]

Stephen, thank you for all the work you do on the Stella emulator!

Please don't take my comments the wrong way, as I am using Stella on an unsupported platform (iPad).

Comments of the execution of programs is for the programmer's benefit. Since I'm using such a new, slow unsupported platfom (iOS), programmers may never know something in their code is slowing things down because of the speed of today's machines, so I mention it for their benefit.

[+SpiceWare]

programmers may never know something in their code is slowing things down because of the speed of today's machines, so I mention it for their benefit.

Truthfully, I don't care that much about how it performs in Stella. What I care about is how it performs on an actual Atari.

[GroovyBee]

but I'll bet there are many improvements to be made in the actual ARM emulation too.

 

Just took a look at the source code for the "thumbulator" and it'd need quite a bit of work to get the speed up.

[supercat]

I've been out of 2600 programming for awhile, but would suggest that a useful trick for improving legibility of "flicker-blinds" text is to try to balance out the "even" and "odd" frames. This will work best with text that's either 7 or 11 lines high, so that something like an "E" will have the center line flickering opposite the top and bottom. Also, it can be helpful to design an "E" like:

XXX
X.X
X..
XX.
X..
X.X
XXX

so that the "serifs" balance out the even and odd frames.

[+SpiceWare]

I've been out of 2600 programming for awhile, but would suggest that a useful trick for improving legibility of "flicker-blinds" text is to try to balance out the "even" and "odd" frames.

 

 

I'm using the same set of pixels for both frames. The 3x5 characters are displayed as 3x10.

XXX
XXX
X..
X..
XXX
XXX
X..
X..
XXX
XXX

 

Using your trick would probably look better, but it'll use extra ROM and I'm developing this to use for an easter egg in Space Rocks which is getting tight on space. The large asteroids alone will take up 4.5K to hold the solid and vector images as well as the HMOVE shift tables.

[+stephena]

programmers may never know something in their code is slowing things down because of the speed of today's machines, so I mention it for their benefit.

Truthfully, I don't care that much about how it performs in Stella. What I care about is how it performs on an actual Atari.

 

True, but it would be nice to have Stella perform well too, as a useful basis for testing during development. But before any speedups are even considered, I think it would be more appropriate to work on making the ARM emulation cycle-accurate. That way, if your code was too slow for a real console, you'd see that in Stella right away. This is a separate thing from whether Stella itself is fast enough to run the code.

 

And to anyone that thinks I take offense to reports, please don't. My responses tend to be very direct because that's the way I think. I've been told that I can be too direct sometimes

[+SpiceWare]

True, but it would be nice to have Stella perform well too, as a useful basis for testing during development. But before any speedups are even considered, I think it would be more appropriate to work on making the ARM emulation cycle-accurate. That way, if your code was too slow for a real console, you'd see that in Stella right away. This is a separate thing from whether Stella itself is fast enough to run the code.

That would be nice, though I suspect it'll take a while to implement.