Dragon's Cache - Vs. Puzzle Drop Game - Now Available for Purchase!!!

[Revontuli]

Quick fix now that I'm back from a break:

 

DragonsCache_8_3_2020.bas.a78

DragonsCache_8_3_2020.bas.bin

 

Found some inaccuracies when tallying wins/losses/draws in various 2-player modes - bug fixing at this point can be tricky, where a fix in one place introduces bugs in another.  If anyone wants to try 2-player modes, even just as a stress test on their own, that could be handy information for me!

 

It's really a crapshoot if the highscores work in BupSystem.  The completed ROM worked, then broke, then worked again.  One time I literally added a redundant, extra "myTempB = 0" and the attract mode glitch went from broken to fixed.  I add code that has nothing to do with the high score code and it still seems to affect how BupSystem treats the high score behavior - even if the code itself does nothing.  This could signify nothing or something very, very, sinister - Again, I'm hoping the ROM works on the physical Atari 7800 without such problems.

 

Even just playing the game on an emulator to see if I missed any game specific stuff (like the match winner/loser tallies) is invaluable.  I'm planning to get this ready for cartridge *very* soon, so any fixes afterwards will be much trickier to implement

 

[AW127]

Yes, it's really strange. In both new versions, it hangs again when once in the highscore-screen and the player can not return to the menue without making a reset. The game itself always seems to works in "Bup System" in all posted versions, it's just that highscore problem.

 

33 minutes ago, Revontuli said:

One time I literally added a redundant, extra "myTempB = 0" and the attract mode glitch went from broken to fixed.  I add code that has nothing to do with the high score code and it still seems to affect how BupSystem treats the high score behavior - even if the code itself does nothing.

Maybe it could make sense, to give the programer of "Bup System" the info, what exactly you changed in the code and consequences this then had in the emulator. Because you wrote, one time it worked in the emu, then you changed something and stopped working. It could probably help him, to better isolate the problem with this saving of the score in his emulator? I really like "Dragon's Cache" and because i don't have the a real A7800, i usually open the game-rom in "Bup System". Would be great if this problem could be identified and wiped out.

[Revontuli]

I removed a "clearscreen" that might have been superfluous - these seem to work on BupSystem, at least on my machine:

 

DragonsCache_8_3_2020a.bas.a78

DragonsCache_8_3_2020a.bas.bin

Edited August 3, 2020 by Revontuli

[+Trebor]

5 hours ago, Revontuli said:

I removed a "clearscreen" that might have been superfluous - these seem to work on BupSystem, at least on my machine:

Under console hardware, the '8_3_2020a' build has issue(s).

 

It cycles through the title screen and high score entry after initial system power on.

 

However, played the default 4 gems, "Score" game.  Once 'Game Over' was met, it does not advance to high score entry, and the game does not respond to controller button presses or select/reset button presses with an AtariVox/SaveKey present or without it present (Nothing plugged into the Player 2 port).

 

The '8_3_2020' build works perfect under the console hardware with or without an AtariVox/SaveKey present.

[AW127]

14 hours ago, Revontuli said:

I removed a "clearscreen" that might have been superfluous - these seem to work on BupSystem, at least on my machine:

 

 

Hm, i have this highscore problem also with this release, when i use "Bup System". Strange that it works for you. How can that be?

 

Are you really sure? When you start the game in the emu and wait until it goes to the highscore-screen by itself, then in this screen, you can see all the colors in the font and you can also go back to the title-menue by pressing a button?

 

This don't work here on my PC with version 0.9.6.3 of "Bup System". Here the font in the highscore-screen is black/white then, which is always the first sign, that something is wrong. And ideed, then the game hangs and to play again, i must make a reset. In version 6_7_2020 of the game, i can see all the colors of the font in the highscore-screen and with a button-press then, i can go back to the title-menue to play the next round of the game. A difficult problem to identify, really. I played so many games in Bup System, but this here is the only one that makes such kind of problems in this emulator. Annoyingly, it's also a really good game. *lol* 

 

 

 

"Revontuli", one suggestion. When looking at the thread so far, the fact that the game saves the highscore seems to have caused different problems so far. And then there is also the fact, that these saved highscore is gone anyway, when the player ended the game and started it again on the next day. Maybe it could make sense, to release two versions of the game in the future (if this would not cause to much additional work for you?)

 

One version for the real console WITH the highscore-screen, because there this seems to work like it should and a second version for emulators like "Bup System" or "Pro System" and so on, in which this highscore-screen is never shown and the score is not written in. I think, not having this screen is not such a big loss, because like it wrote before, the highscores are not really saved anyway and gone everytime, the user loads the game again. The player can see his score, when a game has ended and he can write it down for himself then by hand, to know which is his real highscore. The player must do this anyway, because the scores are not really saved.

 

What you think about it?

Edited August 3, 2020 by AW127

[Revontuli]

DragonsCache_8_4_2020.bas.a78

DragonsCache_8_4_2020.bas.bin

 

OK - This build should be exactly the same as the 8_3_2020 build, but I want to have this be current version to work off of as I move forward.  Out of curiosity, I gave this a try and it also seems to work on BupSystem on my machine (although the graphics pause a beat longer as it moves to the high score screen after a game) - even though the last one didn't   It might be different from machine to machine, as well.  That said, the physical 7800 is top priority right now, and I can't directly test on one at the moment, so I'm trying to be careful/paranoid.

 

If this version is broken on the physical 7800, then something strange (but not impossible) is going on...

 

The bug testing is very much appreciated - thank you!

[+Trebor]

10 minutes ago, Revontuli said:

If this version is broken on the physical 7800, then something strange (but not impossible) is going on...

 

The bug testing is very much appreciated - thank you!

Under console hardware...

 

Played fine first 4 Gems, 'Score' game.  Saved high score and cycling through screens without issue.

 

Played a second 4 Gems, 'Score' game.  After "Game Over", it became unresponsive to joystick button presses and Select/Reset button presses.

 

Every subsequent try after that continued to be unresponsive after "Game Over" with or without an AtariVox/SaveKey attached, despite power cycling the console off/on.

 

Prior to starting a game though, it cycles between the title and high score screen without issue.

[Revontuli]

 

31 minutes ago, Trebor said:

Under console hardware...

 

Played fine first 4 Gems, 'Score' game.  Saved high score and cycling through screens without issue.

 

Played a second 4 Gems, 'Score' game.  After "Game Over", it became unresponsive to joystick button presses and Select/Reset button presses.

 

Every subsequent try after that continued to be unresponsive after "Game Over" with or without an AtariVox/SaveKey attached, despite power cycling the console off/on.

 

Prior to starting a game though, it cycles between the title and high score screen without issue.

Does the 8_3_2020 build work through multiple games?  The 8_3 and 8_4 builds should be exactly the same (although I'll try and do a diff on the source code to make sure...)

 

EDIT: Another build to try:

DragonsCache_8_4_2020a.bas.a78

DragonsCache_8_4_2020a.bas.bin

Edited August 4, 2020 by Revontuli

[+Trebor]

2 hours ago, Revontuli said:

Does the 8_3_2020 build work through multiple games? 

Under console hardware, the 8_3_2020 build worked fine through multiple games with and without an AtariVox/SaveKey attached.   However, the 8_3_2020a did not even make it to posting the first time around.

 

2 hours ago, Revontuli said:

EDIT: Another build to try:

DragonsCache_8_4_2020a.bas.a78 48.13 kB · 1 download

DragonsCache_8_4_2020a.bas.bin 48 kB · 1 download

The latest, this build 8_4_2020a, under console hardware works perfect again, even through multiple games with and without an AtariVox/SaveKey attached.

[Revontuli]

1 minute ago, Trebor said:

The latest, this build 8_4_2020a, under console hardware works perfect again, even through multiple games with and without an AtariVox attached.

Good to hear!  I'll send this over to Al to test on his end.  With some of the behaviors that have been cropping up, I want to test on as many 7800s as possible.

 

4 hours ago, AW127 said:

Hm, i have this highscore problem also with this release, when i use "Bup System". Strange that it works for you. How can that be?

It could be how the starting memory is "zeroed" - bugs and glitches like this can be a pain to track down, because it could be an issue with the game, the emulator, or even the operating system of the PC one is using to run the emulator.  There's a lot of moving targets.  I've found that the ROM sometimes works on BupSystem and sometimes not, the bug is not always reproducible.  You're in a state where doing the same action produces different outcomes - If you wonder why programmers get grouchy, it's because of bugs like this.

4 hours ago, AW127 said:

Maybe it could make sense, to release two versions of the game in the future (if this would not cause to much additional work for you?)

I can release a more emulator-friendly version, without the high score, but currently the cartridge version is on a bit of a deadline (as physical copies need to be printed/burned/built) so that's taking a much higher priority at the moment.  I did not get any odd behaviors from the MAME-based emulation, so I'm wondering if BupSystem is finding something MAME isn't, but currently the physical 7800 needs to be as stable as possible.  For emulators I can always post another ROM with a fix - that's not really an option with a run of physical cartridges!

[Revontuli]

I'm trying a little test to see if a different way of resetting the RAM might help with BupSystem compatibility.  It seems to work on my machine, but it's always hard to tell with possible memory bugs.  Hopefully this should also still work with hardware and A7800 (it's just one line of code added near the start to zero-out RAM, it's identical to previous builds in every other way.)

 

DragonsCache_10_16_2020.bas.a78

DragonsCache_10_16_2020.bas.bin

[+Trebor]

1 hour ago, Revontuli said:

I'm trying a little test to see if a different way of resetting the RAM might help with BupSystem compatibility.  It seems to work on my machine, but it's always hard to tell with possible memory bugs.  Hopefully this should also still work with hardware and A7800 (it's just one line of code added near the start to zero-out RAM, it's identical to previous builds in every other way.)

 

DragonsCache_10_16_2020.bas.a78 48.13 kB · 3 downloads

DragonsCache_10_16_2020.bas.bin 48 kB · 3 downloads

Within 10 seconds of the game running it crashes.  Happens on both consoles tested on, an AT84 serial and one of my A1 serials, every time.

 

 

[Revontuli]

12 minutes ago, Trebor said:

Within 10 seconds of the game running it crashes.  Happens on both consoles tested on, an AT84 serial and one of my A1 serials, every time.

Is in during a the transition to the high scores from the title screen, possibly?  Or at the very start of that transition?  That's about the length of time taken, and where the crash happened before.

 

Grrr...if the hardware is crashing with this "fix" I', really not sure what is going, on, then.  The only thing I added to this build was the line:

 

memset $2200 0 1535

 

in my "reset code" at the beginning, which clears the main block of RAM.  My hope was that if some uninitialized "garbage memory" was causing the BupSystem crash, then this might solve it.  If it's directly or indirectly causing hardware crashes, that's a little unsettling...

 

Explicitly zeroing RAM might be causing issues on its own, but both BupSystem and A7800 seem to run the image fine on my machine, which I realize doesn't mean a whole lot.  Anyone looking, feel free to pipe in if any of this sounds fishy or if it sounds like I'm doing something ill-advised   

Edited October 17, 2020 by Revontuli

[+Trebor]

7 hours ago, Revontuli said:

Is in during a the transition to the high scores from the title screen, possibly?  Or at the very start of that transition?  That's about the length of time taken, and where the crash happened before. 

It's more the when than the where.  It occurred within 00:04 of a 'Race' game, that was started as soon as possible.  It happened in just letting the game sit at the menu/title screen.  It froze again at the middle of a 'Score' game. 

 

The item they all had in common was it taking place within ~10 seconds of the game running.

 

I can test more later tonight, if/as needed.

[+Muddyfunster]

I use memset in EXO and I've had problems with blackscreens but only under emulation, not real hardware. On real hardware the problem doesn't seem to manifest.

[+RevEng]

In this latest version, when you clear a group of gems, part of the game code tries to write to the cart rom address space. (assuming accidentally) Trebor uses an nvram based flash cart, which would explain his crashing out in real hardware.

 

If you PM me the list file that was generated along with your those latest attached roms, I can tell you which command is doing this.

 

[edit] teaching a man to fish... if you want to check it out yourself, have a look at quality check your beta games with the debugger section of the "introduction to the mame debugger" wiki page.

[TailChao]

2 hours ago, RevEng said:

In this latest version, when you clear a group of gems, part of the game code tries to write to the cart rom address space, when you first try to clear a gem. (assuming accidentally) Trebor uses an nvram based flash cart, which would explain his crashing out in real hardware.

To dive into this for a bit - as some of the issues seem to be recurring...

 

When something "works on the hardware" this also includes what type of cartridge (or flash cartridge) you're using, and how that affects the game software. What's the exact partitioning and r/w setup of $4000 - $FFFF? Is the internal memory and any EXRAM initialized for you? Are there any "secret" registers you might be hitting by accident?

 

 

2 hours ago, RevEng said:

[edit] teaching a man to fish... if you want to check it out yourself, have a look at quality check your beta games with the debugger section of the "introduction to the mame debugger" wiki page.

Agreed, with the addition that you should also check for (unintentional) accesses in unallocated regions of memory by either Sally or Maria. The latter is particularly dangerous since fetching a garbage DLL could trigger an NMI when you're not expecting it.

 

If I remember right, this is one of ProSystem's biggest faults since it treats any unallocated areas as zero instead of open bus - not sure if any of its forks change this.

[Revontuli]

10 hours ago, RevEng said:

[edit] teaching a man to fish... if you want to check it out yourself, have a look at quality check your beta games with the debugger section of the "introduction to the mame debugger" wiki page.

I may still PM you later, but this got me to find a potential bug I'll try and properly fix today.  Thank you!

 

7 hours ago, TailChao said:

When something "works on the hardware" this also includes what type of cartridge (or flash cartridge) you're using, and how that affects the game software. What's the exact partitioning and r/w setup of $4000 - $FFFF? Is the internal memory and any EXRAM initialized for you? Are there any "secret" registers you might be hitting by accident?

I think this bug is actually different from the other one I was *trying* to fix - I think what's causing Trebor's crashing is poking the wrong value/place when I animate a set of matched gems breaking.  At the very least it flagged the invalid memory access breakpoint in MAME, and looking at how I'm doing things in code this particular bug could be very much my fault If the problem is what I'm thinking, it also makes sense that it'd be invisible or not necessarily crop up all the time, or be glossed over on an emulator - I'm poking tilemaps and asking for sprite info using variables to animate, so I can see how that might cause problems.  I think I've a fix, but I want to make sure.  I'll try and get a new ROM up in a few hours.

 

To review, though, the *original* bug I was trying to fix is bringing in a customized high score leaderboard.  *That* seems to work on MAME and Flashcarts, but not on BupSystem.  I was curious if explicitly zeroing out the RAM at the very beginning might help.  Also, the high score leaderboard *doesn't* seem to trip the debugger breakpoint outlined above, so whatever might be wrong isn't being caught by that particular check.

 

Thank you everyone!

Edited October 17, 2020 by Revontuli

[AW127]

"Revontuli", i have tried your last posted version 10_16_2020 in BupSystem and the highscore-screen problem is still there. When the game goes into the scorescreen one time, it hangs there and the user must make a reset, otherwise he can not return to the main-menue of the game.

A crash, i don't had today, when i played the newest version in BupSystem for around 10 minutes in Score mode. I only recognized the highscore problem which is still there.

 

Still, the version 6_7_2020 that was posted in entry #151, is the latest one, that works perfect in BupSystem. But thanks, that you still work on it, to solve this highscore-incompatibility to the emulator. Seems to be a tricky thing to solve, either in the game or the emulator or whatever is causing this highscore-screen problem here.

Edited October 17, 2020 by AW127

[Revontuli]

I'm taking a longer look at the code, and finding a few things I should fix or at least make more sturdy in the code - I'll try to post a new build sometime this weekend or early next week.  Thanks to everyone for their help!

[Revontuli]

I don't think the BupSystem bug is fixed (I'm still trying to sniff out the origin of that with some help), but this should hopefully fix the matched gems crashing bug:

 

DragonsCache_10_23_2020.bas.a78

DragonsCache_10_23_2020.bas.bin

[Revontuli]

With a lot of help from RevEng we've found a possible workaround - there seems to be an issue when the game tries to detect external hardware for saving scores when in BupSystem - telling the ROM there's no high score device seems to get around the crash.  I'm uploading a cartridge version and a "BupSystem compatible" version for those who want to try either:

 

DragonsCache_10_24_2020.bas.a78

DragonsCache_10_24_2020_BupSystem.bas.a78

 

DragonsCache_10_24_2020.bas.bin

DragonsCache_10_24_2020_BupSystem.bas.bin

 

Any further testing on hardware would be appreciated - this search did help me find another, very sinister bug in the cart version.  Many thanks to everyone for bug hunting!

Edited October 25, 2020 by Revontuli

[+Trebor]

The cart version goes right to the "Score" game menu under real hardware.  It does play fine though.  However, there is no way to even access the "Main" menu with game type selection.

[Revontuli]

18 hours ago, Trebor said:

The cart version goes right to the "Score" game menu under real hardware.  It does play fine though.  However, there is no way to even access the "Main" menu with game type selection.

That's very strange - this doesn't happen with the earlier builds, correct?  

 

This *would* happen if the game registered the joystick button being pressed repeatedly - I'll take a look on my end, the only thing I can think of off the bat is to possibly try another controller, if possible.  I'll see what else might be the issue, although I'd welcome any input from others!

 

EDIT: "Back" should at least move you back to the title screen - does this work?

Edited October 26, 2020 by Revontuli

[+Trebor]

12 hours ago, Revontuli said:

That's very strange - this doesn't happen with the earlier builds, correct?  

Correct.  This is a first ever for this issue.

 

12 hours ago, Revontuli said:

This *would* happen if the game registered the joystick button being pressed repeatedly - I'll take a look on my end, the only thing I can think of off the bat is to possibly try another controller, if possible.  I'll see what else might be the issue, although I'd welcome any input from others!

I have several consoles and numerous controllers.  A few consoles are hooked up simultaneously.  The issue occurs on both an AT84 serial and an A3 serial with two different joysticks.  Just to be clear, the game does not start up automatically, nor does it enter initials automatically on the high score entry screen.  It allows free movement up and down through the various options within the "Score" game menu.

 

Quote

EDIT: "Back" should at least move you back to the title screen - does this work?

There is no "Back" option.  The options listed are:

 

1 PLAYER

2 PLAYERS 

MUSIC: A

GEMS:

  [4 DEFAULT ONES]

 

If I let the game just run, it cycles between the above and the high score entry screen for "FOUR GEMS" ~12 seconds.

 

*EDIT: P.S. Well, I'm an idiot.  For some reason I had it fixed in my mind game mode was selected first and then the above appears.  Humble apologies here.  Extra embarrassing to go through the same motions on two different consoles and not come to a realization.  

 

Anyhow, it's working just fine for all modes.  After selecting number of players I am presented with the Game Mode option screen.  All game modes are working beautifully.

 

Wow, I need more sleep or a vacation, or both...lol.