Videobrain Debug Continues

Weeel, I have gotten to the point where all the main timing is figured out,  so the next and last step is to thoroughly poke the video chip in an attempt to suss out all the edge cases and other weirdness.

To perform this task, I have made a second perf board that plugs into the “video” part of the Video Brain.  This board contains a PIC18F452 and a MAX232 serial level translator, and will take the place of the F8 CPU, 3853, and everything on the lower board.  I can now poke the registers directly using the PIC, and I did not have to write any F8 code.  score.  Also, the PIC is muuch faster at poking the UV201.  Also, it is in circuit programmable, I do not have to burn EPROMs (or flash ROMs), and I don’t have to figure out how to use the BIOS and all that.  So I spent me 1.5 hours making the board instead of learning the ins and outs of the F8 code on the system.

Before seeing that, though, I had to hack the VB to slow down its clock, since I was being buffaloed by propagation delays.  These delays made it very difficult to figure out exactly what was going on, so now that they are gone things are working much better.

Videobrain Fixes

The changes from last time are the addition of the clocking circuitry on the left under the video plug-in area (lower left corner), and I have the game EPROM installed into its socket now.  I made several other fixes and changes but they are not visible.

videobrain bottom

Here’s the bottom side in case anyone was curious.  The black things are rubber feet so it won’t scratch the hell out of my table (or skitter off it for that matter).  The two wires on the right side are 12V in.  black marker’ed wire = ground, other is +12V.  There’s a 5V buck regulator to generate 5V to run everything.

videobrain PIC

And here’s the new addition.  This PIC board replaces the F8 CPU, and gives me an in-circuit programmable microcontroller and serial port so I can dork with the UV201’s registers in near real time.  I can just type some commands in PUTTy and it will change the register values.  The PIC takes care of reloading the UV201 registers every frame (it reloads all of them) so that any changes are instantly picked up.  The cable on the left is the programming cable, one on the right is RS-232.

videobrain under PIC control

And, what it’s all about.  The PIC is driving the UV201 now, instead of the F8 CPU.  I used the logic analyzer to snag the register writes to the UV201, and just duplicated those readings in my program for testing.  The graphics for this game are pulled out of its cartridge ROM directly, except for the two players for some reason.  Those are coming out of RAM, and that’s why they show up as two random blobs.  I will be loading checkerboard patterns into RAM and using that for testing, so I can make sprites of any size and move them around and see what happens when they collide with one another.  (We know basically what happens, but I don’t think anyone has any clue what happens at the edge cases.  How close to the edge can an object be? can they be touching, or does there have to be at least a 1 pixel space?  and other such questions).

I should be able to finish up my document now using the information gained from this.

Videobrain Lives!

Well, I did it.  I got ‘er working.  Mostly!  Thanks to the people on the Videobrain/Channel F list for their help.  The problem that prevented it from working was dumb.  There were two pins swapped to the UV201.  Pins 35/37 on the schematic to be exact.  I figured this out using an Excel spreadsheet of the chip connections that was done by Sean Riddle.  I was comparing the schematic to the spreadsheet and found the problem.  After swapping those two pins, things started looking much better.  Almost fine in fact, on the logic analyzer.  It was no longer hanging up and the video pins seemed to have some activity too.   Soooo, I hooked the monitor up and was prodding the R-Y and B-Y and Y outputs from the video circuit, and got some recognizable text on the screen!  Score!    Looks like the ‘brain can do 16 colours maximum (unless there’s something I missed), since all video data must come out of pins 2, 3, 4, 5 on the UV201.  Pins 19/20 on the UV202 appear to be composite synch and blanking it looks.   So enough of that, how does it look?


WOOT!  Look at that!  I got the best looking Videobrain evar, in RGB no less.  I know colours aren’t 100% correct, but we’ll get to that later.  I need to translate the 16 colours it can do into RGB values then devise a circuit to produce this.   One thing I found interesting is the Videobrain appears to output interlaced video.  Fan-cee.


I played around with the text editor doodad and typed some random stuff.  Interestingly, if you press shift, the screen goes all wonky in places, and stays that way until you press shift again!  Only while shifted does it screw up- and interestingly it will screw up on every screen if the system is “shifted”.  If you press shift again, video is fine.  I am not sure if this is an ASIC issue, or a hardware one (i.e. the final version of the system was fixed up somehow to prevent this issue).


Here’s that screwy thing going on.  You can see 5th through 7th rows are all wonky.  The pixel data randomly “shifts” up and down.  There’s no apparent pattern to the shifting.


Lol.  Who’d want a clock or alarm on this thing?  I can’t quite figure that out.  Oh well, that seems to work in any event.


And finally the colour test.  Yep it looks a bit hosed up.  I am using 3 of the ASIC pins inverted to generate RGB into the monitor.  This is just a hack so I can play around with it.   So that’s it for now- I got it working (mostly) and I will be testing the games out soon.  I have them all burned onto a single EPROM with some jumpers to select a game.