Membler Industries in 2015

The Membler Industries, Strangulation Games, and Strangulation Records forum.

Moderator: Moderators

User avatar
infiniteneslives
Posts: 2097
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Membler Industries in 2015

Post by infiniteneslives » Fri Mar 16, 2018 6:34 pm

lidnariq wrote: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

lidnariq
Posts: 8691
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Membler Industries in 2015

Post by lidnariq » Fri Mar 16, 2018 6:55 pm

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.

User avatar
infiniteneslives
Posts: 2097
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Membler Industries in 2015

Post by infiniteneslives » Fri Mar 16, 2018 7:00 pm

Ahh I see, possible them being as new as they are the tools aren't fully updated with the silicon's abilities. Sounds like may be worth asking support directly.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2030
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Membler Industries in 2015

Post by FrankenGraphics » Sat Mar 17, 2018 6:26 am

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.
http://www.frankengraphics.com - personal NES blog

lidnariq
Posts: 8691
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Membler Industries in 2015

Post by lidnariq » Sat Mar 17, 2018 1:03 pm

Eh, just a GreenPak with enough I/O.

Because I enjoy greenpak golf, I was able to stuff something like GTROM into one SLG46537, with the following function map:

Code: Select all

mask: $F000
 $5000: [.... DDDD] - selects 32K PRG bank
 $6000: [.... ...C] - selects 8K CHR RAM bank
 $7000: [.... ...N] - selects 4K NT RAM bank
Attachments
gtrom-separated.png
gtrom-separated.zip
(3.92 KiB) Downloaded 1254 times

User avatar
Memblers
Site Admin
Posts: 3760
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Membler Industries in 2015

Post by Memblers » Mon Sep 24, 2018 11:10 pm

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.

Here's what the mapper write looks like (74HC377).
1(yellow) is register clock (inverted M2)
2(cyan) is register enable !(PRGCE & A12 & A14)
3(magenta) is data output (supposed to be low)

first image is normal write - STA $5000
gtrom_reg_normal.png
second image is glitched write - STA $5000,X
gtrom_reg_indexed.png
Attachments
GTROM schematic
GTROM schematic

User avatar
pubby
Posts: 536
Joined: Thu Mar 31, 2016 11:15 am

Re: Membler Industries in 2015

Post by pubby » Wed Sep 26, 2018 12:40 am

Kool. Good job figuring it out!

lidnariq
Posts: 8691
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Membler Industries in 2015

Post by lidnariq » Thu Jan 24, 2019 3:06 pm

Memblers wrote:I did a full chip erase, went into ID mode, then dumped the first 256 bytes ($8000-$80FF) and it looks like this:

Code: Select all

BF B7 01 FF 01 FF FF FE FF FF 25 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0F 06 01 FF (the rest is all FF)
lidnariq wrote:First 64 bytes of the ID memory on this random one I have are:

Code: Select all

BF B7 01 FF 01 FF FF FE FF FF 25 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 0E 0C 04 FF FF FF
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.

Post Reply