NES to USB Keyboard interface?

[Pokun]

Pause is not special on USB as it uses an entirely different protocol.

[rainwarrior]

Pause is not special on USB as it uses an entirely different protocol.

What are we comparing to? Are you using a PS/2 keyboard?

[Pokun]

Yes a PS/2 keyboard as I said earlier.

[bitcores]

Yes, I thought that was the plan all along, or I think at least it was mentioned in this thread way back.

Since the Hori Track connects to the 15P expansion port it should be D1. The wiki doesn't say if it's input port 0 ($4016) or 1 ($4017) though. Hopefully it's port 0 which the keyboard doesn't use.
Though since it seems to work like a normal expansion controller with extra reports, I guess it needs the strobe which is D0 of the output port and which IS used by the keyboard to reset to first row.

Seeing it has Start and Select buttons, I am going to assume its normal usage will be as the player 1 controller ($4016.1). Obviously, it was never intended to be used together with the Family Basic Keyboard, but it might be nice to have it available.
I will need to add /OE1 to my interface, strobing D0 (OUT0) would tell both "devices" to be ready to output data, but the keyboard advances on the toggling of D1 (OUT1) while the Hori Track will advance on the toggling of /OE1.
So if you were to make a program uses both of them you would strobe D0 and then read three bytes from $4016 followed by the Family Basic Keyboard reading on $4017, or vice versa.

I am thinking of implementing $4016.1 and $4017.0 (for subor mouse) on the same pin on the Pico on my interface, using a jumper (or switch, implementers discretion) to select which line (or none) is connected. RF/Twin Famicom users would just have to disconnect their player two controller internally if they want to have subor mouse functionality.

[Pokun]

Oh I see, so it is possible to have the cake and eat it too, that's great!

I guess using that method with /OE wouldn't work with the existing games though, so it might be nice if the interface also allowed just connecting a mouse/trackball and make it work like the real Hori Track as well so that the existing Hori Track games would work with it.

[bitcores]

I'm still a noob so perhaps I'm being confusing with my use of terminology.

What I was trying to say was that I should be able to emulate the HoriTrack correctly, so that it will work in games as the player 1 controller, so long as it's using $4016.1. I will need to get a compatible game for testing, though (luckily I recently restored a Twin Famicom I can use).

It wouldn't interfere directly with the Family Basic emulation because when you go to read your connected devices you strobe $4016 anyway. It tells the controllers to read their button states and the Family Basic keyboard to reset to the start row. The method of advancing the output of the HoriTrack and the Family Basic keyboard is different, so you can read them individually without them interfering with each other.
The only thing is that the Family Basic emulation would interfere with the player 2 controller (if you wanted to emulate two HoriTrack controllers, that could be done with major software changes).

Seeing the console never supported having the HoriTrack and Family Basic keyboard connected at the same time (perhaps if the US release happened, the AV Famicoms could have done it) maybe emulating both at once would be a useless feature anyway.

[Pokun]

OK I was thinking the strobing would be a problem but as you say it isn't, all controllers are using it as a reset after all.
Standard controllers and Hori Track are both clocked by simply reading $4016/$4017 which is using the CLK pins while the keyboard uses the OUT1 pin (write to $4016.1) to advance a row when toggled.
But I'm not sure what /OE is for.


Yeah Hori Track is most likely read from $4016.1 since it is supposed to work like a standard extension controller.
It might be possible to check Putt Putt Golf (PAC-PPG) for its Hori Track usage to confirm.


I don't think it's a useless feature. IIRC this whole project was 1) for adding a new keyboard and mouse interface for the Famicom for homebrew developers with full support for PS/2 & USB keyboards/mice and 2) for working as an adapter for PS/2 & USB keyboard/mice to emulate the existing keyboard and mouse interfaces (Family BASIC keyboard, Hori Track and Famiclone stuff).

Even people with a real Family BASIC keyboard and Hori Track can play homebrew that uses both using a custom adapter for daisy chaining them both to the expansion port (Neo Geo extension cables are useful for this).
I only have the keyboard but maybe I'll pick up the trackball as well some day, they don't seem to be very expensive.

[bitcores]

But I'm not sure what /OE is for.

/OE is what the CLK is called on the controller port side. Seeing it goes through the inverters it is only visible to the controllers when you read from $4016/$4017, which is probably why it was given a different name.

[Pokun]

Oh I see, I think maybe they have changed the name since I last looked at it, I don't remember seeing it before.

[lidnariq]

It's not inverted.

It's an active-low signal when it leaves the CPU, and it's an active-low signal when it arrives at the controllers, and on the NES it's the exact same signal on both sides with no modulation.

On the Famicom specifically, there's some shenanigans where /OE1(or /OE2) and M2 go through a 40H368, but that just changes how long it's asserted. (On the NES, /OE1 is low for the full 560ns and is high the rest of the time. On the Famicom, the controller sees a weak pullup most of the time, then it's pulled high strongly during φ1 for 140-210ns depending on CPU revision, and then it's pulled low strongly during M2 for the remaining 350-420ns, and then it floats high.

Visually:

Code: Select all

NES ¯¯¯¯¯¯________¯¯¯¯¯¯
HVC ~~~~~~¯¯¯_____~~~~~~

The only relevance of this is that on the NES, DMA-triggered bit deletions (or misguided use of RMW instructions) will assert the signal for multiple CPU clocks without a glitch. On the Famicom, each CPU clock will cause an additional bit deletion.

[bitcores]

Visually:

Code: Select all

NES ¯¯¯¯¯¯________¯¯¯¯¯¯
HVC ~~~~~~¯¯¯_____~~~~~~

I've been testing entirely on Famicom and didn't even consider that the timing on the OE line might be different on the NES.
I think that shouldn't affect my interface, because it's looking for the return to high for pushing the next bit onto the output, but I'm going to have to keep this in mind.

Regarding the inverted signals, I think I am confusing people due to mainly looking at this page https://www.nesdev.org/wiki/Expansion_port (because I am always dealing with the Expansion port) and the /OE pins there are NOT the /OE pins on the CPU in https://www.nesdev.org/wiki/CPU_pinout.

[lidnariq]

Regarding the inverted signals, I think I am confusing people due to mainly looking at this page https://www.nesdev.org/wiki/Expansion_port (because I am always dealing with the Expansion port) and the /OE pins there are NOT the /OE pins on the CPU in https://www.nesdev.org/wiki/CPU_pinout.

Yes they are? Well, on the NES anyway. Same caveat as in my previous post.

[bitcores]

Regarding the inverted signals, I think I am confusing people due to mainly looking at this page https://www.nesdev.org/wiki/Expansion_port (because I am always dealing with the Expansion port) and the /OE pins there are NOT the /OE pins on the CPU in https://www.nesdev.org/wiki/CPU_pinout.

Yes they are? Well, on the NES anyway. Same caveat as in my previous post.

OK, I think I understand the difference between the HVC and NES now.

On the NES the /OE pins connect to both the '368 and the controller ports, while on the HVC the /OE pins only connect to the '368 which the M2 to passes through to the controller ports.
We can wrap up this discussion now. Suffice to say, Family Basic Keyboard and HoriTrack should work together.

[bitcores]

I haven't done much in the way of code lately, but I have moved away from the breadboard and built a prototype.

DSC_2212.JPG

The DSub-15 VGA connector makes a good connector for Famicom expansion port as it is the same number of pins so you can map them one-to-one. For controller port (NES/AV Famicom) keyboard/mouse host only use, maybe a 6 or 8 pin DIN would be nice.
A full feature PCB would need to be a bit bigger to fit the VGA connector and PS/2 connectors for direct input. K/M host only with a Pico Zero wouldn't be much bigger than a full size Pico.
I think I will put the OUT0-2 lines on voltage dividers later for Famiclone resilience.

[bitcores]

I was reading up on the subor mouse in order to get the subor keyboard and mouse support implemented and I came across this information from Nocash's documentation http://problemkaputt.de/everynes.htm#co ... llandmouse

Namely, Subor is doing the keyboard reading AFTER and ONLY AFTER single-byte-mouse reads (in case of multi-byte-mouse reads, it's completely omitting keyboard reading in that frame) (though unknown if that kind of handling is really required).

I was operating under the assumption that, similarly as to discussed about concurrent Family Basic Keyboard and Hori Track input, reading from both devices could be done concurrently (they don't conflict on the Data bus). The example of how to read the mouse data is interesting, though.

Code: Select all

Reading a mouse byte is done as so:

  [4016h]=01h
  wait 28 clks (14 NOPs)
  [4016h]=06h
  read 8bits from [4017h].R.Bit0 (MSB first) (bits are NOT inverted!)

Because you write 06h to $4016 at the end of the strobe, this suggests to me that the 01h write is disabling the keyboard (or the keyboard is assumed to already be disabled), if the subor keyboard works in that manner (which it looks like it does in the Mesen implementation at least), and then enabling it after. What I don't understand is why this is done.
What comes to mind is the possibility that, unlike the Family Basic which will report the momentary state of the keys as you read $4017, the subor keyboard buffers the states like a controller when you strobe it, though this is not the way Mesen is emulating it.

My assumption from the statement "(though unknown if that kind of handling is really required)" is that this method of reading the mouse and keyboard data was determined from examining the some software that utilized both, and may not even be the best way of doing it. In fact, determining whether to read the keyboard only after reading the first byte of the mouse and determining it is a single-byte-report could result in missed keystrokes in rare cases.
The way I was thinking to handle them was to strobe both with [4016h]=05h followed by [4016h]=04h, the same way you would do Family Basic Keyboard and seems to work just fine with the subor emulation in Mesen. Followed by reading [4017h], which would read the current keyboard column,row on D1-4 and the first bit of the mouse on D0, as well as advancing the mouse output. Then you would write [4016h]=06h to advance the keyboard output and read [4017h] again.
Once you have the first byte of the mouse output, you can determine whether to keep or ignore the following data from D0 (some software seems to just read three bytes worth regardless) and you just keep alternating [4016h]=04h/06h until you finish the keyboard data.
But there could be a flaw in this that I am missing.

One caveat is that it seems the subor mouse is not limited to Controller Port 2, some software expects it in Port 1 which isn't possible through the Famicom expansion port alone (the NES expansion port could be made to work, as could an AV Famicom with two connectors).

--edit--
Woops, I missed this line from the nesdev wiki on the subor mouse.

Otherwise, a 3-byte response is sent. In this case, the strobe bit must be toggled 3 times in a row to read the entire response (e.g read $4017 8 times, toggle strobe bit, read 8 more times, etc.)

This would get in the way of reading the keyboard data in concert with the mouse data, unless the keyboard ignores the strobe bit while it is disabled. Though I suppose even if it does you could advance the keyboard row,column 8 times after the second byte strobe, and then 16 times after the third byte strobe, then continue reading the data from [4017h].