nesdev.org

In [url=http://forums.nesdev.com/viewtopic.php?p=100828#p100828]this topic[/url], nocash wrote:How are other SNES emulators doing character output? What I/O address(es) are they using? Which emulator(s) do support character output? Are there any?

I believe blargg did something like that for the NES; but no SNES emulators support direct character output.

However, take a look at USART. With a few simple parts, you can send and receive data over the controller port (synchronous, so no tricky timing to consider), and then you can write a PC program that can handle printing text, writing to files, reading from files, etc. The PC program allows for any kind of debugging you want.

The nicest part is it works under my emulator -and- on real hardware, so you can debug software on both with the same code.

If you really want to implement this as a print text only option ... go with $21c0-21ff, so that only PA7+PA6+/PAWR need to be watched. It probably doesn't matter, but the SA-1 maps $2200 (CPU control); which might matter for 16-bit writes (accidental or otherwise.)
If you're willing to help me make an SNES expansion port connector, I'll write the firmware to drive an LED to print out messages on real hardware as well as emulate it in software. Thread

The controller port connection looks useful, too. Downsides are that it's a bit slower, and won't work if you want to use two controllers during debugging. Using an 8bit port will be faster, and it's easier to implement (both for SNES game authors and SNES emulator authors).
I am not really planning to implemt it on real hardware. Doing that would be quite simple, but just doesn't seem to be that important to me. On hardware, one would need some extra logic for receiving a "Busy" flag by reading from some I/O address.

SA-1 with port 2200h... oh yes, good that you mention it! Thanks! I was always wondering why nintendo used 8bit I/O ports on a 16bit cpu. And now I'be been almost doing the same thing :-) Then I'll change it to this:
21FCh 8bit character output
21FDh 8bit unused, no function
So one could do either 8bit or 16bit writes to 21FCh.

Can't help on making connectors for the SNES expansion port. Another option would be to plug something between SNES and game cartridge (as done by Game Genies), but the cartridge slot is also having a nonstandard pitch (2.50mm instead of 2.54mm).
For DIY projects it would seem easiest to me to wire a standard connector directly to solder points on the SNES mainboard. Downside would be that people would need to do that themselves, and can buy it ready for use.

Btw. for the NES, I've found this: viewtopic.php?p=82422#p82422

> Downsides are that it's a bit slower, and won't work if you want to use two controllers during debugging.

Slower, yes. 40KB/s max, 20KB/s practical for your typical code. Not a big deal for text printing.

It definitely works with two controllers. It was designed so that IObit toggles the USART vs the controller. It works in both ports, but it's ideal to place it in port 1, since port 1 doesn't ever use IObit officially (multitap, super scope and justifier all go in port 2. Mouse almost always does, at least.) Also slightly faster since $4016 is both latch and clock for RMW operations.

Anyway it's your call. I just like that it works on real hardware, too. Nobody's going to be developing SNES games on either of our emulators. Aside from d4s' two games, there is no SNES homebrew scene.

> On hardware, one would need some extra logic for receiving a "Busy" flag by reading from some I/O address.

If it's a one way output port and always live or buffered, watching /PAWR would be enough.

> Then I'll change it to this: 21FCh 8bit character output

Annoying address decoding if someone did choose to make it on hardware, I'd choose $21c0, but whatever.

> Another option would be to plug something between SNES and game cartridge (as done by Game Genies), but the cartridge slot is also having a nonstandard pitch (2.50mm instead of 2.54mm).

Yes, very true. But even harder to get a full passthru (both male card into the SNES, and female edge card connector. Though you could more easily cannibalize SNES units than Exertainment / BS-X units for those.)

I really wish I could understand why all these other people have no problems sourcing these components. I contact a dozen "edge card manufacturers" and none of them are willing to work with me at all. The guy that made the NES one won't even respond to a simple message.

I guess I'll just go with my FFC attempt, then.

> Btw. for the NES, I've found this: viewtopic.php?p=82422#p82422

Seems overly complicated, and could never work on anything but an emulator. But I suppose it would be easier for someone writing assembler code targeting that emulator to quickly output data with.

byuu wrote:Nobody's going to be developing SNES games on either of our emulators. Aside from d4s' two games, there is no SNES homebrew scene.

Some of SNES homebrew games released in 2011-2012, not by d4s: Chrismas Craze (16-bit XMas), Classic Kong (Complete), Uwol: Quest For Money, Mazezam Challenge.

bsnes was used to develop two of them at least, the debugger version (v060d) mostly.

And I've used BSNES (also 0.60d) a lot while developing the menu software for the SNES Myth flashcart (though for the hardware-specific parts like accessing the on-cart RAM and SD-card interface I obviously have to test on the real thing).

byuu wrote:...I really wish I could understand why all these other people have no problems sourcing these components. I contact a dozen "edge card manufacturers" and none of them are willing to work with me at all. The guy that made the NES one won't even respond to a simple message...

Might be worth contacting Matthias over at Retrode.org, he got a load of Snes cart connectors made for his Retrode production run, maybe he has a contact that would be willing to make some?

> It definitely works with two controllers. It was designed so that IObit toggles the USART vs the controller.
Oh, didn't knew that. I had a short look at http://byuu.org/snes/usart/design but without schematic it wasn't too obvious how it would work. The $27 teensy++ was also keeping me away there - my PC still has a nice parallel port, so I can transfer data with a 74xxx 8bit latch for around 30 cents :-)

> Nobody's going to be developing SNES games on either of our emulators.
> Aside from d4s' two games, there is no SNES homebrew scene.
Very motivating ;-) there are a few more homebrew games once and then.

>> Then I'll change it to this: 21FCh 8bit character output
> Annoying address decoding if someone did choose to make it on hardware, I'd choose $21c0, but whatever.
21FCh is the offical should-use-this address. If you want to, you can mirror it to 21C0-21FF in hardware and it'll work without problems (unless you have the exertainment bike connected to 21C0-21DFh at same time).

>> Btw. for the NES, I've found this: viewtopic.php?p=82422#p82422
> Seems overly complicated, and could never work on anything but an emulator.
Has it ups and downs. It's very easy to use, and much faster than single-character outputs.

nocash wrote:>> Btw. for the NES, I've found this: viewtopic.php?p=82422#p82422
> Seems overly complicated, and could never work on anything but an emulator.
Has it ups and downs. It's very easy to use, and much faster than single-character outputs.

Yeah, each way has it's perks. I've actually improved on it lately, so that it uses 0 cycles(*) and reads the debug strings from an external file, but this only works with CA65 because the method relies on the debug file that CA65 generates. This maybe doesn't sound like that big of a deal, but the debug strings did end up using a significant amount of space in my previous project so it's nice that they don't fill up the ROM needlessly, even during development.

(*) I had to add an option to output a NOP instruction if the debug output is the very last statement of a conditional block because otherwise it wouldn't be possible for the emulator to distinguish whether the debug output should happen inside the block or after it. [/size]

nocash wrote:> It definitely works with two controllers. It was designed so that IObit toggles the USART vs the controller.
Oh, didn't knew that. I had a short look at http://byuu.org/snes/usart/design but without schematic it wasn't too obvious how it would work. The $27 teensy++ was also keeping me away there - my PC still has a nice parallel port, so I can transfer data with a 74xxx 8bit latch for around 30 cents

The Teensy++ seems like it's just being used as a USB<->USART bridge. If you have some other means to communicate with a USART device, you should be able to use that instead. In any case, I'd suggest an FTDI USB<->USART converter over a Teensy++ in this situation anyway. $15, rather than $27, and a microcontroller is rather overkill for USB-to-serial anyway...

> The Teensy++ seems like it's just being used as a USB<->USART bridge.

Pretty much, yes. It also checks IObit to disable itself when that bit is set (and the ISL pushes the other signal through to the passthru controller port connector.)

There's also a hardware switch on my board to force it off for the few stupid games that clear IObit for no reason.

> I'd suggest an FTDI USB<->USART converter over a Teensy++ in this situation anyway. $15, rather than $27

Tried it: http://byuu.org/snes/uart/hardware

A standard UART is not sufficient, because it's asynchronous. Thanks to SNES DRAM refresh, the best you can get is 57kbps reliably, 115kbps unreliably. And even that is a pain to write the cycle-timed code.

The Teensy is synchronous and watches the clock line at 16MHz, builds a byte, and then sends it to the PC, so you can push it at up to 1Mbit/s. The limit is the SNES' CPU speed, which knocks you down to about 320kbps. That's still 3-6x faster than a simple FTDI cable. And the code to drive it on the SNES side is nice and simple.

The Teensy is a bit overkill, but it's the easiest thing to program and use for USART. It's also not fast enough to handle 2.68MB/s that would be possible with an expansion port connector. Anyway, if you can make a device that is just as fast, functional, synchronous, and allows software IObit+psychical SPDT switching of serial vs controller passthru for less money, please do
I've love to sell these, but nobody's going to pay $100 for one.

So in other words, the Teensy is acting as an SPI slave. Isn't there anything cheaper that can act as an SPI slave and a USB device?

I was talking more along the lines of https://www.sparkfun.com/products/9716? rather than the cable. Supposedly, the FT232R chip is capable of synchronous bit-bang transfer, though you might have to hack that board to access pins not broken out on it in order to change that configuration (or just modify the design and build it from scratch, they provide Eagle files for most of their boards). If you wanted a bit more configuration, you could build around the FT232H which supports a ton of synchronous and asynchronous protocols. http://www.ftdichip.com/Products/ICs/FT232H.htm

tepples, feel like splitting off the cable discussion for nocash? Don't mean to derail his thread.

qwerty, that's all nice and well, but $15 for that FTDI isn't saving anything over $16 for a Teensy. I use the Teensy++ with pins because it doesn't require any soldering (Teensy with pins doesn't have a pin for one of the UART signals I need.)

The bulk of the cost is all the small parts I have to keep including, it's not the Teensy that's a killer.
Teensy++ with pins - $27 (knock it down to $16 if you don't mind soldering a bit.)
Breadboard to hold everything - $10 to $15 (I don't like soldering onto perf board; I really don't want to fab PCBs either)
2x DB9 breakout boards - $16 (I don't like wires sticking out of the board, too easy to knock them out)
Mini-B USB cable - $5
SNES extension cable - $6
7x AWG crimp terminals - $3
Spool of 22 AWG solid core wire - $5 (to be fair, you can make a few boards with one spool)
2x DB9 hoods - $4 plastic; $8 metal (interference isn't a problem, but metal is nice)
2x DB9 solder cups - $4
2x DB9 grommets for hoods - $1
2x ISL84544 digital SPDTs - $5
1x 2-pin SPST - $1
2x resistors - $0.50
1x LED - $1
Now add in shipping because you have to go to at least three places to get all of that, so add on $15.
Now add sales tax to most of that stuff.
And we still haven't considered any kind of enclosure.

It's death by a thousand papercuts.

> http://www.ftdichip.com/Products/ICs/FT232H.htm

It sure would be nice if they made those in DIP form.

The UM232H dev board here looks nice: http://www.mouser.com/new/ftdi/ftdift232h/
But you apparently have to add your own EEPROM to configure it to not be async UART, blech.

The really nice thing about the Teensy too, is that it's synchronous, but on the PC programming side, it acts as though it's your typical RS232 UART. You just ignore the baud rate setting (has no effect), set up your ioctl()'s, open your /dev/ttyUSB0, and start read()'ing and write()'ing to it. The Teensy buffers your data (128-byte buffer), and sends it along in async mode to the PC using its internal UART.

The sync bit-bang of this chip sounds lovely indeed, but it no doubt needs their own custom drivers, which is going to be a hassle for many people.

Yeah, sorry about derailing the thread. Splitting this off to a separate topic would probably be good... Anyway, I've started getting into PCB assembly, and it really does result in a much better end product than breadboarding. It also tends to be cheaper on parts. Ideally, what you'd need is:

FT232H: $4
Various resistors/caps/crystal/etc: $1-2
PCB: $2-$5 (have to order in multiples of 3 or 10, depending where you go)
SNES extension cable: $5
ISL84544CPZ: $2
Mini USB-B port: $0.50

I'll assume you already have a USB cable or three...

Total cost for the entire unit is still under $20

Also, the Retro-Bit SNES extension cables have all 7 connectors, so no need for pulling apart the plug and transplanting +5V into IOBit.

FT232H outside of RS232 async mode requires libftdi, and to get at the full SPI/bit-bang interface, you need a third-party libmpsse. It is not acceptable to require a third-party kernel driver to use this, even if it's much cheaper. That's a serious deal breaker.

> Anyway, I've started getting into PCB assembly, and it really does result in a much better end product than breadboarding.

I'm sure it does. When I find more than a single person wanting to buy one, it may be worth considering.

> Also, the Retro-Bit SNES extension cables have all 7 connectors, so no need for pulling apart the plug and transplanting +5V into IOBit.

No they don't. They lie and say they do, and they have the metal pins on the male end, but if you open the female end ... five wires. I know this very, very well. For a long time, I was opening them up, and moving the Vcc pin to IObit. The wires are also piss poor garbage. I get resistance on at least one line on most cables before I even touch them.

Trust me, I've bought dozens of them. Both the old and new style packaging, as well as generic ones with no boxes in bulk. I've bought probably 30 of the things. Still don't believe me? This was my last attempt at wiring one of those pieces of shit into a DB9 cup:



Anyway, it's easy to make a 7-pin. Only problem is I can't find a 24-28AWG crimp tool that's affordable, so I just solder 22AWG stranded wire onto them. I know you're not supposed to do that, but fuck it, it works.



And it looks awesome.