JohnPCAE

I'm interested in one of the remaining copies of Pandora if available.

It's a shame we don't have the PhillyClassic event anymore. I'd drive up with a couple of ACC units to hand out.

I would recommend going with a plain Raspberry Pi Pico rather than a special Adafruit version. The reason is that the plain-Jane Pico will probably be around a lot longer. My first version of the ACC was designed around Sparkfun's special version of the Arduino called the Redstick, which wasn't around long before they discontinued it. That forced me to do a total redesign.

What about the algorithm in the Atari 2600 maze generation game?

Looks like it's sold out now 🙁

The add-on I'm designing for the ACC is intended to give USB and Wifi.

Many are with an ACC plugged in...

Once it's built and tested, I'll zip up all the board details and software and post it on the forums. It will take a while, though to get to that stage.

Board design for a peripheral add-on. The intent is to provide USB, Wifi, and real-time clock (and it has a seven-segment LED and auxiliary I2C for debugging). USB and Wifi would be very slow since it would be passed through the ACC's parallel port but it should be enough for HID devices and slow net access. I'm also planning to look into whether a Pi Pico can be used for converting the ACC's video output to an RGB video overlay (the ACC has a 2x6 header on it for this purpose). By the way, I've still got two complete ACC units sitting here looking for developers. This the RTC it's designed for: https://www.adafruit.com/product/3013

Where do we go to pay for them? Do we wait until we get contacted?

I'm a lifelong American and this is the first time I've seen an "American style" crossword. I've only ever seen the British/Australian style ones in our local newspaper.

I should point out that it's not necessary to delve into the schematic to make the circuit boards. All of the Gerber files for both boards are included in the ZIP file, so all you would need to do is ZIP up the Gerber files and send them to the board fab site of your choice.

The Pico is what's driving the whole thing. There's a ton of software that I wrote for it (the sources are in the ZIP). So yes, you'd program it once and that's it. The compiled .uf2 file that you'd drag to the Pico to program it is in the ZIP.

1. The cartridge board uses a PLL circuit to synthesize an MCLKx4 signal from the Master Component's MCLK signal. MCLK is good enough only for generating black-and-white overlaid video. To generate color video I need a clock signal that is four times the rate. And it has to use a PLL circuit to generate it from the original because the resulting MCLKx4 signal needs to remain phase-locked to the original. If I were to use, for example, a separate crystal to generate the 14.31818 MHz signal instead, the overlaid video would jitter from left to right (which I tested and verified). So the cartridge board performs a very important function. 2. I don't mind at all. I only wanted to invent it. I'd very much like for people to make and sell them. 3. I don't have anything in PDF format. I can generate screenshots from the schematic, or anyone with Eagle (or anything that can import Eagle files, like KiCad) can do the same. The Eagle schematic and board files are included in the ZIP. It uses some custom libraries, but if anyone needs them I can update the ZIP file. 4. It uses standard cartridges. The DB25 is a bidirectional parallel port. I had just enough I/O pins and board space available to shoehorn that feature in. The idea is that someone could use it to connect an Inty to an external peripheral. For example, I envision a separate board that, when plugged into it, would supply a few USB ports and a real-time clock. I even began a preliminary design for such a board over the weekend. At its heart would be another Raspberry Pi Pico, which can operate as a USB host. It uses I2C to communicate to an Adafruit high-resolution real-time clock breakout board. The only other connector of any note (excluding the one for a power LED) is a 2x6 header. It contains the digital video signal value right before it's converted to analog as well as some timing information. The purpose of this connector is to enable conversion to RGB in the future, since this board only piggybacks the overlaid video into the Master Component's composite signal (that is, if you use an RGB board in your Master Component, the overlaid video won't be visible). This connector means that a daughterboard could theoretically convert the overlaid video to RGB for later combining with RGB video downstream.

Well, the product itself is completed and ready for anyone to build. I had some thoughts this morning on some potential further enhancements to the software, but the hardware design is 100% complete. Everything that someone needs to build one is in the zip file that I attached a few posts above. It uses only old-school through-hole soldering because I wanted to make it as easy as possible for anyone to construct.

Anyone else interested? I should be getting the 2nd wall wart in the coming days.

Will you be contacting us in the forum when it's our time to send payment? I haven't been paying close attention (and I'm not too keen on reading 26 forum pages). How does this work?

I just finished building a second spare unit, so once I get the wall-wart from Amazon I'll have two spares that I can send to people interested in checking them out for potential development (for free!). One thing I just learned: if you get a Raspberry Pi Pico with headers pre-installed, check them for shorts! Whoever soldered them on did a lousy job. It took me a week to track down the problem.

Another couple of updates: 1. Altered how sprite linking works. I realized that setting the Y position for a linked sprite to 255 would conflict with a position at the bottom of the screen, so instead the X position will designate that a sprite is linked to a parent and the Y position will contain the sprite index of the parent. Since a screen is only 160 pixels across when dealing with sprites, this gives me a lot of freedom for how the X coordinate can be used to link sprites. So, instead of only using X=255 to link a sprite to a parent, putting a value in the range 192..255 into the X coordinate will not only link a sprite but also specify a relative location with respect to its parent. I've added a section in the documentation that describes how it works. Long story short, it allows building large, high-resolution sprites that can be moved around simply by setting the location of the parent sprite. For example, you could build a multicolored large sprite for the Sinistar enemy and have it move around without any visual shearing since all sub-sprites would automatically move together. 2. Fixed a bug in the Gerber files such that some IC names weren't showing up on the silkscreen. 3. Added an appendix at the end of the documentation with bill-of-materials info. It's in a slightly more useful format than the BOM in the separate text file as it groups identical components together and provides an overall quantity. Advanced Console Component 20220919.zip

Do we know if the Basic cartridge for the KC is written in CP1600 assembly or 6502? It would be great if we could port it to my add-on project!

The chip shortage is a real pain. I wanted to get some simple DIP TTL SN74LS08 AND gates, and Mouser won't have them until NEXT summer. Luckily I was able to put in some CMOS ones and they're working even with the voltage level mismatch.

Any thoughts on adding extra opcodes, such as either the Locutus instruction set or the instruction set I have in the Advanced Console Component (which doesn't conflict with the Locutus instruction set)?

I have a complete spare unit boxed up and ready to send to anyone who wants to develop for it. I have a second spare unit almost finished, and the remaining chips that I need to complete it should arrive today. All chips are socketed so all I have to do is pop them in, set up and pop in the Pi Pico, and test it. Before sending the second one I'll also probably order a wall wart for it as well (6V center positive).

You know, my project in the Bird's Nest thread (Advanced Console Component) brings a ton of enhancements to existing Intellivision units. I don't have the skills to make an FPGA solution, but it could be conceivably reduced to just an FPGA, 1K FIFO, and the Raspberry Pi Pico. All of the chips on the board except for the FIFO chip are just TTL glue logic. You could probably also bury the FIFO in the FPGA as well.

Maybe just have a panel on the back that slides or rotates up to support the top of the overlay.