In Nintendulator and my emulator, if you reset Micro Machines, it crashes the CPU (it jumps to a bad location and executes a KIL instruction). But, I have yet to figure out why. It must be sensitive to initial memory values or the state of the CPU. Anyone have a clue on this one?
Did you try to reset twice in a row?
I don't own a copy of Micro Machines, but I do own a copy of Bee 52, and I know that all Codemasters games share library code, such as the "happy face" ROM test and possibly the CHR codec. While testing the Codemasters logo screen for zeroone, I discovered that if I press Reset once, the power light turns off and stays off. If I press Reset again, it comes back up. Perhaps a Reset press at certain points in the program confuses the code that drives the CIC stun circuit.
I don't own a copy of Micro Machines, but I do own a copy of Bee 52, and I know that all Codemasters games share library code, such as the "happy face" ROM test and possibly the CHR codec. While testing the Codemasters logo screen for zeroone, I discovered that if I press Reset once, the power light turns off and stays off. If I press Reset again, it comes back up. Perhaps a Reset press at certain points in the program confuses the code that drives the CIC stun circuit.
tepples wrote:
Did you try to reset twice in a row?
I don't own a copy of Micro Machines, but I do own a copy of Bee 52, and I know that all Codemasters games share library code, such as the "happy face" ROM test and possibly the CHR codec. While testing the Codemasters logo screen for zeroone, I discovered that if I press Reset once, the power light turns off and stays off. If I press Reset again, it comes back up. Perhaps a Reset press at certain points in the program confuses the code that drives the CIC stun circuit.
I don't own a copy of Micro Machines, but I do own a copy of Bee 52, and I know that all Codemasters games share library code, such as the "happy face" ROM test and possibly the CHR codec. While testing the Codemasters logo screen for zeroone, I discovered that if I press Reset once, the power light turns off and stays off. If I press Reset again, it comes back up. Perhaps a Reset press at certain points in the program confuses the code that drives the CIC stun circuit.
It's a bit difficult to reset a crashed CPU in an emulator.
Instead of choosing Emulation > Soft Reset (FCEUX SDL) or NES > Reset (FCEUX Windows) or Nintendulator's counterpart once, choose the menu item twice.
tepples wrote:
Instead of choosing Emulation > Soft Reset (FCEUX SDL) or NES > Reset (FCEUX Windows) or Nintendulator's counterpart once, choose the menu item twice.
I don't follow. Can you please clarify what you want me to try?
I want you to try a soft reset in your emulator, but try it twice in a row. If the first leads to a STP (also called KIL), the second may cause execution to continue.
Or am I misunderstanding what you meant by "a crashed CPU"? Is your emulator's core actually crashing? Or does a soft reset fail to pull it out of STP?
Or am I misunderstanding what you meant by "a crashed CPU"? Is your emulator's core actually crashing? Or does a soft reset fail to pull it out of STP?
tepples wrote:
I want you to try a soft reset in your emulator, but try it twice in a row. If the first leads to a STP (also called KIL), the second may cause execution to continue.
Or am I misunderstanding what you meant by "a crashed CPU"? Is your emulator's core actually crashing? Or does a soft reset fail to pull it out of STP?
Or am I misunderstanding what you meant by "a crashed CPU"? Is your emulator's core actually crashing? Or does a soft reset fail to pull it out of STP?
Ah. I understand now.
The second reset does pull it out of the halt state; however, it shortly thereafter executes the same KIL instruction that halted it on the first reset. Successive resets produce more halts.
Edit: For testing purposes, I modified my emulator to clear main memory and vram on reset, to reset all the mapper banks and to clear all the CPU registers and flags. And, the CPU still jams on reset! That's really strange. Some other state information is causing this.
Create a trace log from a power-on, then from a soft reset. See where they diverge.
thefox wrote:
Create a trace log from a power-on, then from a soft reset. See where they diverge.
Code:
BFC8 CA DEX A:0B X:B3 Y:01 P:A5 SP:FB CYC:302 SL:240
BFC9 D0 FD BNE $BFC8 A:0B X:B3 Y:01 P:A5 SP:FB CYC:308 SL:240
BFC8 CA DEX A:0B X:B2 Y:01 P:A5 SP:FB CYC:317 SL:240
BFC9 D0 FD BNE $BFC8 A:0B X:B2 Y:01 P:A5 SP:FB CYC:323 SL:240
BFC8 CA DEX A:0B X:B1 Y:01 P:A5 SP:FB CYC:332 SL:240
BFC9 D0 FD BNE $BFC8 A:0B X:B1 Y:01 P:A5 SP:F8 CYC:338 SL:240
0300 4C 1A FC JMP $FC1A A:0B X:B1 Y:01 P:A5 SP:F8 CYC: 27 SL:241
FC1A A6 21 LDX $21 = FA A:0B X:FA Y:01 P:A5 SP:F8 CYC: 36 SL:241
FC1C 9A TXS A:0B X:FA Y:01 P:A5 SP:FA CYC: 45 SL:241
FC1D 6C 03 03 JMP ($0303) = 9EC7 A:0B X:FA Y:01 P:A5 SP:FA CYC: 51 SL:241
9EC7 33 99 RLA ($99),Y = 0000 @ 0001 = 78 A:01 X:FA Y:01 P:24 SP:FA CYC: 66 SL:241
9EC9 CC E6 72 CPY $72E6 = 00 A:01 X:FA Y:01 P:25 SP:FA CYC: 90 SL:241
9ECC 90 3C BCC $9F0A A:01 X:FA Y:01 P:25 SP:FA CYC:102 SL:241
9ECE 18 CLC A:01 X:FA Y:01 P:24 SP:FA CYC:108 SL:241
9ECF 00 BRK A:01 X:FA Y:01 P:24 SP:F7 CYC:114 SL:241
FFFF FF 00 F1 ISB $F100,X @ F1FA = 53 A:AC X:FA Y:01 P:A4 SP:F7 CYC:135 SL:241
BFC9 D0 FD BNE $BFC8 A:0B X:B3 Y:01 P:A5 SP:FB CYC:308 SL:240
BFC8 CA DEX A:0B X:B2 Y:01 P:A5 SP:FB CYC:317 SL:240
BFC9 D0 FD BNE $BFC8 A:0B X:B2 Y:01 P:A5 SP:FB CYC:323 SL:240
BFC8 CA DEX A:0B X:B1 Y:01 P:A5 SP:FB CYC:332 SL:240
BFC9 D0 FD BNE $BFC8 A:0B X:B1 Y:01 P:A5 SP:F8 CYC:338 SL:240
0300 4C 1A FC JMP $FC1A A:0B X:B1 Y:01 P:A5 SP:F8 CYC: 27 SL:241
FC1A A6 21 LDX $21 = FA A:0B X:FA Y:01 P:A5 SP:F8 CYC: 36 SL:241
FC1C 9A TXS A:0B X:FA Y:01 P:A5 SP:FA CYC: 45 SL:241
FC1D 6C 03 03 JMP ($0303) = 9EC7 A:0B X:FA Y:01 P:A5 SP:FA CYC: 51 SL:241
9EC7 33 99 RLA ($99),Y = 0000 @ 0001 = 78 A:01 X:FA Y:01 P:24 SP:FA CYC: 66 SL:241
9EC9 CC E6 72 CPY $72E6 = 00 A:01 X:FA Y:01 P:25 SP:FA CYC: 90 SL:241
9ECC 90 3C BCC $9F0A A:01 X:FA Y:01 P:25 SP:FA CYC:102 SL:241
9ECE 18 CLC A:01 X:FA Y:01 P:24 SP:FA CYC:108 SL:241
9ECF 00 BRK A:01 X:FA Y:01 P:24 SP:F7 CYC:114 SL:241
FFFF FF 00 F1 ISB $F100,X @ F1FA = 53 A:AC X:FA Y:01 P:A4 SP:F7 CYC:135 SL:241
The deviation happens at that spontaneous jump to $0300. From the SL, it coincides with NMI. Prior to the jump, it was in loop that was decrementing X to 0. I will keep investigating.
Edit:
The last bank in mapper 71 is fixed. Here is the NMI address:
Code:
0F:FFFA:00 BRK
0F:FFFB:03 UNDEFINED
0F:FFFB:03 UNDEFINED
NMI directs execution to code loaded into RAM.
Edit 2:
I can fix the problem by writing $00 to the PPU CTRL register ($2000) on reset, disabling NMI's. Should that be happening?
zeroone wrote:
I can fix the problem by writing $00 to the PPU CTRL register ($2000) on reset, disabling NMI's. Should that be happening?
Yes on NES. No on Famicom (reset line is not connected to PPU).
http://wiki.nesdev.com/w/index.php/PPU_power_up_state
So Micro Machines has yet another way that it runs properly on an NES but not a Famicom! Interesting.
(The other way is reading $2004.)
(The other way is reading $2004.)
rainwarrior wrote:
So Micro Machines has yet another way that it runs properly on an NES but not a Famicom! Interesting.
(The other way is reading $2004.)
(The other way is reading $2004.)
It sounds like it should also fail on reset for the NES-101. If anyone has the hardware, please confirm.
What is the reading $2004 issue?
$2004 isn't readable on a lot of Famicom units. Micro Machines polls it to time some raster effects.
zeroone wrote:
I can fix the problem by writing $00 to the PPU CTRL register ($2000) on reset, disabling NMI's. Should that be happening?
The wiki says clearly to set $2000 to $00 on powerup and RESET in the NTSC version. Well, so the PPU state is different in a Famicom..???
Zepper wrote:
zeroone wrote:
I can fix the problem by writing $00 to the PPU CTRL register ($2000) on reset, disabling NMI's. Should that be happening?
The wiki says clearly to set $2000 to $00 on powerup and RESET in the NTSC version. Well, so the PPU state is different in a Famicom..???
Indeed:
The wiki wrote:
On top-loaders (Famicom, NES-101), the Reset button resets only the CPU.
Ah... the full quote.
"The Reset button on the Control Deck resets the PPU only on the front-loading NES (NES-001). On top-loaders (Famicom, NES-101), the Reset button resets only the CPU".
Interesting. Just tested it in my emulator and - indeed - it scrambles the image and got opcode $12 as invalid.
"The Reset button on the Control Deck resets the PPU only on the front-loading NES (NES-001). On top-loaders (Famicom, NES-101), the Reset button resets only the CPU".
Interesting. Just tested it in my emulator and - indeed - it scrambles the image and got opcode $12 as invalid.
Anyone know a guy who has a copy of Micro Machines and an NES-101?
tepples wrote:
Anyone know a guy who has a copy of Micro Machines and an NES-101?
I own a toploader NES, swapped duty cycles, but unsure if it's a 101.
About the cart (USA?), I could buy it, but... not looking in good condition.
Zepper wrote:
I own a toploader NES, swapped duty cycles, but unsure if it's a 101.
"NES-101" is the model number of the official top-loading NES, which the Phantom System definitely isn't. I do remember my clones (Turbo Game and Dynavision) resetting only the CPU though... Maybe the Phantom System is the same?
I have an NES-101, but the only Camerica cart I own is Bee 52.
It's a custom brazilian NES board. A toploader, probably famiclone.
A flash cart should suffice, unless you think there's some yet-misunderstood feature of the cartridge? What's the goal of the test, tepples?
The goal of the test is to see whether pressing Reset freezes an authentic copy of Micro Machines on systems that don't reset the PPU along with the CPU. If so, we can list it in Game bugs.
No japanese version, right?
EDIT: no good offers... I could buy one of these. No way.
In Brazil, it's even rare and hyper-overpriced.
https://www.amazon.com/gp/offer-listing ... rtIndex=20
EDIT: no good offers... I could buy one of these. No way.
In Brazil, it's even rare and hyper-overpriced.https://www.amazon.com/gp/offer-listing ... rtIndex=20
Well, I've played Ultimate Stuntman on a Hi-Top Game, a NES clone from Millar.
If I remember correctly, I needed to press reset more than once to go back to title.
It should behave similar to Micro Machines, should it?
I also think that the Gradiente's Phantom System is the only clone that also resets the PPU, at least the only one I know of. When the reset button is pressed it blacks out the screen.
I'll try to do some tests tomorrow to confirm this, since the one I got is almost fully functional.
If I remember correctly, I needed to press reset more than once to go back to title.
It should behave similar to Micro Machines, should it?
I also think that the Gradiente's Phantom System is the only clone that also resets the PPU, at least the only one I know of. When the reset button is pressed it blacks out the screen.
I'll try to do some tests tomorrow to confirm this, since the one I got is almost fully functional.
Confirmed.
I tested Ultimate Stuntman on the Hi-Top Game.
Pressing reset mutes some audio channels and after the intro ends, it goes back to Codemaster's logo.
On the Phantom System the game goes back to the logo as soon as I press reset.
Micro Machines should behave the same way, correct?
I tested Ultimate Stuntman on the Hi-Top Game.
Pressing reset mutes some audio channels and after the intro ends, it goes back to Codemaster's logo.
On the Phantom System the game goes back to the logo as soon as I press reset.
Micro Machines should behave the same way, correct?
Hmm... now I wonder...
If I use a 72-to-60pin adaptor and plug MicroMachines in an original Famicom... would it work?
Has the Famicom any kind of protection?
If I use a 72-to-60pin adaptor and plug MicroMachines in an original Famicom... would it work?
Has the Famicom any kind of protection?
I think it doesn't have any kind of protection.
I don't know if the Famicom also resets the PPU, but the Phantom System definetively does!
I don't know if the Famicom also resets the PPU, but the Phantom System definetively does!
There's nothing preventing NES cartridges from working on the Famicom besides the different connector. If a game doesn't work, the software is to blame.
Fisher wrote:
I don't know if the Famicom also resets the PPU
thefox wrote:
No on Famicom (reset line is not connected to PPU).
I should have read the thread more carefully.I just don't have an original Micro Machines, and the prices here in Brazil, as stated before, just don't fit my pockets
But Ultimate Stuntman should behave the same way.
EDIT: Is just me that's finding funny 3 brazilians talking in another language in a foreign forum?
In fact, I just couldn't find a forum as good as nesdev to suit my NES needs.
I've even come across an old brazilian forum that a guy asked me money to give information...
Unfortunatelly this forum doesn't exists anymore.
Fisher wrote:
Is just me that's finding funny 3 brazilians talking in another language in a foreign forum?
I'm used to talking about NESDev exclusively in english, so talking in portuguese would actually feel weirder to me.
Quote:
In fact, I just couldn't find a forum as good as nesdev to suit my NES needs.
NESDev is the best there is!
Quote:
I've even come across an old brazilian forum that a guy asked me money to give information...
That's terrible!
Quote:
Unfortunatelly this forum doesn't exists anymore.
The forum where the guy tried to extort you? I'd say it's a fortunate thing it doesn't exist anymore.
Yes! Nesdev rulz!! I'm learning a lot! And people here are polite.
I'm kind of disappointed with the Brazilian forums...
Unless there's some of them I had not come across, most are very superficial even for me that consider myself a rookie.
But back on topic:
Were these tests somehow conclusive?
Should I try to capture some videos of the clones?
I think I should try to explain the audio bug more clearly...
I'll look this back tomorrow.
I'm kind of disappointed with the Brazilian forums...
Unless there's some of them I had not come across, most are very superficial even for me that consider myself a rookie.
But back on topic:
Were these tests somehow conclusive?
Should I try to capture some videos of the clones?
I think I should try to explain the audio bug more clearly...
I'll look this back tomorrow.
I can verify that it does hang on reset on my Famicom, using a PowerPak or Everdrive N8 with a 72-60 pin adapter. It also has some minor visual artifacts / jumpy screen due to the known problem with $2004. These problems do not occur on my NES, precisely as expected. (In case it wasn't made clear already: this game was not released in Japan.)
I don't really see a necessity to seek out the original cart, though. All of the individual factors involved seem to be well understood. It's a very simple discrete mapper, and the effects involved aren't directly related to the mapper anyway.
Is there some expectation that what we know doesn't precisely describe the behaviour of the real cart already?
I mean, if someone has it on hand already, go ahead and test it if you like, but I don't think the potential for gained knowledge is very high.
I don't really see a necessity to seek out the original cart, though. All of the individual factors involved seem to be well understood. It's a very simple discrete mapper, and the effects involved aren't directly related to the mapper anyway.
Is there some expectation that what we know doesn't precisely describe the behaviour of the real cart already?
I mean, if someone has it on hand already, go ahead and test it if you like, but I don't think the potential for gained knowledge is very high.
rainwarrior wrote:
I don't really see a necessity to seek out the original cart, though. [...] Is there some expectation that what we know doesn't precisely describe the behaviour of the real cart already?
The expectation is not among us as much as among people who don't know what they don't know. I wanted a way to make the misbehavior obvious enough for even the lowest common denominator who frequent YouTube: "I plug this cartridge into this console, and this bug happens." By designing a demonstration that uses all original parts that one could reasonably have encountered prior to 1997, when emulation started to take off, we eliminate cause for comments to the effect "You cheated; you used a flash cart and a Famicom." It's the same naivety that leads people to believe that use of the iNES container format in Virtual Console implies Nintendo copied games from infringing ROM sites.
Hrm, I was expecting that link to go to Donald Rumsfeld's "unknown unknowns" quote, but regardless: IMO there's not even a hint of an unknown here to investigate at this point.
I mean, if somebody really wants to own this game that's fine by me, but I'm just trying to suggest that we almost certainly have it nailed already. (If you feel like buying the game to prove that we have not, I'm not gonna stand in your way.)
But you're the one questioning the legitimacy of the emulated version in this case. O_o?
I mean, if somebody really wants to own this game that's fine by me, but I'm just trying to suggest that we almost certainly have it nailed already. (If you feel like buying the game to prove that we have not, I'm not gonna stand in your way.)
tepples wrote:
It's the same naivety that leads people to believe that use of the iNES container format in Virtual Console implies Nintendo copied games from infringing ROM sites.
But you're the one questioning the legitimacy of the emulated version in this case. O_o?
Right now I personally am satisfied. There is no pressing need to reproduce the test with all original parts. But if we eventually make a video demonstrating this bug to the public, I'd prefer it be done with original parts to avoid the appearance of impropriety.
Fine, fine... 
So I can buy an used Famicom and that Micro Machines cartridge. It's always interesting stuff!
So I can buy an used Famicom and that Micro Machines cartridge. It's always interesting stuff!We know that the glitchy graphics occur on a rev E or earlier PPU. Early NES-001s used the rev E chips, so Micro Machines will show glitches on them. On my AV Famicom, pressing reset at anything other than during the racing will cause a glitchy static image and a crash. Sometimes pressing reset again will get out of the crash state, more often it won't. However, pressing reset on while racing will reset to the Codemasters logo reliably.
Do cartridges receive power up and reset signals? In terms of emulation, should mappers reinitialize registers and other state information when the reset button is pressed?
AFAIK, these signals are not directly available, but it is possible to detect a reset by observing the behavior of other signals. Some mappers do initialize their registers to known values while others don't... I believe the wiki has this information, doesn't it?
PowerPak and Everdrive N8 both rely on being able to detect reset.
Mapper 31 requires power-on detection, but not reset.
There's a suggestion that some MMC5 games have power-on expectations but I don't know if that's a reliable feature of the mapper.
There might be others, but the vast majority of mappers don't have any kind of power/reset initialization. Usually what I've found when I've tested them is random results (i.e. any state possible), but not evenly distributed.
I believe reset detection is done based on the M2 clock signal, which halts while reset is held? I don't know how mapper 31 detects power-on though, infiniteneslives implemented it.
Some info here: http://forums.nesdev.com/viewtopic.php?p=99137#p99137
Mapper 31 requires power-on detection, but not reset.
There's a suggestion that some MMC5 games have power-on expectations but I don't know if that's a reliable feature of the mapper.
There might be others, but the vast majority of mappers don't have any kind of power/reset initialization. Usually what I've found when I've tested them is random results (i.e. any state possible), but not evenly distributed.
I believe reset detection is done based on the M2 clock signal, which halts while reset is held? I don't know how mapper 31 detects power-on though, infiniteneslives implemented it.
Some info here: http://forums.nesdev.com/viewtopic.php?p=99137#p99137
rainwarrior wrote:
PowerPak and Everdrive N8 both rely on being able to detect reset.
Mapper 31 requires power-on detection, but not reset.
There's a suggestion that some MMC5 games have power-on expectations but I don't know if that's a reliable feature of the mapper.
There might be others, but the vast majority of mappers don't have any kind of power/reset initialization. Usually what I've found when I've tested them is random results (i.e. any state possible), but not evenly distributed.
I believe reset detection is done based on the M2 clock signal, which halts while reset is held? I don't know how mapper 31 detects power-on though, infiniteneslives implemented it.
Some info here: viewtopic.php?p=99137#p99137
Mapper 31 requires power-on detection, but not reset.
There's a suggestion that some MMC5 games have power-on expectations but I don't know if that's a reliable feature of the mapper.
There might be others, but the vast majority of mappers don't have any kind of power/reset initialization. Usually what I've found when I've tested them is random results (i.e. any state possible), but not evenly distributed.
I believe reset detection is done based on the M2 clock signal, which halts while reset is held? I don't know how mapper 31 detects power-on though, infiniteneslives implemented it.
Some info here: viewtopic.php?p=99137#p99137
I noticed other games that fail on a soft reset. For instance, Bao Xiao San Guo.7z <Bao Xiao San Guo (Ch).nes> from GoodNES3.23b crashes with the following error in Nintendulator when reset during the intro:
Code:
Invalid opcode $CF (DCP) encountered at $8523
A hard reset works. But, as you suggest above, that might not reflect real hardware behavior.
Here are a few other ROMs with soft reset issues:
Chong Wu Da Jia Zu Bu Luo Fen Zheng (Pet Family).7z
Cvetnye Linii (Color Lines).7z
Da Hang Hai VII.7z
Kou Dai Jing Ling - Fei Cui.7z
Mortal Kombat 3.7z
Shu Ma Bao Bei (Digimon Crystal).7z
Shui Hu Shen Shou (ES-1087).7z
Xi Chu Ba Wang.7z
Xiong Ba Tian Xia.7z
And, none of these are failing for lack of resetting the PPU.
Regarding the list of ROMs above, all of them appear to require a hard reset to properly start up, with one exception: Cvetnye Linii (Color Lines). That Dendy ROM gets stuck in a loop on reset. The reset address and the IRQ address are both $FF97. Consequentially, in my emulator, it keeps bouncing between the following 2 instructions:
According to the wiki, the APU Status register ($4015) is set to 0 on reset. This disables DMC interrupts. But, what about Frame Counter interrupts? Are they disabled on reset? That is what is causing my emulator to get stuck above.
Edit: That Dendy ROM enables Frame Counter interrupts via register $4017 and it never disables them.
Code:
00:FF97:58 CLI
00:FF98:A9 00 LDA #$00
00:FF98:A9 00 LDA #$00
According to the wiki, the APU Status register ($4015) is set to 0 on reset. This disables DMC interrupts. But, what about Frame Counter interrupts? Are they disabled on reset? That is what is causing my emulator to get stuck above.
Edit: That Dendy ROM enables Frame Counter interrupts via register $4017 and it never disables them.
zeroone wrote:
According to the wiki, the APU Status register ($4015) is set to 0 on reset. This disables DMC interrupts. But, what about Frame Counter interrupts? Are they disabled on reset? That is what is causing my emulator to get stuck above.
This says $4017 is unchanged.
https://wiki.nesdev.com/w/index.php/CPU ... fter_reset
It also says IRQ inhbit is set on reset, though, which should block it unless cleared by the software?
rainwarrior wrote:
It also says IRQ inhbit is set on reset, though, which should block it unless cleared by the software?
It resets to this address:
Code:
00:FF97:58 CLI
Edit: Is it possible that the Dendy resets the APU?
Edit 2: For the CPU Power Up State wiki page, was $4017 verified based on the behavior of the APU or did someone attempt to read from that register. Aside from $4015, all the APU registers are write-only.
Edit 3: No other emulator has issues resetting this Dendy ROM. I assume this is some bug in my emulator, but I can't pinpoint the issue. Any suggestions?
I was just reading an old topic and apparently I DO own a copy of Micro Machines:
viewtopic.php?p=11638#p11638
Now I wonder if the CIC circumvention hack could cause any damage whatsoever to an AV Famicom... I paid a lot of $$$ for mine (importing from Japan and paying 60% of price + shipping in taxes), so I'd really hate to screw it up.
viewtopic.php?p=11638#p11638
Now I wonder if the CIC circumvention hack could cause any damage whatsoever to an AV Famicom... I paid a lot of $$$ for mine (importing from Japan and paying 60% of price + shipping in taxes), so I'd really hate to screw it up.
Regarding Cvetnye Linii (Color Lines), Nintendulator appears to fully reset the APU on reset. In the snippet below, the power on code is identical to the reset code, including clearing the IRQ request flags:
This may not reflect actual hardware behavior. Per the discussion above, I suspect that Cvetnye Linii (Color Lines) won't reset properly on a real system.
In any case, should emulators fully reset the APU on reset?
Code:
void PowerOn (void)
{
#ifndef NSFPLAYER
ZeroMemory(Regs, 0x18);
#endif /* !NSFPLAYER */
Frame::PowerOn();
Square0::PowerOn();
Square1::PowerOn();
Triangle::PowerOn();
Noise::PowerOn();
DPCM::PowerOn();
Race::PowerOn();
Cycles = 1;
CPU::WantIRQ &= ~(IRQ_FRAME | IRQ_DPCM);
InternalClock = 0;
}
void Reset (void)
{
#ifndef NSFPLAYER
ZeroMemory(Regs, 0x18);
#endif /* !NSFPLAYER */
Frame::Reset();
Square0::Reset();
Square1::Reset();
Triangle::Reset();
Noise::Reset();
DPCM::Reset();
Race::Reset();
Cycles = 1;
CPU::WantIRQ &= ~(IRQ_FRAME | IRQ_DPCM);
InternalClock = 0;
}
{
#ifndef NSFPLAYER
ZeroMemory(Regs, 0x18);
#endif /* !NSFPLAYER */
Frame::PowerOn();
Square0::PowerOn();
Square1::PowerOn();
Triangle::PowerOn();
Noise::PowerOn();
DPCM::PowerOn();
Race::PowerOn();
Cycles = 1;
CPU::WantIRQ &= ~(IRQ_FRAME | IRQ_DPCM);
InternalClock = 0;
}
void Reset (void)
{
#ifndef NSFPLAYER
ZeroMemory(Regs, 0x18);
#endif /* !NSFPLAYER */
Frame::Reset();
Square0::Reset();
Square1::Reset();
Triangle::Reset();
Noise::Reset();
DPCM::Reset();
Race::Reset();
Cycles = 1;
CPU::WantIRQ &= ~(IRQ_FRAME | IRQ_DPCM);
InternalClock = 0;
}
This may not reflect actual hardware behavior. Per the discussion above, I suspect that Cvetnye Linii (Color Lines) won't reset properly on a real system.
In any case, should emulators fully reset the APU on reset?
Reset at least silences the APU (like writing 0 to $4015). Reset doesn't affect any expansion audio that I know of, though.
I'm not sure about the rest of it. Silence via $4015 requires at least the high byte of frequency to be reloaded before they can produce sound again, but I haven't really tested if the other registers have surviving information.
I think lidnariq determined that the noise LFSR was reset to 0 as well?
Mega Man seems to rely on sweep being disabled at least at power-on (i.e. the "game genie" sound problem), not sure if it's affected by reset.
$4017 is not reset, as discussed early.
I'm not sure about the rest of it. Silence via $4015 requires at least the high byte of frequency to be reloaded before they can produce sound again, but I haven't really tested if the other registers have surviving information.
I think lidnariq determined that the noise LFSR was reset to 0 as well?
Mega Man seems to rely on sweep being disabled at least at power-on (i.e. the "game genie" sound problem), not sure if it's affected by reset.
$4017 is not reset, as discussed early.
No, the noise LFSR is left as-is. It just comes out of a cold boot all 0, like most other things in the CPU. (due to how NMOS works, I suspect.)
As far as what things are cleared on warm boot? I've been meaning to sit down with Visual2A03 and find every stupid place that _res winds through, but there's an awful lot of them: 312.
As far as what things are cleared on warm boot? I've been meaning to sit down with Visual2A03 and find every stupid place that _res winds through, but there's an awful lot of them: 312.
rainwarrior wrote:
$4017 is not reset, as discussed early.
Agreed. But, there might be many poorly tested games out there that fail on reset, not just this Dendy ROM. Are there any side effects to fully resetting the APU on reset? Will any games actually break? Since Cvetnye Linii (Color Lines) resets properly in most emulators, I suspect all of them are already resetting the APU on reset.
To briefly summarize: Of the 312283 (I forgot to deduplicate) nodes that are cleared during reset, (at least) 161159 are given names in Visual2A03:
* frame_irq (acknowledging the IRQ but not disabling it)
* frm_c
* snd_halt
* spr_addrX (to cleanly abort an in-progress DMA, I assume)
* sq0_cX, sq0_envcX, sq0_envtX, sq0_lenX, sq0_on, sq0_swptX, sq0_tX
* sq1_cX, sq1_envcX, sq1_envtX, sq1_lenX, sq1_on, sq1_swptX, sq1_tX
* tri_cX, tri_lcX, tri_lenX, tri_on, tri_tX
* noi_envcX, noi_envtX, noi_lenX
* pcm_aXX, pcm_bitsX, pcm_en, pcm_irq, pcm_lcXX, pcm_on
* frame_irq (acknowledging the IRQ but not disabling it)
* frm_c
* snd_halt
* spr_addrX (to cleanly abort an in-progress DMA, I assume)
* sq0_cX, sq0_envcX, sq0_envtX, sq0_lenX, sq0_on, sq0_swptX, sq0_tX
* sq1_cX, sq1_envcX, sq1_envtX, sq1_lenX, sq1_on, sq1_swptX, sq1_tX
* tri_cX, tri_lcX, tri_lenX, tri_on, tri_tX
* noi_envcX, noi_envtX, noi_lenX
* pcm_aXX, pcm_bitsX, pcm_en, pcm_irq, pcm_lcXX, pcm_on
zeroone wrote:
Are there any side effects to fully resetting the APU on reset? Will any games actually break?
Except for $4017 the registers are write only. I think the only way it can affect anything but sound is through an IRQ? (DPCM and/or Frame Counter.)
So... the consequences of an incorrectly initialized APU are quite low, especially since it's silenced by the reset.
lidnariq wrote:
No, the noise LFSR is left as-is. It just comes out of a cold boot all 0, like most other things in the CPU. (due to how NMOS works, I suspect.)
Ah, thanks for the clarification.
lidnariq wrote:
To briefly summarize: Of the 312 nodes that are cleared during reset, (at least) 161 are given names in Visual2A03:
* frame_irq (acknowledging the IRQ but not disabling it)
* frm_c
* snd_halt
* spr_addrX (to cleanly abort an in-process DMA, I assume)
* sq0_cX, sq0_envcX, sq0_envtX, sq0_lenX, sq0_on, sq0_swptX, sq0_tX
* sq1_cX, sq1_envcX, sq1_envtX, sq1_lenX, sq1_on, sq1_swptX, sq1_tX
* tri_cX, tri_lcX, tri_lenX, tri_on, tri_tX
* noi_envcX, noi_envtX, noi_lenX
* pcm_aXX, pcm_bitsX, pcm_en, pcm_irq, pcm_lcXX, pcm_on
* frame_irq (acknowledging the IRQ but not disabling it)
* frm_c
* snd_halt
* spr_addrX (to cleanly abort an in-process DMA, I assume)
* sq0_cX, sq0_envcX, sq0_envtX, sq0_lenX, sq0_on, sq0_swptX, sq0_tX
* sq1_cX, sq1_envcX, sq1_envtX, sq1_lenX, sq1_on, sq1_swptX, sq1_tX
* tri_cX, tri_lcX, tri_lenX, tri_on, tri_tX
* noi_envcX, noi_envtX, noi_lenX
* pcm_aXX, pcm_bitsX, pcm_en, pcm_irq, pcm_lcXX, pcm_on
Interesting!
Ok, I made an effort to trace down the remaining nodes.
Of the 283 unique nodes that are grounded during +RESET, 159 are as above.
Another 22×4=88 nodes keep the address bus, OUTn, /JOYn, and R/W pins Hi-Z during +RESET.
(You'll notice M2 is not in the list. reset goes through several extra inverters before eventually disabling the drivers for M2, so they're not counted in the 283)
6: The upper six bits of the delta channel DAC (W4011) are cleared (but not the LSB)
8: The DPCM shift register is cleared.
4: The lower four bits of noise frequency register (W400E) are cleared (but not the noise/tonal bit)
4: The lower four bits of the channel enable register (W4015) are cleared (but not the DPCM in-progress flag)
1: glue node for connecting the outer 2A03 hardware to the 6502
The remaining 13 nodes I kinda gave up on; they are mostly related to DPCM and DPCM DMA.
(they are : somethings pertaining to [apu_clk2 ; the frame sequencer ; -reset ; 2x pcm_doadjust ; 2x rdy ; use_spr_ab ; 2x noi_t ; pcm_t ; dpcm ; dpcm dma] )
The attached text file are my added set of node names for Visual2A03. You'll want to remove or improve the "something_XXX" node names rather than using my terrible halfassed names.
Of the 283 unique nodes that are grounded during +RESET, 159 are as above.
Another 22×4=88 nodes keep the address bus, OUTn, /JOYn, and R/W pins Hi-Z during +RESET.
(You'll notice M2 is not in the list. reset goes through several extra inverters before eventually disabling the drivers for M2, so they're not counted in the 283)
6: The upper six bits of the delta channel DAC (W4011) are cleared (but not the LSB)
8: The DPCM shift register is cleared.
4: The lower four bits of noise frequency register (W400E) are cleared (but not the noise/tonal bit)
4: The lower four bits of the channel enable register (W4015) are cleared (but not the DPCM in-progress flag)
1: glue node for connecting the outer 2A03 hardware to the 6502
The remaining 13 nodes I kinda gave up on; they are mostly related to DPCM and DPCM DMA.
(they are : somethings pertaining to [apu_clk2 ; the frame sequencer ; -reset ; 2x pcm_doadjust ; 2x rdy ; use_spr_ab ; 2x noi_t ; pcm_t ; dpcm ; dpcm dma] )
The attached text file are my added set of node names for Visual2A03. You'll want to remove or improve the "something_XXX" node names rather than using my terrible halfassed names.
The Aladdin Deck Enhancer ROM of Micro Machines does not hang on the menu screens when I press the reset button on my Famicom and AV Famicom. It only mutes the sound until the screen changes. Sometimes the graphics may appear garbled for a second, but they will appear normally thereafter. The European ROM of Micro Machines always does a proper reset on my Famicom and AV Famicom regardless of the screen you are on. The European ROM does not adjust the speed in any way for PAL machines, it runs perfectly on an NTSC console.