Jump to content
IGNORED

32 character text display


solidcorp

Recommended Posts

The 32 character routines are far enough along for what I needed in Space Rocks, so work on the 32 character routines for general use will resume once Space Rocks is completed.

post-3056-0-59701300-1340819528_thumb.png

 

What I'm planning to do is create a demo like I did for DPC+ where each bank (1-5) will show off a different feature. There won't be a demo in bank 0 because that's where the ARM code and font data are located. You will be able to utilize space in bank 0 for storing text strings and such as the ARM code doesn't have the bank restricts that 6507 code does because the ARM sees the entire cartridge w/out having to do any tricks.

Link to comment
Share on other sites

  • 8 months later...

Has anyone tried doing a gapless Stellar Track kernel like what was being planned for Chimera?

 

 

I like this because it has the full ATASCII character set, therefore it looks like something Atari Inc. would have done.

 

We were planning on having this be both a character or bitmap mode, kind of the standard 1-bit bitmap mode, and another would have been an ARM-driven version of the Suicide Mission kernel. So games could be targeted to these as if they were genuine graphics modes like on a home-computer.

Link to comment
Share on other sites

Has anyone tried doing a gapless Stellar Track kernel like what was being planned for Chimera?

 

I like this because it has the full ATASCII character set, therefore it looks like something Atari Inc. would have done.

 

We were planning on having this be both a character or bitmap mode, kind of the standard 1-bit bitmap mode, and another would have been an ARM-driven version of the Suicide Mission kernel. So games could be targeted to these as if they were genuine graphics modes like on a home-computer.

 

Your video is private.

Personally I love bitmap mode like Suicide Mission. It's so different. I even have an idea for a game if I learn enough.

Scumsoft was the last member working on something like this.

He went missing/silent.

He posted a demo where a bitmap knight can move all around a 92 x 100 something, if I remember correctly using Harmony tricks, planned to go 115 x ? wide.

Link to comment
Share on other sites

Has anyone tried doing a gapless Stellar Track kernel like what was being planned for Chimera?

 

It can be gapless vertically, but not horizontally.

 

The vertical gaps are added in the C code, by line *start++ = 0;, in order to save ROM space in the FONT data.

 

    for(x=0;x<32;x += 2)
   {
       start = &TEXT_COLUMN[(x>>1) * TEXT_COLUMN_HEIGHT];

       for(y=0;y<gRowCount;y++)
       {
           char_l = TEXT_SCREEN_MEMORY[y*32+x];
           char_r = TEXT_SCREEN_MEMORY[y*32+x+1];

           shift_l = (char_l & 1) ? 4 : 0;
           shift_r = (char_r & 1) ? 0 : 4;

           char_l >>= 1;
           char_r >>= 1;

           start_char_l = flashdata + FONT_LOCATION + char_l * FONT_HEIGHT;
           start_char_r = flashdata + FONT_LOCATION + char_r * FONT_HEIGHT;

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

           *start++ = 0;
       }
   }  

 

Remove that line and the vertical gap goes away, though you'll want to change the font data from 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

 

to 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________

 

and increase the constant FONT_HEIGHT by 1.

 

The horizontal gaps are also added in C code, by the 0x70 & and 0x07 &, but they are added due to this timing issue in the kernel:

post-3056-0-86379100-1362931473_thumb.png

 

The datastream is compensated for the issue by this bit of C code:

    // compensate for sprites 11, 13 and 15 being off by 1 pixel
   start           = &TEXT_COLUMN[TEXT_COLUMN_HEIGHT*11];
   start_char_l    = &TEXT_COLUMN[TEXT_COLUMN_HEIGHT*13];
   start_char_r    = &TEXT_COLUMN[TEXT_COLUMN_HEIGHT*15];

   for(i=0;i<TEXT_COLUMN_HEIGHT;i++)
   {
       *start++ <<= 1;
       *start_char_l++ <<= 1;
       *start_char_r++ <<= 1;
   }

  • Like 2
Link to comment
Share on other sites

I remember it was tricky getting the gapless Stellar Track kernel to work but I have old threads on my blog documenting the process and the help I received. Stellar Track requires gaps between characters and processing time between rows but the kernel in my demo doesn't require either. The way it spools data out via hotspots is, based on what I've read, not that different from how Harmony works. So it seems in theory this sort of kernel would work on Harmony, but it sounds like nobody's tried doing it yet. Not to disparage what this other kernel does, of course. In my demo it really was like a true text mode and you could print to it. I was talking to Chimera through a serial port and every character I typed in Hyperterminal on my PC got printed onto the screen. There is a perception of gaps betwen characters in my demo by virtue of the flicker, but it's not really there. If you used it like a bitmap mode then you'd have sort of a column-like artefact due to the flicker. I always wanted to see how something like that might look with something other than text. There are, of course, many strategies for packing as many bits onto a line as possible.

Link to comment
Share on other sites

Yeah, the DPC+ kernel for this is a loop that reads in bitmap data for the whole screen. If sprite positions 11, 13 and 15 could be corrected then the kernel could be used to draw a 128x100 bitmapped image.

 

I have 2 main ARM routines that are called to update the text. Print() and RenderScreen().

 

Print() accepts a string and updates TEXT_SCREEN_MEMORY with the characters to disply.

 

RenderScreen() takes the contents of TEXT_SCREEN_MEMORY and converts it to bitmapped data that the kernel reads in. The snippet of code above with for(x=0;x<32;x += 2) is the main section of RenderScreen().

 

In Space Rocks I call PrintChar(), instead of Print() as I'm simulating 300 baud speeds, in Overscan and RenderScreen() in Vertical Blank.

http://youtu.be/FjNSrskWngM

Edited by SpiceWare
Link to comment
Share on other sites

  • 2 years later...

Pretty cool, eh? cd-w figured it out.

The last I saw this capture from Stella, there was not the duplicate error on the left. No one answered if it was a fix in Stella or a fix in the display routine.

 

I would guess a fix in Stella because we program for real hardware?

Link to comment
Share on other sites

When I ran a BBS from an Atari 800XL I had written a text adventure you could play on the BBS like a super-simple Zork.

I remember putting a lot of time into it.

There is a small chance I still have it, but last time I went through my floppies I didn't see it.

 

That would be kind of cool to do another text adventure using the 32 character display.

I know it's been done with Sears original Stellar Track, and its hack into Dark Mage, still...

And just yesterday I started to build up another RetroPie, and it installs with Zork I, II, & III as a default, and I played a bit of Zork I.

Link to comment
Share on other sites

My understanding is, this is still the 32 char routine, except that there are no gaps? So you can draw 128 pixels now.

Yep! cd-w figured it out:

 

; The sprites are positioned:
; |_0_0_0_1___10_010_
; |0_0_0_1_101X_0___0

; NOTES:
; 1) The left 2 copies of P0 are junk - they dont show on real hardware,
; but in Stella they are displayed. I'm using a PF mask to cover them up.
; 2) The X position is an extra copy of sprite 0 that needs to be masked by
; the ball. It isn't possible to modify NUSIZ0 early enough to prevent this
; copy showing.
; 3) The multi-RESP0 trick is used to create the second copy of P0 - it is
; performed at cycles 39/45 and 47/53 to avoid any gaps.

try changing both difficulty switches

128_20160215.bin

 

I do see a minor glitch from when I implemented even/odd frames. The first 2 characters are missing the topmost scanline. I plan to replace the "stairs", used for confirming GRP0 and GRP1 updates are correct, with a line drawing demo. I'll post the source when that's done.

Link to comment
Share on other sites

My understanding is, this is still the 32 char routine, except that there are no gaps? So you can draw 128 pixels now.

Yep! cd-w figured it out:

 

; The sprites are positioned:
; |_0_0_0_1___10_010_
; |0_0_0_1_101X_0___0

; NOTES:
; 1) The left 2 copies of P0 are junk - they dont show on real hardware,
; but in Stella they are displayed. I'm using a PF mask to cover them up.
; 2) The X position is an extra copy of sprite 0 that needs to be masked by
; the ball. It isn't possible to modify NUSIZ0 early enough to prevent this
; copy showing.
; 3) The multi-RESP0 trick is used to create the second copy of P0 - it is
; performed at cycles 39/45 and 47/53 to avoid any gaps.

Is there a bin for this? I'd like to see it on CRT and LCD tvs.


I'm not quite ready to release it, but here it is anyway :) Try out both difficulty switches

128_20160215.bin

 

I just noticed a minor glitch from when I implemented even/odd frames. The first 2 characters are missing the topmost scanline. I plan to replace the "stairs" test pattern, used for confirming GRP0 and GRP1 updates are correct, with a line drawing demo. I'll post the source when that's done.

  • Like 5
Link to comment
Share on other sites

Questions:

 

Did CD-W do this with or without DPC+? It just says without bus stuffing.

 

I know Spice did his with DPC+. Does DPC+ let you update NUSIZ0 early enough so as not to need the Ball as a masking object?

 

Would Bus Stuffing let you update NUSIZ0 early enough?

 

Is a blank scan line still required between rows?

Link to comment
Share on other sites

Questions:

Did CD-W do this with or without DPC+? It just says without bus stuffing.

I know Spice did his with DPC+. Does DPC+ let you update NUSIZ0 early enough so as not to need the Ball as a masking object?

Would Bus Stuffing let you update NUSIZ0 early enough?

Is a blank scan line still required between rows?

My kernel requires DPC+ also - it is very similar to the previous approach, I just reorganised things a bit to avoid the vertical gaps.

 

Bus stuffing should allow the ball to be removed, and the lines to be individually coloured.

 

The blank line between rows is artificial - there is no need for any horizontal or vertical gaps.

 

Chris

Edited by cd-w
Link to comment
Share on other sites

Amazing!

I wish more 'retrogamers' actually understood what is accomplished here.

The old 2600 has two 8-bit registers to draw its player 'sprites'.

Simply two places to put eight ones and/or zeroes: 11111111 10101010

 

Here you take that space for just 16 on or off dots, and turn them into rows of 128 dots that change both across the display, and change down the display. Most of it done with just assembly programming precise timing.

All on 1970's hardware technology.

Link to comment
Share on other sites

Indeed it is quite an accomplishment. This is truly inspiring.

 

Have you thought about trying to extend it to the full 160 pixel width? My experiments with bus-stuffing in stella seem to indicate that it's possible, but perhaps this technique can accomplish it with only DCP+.

 

Looking forward to the line drawing demo. Thanks for sharing!

Link to comment
Share on other sites

Very cool !!!

 

attachicon.gifIMG_0721.JPG

 

( This is PAL60. There seems to be another small glitch. I think I've seen this before while doing interlace experiments. There may be something wrong with the vsync/vblank/overscan timing, but it likely will only show on PAL systems. )

What kind of glitch are you seeing on PAL - is the screen rolling or is it the weird coloring at the top of the screen?

 

Chris

Edited by cd-w
Link to comment
Share on other sites

Here you take that space for just 16 on or off dots, and turn them into rows of 128 dots that change both across the display, and change down the display. Most of it done with just assembly programming precise timing.

To be fair we should speak about 2x64 dots (which made the task even more complex).
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...