I'm a little confused by their claim that the '824 there supports 17 I/O—unlike some of the older ones, I don't see a way to turn off the I²C logic unit, so that's two pins permanently lost.

From the datasheet, "The SLG46824 has a total of 13 GPIO, 2 GPO and 2 GPI Pins which can function as either a user defined Input or Output, as well as serving as a special function (such as outputting the voltage reference). ... GPI: SCL and SDA serve as General Purpose Input Pins."

Looks like they're general purpose IN only, and including them in the i/o count because of that.

_________________If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Yeah, but even allowing them to be exclusively inputs, I didn't see a way to disable I²C so that the general fusemap could use them in logic, nor did I see SCL and SDA show up in the matrix (pages 30-31) for use.

Too bad they only mention the '824 and '826 as coming in packages with legs.

I see, so it would require quite the redesign involving at least a greenpak and it'd need to be price-comparable to the currently used off the shelf logic devices; which would narrow the range of possibilities further.

I think the most useful division would be the 2 ppu page selects from the cpu page select since they're quite central. separating the 2 ppu page selects from each other or the blinkenlights from the rest seems like "only if there's logic left to use" options.

errata note: When one of the two the pattern table pages is selected, the wrong tile may be fetched by the PPU at the exact moment that the CPU writes to the mapper register. To avoid this, you must not write to the mapper during rendering. The other pattern table page is not affected.

I created this rumor, and I can finally put it to bed. The work-around is dead simple - don't use absolute indexed addressing mode to write to the register. E.g., do STA $5000 instead of STA $5000,X. That was easy.

Why this happens, is because the 6502 accesses memory on every cycle. LDA ABS,X takes 4 cycles, 5 if a page boundary is crossed. But STA ABS,X always takes 5 cycles. By the time it hits cycle 4, it's already read the opcode and is working on fixing up the high byte of the address (for page boundary cross) but it's still going to access memory. You wouldn't want it to do a write, because the address hasn't been fixed up yet. So it does a read, and discards it. The mapper register is sensitive to reads, so the register value becomes the open-bus value (the high byte of the address) for one CPU cycle.

That explains why there have been zero complaints about it. It was my testing method that failed. I've hacked a few UNROM games and simply changed the mapper address, but not the opcode, so the glitch manifests. It seemed weird that I didn't see it happening in my own programs. Mystery solved.

So now instead of a bug, we have a strange new feature. It could be used like the PPU 'monochrome bit' to benchmark your CPU usage. Or you could write to it in an idle loop to create a glitchy screen noise effect. It can affect the attribute table as well, which can get pretty colorful. Just do a STA $5000,X if you want to try it.

GTROM - $9.25 each, if you're looking for a cheap simple mapper. $35+shipping for a devkit.

I just wanted to briefly follow up on this. At my request Markfrizb looked at a couple very recent (date silk 1844) SST39SF040s and the date bits are not present. The first 32 bytes are unchanged relative to above.

Who is online

Users browsing this forum: No registered users and 1 guest

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