Action 53 volume 3
Moderator: Moderators
Re: Action 53 volume 3
Status update: Today I recovered the files for volume 3 and got it building on volume 4's codebase, with the new versions of Brick Breaker and Flappy Jack.
Brick Breaker and Jupiter Scope have in common that they occupy the bottom half of a 32 KiB bank using the "submulti" mechanism, which puts two 16K PRG banks into one outer bank. When a submulti is running, the game's 16K bank is mirrored into both $8000 and $C000 using UNROM (180) mode for the bottom half game or UNROM (2) mode for the top half game. The exit patch for the bottom half game involves switching the second half into $C000 and then running the top half game's exit patch, which switches to the menu bank. This process works every time in FCEUX, but then FCEUX always stops execution at the same point in a frame. So just to make extra sure, I've added 3 bytes to the bottom half exit patch to disable NMI (which toploaders don't do on reset).
I don't expect volume 4 to use submulti because CNROM entries outnumber NROM-128 entries to such an extent that there isn't enough space in unused portions of PRG ROM banks to hold all their compressed CHR data.
Does this build work better? If so, that leaves one more thing for me to do, namely restore the ability to customize text displayed over the title screen.
Brick Breaker and Jupiter Scope have in common that they occupy the bottom half of a 32 KiB bank using the "submulti" mechanism, which puts two 16K PRG banks into one outer bank. When a submulti is running, the game's 16K bank is mirrored into both $8000 and $C000 using UNROM (180) mode for the bottom half game or UNROM (2) mode for the top half game. The exit patch for the bottom half game involves switching the second half into $C000 and then running the top half game's exit patch, which switches to the menu bank. This process works every time in FCEUX, but then FCEUX always stops execution at the same point in a frame. So just to make extra sure, I've added 3 bytes to the bottom half exit patch to disable NMI (which toploaders don't do on reset).
I don't expect volume 4 to use submulti because CNROM entries outnumber NROM-128 entries to such an extent that there isn't enough space in unused portions of PRG ROM banks to hold all their compressed CHR data.
Does this build work better? If so, that leaves one more thing for me to do, namely restore the ability to customize text displayed over the title screen.
- Attachments
-
- a53vol3-page16.7z
- (413.06 KiB) Downloaded 1797 times
Re: Action 53 volume 3
Thanks for your efforts.
I've noticed a very, very, very minor issue with Goddess which my Obsesive Compulsive self can't let go: it's v1.5 but it says 1.3 on the title screen. Would it be much of a hassle if I submit a fixed version? If it is, I can live with the 1.3
I've noticed a very, very, very minor issue with Goddess which my Obsesive Compulsive self can't let go: it's v1.5 but it says 1.3 on the title screen. Would it be much of a hassle if I submit a fixed version? If it is, I can live with the 1.3
Re: Action 53 volume 3
The version string ("1.3") is stored at $DD20 in the iNES ROM, which corresponds to $DD10 in the fixed bank. So changing the byte at $DD12 to $35 fixed this. The Action 53 builder can replace short hex strings without needing to change the ROM file itself.
It's patch1 (not patch3 as might be expected for the fixed bank of a 64 KiB UNROM) because the prgunused and patch commands count 32K banks.
tl;dr: No worries.
Code: Select all
; The version is 1.5, but the ROM erroneously says 1.3. Fix this
patch1=DD12=35
tl;dr: No worries.
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Action 53 volume 3
Thanks for the effort on this Tepples, I'll test it out today and report back.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Re: Action 53 volume 3
Thank youtepples wrote:The version string ("1.3") is stored at $DD20 in the iNES ROM, which corresponds to $DD10 in the fixed bank. So changing the byte at $DD12 to $35 fixed this. The Action 53 builder can replace short hex strings without needing to change the ROM file itself.It's patch1 (not patch3 as might be expected for the fixed bank of a 64 KiB UNROM) because the prgunused and patch commands count 32K banks.Code: Select all
; The version is 1.5, but the ROM erroneously says 1.3. Fix this patch1=DD12=35
tl;dr: No worries.
Re: Action 53 volume 3
4 day ping.
The next build will include space for a gift message of up to 26 characters and 128 pixels.
The next build will include space for a gift message of up to 26 characters and 128 pixels.
Re: Action 53 volume 3
No Jupiter in Jupiter Scope. Mirroring problem?
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Action 53 volume 3
Thanks for the poke Tepples, All the repairs to the individual roms appear corrected. The reset lock up problem still seems to be there. FWIW Jupiter scope is the easiest for me to replicate with and it seems like reset typically works from title screen, but resetting while playing or on game over screen locks up the cart/console more often than not. But IDK if it's worth getting to worked up about at this point since it's not looking to be an easy fix. I can get you a cart to allow you to build and test 1MByte roms on if you'd like.
Oh I didn't notice that, I'm not even sure I've seen Jupiter in the back ground. ever..?nin-kuuku wrote:No Jupiter in Jupiter Scope. Mirroring problem?
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Re: Action 53 volume 3
I fixed the missing Jupiter in Jupiter Scope problem in my local build. It was indeed mirroring.
Another problem with fixing freezes that occur on hardware and do not occur in an emulator is that I don't own a logic analyzer with which to pinpoint which instruction caused the freeze. I'd be interested in ways to pinpoint which instruction caused the freeze without needing to purchase and use a logic analyzer.
I guess I'll have to get my (old model) Kazzo working again in GNU/Linux. The last time I tried it was several years ago, before I started using GNU/Linux almost exclusively.
Another problem with fixing freezes that occur on hardware and do not occur in an emulator is that I don't own a logic analyzer with which to pinpoint which instruction caused the freeze. I'd be interested in ways to pinpoint which instruction caused the freeze without needing to purchase and use a logic analyzer.
I guess I'll have to get my (old model) Kazzo working again in GNU/Linux. The last time I tried it was several years ago, before I started using GNU/Linux almost exclusively.
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Action 53 volume 3
I've got a new software and firmware build that runs in linux. I'll share it with you before I get the board sent your way. The old software and firmware won't even support flashing this new board design so don't waste your time with that.tepples wrote:I guess I'll have to get my (old model) Kazzo working again in GNU/Linux. The last time I tried it was several years ago, before I started using GNU/Linux almost exclusively.
I don't want to delay the release to sort out this reset issue, but with everything else on my plate at the moment I won't have time to release A53 for a few more weeks. So if we can manage a remedy in that time all the better. If not, we'll just move forward with the build that correct JScope and adds in custom messages.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Re: Action 53 volume 3
This fixes the display of Jupiter and adds enough space for a 2-line gift message. But I still can't replicate the Reset freeze in an emulator.
- Attachments
-
- a53vol3_giftmessage.7z
- (413.35 KiB) Downloaded 440 times
Re: Action 53 volume 3
This screen? if so, AFAIK coredump is not located directly under any hardware vector and only should pop up if the A and B buttons are pressed when the menu starts up.infiniteneslives wrote:I did get a core dump screen from brick breaker one time suggesting the reset vectors weren't in place.
Though now that I think of if, it would have a high probability to run correctly if something jumped into the middle of it, as it's whole state is contained in just 1 CPU register.
Re: Action 53 volume 3
Is this being tested on a top-loader (HVC-* or NES-101) or a front-loader (NES-001)? It matters because a front-loader disables NMI on reset and a top-loader doesn't.
My next direction is to log all writes to the mapper ($5000-$5FFF and $8000-$FFFF) from game start to reset, in order to test for defects in the implementation of the mapper in the CPLD that depend on write order. I remember FCEUX having such order dependencies.
My next direction is to log all writes to the mapper ($5000-$5FFF and $8000-$FFFF) from game start to reset, in order to test for defects in the implementation of the mapper in the CPLD that depend on write order. I remember FCEUX having such order dependencies.
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Action 53 volume 3
Was better part of a month ago now, but I believe so. I've seen the Lizard crash screen a number of times lately (poor connection at powerup when testing) so my photo memory is a little blurry. I just recall seeing something that fairly obviously looked like a blue screen crash report.JRoatch wrote:This screen? if so, AFAIK coredump is not located directly under any hardware vector and only should pop up if the A and B buttons are pressed when the menu starts up.infiniteneslives wrote:I did get a core dump screen from brick breaker one time suggesting the reset vectors weren't in place.
Though now that I think of if, it would have a high probability to run correctly if something jumped into the middle of it, as it's whole state is contained in just 1 CPU register.
I'm testing on a front loader. Although I've also tested on a clone console and had no issues there. I have a few other consoles to test on including AVS and such so I'll try to see if it's limited to one specific console or not.
EDIT: With there being a significant amount of logic to spare on the CPLD, I'm wondering if it would be worthwhile to implement a hardware mapper register reset that detects reset condition on CPU A0 and/or M2 and resets all mapper registers. Guessing that may be a useful feature for rom builder tool as well..? That logic may not be as easily implemented on my 32 macrocell board if we step back down to 512KB PRG-ROM on future volumes, but I should be able to easily do it on this volume as I have a ~20Mhz oscillator and a plethora logic cells on chip at my disposal.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Re: Action 53 volume 3
Surely all you need is one spare input, and the diode-resistor-capacitor detector externally?infiniteneslives wrote:That logic may not be as easily implemented on my 32 macrocell board if we step back down to 512KB PRG-ROM on future volumes