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

A little less clever, I think? The keyboard's data line itself can pull /IRQ low ... and extra hardware appears to keep it low until the keyboard has clocked something in 9 times (i.e. ignoring the parity bit). So /IRQ appears to be asserted for the entire transmission. At 11 bits and 30-50µs per bit, each keyboard transmission will take 330-550µs, or roughly 600-1000 CPU cycles. The hardware assist does deserialize the bits—reads from (mask $F001) $5001 and $5000 return the most recent 4 bits clocked in or the 4 bits before that, respectively.

Quote:

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.

Yeah? Might be able to just connect Kbd Clock to /IRQ ... I don't think the lack of acknowledgement will be a major flaw?

NMI, other IRQs, and OAMDMA will interfere with keyboard receipt, but that's basically guaranteed of any solution that doesn't buffer the entire stream.

Quote:

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

Really depends on whether you consider that an acceptable cost, of course.

I'll note that in the NES expansion port, 11 of the 15 signals of the Famicom expansion port (including /IRQ; notably NOT including OUT0,1,or 2) are on the same side as the Audio In pin. Seems like it would be practical to extend INL's audio mixing board.

I'll note that in the NES expansion port, 11 of the 15 signals of the Famicom expansion port (including /IRQ; notably NOT including OUT0,1,or 2) are on the same side as the Audio In pin. Seems like it would be practical to extend INL's audio mixing board.

Part of the issue is that it's also challenging to use my method to mate with two pins which are directly next to each other. It may be possible to make it work by staggering even and odd pins at different heights so neighboring pins don't short out with each other where the contact solders to the board. It wouldn't be too hard to expand my method to having a board on each side of the EXP port connector if one were already going try and mate with all 11 or more pins. I just saw that as beyond the scope when designing the board.

My method could probably work with all 48 pins, I'm just not sure it's the best solution when mating with more than a few pins. It's still not compatible with toploaders or clones. As more an more high end clones become popular in the market the EXP port starts to become less appealing.

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

So ... КД522 would pull /IRQ low whenever KBD DATA is low ... but that actually gets in a fight with the КР1533ТМ2 which isn't open-collector...

A read from $5002 reset all 8 bits of the shift register to 0 and the 74'74's output to high... I've got to be confusing myself. The inverter should mean that /IRQ is only driven low by the 74'74 9 clocks after the first time KbdClock falls while KbdData is high ... i.e. not including the start bit?

infiniteneslives wrote:

Part of the issue is that it's also challenging to use my method to mate with two pins which are directly next to each other. It may be possible to make it work by staggering even and odd pins at different heights so neighboring pins don't short out with each other where the contact solders to the board. It wouldn't be too hard to expand my method to having a board on each side of the EXP port connector if one were already going try and mate with all 11 or more pins.

I was more thinking of just grabbing +5V, ground, and two random signals on that same side. I don't think there's any point in bothering getting 11 of the 15 famicom expansion port pins and not making the full connector.

A read from $5002 reset all 8 bits of the shift register to 0 and the 74'74's output to high... I've got to be confusing myself. The inverter should mean that /IRQ is only driven low by the 74'74 9 clocks after the first time KbdClock falls while KbdData is high ... i.e. not including the start bit?

This cartridge is compatible only with XT keyboards, which consist of 9 bit transfers (start+8 bits, without parity and stop bit), data valid on falling edge of clock.On XT keyboards start is high and this is what is clocked into 74'74 input after 9 clocks.

This cartridge is compatible only with XT keyboards, which consist of 9 bit transfers (start+8 bits, without parity and stop bit), data valid on falling edge of clock.On XT keyboards start is high and this is what is clocked into 74'74 input after 9 clocks.

Ah-hah. And most pertinently, the idle voltage is low and the start bit is high. So 9 clocks later, the high start bit has been inverted and latched and is now pulling /IRQ low. Got it.

Quote:

Now according to yours thread - Atmega8 + VUSB should be enough to communicate with USB mouse/keyboard as USB host and translate it to more NES friendly protocol.

V-USB is a device-only firmware, not able to be a host.

Honestly, it feels like it "should" be possible to bit-bang a minimal host implementation that can only talk to a keyboard, but... or even to use a micro with actual USB PHY hardware to do the same ... but there's no evidence that anyone has done so.

Honestly, it feels like it "should" be possible to bit-bang a minimal host implementation that can only talk to a keyboard, but... or even to use a micro with actual USB PHY hardware to do the same ... but there's no evidence that anyone has done so.

I think bit-banging is your only option unless the mcu USB phy specifically supports hosting/OTG. Many mcus with USB phy only support device operations I would assume. In my experience with a STM32 mcu which has USB, but lacks OTG, the abstraction that the hardware provides doesn't give you enough control to act as a host.

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

But what would you use a keyboard for, other than a BASIC interpreter? I ask because the PS/2 to controller port adapter implementation by tpw_rules got hung up on making a demonstration app that was a player for Z-machine (Infocom interactive fiction) story files.

Lol, true, I measured two adapters I have (one for PS2 keyboard, one for PS2 mice) and there is direct connection between:PS/2 data -> USB D-PS/2 clock -> USB D+

I have same adapter for PS/2->DB9 and I remember that it worked ONLY with the mouse it was shipped with so not dual PS/2 / DB9 mouse exists. What about PS2 / USB i dont know because all USB keyboards I've tested worked without problems.

I managed to get a ps/2 keyboard interface working via PIC microcontroller, although I still have a few kinks to work out. The biggest issue I'm having is response time. I'm currently holding the keyboard clock line low so all keystrokes are buffered (in the keyboard) until the NES is not reading from the PIC. Then a single keystroke is sent from the keyboard to the PIC and the equivalent family basic key is determined via look-up tables. The PIC then waits for an NES write to the exp_out lines, sends the keystroke to the NES, and the process repeats. With this method, 12 keystrokes takes roughly 6 seconds to fully process.

I think continuously reading, calculating, then buffering keystrokes in the PIC might be faster, but the overall speed will still be bottlenecked by the NES. What are your thoughts? Can anyone think of a way to make this faster?

My best guess is that you're detecting the wrong state from whatever software (Family Basic?) you're testing against as "idle", and the amount of time that the keyboard is allowed to talk is a tiny fraction of real time.

Who is online

Users browsing this forum: No registered users and 2 guests

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