Jump to content
IGNORED

Help with SCORE glitch (maybe)?


Glenn Jupp

Recommended Posts

I'm getting a weird little glitch in the SCORE on what's going to be a bBasic chess clock when it grows up (actually, it's going to be for this old hex-n-chit wargame, but that's neither here nor there).

 

When the second, fourth or sixth digit equals 2,3,6 or 7 then the digit to the left shows a sprite that's the top 6 lines of the correct sprite and the bottom 2 lines of the wrong sprite. I would post a screencap, but it doesn't do this on the emulators, just on my real 2600jr with a KrokoKart.

 

Am I doing something sloppy in BAS to cause this? Is it the fault of the 2600jr and/or the Krok?

 

BAS and BIN are attached. The BAS is uncommented 'cause I wasn't expecting to share this preliminary mucking about with anybody. Joystick0 to set the time, left and right, up and down, you'll see. Press Select to start the countdown. Time is in minutes, seconds, frames, so don't set it for 995959.

time_set.bas

time_set.bin

Link to comment
Share on other sites

I'm getting a weird little glitch in the SCORE on what's going to be a bBasic chess clock when it grows up (actually, it's going to be for this old hex-n-chit wargame, but that's neither here nor there).

 

When the second, fourth or sixth digit equals 2,3,6 or 7 then the digit to the left shows a sprite that's the top 6 lines of the correct sprite and the bottom 2 lines of the wrong sprite. I would post a screencap, but it doesn't do this on the emulators, just on my real 2600jr with a KrokoKart.

 

Am I doing something sloppy in BAS to cause this? Is it the fault of the 2600jr and/or the Krok?

 

BAS and BIN are attached. The BAS is uncommented 'cause I wasn't expecting to share this preliminary mucking about with anybody. Joystick0 to set the time, left and right, up and down, you'll see. Press Select to start the countdown. Time is in minutes, seconds, frames, so don't set it for 995959.

Do other bB games (made with version 1.0) exhibit this same behavior or just your game?

 

Either way, some 2600Jr's use a slightly different TIA chip, so it's possible that this is the cause. If you can post a picture of your television, that would be great. If not, I will try to find my 2600Jr (though I have no clue if it has the different TIA chip...)

Link to comment
Share on other sites

I checked the bBasic program "Sample" and it does the same thing for me. Took some pix but be warned; the good camera is on the blink so I had to use the cruddy el-cheapo digicam. The TV could be better, too.

 

badscore012.jpg

 

The score is supposed to say 632343. But the first sprite is starting with the second last byte of the data for "7," and so on.

 

And for what it's worth, my Jr's serial number is A1 79 1338967. What's yours?

Link to comment
Share on other sites

Do other bB games (made with version 1.0) exhibit this same behavior or just your game?

 

Either way, some 2600Jr's use a slightly different TIA chip, so it's possible that this is the cause. If you can post a picture of your television, that would be great. If not, I will try to find my 2600Jr (though I have no clue if it has the different TIA chip...)

Could it be the illegal opcodes? I notice that the score routine uses LAX (),Y and NOP 0. Presumably the commands are working at least somewhat, otherwise I'd expect that *all* of the scan lines of the digits would be messed up-- but could their timing be off just a bit, especially on the NOP 0, causing a cumulative timing difference that eventually throws things out of whack by the 7th scan line?

 

Perhaps try compiling it with the "no illegal opcodes" option, and see if that makes a difference?

 

Michael

Link to comment
Share on other sites

Do other bB games (made with version 1.0) exhibit this same behavior or just your game?

 

Either way, some 2600Jr's use a slightly different TIA chip, so it's possible that this is the cause. If you can post a picture of your television, that would be great. If not, I will try to find my 2600Jr (though I have no clue if it has the different TIA chip...)

Could it be the illegal opcodes? I notice that the score routine uses LAX (),Y and NOP 0. Presumably the commands are working at least somewhat, otherwise I'd expect that *all* of the scan lines of the digits would be messed up-- but could their timing be off just a bit, especially on the NOP 0, causing a cumulative timing difference that eventually throws things out of whack by the 7th scan line?

 

Perhaps try compiling it with the "no illegal opcodes" option, and see if that makes a difference?

 

Michael

I doubt it's illegal opcodes as the Jr uses the same CPU. Late model Jrs are known to have TIA differences, particularly in the HMOVE circuitry. I'd think that if NOP 0 was a problem, it would exhibit itself with one of the many homebrews that have used it over the years.

 

I hacked the time_set binary to change the HMOVE timing by one cycle. Glenn, if you can try this binary out, let us know how it works!

time_set74.bin

Edited by batari
Link to comment
Share on other sites

Late model Jrs are known to have TIA differences, particularly in the HMOVE circuitry.

Okay, that rings a bell, but I don't remember the details-- something about cycle 73 HMOVEs versus cycle 74 HMOVEs? I'll have to dig through the forums for "HMOVE" to see, because I know this topic was discussed in a thread a year or so ago.

 

Michael

Link to comment
Share on other sites

Late model Jrs are known to have TIA differences, particularly in the HMOVE circuitry.

Okay, that rings a bell, but I don't remember the details-- something about cycle 73 HMOVEs versus cycle 74 HMOVEs? I'll have to dig through the forums for "HMOVE" to see, because I know this topic was discussed in a thread a year or so ago.

 

Michael

I think it was about nonstandard HMOVEs in general. IIRC, someone (Supercat I think) posted a demo using HMOVEs at weird times - I think it was cycle 20 or 50 or thereabout, and it was found to not work properly on a late model Jr. This caused some concern since cycle 73 and 74 HMOVEs are so useful and we didn't want to learn that we couldn't use them.

 

So I wrote a test binary that used cycle 74 HMOVEs and it was found to work properly on the Jr. My score routine uses a cycle 73 HMOVE, which I assumed would also work, but maybe it doesn't really. To my knowledge, cycle 73 HMOVEs haven't been formally tested on a Jr.

 

So... basically, the test binary above was hacked to use a cycle 74 HMOVE instead. If it works, then this might suggest that cycle 73 HMOVEs aren't reliable. If it doesn't work then I might have another suggestion.

Link to comment
Share on other sites

I think it was about nonstandard HMOVEs in general. IIRC, someone (Supercat I think) posted a demo using HMOVEs at weird times - I think it was cycle 20 or 50 or thereabout, and it was found to not work properly on a late model Jr. This caused some concern since cycle 73 and 74 HMOVEs are so useful and we didn't want to learn that we couldn't use them.

 

So I wrote a test binary that used cycle 74 HMOVEs and it was found to work properly on the Jr. My score routine uses a cycle 73 HMOVE, which I assumed would also work, but maybe it doesn't really. To my knowledge, cycle 73 HMOVEs haven't been formally tested on a Jr.

 

So... basically, the test binary above was hacked to use a cycle 74 HMOVE instead. If it works, then this might suggest that cycle 73 HMOVEs aren't reliable. If it doesn't work then I might have another suggestion.

I did some searching in the forums last night, and what I found was that HMOVE pulses (don't know if I'm saying that right) occurring during the scan line (active video) will cause movement in late model 2600Jrs. manufactured in China (although another post referred to PAL 2600Jrs.)-- whereas HMOVE pulses occurring during the scan line do *not* result in movement on (all?) other TIAs. It seemed at the time of those posts that cycle 73/74 HMOVEs were considered safe, but 73s hadn't specifically been tested, although it was confirmed (assumed?) that cycle 71/72 HMOVES caused troubles, along with anything before cycle 71, due to the pulses that occur during the scan line. I don't pretend to understand all of that, so I may have summarized/paraphrased it incorrectly.

 

Michael

Link to comment
Share on other sites

Well, after trying no illegal opcodes and the HMOVE74 hack, nothing's changed.

 

Might it be something in the KrokoKart? Any reports of Kroks playing funny tricks on people?

My Krokodile Cartridge won't play my E7-bankswitched WIPs correctly-- it acts like it's having trouble emulating the 256-byte RAM banks (the 1K RAM bank seems fine)-- but I haven't checked it out thoroughly yet, and it's worked just fine for normal 2K and 4K cartridge formats. So I'm inclined to think that it's your 2600Jr., but I'll test your program on my Krokodile Cartridge just to be sure. Which version of the Krokodile Commander software are you using?

 

Michael

Link to comment
Share on other sites

Krokodile Commander v1.06. Dunno what the Kart's firmware version is (it has been revised some, right?)

 

If only I had a different multicart to try it on...

 

Hey, what would I have to do to jimmy a bBasic game onto a Supercharger?

 

EDIT: Ok, a quick search and I found SpiceWare's modified score_graphics.asm for bBasic 0.99. Is it still good for v1.0?

Edited by Glenn Jupp
Link to comment
Share on other sites

Well, after trying no illegal opcodes and the HMOVE74 hack, nothing's changed.

 

Might it be something in the KrokoKart? Any reports of Kroks playing funny tricks on people?

Drat... I was hoping that would make a difference.

 

One question: Are the numbers in the correct location, or are they shifted left or right as compared with emulators?

Link to comment
Share on other sites

The score sprites look to be in the right place. If they're not then it isn't by much and my GEV sprite is off by the same amount, and that doesn't sound too likely, does it?

 

Fiddled about with the Supercharger and bB1.0, came up zilch. Gonna try with bB0.99 next.

Link to comment
Share on other sites

The score sprites look to be in the right place. If they're not then it isn't by much and my GEV sprite is off by the same amount, and that doesn't sound too likely, does it?

 

Fiddled about with the Supercharger and bB1.0, came up zilch. Gonna try with bB0.99 next.

I'm now thinking it has to do with the GRPx timing. One of the writes comes while one digit is being written, and while emus and regular 2600s don't mind, it's possible that the Jr does. I'm working on tweaking the timing to see if you get better results. I'd imagine that 0.99 works, as this has a standard 6-digit score routine while 1.0 does not.

Link to comment
Share on other sites

I'm now thinking it has to do with the GRPx timing. One of the writes comes while one digit is being written, and while emus and regular 2600s don't mind, it's possible that the Jr does. I'm working on tweaking the timing to see if you get better results. I'd imagine that 0.99 works, as this has a standard 6-digit score routine while 1.0 does not.

 

What do you mean "comes while one digit is being written"? I would expect a lot of code relies upon pixel-perfect GRPx writes, and I don't recall having heard of this problem before.

Link to comment
Share on other sites

I'm now thinking it has to do with the GRPx timing. One of the writes comes while one digit is being written, and while emus and regular 2600s don't mind, it's possible that the Jr does. I'm working on tweaking the timing to see if you get better results. I'd imagine that 0.99 works, as this has a standard 6-digit score routine while 1.0 does not.

 

What do you mean "comes while one digit is being written"? I would expect a lot of code relies upon pixel-perfect GRPx writes, and I don't recall having heard of this problem before.

Basically, on regular consoles and emulators, the 6th digit will inherit the leftmost pixel (MSB) of the 4th digit. Since the MSB of all digits is zero, this isn't noticeable. I think the 6th digit is displayed only because of a dummy GRP0 write (due to VDEL) which usually occurs before the digit is displayed, but in my score kernel I think the write occurs late, i.e. while the digit is being displayed.

 

It's possible that the Jr ignores the VDEL in this case and the whole display gets mucked up as a result. My plan it to change the kernel so this write occurs one cycle sooner and see if that works.

Link to comment
Share on other sites

Basically, on regular consoles and emulators, the 6th digit will inherit the leftmost pixel (MSB) of the 4th digit. Since the MSB of all digits is zero, this isn't noticeable. I think the 6th digit is displayed only because of a dummy GRP0 write (due to VDEL) which usually occurs before the digit is displayed, but in my score kernel I think the write occurs late, i.e. while the digit is being displayed.

 

It's possible that the Jr ignores the VDEL in this case and the whole display gets mucked up as a result. My plan it to change the kernel so this write occurs one cycle sooner and see if that works.

It should be possible to time the writes so each digit's pixels are intact-- all 8 of them-- but I know that getting the timing right can be tricky, especially depending on the horizontal positioning of the sprites. One thing that used to give me a lot of trouble was that it would *seem* like the timing should be okay, but the pixels were still "bleeding over" into the next copy of the players-- until I read the TIA opus by Andrew Towers, which explained (and I'm paraphrasing it into my own words here) that the players essentially have a 9th pixel to the left of bit7, which is always blank. That's not really the case, of course, but that's the gist of what the player timing means. That is, if you set a player's horizontal position, and then set that player's missile to the same horizontal position, by performing two identically-timed RESxx commands (e.g., RESP0 and RESM0) on two different lines (since you can't very well do both on the same line at the same cycle), then the missile will be like a 9th pixel of the player, since the missile will be 1 pixel to the left of the player. Here's a portion of one of the timing lists to show what I mean:

 

011100	16	21.3	64	(draw -012)
101110	17	22.6	68	(draw 3456)
010111	18	24	72	(draw 7---)

 

The first part of the first draw is essentially a blank pixel, and the player doesn't actually start to display until the pixel after that-- but that blank pixel is where the missile would be if it were set to the "same" horizontal position as the player.

 

So the way I understand it-- and I may be totally wrong on this-- when you're doing the score trick, you really need to update the next player copy 1 cycle earlier than where you'd think, otherwise it ends up inheriting the first pixel of the previous copy. At least, that's what seemed to be happening when I was trying to learn the score trick, and when I read Andrew's opus, it sort of made sense of a few things that had been bugging me (such as why RESxx positions the missiles and ball at the pixel location you'd expect, but the players are 1 pixel to the right of that expected position).

 

Michael

 

PS -- A while back (before 1.0 was released), I had posted some custom mods that allowed the score to be used for an "inventory strip," and my demo to illustrate how it worked included moving a "cursor" around in the inventory strip. I adjusted the player positions in the score to make them centered on the screen, and the cursor (drawn with inverted pixel shapes) displayed correctly for all six positions, without any pixels bleeding over into the next player copy. So I know it's possible-- although I also know that you shifted the score to the right of the center for timing reasons. So if you can't do anything with the write timings, you might try shifting the player positions a little bit (left or right, depending on your writes) to see if that helps.

Edited by SeaGtGruff
Link to comment
Share on other sites

It took me a while to tweak the timing to get the two playfield bars in there and timed just right, which required making the score off-center. But that's not to say that the kernel can't be modified to work on a Jr as well.

 

For that matter, it might be possible that the score can be centered, allow two playfield writes, AND display all 8 pixels of the 6 digits. I tried for a long time but wasn't able to do all 3 (that 6-digit score is a tricky beast.)

 

Anyway, I'm trying another test binary. This time I shifted the whole score to the right by one pixel so that last digit gets its VDEL before it's displayed. The side-effects are that the score is slightly more off-center and one of the other digits' timing might be a little off, though the Jr might not balk at this. Worth a shot anyway.

 

So Glenn, try this binary out and let us know how it works. We'll get to the bottom of this one way or another...

time_set1.bin

Link to comment
Share on other sites

Guess what? No effect.

 

Well, yeah, the score is now shifted one pixel to the right. But it's still reading the sprite data two addresses too high, sometimes.

 

I want to rule out the Krok, but I'm having trouble porting this to the Supercharger. Any advice?

Link to comment
Share on other sites

Guess what? No effect.

 

Well, yeah, the score is now shifted one pixel to the right. But it's still reading the sprite data two addresses too high, sometimes.

 

I want to rule out the Krok, but I'm having trouble porting this to the Supercharger. Any advice?

I think the SC should work with the modified score_graphics.asm as noted above. Did it not work with this?

 

Anyway, here's another go at it. In this case, I've tried a different way of setting the score pointers. BTW, thanks for your help with this.

time_set2.bin

Link to comment
Share on other sites

The modified score_graphics.asm didn't work for me. Maybe I used it with the wrong version of bB0.99? Dunno why I'm bothering, since 0.99 didn't give this score problem. Just stubborn, I guess.

 

Time_set2 doesn't look any different on my junior. Phooey.

 

And thanks back at you for helping.

Link to comment
Share on other sites

The modified score_graphics.asm didn't work for me. Maybe I used it with the wrong version of bB0.99? Dunno why I'm bothering, since 0.99 didn't give this score problem. Just stubborn, I guess.

 

Time_set2 doesn't look any different on my junior. Phooey.

 

And thanks back at you for helping.

I changed both the score kernel and the score pointer calculation method in 1.0, so it seems to me that it's one or the other. In this next binary, I've tried a completely rewritten score pointer setting routine which, if it doesn't work, should virtually rule out any error here.

time_set3.bin

Link to comment
Share on other sites

Hey hey! That did it! Now I have no excuse to procrastinate any longer. Thanks (I think).

 

So, what's the magic trick to fixing it?

Glad it worked - this means the score kernel is not the cause and it's the way I set the pointers.

 

For the test bin I replaced this with a purely table-based method, which was kind of overkill and rather inefficient. It's not worthy of release. Before I release an updated std_overscan.asm, I'd like to further track down the problem if you don't mind. I'm posting another test bin - if it works, I'll go ahead and post an update.

time_set4.bin

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