Sold off a bunch of retro stuff to pay bills :/ , but at least I still have a place to live 
Got some work too, finally. My health has recovered, though stress is still there due to unknown length of job/work. Livin’ day to day, basically. C’est la vie, such as the cliche goes.
Some info PCE related (why not, this is a PCE dev blog after all). I/O – gamepad port. The SGX has a wonderful I/O port made in additional to the PCE’s port. They’re shared, until something is detected on the SGX front port – then gamepad is disabled. But that’s not what this post is about, although the SGX has the nice luxury of quite a few input and output lines. This is about the original PCE’s input and output lines. To be blunt, 2 output lines and 4 input lines. The 4 input lines, not so bad actually. It’s the output lines that cripple the port IMO. But there’s a saving grace that NEC (or Hudson) in their wisdom, gave us. All the gamepads use a 74×157 stock TTL chip. There’s a specific characteristic about this 2line to 1line switch. When Reset is held, all 4 output pins are driven low (read as 1′s on the CPU side; low =1, high =0). What does this mean? It means you can daisy chain devices on the port. The I/O port itself lacks any /RD or /WE or /CE such lines. So you can’t setup a simple self clocking device every time the port is read. What you have to do instead, is use the output pins to clock any devices manually.
My interests comes directly from wanting to communicate with the PCE. PC is the host, PCE is the device. You send commands/requests to the PCE. The higher level protocol isn’t that important; it can be anything really. It’s the low level communication protocol that’s tricky. With only 2 bits for output, you’re very limited to how you can chain multiple devices to the single port. My situation calls for three things; a comm port (to/from the PC), a keyboard port, a mouse port, and a gamepad port. I don’t plan on using official PCE mouse. I don’t have the money to buy one, plus I have spare MCU’s laying around and plenty of spare PS/2 mice. I’ll make my own converter for that (though I’ll probably replicate the PCE’s official mouse protocol). Same for the PS/2 keyboard reader.
I won’t bother explaining the boring low level protocol details now (some point later, possibly with a video of it working on the real system), but the last key component was how to pass control of the port to the gamepad or TAP. I figured a time slice or window would be the best approach. But one would need to be able to detect when the ‘comm’ device has transitioned control to the gamepad device. And that very method is the Reset line held high for the ’157. It forces all output lines low, so no matter what the pad button states are – it will always be 1111b upon reading it. With the ‘comm’ device, you request a gamepad device time slot – then poll the read port until you get the gamepad ‘ID’ value.
As for the ‘comm’ device itself. For now, I have a ’877a MCU up and running. Though I’ll probably end up using one of the faster 18 series PIC chips. The MCU itself doesn’t directly communicate with the PC. That’s handled via a USB to parallel device (looking at a FTDI 245R currently).
Some background: Looking for ways to communication with a PC; legacy ports seemed too messy. And are being phased out. My main PC lacks a par port, but has a serial port still. I had toyed with the idea of doing a ‘shared file’. I would emulated basica ATA command set via the MCU and make a virtual FAT32 small drive via some SRAM connected to the MCU. Nothing complex, just a MBR, FAT, and a root directory only and a single file. The PC and PCE could both read/write to this file. For interface it to the PC, I would connect the I/O lines of the MCU that emulate the ATA HD device, to a ATA to USB external adapter. It’s practical, no comm ports or drivers needed, etc. The main thing with this ‘comm’ device (in whatever conceivement), was so that it could be replicatable via other people. I.e. I wanted an environment on the PCE that had access to a keyboard, mouse, gamepad, and PC. First soft to use this environment would be music related (tracker or such), but I had other plans as well. The other reason why I had thought about the shared file approach and emulating an ATA device, is that I was looking into ATA PI protocol. Basically SCSI packets over ATA interface. It’s what CD/DVD/etc drives use. It’s not exactly SCSI, but it’s very close (for CD drives, that is). PCE also uses a SCSI packet type interface to communicate to the CD rom drive, for the CD addon. I guess you can see where I was going with this. It wouldn’t be too difficult to get a MCU to translate on the fly the SCSI type interface and status bits of the original NEC CD MCU controller, to a more modern CD drive (or even emulated drive Hudson CD dev system was just this; an HD emulating a CD drive tracks). Of course, this wouldn’t be a complete solo project of my own. If I were to tackle that in the future, I’d definitely would need some assistance (on both sides of the fence). But that’s a topic for another day.
First things first. For now, I don’t have the 245R. So for the ‘comm’, I’ll just have the PCE access it in different ways (read out data, write in data (eeprom), etc), and get the pass through code working. Current PCE gamepad code put about ~1500ns delays from selecting the port, to reading the port. That’s too fast for the MCU to do it internally as it is now, which isn’t using any external chips. Internally,in pass through ‘window’ mode – the MCU just copies one port to another (two one for reads, one for writes). @ 16mhz, it takes 2000ns for one complete passing of the port data. It’s slow, but I’d be writing my own driver anyway. The 18 series has faster speeds and better instruction set. So I could get it down to less than 800ns most likely, and have it run in stealth mode on power up/on by default- so you could leave the comm device connected if you wanted to play regular games without having to remove it. The less chips on the port, the better. I don’t know how much power I can draw from the I/O 5v line and so I rather the total number of ICs to a minimum.
