JohnPCAE

I wonder if you're running into flash latency. Is your game stored in flash? I wonder if you need to first preload it into RAM.

The waits that I'm doing are in nanoseconds, not milliseconds. A single NOP instruction on a Pi Pico running at 133MHz takes about 7.5ns.

Oh yeah, if you're only emulating ROM then you don't need to care about DWS (as long as you're not emulating something with RAM like Chess).

You only need to handle BAR, ADAR, DWS, and DTB. You can treat all others like a NACT. And you don't have to care about SDBD. One thing I do is detect MSYNC pulses and reset my internal variables, including setting my "previous bus state" variable back to NACT. You're doing the right thing with DTB. On a BAR or ADAR, I prefetch the word at that address and on a DTB I put that word on the bus. In fact I handle BAR and ADAR in the same portion of code. Try tweaking your timing: how long you hold the data on the bus for DTB and how long you wait for the address to be stable on BAR and ADAR. Maybe you're timing is marginal.

Or you might not be holding the data on there long enough. When I write to the bus with all 16 bits at a time, I then have to keep the data on the bus for at least 600ns before I set my data pins back to input. Oh, and I do reads and writes on multiple pins simultaneously for speed. In the ACC I do them 8 at a time and in the USB board I do them all 16 at a time. The important thing is to get all 16 data bits on the bus before other chips start looking for them.

I see. It looks like the serial number is a single byte. I can add a routine to TinyUSB to retrieve it and store that as well as the VID and PID.

I'm not suggesting that we would supply calibration data but only that when people calibrated their controllers the VID and PID would be stored along with the calibration data in flash. That way it could be retrieved at a later time by either the same or a different game and matched with the controller. The idea is that if a person has multiple USB controllers of different types it could match the correct calibration data with the correct controller.

Hmm. TinyUSB doesn't yet have a host-mode driver for USB audio devices, so MIDI won't be happening for now. But at least HID devices are working and I've completed putting in code for mass-storage devices, though that's still untested.

I've figured out how to set the LED's on a keyboard and I've added some initial code for mass-storage devices (you can get some basic info like block size and number of blocks). I've also started looking at MIDI device support, but this might be difficult since I don't have any. As for mass-storage devices, dealing with device format (FAT16, FAT32, NTFS, etc.) will be outside the scope of this project. I plan to let the Inty read or write raw data but interpreting the format will be up to Inty software. I'm providing an 8k shared memory area that can be used for anything requiring a buffer (controller calibration, mass storage data, etc.). You access it via a couple of registers: data pointer and data value. Reading or writing to the data value register auto-increments the data pointer.

Shapeways nylon SLS prints are a bright white, so people like me could use a close paint match for the Inty II color anyway. Just a heads-up. As the fit is so tight, it's causing the board to not lay flat and causes it to be a little harder than I'd like to insert a cartridge. I've widened the shell by 12mm to solve this and I'm waiting for the updated knob to arrive tomorrow before I sign off on the change (I want to first know if I need to shift the knob by a millimeter or two). So an updated set of models is coming at some point.

No, I mean run your code FROM RAM. Running it directly from flash might be causing you latency problems. For example, on the Pico my Intellivision bus code runs on core #1, and I designated that code as __time_critical_func, which causes the entire routine to be loaded into RAM at startup: void __time_critical_func(core1_main()){...}

One other tip: run your code out of RAM if possible. I found that running my code from flash on a Raspberry Pi Pico wouldn't work. The problem is that reading a new page from flash introduces latency that was causing me to miss bus cycles.

Also make sure that your cartridge board is wrapping BC1, BC2, and BDIR back to the Master Component like other carts do. This is critical.

You need to support ADAR in addition to BAR. Direct addressing instructions use one and indirect addressing instructions use the other. On BAR and ADAR cycles, the address will not immediately be stable on the bus. When I detect them I first have to wait for about 525ns before I grab the address off the bus.

This is untested, but I've added code to load/save 4k (2k words) of calibration data to the Pi Pico's flash memory. So theoretically a game could read the VID and PID of a controller, load the calibration data, and if there isn't a block for that controller somewhere in the data, let players calibrate their controller and save it to flash (or let them recalibrate whenever they want). The nice thing is that the calibration data would be persistent across sessions and even games. We would all have to agree on a memory layout standard for calibration data though. The memory area is large enough that it could store calibration data for many controllers at once. It's probably enough to store data for as many controllers as any of us could ever own.

That explains why TinyUSB isn't even seeing it mounted. It's not even calling the HID mount callback routine. I think I'll just skip that controller then and move on to diagnosing detecting devices that are already plugged in. It detects a device if you plug it in after the Inty is powered up, but it's not seeing devices that were already plugged in. I could have sworn that was working earlier. I'm also wondering if I can store calibration data in the Pi Pico's flash memory. I don't know if it's feasible but that would mean that calibration could be persistent across game sessions and even from one game to another. Edit...Aha. It's the hub. If it's already plugged into the hub then the software in the Pico gets confused. But if it's already plugged in directly without a hub it works fine. So that's something else to investigate. That might be a TinyUSB issue.

Order #49 is in.

My Logitech Wingman and Microsoft flightstick work (both are also classified as HID joysticks). That only leaves a custom arcade stick I bought a long time ago that's based on an old XBox 360 controller. That doesn't show up at all, so I'll investigate it. It would be cool if it supported original XBox 360 controllers. It's worth pointing out that all USB joysticks require calibration, so any Inty games that support them will have to provide people with a calibration screen. It would be cool if they also saved calibration info to cart storage. One thing I'll look into is supplying the Inty with the USB VID (vendor ID) and PID (product ID) for any controllers to make looking up precalibrated data possible.

A little more progress. I have data from a Microsoft Sidewinder and an N64 controller (using USB adapters) getting to the Inty. Both are classified as USB HID Joysticks (as opposed to HID gamepads which sends different data). So theoretically, anything classified as a HID joystick should work. I have a couple of other controllers I can test tomorrow, one of which is an MS flight stick. I put in code to process data from HID gamepads as well, but I might not have anything to test it.

Making progress. I have mouse and keyboard events making it to the Inty. There's also a keyboard event buffer that is set to 16 events for now. You can connect multiple keyboards and mice if you really want (I allow a maximum of 16 devices). Next I'll look into gamepads.

Correction, I was testing with a USB keypad, not a gamepad. But I do have USB controllers that I plan to eventually test. First I'll work on mouse support, though, as that's easiest.

This project is only in its infancy, but it's happening. What you see here is an experimental board that's talking to the Inty about connected USB devices. So far I only have it telling the Intellivision how many devices are connected, but it's only been 24 hours of work. This is nowhere near the final version of the board's layout, but as you can see it's going to be very simple: only three level-shifter ICs, a power MOSFET, and a Pi Pico (and a few passives for a nice clean power rail). The plan is to support (at the very least) keyboards, mice, and gamepads, and if I'm very lucky, mass-storage devices. It's theoretically possible to also add Wifi with a Pi Pico W, and a real-time clock using spare I2C pins. In this picture, it's not my Logitech mouse that's plugged in, but a 4-port USB hub (yes, you can use a hub). And I was testing with a USB gamepad. I've already tested the software with an earlier standalone unit so I already know it can handle a mouse and keyboard plugged in at the same time. In terms of the Inty's memory map, it takes over addresses $007C and $007D, and like the ACC uses a register array. $007C is where you set the register index and $007D is where you read or write the register value. Also like the ACC, one of the registers is a read-only signature register where a magic value tells you if the unit is plugged in.

I just wanted to point out that I still have two spare ACC units here gathering dust, and I've been slowly building a third one. The minimum order from JLCPCB is five circuit boards, so I have enough to build one for myself and up to four spares. Would any developers be interested in one?

Off-the-wall idea. How hard would it be to write a translator that can translate 6502 assembly to CP1600? It would be really awesome if we could port KC basic to the ACC.

One of the things Shapeways does is lets you set up a shop to share your ideas and make it easy for others to order them. So I've added the various Intellivoice II parts to my shop. There's no markup on them -- I don't make any money on these. But they should make it easy to get your own if you decide to go the (admittedly expensive) Shapeways route. The upside is that the quality will be second-to-none since it uses SLS printing rather than filament printing. I should point out that the volume knob is subject to change since I haven't received the updated version yet in the mail. There is a possibility that it will have to be revised once I get it and do a fitment check. https://www.shapeways.com/shops/hustin