Jump to content
IGNORED

Minikernel - Player Scores


CurtisP

Recommended Posts

The minikernel is complete and ready to use.

Any chance you might be able to do a 4 player version (4 2-digit scores)? If so, I could really use it.

 

Probably not 4 on one line, but two on a line stacked on top of each other would be doable. It would require that the 6-digit score be turned off, though.

Link to comment
Share on other sites

Thanks, this looks great!

 

Could you test this with your Krokodile Cart for me? My Supercharger and 2600 are packed away at the moment.

Sure thing, but it won't be tonight.

 

I will say this, though-- and I probably should have posted something sooner about it. Last weekend I was running some tests on my heavy-sixer to get a better understanding of some of the finer details of the interval timer, and comparing the results with the z26 and Stella emulators. I was writing simple little programs in batari Basic, and displaying the values of TIMINT and INTIM using the score. In doing so, I happened to notice that the updating of the last digit of the score was a little off on my real Atari-- that is to say, the first 2 or 3 pixels of the 1s (sixth) digit were from the 100s (fourth) digit, and then the remaining pixels were from the 1s digit. This is caused by a combination of the timing of the "STA GRPx" commands and the horizontal positions of the players in the score. It looks like either the STA commands need to occur 1 cycle sooner, or the score needs to be shifted left 3 color clocks. The odd thing was, the z26 and Stella emulators both showed the last digit "correctly," so apparently they aren't emulating the actual timing behavior correctly. I meant to do some further investigations to verify this, and then tinker with the score timing in batari Basic. In particular, I'm curious to see if using VDELxx has any bearing on this. (I'm wondering if there's a tiny delay of 1 cycle after GRP0 is updated, during which the "old" GRP1 register is being updated from the "new" GRP1 register.)

 

Michael

Link to comment
Share on other sites

Probably not 4 on one line, but two on a line stacked on top of each other would be doable. It would require that the 6-digit score be turned off, though.

 

That would totally rock! I wouldn't mind at all that the 6-digit score get turned off. If there is anyway to also fit colors into it, that would be best, but even a single hardcoded color would be fine!

Link to comment
Share on other sites

I just realized that as currently written, this minikernel will crash when used with the multisprite kernel. It's an easy fix, so I will change it when I add the ability to show 4 scores (along with a few other tweeks).

 

Personally I wouldn't be using this with multisprite. I gave up on multisprite for the Ultimate Indy 500 game because of the lack of possible paddle support. Michael mentioned potentially modifying the kernel to get better vertical resolution of the playfield, but for now I'd still be really interested in a 4 score minikernel. If there were a way to have colors with those scores that would be even better, but they definitely wouldn't be necessary. They would be my lap counters, so they would be as functional within the game as they would be for display purposes. Thanks for doing this!

Edited by Fort Apocalypse
Link to comment
Share on other sites

Sure thing, but it won't be tonight.

 

I will say this, though-- and I probably should have posted something sooner about it. Last weekend I was running some tests on my heavy-sixer to get a better understanding of some of the finer details of the interval timer, and comparing the results with the z26 and Stella emulators. I was writing simple little programs in batari Basic, and displaying the values of TIMINT and INTIM using the score. In doing so, I happened to notice that the updating of the last digit of the score was a little off on my real Atari-- that is to say, the first 2 or 3 pixels of the 1s (sixth) digit were from the 100s (fourth) digit, and then the remaining pixels were from the 1s digit. This is caused by a combination of the timing of the "STA GRPx" commands and the horizontal positions of the players in the score. It looks like either the STA commands need to occur 1 cycle sooner, or the score needs to be shifted left 3 color clocks. The odd thing was, the z26 and Stella emulators both showed the last digit "correctly," so apparently they aren't emulating the actual timing behavior correctly. I meant to do some further investigations to verify this, and then tinker with the score timing in batari Basic. In particular, I'm curious to see if using VDELxx has any bearing on this. (I'm wondering if there's a tiny delay of 1 cycle after GRP0 is updated, during which the "old" GRP1 register is being updated from the "new" GRP1 register.)

 

Michael

I have not noticed this issue on my 4-switch, so it might be a heavy-sixer thing. If you can post the binary you used to test the timers, I will let you know if that binary has a distorted score. BTW, have you noticed any weirdness with the score on all bB 1.0 binaries, or just this one?

Link to comment
Share on other sites

Sure thing, but it won't be tonight.

It looks like either the STA commands need to occur 1 cycle sooner, or the score needs to be shifted left 3 color clocks. The odd thing was, the z26 and Stella emulators both showed the last digit "correctly," so apparently they aren't emulating the actual timing behavior correctly. I meant to do some further investigations to verify this, and then tinker with the score timing in batari Basic. In particular, I'm curious to see if using VDELxx has any bearing on this. (I'm wondering if there's a tiny delay of 1 cycle after GRP0 is updated, during which the "old" GRP1 register is being updated from the "new" GRP1 register.)

I have not noticed this issue on my 4-switch, so it might be a heavy-sixer thing. If you can post the binary you used to test the timers, I will let you know if that binary has a distorted score. BTW, have you noticed any weirdness with the score on all bB 1.0 binaries, or just this one?

 

Thanks for the info. It was a pain getting the cycles right, but I may have to work on it some more. I pulled out my heavy six so I can do some more testing.

 

Looks like I'm going to have to buy some more 2600s, all I have are heavy-sixers.

Link to comment
Share on other sites

Alright. I finally saw the color bug that Michael pointed out (right most pixel of the first digit). Adding a cycle into the middle of the display routine fixed it.

 

I rewrote the code to reference existing labels instead of memory locations, so it should work with both kernels now.

 

And I added support for 4 scores (each with it's own color of course). With just one minikernel, you can have 2 or 4 scores. See the documentation for more details.

playerscores.zip

playerscores.bin

Link to comment
Share on other sites

Alright. I finally saw the color bug that Michael pointed out (right most pixel of the first digit). Adding a cycle into the middle of the display routine fixed it.

 

I rewrote the code to reference existing labels instead of memory locations, so it should work with both kernels now.

 

And I added support for 4 scores (each with it's own color of course). With just one minikernel, you can have 2 or 4 scores. See the documentation for more details.

The problem with adding cycles is it might muck up the pfscore bars. IIRC, the timing on those needed to be exactly as it was or they wouldn't work right.

Link to comment
Share on other sites

Alright. I finally saw the color bug that Michael pointed out (right most pixel of the first digit). Adding a cycle into the middle of the display routine fixed it.

 

I rewrote the code to reference existing labels instead of memory locations, so it should work with both kernels now.

 

And I added support for 4 scores (each with it's own color of course). With just one minikernel, you can have 2 or 4 scores. See the documentation for more details.

The problem with adding cycles is it might muck up the pfscore bars. IIRC, the timing on those needed to be exactly as it was or they wouldn't work right.

Sorry, I just downloaded your code and see that you were talking about your own 2-player score thing and not the bB 6-digit score. So does that one work, or does it have the same bug?

Link to comment
Share on other sites

The problem with adding cycles is it might muck up the pfscore bars. IIRC, the timing on those needed to be exactly as it was or they wouldn't work right.

Sorry, I just downloaded your code and see that you were talking about your own 2-player score thing and not the bB 6-digit score. So does that one work, or does it have the same bug?

 

Mine is working now. Your score code only has one color, whereas mine has two per line. Michael noticed that the color was off by one pixel, but i was able to fix it by adding a cycle. Getting that timing right sure can be a pain, can't it?

 

Anyway, I've licensed the minikernel so that it can be included in future releases of bAtari Basic. I think it is pretty solid at this point.

Link to comment
Share on other sites

As for the 6-digit score routine, I have never seen any problems with any of the digits. I saw things similar to what Michael was describing when I was playing around with my code to get the timing right, but once I did it's been fine. As far as i can tell, so is yours.

It's the graphics that seem to be off, not the colors. And it doesn't happen on the emulators, just on a real Atari (well, on my heavy-sixer, at least-- I haven't tried it on my 7800 yet, but I *did* find my Cuttle Cart 2 today! :)).

 

Michael

Link to comment
Share on other sites

It's the graphics that seem to be off, not the colors. And it doesn't happen on the emulators, just on a real Atari (well, on my heavy-sixer, at least-- I haven't tried it on my 7800 yet, but I *did* find my Cuttle Cart 2 today! :)).

 

Just to be clear, which score are you talking about, this minikernel one or the standard six-digit? And in exactly which digit (numbered from the left) are the graphics messed up?

Link to comment
Share on other sites

It's the graphics that seem to be off, not the colors. And it doesn't happen on the emulators, just on a real Atari (well, on my heavy-sixer, at least-- I haven't tried it on my 7800 yet, but I *did* find my Cuttle Cart 2 today! :)).

 

Just to be clear, which score are you talking about, this minikernel one or the standard six-digit? And in exactly which digit (numbered from the left) are the graphics messed up?

I noticed it in the standard six-digit score the other weekend, while running some little test programs I wrote to help me answer certain questions I had about the interval timer. I was using bB's score to display the value of the timer, as well as the status of the timer interrupt flag. I was running my test programs in the z26 and Stella emulators, but Fred/batari had once posted a comment that the timer isn't being emulated correctly on the emulators, so I was also running my test programs on my 2600 (heavy six-switch), and comparing all three results (z26, Stella, and 2600). When I did, I noticed that the score looks fine on the emulators, but the last digit is a little bit off on my 2600-- specifically, it looks like the graphics for the last digit are being updated about 1 cycle later than expected, because it looks like the first few pixels of the sixth digit might be the same as the first few pixels of the fourth digit. I need to investigate this further, but I'm in the middle of moving, so I can't do it right now.

 

Anyway, when you asked me to check your minikernel on my 2600 with the Krokodile Cartridge, I said I wouldn't be able to do that yet, but then I commented about what I'd noticed the week before in bB's standard score. I figured that if this problem is occurring in bB's six-digit score, then your minikernel might exhibit the same problem on a real 2600. Note that if this is caused by a slight timing issue (as I suspect), then it follows that the timing of any color changes in your minikernel might be a little off, as well. When I'm finished moving, I'll do some more tests to investigate further, and post my results.

 

Michael

Link to comment
Share on other sites

  • 2 weeks later...

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...