SNES-Tap: save your game whenever you want... really?

Hi,

Have some of you ever heard of this?

http://www.retrocollect.com/News/save-states-console-add-on-snes-tap-set-for-the-super-nintendo.html

Even though it is a great idea, I've been thinking who this can be done technically, and have some doubts... In order to save a game whenever you desire, you need to save:
* CPU state
* SNES' RAM and VRAM

Using Expansion port, you can access B-bus, so you can "dump" RAM and VRAM through DMA into the FPGA, right? You'd stop CPU processing when doing DMA, and maybe there would be some issues when CPU restarted, but technically seems feasible.
But what about CPU state? How can you dump internal registers? I think it is impossible unless you were monitoring every instruction 65C816 executes, which can'd be done over Expansion Port.

Am I wrong?

SNES backup devices with RTS-capability have been created in the past, e.g. the Game Doctor SF7. I assume they accomlish this by hooking the NMI, and given some condition (e.g. a particular button combination), run a small piece of code that saves whatever state they can to some memory on the backup device. I've never tried any of them myself, so I don't know how well it works. I would expect some glitches though, because IIRC some of the PPU registers are write-only, so backing up the PPU state would be difficult. Backing up the SPC state also seems like it would be difficult.

Now, if this new SNES-Tap is able to "see" every instruction being executed, as that retrocollect page suggest, it could (in theory, given sufficient performance) emulate a SNES on the device, thereby creating its own view of the state of WRAM, VRAM, the PPU registers, the S-DSP, etc. I've no idea what you can and can't do with the SNES expansion port, so I don't know whether that's feasible.

I own a GameDoctor SF7 and yes, savestates can be created whenever you want, although not always work properly. Anyway, it is not the same case, since GameDoctor SF7 is connected to cartridge slot, so full awareness of executed instructions can be achieve.

Copiers that support RTS most likely "watch" register writes so that write-only registers can be restored. Compatibility is never going to be 100% because some games might be doing odd things that prevent proper restoration of the state or just in general don't take kindly to messing with the timing by interrupting them for loading or saving. For one example, restoring the precise state of the audio hardware is basically impossible. Games that might stream data are not going to be happy. You don't have this issue with an emulator that can truely save the entire machine state and restore it.

In my experience with the Game Doctor, the RTS works OK in most games however for some games you sometimes need to save and reload your progress in certain areas/scenes and not others because of compatibility issues.

I'm curious about this device which says it uses the expansion port. It's very odd because there isn't much you can do with it that I know of. Very few signals are present. I'm not sure how a RTS device would work without more signals and capability.

There is a ribbon cable in the picture that could be going to the cartridge slot for more important signals.

Hey Guys!
I’m the designer of the SNES-Tap. I didn’t realize someone wrote an article on the device so perhaps I should clarify exactly what is going on. That image on retrocollect of the REV A board was the initial prototype I showed at 2015 Bay Area Maker Faire. The board design is almost an exact replica of the board made by qwertymodo/byuu shown here: viewtopic.php?f=12&t=9386&start=60 That demo for Maker Faire did not have any load/save state. All the FPGA did was sit on the expansion bus port to snoop on all transactions made to the PPU and APU (since EXP gives you this visibility). I had the FPGA stream those transactions via an FTDI 245H USB 2.0 chip to a recompiled modified version of Snes9x on my laptop. On Snes9x I modified the main emulator loop to include code to receive PPU accesses from the SNES-Tap and feed it to the emulated PPU on Snes9x while the Snes9x is running a rom that is just in infinite loop. The results were that Snes9x rendered the SNES frames almost perfectly . The image shows one window being the elgato composite capture of the console and the other window being the modified version of Snes9x rendering the same frame. One of the issues was Snes9x had flicker but I believe that is attributed to it not being NMI-aware in that design. The initial goal of this project wasn’t for load/save state but instead to create a digital only graphics renderer of an original SNES console (perhaps maybe one day to HDMI).
So after Maker Faire I designed REV B of the SNES-Tap board to include the level shifters on PCB. I was having integrity issues with all the wiring to and from that breadboard so it was time to upgrade. The current version of this board (REV B) is pictured here:

https://pbs.twimg.com/media/CMHYllaUkAAu17o.png

https://pbs.twimg.com/media/CInY1FoUcAAI3bN.jpg

So when I got the REV B in I made some quick FPGA test images to test the integrity and just as expected it was rock solid (with the REV A bread board design I had weird data integrity issues). Now that I had reliability I challenged myself into figuring out ways to take over the console via the EXP port. However as all of you mentioned, formally the EXP port does not have the relevant signals to take control over the CPU and even if it did the RESET vector is always owned by the CART. Without being a man-in-the-middle there’s no way to modify the execution flow dictated by the CART. However, we don’t really need to modify the execution flow of the CART do we? All we really need to do is safely steal the program counter and safely give it back. The simplest way to do this is by vector-hijacking. The SNES-Tap takes over the CPU by hijacking the RESET/NMI vector access. When the CPU goes to service RESET or NMI by reading $FFFC / $FFEA the SNES-Tap will tell the level shifters to force a glitch on the bus when the CPU reads those vectors from CART to instruct the CPU to instead jump to $2184. The SNES-Tap gets CPU execution starting at $2184 going to $21FF, this region is an open region visible to EXP and won’t contend with other peripherals. That’s all good, but without having access to address bits 16 to 8, the data bank and the cart read enables how to we know the CPU is reading the RESET or NMI vectors? Well for RESET it is pretty straight forward and deterministic. The EXP port has RESET_n and the CPU always accesses the emulation reset vector right after reset. A couple of things allow us to achieve this: 1) The data bus is shared for bus accesses on address bus A and address bus B, and 2) Except during DMA address bits 7 to 0 of address bus A are aliased to address bus B. From the point of view of a spectator on address bus B, you can actually see CART and WRAM activity. So after reset we look for the address bus to show us $FC and $FF and we glitch the data bus on those exact cycles. And shortly after the CPU comes to $2184 for execution . The NMI hi-jacking is a bit trickier. With RESET it was easy to instruct the FPGA to look for RESET vectors accesses after RESET_n goes high. NMI vector accesses essentially are random and seemingly unknowable by the EXP port. The key to understanding when NMI is occurring is to understand the behavior of the CPU prior to it entering NMI. One such behavior that occurs prior to NMI or other types of interrupts is that CPU pushes state onto the stack. In fact it actually pushes exactly 4 bytes worth of state. Since we have access to the first 8 bits of address bus A/B you can actually have the FPGA detect the event of when the address bus decrements 4 times in consecutive clock cycles to push data onto the stack in WRAM. To my knowledge there is no other event besides an interrupt that can cause the processor to decrement its address bus 4 times in consecutive clock cycles, the processor tends to keep the addr/PC incrementing. The only other event I can think of is a DMA configured for decrementing addresses, however in this case the Addr bus B is usually held static. So with NMI the story now is similar to reset, once the FPGA detects the CPU preparing the stack for interrupt it will start scanning for the NMI vector address $EA $FF and force a glitch when vector data is being read. Voila, the SNES-Tap grabs execution 60 times per second . Now that we have execution via NMI the load/save state story starts to become easier, the 124 bytes of execution space @ $2184 - $21FF is enough to set up at least 2 DMA operations. So how do we describe more? The SNES-Tap FPGA has the ability to page in and out 16 hooks in that tiny address space. The switching of a page occurs when the processor executes all the way to $21FD and the remaining 3 bytes is forced by the FPGA to jump back to $2184 and increment the hook page for a completely new execution. At the end of all 16 hook pages the SNES-Tap @ $21FD describes an in-direct jump to the real native NMI vector.
The load/save state execution flow shown in that video was assembled in software occupying only 2 hook pages out of the 16. The powerful thing about the SNES-Tap isn’t just load/save state. Instead the power is in giving a software engineer the capability to assemble a piece of hook code and load it onto the FPGA to be executed on console. So instead I see SNES-Tap more as a physical console debugger. There are a lot of interesting things other than load/save state one could develop on this platform using just assembly.
Lastly, yes the APU is a problem for load/save state , and yes I do not believe I can achieve perfect load/save state like emulator. However for functionality you don’t necessarily need perfect load/save state. Good enough with no crashes is better than some existing solutions. However I will add that I have some theories on the APU I’m going to test out.
I hope that clarifies things a little bit!

defparam

> The initial goal of this project wasn’t for load/save state but instead to create a digital only graphics renderer of an original SNES console (perhaps maybe one day to HDMI).

Since we have audio in, we won't need to simulate the SMP/DSP, and the CPU is obviously covered as well, leaving only the PPU.

An HDMI cable that includes a full PPU emulation will be expensive. Especially if you want it to be cycle-accurate for raster effects. However, I think it could be done. If we created a PPU-only emulator (removing all the rest of the overhead) and put that onto an RPi2, that would also get us the HDMI output. The only caveat would be that you'd need to power the RPi2 prior to turning on the SNES, or it'd be all out of sync. Not a big deal.

What this would all really hinge on would be the dot clock line, and how fast the USB2 connector really is. If we could actually update the emulator on every tick to that line, then we could pull off raster effects. And at least for games that don't toggle interlace mode (all but maybe a half-dozen of them), we could predict the PPU render position just from the dot-clock tick, synchronized by the reset signal.

We may need to buffer into chunks of <dot-clock, dot-clock, PPU write $2105=#$NN, dot-clock, dot-clock, ...> and send them in batches to the emulator.

But with all of that, I see no reason why we can't make a ~$25 (Pi) + ~$25 (your board) SNES->1080p HDMI A/V cable.

If you make the hardware, I can make the emulation software.

> https://pbs.twimg.com/media/CInY1FoUcAAI3bN.jpg

Why are all those surface-mount components (resistors? transistors?) on the PCB? And what's the added IC for?

Shouldn't it be possible to do all of that stuff after the ribbon cable moves the signal to the next board?

My concern is that someone might want to make something different with the expansion port, but all those extra components will interfere with what they were wanting to do.

...

Speaking of that, we really need to do something about the Samtec connectors. Expansion port devices are never going to scale to commercial sales if we have to hand-dremel their connectors for each and every board. It's pretty much the main reason I gave up on this.

I am still willing to throw in as much money as I can, and to try and crowd-fund more, to try and get someone like Samtec to make us a custom card-edge connector for this.

> So after reset we look for the address bus to show us $FC and $FF and we glitch the data bus on those exact cycles.

Is it truly safe to force change the data bus over the expansion port here? It sounds like that would be very dangerous, especially if a physical cart were plugged into the system. Which it would have to be, unless you grounded pin 4 of the SNES CIC to get it to release the reset signal, or made some kind of dummy "CIC-only" cart.

If that actually works, then that's a really clever idea!

> The only other event I can think of is a DMA configured for decrementing addresses

This seems a lot riskier. IRQs should do the same thing (but with different vector fetch addresses; however you want to hook these too); and then there's separate emulation vs native mode IRQs and NMI handlers. And I'm not sure off-hand, but I think BRK and COP instructions might match this too, possibly.

However, this may not be necessary ... see below.

> So instead I see SNES-Tap more as a physical console debugger.

This is where I'm most interested :D

For the basic idea of transmitting data to and from a PC, the controller port USART board I've built makes a perfect debugging interface for when you're writing your own game, and you just want to send and receive debugging packets. You could load your games off of any existing copier or flash cart, so no problems there. The downside is you're limited to ~30KiB/s, but that's usually plenty for debugging.

For a fancier idea, I've always wanted to be able to use that expansion port to DMA stream data to and from the PC. You could dump a cart in 1-2 seconds, or stream full motion video at around 20-30fps (along with sound from the PC) ala MSU1, but in a way that'd work with more than just the sd2snes. This would allow you to do truly silly things, like stream the output of Dolphin, scaled down (to atrociously small size), and play some Wii games on your SNES :P But this idea isn't really all that useful. Cart dumping doesn't really matter if it takes 1-2 minutes, since you aren't going to be doing that very often. And the real MSU1 is clearly a superior API since it doesn't require a running PC synced up to your game. And the B-bus has the major problem that you can't go PC<>VRAM, but you'd have to buffer in WRAM, which cuts your max throughput in half.

So, moving on ... what I really envision is having a new way for programmers to create a new class of SNES software. The key to that lies in your reset vector hijacking.

Since you can intercept the boot process, then we can hook a serial loader. So let's imagine a new version of your board that connects to the expansion port, intercepts reset to execute $2184-21ff. This runs a serial loader routine that loads a program into SNES WRAM at $7e2000+, and then jumps to it. That is all you have to do! You don't need any ribbon cable on the expansion port device at all. This means your connector can sit flush on the bottom of the SNES. Meaning you don't need to build an elaborate box to house the adapter, and your SNES can sit normally on a desk or whatever.

Furthermore, this bootloader can have a timeout to jump back to the real cartridge reset vector, if it doesn't detect a serial transmission. So you will never even have to insert/remove it.

Now, when it comes to the serial connector ... filling 128KB of WRAM is only 3-4s with USART. This can be done with an FTDI USB<>serial cable (like the 232H), and we can easily buy bulk quantities of SNES controller extension cables. I found a perfect match crimping pin on Digikey that we can put into the cups to expose all seven data lines. This can be made readily and look 100% professional. The end result will literally look like an SNES<>USB cable, with no boxes or breadboards anywhere.

Now where it really gets exciting ... there's a whole world of things you can do with your serial comm link to your PC and this new "self-boot" setup.

1. You can dump any cart ever! You no longer need to cart-swap a live system, so you can dump SA-1/S-DD1/SPC7110/MMC games. This is something that not even the Retrode can do. I have pretty much the only setup in the world right now that can dump any cart. This would allow anyone to easily dump any cart they own, without having to mod their consoles with a SuperCIC.

2. You can play games! Developers that can code up games in 120KB or less (think demoscene) can produce software that anyone can play. Only, you're not even limited to 120KB total, but 120KB at a time. So long as you can fit one level into 120KB (after loading static resources into the PPU/SMP ... you have all the bandwidth you want there), you can have as large a game as you want! Even better, your game has the native debugging functionality by way of that PC link. Which means ... you can do really fun stuff with this! Like netplay!

3. You can utilize cartridge hardware! If you plugged in a SuperFX or SA-1 cartridge, you could upload your own code right into the cartridge RAM, and use coprocessors with your homebrew! You could use the "Game Processor RAM Cassette" (~$50) as a giant RAM bank to upload 1MB+ games to play. Or best of all ...

4. You can develop a new SNES cartridge! We can use ikari's CIC to get unmodified hardware to unlock. And now we can have anything on this PCB. Maybe an ARM processor so that people can write SNES games in C instead of assembly (this would include a "BIOS" for the stuff that has to be done on the SNES CPU.) Maybe we put 4MiB of DRAM, so that most commercial games could be uploaded and played, or just allow bigger blocks of your own code to run at once (same deal if we could figure out the reprogramming sequence for Nintendo Power carts.) Or whatever else you can dream up.

5. I don't think I need to tell you how insanely useful this would be for hardware research for emulation. It would be a huge boon to both SNES hardware and cartridge coprocessor research.

(Note: homebrew can work just fine without having to hijack the SNES NMI/IRQ routines. Most of IRQ's benefits can be accomplished with HDMA, and NMI can be avoided by just polling $4212 periodically. And if you have a cart that can set values read from $ffxx [SuperFX/SA-1/Cx4 carts can do this], then you can use these anyway.)

Best of all ... all of these use cases work with a simple board that does nothing more than hijack reset to run a serial uploader. And the serial hardware works without needing to install any custom kernel drivers onto your OS of choice, so it'll work on every OS out of the box.

And of course, if you could get $21FF acting as a PC<>USB link, then you'd skip the need for the controller serial cable and greatly increase the transfer speed, opening up a few more silly ideas =) The device couldn't feasibly remain flush with the SNES deck anymore, though. So personally, I like the idea of coupling this with the serial controller cable more.

That is something I'd pay a lot of money for, and again, I'd develop all of the PC software and emulator specialization stuff to make this viable.

...

Hope this wasn't too long. But please keep in touch with me on your progress. I'd really like to work with you on making use of the expansion port!

I want to cover all your comments but at the moment I'm at work. I'll post them later on. I will mention a couple things about the hardware so that you are familiar with some of the limitations I came across. To answer your question those ICs and Capactors on the board are level translators and bypass capacitors, 5v to 3.3v. I don't advise anyone to connect expansion board signals directly to modern embedded inputs unless they know the inputs are 5v capable. Most FPGAs (and RPis) are not 5v capable so you need the shifters. Secondly because most USB interfaces are 60 MHz and the SNES busses are less than 5 MHz there is some careful clock domain crossing required on an FPGA in order to move data from one clock domain to the other without losing integrity. You can place the FT245H into async mode but the interface isn't fully compatible, you'll need some glue logic and also FTDI only provides 8 bits of capture on those devices so you would need some intermediary to serialize address/data/control into an 8 bit interface.

Other than that everything in your write up you mentioned for the most part is possible today. I've written RESET-hijacked bootloaders to play with screen graphics, perform full cart DMAs and pass execution back to the real RESET vector to start the cart. The SNES-Tap FPGA also has a capability called enhanced memory mode which can be configured by the CPU via assembly. With this mode you can set up a DMA operation from CART/WRAM to/from address $21FF which is a local SNES-Tap DMA engine that will push or pull data onto the 32MB of SDRAM local to the FPGA. Then the host (independent of the console) can DMA memory from the 32MB SDRAM on the FPGA board directly to host. You are correct on the limitations of not being able to directly DMA from VRAM to SNES-Tap because they are both on addr bus B, but swap operation into WRAM should still be fairly fast. Sometime in the next month I'll be checking in this code into my github so you can analyze some of the patterns and techniques done in the FPGA.

defparam

Those exist: the "Universal Adaptor" used for region circumvention connects the game pins of the cart in the top and the CIC pins of the cart plugged in the back.


Agreed. At least a working cart dumper would give a valid excuse under 17 USC 117 for having an emulator.


Flashbacks to multiboot on the Game Boy Advance are hitting me. (In a good way.) 30 KiB/s is more than enough for streaming.


Now that'd really be GBA multiboot. (If you want a GBA, you know where to find it.)


Going forward, we might as well adopt something like the Super FX standard for vector redirection.

Half of the reason I'm developing for the SNES instead of the GBA is the fact that the GBA uses an ARM processor, where something like just loading a single number becomes a hassle. (I stopped right there, because I figured the rest would be like that.) The other half is the small resolution (literally half of the Irem M92 or the N64's typical resolution) and the fact that I'd rather work with a console instead of a portable system anyway.

I like the idea and possibilities of the device. It's very interesting. I like the idea of a boot loader for a serial upload for small demos/game programs to load into RAM. And the extension of the idea where you plop some RAM onto a cartridge PCB for even more fun.

For the RAM uploaded program, if the device already can hook the NMI interrupt, why not give the uploaded program a hand by using some location in RAM to hold the NMI vector? That way you don't have to spin everything on register read loops.

> To answer your question those ICs and Capactors on the board are level translators and bypass capacitors, 5v to 3.3v.

Ah, I see. I guess that'll rule out compatibility with my 5v Teensy 2 boards. But I get it, 3.3v is a lot more common. And probably in a few years we'll wish they were 1.8v =(

> For the RAM uploaded program, if the device already can hook the NMI interrupt, why not give the uploaded program a hand by using some location in RAM to hold the NMI vector? That way you don't have to spin everything on register read loops.

My main concern is it seems less safe and adds to the complexity of the device. But as long as this functionality can be disabled (or better, opt-in), then I have no objections to it.

Worst case, it could cause compatibility issues with certain software by stealing a tiny bit of Vblank time each interrupt. If you think that's minor, I once had Mortal Kombat II break completely because my timing was off by two clock cycles. With a library of over 2,000 poorly coded games, weird things can happen.

What I want is the simplest, cheapest possible device to hijack reset, and run a serial loader, and then get out of the way completely.

> Then the host (independent of the console) can DMA memory from the 32MB SDRAM on the FPGA board directly to host.

Ah, a large buffer is certainly doable as well. Even in the best case, you're not going to DMA more than 16MiB in either direction all at once.

Does your device require specialized driver software to use on the PC? That's one thing I definitely want to avoid, as I run rather obscure operating systems (eg Free/OpenBSD.) If it uses stock USB protocols or something, then there's no reason to have the controller serial cable adding to the cost when we can just put a micro-USB port on the SNES-Tap board.

> Other than that everything in your write up you mentioned for the most part is possible today.

Awesome! I really hope I can design a reset loader and get a couple of these devices made for my use. They'd really be very handy :D

> My main concern is it seems less safe and adds to the complexity of the device. But as long as this functionality can be disabled (or better, opt-in), then I have no objections to it.

NMI/Reset hooks can be turned on and off manually via CLI interface on the host. If you would like a programmatic way to that we can discuss the details


> Worst case, it could cause compatibility issues with certain software by stealing a tiny bit of Vblank time each interrupt. If you think that's minor, I once had Mortal Kombat II break completely because my timing was off by two clock cycles. With a library of over 2,000 poorly coded games, weird things can happen.

Thats pretty scary! not even enough time to jump in and out of a hook >=(

> What I want is the simplest, cheapest possible device to hijack reset, and run a serial loader, and then get out of the way completely.

So this clever reset glitch hijacking doesn't have to be done through an FPGA, we could look at how a low-cost low LE count CPLD can manage it. We could look at having a teensy try to manage the glitch but I worry about the precise bus timing with an embedded microcontroller

Perhaps the board would just be the level translator + small CPLD + some ROM.

> Does your device require specialized driver software to use on the PC? That's one thing I definitely want to avoid, as I run rather obscure operating systems (eg Free/OpenBSD.) If it uses stock USB protocols or something, then there's no reason to have the controller serial cable adding to the cost when we can just put a micro-USB port on the SNES-Tap board.

So i'm more of a hardware guy than a software guy, however I did write a python based CLI interface for this device. The backend of the python application uses the ctypes library to drive the FTDI's D2XX libraries directly on windows (interfacing to ftd2xx.dll for 32-bit and ftd2xx64.dll for 64-bit). All I really needed was READ/WRITE and rx buffer size count functions. So building those Ctypes abstractions were fairly straight forward. You can find D2XX's software API's on their website and I know they support Windows/Linux/ARM Android. I've gotten previous FT245H-based designs to work with FTDI drivers on my android phone

If your device uses the FT232 then you must be using similar libraries and so this device should work just fine.

The protocol I defined over USB Read and Write is fairly trivial. A command/address/length/data for write operations and a command/address/length for read operations. Also there is a separate ingress command for callbacks. Every time the SNES goes in and out of reset the FPGA issues a callback. Also within a NMI hook on the FPGA you can have the SNES CPU write a descriptor register on the FPGA to issue a callback with meta data.

If you look at the link below from my twitter I show an example of this CLI based application retrieving cart header information from Rockman X2 right out of reset. There is a reset hook defined whose job is to read location $00FFC0-$00FFFF and stream the data back to the host. In this image you see that data printed to the commandline.

https://pbs.twimg.com/media/CMkUpsXVAAAxez3.jpg


> Awesome! I really hope I can design a reset loader and get a couple of these devices made for my use. They'd really be very handy

At the moment the Rev B device consists of The SNES-Tap RevB board + DE0-Nano FPGA dev board by Terasic + Adafruit FT245H breakout board. I may have to go back to OSHPark and get more boards made if you are interested. I don't really have an assembly shop I kinda just do the reflow soldering myself.

Also in the near future I will be fabricating the Rev C board shown here:
https://pbs.twimg.com/media/CMHgRTOUwAAzWB2.png
https://pbs.twimg.com/media/CMHgRSFUMAAQLwf.png

The Rev C board gets rid of all the crazy wiring/breakouts and gives an all-in-one FPGA + memory + USB + levelshifters.

defparam

> NMI/Reset hooks can be turned on and off manually via CLI interface on the host.

That works great for me :D

> Thats pretty scary! not even enough time to jump in and out of a hook >=(

Indeed, if I recall correctly, it was setting up IRQs each scanline, and occasionally it'd set it just a bit too late and miss a scanline, causing really nasty line corruption.

You wouldn't hit the issue if your emulation ran faster than the real thing, nor if it were significantly slower. I hit a reverse-Goldilocks situation when I was homing in on perfect CPU timing.

> So this clever reset glitch hijacking doesn't have to be done through an FPGA, we could look at how a low-cost low LE count CPLD can manage it

That would be absolutely fantastic! Anything that would cut down the cost would help a lot. Even better if we could find a nice 5V CPLD and skip even the level shifters.

Of course, my desired use case could be very different from yours. You could for instance offer lots of additional features with the FPGA, like SNES->HDMI output, high-bandwidth transfers, an IDE header breakout for the pins for add-ons, etc.

> We could look at having a teensy try to manage the glitch but I worry about the precise bus timing with an embedded microcontroller

Yeah, plus the Teensy isn't really all that Teensy. It would be hard to slap onto the bottom of the deck without requiring elevating the SNES deck off the ground, and its power draw might be a good bit higher. It would be unfortunate if we had to run a DC adapter to this board.

> If your device uses the FT232 then you must be using similar libraries and so this device should work just fine.

Well ... FT232, Teensy, etc use a standard serial-over-USB interface. They show up as standard TTY devices you can talk to, and these all use open source drivers written by each OS vendor, rather than by FTDI. Don't even need special userland libraries. All you do on Linux is call open("/dev/ttyUSB0"), ioctl() the configuration settings, and then read() and write() to it. The major benefit here is plug-and-play on every OS.

I am not sure if there are D2XX drivers for FreeBSD or not, for example.

> Also in the near future I will be fabricating the Rev C board shown here:

Both the SNES card-edge connector and IDE header are on the same side of the board? How does that work? Won't connecting the card-edge cause the board to sink into the SNES deck, blocking the IDE header?

> I may have to go back to OSHPark and get more boards made if you are interested. I don't really have an assembly shop I kinda just do the reflow soldering myself.

Unfortunately, reflow/surface-mount soldering isn't something I can do :(

I do have about 50 PCBs made for qwertymodo's old design and a few tubes of the card-edge connectors from Samtec. But they've just been sitting in a box because I can't do anything with them.

...

So, if you're willing to help me (I'd be hugely grateful!), it would be ideal if we could design a something like this:

* SNES card-edge connector
** preferably not by hand-dremeling the Samtec connectors; but if there's just no way around it, then okay
* 5V CPLD (if impossible, then 3.3V CPLD + level shifters; but I'd pay more for 5V -> less complexity here.)
** only job is to replace $2184-21ff with a custom serial loader, and hijack reset vector to fetch $2184 instead of ROM[$fffc]
*** I'll write the routine that runs there, that should be easy enough. I can debug it through my emulator.
* nothing protruding from the other side of the PCB (the side without the SNES connector)
** we could put something under the PCB to protect it later, so eg your SNES could rest on carpet safely.
* no external power supply (use +5V/GND signals from the SNES deck, suck as little power as possible)

I'd definitely want to fund at least 10 of these for my own personal use (2 is probably enough, but I doubt I'll ever get the chance to have someone make one of these again for me); and ideally I'd like to fund more for the sake of selling / giving them out to other SNES developers that might help to improve SNES emulation.

Funding wise, it really depends. I could easily do $200. Above that, we could look into fundraising. I imagine it wouldn't be too hard to get us up to four figures, provided we give out boards to donors.

Ultimately, I would love to be able to produce these myself. Buy all the components and learn the soldering / CPLD programming required. But if that's just impossible, then I'd have to pay you to populate the boards for me too.

Also, in return, I'd be willing to lend my abilities to whatever you wanted to do. I can build SNES-Tap functionality into my emulator, make a PPU-only emulator (my PPU core is just as fast as Snes9X's, in isolation), etc.

>That would be absolutely fantastic! Anything that would cut down the cost would help a lot. Even better if we could find a nice 5V CPLD and skip even the level shifters.

>Of course, my desired use case could be very different from yours. You could for instance offer lots of additional features with the FPGA, like SNES->HDMI output, high-bandwidth transfers, an IDE header breakout for the pins for add-ons, etc.

Yes it appears your use case is much more minimalist (which is fine!). My goal isn't just to push out my vision of what debug board should be. One of my goals is also to help enable the dev community, so I don't mind helping out on a smaller , low cost version of this design. The only finite resource I worry about is my time as this isn't my day job.


> Well ... FT232, Teensy, etc use a standard serial-over-USB interface. They show up as standard TTY devices you can talk to, and these all use open source drivers written by each OS vendor, rather than by FTDI. Don't even need special userland libraries. All you do on Linux is call open("/dev/ttyUSB0"), ioctl() the configuration settings, and then read() and write() to it. The major benefit here is plug-and-play on every OS.

> I am not sure if there are D2XX drivers for FreeBSD or not, for example.

Ah ok I understand.. well the SNES-Tap uses USB 2.0 via FT245H configured in asynchronous FIFO mode. I am unsure about the native operating system support you mention. However I fear that since the async and sync FIFO modes are higher bandwidth they probably don't fall under a standard universal opensource operating system device model. I do believe you may need to download and use FTDI's drivers or instead use an opensource variant like libftdi/libusb.

>Both the SNES card-edge connector and IDE header are on the same side of the board? How does that work? Won't connecting the card-edge cause the board to sink into the SNES deck, blocking the IDE header?

OK yeah I think we need to discuss the mechanical keep-out areas so that we are on the same page However first I want to mention that on Rev C I do not breakout signals into an IDE anymore. Everything goes to the host via USB through that USB Mini connector. That header that looks like a mini IDE header is the JTAG to the FPGA which may or may not get populated. The design just uses USB for communication.

I understand your reservations on having components on the same side as the expansion port connector, wouldn't it interfere with the deck? Well if you look closely at the expansion port, it is fairly close to the edge/corner of the deck (at least on the USA version, i haven't checked the japanese version). The expansion port is a good 20-30 cm away from clearing the deck. So on that Rev C board i defined a keepout area to a certain point. That keepout area cannot contain any components otherwise you cannot achieve a mechanical mate. However I liked the idea of a board making a mate to the EXP port as flush as possible but having the board be long enough so that it peeks out the back of the console and you can see LEDs and USB interface on top side of the board while all IC components are on the bottom side.

Even with that configuration the height of the IC components + PCB thickness still is taller than the vertical clearance the deck gives you by design. So you'll always have to deal with a little tilt unless you raise the deck by putting some elevation on the feet.

> Unfortunately, reflow/surface-mount soldering isn't something I can do
for low volume runs 5-10 boards I can probably handle the assembly myself. Especially if its a simpler design


> I do have about 50 PCBs made for qwertymodo's old design and a few tubes of the card-edge connectors from Samtec. But they've just been sitting in a box because I can't do anything with them.

So if you have qwertymodo's original design fully assembled you may be able to use them to prototype some 5v CPLDs. Plus if you also have bunch of those samtec connectors unpopulated we should be able to use those parts for assembly as they are not cheap (I think for QTY 1 they run about 6 or 7 dollars these days, I could be wrong)

I understand the dremel issue is a pain. I know the Samtec FAE who works closely with my company (and gave me samples for Maker Faire). I'll ask about a custom connector and see what he thinks.

...

> So, if you're willing to help me (I'd be hugely grateful!), it would be ideal if we could design a something like this:

for me time is the biggest expense, not so much money. However I'm willing to engage for now, if we can draft up a design that I think has a chance, lets try it out.

> * SNES card-edge connector
> ** preferably not by hand-dremeling the Samtec connectors; but if there's just no way around it, then okay

yeah lets assume for now there isn't (unfortunately)


>* 5V CPLD (if impossible, then 3.3V CPLD + level shifters; but I'd pay more for 5V -> less complexity here.)

We can try out some 5v CPLDs. Ones that come to mind are:
1) Xilinx XC95xx devices
2) Atmel ATF15XX devices
3) Lattice ispMACH 4A devices
4) Altera MAX7000 devices

Some of these devices may be obsolete, 5v isn't popular these days but the military typically keeps it going.

> ** only job is to replace $2184-21ff with a custom serial loader, and hijack reset vector to fetch $2184 instead of ROM[$fffc]
> *** I'll write the routine that runs there, that should be easy enough. I can debug it through my emulator.

OK i was going to ask about memory. After the CPLD performs a glitch and redirects PC how much instruction memory do you need? Is it just 124 bytes ($2184-$21FF) or did you expect to DMA more into memory from the device? I suspect using a primary/secondary bootloader approach with your serial cable you probably just need 124 bytes, but correct me if i'm wrong.

> * no external power supply (use +5V/GND signals from the SNES deck, suck as little power as possible)

Hey if SD2SNES can borrow power from the SNES to power a xilinx spartan + arm + memory + etc.. then we should be OK with a tiny cpld + eeprom

>I'd definitely want to fund at least 10 of these for my own personal use (2 is probably enough, but I doubt I'll ever get >the chance to have someone make one of these again for me); and ideally I'd like to fund more for the sake of selling / >giving them out to other SNES developers that might help to improve SNES emulation.

>Funding wise, it really depends. I could easily do $200. Above that, we could look into fundraising. I imagine it wouldn't >be too hard to get us up to four figures, provided we give out boards to donors.

Yeah lets look at the initial quantity (of say 5 or 10) as a prototype run. It shouldn't exceed 200, but we have to draft up the design first and look at the BOM. I'm weary of donating my time to large manufacturing efforts. I'm not really an expert at manufacturing, and it can be time consuming

>Ultimately, I would love to be able to produce these myself. Buy all the components and learn the soldering / CPLD >programming required. But if that's just impossible, then I'd have to pay you to populate the boards for me too.

Time to invest in some solder paste and a hot plate skillet It's fun, i should conduct workshops.

Honestly I'm a big proponent for open source. If we can get something working and I can give the blue prints to you or the next hardware guy, all the better in my eyes.

>Also, in return, I'd be willing to lend my abilities to whatever you wanted to do. I can build SNES-Tap functionality into my emulator, make a PPU-only emulator (my PPU core is just as fast as Snes9X's, in isolation), etc.

So the market of people I also would like to cater to besides the devs is the twitch speedrunning community. This community for the most part uses native console hardware and can benefit from features like digital only graphics rendering for improved stream video quality, load/save state for CARTs which have complicated co-processor architectures (CX4/SA-1/etc..) and also from a dev point of few TASers may find use for such a device to perform glitch hunting. So if you could see lending expertise/resources in those areas that would be helpful.

OK since my expertise is mainly in Altera FPGAs/CPLDs a did a quick compile on a EPM7064STC44-10N in Quartus II 13.0sp1 (http://www.digikey.com/product-detail/e ... ND/1084671)

In this compile I took just the verilog from the SNES-Tap FPGA in charge of scanning and applying the reset hook glitch and added it to compile on this CPLD, plus I added the logic to create a 128-byte on-chip ram to read when the CPU comes to access $2184-$21FF. (this RAM can be initialized to contain a bootloader)

The compile just passed using 56 out of the 64 macrocells (88 % area utilization)

the EPM7064STC44-10N seems like a good candidate for the tiny board. The question I still have on my mind is since the SNES-Tap uses the level shifters to out drive the CART and force a vector override, can the EPM7064STC44-10N's output buffers also override those same signals with equivalent strength. I'll dig through the electrical characteristic of the device.

> One of my goals is also to help enable the dev community

This would definitely help me out a ton.

ikari_01 made a customized SNES deck for me with a special SuperCIC that allowed for cart-swapping to resync the CIC. This was required to dump SA-1/S-DD1 carts. The problem is, dumping an entire US set has worn out the connector (1-5 tries per cart + swap with dev cart), and now I need to dump 1445 more carts, so ... not being able to CIC-unlock means I can't dump any of the JP SA-1 carts right now. That also means I can't ever try to improve SA-1 emulation through BW-RAM tests.

> Ah ok I understand.. well the SNES-Tap uses USB 2.0 via FT245H configured in asynchronous FIFO mode. I am unsure about the native operating system support you mention.

Okay, I'll look into that. I want to try and help support whatever your official SNES-Tap design is too. I think software emulators go great with debugging/development, and would pair nicely with a hardware interface.

> That header that looks like a mini IDE header is the JTAG to the FPGA

Ooooh, okay. Makes sense :D

> However I liked the idea of a board making a mate to the EXP port as flush as possible but having the board be long enough so that it peeks out the back of the console and you can see LEDs and USB interface on top side of the board while all IC components are on the bottom side.

Yeah, that's cool. The reason for shorter boards was really the cost of the PCB. But like you said, we'll probably not be able to obtain 4-digit quantities of these, so it's probably no big deal.

> So you'll always have to deal with a little tilt unless you raise the deck by putting some elevation on the feet.

I'm thinking this will probably be essential anyway. Seems like having the under side of the PCB lying on carpet would be bad for ESD. So it's probably good to just require four adhesive risers to be placed under the SNES deck for this.

If we get this to a point I can give the boards out, I'll just include the risers with the board (and likely the serial controller cable.)

> So if you have qwertymodo's original design fully assembled

I have a single one that he sent me assembled. Tested all the pins, it works perfectly. I also have an IDE ribbon cable for it to get the lines into a breadboard.

If there's a breadboard friendly 5V CPLD, we could definitely go that route.

> I know the Samtec FAE who works closely with my company (and gave me samples for Maker Faire). I'll ask about a custom connector and see what he thinks.

Awesome, thank you! I tried reaching out to them myself, but not having any real contacts and being a small fish, I couldn't get past their first layer of customer service.

Try and get a minimum order quantity if possible. Even if it's insane like 5000+ units, as long as the per-unit discount goes up with the higher quantity, I might be able to fund-raise around that. Could even try out Kickstarter or something silly.

...

Per Digikey:

> 1) Xilinx XC95xx devices

13 pages of matches, quantities of 300 - 5000, prices from $1.50 - $20/ea.

> 2) Atmel ATF15XX devices

9 pages of matches, quantities from 300 - 1800, prices from $5 - $12/ea.

> 3) Lattice ispMACH 4A devices

15 pages of matches, quantities from 500 - 2000 per part, prices around $3 - $10/ea.

> 4) Altera MAX7000 devices

5 pages of matches, quantities from 60 - 400, prices around $12 - $40/ea.

...

Xilinx seems like the most affordable and has the highest quantity, but I've heard horror stories about them. Never heard of Lattice. I've heard a lot of favorable things about Atmel, so that may be the way to go?

Up to you, whichever you think would be better.

> After the CPLD performs a glitch and redirects PC how much instruction memory do you need? Is it just 124 bytes ($2184-$21FF) or did you expect to DMA more into memory from the device?

Just the 124 bytes is fine; we don't need DMA. Forgive my lack of knowledge on EE, but can the CPLD itself act as ROM at this size? Or do we need to have a separate ROM chip for this tiny bit of data?

> I suspect using a primary/secondary bootloader approach with your serial cable you probably just need 124 bytes, but correct me if i'm wrong.

That is correct. The code at $2184 would be a simple loop that polls the SNES controller port for serial data, and stores it at $7e2000+. Once done, it would jump there to begin execution. I have this code already written, and it sits on a dev cart.

But for this, I might try and fit a time-out to allow the device to stay plugged in and still boot regular carts. Depends on how much room I have left. I think my current loader's around 90 bytes already.

I'd like to be able to jump back to $2184 from my own uploaded code from the controller serial cable once a program is done executing, to allow another upload without resetting the console. Can't see any reason this wouldn't be possible, but just figured I'd mention it :)

> I'm weary of donating my time to large manufacturing efforts. I'm not really an expert at manufacturing, and it can be time consuming

Well ... I'm willing to learn the basics. If we can get this working, then I can buy up quantities in the hundreds, and then figure out how to use JTAG to program these CPLDs, and how to solder all the components onto unpopulated PCBs.

> So the market of people I also would like to cater to besides the devs is the twitch speedrunning community.

So human speedruns, not TAS speedruns.

The tricky part here would be that they frown upon anything that differs from the real game code. I would think hijacking NMI to send back things like PRNG state to a PC display to help them would constitute tampering with the timing of the original game :/

Digital graphics, I think that's possible. I actually wrote an SNES music format black box that worked by only replaying a log of $2140-217f writes to the chip, and this allowed perfect playback of streaming audio games. The same concept with $2100-213f writes for the PPU ... I see no reason why we can't get that to work. And I'm pretty sure we can get both the HDMI output and SNES PPU emulation onto an RPi 2, so it should be really cheap and portable, too.

> I have a single one that he sent me assembled. Tested all the pins, it works perfectly. I also have an IDE ribbon cable for it to get the lines into a breadboard.

> If there's a breadboard friendly 5V CPLD, we could definitely go that route.

OK I have the same exact board too (my version of it). Theoretically we could test these chips today using that board without the need of building a PCB or even soldering. If we get the 44-PPLC package of the MAX7000S and you get a 44pin plcc socket breakout board you we may be able to connect the chip to qwertymodo's board using just jumper wires:

44PLCC MAX7000S: http://www.digikey.com/product-detail/e ... ND/1084676
44PLCC breakout: http://www.ebay.com/itm/PLCC44-PLCC-44- ... 0847570276
JTAG USB-Blaster: bunch of cheap clones on ebay

> Awesome, thank you! I tried reaching out to them myself, but not having any real contacts and being a small fish, I couldn't get past their first layer of customer service.

I'll send an email on Monday

...

> Up to you, whichever you think would be better.

Some of those parts aren't in stock or obsolete. I'm going to stick to Altera for now but we can always switch.

> After the CPLD performs a glitch and redirects PC how much instruction memory do you need? Is it just 124 bytes ($2184-$21FF) or did you expect to DMA more into memory from the device?

>Just the 124 bytes is fine; we don't need DMA. Forgive my lack of knowledge on EE, but can the CPLD itself act >as ROM at this size? Or do we need to have a separate ROM chip for this tiny bit of data?

From the testing I did today the MAX7000S supports a 128 byte on-chip rom initalized by eeprom program configuration

> I'd like to be able to jump back to $2184 from my own uploaded code from the controller serial cable once a program is done executing, to allow another upload without resetting the console. Can't see any reason this wouldn't be possible, but just figured I'd mention it

This will work. The HDL described has the CPLD always responding to read requests between $2184-$21FF.

>Well ... I'm willing to learn the basics. If we can get this working, then I can buy up quantities in the hundreds, and then figure out how to use JTAG to program these CPLDs, and how to solder all the components onto unpopulated PCBs.

If you have quantities in the +100s to be done "manually" you should consider solder paste stencilling and toaster oven reflow. We'll cross that road when we get there.


> So human speedruns, not TAS speedruns.
yup

>The tricky part here would be that they frown upon anything that differs from the real game code. I would think hijacking NMI to send back things like PRNG state to a PC display to help them would constitute tampering with the timing of the original game :/

This is true. The use-case is more for improved video quality and during practice to enable load/save states on CARTs that currently do not have load/save state support with GameSaver or other RTS (like Rockman X2/X3, Yoshi's Island, Mario RPG). However you are right someone could use debug tools to cheat. The communities have some trust for the runners, for instance for some categories emulator is allowed and that can be tampered with.


>Digital graphics, I think that's possible. I actually wrote an SNES music format black box that worked by only replaying a log of $2140-217f writes to the chip, and this allowed perfect playback of streaming audio games. The same concept with $2100-213f writes for the PPU ... I see no reason why we can't get that to work. And I'm pretty sure we can get both the HDMI output and SNES PPU emulation onto an RPi 2, so it should be really cheap and portable, too.

I agree! sounds good

Well, first of all, my congratulations to defparam for such a clever way to take control of SNES system through Expansion Port. I couldn't read all comments yet, but it looks realy promising.
I could be interested on helping with this too; I'm a professional on FPGAs (Virtex4, Spartan6, Kintex and Zynq) and do some PCB designs. Besides, I've been SNES romhacking from more than a decade and a half, and could help with ASM coding.

@defparam:

Which kind of FPGA are you using? How do you do the level-shifting? I'm currently using TXB0108PWR to interface my Zedboard with SNES cartridge connector. Those level shifters are direction sensitive, so you can use them in bidirectional buses such as CIC and data bus.




Those cart-edge connectors from Samtec are just the same than those the SNES deck mounts? If so, which reference are they? I'm been looking at Samtec's website but I don't know which ones are them.


Well, I finally finished reading all comments and have some ideas:

* Xilinx Spartan6 XC6SLX4 is more powerful than a CPLD, its package is TQF144 which is not difficult to solder and it's about 12USD at most (local FAE could give better prices for more than 10 units). It has 216Kb of Block RAM, more than enough for all your ideas.

* You can execute virtually any code from $2184 to $21FF if you add a "BRA $7D" when accessing $21FE. You can implement a FIFO in the FPGA which gives a data byte whenever you access $2184 to $21FD sequentially, but a 0x80 when accessing $21FE and 0x7D when accesing $21FF. If you want to save resources, remove the FIFO and just decode the address to decide whether to give a data byte or the BRA.

> Which kind of FPGA are you using? How do you do the level-shifting? I'm currently using TXB0108PWR to interface my Zedboard with SNES cartridge connector. Those level shifters are direction sensitive, so you can use them in bidirectional buses such as CIC and data bus.

At the moment I'm using a Cyclone IV on the DE0-Nano kit. Once I get SNES-Tap Rev C. board in it will be using a MAX 10 FPGA. The level shifting is done using the NXP 74ALVC164245 and its variants. The same level shifters found on the SD2SNES.

> I could be interested on helping with this too; I'm a professional on FPGAs (Virtex4, Spartan6, Kintex and Zynq) and do some PCB designs.

Once I release the verilog feel free to port to whatever FPGA family you feel is better suited. There are some Altera-specific elements (i.e. SDRAM controller, Qsys-interconnect, AVL-MM memory mapped interfaces, SCFIFOs and ALTSYNCRAMs), but I'm sure there are equivalents on Xilinx-side.

> Those cart-edge connectors from Samtec are just the same than those the SNES deck mounts? If so, which reference are they? I'm been looking at Samtec's website but I don't know which ones are them.

qwertymodo/byuu identified the best suit connector for the EXP port, it is: Samtec MEC2-30-01-L-DV

The MEC2-30-01-L-DV is a 60-pin polarized connector, since the MEC2 doesn't have a 28-pin variant we use the MEC2-30-01-L-DV and saw/dremel off pins 29-60.

> * Xilinx Spartan6 XC6SLX4 is more powerful than a CPLD, its package is TQF144 which is not difficult to solder and it's about 12USD at most (local FAE could give better prices for more than 10 units). It has 216Kb of Block RAM, more than enough for all your ideas.

This is true but Byuu is looking for a single chip solution, bare minimal board to do that reset hook. If I can get away with just a MAX7000S which uses 5v logic and doesn't need a config mem... I may be able to make it a 1 chip board, and the MAX7000S I believe is 44-pin.

> * You can execute virtually any code from $2184 to $21FF if you add a "BRA $7D" when accessing $21FE. You can implement a FIFO in the FPGA which gives a data byte whenever you access $2184 to $21FD sequentially, but a 0x80 when accessing $21FE and 0x7D when accesing $21FF. If you want to save resources, remove the FIFO and just decode the address to decide whether to give a data byte or the BRA.

This is exactly what the snes-tap does when I was describing hook pages. However it is not a FIFO instead it is a block ram with 16*256B addressable memory. Once a hook finishes the SNES-Tap forces a branch at $21FD back to $2184 and the FPGA increments the address pointer (address bits 12 downto 9) to point to the second page in that block ram.

------
I have a devkit with an Altera MAX7000S. I'm going to test to see if the device can apply the reset hijacking correctly. I'll post results when my testing is complete.

Thanks!
defparam

> The MEC2-30-01-L-DV is a 60-pin polarized connector, since the MEC2 doesn't have a 28-pin variant we use the MEC2-30-01-L-DV and saw/dremel off pins 29-60.

Also worth noting that the pin pitch is wrong. It's .254 instead of .250 (or maybe I have that backwards?); however, with 14 rows per side, it's not enough for them to get misaligned enough to matter.

I haven't actually tried dremeling my connectors down yet; that's going to be fun. As will trying to rebuild the wall with epoxy or something. qwertymodo did a fantastic job on his though, it looks almost like a factory part.

> This is true but Byuu is looking for a single chip solution, bare minimal board to do that reset hook.

Yep, and I want to try and avoid as much soldering as humanly possible.

The PLCC package with the breadboard adapter would go great here. My serial controller for the PC is entirely on a breadboard as well.

The only part where I'm ruined is the Samtec connector requires surface-mount soldering. No getting around that.

> I may be able to make it a 1 chip board, and the MAX7000S I believe is 44-pin.

On that note, should I go ahead and order a couple MAX7000S chips, the breadboard adapter, and one of those USB blasters? (any preference? A lot of them say MAX7000S compatible, so I'm guessing it doesn't matter.)

I probably won't have the skill to write the VHDL for this CPLD to do what we want, unfortunately :(

> I have a devkit with an Altera MAX7000S. I'm going to test to see if the device can apply the reset hijacking correctly. I'll post results when my testing is complete.

Fantastic! Thank you so much again for working on this! :D

> Also worth noting that the pin pitch is wrong. It's .254 instead of .250 (or maybe I have that backwards?); however, with 14 rows per side, it's not enough for them to get misaligned enough to matter.

Woah 0.254mm/0.250mm pitch?! Thats way too small. You are thinking about the top cart connector. SNES top card edge connector has a pin pitch of 2.5mm and all modern edge connectors today are 2.54mm pitch 100mil. To get a 2.50mm edge connector you have to get it custom made. You can use the 2.54mm pitch connector but you may have slight electrical contact misalignment.

The expansion port is a different story. The pin pitch is smaller than cart at 2.0mm (0.0787") and the Samtec connect fits 2.0mm pitch exactly. No worries about misalignment.


> I haven't actually tried dremeling my connectors down yet; that's going to be fun. As will trying to rebuild the wall with epoxy or something. qwertymodo did a fantastic job on his though, it looks almost like a factory part.

Its not too bad, usually take pliers and pull the the contact teeth of pins 29-32, place the connector in a vice and use the rotating disc dremel bit to saw it off. Then I use another dremel bit to smooth/polish it down to size. None of mine have epoxy, but I like that idea.

> Yep, and I want to try and avoid as much soldering as humanly possible.
> The PLCC package with the breadboard adapter would go great here. My serial controller for the PC is entirely on a breadboard as well.


Feel free to test with the PLCC, however with my board design i'm going to use the TQFP-44, I'm worried that the throughhole from the socket will get in the way. By the way I forgot to mention that this design also requires a 25MHz clock to oversample the bus to pinpoint exactly when/where to apply the glitch.

> The only part where I'm ruined is the Samtec connector requires surface-mount soldering. No getting around that.
I can assemble boards for you, we can start with 10. I'll let you know if its becoming a hassle

> On that note, should I go ahead and order a couple MAX7000S chips, the breadboard adapter, and one of those USB blasters? (any preference? A lot of them say MAX7000S compatible, so I'm guessing it doesn't matter.)

The other complication is that 25 MHz clock I forgot to mention :/ , you may be able to feed an input pin with an ext clock from another board ... The USB-Blaster should be OK... most clones work, its fairly simple JTAG. You are also going to want to download Quartus II 13.0SP1 with the MAX device families installed. (don't get 14.0/15.0, Altera removed support for legacy MAX devices in 13.1 and on)

> I probably won't have the skill to write the VHDL for this CPLD to do what we want, unfortunately

The good news is I already wrote the verilog for you ... I should give an update as my testing is complete! So tonight I brought home a dev kit with a MAX7000S (a larger one with 128 Macrocells, but the design fits on the 64mcell too). I ported the SNES-Tap reset hook code to the MAX7000S and pinned out the chip to interface with the qwertymodo board. After some massaging I was able to see the reset vector being hijacked successfully!

The hook code I had in ROM at locations $2184-$2186 was $6C/$FC/$FF ... so basically an indirect jump to the reset vector. I saw in my analyzer the hook addresses being read from the CPU! and the game executed normally with no issues!

It's now confirmed that the MAX7000S works perfectly for hooking reset @ 5volts on the expansion port. I think now I have enough confidence to start designing a 2-layer board in Altium.

I will upload the verilog to my github tomorrow or the day after so everyone can get a feel of what the HW looks like, and you can see where exactly to place your bootloader.

> Fantastic! Thank you so much again for working on this!
No problem! its fun

> To get a 2.50mm edge connector you have to get it custom made. You can use the 2.54mm pitch connector but you may have slight electrical contact misalignment.

Ah yes, this is what I was thinking of. Off by one decimal place (no big deal, just an order of magnitude :P), and was thinking of the wrong connector.

Heh, I have such a horrible memory >_>

I think I remember now ... I considered that this same kind of device could be made, and also be much more powerful (eg MSU1 support) by a cartridge pass-through connector. But that turned out to be even more troublesome because of sourcing the card-edge connector for the original carts.

> The expansion port is a different story. The pin pitch is smaller than cart at 2.0mm (0.0787") and the Samtec connect fits 2.0mm pitch exactly. No worries about misalignment.

Ooooh, excellent! So all we have to do is hope that we can convince them to do a run of 28-pin connectors for us :D

> By the way I forgot to mention that this design also requires a 25MHz clock to oversample the bus to pinpoint exactly when/where to apply the glitch.

Ah, rats. More wiring :(

> It's now confirmed that the MAX7000S works perfectly for hooking reset @ 5volts on the expansion port. I think now I have enough confidence to start designing a 2-layer board in Altium.

Wow, you are super fast at this!! :D

I'll probably be a bit slower on my side in trying to design the 124-byte bootloader.

Not sure whether we should try programming the MAX7000S and its bootloader before soldering up the board (which I guess is crystal + MAX + Samtec connector), or after (by exposing a header for the JTAG pins or something)

If it's the former, I'll need to complete the bootloader first. If it's the latter, then you should be able to put dummy data in there for now, and I can iterate on the bootloader design over time with that USB blaster.

My plan to create the bootloader is to emulate this "reset hijack" device in higan. I already emulate my synchronous UART controller in higan, so if I can get a game uploaded from reset in higan, then I'll know it works.

> I can assemble boards for you, we can start with 10. I'll let you know if its becoming a hassle

Excellent! Thank you very much!

I think having ten populated boards with my desired bootloader should work great.

And having the part-list and such, I can always get the parts for more and work out how to populate the PCB later on if I end up having a need for more than 10.

That's a really neat project idea.

I just wanted to mention regarding 5V CPLDs, you may know this already, but there are some 3.3V CPLDs that are have 5V-tolerant inputs. Such as XC95XL, and ispMACH4000. Because you need 5V out, you could always add a buffer like 74HC245. That may require more parts, but it could end up cheaper and easier to source.

I see Memblers beat me to mentioning the XC9500XL parts. They work great, especially considering the true 5V XC9500 line is EOL. They're really handy if you need to interface with other 3V parts, since they can basically act as level shifters. Also, they're way cheaper than the Altera parts. You might not need to convert the 3.3V outputs to 5V if the SNES accepts TTL logic levels, as the XC9536XL datasheet lists VOHmin at 2.4V. If the SNES requires CMOS inputs, then you might be out of spec.

> Wow, you are super fast at this!!

Haha, yeah I can port FPGA designs fairly quickly. I was lucky enough to find a devboard of such an old CLPD. Attached is an image of that devboard wired up, based on the peripherals on board you can see its age (circa 1997~). The top probe is my USB-Blaster, the wiring on the left is my 8-channel 24MHz digital analyzer, and the rest of the wiring is direct 5V to the expansion. The 8-channel analyzer was needed because MAX is old enough where it pre-dates support for on-chip analyzers like signaltap



Don't worry about me going too fast. Making the board will take me a day or 2 and OSHPark lead time is around 2 weeks. My next 3 weeks will be busy for me as I'll be traveling to Vermont for vacation, so I may go quiet for a bit.

> If it's the former, I'll need to complete the bootloader first. If it's the latter, then you should be able to put dummy data in there for now, and I can iterate on the bootloader design over time with that USB blaster.

So i can write a simple bootloader for just initialization, Maybe something that does "wait 5 seconds, jump to reset routine", something to give confidence that it is working. I think I may have to populate the board with a 10 pin JTAG header so that you can re-program the bootloader. Either I add the header or just add the pads for you to solder JTAG probes to and keep the board flat.

Compiling/Programming your own CPLD image is very easy once I give you the verilog and the spot to place your bootloader. The compiles take less than a minute, the programmer takes another 30-60 seconds.

> That's a really neat project idea.
Thanks!

>I just wanted to mention regarding 5V CPLDs, you may know this already, but there are some 3.3V CPLDs that are have 5V-tolerant inputs. Such as XC95XL, and ispMACH4000. Because you need 5V out, you could always add a buffer like 74HC245. That may require more parts, but it could end up cheaper and easier to source.

I agree, I'm not sure how long the MAX7000S's will be kicking around but there are QTY 2000+ on digikey (and like I said, I think military applications keep these older chips alive). However If it does go obsolete your solution is also viable albeit with more populated ICs on board.

defparam

> I see Memblers beat me to mentioning the XC9500XL parts. They work great, especially considering the true 5V XC9500 line is EOL. They're really handy if you need to interface with other 3V parts, since they can basically act as level shifters. Also, they're way cheaper than the Altera parts. You might not need to convert the 3.3V outputs to 5V if the SNES accepts TTL logic levels, as the XC9536XL datasheet lists VOHmin at 2.4V. If the SNES requires CMOS inputs, then you might be out of spec.

I'm unsure about if SNES is CMOS or TTL spec but the other concern I have is that I may need all 5 volts for out-driving the CART and forcing a glitch on the bus, but that's fine an XC9500XL part with a 74 series front end level translator or buffer is a fine design as well. I'm just an Altera guy and I like the idea of single chip

I like single-chip as well, I just don't like paying 5x as much for that single chip over the alternative

But I see what you mean about out-driving the cart on the bus... that's kind of iffy even under ideal circumstances.

> the wiring on the left is my 8-channel 24MHz digital analyzer

Will we be able to get by with just: { PCB + Samtec connector + MAX7000S + 25MHz crystal + 10-pin IDE header for JTAG } ? Or will we need additional components? (resistors, capacitors, etc) The less components on the board, the easier and cheaper they'll be to assemble.

It's of course not a big deal since you've graciously offered to produce ten of these. But if I were to try offering these at a future point, ease of assembly would be a very desirable trait :D

> Don't worry about me going too fast. Making the board will take me a day or 2 and OSHPark lead time is around 2 weeks. My next 3 weeks will be busy for me as I'll be traveling to Vermont for vacation, so I may go quiet for a bit.

Okay, that's cool. That'll give me time to finalize some of my software stuff.

> So i can write a simple bootloader for just initialization, Maybe something that does "wait 5 seconds, jump to reset routine", something to give confidence that it is working.

Sure. I can write a quick routine for you to that aim that'll set the screen color to green, wait a few seconds, then jump to the real reset vector.

> I think I may have to populate the board with a 10 pin JTAG header so that you can re-program the bootloader.

Oh wow, I thought JTAG was like 4 pins or something. Well yeah, that's fine. I definitely like the idea of being able to reprogram the MAX7000S as needed.

> Either I add the header or just add the pads for you to solder JTAG probes to and keep the board flat.

I'd rather you add the header, please :D

My preference would be to have it be an IDE header with the guard to only allow connecting the cable the correct way.

I'm planning to just put some pegs on the bottom of my SNES deck to keep it off the floor, so it won't matter if it juts out from the bottom for these ten prototype boards.

If the idea takes off and we were to try selling these to people, then I'd like the final version to be able to lie flat on the carpet flush without damaging anything. But no need to worry about aesthetics here.

Durability is really key, though. I'd like to make sure these ten units last as long as humanly possible, and I'm okay with paying extra for that :D

> I agree, I'm not sure how long the MAX7000S's will be kicking around but there are QTY 2000+ on digikey (and like I said, I think military applications keep these older chips alive). However If it does go obsolete your solution is also viable albeit with more populated ICs on board.

To me, the MAX7000S quantity is definitely sufficient. If the ten boards all work out great, I'll probably order parts to make 50 more of these just to sit on them.

And even if in the future we end up burning through all 60 and need more, then we can port the design to a 3.3V board with level shifters and all that jazz.

It won't really matter when both the 3.3V and 5V versions do the exact same thing, and run the exact same bootloader.

Really, the next big issue is going to be reducing the cost and complexity of the USART controller board.

Technically, the direct SNES -> FT232 cable is UART, and so it caps out around 2KiB/s. The full USART to get 30KiB/s is much more complicated ...

This isn't really viable:



The Teensy 2.0++ is $33 after shipping, the breadboard is another $10, the two breadboard DB9 mounts are $8 a piece, the SNES extension cable to cannibalize is $8, even the digital SPDT is $3 (I know, what the hell, right?) Then you have to cover the USB cable, the DB9 solder cups, the DB9 metal shields, the shrink tubing, the wiring, the physical SPDT, the LED, the two resistors, and about 4-6 hours of work.

I'm sure there's a chip out there which can act like a USB to serial adapter with a synchronous mode UART. A lot of the complexity of my design was implementing pass-through. With my design, you can have a regular controller and the USART plugged into the same port. Toggle IObit to digitally enable the USART, or toggle the physical SPDT to forcefully disable the USART. Those aren't -essential-, but both sure are nice because they allow you to leave the device permanently plugged in. Same reason I'd like the timeout on the SNES-Tap boot loader.

May I throw in that as a developer, I'm really excited about this project and can't wait to see it done? I'd buy at least one of the units (EXT-connector + serial cable) as soon as they're ready for release.

I know that we can technically build a more powerful SNES-Tap that does the much faster DMA buffered transfers to the PC, eliminating the need for the serial cable.

But I guess what I like is the idea of having all of these components being mix-and-match.

Serial controller + expansion bootloader: ideal for dumping cartridges and doing coprocessor research.

Serial controller + flash cart: ideal for doing SNES hardware research, and for creating new games with debugging I/O functionality. Could also be used as an alternative to the MSU1 for streaming audio (have the PC play back tracks, mix the PC audio out with SNES audio out) or for adding netplay support to games.

Serial controller + new developer cartridge with gobs of RAM, a BIOS, and an ARM CPU: ideal for creating an "SNES+" SDK that lets you write new SNES games in C.

Serial controller alone: could be used solo if someone releases a new SNES game on cart that can talk to it.
SNES-Tap alone: could be used for HDMI output.
sd2snes alone: MSU1 support :D

There's also the SNES Jr and all those awful clone systems that don't have the expansion port. And there are people who can't afford a $200 sd2snes that may be able to swing $30 for a serial cable (presuming we can make them cheaper.)

But the expansion port is much preferred to a cartridge port pass-through because sourcing SNES cartridge card edge connectors is even more challenging than the expansion port (especially with the extra pins some boards have), and it's also quite a bit uglier to have something sticking out the top of your deck.

So, you know. Let's make as much use of every port as we can.

Definitely.

Speaking of that serial cable, I can still totally build that simplified version we discussed way back whenever that was. I just don't have the software side of things to test out the final result. If you send me your boot ROM and PC-side software, I'd be willing to give it a shot...

Regrettably, I've completely forgotten about our talks of a simplified USART design >_<

I'm a ways away from getting this stuff working again.

I have to finish up icarus, then get higan v095 out.

After that, I still need to get bass building again, then get all the USART stuff working on FreeBSD (never tried it except on Linux before.)

So it'll probably be a while, but sure, I'll send it your way once it's up and going again.

>Will we be able to get by with just: { PCB + Samtec connector + MAX7000S + 25MHz crystal + 10-pin IDE header for JTAG } ? Or will we need additional components? (resistors, capacitors, etc) The less components on the board, the easier and cheaper they'll be to assemble.

The power inputs for the CPLD will requires 0.1uF bypass capacitance, since there are 4 VCC inputs we'll place the capacitors near by those pins, and perhaps maybe one more for the oscillator. For the newer FPGA families I know the JTAG requires some 10kohm pullups/downs, but for these older CPLDs I think they are OK being directly connected.

I was thinking about added a red power LED and 2 green status LEDs that can be mapped to registers and written to @ $2184, but its up to you. It can be designed on the board but doesn't need to be populated. Also I was also thinking of breaking out the unused I/Os to copper pads anyone can solder to. This way if someone wants to change the CPLD to do something else wacky they can solder to more I/O in an easier way.

Here is the pinout for the package:



> I know that we can technically build a more powerful SNES-Tap that does the much faster DMA buffered transfers to the PC, eliminating the need for the serial cable.
Yeah, I mean its not too difficult to throw a FT232H on this and get full SNES DMA over USB 2.0, but i'll keep this simple for now. The controller port cable is interesting it reminds me of how embedded hackers reverse engineer firmware and get a bootloader to work via UART over an LED

> Oh wow, I thought JTAG was like 4 pins or something. Well yeah, that's fine. I definitely like the idea of being able to reprogram the MAX7000S as needed.

you are correct, JTAG is precisely 4-pins. However the Altera standard JTAG header pinout is 10 pins for all their devices, it contains like 2 GNDs and like 3 or 4 NCs. To use the USB-Blaster we kind of have to mate to this format. I'll add the header with the guard and plenty of indication of pin 1

byuu, even if you just had a working ROM that I could throw onto a boot cart, just so I could confirm that my firmware was performing as expected, that would at least be enough to throw something together. I might even try to build an even smaller version out of my favorite USB PIC, the PIC16F1455, now that the M-Stack firmware includes CDC-class support, though I've never tried bandwidth benchmarking it... it'd be dirt cheap though. Heck, the SNES controller connector would be the most expensive part, and even that is only ~$2US.

Random aside, one of my minor gripes with Xilinx is that they have NEVER had a standard JTAG header pinout, so you just have all 6 wires hanging loose and you connect them all separately, and you get to make up your own pinout every time you make your own board. :/

Well, beggars can't be choosers, so I'll certainly work with whatever I get ^^'

But if it's all the same and you don't mind ... I'm really big on absolute minimalism. I like to keep everything as tiny and simple as possible. The less there is, the less that can go wrong :)

Code for writing to $218x would add to the Verilog source size. Extra I/O pads that I could never solder to would just make the PCB look more complicated. I don't like logos, I don't like LEDs (I have black masking tape on nearly every electronic device I own), etc.

When I hear caps, I worry about electrolytic ones leaking or drying out over time. Have had many things break on me for that reason >_> But if they're a requirement, then they're a requirement. Nothing can be done about it.

I know my USART looks complicated. But that's because I am not an EE. That was the best job I could do. The LED was out of necessity since I didn't have a way to clearly label the on/off switch for the device.

> Yeah, I mean its not too difficult to throw a FT232H on this and get full SNES DMA over USB 2.0, but i'll keep this simple for now.

I'm certainly all for the full-featured model as well! Eg your official SNES-Tap. There's no reason we can't do HDMI video output + hardware save states + TAS functionality + SNES DMA over USB + LED over MMIO writes + other features for the official SNES-Tap :)

I'll be very interested in buying one or two of those off of you once you have them up for sale, assuming you sell them of course :)

Just, for this use case ... I'm highly in favor of simplicity. Eg hence wanting to use the 5V CPLD to save on the need for the level shifting components.

If I were 100% certain I could make a finalized bootloader, I'd even say to program that on and not have the JTAG header. But knowing me, I'll probably want to change it later on, and I won't be able to solder on to headers myself to do so; so that's more of a necessary evil to me.

> you are correct, JTAG is precisely 4-pins. However the Altera standard JTAG header pinout is 10 pins for all their devices

Aaah, okay, gotcha. And that's perfect! Being able to plug the USB-Blaster directly into this would be extremely convenient :D

I guess if you had the extra pins unconnected, and I could just flash a simplified version of the Verilog code that lacks the MMIO write functionality, etc, then it would be a decent compromise :D

> byuu, even if you just had a working ROM that I could throw onto a boot cart, just so I could confirm that my firmware was performing as expected, that would at least be enough to throw something together.

I might. Although my Makefile clean commands usually remove binaries, and I've never built bass on FreeBSD. Worst case, I guess I can throw the USART source onto my FTP server, then build that with the bass for Windows binaries I am hosting ...

I'll see what I can get together.

> But if it's all the same and you don't mind ... I'm really big on absolute minimalism. I like to keep everything as tiny and simple as possible. The less there is, the less that can go wrong

> Code for writing to $218x would add to the Verilog source size. Extra I/O pads that I could never solder to would just make the PCB look more complicated. I don't like logos, I don't like LEDs (I have black masking tape on nearly every electronic device I own), etc.

> When I hear caps, I worry about electrolytic ones leaking or drying out over time. Have had many things break on me for that reason >_> But if they're a requirement, then they're a requirement. Nothing can be done about it.

This variant is more for you than me since you are providing funding. Also since it will be open source anyone can create their own variant with bells/whistles (like SNES-Tap)

So OK, no LEDs, minimal silk screen, bypass caps required (sorry) it should only be 4 or 5, we can also use larger ones like 0603s and higher so that they are easier to hand solder. I'll keep the board PCB absolutely clean. You can review the 3D model before I ship the gerbers.

Thanks,
defparam

byuu, the bypass caps will be ceramic, so don't worry too much there. They're pretty much required, though.

SNES-Hook 1.0 - A bootloader for the SNES console

As promised here is the quartus project and verilog source code for the SNES-Hook bootloader:

https://github.com/defparam/snes-hook

There are no Altera-specific primitives instantiated in this verilog. It is pure Verilog-2001. Feel free to port to your FPGA vendor/family of your choice. The quartus project file should compile without error on Quartus 13.0SP1 with MAX device families installed. Currently I haven't constrained the pins. Once I layout the board I will update the constraints with absolute pin locations.

byuu - Whenever you feel ambitious you can try to download the Quartus II 13.0SP1 Webpack for Windows or Linux (CentOS/RHEL-based systems) and see if you can create a programming (*.pof) file. Also the file of interest for you would be the bootcode.hex file which is a plain ascii-hex description of the bootrom.

Also byuu tonight I got the initial placement done. Here are the 3D images. Let me know if you are OK with them or if you want to change anything.








Thanks all,
defparam

> https://github.com/defparam/snes-hook

Oh nice! That's a surprisingly tiny amount of Verilog, too :D

> byuu - Whenever you feel ambitious you can try to download the Quartus II 13.0SP1 Webpack for Windows or Linux (CentOS/RHEL-based systems) and see if you can create a programming (*.pof) file.

Okay, I'll dig around for it when I have some time freed up.

> Also byuu tonight I got the initial placement done. Here are the 3D images. Let me know if you are OK with them or if you want to change anything.

Oh wow, it's so tiny! I love it :D

> So OK, no LEDs, minimal silk screen, bypass caps required (sorry) it should only be 4 or 5, we can also use larger ones like 0603s and higher so that they are easier to hand solder. I'll keep the board PCB absolutely clean. You can review the 3D model before I ship the gerbers.

I feel terrible for having you design things according to what I want, when it's you putting in the work. Please accept my sincere apologies on that. But I am truly very grateful for this! :D

Dumping my 1450 Super Famicom cartridges is going to be so much faster now! And I can finally get rid of my Super UFO 8.3j and floppy disks. I had been using them to reprogram my SRAM devcart which contained the serial loader. It would frequently get erased due to the cart swapping I had to do to dump carts. Plus, no more need for the failing SuperCIC deck!

>Quartus II 13.0SP1 Webpack for Windows or Linux

there is a good guide on the arch wiki giving some hints how to get 13.0SP1 running on more mordern linux systems

https://wiki.archlinux.org/index.php/Al ... n_Software

> there is a good guide on the arch wiki giving some hints how to get 13.0SP1 running on more mordern linux systems

I never seen this guide before, thanks for sharing!

> Oh wow, it's so tiny! I love it

OK cool , hoping routing it won't be too bad on 2-layer but the vertical height constraints + pads on top and bottom should be an interesting challenge. Once i'm done routing i'll post the schematic up on github for review before sending off the gerbers.

> I feel terrible for having you design things according to what I want, when it's you putting in the work. Please accept my sincere apologies on that. But I am truly very grateful for this!

No worries, the LEDs were more for a hw debug capability because this device is pretty much a blackbox right now. Since this design is super simple and since I was able to confirm the design on a MAX dev kit on monday i'm much more comfortable leaving out peripherals for board debug. I may add copper pads to the bottom for quick signal access, or better yet i'll see if I can use the unused pins on the JTAG header for some debugability as long as it doesn't interfere with the programmer.

defparam

> I may add copper pads to the bottom for quick signal access

Yeah, that should be fine if you like.

> or better yet i'll see if I can use the unused pins on the JTAG header for some debugability as long as it doesn't interfere with the programmer.

Also fine, but if you do this, please test with one of the affordable USB-blasters, and let me know the exact make and model, so I can buy the same one and positively rule out any unlikely / weird compatibility issues =)

Probably safer to have them just be separate pads. But if you're sure it's safe, then I'll trust your judgment. You know the Altera stuff a whole lot better than I do :D

OK layout and routing is complete and the altium design files have been check-in to: https://github.com/defparam/snes-hook

The schematic is located here: https://github.com/defparam/snes-hook/r ... ematic.pdf

preview of the top layer: http://i.imgur.com/C6e6tDT.png
preview of the bottom layer: http://i.imgur.com/Nk3QGbe.png

Changes:
I had to add 4 1K ohm resistors to pull up/down the JTAG lines. I wasn't going to do this at first but it is recommended per application note 95: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an095.pdf
Warning: I forgot to mention this before but since this is an EEPROM-based CPLD Altera guarentees at least 100 erasures. After that state may start to degrade. I would suggest testing a bootloader on an emulator rather than testing on CPLD. Also since we are using an initialized RAM acting as a ROM, we may be able to allow for access to the write port for post power-up re-init.

If all is good with the schematic and design I can place the OSHPark order on Sat/Sun, until then feel free to review and comment. For 9 copies of this board it will be around $22 shipped (they do multiples of 3). The estimated BOM right now is around $12.00 per qty 1 assuming you leverage your MEC2 connectors, otherwise it will be around $19.00. (part costs don't include shipping)

> Also fine, but if you do this, please test with one of the affordable USB-blasters, and let me know the exact make and model, so I can buy the same one and positively rule out any unlikely / weird compatibility issues =)

I have a bunch of the low cost ones. I send you one on the house.

Thanks,
defparam

Unfortunately I'm not qualified to say anything on the hardware design.

But from a visual standpoint, everything sounds good to me, including the price.

So ... 100 writes. That's really quite low, huh? It should be fine, though. I only expect to program it once after I've received them. I'll keep in mind that they're not resilient enough to keep doing it. I suppose you'd program it the first time to test the unit (if you don't mind testing, that is ... I'm not very good at testing, let alone repairing, issues x.x), so that'd be two total writes a piece.

Also, you say that it's RAM that acts as ROM. Does that imply the device needing to maintain power to hold the RAM? Or is it NVRAM?

I assume it's part of the configuration bitstream that gets copied into the device's block RAM at power on, the same way a PC-based emulator or Nintendo's Virtual Console loads a "ROM".

Only 100 erases? Wow, I didn't realize it was that low. I had a university PLD's course where we used a MAX7000 chip (I think it was the 7064), and we used it all term. I'll bet mine is pretty much used up at this point. Bummer, I made a nice PCB version of the class dev board and everything...

Wow! nice design. Looks good

Yeah I think the 100-erases is probably an ultra conservative number to keep customers from using it like an FPGA for support reasons. It may burn out closer to 500-1000 depending on the silicon.

OK Quick update!

I sent the board gerbers out to OSH Park and ordered 9, they should arrive in 2 weeks. When I get a chance i'll start putting orders in for the other components. (I'll direct message you Byuu when I do).

For those playing at home feel free to buy the board direct from OSHPark here: https://www.oshpark.com/shared_projects/TfNKjUM6
Keep in mind it hasn't been tested working yet.

Thanks all
defparam

OK so I moved the SNES-Hook discussion to a different thread.

Here is a quick update on SNES-Tap!

https://www.youtube.com/watch?v=dE_q4EpsLco

Thanks,
defparam