Hi!

I'm currently developing a NES<->PC transfer cable. (to PC parallel port)
Idea came from Memblers, not from me.

PC to NES is very easy using parallel port databits, but NES to PC communicating seems like tricky thing to do, driving the P/S (strobing)
line to 1 to 0 causes a clock pulse generator to reset, so CLOCK and P/S syncronous data transfer is impossible.

Could it be good idea to create a dataexchange like in N64 controller?

Zapper ports would be nice, but i believe that they are for input only, can anyone confirm this?

- Sepi

Is this the N64 controller interface you mentioned?
(warning: site has MIDI music. annoying!)
http://home.t-online.de/home/stephan.hans/n64.htm

Maybe it's significantly different than the NES, but I dunno.

From what I can tell, there might be 2 totally different ways to do this. Either using the controller port, or using the expansion port.

AFAIK, the controller is input only. I know the Zapper sends info to the NES (white color detected or not, trigger pressed or not), but doesn't receive anything back. As I had mentioned to Sepi, I have no idea how data could be sent through this. (maybe by timing the strobes? "fast" strobe is 1, while a "slow" strobe is 0? I'm not sure how practical that is, on the PC software side).

The expansion port seems to have I/O features, but of course it's not documented fully because nothing ever used it. (well, there were at least 2 modems developed seperately, but they went unreleased) But the expansion port might be worth considering, if it could make the cable easier to build.

Hell, people make atari carts and such, I imagine an expansion port mini-cartridge could be made. It's an understatement to say that PCB design a bit out of my league, though. :)

But I'm hoping this could be something that everyone could benefit from. I'd be willing to assemble them myself, if it's not too difficult. If and when the vgwiz Maxicart becomes available, something like this would be just too cool. Maybe the transfer rate wouldn't be too impressive, but with something like this I imagine the NES could have access to things like the PC's disk drives, keyboard, MIDI, - pretty much anything the PC's host software is capable of accessing.

Big Time, you made the FDS loader (a marvel of NES engineering IMHO :) This is probably totally different, but do you have any ideas or advice on how to best accomplish this?

If you use the expansion port on the bottom of the NES, you get a total of 3 output bits and 5 input bits - this would allow using one bit as a "clock" signal in either direction, giving you 4 bits per read and 2 bits per write. If you used both $4016 and $4017 for reading, you'd get a total of 10 bits to read from, which would make it easy enough to receive an entire byte at a time

--
Quietust
P.S. If you don't get this note, let me know and I'll write you another.

I did some reseach to P/S signal, it seems like the NES can drive the P/S line to 1 to 0 state in about 5 us.

According the M.Fayzullins nes.doc strobing can be kept in hi or low state as long as necessary, so it would be good for N64 controller style data exchange.

But realized that there is also easier way to accomplish to NES to PC data exchange, P/S line is too fast for PC parallel port, so we would need to acknowledge it, Zapper port is ideal for this job! all we need to do is to simply ground the pin. 7 from NES, this would acknowledge NES to transmit next bit. Only drawback is that mutilating Zapper and is necassary.

This way the data transmission could be quite fast i think, it's pretty much up to the host application.

Let's assume that time to read and acknowledge the P/S state takes about 1ms in total, we would get a transfer rate of 125bytes / 1 second.

I actually don't know has fast PC can read parallel port inputs, but i bet that it's much faster than 1ms. How fast the communication would need to be anyway?

- Sepi

125 bytes/sec sounds decent, that's about 2 bytes per frame and I believe that'd be just over a minute to transfer 8KB. That will be good enough for uploading from the NES. For downloading to the NES, faster would be better. But I imagine that more often small amounts would be transfered. So 125 bytes/sec is acceptable enough for that too, IMHO.

Ok, let me see if I understand this easier method. I probably have something wrong, so let me know if I do.

For NES to PC communication, the NES would set the strobe to 0 or 1, and this would be the data. The PC would recieve it and change the state of a zapper port to acknowledge. The NES would wait until it changed, then go back to the first step.

For PC to NES communication, the PC would put the bit somewhere (controller or zapper line?), and the NES would receive the bit and change the state of the strobe line to acknowledge. The PC waits for that, then goes back to the first step.

It sounds almost too easy. Is this abuse of the strobe line or what? :P

Yes, that is exactly what i was proposing! everything is pretty much like you said.

In PC to NES communication, PC would use zapper port to send data, and then NES would acknowledge it by using controller strobe.

In PC to NES communication we could use also a faster method, using controller databits to send data, but in this case we would probably have to leave away the acknowledgement.

I think that PC to NES communication does not even need acknowledgement, since i have already used a keyboard and mouse as a input device in NES games!

I checked with scope how offen Super Mario Bros reads the controller databits, it occurs in 100us intervals, but i think that especially desiged "Nes operating system" could do this task much faster!

Unfortunately i have also a chaos theory:
since P/S line resets the clock pulse genetator, it may be possible that NES does not respond to zapper either! there is only two ways to ensure this,

1. Hacking a zapper only NES game. (does such games even exist!!??)
2. Try this transfer cable in practice!

just like Mr.Murphy said:
"If something can go wrong, it will go wrong!"

- Sepi

In reply to:

---

Hacking a zapper only NES game. (does such games even exist!!??)

---

is't duck hunt zapper only

No, in duck hunt you can select game type in title screen with controller 1, and move the targets in the game with directional pad.

I have learned that from from nestech.doc that each reading $4016 makes the
clock out line to perform a new rising edge, this is however my own assumption i do not have any facts to support this theory.

I'll have check if my NES schematics could provide some answers, since ROM hacking bit out of my league. (Yes, i'm AM a newbie in NES programming)

- Sepi

'Barker Bill's Trick Shooting' and 'To the Earth' are a couple games that seem to only support the zapper. (on the title screen at least, pressing buttons on the controller does nothing)

I think those 2 carts were only released in the US. I could dissassemble the zapper-reading code, if it will be helpful.

Here's some already existing dissassemblies (nice ones too, it's possible they can be re-assembled):

Wild Gunman, but it uses the controller on the title screen
http://www.stud.ntnu.no/~kenth/nesrev/lib/htm/WildGunman.htm

Hogan's Alley (same as above)
http://www.stud.ntnu.no/~kenth/nesrev/lib/htm/HogansAlley.htm

Excite Bike. You know the save/load option in that game? It was made for the Famicom tape drive. It uses the heck out of $4016, probably going through the expansion port, but maybe it's interesting anyways.
http://www.stud.ntnu.no/~kenth/nesrev/lib/htm/ExciteBike.htm

Yes, it would be helpful to know that are the joystick polling routines present
in the games. If the polling request is somehow related to trigger/sprite
detection, then we have to consider the use of the expansion port.

- Sepi

The Zappers are read the same way as the controllers. Set the strobe to 1, then zero, then read the data on bit at a time.

Barker Bill's trick shooting uses Nintendo's kinda 'standard' controller reading routine (getting from both $4016 and $4017, even, though I doubt they are both used in this game)

To the Earth seems to work more like a zapper-only game, it reads $4016 3 times (trashing the results) before saving any of the data that was read.

Something I hadn't considered that might complicate things a bit, is that the strobe is shared for both controller ports. Maybe we can make it handshake somehow, so the PC software can know the difference between controller reads and communication attempts.

It looks like we'll need someone with a devcart to test this stuff out. I don't have one, though, and it seems the wait for the Maxicart will be a little while longer..

The expansion port would be kinda nice to use, though. But a downside is that newest Nintendos (like the top-loader), and probably all clone systems don't have it.

Does anyone have a rough idea of how much it might cost to make little cartridge-type boards that would connect to it, BTW? I have no idea.

Maybe a Nintendo would also need to sit upside down to hold the expansion cart. But I suppose that shouldn't be anything to worry about. (just write good enough software so the user doesn't want to change carts, heheh)

This is a major bummer...

Handshaking is probably the best change for NES to PC data exchange.
ATMEL microcontrollers are very handy for this purpose.
What do you think? except from Exp.port, i can't see any other way to
accomplish this.

my previous "Clock pulse reset" theory is false!

I traced with oscilloscope the P/L and CLOCK line presense in various games,
the controller communicating appeared to be exactly the same, until i found
one exception, this exceptional game was Metroid.

In metroid (at start screen) controller is polled and then readed and then
polled again... But when this second controller polling occurs, the controller
reading sequence is not present.

This proves that my theory was incorrect.

I'm sorry that my incompetence has caused so much trouble...
Anyways, now the NES to PC data exchange can be easily accomplished!

Perhaps we could investingate the Metroid ROM to get confirmation for this?
There is great change that i'm wrong again, heh!

There's a Metroid dissassembly here:
http://www.stud.ntnu.no/~kenth/metroid/metroid.asm
Look up 'ReadJoyPads' in there to see it. It strobes before reading each controller (which is unnecessary, actually), so you shouldn't see the second read sequence unless you're monitoring both controllers.

I'm pretty sure the NES can read and strobe the controller(s) pretty fast. I saw this happen in Defender of the Crown (and I double-checked just now), once you get past the title screen (on the screen where it shows some text for the story) it sits in a loop strobing and reading both joysticks until a button is pressed. No delay or anything, other than the code in the loop itself.

Most programs poll the controllers in the NMI routine, in that case it would be happening at a steady rate (60 or 50 times/sec), coinciding with the refresh rate (and the code's main loop).

Also, there might be some way to do handshaking in software, right? I envision having a controller and the NES to PC cable plugged in at the same time. Ideally, the communication will be transparent to the user. So the PC-side software would be seeing the steady strobe intended for the controller, as well as attempts to initiate communication.

The difference is when the NES code reads the controller it'll only strobe once (then wait another frame), and when doing a communication attempt it would stobe, wait for acknowledgement, then use the strobe again. So my idea is to have the PC-side software only treat it as a communication attempt if the strobe changes states twice within 1/60th of a second (1 to 0, then 1 to 0, waiting for acknowlegement, of course). Then the actual communication would begin. If there's only one strobe and a set amount of time passes by, then the PC-side software knows it was only for the controller.

Does anyone know if that sounds feasible? Of course, this does require the software handshaking to be able to finish within 1/60th of a second (or 1/50th for PAL systems).

It does introduce some contraints on the NES software side, but I think we can live with only polling the controller 60 or 50 times a second anyways. :P

Smallest intervals in clock line is about 500ns, and P/L line about 5us, these
intervals are far too fast for LPT port, external logic is a necassary.

Your suggestion about the handshaking sounds good, but... this would complicate things, trapping the communication attempt would require more complex logic, since we cannot do this only with PC software.

We could also create a "byte checking" in the transfer protocoll, what i mean
is that first NES would send a byte, then PC would receive it, and then acknowledge it by sending it back to NES, if the byte received is correct
NES would proceed to sending the next byte. What do you think about this?

I'm still trying to stay away from microcontrollers and excessive amount of hardware, NES power supply reserve is pretty limited (less than 20mA)

There are also limitations in LPT port, we have only 5 inputs ports, so we probably have to split a byte in two parts, but i belive that this will not constitute a problem.

What do you think about all this? i think that this project has been far more difficult than first thought, but not impossible.

P.S
By the way, if NES blocks the reading attemps from $4016 when P/L is high by hardware/software, all this won't work either...

'byte checking' sounds like the safest way to do it.

A faster (but possibly less reliable) way would be to use a parity bit for each byte (I think that's what it's called, I'm not sure. Where you send an extra 1 or 0 depending on the recieved byte having an even or odd number of 1's). That could be combined further with something like an 8-bit checksum for every X number of bytes. (X could be a small number if errors are likely)

In a best-case scenario it would mean less redundant data and more speed. But if we need to plan for the worst, byte checking might be the way to go.

Does the protocol depend on the hardware? Maybe they're complementary?

This does seem pretty difficult. Looking for a simple solution to a not-so-simple problem, heheh. I'm glad you're helping me make some sense of this. :)

About $4016, in Excitebike I see this bizarre sequence. It appears to be the 'loading' code:
(it starts at LC639)

LC62D:
LDA #$05
STA $4016
PHA
PLA
PHA
PLA
PHA
PLA
RTS

LC639:
JSR LC62D
LDA $4016
AND #$02
BEQ LC639
LC643:
JSR LC62D
LDA $4016
AND #$02
BNE LC643
RTS

It sets the strobe, then reads $4016, so we might be safe. The accessory using this was only released on the Famicom (schematics are on this site, if it helps any), but the NES version of Excitebike is identical to the FC version, anyways.

I hope Nintendo didn't give as a save/load option that they knew was doomed to fail on the NES, heheh.

Heh, that code does have an amusing way of delaying, or whatever it's doing.

I have made a premilinary schematic for the transfer cable, check it out.
wwwk.heltech.edu.hel.fi/koti/sepi/nes/ltp2nes.gif
wwwk.heltech.edu.hel.fi/koti/sepi/nes/transnes.txt

Parity bit can be used in PC to NES connection, this actually depends
more from software.

In case of NES to PC connection, we do not have that many ports available,
at least in the desing that i have been working on, so byte checking in this
case is probably our only shot.

Downside in the current desing is that PC or NES does not react if received byte is incorrect, so you must manually erase the incorrect bytes.

By the way, how complex cartridge back-up units are? i mean, if we could fit this device inside GameGenie unit, would it be possible to read ROMs from the the cart and transfer them to PC? i know this sounds kinda crazy...

Cool.

The first link is broken, here's the fix (a lucky guess)
http://wwwk.heltech.edu.hel.fi/koti/sepi/nes/lpt2nes.gif

To backup a cartridge, we'd probably need to have our own code running while the cart is plugged in. Copynes did this by having an internal BIOS ROM that was loaded into the expansion area ($4018-$5FFF), and it had to take over the CPU's reset vector.

I wonder if carts can be safely switched while the power is on? (the lockout chip might need to be disabled or something) That way the first cart could load code into the NES's internal RAM and run from there, then you'd swap carts and start uploading. This method sounds downright evil, though. :)

Most carts have been dumped already. But it would be kinda funny if it could do that.

BTW, 'desing' should be spelled design. That's ok though, I don't know myself if spelled should be spelled as spelt or what. :P

Oh, sorry about the bad link!

was the desciption file accurate enough? My english isn't always that good,
so comments are welcome!

Premilinary test can be done with any NES game, devcart is not necassary,
this way you'll only receive nibble of zero's, but i guess that's just fine
for a beta test.

All we need now is the maxicart! i can't wait!

news flash! i tested this design, clock pulse counter and shift register seem to be working allright!

i was thinking, perhaps we should support zapper too?

Great. :)

Using the zapper connection might be good, especially if it could mean faster transfers. If it doesn't make it a whole lot more expensive to make, then I say go for it. But I don't really have an idea of how much it might cost anyways. (all those 40xx parts are pretty cheap at least, somewhere around 60 cents on Mouser.com). I imagine the circuitboard itself would be the pricey part.

We should go with whatever gives us the best effeciency and most 'bang for the buck'.

If NES would be in sync. with PC, in theory we could use zapper ports to output
an 8-bit serial data just like controller. Since the situation is not in our
favor, we can only output a single bit. These bits could serve purpose in
PC to NES communication attempt, what do you think?

Zapper sprite detection may have a huge tolerance, for this reason it may
be that it's not very ideal for serial data transmitting.

Zapper trigger/sprite is quite simple to utilize, only one transistor for
each is required to do this. BC547 transistors are quite cheap they should
be around 10 cents, not a reason for bankrupt i think.

PCB would be the best way to build this, but unfortunately not everyone has
equipment for this.

Building this device on experiment circuitboard will is probably the best
choice, they are not too expensive either, around 2 bucks.

I don't have very much experiece from NES asm yet, so i cannot provide
my help in that i'm afraid... do you have ideas for software on NES?
I guess somekind of operating system or terminal program is pretty much
required.

What are your future plans for this project? NSF maybe?

Right, maybe we can use the zapper trigger as an extra data bit from the PC or something?

The nestech doc mentions something about "half-strobing" - if the strobe is 1, then accesses to $4016 are for the expansion port. That info doesn't sound compatible with this design, or is it? I didn't notice that earlier. :|

Do you have access to a game with save/load options? Excitebike, Wrecking Crew, and Mach Rider come to mind. Maybe when it's doing the save/load thing we could see if it's accessing the expansion port, the joystick port, or both.. Then we will know for sure about this strobing thing.

I'm wanting to write a music program. With this, the user could load and save songs, samples, or other things (even code expansions.. like plug-ins). Plus I'm also hoping it would be possible to read some basic form of MIDI data coming form the PC. Or maybe use a keyboard as an input device through the software.

you are right, there is a conflict in the hardware! this method writes to the
expansion port, i bet that the joystick operation is obstructed during this
time.. but as you said, we cannot know this for sure until we try it!

You don't mean battery back-up games? i only have three of them star tropics and zelda1 & 2.

Even though the joystick operation is obstructed during the exp. port
writing, there is however remedy for this problem! Binary counter might be
helpful in this case.

Those 3 games I mentioned (all first-gen games in the "programmable series") used a tape drive connected to a keyboard that plugged into the Famicom expansion port. This hardware wasn't released for the NES though, only the Famicom.

The expansion port is different from the NES expansion port, you can see it here (it must be the one labeled P2).
http://nesdev.parodius.com/Ntd_8bit.jpg

It looks like there are a lot of controllers available for the Famicom that plugged into it's expansion port. From that, I'd presume that the Famicom accesses the expansion port and the controller with the same code (who'd want a controller that only works with a few games?). I'm confused. This is some weird stuff. :)

Heheh, I just stumbled across this on google:
http://www.gamersgraveyard.com/repository/snes/peripherals/sfc_modem.html

An SNES modem that goes through the controller port. Nifty.

New schematic is ready!

I corrected the circuit, counter and shift register are history
and they have been replaced with binary counter and RS flip-flop.

Due the changes in schematic, transfer protocol is different from the
previous version, but actually i think it's easier and probably faster too!

http://wwwk.heltech.edu.hel.fi/koti/sepi/nes/lpt2nes.gif
http://wwwk.heltech.edu.hel.fi/koti/sepi/nes/transnes.txt

In nutshell, the transfer is made by reading X times from $4016 (X can be 0-7)
when transfer is complete, poll the controllers to acknowledge PC that data is
ready to reading.

When reading is completed, you must reset the transfer hardware to receive
next nibble. This is done by setting /STROBE to hi-state then back to
low-state, just like polling NES controllers.

How does this sound? i belive that this circuit is no longer in conflict
with NES hardware/software, since the NES strobe is never in hi-state
during the reading sequence.

Nice work. :)

It took me a moment, but I see how it works now.

Reading the controller increments the counter, and strobing it from 1 to 0 puts the counter value on the PC port's data register. It sounds simple enough to work!

If X can be 0-7, then we're working with 3 bits. In that case we'd have a 3-step process for sending a byte, with one extra bit in the 3rd transfer that we could use a parity bit for the byte.

I'll write some NES code to work with this shortly. And I'll try to figure out a handshaking procedure that won't conflict with any NES accessories or some unpredictable conditions.

I figure the logical thing to do is use the interface with the 2nd port on the NES. The only difference is that the reads will go to $4017. This thing should work on any NES, Famicom, and probably even SNES port. (SNES also has the same registers at $4016 and $4017)

Ok, here's some partially-ready code, from how I understand it works.
http://mywebpages.comcast.net/memblers/nes2pc.asm

The handshaking still needs to be worked out. I think we can do a pretty thorough handshake before starting the transfer, then some smaller (faster) ones before sending each segment of bits. How does that sound?

Sorry there was something heretic in my previous message!
X can be anything from 0 to 15, not 0 to 7, so we can transfer 4 bits per
transfer.

Actually all this depends more from NES software, you can do it also with
parity bit checking if you want, but i think that byte checking is more
reliable!

there was some minor glitches in the circuit, now i have corrected them.

There is some minor changes in the reset sequence too, counter must be resetted
with /AUTOFEED and RS flip-flop with /STROBE.

Sorry, i had an slight misundestanding in my previos message!
/AUTOFEED is NOT required in the new version in any shape or form.

Sorry about the inconvenience.

Cool. No problem with the code BTW, I can fix that very easily.

There's so many different ways to do it, I suppose we should go with the safest way for now. I'll make it check every nibble as it goes along, then check the completed byte.

I have tested the existing circuit, not in NES but with external clock
(slower) and manual strobing, everything seems to working correctly.

KHorton's NES Cart file confirms that clock pulses can be controlled by
software. Basicly this means that there is no way that this circuit can
fail to operate in practice.

The existing circuit still needs to be updated, zapper ports are
not utilized yet, and PCB will be available too shortly.