Hi,
Have some of you ever heard of this?
http://www.retrocollect.com/News/save-s ... tendo.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-Tap: save your game whenever you want... really?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: SNES-Tap: save your game whenever you want... really?
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.
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.
Re: SNES-Tap: save your game whenever you want... really?
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.mic_ wrote: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.
Re: SNES-Tap: save your game whenever you want... really?
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.
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.
Re: SNES-Tap: save your game whenever you want... really?
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
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
Re: SNES-Tap: save your game whenever you want... really?
> 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!
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!
Re: SNES-Tap: save your game whenever you want... really?
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
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
Re: SNES-Tap: save your game whenever you want... really?
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.byuu wrote:or made some kind of dummy "CIC-only" cart.
Agreed. At least a working cart dumper would give a valid excuse under 17 USC 117 for having an emulator.Cart dumping doesn't really matter if it takes 1-2 minutes, since you aren't going to be doing that very often.
Flashbacks to multiboot on the Game Boy Advance are hitting me. (In a good way.) 30 KiB/s is more than enough for streaming.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.
Now that'd really be GBA multiboot. (If you want a GBA, you know where to find it.)Maybe an ARM processor so that people can write SNES games in C instead of assembly
Going forward, we might as well adopt something like the Super FX standard for vector redirection.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.)
-
Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: SNES-Tap: save your game whenever you want... really?
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.tepples wrote:(If you want a GBA, you know where to find it.)
Re: SNES-Tap: save your game whenever you want... really?
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.
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.
Re: SNES-Tap: save your game whenever you want... really?
> 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
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
Re: SNES-Tap: save your game whenever you want... really?
> 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. 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
Re: SNES-Tap: save your game whenever you want... really?
> 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 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.
Re: SNES-Tap: save your game whenever you want... really?
>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.
>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.
Re: SNES-Tap: save your game whenever you want... really?
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.
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.