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?

videobrain_lives2

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.

videbrain_lives1

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).

videobrain_problem

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.

videobrain_lives4

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.

videobrain_lives3

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.

Videobrain Prodding

videopain_debug

Yep, I broke out the logic analyzer!  I have hooked it up to the Videopain as I have come to call it.  There’s about 90 probes hooked up.  I used 6 pods which have 16 lines each and a clock.  I can’t quite save the data off the analyzer yet but I am working on it.   This thing is GREAT.  I could watch the code run, and then the CPU died.   I discovered too, that the RAM’s Din and Dout pins were swapped.  The schematic shows Din and Dout swapped so that meant I had to move a bunch of wires on the SRAM chips.  After doing this, I could see the SRAM clearing routine run ONCE at powerup now, instead of each reset.  On subsequent resets it reads the signature byte out of RAM and knows that RAM was initialized already.

After some more RAM writing, and other various things, the CPU writes to the UV201 ASIC and gets hung up.  I tried multiple ASICs, but they all do the same thing.  I have come to the conclusion that I’m fairly certain the schematic has some kind of error on it, which is preventing this from working.  Interestingly the RAM writes, which also stop the CPU work fine.  But when the ASIC is written to, it never resets the flipflop and the CPU stays frozen forever.  Here’s some handy-dandy captures with some code to illustrate this:

videobrain_ramwrite

Here you can see a normal RAM write.  Watch the “RAM WR” signal.  When it goes low, the clock to the CPU (XTAL) stops, which has the effect of stopping the CPU’s output clock below it (PHI0).  As usual, click to embiggen pictures.  This works fine and you can write to RAM as many times as you like, as the RAM init shows.   The logic signals here relate to the following code:

LM ; 43cf 16

XDC ; 43d0 2c

ST ; 43d1 17

DS (IS) ; 43d2 3c

BF $4,A43ce ; 43d3 94 fa

PK ; 43d5 0c

43D1h is the ST(ore) instruction, which writes to RAM.  DC is pointing to 0FE8, which is the address it writes to.

videobrain_death

And here is where it wedges.  It doesn’t crash, it just goes to sleep and never wakes up.  This is the first write to the ASIC.  The code for this is:

DCI $0850 ; 4763 2a 08 50

LIS $4 ; 4766 74

SL 4 ; 4767 15

LR $8,A ; 4768 58

LI $ff ; 4769 20 ff

A476b: ST ; 476b 17

The ST instruction at the end writes to (DC) which is pointing to 0850h, one of the ASIC registers.  Check out the trace:  The address bus is stuck on 0850h, data bus is 0ffh (which is what it’s writing, from that LI $FF),  RAM WR pulsed low to indicate the write, the CPU stops, and that’s it.

At this point I am fairly sure it’s an error in the schematic and I am kinda stuck until I can get a Videobrain to poke, or someone to confirm a few things on the schematic.  I am not quite sure why writing to the ASIC is doing this, while writing to other things does not. That part is kind of a mystery.  The next step is to see if I can solve THAT mystery.  If not I dunno what to do except some external help with tracing some paths on the system.