32 character text display

[solidcorp]

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.

 

Cool, I knew someone must have been down this road and I'd find them here.

 

I really don't like the flickering as opposed to venetian blinds, I think Stella is very generous with the phosphor setting as compared to what you see on a TV (my TVs anyway).

 

How are you doing flickerless three groups of three sprites?

(If you hit RESPx more than once on a scan line in triple player mode, it resets the hardware after the first sprite displays so you just see a space, sprite, space, sprite.)

[supercat]

I really don't like the flickering as opposed to venetian blinds, I think Stella is very generous with the phosphor setting as compared to what you see on a TV (my TVs anyway).

 

On CRT-based screens, flicker-blinds are better than column-based flicker. On some LCD screens, flicker-blinds come out really ugly and column-based flicker is decidedly better.

 

How are you doing flickerless three groups of three sprites? (If you hit RESPx more than once on a scan line in triple player mode, it resets the hardware after the first sprite displays so you just see a space, sprite, space, sprite.)

 

One of the sprites was set to show three copies (of which two actually appear on screen) and the other two copies (of which one appears). Hitting RESPx on both sprites in the proper order when they're properly configured will cause one sprite to appear between the copies of the other two. There will be one column of overlap and one blank column, but such is life.

[ScumSoft]

I'm sure the method I use has been done before, but I'm not sure what it would be called.

My kernal moves 6 columns of P0,P0,P0,P1,P1,P1 each 8 pixels apart back and forth between 2 frames, this way I can load unique graphics in each and it gives a 96x192 playfield where I can set each pixel if desired. It's not flicker blinds or the venetian blinds trick. The kernal is posted in the DPC+ programming thread if you want to see it.

 

It could also do 32 characters, but not all in one frame. So 16 per frame across two frames at 50% flicker.

Edited May 2, 2011 by ScumSoft

[eshu]

I'm sure the method I use has been done before, but I'm not sure what it would be called.

My kernal moves 6 columns of P0,P0,P0,P1,P1,P1 each 8 pixels apart back and forth between 2 frames, this way I can load unique graphics in each and it gives a 96x192 playfield where I can set each pixel if desired. It's not flicker blinds or the venetian blinds trick. The kernal is posted in the DPC+ programming thread if you want to see it.

 

It could also do 32 characters, but not all in one frame. So 16 per frame across two frames at 50% flicker.

 

Yours would be a 24 char display (96=24*4) - when I was thinking about your dpc+ bitmap kernel it got me thinking about this comment:

 

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.

 

This would make me think it could be possible to do a dpc+ kernel with 134/135*192 resolution. Since I assume solidcorp isn't using anything like dpc+ the cycles saved from immediate loads plus a few other tricks should hopefully give you time to play with the missiles and ball etc to fill the 3/4 pixel gap per frame.

[SeaGtGruff]

I'm sure the method I use has been done before, but I'm not sure what it would be called.

My kernal moves 6 columns of P0,P0,P0,P1,P1,P1 each 8 pixels apart back and forth between 2 frames,

I believe this is what supercat referred to as "column-based flicker," because each frame has a distinct set of six columns, and you shift them back and forth from frame to frame so the columns of one frame fill up the gaps between the columns of the previous frame. That's how I did it in "E.T. Book Cart," at least partly because it was easier for me to position the columns as needed at the beginning of each frame (versus shifting back and forth from line to line, which in a "normal" cycle 3 HMOVE is limited to 8 color clocks right and 7 color clocks left). The flicker looks bad on most CRT-type TVs, but as supercat said, it looks really good on some LCD TVs (it looks great on mine).

 

Michael

 

Edit -- Except I used a P0 P1 P0 P1 P0 P1 arrangement, not a P0 P0 P0 P1 P1 P1 arrangement.

Edited May 3, 2011 by SeaGtGruff

[solidcorp]

Many of the RESPx strobe techniques suffer because sooner or later you end up needing to write to a RESPx on the same cycle that you need to write to a GRPx register.

 

Also, like supercat said, since the CPU runs one cycle for every 3 color clocks and the quickest you can write to RESP values is in 3 cycles or 9 pixels (without using BRK or JSR tricks which require the stack pointer get reset) single pixel gaps or overlaps are all but unavoidable. Such is life.

 

There is still a lot of time in the lines of my kernel to do more interesting things like set colors or adjust the playfield but remember that the missiles inherit their NUSIZ from their player and are trippled just like the players if that is enabled. It also takes more code to enable and disable the missiles and the ball. Due to timing and the trippling I abandoned trying to fill the center with one more column of missile/ball text.

 

I don't use DPC in this kernel, though I have nothing opposed to "illegal opcodes". I use macros to display the venetian blinds of 5 lines without loops (2 different synchronized routines used on alternate frames). For timing I also absolutely had to use vertical delay and I used the stack pointer as a byte register (TXS,TSX) to recover a byte in 2 cycles instead of reading from zero page which would have taken 3 cycles at a critical moment later in the scan line.

 

Can any of you post links to your screnshots or relative posts?

 

Scott

[eshu]

Many of the RESPx strobe techniques suffer because sooner or later you end up needing to write to a RESPx on the same cycle that you need to write to a GRPx register.

 

Also, like supercat said, since the CPU runs one cycle for every 3 color clocks and the quickest you can write to RESP values is in 3 cycles or 9 pixels (without using BRK or JSR tricks which require the stack pointer get reset) single pixel gaps or overlaps are all but unavoidable. Such is life.

 

There is still a lot of time in the lines of my kernel to do more interesting things like set colors or adjust the playfield but remember that the missiles inherit their NUSIZ from their player and are trippled just like the players if that is enabled. It also takes more code to enable and disable the missiles and the ball. Due to timing and the trippling I abandoned trying to fill the center with one more column of missile/ball text.

 

I don't use DPC in this kernel, though I have nothing opposed to "illegal opcodes". I use macros to display the venetian blinds of 5 lines without loops (2 different synchronized routines used on alternate frames). For timing I also absolutely had to use vertical delay and I used the stack pointer as a byte register (TXS,TSX) to recover a byte in 2 cycles instead of reading from zero page which would have taken 3 cycles at a critical moment later in the scan line.

 

Can any of you post links to your screenshots or relative posts?

 

Scott

 

I really haven't looked at this in great detail - I thought it might be worth looking into for ScumSoft since he's doing a dpc+bitmap kernel. I would have to sit down with pen and paper to look at the possibilities - I presume you're hitting respx once for each player? I just thought something might be possible with the cycle savings from dpc+, I was hoping you where using a loop though for a few more cycles saved to be honest though

 

I presume your using zero page loads for the data, so that would be one cycle saved per load for 8 cycles. He could also lose txs,tsx since you can just load immediate, for 4 more cycles. Doing the ball is a no brainer lda #,sta enabl could be done at any point to use 5 cycles. Hopefully we could keep that data in the accumulator and ror, sta enamx at the appropriate point for 4 more cycles. We'd have to use the 1st or 4th copy of the missile only and disable or have disabled the missile before the 2nd or 1st copy appears. I hadn't been thinking about using all the registers since i didn't realise this was needed when the copies were 8 pixels apart, I guess that's an artifact of having to hit respx at the right point? So I was hoping Y say could be kept with the d1 bit set to 0. So just sty enamx at any point. That would just squeeze into the cycles saved but I thought there might have been a few more available. I guess it's possible to shave off quite few cycles by not using venetian blinds?

 

I may try and knock something up - any hints to the respx timing I've always been a bit confused by where the extra copies appear, I presume you have to hit at some point between the first and second copies, instinct would be to hit it at exactly the start of the second copy, but I'm not sure that's right?

 

Edit: Didn't remember respx trick right, I have to hit it three times between changing grpx right?

Edited May 3, 2011 by eshu

[solidcorp]

On CRT-based screens, flicker-blinds are better than column-based flicker. On some LCD screens, flicker-blinds come out really ugly and column-based flicker is decidedly better.

 

Call me a purist, but I like using the 2600 unmodified with same technology that was available in its heyday (the 70's and 80's).

 

That means a CRT TV, I never had my 2600 connected to an LCD TV as a kid and I'm not going to start now!

 

Scott

[solidcorp]

 

I really haven't looked at this in great detail - I thought it might be worth looking into for ScumSoft since he's doing a dpc+bitmap kernel. I would have to sit down with pen and paper to look at the possibilities - I presume you're hitting respx once for each player? I just thought something might be possible with the cycle savings from dpc+, I was hoping you where using a loop though for a few more cycles saved to be honest though

 

The players are set to tripple close mode. I hit RESP0 and RESP1 four times each per line, but each time you hit them within a scan line it seems to restart the scanning at the start of the first space, so you get two copies of the player that look like[space][player][space][player]. The arrangement of player 0 and player 1 is critical since you have to load graphics and strobe the resets at very particular times that in most configurations will either overlap meaning that you need to write a RESPx and a GRPx register in the same cycle, or they are so close together that you can't fetch data fast enough. It takes 18 pixels to load and store one byte from zero page:

lda zp ; 3 cycles, 9 pixels

sta zp ; 3 cycles, 9 pixels

 

I presume your using zero page loads for the data, so that would be one cycle saved per load for 8 cycles. He could also lose txs,tsx since you can just load immediate, for 4 more cycles.

 

Immediate can only work for constant data, not characters that change every line.

 

Doing the ball is a no brainer lda #,sta enabl could be done at any point to use 5 cycles. Hopefully we could keep that data in the accumulator and ror, sta enamx at the appropriate point for 4 more cycles. We'd have to use the 1st or 4th copy of the missile only and disable or have disabled the missile before the 2nd or 1st copy appears.

 

The vertical delay and all the registers including the stack pointer must be used to attain the timing needed for venetian blinds. Data is loaded into the delay registers of P0, P1, and the display of P0, data is also loaded into SP,A,X, and Y, then the first store to RESP0, then it's a race to load and store all the register to position and write the pixels of the 8 bytes of sprites on that single height scan line.

 

I hadn't been thinking about using all the registers since i didn't realise this was needed when the copies were 8 pixels apart, I guess that's an artifact of having to hit respx at the right point? So I was hoping Y say could be kept with the d1 bit set to 0. So just sty enamx at any point. That would just squeeze into the cycles saved but I thought there might have been a few more available.

 

Remember that the players are set to triple single width mode and the missiles will be too. You can have different settings for both, otherwise, there are plenty of cycles for setting ball/missile and even playfield graphics.

 

I guess it's possible to shave off quite few cycles by not using venetian blinds?

 

Yes, venetian blinds take more cycles and are harder because you need to reset the graphics registers more frequently and have to use a single scan line kernel.

 

I may try and knock something up - any hints to the respx timing I've always been a bit confused by where the extra copies appear, I presume you have to hit at some point between the first and second copies, instinct would be to hit it at exactly the start of the second copy, but I'm not sure that's right?

 

Yes, like I said, when in triple player mode and you write RESPx more than once a scan line, it appears that the player graphics will appear 8 pixels to the current pixel location at the end of the sta instruction, and it will only show two copies. Set up a test case and play with it in Stella, use the debugger to tweak values or set up many scan line experiments at one time to view results.

 

Edit: Didn't remember respx trick right, I have to hit it three times between changing grpx right?

[eshu]

I couldn't resist having a crack at this after some experiments. This is untested on real hardware but I'm hopeful it will work...It's a bit rough and ready at the moment, I'll clean it up and post the code in the next few days....

 

Screenshot is with phosphor effect enabled in stella:

 

36char.bin

[dwane413]

I couldn't resist having a crack at this after some experiments. This is untested on real hardware but I'm hopeful it will work...It's a bit rough and ready at the moment, I'll clean it up and post the code in the next few days....

 

Screenshot is with phosphor effect enabled in stella:

 

 

I'm sorry, but it doesn't seem to work right on my 6 switch Sears Video Arcade and Harmony cart.

[ScumSoft]

I get the same problem on mine as well. (light sixer)+Harmony

[SeaGtGruff]

I get the same problem on mine as well. (light sixer)+Harmony

So what he's got is still good for a 32-character display.

 

Michael

[eshu]

I'm sorry, but it doesn't seem to work right on my 6 switch Sears Video Arcade and Harmony cart.

 

Ah, it's a shame - looks like I've found a spot where stella get's it slightly wrong.....It's a bit hard to tell from the picture, ignoring the first four characters are there any other problems?

[ScumSoft]

Everything other than that looks right.

[dwane413]

It's a bit hard to tell from the picture, ignoring the first four characters are there any other problems?

Like ScumSoft said, everything else is fine.

[+Random Terrain]

Keep plucking that chicken. It's nice that you guys are working together on the best looking, most readable, most amazing text display that will eventually help all Atari 2600 assembly language programmers and maybe even batari Basic users.

[eshu]

Here's a quick test before I clean it up - this should be 32 characters well spaced and in the centre of the screen:

 

 

If someone could confirm it's working right on real hardware I would appreciate it...

32charnew.bin

[dwane413]

If someone could confirm it's working right on real hardware I would appreciate it...

Yes, it works. Looks nice.

[+Random Terrain]

Here's a quick test before I clean it up - this should be 32 characters well spaced and in the centre of the screen:

I see that you're trying to square off some of the letters, including the B. Problem is that it looks like a fancy E. Below is an image with three rows of letters. The first row is yours, the second row is every letter possible squared off, then the third row is just about every letter rounded off (except for the U). To my eyes, the third row is the most readable without much need to slow down and decipher anything. I kind of like your squared off J a little better than the rounded off one (something I and every other dork with an 8-bit computer has drawn before), but for my eyes, your S is a little too fancy. The traditional S (shown in the third row) is easier for me to recognize without even a fraction of a second of extra mental conversion time.

 

[cd-w]

Here's a quick test before I clean it up - this should be 32 characters well spaced and in the centre of the screen.

 

Very nice work. It looks like you are hitting RESP0 three times per scanline: once to position on the left, and then twice to get a further two (x3) copies on the right?

 

Chris

[eshu]

Here's a quick test before I clean it up - this should be 32 characters well spaced and in the centre of the screen.

 

Very nice work. It looks like you are hitting RESP0 three times per scanline: once to position on the left, and then twice to get a further two (x3) copies on the right?

 

Chris

 

Yes pretty much, The first RESP0 is hit at the very end of the scanline (cycle 76/0), which allows me to use HMOVE to adjust it's position before it appears (I don't think I've seen this done with the RESPx trick before) - I realise If I hit the final one a bit later I should be able to get extra copies, I think the timing is too tight to use them as I need to HMOVE and strobe RESP0 around the end of a scanline so it's quite busy. I need to look at it properly but wanted to nail 32 chars first.

 

Incidentally stella was allowing me extra copies by hitting RESP0 on cycle 76/0 since it was generating a start signal when they appear on the next scanline showing all 3 copies - this doesn't seem to happen on real hardware - I need to double check it doesn't happen with say a cycle 75 strobe, but I think it's unlikely.

 

Edit: There you go RT, changed the font for you

32charnew2.bin

Edited May 16, 2011 by eshu

[dwane413]

Here's another pic so you can see how it looks on real hardware. I think it looks great. (NOTE: I've mentioned this in another thread or two, but the RGB colors on my tv are not aligned.)

 

This is a more accurate picture than the one I posted last night. I discovered today that my DVD recorder (Presidian PDR-3222) was changing the way it looks. I guess you could say that it was sort of undoing the phosphor effect.

 

I just noticed you posted a new message. I haven't checked it out yet.

[eshu]

Here's another pic so you can see how it looks on real hardware. I think it looks great. (NOTE: I've mentioned this in another thread or two, but the RGB colors on my tv are not aligned.)

 

This is a more accurate picture than the one I posted last night. I discovered today that my DVD recorder (Presidian PDR-3222) was changing the way it looks. I guess you could say that it was sort of undoing the phosphor effect.

 

I just noticed you posted a new message. I haven't checked it out yet.

 

Thanks dwane I really appreciate it - I do actually have a 2600 and harmony cart, but I live in a small flat with my partner and one year old son. The only TV we have is an LCD and it doesn't work too well with the 2600 - between that and the fact my son loves wires the 2600 is in storage for now....

[+stephena]

Incidentally stella was allowing me extra copies by hitting RESP0 on cycle 76/0 since it was generating a start signal when they appear on the next scanline showing all 3 copies - this doesn't seem to happen on real hardware - I need to double check it doesn't happen with say a cycle 75 strobe, but I think it's unlikely.

This is a corner case that isn't handled properly in Stella yet. Can you provide a test ROM that illustrates what you're seeing (ie, one that specifically shows that Stella is different than real hardware)?