DanBoris

This is very interesting, this looks like a prototype of some sort. That's not what the normal voice module PCB looks like.

It's quite possible that the voice module was supplied with a higher current AC adaptor to support the extra load of the voice hardware.

There is a picture on this site of one that doesn't have the vent. It appears without the vents in all the advertising I have been able to find, but pictures of the actual unit seem to always have it. That vent is right over the ROM board so it's possible that the early models didn't have it and they later discovered it was needed. http://www.videogameobsession.com/videogame/odyssey/odyssey2.htm

That is very strange, not sure why anyone would do that. Maybe the cartridge connector on the system was broken so they just hard wired it to the slot in the voice module? Would be really interesting to see what is going on inside.

Here is what the highway part of the game looks like if you turn off all the sprites. And here it is with the sprites on..

I look a look at Frogger and I think the cars and logs are combinations of characters and sprite with mid screen changes to re-use the sprites. I also forgot that there is a way to display only portions of the internal characters (with some limitations) which allows for some more flexibility in creating custom images.

The animated frog on the intro screen is easy, that's just a combination of the four sprites. The bigger question is, how were the cars done?

It might be possible to update the sprites mid-screen, this is something someone would need to experiment with on the real hardware to see how far you could put it. The CPU does control the VDP chip, but the VDP is totally responsible for controlling the video signal so you are limited to what it allows you to do. The character set is baked into the hardware of the chip, so there is no way for the CPU to override that. The Videopac+ simply adds a second video chip that generated background image that the original O2 graphics are overlayed on. The new videochip provides a 40x24 text mode with some redefinable characters. It's easy to look back and criticize the design of the system, but it all comes down engineering tradeoffs when the system was being designed. I am sure the designers had specific goals in mind and designed a system simply to achieve those goals. The O2 came out in 1978 and was a major step up from anything Magnavox had done before. They had no idea what the videogame market would look like in just a few years so the limitations were probably not seen as a big deal.

Intellivoice and the O2 Voice both use a version of the same voice synthesizer chip, they SP0256.

looks like most of those games are using the enhanced background graphics on the Videopac+. Take away the background and they are using the basic functions of the O2 hardware.

Pac Man/KC uses all the O2 objects, the player and ghosts are the sprites, the maze is the grid, dots are individual characters 27s, and the score is the quad characters. No, there is no way to flip characters or sprites. I guess in theory you could do PCM sound, but the O2's processor is pretty slow, so even if you could do it you probably couldn't do much else.

Custom characters are not possible on the O2, only the 4 custom sprites. I wrote the first emulator the O2, so I can say this with confidence. The moving dots in KC are just character 27.

The challenge with using the dot tile is that you are limited to how many you can put on the screen. You can have 12 that are individually controlled and then 4 groups of 4 that have to be displayed together. The question would be how many you can generate using mid-line or mid-screen register changes? In theory you could create a 28 pixel wide bitmapped display this way if you could change the registers fast enough.

I can confirm that the O2 cannot flip sprites, you would have to reverse the actual sprite data. As for a user defined characters set, the problem would have been where to store it. The O2 video chip runs entirely off internal data, it cannot access any other memory on the system. The 8048 can also only access 256 addresses external to the CPU and the video chip already takes up almost all of that. They would have had to add extra memory to the chip and implemented a bank switching scheme to give access to it. Certainly was possible but it seems they did not think it was worth while for what they were trying to achieve with the system.

This is what made ports so challenging on this system. The only thing you had total control of was the 4 8x8 sprite which could make it very difficult to match the graphics of the game you are trying to port. The cartridge slot does support bank switching up to 8K.

I tried this using Ghidra 10.4 and it doesn't seem to work. The extension is installed but when I try to import .atr it just treats it as a raw binary.

I recently repaired the my Coleco Telstar Arcade and while I was in the process I traced out the schematics for the entire system. Since this is hand drawn it may not be 100% accurate, but it is still a good reference if you are trying to repair of these. ColecoTelstarArcadeSchematics.pdf

One of things you can look for it things that always have to be done on the real hardware for a program to work. For example, in the Atari 5200 you can't read the joysticks unless the pot scan is enabled. Since there is no reason for a game to leave post scan disabled, and emulator might not emulate that feature (my 5200 emulator at the time didn't) because it wouldn't impact any existing programs. I can be come an issue if someone is using the emulator to develop new software, you could end up with a program that works on the emulator but not on the real hardware. Of course behavior that exists in the real hardware can be replicated in emulation if the emulator author wants to do it.

Best I can tell from the picture, the buttons are wire to left, right and down, and the switch turns the other three switched on and off. It's an odd configuration.

Bank switching can also easily be done with discrete logic, here is a cartridge that does it with three logic chips... https://atarihq.com/danb/7800cart/C300595.pdf

Some background on how I did the reverse engineering for this system. First I needed rom dumps, so I built a cartridge reader and a reader for the BIOS ROM that is in the processor. For schematics I hand traced the board and drew them out with schematic capture software. With the exception of the audio/video chip everything else on the board was off the shelf parts. Obviously the hardest part was the audio/video chip. I took a two pronged approach to that. First, I wrote the beginnings of an emulator that implemented everything but that chip and just logged all the writes to the chip. Since almost all O2 games start with the game select screen, I let it run until I was sure it had written that screen to the video chip. I then looked at the logged writes and tried to match them to what was on the screen. This was made somewhat easier by the three 'e' in "game select'. The O2 doesn't have traditional character based video so it wasn't as straight forward as finding the characters in video memory. To verify what I had figured out a build an adaptor so I could connect an eprom emulator to an actual O2, this allowed me to run my own code on the system. I took what I learned from the emulator and applied those same video writes to the actual system to see how the behaved. This initially produced some strange results because as it turns out, I had mistakes in the 8048 CPU core I had written for the emulator, so the values being sent to video memory weren't entirely correct. Once I figured out that screen I moved on to the grid style background that is common on O2 games. I used Football as a test case here since it has a simple use of the grid. From that it was pretty easy to figure out how the grid was drawn. I basically continued this process until I figured out all the graphic objects. I would have taken this same approach to figuring out the sound, but as I mentioned above, I was provided the documentation which showed how the sound worked, it also helped me verify my assumptions about how the video worked.

When I wrote my Odyssey 2 emulator back in the 90's there was no documentation available except of the Intel 8048 processor it used. I had to figure out everything else through reverse engineering. Funny enough, once the emulator was out there, one of the original O2 programmers sent me the official documentation for the machine.

... and I thought 16 bits would be plenty.

And if it is using Stella, I wonder what it is using for the 7800 emulation. Would like to know if any of my code is in there.

Correct, you can only program an 8048 once, but an 8748 has eprom with a window so it can be erased.