Jump to content
IGNORED

Twelve Digit Display


 Share

Recommended Posts

A few years back while Darrell was developing Space Rocks we developed a 14 digit score. You can read more about that here, although that topic didn't start out with that goal. With Space Rocks being a DPC+ game it was possible to take the 14 digit score kernel and put it into a nice small loop.

 

Recently other people had interest in a 12 digit score. I took my old concept code and finished it so that a user can incorporate it into a game.

 

post-7074-0-25328700-1470502269_thumb.png

 

TwelveDigitDisplay.zip

 

This post contains a new version. You can choose between two builds to trade off saving bytes for saving cycles.

;Fast PF Mask Building
;---------------------------
;Left PF Mask Building = 447 cycles
;Right PF Mask Building = 451 cycles
;Kernel 150 bytes, Data 50 bytes, Subroutines 576 bytes (776 total)


;Slow PF Mask Building
;---------------------------
;Left PF Mask Building = 507 cycles
;Right PF Mask Building = 634 cycles
;Kernel 150 bytes, Data 82 bytes, Subroutines 351 bytes (583 total)

Enjoy! :)

  • Like 7
Link to comment
Share on other sites

Currently working on the full 14 digit display. Already have it working, but need to make it more efficient before release. The 14 digit kernel does take more bytes than 12 digit kernel due to more unwound loops, but I'm sure at least some of it can be improved.

 

 

The good news is that it is still only uses 14 bytes of ram for masking of the digits. That's not too bad for what it does. By contrast a typical 6 digit display would use 12 bytes of ram for the display if it had indirect Y pointers, and one or two more for a loop counter and a temp register.

  • Like 2
Link to comment
Share on other sites

 

Let me guess: You are also using missiles and/or ball for extra digits now?

 

The missiles. You can read about that in the topic he referenced.

 

You can also see it in action by running Space Rocks (link at top of first message will take you to the current build) in Stella

post-3056-0-77010900-1470758559_thumb.png

 

then using one of the Developer Keys (COMMAND-COMMA on a Mac, or ALT-COMMA on Linux & Windows) to turn on Fixed Debug Color mode

post-3056-0-08367400-1470758579_thumb.png

post-3056-0-85843900-1332874325.gif

  • Like 1
Link to comment
Share on other sites

No problem!

Due to how the TIA is designed, the missiles will output the same number of copies/spacing as the players, so there's three copies of each missile. In the 1-6-6-1 layout one copy of the missiles overlaps with one of the score digits. It may, or may not, be possible to line them up in a way to get a 7-7 layout.

Thanks! It does use both players to draw the objects. It tries to draw an object using player0 first, if it can't it then tries to draw with player1. In that screenshot it was able to draw all objects using player0, so it didn't need to use player1. In this screenshot it needed to use both players:
post-3056-0-27317100-1470856151_thumb.png

If you play Space Rocks with Fixed Debug Color mode turned on you'll see that objects might be drawn using player0 on one frame, then with player1 on the next.

The technical stuff is in my blog. You'll find a list of Categories on the right, such as one for Space Rocks, which will filter the blog entries to just those. Just remember the blog is newest-entry-first, so you'll have to go to the last page to start from the beginning.

  • Like 1
Link to comment
Share on other sites

No problem!

 

Due to how the TIA is designed, the missiles will output the same number of copies/spacing as the players, so there's three copies of each missile. In the 1-6-6-1 layout one copy of the missiles overlaps with one of the score digits. It may, or may not, be possible to line them up in a way to get a 7-7 layout.

 

Oh yes, I forgot about the copies!! That could be a bit trickier or maybe impossible then.

 

I don't know too much about the TIA internals right now, and I guess, that if it would be possible, somebody had surely discovered it after all those years of TIA-hacking.

 

 

 

If you play Space Rocks with Fixed Debug Color mode turned on you'll see that objects might be drawn using player0 on one frame, then with player1 on the next.

 

The technical stuff is in my blog. You'll find a list of Categories on the right, such as one for Space Rocks, which will filter the blog entries to just those. Just remember the blog is newest-entry-first, so you'll have to go to the last page to start from the beginning.

 

I edited my post, but you was faster. ;)

 

Meanwhile I discovered a newer version of Space Rocks and I have seen that it uses all player objects. Hard to play in debug mode. ;)

Really a lot of objects that are moving!!

 

 

I have seen your blog but did not know about the categories. Very useful!

Link to comment
Share on other sites

Thanks for the hint! :)

 

Would it be also possible to place the missiles without the gap?

 

I mean "8888888" instead of "8__888888".

 

 

BTW: Impressive Space Rocks! Fun to play!

Yes, this is possible if you do it this way:

 

post-7074-0-61353800-1470895323_thumb.png

 

 

Where the digits look like "B" is where missiles are being used. The third B overlaps the P0 and P1 graphics, the first two don't. To make the "B" look like an "8" requires playfield blocks to cover up a few bits.

 

 

I haven't checked if the timing of the playfield writes would have any conflicts with drawing the score this way.

Link to comment
Share on other sites

Yes, this is possible if you do it this way:

Where the digits look like "B" is where missiles are being used. The third B overlaps the P0 and P1 graphics, the first two don't. To make the "B" look like an "8" requires playfield blocks to cover up a few bits.

 

That's a good idea to use the missiles in the middle and also 1 copy of them.

 

First I thought of using it to the left and right, but this is a much smarter solution! I like it!

 

Can you post a binary to see it in action?

Link to comment
Share on other sites

Yes, this is possible if you do it this way:

 

Ah - so scoot the players closer together.

 

:ponder: having so many updates near the middle of the scanline will make timing more difficult. If it doesn't work with a normal, or even DPC+, Kernel it's possible it'll work with BUS.

Link to comment
Share on other sites

 

That's a good idea to use the missiles in the middle and also 1 copy of them.

 

First I thought of using it to the left and right, but this is a much smarter solution! I like it!

 

Can you post a binary to see it in action?

Yes, it is also possible to put the extra digits on the other edges. Here again the "B" are created by missiles. The extra digit wrapping around the right edge (which looks like a "1" and "3") would get covered up with the playfield writes so you would again have a 14 digit display.

 

 

post-7074-0-93981500-1470973917_thumb.png

  • Like 1
Link to comment
Share on other sites

Yes, it is also possible to put the extra digits on the other edges. Here again the "B" are created by missiles. The extra digit wrapping around the right edge (which looks like a "1" and "3") would get covered up with the playfield writes so you would again have a 14 digit display.

 

OK, so there are 2 possible solutions to do it.

 

Not really the same, but 2 with different space in the middle of the 2x 7-digit scores.

Link to comment
Share on other sites

 

:ponder: having so many updates near the middle of the scanline will make timing more difficult. If it doesn't work with a normal, or even DPC+, Kernel it's possible it'll work with BUS.

 

You mean BUS stuffing? I read some comments on this technique. Seem to me like on the bus 2 chips were outputting at the same time and the card wins, isn't it?

According to this, isn't there a risk of damaging the hardware?

Link to comment
Share on other sites

 

You mean BUS stuffing? I read some comments on this technique. Seem to me like on the bus 2 chips were outputting at the same time and the card wins, isn't it?

According to this, isn't there a risk of damaging the hardware?

 

Yep. The 6507 needs to output a $FF for it to be OK. We're going to set up Stella to generate an error if the 6507 isn't outputting $FF when Bus Stuffing is active. More info here and here.

 

Once it's done I'll be rebooting Draconian to use it.

Link to comment
Share on other sites

 

Yep. The 6507 needs to output a $FF for it to be OK. We're going to set up Stella to generate an error if the 6507 isn't outputting $FF when Bus Stuffing is active. More info here and here.

 

Once it's done I'll be rebooting Draconian to use it.

 

I read the linked infos carefully. Now I have an idea of whats going on with bus stuffing! Thanks for the hints!

It's really interesting that the guys of Atari invented this (The Graduate). So this should be working...

 

The extension of Stella is surely a good idea to prevent damaging the hardware.

Maybe also the hardware could first check the bus, if $FF is on it before overriding it?

 

 

Looking forward to the new Draconian! :)

Link to comment
Share on other sites

EDIT: OK, as Thomas said below, this topic is not new. But I leave it anyway here, so you can see my point of view ;-) )

 

(Maybe this is a little off topic, so I apologize for this)

 

But what also comes to my mind when I read the articles on bus stuffing:

 

When a new hardware degrades the VCS only to be a co-processor for audio/video/io then the complete system isn't a 2600 any more.

So when somebody asks: is XXXXXXXXXX possible on a 2600, then the true answer is NO... YES only with hardware extensions which were much more powerful than the whole VCS.

 

This finally leads to the question: is Pitfall II a 2600 game when it uses DPC?
My personal opinion is YES, because the VCS is the main processor and the DPC is his helpful slave.

With bus stuffing these roles were changed, so in my opinion thats not a real 2600.

 

Also the system is much more complex to understand and to progam. I has it's reason that there are not so much programs using DPC/DPC+.

The more the VCS expands the more it looses it's simplicity, which makes it in fact most attractive to play with it (in the mean of coding).

 

 

... and when you think even more radical: you could plug an extension card to the VCS with its own HDMI-output, that only the IOs (joysticks etc.) where delivered by the 6507.
So should that system also be called a VCS? I think no!

 

 

To clear this: The upper should not be meant as criticism... I like the idea of expanding the system, don't get me wrong!!
It's more a philosophical discussion.

Edited by MacrosCode
Link to comment
Share on other sites

Its not bus stuffing, but DPC+ and ARM what you are referencing too.

 

We had this discussion on AA frequently before, opinions vary. Especially between developers, not so much between consumers (they often don't care). Look it up.

 

I has it's reason that there are not so much programs using DPC/DPC+.

The more the VCS expands the more it looses it's simplicity, which makes it in fact most attractive to play with it (in the mean of coding).

The reason is different. Some developers like exploring new technology and some prefer to stick close to the original specs.

Edited by Thomas Jentzsch
  • Like 1
Link to comment
Share on other sites

We had this discussion on AA frequently before, opinions vary. Especially between developers, not so much between consumers (they often don't care). Look it up.

 

Please don't beg me! :)

 

As a newbie my mission was to write about this topic again to keep the frequency. :-D

  • Like 1
Link to comment
Share on other sites

It's really interesting that the guys of Atari invented this (The Graduate). So this should be working...

Actually, it was a few guys from Commodore.

 

The extension of Stella is surely a good idea to prevent damaging the hardware.

Maybe also the hardware could first check the bus, if $FF is on it before overriding it?

Don't know if there's enough time for that to happen, I'll mention it to cd-w.

 

Looking forward to the new Draconian! :)

Thanks!

 

As Thomas says, that discussion comes up a lot. For me as long as you plug the cartridge into the console, then play the console like normal, then its a 2600 game. I also find "Homebrew Hardware" to be as interesing as "Homebrew Software". Random Terrain has a nice article about it - Atari's Promise Means It's Not Cheating.

Link to comment
Share on other sites

Actually, it was a few guys from Commodore.

 

[...]

 

As Thomas says, that discussion comes up a lot. For me as long as you plug the cartridge into the console, then play the console like normal, then its a 2600 game. I also find "Homebrew Hardware" to be as interesing as "Homebrew Software". Random Terrain has a nice article about it - Atari's Promise Means It's Not Cheating.

 

Commodore? Shame on me, you are right!

I did no read carefully enough! :)

 

Interesting article of Random Terrain about that topic.

Link to comment
Share on other sites

For me, there is no clear decision. I have been collaborating at two of Darrell's projects, so I got some first hand experience there too. For now, I decided to stick closer to the original specs (just with more ROM and RAM) and code my games in 650x assembler.

  • Like 1
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...
 Share

  • Recently Browsing   0 members

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