SeaGtGruff Posted June 23, 2012 Share Posted June 23, 2012 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. 1 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 23, 2012 Share Posted June 23, 2012 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 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 23, 2012 Share Posted June 23, 2012 (edited) 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 23, 2012 Share Posted June 23, 2012 Here's 3x7 and 3x8. They're based on SeaGtGruff's 3x9 font for consistency, with some compromises. font3x8.txt font3x7.txt Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 23, 2012 Share Posted June 23, 2012 ...and 3x6 font3x6.txt Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 23, 2012 Share Posted June 23, 2012 Thanks! 32x11 using 3x8 font 32x12 using 3x7 font ROMs 32x11.bin 32x12.bin Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 23, 2012 Share Posted June 23, 2012 here's photos of the 3x5 and 3x4 fonts using that camera app. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 23, 2012 Share Posted June 23, 2012 ...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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 23, 2012 Share Posted June 23, 2012 Here's the fixed files... font3x7.txt font3x6.txt Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 23, 2012 Share Posted June 23, 2012 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 23, 2012 Share Posted June 23, 2012 Gah... looks like the gaffe in 3x7 propagated to 3x6. Third time is the charm? font3x6.txt Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 24, 2012 Share Posted June 24, 2012 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 1 Quote Link to comment Share on other sites More sharing options...
Pioneer4x4 Posted June 24, 2012 Share Posted June 24, 2012 That looks really good, but are you burning an entire row of pixels just for 3 characters with descenders? Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted June 24, 2012 Share Posted June 24, 2012 If you publish the ARM "C" code I can take a look at optimising it when I get some time. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 24, 2012 Share Posted June 24, 2012 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. Quote Link to comment Share on other sites More sharing options...
+stephena Posted June 24, 2012 Share Posted June 24, 2012 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. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 24, 2012 Share Posted June 24, 2012 Have fun! Quote Link to comment Share on other sites More sharing options...
+Nathan Strum Posted June 24, 2012 Share Posted June 24, 2012 Have a great time! Quote Link to comment Share on other sites More sharing options...
Pioneer4x4 Posted June 24, 2012 Share Posted June 24, 2012 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!) Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 24, 2012 Share Posted June 24, 2012 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 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 26, 2012 Share Posted June 26, 2012 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 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted June 26, 2012 Share Posted June 26, 2012 The best optimisations I can come up with require aligned data and a fixed font height. Is that going to be a problem? Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 26, 2012 Share Posted June 26, 2012 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? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted June 26, 2012 Share Posted June 26, 2012 (edited) 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: 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. Display Kernel - 6507 draws the screen by reading the graphics data. 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 Vertical Blank - call RenderScreen() Display Kernel - 6507 draws screen OverScan - 6507 game logic section A [*]Odd Frame Vertical Blank - 6507 game logic section B Display kernel - 6507 draws screen OverScan = 6507 game logic section C Edited June 26, 2012 by SpiceWare Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted June 26, 2012 Share Posted June 26, 2012 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 . 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.