Jump to content
IGNORED

Hunchy II


cd-w

Recommended Posts

Hi there!

 

Hm... looks good on my PAL & CC1 setup...

I see in the source that you have music data on $FFF8 maybe that's a problem for the SC?

 

Greetings,

Manuel

902601[/snapback]

 

Thanks - The game uses all of the available 4K ROM, so I guess it just a Supercharger issue. However, I'm surprised that it causes graphic corruption, rather than simply freezing the console.

 

Chris

Link to comment
Share on other sites

Darn - I just noticed that the score between levels does not work on my Supercharger (the text is garbled) even though it works fine with the emulators.  It could be that my hardware is broken (I recently plugged it into a 7800 by mistake), but I suspect that the timings are slightly out.  Can anyone confirm that this happens for them also?  Also, any suggestions for fixing this would be greatly appreciated.  The source is included in the archive file.  I was hoping that the 4K version was completed now  :(

902581[/snapback]

 

Text between levels is garbled on my system as well.

Cuttle Cart.

Atari Jr.

 

Once we found that we finished level 1 without collecting the last bell.

 

I'll take a look at the source and see if I can offer any suggestions for the garbled text.

Link to comment
Share on other sites

Hi there!
Text between levels is garbled on my system as well.

Cuttle Cart.

Atari Jr.

Hm... Just for the record, I tested on a 6er.

I'd suggest looking into the Z26 log for "deep" or "weird" now.

Greetings,

Manuel

902943[/snapback]

 

Interesting - I am also using an Atari Jr. with my supercharger. I just ran a trace with Z26 and the only "weird" in this section of the code was the HMOVE at cycle 62 which I use to move P1 left by 1 pixel. I got the $20 value from the HMOVE timing chart (-1 on cycle 62):

 

       lda #$20            ; [54] + 2      Shift P1 Left By 1 Pixel
       sta HMP1            ; [56] + 3
       sta HMOVE           ; [59] + 3

 

EDIT: I just dug out my old 6-switcher woody and the text is not garbled. This points to a subtle difference between the woody and Jr! Both consoles are PAL region (although the game is NTSC).

 

EDIT: I tried putting the HMOVE in the proper place and that appears to fix the problem! I guess the HMOVE timings are different on the Jr. then?!

 

Chris

Edited by cd-w
Link to comment
Share on other sites

EDIT: I tried putting the HMOVE in the proper place and that appears to fix the problem!  I guess the HMOVE timings are different on the Jr. then?!

 

Chris

902948[/snapback]

I have heard elsewhere that the Jr. and some 7800s have slightly different HMOVE circuitry in their TIA chips. I understand that Kool-Aid Man doesn't work on them either because it does funky things with HMOVE/HMxx.

Link to comment
Share on other sites

Hi there!

 

EDIT: I tried putting the HMOVE in the proper place and that appears to fix the problem!   I guess the HMOVE timings are different on the Jr. then?!

 

There seem to be small differences when doing evil things with early/late HMOVEs. I saw a similar oddity a few days ago, when testing Simons "Eurocon 2005" demo, where we just had it the opposite way, it ran fine on the Jr. and had problems on my 6er...

 

An amazingly cool thing would be if you could run Brad Motts test tool on your Jr. and recreate an HMOVE chart just like he did with a "regular" console. So we could possibly single out *unstable* HMOVE timings that are to avoid at all costs.

 

(I'm always scared when coding stuff like that. Thank heavens Star Fire works on both consoles, but I wouldn't dare placing a bet on my recent Worm Whomper demo... Hm... could you possibly give it a try on your Jr.? ;) )

 

Greetings,

Manuel

Link to comment
Share on other sites

Hi there!

 

There seem to be small differences when doing evil things with early/late HMOVEs. I saw a similar oddity a few days ago, when testing Simons "Eurocon 2005" demo, where we just had it the opposite way, it ran fine on the Jr. and had problems on my 6er...

 

An amazingly cool thing would be if you could run Brad Motts test tool on your Jr. and recreate an HMOVE chart just like he did with a "regular" console. So we could possibly single out *unstable* HMOVE timings that are to avoid at all costs.

 

(I'm always scared when coding stuff like that. Thank heavens Star Fire works on both consoles, but I wouldn't dare placing a bet on my recent Worm Whomper demo... Hm... could you possibly give it a try on your Jr.? ;) )

 

Greetings,

Manuel

902968[/snapback]

 

Hi Manuel,

 

Thanks - this is going to be a real pain for 2600 development! At least I have one of the problem consoles to test things on. Does this happen with all Jr. consoles, or is is just the PAL ones? I will run your worm whomper demo after work and let you know the results. I also found Brad Motts Tool in the Stella archives and I will see if I can recreate the table for my Jr. I am hoping that there will be significant overlap ...

 

Thanks,

Chris

Link to comment
Share on other sites

Thanks - this is going to be a real pain for 2600 development!  At least I have one of the problem consoles to test things on.  Does this happen with all Jr. consoles, or is is just the PAL ones?  I will run your worm whomper demo after work and let you know the results.  I also found Brad Motts Tool in the Stella archives and I will see if I can recreate the table for my Jr.  I am hoping that there will be significant overlap

902973[/snapback]

From my experience, only consoles made in China in 1989 or later are affected by the different HMOVE behaviour. Unfortunately this includes all PAL 7800s. Older 2600 Jrs. should work just like the 6- and 4-switch models. At least it is like this with all my PAL consoles.

 

The difference is in HMOVE pulses that happen during the visible part of the scanline. As you might know, the TIA will generate a left-shift pulse every 4 pixels when you trigger a HMOVE. It will continue to do so until the motion counters for all movable objects have been matched with the HMOVE counter. When you trigger HMOVE at the start of VBLANK, all counters will usually have been matched by the end of VBLANK.

 

The only exceptions are when you trigger the Cosmic Ark starfield effect or when you trigger HMOVE during the visible part of the screen. The clock lines for the HMOVE pulses are used for different things during the visible part of the scanline, so the shifting pulses will be ignored on a normal VCS. This is why you get different shifting distances when you trigger HMOVE on different cycles. It depends on how many of the HMOVE pulses happen during VBLANK.

 

On the China-VCS the HMOVE pulses during the visible part of the scanline unfortunately overlap with the display clocks for the player graphics in such a way that those will be canceled out. As a result it will appear that the player graphics get shifted to the right by one pixel for every HMOVE clock. Since HMOVE pulses happen every 4 pixels, they can generate such a shift even in the middle of a player display.

 

So, if you want to keep your game compatible with both types of consoles, you need to avoid moving player graphics with HMOVEs that happen during the visible part of the scanline. But AFAIK only the players are affected by this. So Manuel's worm demo should work fine, since it only uses missiles and the ball. ;)

 

 

Ciao, Eckhard Stolberg

Link to comment
Share on other sites

Hi there!

 

So Manuel's worm demo should work fine, since it only uses missiles and the ball. ;)

 

Phew... thank heavens my worms are safe! ;)

 

Hm... but thinking more about this, the bug in Simons demo resulted from a "deep" HMP1 write, at cycle 23. It worked fine on the (chinese?) Jr. but the sprite occasionally "jumped" on the 6er, as if certain HMP1 values were misinterpreted. Is that related somehow or just another phenomenon?

 

BTW: I know I'm probably asking the world here, but could a future version of Z26 eventually have a "chinese" mode? :ponder:

 

Greetings,

Manuel

Link to comment
Share on other sites

Hi Manuel,

 

Thanks - this is going to be a real pain for 2600 development!  At least I have one of the problem consoles to test things on.  Does this happen with all Jr. consoles, or is is just the PAL ones?  I will run your worm whomper demo after work and let you know the results.  I also found Brad Motts Tool in the Stella archives and I will see if I can recreate the table for my Jr.  I am hoping that there will be significant overlap ...

 

Thanks,

Chris

902973[/snapback]

 

For the record, my Jr is NTSC and had the garbled text. My Jr was made in Taiwan in August 1989 so it's a late model.

 

Like you, I got the text to be ledgible by putting the HMOVE earlier, however there's that 1 pixel shift, did you fix that?

Link to comment
Share on other sites

I tried the HMOVE test program from that link Chris, and got different results between my August 1989 Jr. and Z26 or Stella.

 

First of all, the test code generates 249 lines (as reported by Z26) and is very unstable on my TV.

 

So I increased the active display by 13 lines and the display was less jumpy (but still a bit jumpy).

 

Second, at the default delay of 10 cycles, the Jr. immediately diverges from the emulators. On the Jr. P1 is shifted right once every 8 lines and is symmetric with the second part (group of 8) where p1 is shifted left once every 8 lines.

 

The Jr. and Z26 converge at cycle 74 and then diverge again at cycle 80 with my system showing additional movement right as you go down the screen for the first group of eight (as before)

Link to comment
Share on other sites

Hm... but thinking more about this, the bug in Simons demo resulted from a "deep" HMP1 write, at cycle 23. It worked fine on the (chinese?) Jr. but the sprite occasionally "jumped" on the 6er, as if certain HMP1 values were misinterpreted. Is that related somehow or just another phenomenon?

It could be related. If the HMOVE occured right after the WSYNC, and the HMP1 value was $70 at that time, then overwriting it with something else at cycle 23 should cause the Cosmic Arc starfield effect for player 1. It would last until the next HMOVE. During that effect there would be a new HMOVE clock pulse every 4 pixels for player 1. On the newer Jr. that would result in lots of extra right shifts for player 1, while there would be only left shifts (or no extra shift, if the next HMOVE was already in the next scanline) on the 6er.

 

BTW: I know I'm probably asking the world here, but could a future version of Z26 eventually have a "chinese" mode?  :ponder:

903062[/snapback]

Well, at least you are asking at the right time. ;) We are currently trying to port z26 to C code, which is why there hasn't been a new version in such a long time. We'll probably have to redesign the TIA line rendering code to fix some other inacuracies anyway. So adding an optional "TIA89" mode might be possible. But all that testing for extra shifts while rendering each player pixel might slow things down a lot, so I'm not sure if the new mode would be worth that tradeoff. It should be really simple to add a special warning in the trace log every time you are going to create HMOVE pulses for the player graphics during the visible part of the scanline though.

 

 

Ciao, Eckhard Stolberg

Link to comment
Share on other sites

From my experience, only consoles made in China in 1989 or later are affected by the different HMOVE behaviour. Unfortunately this includes all PAL 7800s. Older 2600 Jrs. should work just like the 6- and 4-switch models. At least it is like this with all my PAL consoles ...

903045[/snapback]

 

Hi Eckhard,

 

Thanks for the technical explanation. I'm not sure if I follow all the details, but if I understand correctly then there is no point generating a new table of HMOVE shift values (using Brad Motts tool) as the display of the player graphics be corrupted by this method?

 

Thanks,

Chris

 

P.S. The worm whomper demo does indeed run fine on this console.

Link to comment
Share on other sites

OK, here is another version of Hunchy 2. The main changes this time are:

  • Arari VCS Jr. Fix
  • Modified Game Tune by supercat
  • PAL Version
  • Reset Button Support

As usual, let me know if you find any bugs or glitches. If you are using a Supercharger then the tune will crash the console if you let it play for too long! Many thanks to supercat for his coding help and suggestions behind the scenes!

 

Thanks,

Chris

h2v07.zip

Edited by cd-w
Link to comment
Share on other sites

Arari Jr. Fix

Works!

 

Great!

 

If you are using a Supercharger then the tune will crash the console if you let it play for too long!

Interesting... why?

903849[/snapback]

 

As I understand it, the Supercharger uses the address $FFF8 to perform bankswitching, and in Hunchy 2, this address is used for the music data. Therefore, when this address is hit in the tune, the supercharger performs a bankswitch and crashes (unless it has been modified).

 

EDIT: I just noticed that I can overlap Space and TimeBar2 in my code which saves 5 bytes at the end. This fixes the Supercharger crashing issue. I will make this change properly in the next release.

 

Chris

Edited by cd-w
Link to comment
Share on other sites

Thanks for the technical explanation.  I'm not sure if I follow all the details, but if I understand correctly then there is no point generating a new table of HMOVE shift values (using Brad Motts tool) as the display of the player graphics be corrupted by this method?

903753[/snapback]

Yes, generating a table for this would be a lot of work, because the final player shifting distance does not only depend on where in the line you do the HMOVE but also on where in the line the player was positioned before. And if the HMOVE clock pulses happen while the player is displayed, the graphics will be corrupted anyway. And since the mechanics behind this effect are already understood quite well, there is no point in generating a new table.

 

BTW, did you check when and where your problematical 2600 Jr. console was manufactured?

 

 

Ciao, Eckhard Stolberg

Link to comment
Share on other sites

...

BTW, did you check when and where your problematical 2600 Jr. console was manufactured?

903928[/snapback]

 

Thanks - I can't see a manufacturing date (perhaps it's inside) - all it says on the underside is: "Atari 2600, PAL-I, Atari Corporation, Made in China, S/N X709 3329215".

 

Chris

Link to comment
Share on other sites

Hi there!

 

So adding an optional "TIA89" mode might be possible. But all that testing for extra shifts while rendering each player pixel might slow things down a lot, so I'm not sure if the new mode would be worth that tradeoff.

 

What? :-o

 

You're saying you're going to knowingly accept imperfect emulation? :-o :-o :-o

 

Just imagine the improvement on Kool-Aide-Man! People could get the game emulated just like they remember it! :lol:

 

P.S. The worm whomper demo does indeed run fine on this console.

 

Yay! Thanks for confirming! As a little thank you I attached the latest version extra for you! Now having worms at different speeds! :)

 

Greetings,

Manuel

worm.zip

Link to comment
Share on other sites

Yay! Thanks for confirming! As a little thank you I attached the latest version extra for you! Now having worms at different speeds! :)

903986[/snapback]

 

Thanks - this is looking great (and I just checked that it still works with my hardware!). Will there be enough time in the kernel to display the player sprites also? There does seem to be a problem with stella (1.4.2), but perhaps this is fixed in the latest version. I have attached a screenshot of the problem below (the worsm appear broken into segments):

 

post-6563-1123103080_thumb.jpg

 

Chris

Link to comment
Share on other sites

Hi there!

 

Thanks - this is looking great (and I just checked that it still works with my hardware!).

Thanks!

 

Will there be enough time in the kernel to display the player sprites also?

Yup. Right now it's only using little more than one line of a 4LK. I still have both sprites available and M0. Actually the plan is to reposition the second sprite as well, so there'll be a hell of things going on on the screen if everything works out :)

 

There does seem to be a problem with stella (1.4.2), but perhaps this is fixed in the latest version.   I have attached a screenshot of the problem below (the worsm appear broken into segments):

Ugh... Stella again... well, last time I checked Stella didn't run on my machine at all... (Same as WinZ26 BTW, there's a bug in the SDL layer regarding my 10 year old Joypad or something like that... :roll: )

 

Hm... so I can only assume that probably the emulation of the 65XX core for "JSR" maybe isn't cycle perfect in Stella or something like that...

 

Greetings,

Manuel

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