32 character text display

[eshu]

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)?

 

You could use 36char.bin which I posted earlier in this thread - it shows 36 chars in stella, but not on real hardware

[+Random Terrain]

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

Thanks. Looks good.

[SeaGtGruff]

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.

Strobing RESP0 and HMOVE together are done all the time when positioning sprites. Just because you're strobing RESP0 at the end of the line doesn't really make it a special case.

 

To get 36 characters I believe you will need to strobe RESP0 four times-- once at the beginning of the (visible) line to get the first three copies, then twice on the right side of the screen to get the last three copies, then one more time at the end of the line to set up for the next line. This is because if you strobe RESP0 and the reset does *not* occur while a START signal is active for one of the extra copies, you will not get the main copy until 228 cycles later-- usually stated as "on the next line," but that's potentially misleading, because if you strobe RESP0 at the very end of a line (i.e., on cycle 74), such that player0 would be positioned at screen location 2, "on the next line" could be misinterpreted to mean "after an HBLANK has occurred," but it doesn't-- the sprite's position counter must count through all 160 of its values so the END state (which resets the counter normally) can trigger a START signal.

 

Apparently Stella is not checking the actual count, just checking the line number or something like that to see if an HBLANK has occurred after strobing RESP0.

 

When you strobe RESP0 at the end of the line to set up for the next line, you must position the main copy at the right side of the screen so the near copy will be wrapped around to the left side of the screen at the spot where you want to RESP0 again to get the main copy for the first three copies.

 

Michael

[eshu]

To get 36 characters I believe you will need to strobe RESP0 four times

 

I'm strobing it twice with 6 cycle separation for the last three copies, if I strobe it with 11 cycle separation I get four copies...

[Omegamatrix]

I tried it on my Harmony and it looked great on my CRT TV. Well done!

 

 

[SeaGtGruff]

To get 36 characters I believe you will need to strobe RESP0 four times

 

I'm strobing it twice with 6 cycle separation for the last three copies, if I strobe it with 11 cycle separation I get four copies...

Line 1:

Start with a cycle 71 RESP0. This will reset the main copy of player0 to position 150, and the near copy will be at position 6.

After HBLANK, do a cycle 23 RESP0. This will reset the main copy of player0 to position 6, so the reset will coincide with the START signal of the near copy.

This will give you the first three sprites.

After loading and drawing the player1 graphics, do a cycle 49 RESP0 followed by a cycle 55 RESP0 to get the last three copies of player0.

 

Line 2:

Right after that, do a cycle 74 RESP0. This will reset the main copy of player0 to position 159, and the near copy will be at position 15.

After HBLANK, do a cycle 26 RESP0. This will reset the main copy of player0 to position 15, so the reset will coincide with the START signal of the near copy.

After loading and drawing the player1 graphics, do a cycle 52 RESP0 followed by a cycle 58 RESP0 to get the last three copies of player0.

 

Line 3:

Right after that, do a cycle 71 RESP0 and repeat the process.

 

The "touchy" part is the cycle 58 RESP0 followed by the cycle 71 RESP0:

 

cycles 49, 50, 51 = STA RESP0

cycles 52, 53, 54 = sleep 3 = ^^^^-7654 (not drawn)

cycles 55, 56, 57 = STA RESP0 = 3210---ss (not drawn)

cycles 58, 59, 60, 61, 62 = sleep 5 = ^^^^-76543210--

cycles 63, 64, 65, 66,67 = sleep 5 = -ssss-76543210-

cycles 68, 69, 70 = STA RESP0 = --ssss765

cycles 71, 72, 73 = sleep 3 = ^^^^-7654 (not drawn)

 

I'm not sure if the third copy will continue to be drawn during the reset signal-- if it does, there's a good chance that only 7 pixels will be drawn, since the last pixel will fall within the new "count 0." But if I'm not mistaken, the last bit will always be blank, anyway, so no harm no foul. In any case, you should at least be able to get 35 characters, if not 36.

 

The other situation-- a cycle 55 RESP0 followed by a cycle 74 RESP0-- shouldn't be a problem.

 

You could also add 1 to all of these cycle numbers:

 

cycle 72 RESP0, cycle 24 RESP0, cycle 50 RESP0, cycle 56 RESP0

cycle 75 RESP0, cycle 27 RESP0, cycle 53 RESP0, cycle 59 RESP0

cycle 72 RESP0, etc.

 

This still presents the same "sticky" situation with the cycle 59 RESP0 and cycle 72 RESP0, but I don't know which numbers will work out better for your code.

 

Michael

 

PS -- In all the screenshots of the 32-character display, it looks like there's room for only one more character to the left, and one more character to the right, or 34 characters max? I guess that might be due to HMOVE bars? If that's the case, you will probably need to go with the second set of numbers.

Edited May 16, 2011 by SeaGtGruff

[+SpiceWare]

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

 

This is quite impressive - are there any spacing issues, or could it be used to display a 128x200 bitmap?

[+SvOlli]

This is quite impressive - are there any spacing issues, or could it be used to display a 128x200 bitmap?

Because of the interlace used shouldn't the question be: "could it be used to display a 128x100 bitmap?"

[+SpiceWare]

The way he's using it is 128x100, but you can put out different images for the odd and even scan lines - just like how PAL is 625 and not 312.

 

One of my initial Harmony demos was 96x200, it could easily be adapted to 128x200.

http://www.youtube.com/watch?v=QNkvn3_rnXU

[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:

 

This is quite impressive - are there any spacing issues, or could it be used to display a 128x200 bitmap?

 

Unfortunately there are some spacing issues - Three player objects (6 characters) are 1-pixel out of place for a bitmap display on every other scanline. With the cycles gained by using DPC+ it would probably be possible to fill the gaps with missiles or the ball, like I did in another thread which was based on similar techniques - http://www.atariage.com/forums/topic/181816-bigger-bitmaps-with-dpc/.

 

I'm pretty sure with bus stuffing (http://www.atariage.com/forums/topic/183085-bus-stuffing-like-the-graduate/) it should be possible to do a full screen (160x200) interlace display.

[+SpiceWare]

Unfortunately there are some spacing issues - Three player objects (6 characters) are 1-pixel out of place for a bitmap display on every other scanline.

 

Bummer. I hacked the font and removed the ASLs (as they were hiding the overlapped pixels) to see where the issue occurs.

With the cycles gained by using DPC+ it would probably be possible to fill the gaps with missiles or the ball

Hmm - tricky part would be that the missiles are going to be triple copied just like the sprites. The only arrangement I can see that might make it possible would be to put the ball in the first gap and a missile for the 2nd and 3rd. I suspect the 3rd copy of the missile could be hidden by the playfield.

 

I'm pretty sure with bus stuffing (http://www.atariage....e-the-graduate/) it should be possible to do a full screen (160x200) interlace display.

Yeah, the bus stuffing's pretty clever. I find it interesting that The Graduate is basically the same concept as the Harmony/Melody cartridge - a computer, plugged into the cartridge port, that works in tandem with the 6507 to make the 2600 do things it could not do on it's own.

[+Gemintronic]

I'm wondering how much adaptation it'd take to make eshu's 32 character display kernel work with bB. I assume I could call it by doing a "include eshu32char.asm" or whatever the file is called and then running it instead of the DRAWSCREEN command. What about the characters? would I have to DIM some oddball area of memory for each character?

Edited June 12, 2012 by theloon

[eshu]

I'm wondering how much adaptation it'd take to make eshu's 32 character display kernel work with bB. I assume I could call it by doing a "include eshu32char.asm" or whatever the file is called and then running it instead of the DRAWSCREEN command. What about the characters? would I have to DIM some oddball area of memory for each character?

 

Unfortunately it uses a lot of zero page RAM in it's current state, so I don't think it would be suitable to use with bB - when I get some time I'm planning to revist what is possible with bB

[+SpiceWare]

Been working on converting eshu's 32 character display to DPC+. So far I've got the even frames displaying. The 2 scan lines are in a single loop and fetch all the data from data streams instead of zero page RAM.

 

 

It glitches in Stella though. It shows 0123 twice. I've hidden the initial 01 behind the playfield.

 

At the moment the display data is hard coded in the data streams. I plan to have 32x16 bytes allocated as screen memory. An ARM routine will convert the contents of screen memory to data streams. I should also be able to display the ball as a cursor. Will look into that when I get the odd frames working.

 

I'm going to set this up so there's a number of ARM functions in bank 0 that can be called to display text. These functions can be called from 6507 code, so anybody could use them without having to recompile the C code.

 

ROM

32x16.bin

[+Gemintronic]

Do you already have the IBM ASCII font handled? Could I find and/or make one for you?

 

I hear voices.. and they say "DPC+ NetHack made in bB"...

Edited June 20, 2012 by theloon

[eshu]

looking good

[Pioneer4x4]

Been working on converting eshu's 32 character display to DPC+. So far I've got the even frames displaying. The 2 scan lines are in a single loop and fetch all the data from data streams instead of zero page RAM.

I wish I understood more, but just looking at it, I am extremely impressed. What is the effective total resolution being used on that screen? Something like 160x92? I can't work out how to make a 10x10 grid addressable with 3 colors, and you do that!

Edited June 20, 2012 by Pioneer4x4

[+stephena]

It glitches in Stella though. It shows 0123 twice. I've hidden the initial 01 behind the playfield.

 

What in your opinion is the problem here? I know that there's still an issue in Stella with incorrect output when you're modifying the NUSIZx registers while a draw is occurring (basically a timing issue). Do you think this is related, or is it something else?

[+SpiceWare]

Do you already have the IBM ASCII font handled? Could I find and/or make one for you?

 

I hear voices.. and they say "DPC+ NetHack made in bB"...

 

I've only done a preliminary font, the characters are all 3x5 with 1 pixel spacing. I want to add lowercase and realized I'll have to increase the height, which will result in fewer rows of text, either 32x12 or 32x13 depending on the letter size.

 

However - for NetHack I think you'd want the 15 rows of text. What I'll probably do is set it up so that at compile time you select FONT_ALL_CAPS or FONT_LOWER_CASE and it'll build with the appropriate font. The font will not be stored in the C code, so it'll be easy to customize the characters.

Edited June 20, 2012 by SpiceWare

[+SpiceWare]

What is the effective total resolution being used on that screen? Something like 160x92?

Vertically it's 90, there's 15 rows of text using letters that are 5 pixels tall with 1 pixel spacing between each row. Horizontally it's "128", but not really as 3 of the sprites are off by 1 pixel, so in those sprites the graphic data is shifted left to compensate. You can see where that occurs in reply 61. Because of that the characters are limited to just 3 pixels wide - looking at the bits as 76543210 then the left character is drawn using bits 654 and the right using bits 210 in the "normal positions" and the 3 sprites that are off use 765 and 321.

 

Because of the shifting, the font width is limited to just 3 pixels, not 4 as you'd expect.

 

I use bit 7 in the first non-shifted sprite's datastream (the one currently showing 01) to trigger the end of the kernel loop.

Edited June 20, 2012 by SpiceWare

[+SpiceWare]

What in your opinion is the problem here? I know that there's still an issue in Stella with incorrect output when you're modifying the NUSIZx registers while a draw is occurring (basically a timing issue). Do you think this is related, or is it something else?

Hmm. It's not NUSIZ, it's set to 3 copies during init and never changed after that.

 

Possibly it's because RESP0 is hit at cycle 76/0 - maybe that's suppressing the initial copy of the triplicate.

 

Would the source help?

[eshu]

SeaGtGruff/Michael's explanation here made a lot of sense to me as to what might be the difference between Stella & real hardware for the issue being displayed here:

 

This is because if you strobe RESP0 and the reset does *not* occur while a START signal is active for one of the extra copies, you will not get the main copy until 228 cycles later-- usually stated as "on the next line," but that's potentially misleading, because if you strobe RESP0 at the very end of a line (i.e., on cycle 74), such that player0 would be positioned at screen location 2, "on the next line" could be misinterpreted to mean "after an HBLANK has occurred," but it doesn't-- the sprite's position counter must count through all 160 of its values so the END state (which resets the counter normally) can trigger a START signal.

 

Apparently Stella is not checking the actual count, just checking the line number or something like that to see if an HBLANK has occurred after strobing RESP0.

 

When you strobe RESP0 at the end of the line to set up for the next line, you must position the main copy at the right side of the screen so the near copy will be wrapped around to the left side of the screen at the spot where you want to RESP0 again to get the main copy for the first three copies.

 

Michael

[+stephena]

Right, this issue was reported before, and in this same thread no less. I really need to upgrade my memory I guess I can just go by the 36char.bin report, since it seems to be the same problem.

 

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.

[Pioneer4x4]

I've only done a preliminary font, the characters are all 3x5 with 1 pixel spacing. I want to add lowercase and realized I'll have to increase the height, which will result in fewer rows of text, either 32x12 or 32x13 depending on the letter size.

 

My OLD printer for my TRS-80 Model III was effectively a 7 pin (really 1 pin with a rotating groved platter...), and it did not print decenders, they floated up so that they were the same height as normal characters, it looked odd, but worked and was readable.

Stll, even getting a decent lowercase in 6+1 would look pretty bad, so 12 lines would be tops.

 

As for the rest, I still don't get it!

[+SpiceWare]

Found a 3x5 font with lowercase.

 

Also found a 3x4 font with lowercase. I think we'd get 32x20 using that - would be quite useful for NetHack