DanBoris

Looks great, what emulator are you using?

That for the production version of the voice (I actually drew this). It's quite different from what is seen in this version.

Yep, that me, still not used to being a "celebrity" Yeah, it's possible the cartridge went bad, I assume you only have one?

Are we sure this is an April Fools joke? The game is actually a perfect fit for the graphic capabilities of the O2.

The weak link in the Microvision is the display thy go bad a lot. There is a thread here from someone who is doing replacements...

I would say something like, "swap A201/A200/A202, testing after each, did this fix the problem?"

For the STC waveforms I would just use what is already there. Unless someone has that cartridge they will not be able to reproduce those wave forms.

Cool project, looks good so far. When I do projects like this I do them for myself, and if other get's benefit all the better. As we can see, original documents can have mistakes, at least with a new version any mistakes that are found can be corrected to make a better document.

Yes, that seems right. Both pins 6 and 10 on J101 are ground. I think the second block should be CR201, but I also think the yes and no are reversed. If CR200 was for example shorted, it would pull the cathode to ground so you wouldn't get a signal. So if there is No signal it is defective. Same with the second block.

Looks like a mistake, it should be +5v. #1 is ok. This signal would be pronounced "Phase zero", do you have the Greek letter Phi and then the number zero. Slashed zero is fine, but not really needed since it's unlikely to be confused with a letter O. Doesn't really matter but "Is there an open" is proper terminology. Looks like a mistake, I don't see why you would jump back to the point in the troubleshooting. Looks like they always tried to have everything that goes back to A be joined to a single A node unless it has to cross another line. Sort makes sense since A is start back the start. I could take a shot that.

I will have to look into that one. My assumption is the "corruption" that occurs when you overlap characters is predictable so certain interactions may be useful. Someone actually created a utility to figure this sort of thing out. http://www.guttenbrunner.com/videopac/

If two characters are touching, even if the pixels are blank, it will mess up the character graphic. I would like to play around with that interaction some more to see if I can figure out how the VDC hardware handles this and maybe even find a way to emulate it. Internally graphics data has to move into a shift register so it can get clocked out onto the screen one pixel at a time. Since sprites can overlap each other, there is likely one shift register for each sprite. With the characters, my assumption is that there is a single shift register that is why characters cannot overlap.

Sprite and characters are different things. Sprites have a user definable shape and can overlap any other object on the screen, sprite of characters. Characters have to come from the internal character set and can not overlap other characters. The O2 clearly wasn't "dead on arrival" since it has a good sized library of decent games. It was not as flexible as the 2600 but the programmers managed to do some cool stuff with the hardware. The Channel F did have more flexible graphics, but it O2 had a higher resolution and a little more color flexibility. The Channel F also has a pure bit-mapped display so the CPU had to do all the drawing work which would have made if difficult to go more complex arcade style games like the O2 did.

I did verify on the actual hardware that if two characters overlap, even overlapping blank pixels, you get strange results. Here is a picture of what happens when I try to put two character 27s right next to each other. You can see one on the left but the other becomes garbage.

Yes, but you can re-use a sprite as you go down the screen so you can have more the 4 moving sprite objects.