It is currently Fri Nov 24, 2017 5:22 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Aug 14, 2017 4:23 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5842
Location: Canada
I was thinking about keyboard input on the NES, and wondering what a sensible (i.e. relatively easy to build and use) interface for a modern keyboard would look like.


The Family Basic controller just lets you manually poll it to scan the key matrix 4 bits at a time. This seems relatively convenient, though with all of its I/O bits it needs to go through the expansion port.

In the DOS days, if I recall correctly, the interface was getting an interrupt whenever a key was pressed or released, during which you could read a byte of data (scancode) and command key flags (alt,shift etc.). The interrupt is probably not the best thing here, but I think the parsimony of scancode events is good.

I understand that modern USB keyboards are poll based, though. Does it retain a queue of scancodes since last poll that can be read?


So, my question is what the minimal (i.e. easiest to build) USB interface should look like, especially from the NES programming side. Could the NES directly communicate with a USB keyboard, or how much stuff would you need to put in an adapter between it? Is only having the $4016 strobe for upload a big problem? If a simple/direct communication isn't feasible, what does the next best thing look like?

I guess being able to use D1-D4 for each poll like the Family BASIC keyboard would be nice, but require use of the expansion port, though probably even 1 bit serial is fast enough for most purposes?

Also there's a question of how to identify the attached device, though I'd presume USB already has a convenient protocol for this.


Of course, several steps away from this level I could just throw like an Arduino or something at the problem, which seems like a valid solution to me but I was wondering if there's a relatively "simple" or "natural" alternative. My goal here isn't really requesting that someone design me a USB keyboard to NES adapter, I only want to get a rough idea of the possibilities and how complex they are.

What I really want to do is make an NES project that uses a keyboard/mouse in an emulator, but I'd like it to be something that could be built in hardware without too much trouble, if possible.


Oh, and also same question but USB mouse, I guess. (Or combo keyboard + mouse? Does it complicate things a lot if they're 1 device?)


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 4:45 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 245
Location: Poland
One of my previous projects:
https://translate.google.pl/translate?s ... edit-text=


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 4:48 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
No, nothing simple. Cheapest option is definitely going to be to use a microcontroller with USB host.

The slowest USB speed requires being able to alternate the pins at 1.5MHz.

But there's a nontrivial chance that most USB keyboards still can use the PS/2 protocol, which is enough slower that it could be bit-banged by the NES.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 5:56 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5842
Location: Canada
Thanks. "microcontroller" gives me a ballpark of complexity to consider.

I dunno if I'd want to go down the PS/2 route. I think that's becoming "vintage" hardware at this point.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 5:58 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19257
Location: NE Indiana, USA (NTSC)
The trouble with AT protocol (as used by PS/2 keyboards) is that the device expects to drive the clock, which means the MCU needs to be a slave to both the NES and the keyboard. A couple years ago, tpw_rules was working on an MCU-driven adapter that could work in raw PS/2 mode (if a keyboard is connected) or emulate a Super NES Mouse (if a mouse is connected), but life got in the way.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 6:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
rainwarrior wrote:
I think [PS/2 is] becoming "vintage" hardware at this point.
The connector? Absolutely. But most keyboard manufacturers have no reason to rewrite their keyboard firmware since their original port two decades ago to USB. That's the only reason why I suspect you could get away with it.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 9:25 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1925
Location: WhereverIparkIt, USA
lidnariq wrote:
But there's a nontrivial chance that most USB keyboards still can use the PS/2 protocol, which is enough slower that it could be bit-banged by the NES.
What do you mean exactly? Are you saying that perhaps a USB keyboard's D+/- lines could also act as PS/2 CLK/DATA with a wire/passive adapter alone? As in the keyboard might be actively detecting if it's wired to a USB or PS/2 port at power up? That seems crazy to me, but I really have no clue.

I always assumed USB <-> PS/2 adapters always had a tiny mcu inside actively handling the conversion.. But some quick searching shows that may not be the case after all. So USB -> PS/2 conversion can be done passively, but surely the opposite (PS/2 -> USB) requires active conversion..? I would have a hard time imagining that PS/2 support is build into the USB spec, not only would USB hosts need to support it, but hubs too..

So if an USB to PS/2 keyboard adapter is nothing more than wiring USB D- to PS/2 Data, and USB D+ to PS/2 Clock, then presumably most USB keyboards are also PS/2 keyboards they just happen to physically have a USB connector. In that case I agree with lidnariq, it would be much simpler for the NES device to implement PS/2 protocol. You could simply have a USB connector which assumes the keyboard plugged into it supports passive conversion from USB to PS/2.

Quote:
I guess being able to use D1-D4 for each poll like the Family BASIC keyboard would be nice, but require use of the expansion port, though probably even 1 bit serial is fast enough for most purposes?
The other way to have nibble/byte access is have the keyboard accessed via the cartridge port.

Quote:
So, my question is what the minimal (i.e. easiest to build) USB interface should look like, especially from the NES programming side.
Curious what you mean by easiest to build exactly. Do you mean easiest to manufacture, create and develop a hardware and software design, or something built in a DIY fasion by the user themselves? From my biased perspective putting a mcu and glue logic in the cartridge would be the easiest to design and manufacture. But from a hobbyist/DIY perspective it's probably easiest to connect the mcu to the NES controller ports. It's probably best to keep the keyboard peripheral separate from the cartridge hardware. But if I ever pull off my hair brained idea, perhaps putting keyboard controller hardware inside the cartridge itself isn't that costly/wasteful.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 9:47 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
infiniteneslives wrote:
I would have a hard time imagining that PS/2 support is build into the USB spec, not only would USB hosts need to support it, but hubs too..
You're right, it's not.

Quote:
So if an USB to PS/2 keyboard adapter is nothing more than wiring USB D- to PS/2 Data, and USB D+ to PS/2 Clock, then presumably most USB keyboards are also PS/2 keyboards they just happen to physically have a USB connector. In that case I agree with lidnariq, it would be much simpler for the NES device to implement PS/2 protocol. You could simply have a USB connector which assumes the keyboard plugged into it supports passive conversion from USB to PS/2.
That is exactly what I'm saying. There was a time when many mice and keyboards came with passive shape adapters, and the microcontroller inside the device just decided whether to speak PS/2 or USB depending on whether the data lines encountered pulldowns (USB) or pullups (PS/2).

Mice have continued to undergo development, so the nicer ones may well have dropped PS/2 support ... but keyboards are more-or-less unchanged.

This is not to say that active translators don't also exist. (They do). But they're more expensive than having the microcontroller in the keyboard/mouse be "bilingual" in the first place.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 10:17 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5842
Location: Canada
infiniteneslives wrote:
the keyboard might be actively detecting if it's wired to a USB or PS/2 port at power up?

Yes that's what they do.

infiniteneslives wrote:
most USB keyboards are also PS/2 keyboards they just happen to physically have a USB connector.

Probably all early USB keyboards were PS/2 keyboards as well. They generally used to ship with a passive adapter in the box.

I'm sure it's not that hard to find one that still does PS/2, but there are plenty that do not, however. (More than half of the USB keyboards I currently own are actually keyboard and mouse combos, for instance.)

It's a bit different question whether it's "here's something that will work with any modern keyboard" and "this will work if you happen to have a keyboard with a feature that likely wouldn't even be mentioned on the box anymore"... like if it was me trying to build a thing once for my own personal use, sure maybe the PS/2 is good, but if it's supposed to be something easy to use by anybody, no I wouldn't really want them to have to hunt down a PS/2 keyboard.

infiniteneslives wrote:
Curious what you mean by easiest to build exactly. Do you mean easiest to manufacture, create and develop a hardware and software design, or something built in a DIY fasion by the user themselves?

Either/both. I wanted to know the range of possibility here.

infiniteneslives wrote:
But from a hobbyist/DIY perspective it's probably easiest to connect the mcu to the NES controller ports.

That would be my preferred way to do it, for a lot of reasons. One big reason you just skipped is being able to run the software on a PowerPak other other easy to find hardware instead of something that requires a custom board even to work. Reusability, etc. The cartridge is probably the last place I'd want to put it.

The expansion port would maybe be acceptable but even with a plug-in-adapter it's still a (very mild) case mod. Something you can just plug in to the front without altering your NES is the path of least resistance. I don't really see a necessity for using the expansion port here... if it could have helped with extra output or something, but that doesn't seem warranted? I'd rather aim for something more accessible unless there's a significant advantage to doing it another way.


Of course, how it gets built is slightly out of the scope of my goal anyway. I mainly just want to implement something that can talk to a keyboard and/or mouse, has a reasonable protocol on the NES CPU side, and would be easy to build a conforming device for. If the basic complexity level of such a device is a microcontroller, then that's really enough information for me to go on at this point. That puts a lot within easy reach, I think. (...and obviates a need to actually duplicating USB/etc. protocol directly.)

PS/2 is sort of an interesting option, if the NES could interface with it directly enough, but only if it made the hardware significantly easier to acquire and build (i.e. more accessible), and I'm not sure that it would be, at least in the ways that I care about. (If you've got a compelling argument about how easy to make it would be, though, I'd listen.)


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 10:55 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1925
Location: WhereverIparkIt, USA
rainwarrior wrote:
PS/2 is sort of an interesting option, if the NES could interface with it directly enough, but only if it made the hardware significantly easier to acquire and build (i.e. more accessible), and I'm not sure that it would be, at least in the ways that I care about. (If you've got a compelling argument about how easy to make it would be, though, I'd listen.)


The real benefit of targetting PS/2 in terms of the hardware is that it's a simpler and cheaper interface compared to USB. If the user were building the device themselves, you would have the option of targeting a low cost, widely available, 8bit mcu available in DIP packaging with PS/2. An mcu that supports USB host/OTG is another league of mcu. Aside from being more expensive, only comes in fine pitched surface mount packages. A mcu that supports USB host/OTG is also less likely to be 5v tolerant so additional circuitry/components may be needed before connecting to a 5v controller port. So if your talking about users building it themselves, it's more likely for someone to have mcu flashing/soldering tools/skills for a PS/2 design compared to USB. Maybe those aren't the ways you care about though.?

Doesn't sound much like you need to worry too much about USB vs PS/2 at this point though. Creating a interface standard via the controller port that's within reach of both scales of mcu (PS/2 or USB) allows decisions to be made about how to specifically implement the hardware. Maybe there's some open source design available that uses a simple 8bit mcu which users can create themselves, or various people can manufacture, but it's only compatible with PS/2 keyboards. And separately someone else could develop more complex hardware that supports USB or maybe even bluetooth keyboards. If we were to define a standard protocol of transmitting keyboard data over the controller port, then various hardware solutions can design to that standard and the actual protocol of the keyboard is irrelevant.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 11:27 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
Honestly, you could even just bit-bang PS/2 from the Famicom expansion port. Bidirectional communication (e.g. turning on LEDs) requires control of both the clock and data lines,

but...

Since the keyboard controls the clock, it seriously looks like you might be able to get away with just monitoring the clock/data lines and letting the keyboard talk into the void? Here's an old reference I find rather approachable.


Top
 Profile  
 
PostPosted: Mon Aug 14, 2017 11:43 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5842
Location: Canada
infiniteneslives wrote:
So if your talking about users building it themselves, it's more likely for someone to have mcu flashing/soldering tools/skills for a PS/2 design compared to USB.

I think it's more likely for someone to have an Arduino or RPi, which would already come with a USB interface anyway.

I think by the time you're talking about programming a microcontroller directly it's a much more specialized audience, and/or you're talking about production not DIY. So, yeah, if either a PS/2 or USB solution is already involving an MCU than it's more or less a moot point to me.

infiniteneslives wrote:
...the actual protocol of the keyboard is irrelevant.

Yes, it's very flexible if there's an MCU in between. That was really the main question I was asking, whether there's something more low-tech than that, but if it isn't really, then that's all I needed to know.

Like the Famicom BASIC keyboard is wonderfully direct, but obviously they built the keyboard themselves and didn't need to put much stuff between it and the Famicom. I was wondering if there might be some middle ground with a modern keyboard that I was unaware of where you could still leverage the NES' CPU, but I guess not.


Top
 Profile  
 
PostPosted: Tue Aug 15, 2017 12:01 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5842
Location: Canada
lidnariq wrote:
Honestly, you could even just bit-bang PS/2 from the Famicom expansion port. Bidirectional communication (e.g. turning on LEDs) requires control of both the clock and data lines,

but...

Since the keyboard controls the clock, it seriously looks like you might be able to get away with just monitoring the clock/data lines and letting the keyboard talk into the void? Here's an old reference I find rather approachable.

Well, it's interesting anyway. So, assuming you don't need to send any information to it...

It sounds like you could hold the clock low until you're ready to poll, to force the keyboard to buffer input until you're ready, then release it...

At that point the keyboard would start sending bits, but it controls the clock? Could that actually be directly read by the NES CPU? Wouldn't we need some intermediate buffer/latch to capture and hold the bits?


Top
 Profile  
 
PostPosted: Tue Aug 15, 2017 12:20 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6458
Location: UK (temporarily)
Yeah, it would be highly suboptimal; just directly waiting for each individual falling edge from the PS/2 clock pin would take the vast majority of the NES's CPU time. It'll require an awful lot of juggling to have it be anything more complex than just "exclusively paying attention to the keyboard vs doing anything else at all".

It's not quite "absolutely not possible"—once we see a falling edge we have somewhere around 55ish 2A03 cycles before we need to check on it again—but it's rather uncomfortable.

You could add a couple shift registers—the hardware in the cart that Krzysiobal sent in the beginning of the thread has such a hardware assist—but I'm skeptical whether that's a better engineering plan than using a cheap 5V microcontroller.

But the NES already includes the 74'368s on its controller ports, so for just minimal polling ... no extra hardware should be needed.

(edit) OH. Extra hardware to allow the NES to stall the keyboard. Yeah. You would need to add a diode, or a resistor and NPN transistor, or an open-collector buffer or inverter, in order to allow the OUT signal on the controller port to drive the keyboard clock line low but float high the rest of the time.


Top
 Profile  
 
PostPosted: Tue Aug 15, 2017 1:19 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5842
Location: Canada
lidnariq wrote:
You could add a couple shift registers—the hardware in the cart that Krzysiobal sent in the beginning of the thread has such a hardware assist

Ah, so Krzysiobal's cartridge triggers an IRQ each time a byte is finished buffering.

More minimally, the buffer could be done in software? If we just trigger an IRQ on each falling edge of the clock and let the CPU read the data line directly.

Requires the expansion port or cartridge access for the IRQ, but maybe not as bad as polling the clock, and relatively few parts?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group