Bird's nest...

[+BBWW]

This needs to be miniaturized or at least fit into a hollowed out Intelivoice. Those run about $15. It should be a "thing". Amico looks more dead everyday and this would add a lot to a classic console.

 

[overgrouth]

This would bring rise to greate new homebrew games for sure.

[JohnPCAE]

On 3/2/2022 at 6:04 PM, BBWW said:

This needs to be miniaturized or at least fit into a hollowed out Intelivoice. Those run about $15. It should be a "thing". Amico looks more dead everyday and this would add a lot to a classic console.

 

It would have to be an FPGA or CPLD for that, both of which are beyond my skills. That said, I designed it so that it's entirely old-school through-hole construction to lower the required assembly skill set as much as possible.

[JohnPCAE]

I've made a small addition to the code. Now, you can link sprites by specifying 255 as the Y position. When this is set, the sprite's X position specifies the index of the "parent" sprite. A sprite linked in this way will take on the size and position of its parent. This lets you easily implement multicolored sprites since you only need to set the position and size of the parent to affect all of the sprite's constituent parts. Note that you can't daisy-chain sprites with this method: it only follows the link once, so if you have multiple child sprites they all have to be linked to the same parent. I also updated the documentation to match.

 

Advanced Console Component 20220410.zip

[JohnPCAE]

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

Edited September 19, 2022 by JohnPCAE

[JohnPCAE]

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.

[+DZ-Jay]

8 hours ago, JohnPCAE said:

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.

 

Man, I sincerely wish I had the time to work on this.  I really do.  It is a fascinating project, and something that I've been looking forward for a while.

 

Alas, I cannot commit myself to anything -- not only am I a procrastinator of the first order (seriously, with emphasis on "pro"), I have way too many half-started projects already and haven't managed to complete a single one.  Plus, of course, there's my ever diminishing life as I get older.

 

All that being said, I seriously hope someone takes this on.  Furthermore, like @BBWW, I want to see this turned into a "thing -- an actual production-ready device that people can tack onto their Master Component and play enhanced games with.

 

Good luck, mate!

    -dZ.

Edited September 21, 2022 by DZ-Jay

[+fdr4prez]

3 hours ago, DZ-Jay said:

I cannot commit myself to anything -- not only am I a procrastinator of the first order (seriously, with emphasis on "pro")

Super Pro Procrastinator 

 

I am glad I ain't the only one

 

[JohnPCAE]

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

[+BBWW]

Post Amico failure, this is such a cool option to upgrade the Intellivision. Looking at the interest for new controllers I can't help but think this is a viable product to develop. I have Zero skills in this realm however. I would consider an investment to get it done.

 

[JohnPCAE]

46 minutes ago, BBWW said:

Post Amico failure, this is such a cool option to upgrade the Intellivision. Looking at the interest for new controllers I can't help but think this is a viable product to develop. I have Zero skills in this realm however. I would consider an investment to get it done.

 

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.

Edited September 23, 2022 by JohnPCAE

[+DZ-Jay]

1 hour ago, BBWW said:

Post Amico failure, this is such a cool option to upgrade the Intellivision. Looking at the interest for new controllers I can't help but think this is a viable product to develop. I have Zero skills in this realm however. I would consider an investment to get it done.

 

 

Same here!  I would consider investing in the implementation of a completed product.

 

   dZ.

[+5-11under]

A few questions. Thanks in advance...

 

1. So the cartridge board is basically there to keep the MCLK clock circuitry closely connected to the console (rather than having that signal pass through the ribbon cable)?

2. Do you care if people make a bunch of these and sell them?

3. Do you have a netlist, and schematic in pdf format?

4. What else do you need for the system? It uses "standard" cartridges? What's the DB25 and other connectors for?

 

Note that I'm not putting this on my to-do list (because like many of you, it's already way too long), but I would like to investigate to see what options there are, besides stuffing 30+ chips onto a bunch of boards.

[JohnPCAE]

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.

Edited September 23, 2022 by JohnPCAE

[+5-11under]

Also, what's the Pico for? Does it just get programmed once, normally, and forget about it after that?

 

[JohnPCAE]

6 hours ago, 5-11under said:

Also, what's the Pico for? Does it just get programmed once, normally, and forget about it after that?

 

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.

Edited September 24, 2022 by JohnPCAE

[JohnPCAE]

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.

[JohnPCAE]

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

 

 

Edited September 27, 2022 by JohnPCAE

[JohnPCAE]

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.

Edited September 27, 2022 by JohnPCAE

[JohnPCAE]

I've fixed several bugs in the processor emulator and added a new instruction: MVIF@ RM, RD. It lets the emulated processor read from its internal font ROM. The documentation has been updated to include the new instruction.

 

Advanced Console Component 20221009.zip

[JohnPCAE]

I don't even want to think about what this would cost to print...

(Why an expansion port? because the ACC actually does have a small expansion header for digital video)

[JohnPCAE]

I've updated the included example. It has a proper detection and initialization sequence now and is a proper example on how a new game should detect the ACC and set up video. I also added some utility routines for setting up 40-column and 80-column text mode and clearing the screen, and updated the comments for some routines.

 

EDIT: I updated the included ZIP with a minor addition. I added support for the new MVIF@ instruction in the acc_coprocessor.src macro file.

 

Advanced Console Component 20221106.zip

Edited November 6, 2022 by JohnPCAE

[JohnPCAE]

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?

[carlsson]

Hm, I had not seen this before and I'm not quite in the dev market to volunteer to borrow one but perhaps it needs more exposure.

 

I see that the documentation and examples are strongly geared towards assembly language. Is there any support for integration with IntyBASIC too? As you may have noticed, the majority of new Intellivision programs these dare is developed in this language, sometimes with additional inlined assembly language. Until there is some interface towards IntyBASIC, I'm afraid that the number of interested developers will be fairly low.

 

Is there any emulation support, for dry testing before acquiring a real unit for testing? It is nearly as important, though a much bigger step to crawl past as emulators don't write themselves over night.

 

I was about to suggest advertising the project on Facebook too, but assuming it so far requires assembly language knowledge, I think the few who truly master it already are on this forum. It is also the matter of the chicken and the egg, if the threshold is reasonably large, people won't be as eager to spending days and weeks in order to get it to do something decent unless they know there is an end user market. At the same time you don't want to plan for mass production before there is a relevant amount of software that uses it.

[JohnPCAE]

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.