It is currently Tue Dec 18, 2018 12:24 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Tue Sep 18, 2018 8:58 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
Location: Chexbres, VD, Switzerland
rainwarrior wrote:
Swapping within hblank was always possible, but I don't know of any commercial era games that did so. (Lot easier now with the hindsight of decades of reverse engineering and emulators.)

Maniac Mansion Marble Madness (*) does this with $2000 while Mother (J) does this with MMC3 bankswitching registers. Long ago I released a demo showing a theoretical Fire Emblem doing this with MMC1 bankswitching registers (the actual Fire Emblem had the MMC4 doing this automatically using hardware only).

(*)Sorry I just originally typed the wrong "MM" game.


Last edited by Bregalad on Tue Sep 18, 2018 11:00 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Sep 18, 2018 9:41 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
tokumaru wrote:
even during hblank the PPU [...] kick off the background rendering for the next scanline, so you still have to tiptoe around those things when making use of hblank.
Specifically, the raster timing means that the fetch for the last possibly-displayed background tile happens on cycle 248, and the bankswitch needs to happen before prefetch for the following scaline starts on cycle 320. (ulfalizer's diagram). This is a little more tolerant (8 extra cycles at the beginning) than the timing for disabling rendering without artifacts.


Top
 Profile  
 
PostPosted: Fri Sep 21, 2018 9:09 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3602
Location: Indianapolis
edit: skip ahead to my later post, as it turns out there is no GTROM glitch.

rainwarrior wrote:
pubby wrote:
It causes a glitch on GTROM I think, but not most other mappers.

GTROM has a problem with CHR banking?

I remember Memblers mentioning some problems during prototyping, but is there a problem in the finished board?


Yeah, that was an "interesting" time. I'd highly recommend to anyone, if they're going to order 1000 assembled boards that you first obtain an oscilloscope. I was so perplexed by the OAM issues (which turned out to be nothing, a bad register setting in the Game Genie) that I kinda glossed over the problem that is in there. I should put it in the main GTROM docs, probably isn't due to a combination of laziness, embarrassment, and that it has a software work-around (for the most common uses at least). Or maybe it's part of a conspiracy to make my boards harder to emulate. :wink: haha

What happens is when you write to the mapper, the latch briefly outputs the high byte of the mapper address, and then the actual data written. For one of the pattern and nametable banks this has no effect, it's just 100% normal. But if using the other bank though, it will screw up the PPU fetch for any cycle you write to the mapper. It doesn't affect CPU banks at all, or the LEDs (theoretically it should dim them very slightly if you wrote to the register a lot, I doubt it's perceptible though).

The work-arounds are only somewhat obnoxious:
1) pattern tables - if you're displaying more than 256 BG tiles it's usually either A) a status bar on top of the screen, or B) a static screen or cutscene. Usually this means for the top portion of the screen, the CPU is waiting for sprite zero and/or running cycle-timed code. During this time you would display the "bad" page, avoid doing any CPU bankswitching (shouldn't be too hard at that point). Then write to the register during hblank. Writing during hblank means that glitch will corrupt sprites on the next line, so can't have sprites on the split point. After you've switched to the "good" page, your program can run as normal.
2) name tables - same as above, or alternately you can use the different $5xxx $7xxx mapper addresses matched up with your nametable bit, and you will always have the "good" page. Glitch is based on the high byte of the address, and the nametable bits happen to line up with those.

It was never supposed to happen, but the nametable glitch actually looks kinda cool sometimes. Would be funny to use it as an effect.


Top
 Profile  
 
PostPosted: Fri Sep 21, 2018 9:22 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
Memblers wrote:
What happens is when you write to the mapper, the latch briefly outputs the high byte of the mapper address, and then the actual data written. For one of the pattern and nametable banks this has no effect, it's just 100% normal. But if using the other bank though, it will screw up the PPU fetch for any cycle you write to the mapper. It doesn't affect CPU banks at all, or the LEDs (theoretically it should dim them very slightly if you wrote to the register a lot, I doubt it's perceptible though).
But ... the 74'377 is a register, not a transparent latch? How do both values make it through?


Top
 Profile  
 
PostPosted: Fri Sep 21, 2018 9:31 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7026
Location: Canada
So, what does "briefly" mean? Does this affect all 8 output bits? Presumably it's fast enough that the CPU's next instruction read is never affected? (Or is the low nybble unaffected?)

Shouldn't the glitch be limited to one sliver of one tile, then?

Why would writing during hblank corrupt the sprites?

Memblers wrote:
Or maybe it's part of a conspiracy to make my boards harder to emulate. :wink: haha

Well, my dump of The Incident appears to (accidentally?) rely on some specific timing of the EEPROM recovery after erase during saving, so even the one game I implemented the emulator to try it didn't completely work for without modification. ;)


Top
 Profile  
 
PostPosted: Fri Sep 21, 2018 9:41 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
Memblers wrote:
you can use the different $5xxx $7xxx mapper addresses matched up with your nametable bit, and you will always have the "good" page. Glitch is based on the high byte of the address, and the nametable bits happen to line up with those.
Thinking a little more, shouldn't you be able to used indexed stores to get around this for CHR banks? e.g. sta $4FFF,X as long as X is nonzero?

(Or does the logic react to reads as well as writes? I never did ask if you'd be willing to share what the specific schematic is...)


Top
 Profile  
 
PostPosted: Sun Sep 23, 2018 12:12 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3602
Location: Indianapolis
rainwarrior wrote:
So, what does "briefly" mean? Does this affect all 8 output bits? Presumably it's fast enough that the CPU's next instruction read is never affected? (Or is the low nybble unaffected?)

Something like 20-30 nanoseconds, and I'm sure it does affect all 8 bits. The CPU address bits will be fine, it's something like 550ns until the next read cycle begins.

rainwarrior wrote:
Shouldn't the glitch be limited to one sliver of one tile, then?

Yeah, the glitches are mostly 8x1 sized, and some look 16x1 (that seems a little fast for consecutive register writes though?).

rainwarrior wrote:
Why would writing during hblank corrupt the sprites?

During hblank the PPU is fetching sprite pattern data for the next line. So to be more precise, it would corrupt the next line's sprite pattern data fetching (only if any are present on the next line).

rainwarrior wrote:
Memblers wrote:
Or maybe it's part of a conspiracy to make my boards harder to emulate. :wink: haha

Well, my dump of The Incident appears to (accidentally?) rely on some specific timing of the EEPROM recovery after erase during saving, so even the one game I implemented the emulator to try it didn't completely work for without modification. ;)

It's funny too because I think bunnyboy had given that code to Kevin, I modified for GTROM mapping, and you've modified it. It's a lot of fingerprints on one subroutine. The SST39SF chips specifies the time it takes, so that should be "within spec", though my usual code polls the chip. I had used some AM29F chips in the past, and those had huge variations in erase time (like some chips took >10 times longer than others).

lidnariq wrote:
Memblers wrote:
you can use the different $5xxx $7xxx mapper addresses matched up with your nametable bit, and you will always have the "good" page. Glitch is based on the high byte of the address, and the nametable bits happen to line up with those.

Thinking a little more, shouldn't you be able to used indexed stores to get around this for CHR banks? e.g. sta $4FFF,X as long as X is nonzero?

(Or does the logic react to reads as well as writes? I never did ask if you'd be willing to share what the specific schematic is...)

That's great! The indexing does work. And $4x,$5x,$6x,$7x is enough to cover both CHR bits.

Yeah, it is sensitive to reads as well, but I haven't tried to do it. Reading would always be the same as the glitch value, that's interesting. I can share the schematic. I'll get some screencaps from the scope and make up a post for it in the GTROM thread tonight or tomorrow.


---
edit
---
I was wrong about the timing, the glitch does last for a full CPU cycle.


Top
 Profile  
 
PostPosted: Sun Sep 23, 2018 12:25 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7026
Location: Canada
Memblers wrote:
rainwarrior wrote:
Memblers wrote:
Or maybe it's part of a conspiracy to make my boards harder to emulate. :wink: haha

Well, my dump of The Incident appears to (accidentally?) rely on some specific timing of the EEPROM recovery after erase during saving, so even the one game I implemented the emulator to try it didn't completely work for without modification. ;)

It's funny too because I think bunnyboy had given that code to Kevin, I modified for GTROM mapping, and you've modified it. It's a lot of fingerprints on one subroutine. The SST39SF chips specifies the time it takes, so that should be "within spec", though my usual code polls the chip. I had used some AM29F chips in the past, and those had huge variations in erase time (like some chips took >10 times longer than others).

I didn't mean it was relying on the delay deliberately. It seemed to be a bug (NMI / thread synchronization) that would occur if the sector clear happened "immediately" which coincidentally caused some bad timing for the bug, not actually to do with the save itself just about how/when NMI was re-enabled after doing the save.


Top
 Profile  
 
PostPosted: Mon Sep 24, 2018 5:59 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3602
Location: Indianapolis
Update on the GTROM glitch, it's caused by using indexing while writing to the register. Just normal STA $5000 works fine every time. So essentially, there is no glitch. The 6502 does a read before the write for absolute indexed write, the mapper is sensitive to reads, thus the open bus result. The failure was in my test methodology (hacking UNROM games' register address, while not changing the opcode). Mystery solved. Will post further info in the Membler Industries section of the forum.

Just wanted to clarify that GTROM works fine, despite what I was saying.


Top
 Profile  
 
PostPosted: Mon Sep 24, 2018 6:08 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
Ah, and that makes the value stick on the output of the latch for a full instruction cycle, long enough for 2 PPU fetches.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group