JohnPCAE

I've started building a second set of boards. I don't have everything I need for them yet, but when it's complete I can send it to you. I'll also have to write some sort of Inty ROM that can actually send something to a MIDI device.

I updated the BOM (Bill of Materials). It's important to use HCT variants for certain chips or the colors don't come out right. Advanced Console Component 20221126.zip

It's here, at the end of a five-year odyssey. I have two spares that I'm willing to give to people interested in developing for it.

A few things in this release: 1. Fixed a software bug relating to setting the color palette. 2. Minor typo fixes in the documentation. 3. Greatly expanded the included example: - It now includes and uses a bunch of generic functions suitable for use with something like IntyBASIC. - It uses what I would consider to be the correct and complete initialization sequence for a game that uses overlay video. - It includes an example of using the coprocessor to execute something useful (in this case, it's a function that converts hue, saturation, and luminance values to color timeslice values) - It includes some example code of reading key events from a USB keyboard (if you have the USB add-on that I'm working on also plugged in). - It's an actual tool. With a USB keyboard plugged in, it can be used for adjusting the color palette. I used it tonight to get the default palette colors a lot closer to the Intellivision's native palette. For the selected color, it prints out the four timeslice values that would be used to program that color. I chose to go with the USB route because it's a lot (a LOT) easier to read USB events than controller events. I'll leave expanding it to use the Intellivision controllers as an exercise for the reader 😉 Advanced Console Component 20221119.zip

This is what I was originally shooting for, but as we learned, it's too narrow for a two-board solution, so I had to widen it by 12mm. The reason for the white blocks in the center of the image is because it's actually composed of two images that I had to Photoshop together, and a narrow vertical stripe in the center was missing (where the catalog folded). I did my best to reconstruct what it would look like. As far as I know, this is just a wooden mockup that Mattel's wood shop made and they never actually made the real thing. I added the expansion door like the one in the ECS to accommodate the expansion connector. A lot of my measurements came from measuring my ECS case. What you might not realize is the complexity of the model. Nearly all of the edges are actually slightly rounded, in the same way that they are on the ECS. There are a lot of 1mm-radius curves in the model as opposed to sharp edges. I did my best to recreate the ECS's profile to a high degree. You can sort of tell that the module in the picture here is a mockup by its edges compared to the edges on the Intellvision next to it. The Intellivoice's edges are sharper as if made by a wood saw as opposed to by a milled injection mold.

Thanks for testing out the final models. Once I get my prints next week and assemble them I'll post the models here. These models are 12mm wider than the originals that I posted at first which alleviates fitment problems. One tip. I used three wires to connect the potentiometer to the board instead of soldering it directly. This gives you some wiggle room to get it positioned just right and might be necessary. It takes some soldering gymnastics to get the little wires to stay put when soldering them. I used the excess from the EDAC connector leads.

If I make a case for the ACC I'll have to consider it. The ACC is rather large.

Would it help if I expanded the included example to include a library of standardized, generic functions?

The ACC doesn't care about vertical blanking: you can change sprite or character graphics any time you want. Depending on when it's drawing, they might not show up until the next frame, but there are no timing restrictions on what you do to it. The 64k words it provides is shared between its functions. The beginning part of it is used for screen memory, the end part is used for sprite graphics, and anything left over can be used for coprocessor code. A good (and simple) use of its coprocessor would be for text scrolling: it's capable of scrolling text in its screen buffer many, many times faster than the Inty could do it. To use the coprocessor, the Inty would have to copy the code from its memory into the shared area at $Dxxx and then instruct the ACC to execute it.

Bear in mind the coprocessor instructions ONLY run in the ACC's memory space. It supplies 64k words as 16 4k pages. Each page is mapped to addresses $D000-$DFFF in the Inty's memory space.

Just FYI, this is the hub I recommend using with the USB add-on. I'm having no problems with this hub and I can sign off on it. You'll also need a USB-A to USB-micro adapter, which I'll also link. https://www.amazon.com/dp/B07L32B9C2?psc=1&ref=ppx_yo2ov_dt_b_product_details https://www.amazon.com/dp/B00K4RZQWQ?psc=1&ref=ppx_yo2ov_dt_b_product_details By contrast, the hub below does NOT work. I suspect that it has to do with the proprietary Ethernet port on the end. I can't get it to mount anything. https://www.amazon.com/Three-Port-Ethernet-Micro-Connector-Great/dp/B083VXQKD1/ref=sr_1_4?crid=F6AMF7YNKKMA&keywords=usb+zero+hub&qid=1668725664&s=electronics&sprefix=usb+zero+hub%2Celectronics%2C62&sr=1-4

I'd like to see a collaboration with the creators of IntyBASIC to see if ACC support could be added to it. The example program provides a few starting routines like detecting it, enabling memory access, enabling video, and setting up text modes, but there would have to be a more fleshed-out series of IntyBASIC functions to go along with the basic stuff. I'm thinking of things like selecting the memory page, outputting text, and setting palette colors for starters. That would at least get basic text support going. After that we could look at supporting the graphics modes and sprites (it supports up to 248 additional sprites). I would think that supporting the coprocessor would come last. The ideal place to emulate it would be in JzIntv, I would think.

Good progress tonight! I had to make a couple of enhancements to the TinyUSB library (that I submitted back to the developers) and now I have multiple devices being mounted with a USB hub (a full-size keyboard, a number pad, a USB stick, and an N64 controller using a USB adapter). And it's now detecting them even if they're already plugged in at powerup. There are other things to test, like actually reading data from a USB stick, but at least mounting and unmounting devices is pretty solid.

*sigh* THIS IS ONE OF THE REASONS WHY I CREATED THE ACC! So we could have much more interesting games on the Inty! You have no idea how frustrating this is. I have two complete ACC units just sitting right in front of me that I'm prepared to gift to developers for free. And yet I have no takers. You get 40x24 text, even 80x24 text if you want to, and it's super-easy to set up. While it provides all kinds of other features like a coprocessor, extra RAM, graphics modes, and a parallel port, you don't have to use them. I've even posted with it an example of how to detect it and set up 40x24 text mode. It's incredibly easy to program for the ACC. And yet no one wants it.

I actually neglected to set them, but the RP2040 datasheet says that the default state is pull-down. Which I think is best since that results in a default NACT state.

I already ordered boards last night and the minimum order is 5 so I can build you one when I get them. The hard part would be the software on the Inty side since I don't know what should be sent to a MIDI device.

I've nailed down the hardware details, so here are the Gerbers for both boards as well as the BOM (it's a two-board solution similar to how the ACC and the Intellivoice II work). The software for the Pi Pico is undergoing rapid development, so I'll hold off on posting it until someone posts here that they've built the hardware and are ready to test the software. I also have a small Inty program that queries the USB board and prints a bunch of information on the screen (key events, mouse events, gamepad/joystick events, and mounted devices). The IntyCartExtend board is identical to the one used for the Intellivoice II, so if you have those, there's no need to order more. IntyCartExtend_Gerber.zip IntyUSBDirect_Gerber.zip Intellivision_USB_BOM.txt

I've put in some tentative support for sending packets over USB to a MIDI device, but I have no way to test it...

Are you trying to log what's happening? That could be causing major latency problems (by the time you finish logging something like the bus state it could have changed, for instance).

Well, well. Someone has added a MIDI host driver to a fork of TinyUSB: https://github.com/rppicomidi/tinyusb/tree/pio-midihost I've integrated it into my TinyUSB library, which means I could conceivably support plugging in a single MIDI device (a single MIDI device is all his driver supports). I'll start looking into adding support tomorrow, but I don't have any MIDI devices to test (a musician I am not). Short of someone with a MIDI device building one of my USB boards and having me send them the microcontroller software (and then they'd have to write something for the Inty to actually use it) I'm not sure how to test it.

Got all my USB sticks mounting (I tested 5 of them). I haven't tried reading anything from them, but they're mounting and unmounting with no problems.

Updated BOM. Thanks to KylJoy for pointing out that C13 was missing from the list. It should be the same as C12. Intellivoice2_BOM.txt

I had to add some code to TinyUSB but I have it properly mounting my 4GB USB stick now. It doesn't like my 8GB stick, though. I'm not sure why. I'm getting DEVICE_ATTACH and DEVICE_REMOVE events but no other events from it. I'm specifically looking for a XFER_COMPLETE event but not getting any.

Could it be the way you handle DeviceAddress? I set it by comparing the incoming address from BAR/ADAR against what is valid (5000-6FFF in your case).

I see. Okay I've set it up so that the Inty can command it to retrieve a gamepad's USB serial number and dump it into the shared memory buffer.