Tag: videobrain

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.

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.

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.

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.

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.

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:

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.

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.