nesdev.com
http://forums.nesdev.com/

Membler Industries in 2015
http://forums.nesdev.com/viewtopic.php?f=4&t=12716
Page 5 of 5

Author:  infiniteneslives [ Fri Mar 16, 2018 6:34 pm ]
Post subject:  Re: Membler Industries in 2015

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.

Author:  lidnariq [ Fri Mar 16, 2018 6:55 pm ]
Post subject:  Re: Membler Industries in 2015

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.

Author:  infiniteneslives [ Fri Mar 16, 2018 7:00 pm ]
Post subject:  Re: Membler Industries in 2015

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.

Author:  FrankenGraphics [ Sat Mar 17, 2018 6:26 am ]
Post subject:  Re: Membler Industries in 2015

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.

Author:  lidnariq [ Sat Mar 17, 2018 1:03 pm ]
Post subject:  Re: Membler Industries in 2015

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:
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.png [ 36.84 KiB | Viewed 7166 times ]
gtrom-separated.zip [3.92 KiB]
Downloaded 174 times

Author:  Memblers [ Mon Sep 24, 2018 11:10 pm ]
Post subject:  Re: Membler Industries in 2015

Quote:
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
Attachment:
gtrom_reg_normal.png
gtrom_reg_normal.png [ 29.33 KiB | Viewed 162 times ]

second image is glitched write - STA $5000,X
Attachment:
gtrom_reg_indexed.png
gtrom_reg_indexed.png [ 33.14 KiB | Viewed 162 times ]


Attachments:
File comment: GTROM schematic
gtrom.png
gtrom.png [ 41.38 KiB | Viewed 162 times ]

Page 5 of 5 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/