01234567890123456789012345678901234567890123456789012345678901234567890123456789 Videobrain Unwrapped -------------------- 05042013 V0.01 Written by: Kevin Horton Description: ------------ The Videobrain Family Computer was an ill-received home computer and videogame playing machine that was way ahead of its time. The system was designed in 1977 and only sold for about one year somewhere in the 1977-1979 time frame. There was only a few games and application programs released for the system before it died a premature death. With more advertising and programs, it might've gotten more popular. A lack of programming and advertising doomed it. --- Reproduction: ------------- I got interested in the VB because I got a hold of a bunch of the ASICs for the system by chance. Videobrain systems (from now on called "VB") are very hard to come by. The last one on ebay was $120 or so and broken, and before that, $400 for a complete system. Since the systems are so rare and expensive, and I had some ASICs, I decided to BUILD my own system! I had most of the chips and parts already to build it so I bought some perf board, 2102 RAM chips, and proceeded to build it. It took me about 4 days to complete it. I followed the schematic I found on the internet. After assembly, I went through and checked every connection with the multimeter. I found 3 or 4 minor flubs which were fixed, and I tried running it. I fired it up and the CPU was getting stuck somewhere. Before the CPU got wedged, the address lines to the RAM chips were toggling as the CPU tried to clear RAM out every reset. After the RAM clearing, it'd hang up and not restart. I managed to find the datasheet for the 2102 RAM chip (this was quite difficult) and figured out that the schematic had Din and Dout flipped. Great. Moving 24 wire later, things looked better: RAM was only being cleared once now and it was possible to see where the CPU was reading the signature byte to skip the clear routine. At this point, the CPU was still stopping. I hooked my logic analyzer up (an Agilent 16700B with three 16750A acquisition cards). Within about 5 minutes I could watch the CPU executing code, and see it was dying when it tried to write to an ASIC register. RAM reading and writing were working fine, halting the CPU and such, but when the ASIC was written to it died and the CPU never woke up. It took me a bit longer to figure out why THAT was happening. After playing around a bit and checking out the spreadsheet that Sean Riddle produced which had the circuit connections in it, it became obvious that the schematic had yet another error. Pins 35 and 37 were shown swapped on the schematic. I flipped these around and now the CPU was running without stopping. I dropped a wire onto some ASIC pins and fed it into my monitor and some stuff that looked like video was appearing on the screen. After a little dorking around, I made an RGB video mod for the system. --- Conventions in this document: I will define several terms first which will hopefully make it easier to explain what is going on. MCLK - Master Clock. This is a 28.6363MHz clock from which all timing is derived. CPUCLK - CPU Clock. This is a 2.04MHz clock which runs the CPU. BRCLK - BR Clock. Not sure what BR stands for. It runs at 3.579MHz. buffered bus This is the buffered address/data bus connected to the cartridge, SRAM, and UV201. All timing is related to one of these three clocks. To make testing and reverse engineering easier, I hacked my Videobrain "prototype" up so that both the CPU clock and the UV202 clocks were derived off the same source. The UV202 uses a 14.3181MHz crystal, and the CPU runs off a 4MHz crystal divided by two via the wait state generator JK flipflop. Originally, the UV202 generated a 14.3181MHz / 7 or 2.04MHz signal, but it stopped 1 cycle too late and this caused issues with wait the CPU. A bunch of "fixup" logic was provided externally to work around the issue. Instead of the 2.04MHz signal, they went with a 2.0MHz clock derived from a separate oscillator. My hack was to start with a 28.6363MHz oscillator and divide it by 2, and feed this 14.318181MHz signal into the UV202, and then divide it by 7 to produce a 4.09MHz signal which was fed into the wait state circuit in place of its 4.0MHz crystal. This hack then ties both the CPU and UV202 timing together under a common clock source. Hopefully this will make sussing out timing easier. It also gives my logic analyzer a perfect clock to suckle off of which will keep the sample count an exact multiple of the CPU and UV202 clocks. --- Chip descriptions: Videobrain ASIC UV202: ---------------------- The UV202 is the timing generator and bus transceiver that links the data bus from the CPU with the buffered data bus. All of the video timing information is generated by the UV202, and it also handles the CPU wait state stuff, but this was broken somewhat in the ASIC so they did some external circuitry to fix it. I investigated it, and the UV202's clock that would've run the 3850 CPU runs a cycle or so too long vs. the external hardware solution. I guess this was too much and it'd hit some kind of timing glitch during a wait state. It seems to accurately track the external clock otherwise. This clock is approximately 2.045MHz, which is 14.318181MHz / 7. This somewhat surprised me that they'd divide by 7 and not 8. Too bad that it is buggy. The duty cycle was 50% so they are checking both edges of the input clock. This is somewhat similar to divide by 3 on the Atari 2600 TIA that divides the 3.579MHz clock down to approx. 1.19MHz. The 3850 is now run off an external 2MHz clock generated by a JK flipflop running off a 4MHz crystal oscillator. UV-202 pinout: 1 - BSE 2 - UMIREQ0 3 - CPUREQ0 4 - Xin 5 - Xout 6 - DMAREQ 7 - CPU CLK 8 - WACK 9 - D0 10 - BD0 11 - D1 12 - BD1 13 - D2 14 - BD2 15 - D3 16 - BD3 17 - Hblank 18 - VBLANK 19 - Burst 20 - Csynch 21 - +5V 22 - +12V 23 - Scanline 24 - Field 25 - BD4 26 - D4 27 - BD5 28 - D5 29 - BD6 30 - D6 31 - BD7 32 - D7 33 - BRCLK 34 - COLCLK 35 - Bus Slot 36 - RST 37 - /800-BFF 38 - GND 39 - CPUREQ1 40 - BISTROBE 1 - BSE Bus slot enable. Normally pulled low via a 39K resistor, and connects to a pin on the cartridge. When pulled high, this causes the output on pin 35 to be enabled. It is synchronized so that it only is checked when a pulse on pin 35 is being emitted. (see pin 35) 2 - UMIREQ0 High when the UV201 wants to DMA data from RAM for display. It has low priority for accessing the bus. 3 - CPUREQ0 See the wait states section for information about this pin. 4 - Xin 5 - Xout Normally connected to a 14.318181MHz crystal. This sets timing for all video rendering and wait state generation. To drive this pin from an external clock, you must connect an inverter from Xin to Xout, and then drive the Xin pin. a 74HC04 is ideal. 6 - DMAREQ Pulses high to tell the UV201 that it is now OK to perform one DMA from RAM. 7 - CPUCLK Broken CPU clock output. This pin toggles at 2.04MHz, which is 14.3181MHz divided by 7. It is a 50% duty cycle waveform. It does not quit soon enough in the wait state, so it was fixed with external circuitry. 8 - WACK Wait Acknowledge. Goes high to acknowledge the wait state. It will not cause the CPU clock to continue until the falling edge of this signal. It is used to gate the ASIC and SRAM writes when high. 9 - D0 11 - D1 13 - D2 15 - D3 26 - D4 28 - D5 30 - D6 32 - D7 These are the data lines that connect to a 2K ROM and the CPU and 3853 SRAM interface. 10 - D0 12 - D1 14 - D2 16 - D3 25 - D4 27 - D5 29 - D6 31 - D7 These are the buffered data lines. They connect to the SRAM, UV201 data lines, a 2K ROM, and the cartridge. 17 - Hblank Goes high in horizontal blank. 18 - VBLANK Goes high for 21 scanlines every 262 or 263 scanlines depending on if this is the odd or even field. It is offset 1/2 scanline during odd fields. This signal is used by the UV201 to synchronize rendering to the scan. 19 - Burst Goes high every scanline immediately after the synch pulse, except for the first 9 scanlines VBLANK is high. 20 - Csynch Composite synch line that goes high at the beginning of each scanline, except in the Vblank region (see below). 21 - 5V Connects to +5V supply 22 - 12V Connects to +12V supply 23 - Scanline This line is not used on the VB, but it toggles at the start of each scanline. It has been useful during debugging. 24 - Field This line toggles every field and reflects if the odd or even field is being displayed. low = odd field, high = even field. 33 - BRCLK This clock is a 3.579MHz clock that is generated by dividing the 14.3181MHz clock down by 4. It clocks the UV201 and provides all timing information to it. 34 - COLCLK This clock appears to be an exact clone of BRCLK. It's the same phase and frequency as BRCLK. It is used by the LM1889 NTSC encoder / TV modulator. 35 - Bus Slot Not used. On the schematic it connected to the input of a triple OR gate, but the output wasn't used. It used to connect to an inverter that disabled address decoding (ASIC, RES2 ROM, SRAM, and cartridge ROM). This signal will stay low unless pin 1 is pulled high. When pin 1 is high, it will output pulses depending on what the UV201 is doing. More info is needed on what this is doing. It appears to be a 3rd form of bus cycle DMA after the CPU and UV201 DMA. 36 - RST Taking this low resets the chip. It is normally connected to a flipflop so that reset goes high at the start of the frame. I think this was done simply so that the reset button was a "reset once when pressed" signal instead of continuous while the button is held down. This would be required for the weird "top loading VCR" style cartridge slot, which resets the CPU when a cartridge is inserted . 37 - /800-BFF input. The external logic must pull this line low when the CPU attempts to access 800-BFF, which is the UV201 address range. 38 - ground Connects to ground. 39 - CPUREQ1 See the wait states section for more information about this pin. 40 - BISTROBE Pulses low to perform a read or write operation. --- Videobrain ASIC UV201: ---------------------- The UV201 is the actual video rendering portion of the system. It fetches data via DMA and then squirts it out its 4 video pins. It relys on the UV202 to generate frame timing information for it. This chip holds ALL of the ASIC registers. UV201 pinout: ------------- 1 - GND 2 - video 3 - video 4 - video 5 - video 6 - BA0 7 - BA1 8 - BA2 9 - BA3 10 - BA4 11 - BA5 12 - BA6 13 - BA7 14 - BA8 15 - BA9 16 - BA10 17 - BA11 18 - BA12 19 - +5V 20 - +12V 21 - BD0 22 - BD1 23 - BD2 24 - BD3 25 - BD4 26 - BD5 27 - BD6 28 - BD7 29 - Field 30 - EXT INT 31 - keypad column 8 32 - R/W 33 - VBLANK 34 - HBLANK 35 - BRCLK 36 - UMIREQ0 37 - BISTROBE 38 - RESET 39 - /CE 40 - DMAREQ 1 - GND System ground 2 - video 3 - video 4 - video 5 - video These 4 pins emit the video. Colour table coming soon. 6 - BA0 7 - BA1 8 - BA2 9 - BA3 10 - BA4 11 - BA5 12 - BA6 13 - BA7 14 - BA8 15 - BA9 16 - BA10 17 - BA11 18 - BA12 These 13 pins are the buffered address bus. They are used to decode the write address when the CPU writes to the UV201, and they also drive the buffered address bus when performing a DMA read. 19 - +5V 5V power supply 20 - +12V 12V power supply 21 - BD0 22 - BD1 23 - BD2 24 - BD3 25 - BD4 26 - BD5 27 - BD6 28 - BD7 These 8 pins are the buffered data bus. 29 - Field Connects to pin 24 of the UV202 for even/odd field determination. 30 - EXT INT Drives the 3853 SRAM interface chip to perform interrupts. 31 - keypad column 8 Drives column 8 of the keypad (lol) 32 - R/W 37 - BISTROBE 39 - /CE These three pins determine what is occuring to the UV201. When /CE is pulled low, a CPU read or write is in progress. the R/W line will determine if this is a read (low) or write (high). It is an inverted version of CPUREQ1. BISTROBE pulses low when the UV202 is finishing its buffered bus cycle, and lets the UV201 and SRAM know that a write should be taking place. 33 - VBLANK 34 - HBLANK These two signals are generated by the UV202 and inform the UV201 where the raster is. 35 - BRCLK 3.579MHz clock that runs the show. 36 - UMIREQ0 Pulled high by UV201 when it wishes to DMA data from the buffered bus. 38 - RESET Low resets the chip. 40 - DMAREQ The UV202 pulses this line high when the UV201 should perform its DMA cycle. --- Frame timing: ------------- Video on the system is indeed interlaced. The timing looks very good. It's not exactly 100% NTSC timing compliant, but for 1978 it probably would've been plenty good enough to be used in a broadcast environment. They seem to have gone all out to make sure their signal is standards-complaint. I suspect they were hoping it might be used at a TV or cable station for showing info screens and such. The way timing is internally generated is mostly done via a scanline counter that counts by 262 or 263 depending on if the odd or even field is being displayed. I have used my logic analyzer (an HP 16700B) to suss out the exact timing, to the cycle, of the VB's frame. The system alternates between even and odd fields approximately 60 times a second, and displays approximately 30 frames per second. Exact cycle timings: Odd Even scanlines 263 262 clocks 59964 59736 (BRCLK's) fields/sec 59.81 frames/sec 29.90 Scanline 228 (BRCLK's) To perform the interlace, the hardware will render 262 scanlines for one field, then 263 for the other, and then shift the vsynch period back or forth 1/2 scanline to align it at the 1/2 scanline point each field. This is common and how most interlaced video is generated at the hardware level. The exact number of clocks for the video is as follows: Each scanline is 228 BRCLKs long, which incidentally is the same as the Atari 2600. It's a tad longer than it "should" be, but it works well enough. During a normal scanline: CSYNCH goes high during cycles 0-17 (18 total). BURST goes high during cycles 21-29 (9 total). HBLANK goes high during cycles 222-227 and 0-32 (39 total). HBLANK spans the end of the previous line to the beginning of the next line. This makes the total visible area on the screen 189 BRCLKs long. During the vertical blanking interval, timing is a bit different. Basically, it is composed of the following: --- (odd field) 3 scanlines of vsynch 3 scanlines of equalization pulses 244 normal scanlines 2.5 scanlines of equalization pulses --- (even field) 3 scanlines of vsynch 3 scanlines of equalization pulses 243.5 normal scanlines 3 scanlines of equalization pulses These two alternate back and forth every field (approx. 60 times a second) to perform the interlacing. The TV synchronizes off of Vsynch, so if you count scanlines starting with it, each field will contain 252.2 scanlines exactly. CSYNCH goes high TWICE during scanlines which contain equalization pulses: It goes high on cycles 0-8, and again at cycles 114-122. These pulses are only 9 clocks wide instead of 18 on a normal scanline. Vsynch is different yet again: CSYNCH is high for the majority of the scanline and pulses low twice. Unlike the equalization scanlines, its low pulses are 18 clocks wide (same as on a normal scanline, but inverted). It sends these pulses out on cycles 105-113 and 219-227. --- Wait States ----------- The UV202 performs all the wait stating. When the CPU wishes to access the buffered bus, the CPU is stopped and waits are inserted. The quantity of wait states inserted varies greatly depending on what peripheral the CPU is accessing. For this timing, I replaced the 28.63MHz oscillator I was using with a 1MHz one. The reason for this is I was being buffaloed by propagation delays in the chips and connections, which made sussing out the exact timing very difficult. The following is what happens inside the UV202 when no propagation delays are taken into account. This will be cleared up later. All of the following timing is relative to the state of the pins on the UV202, vs. the inputs of the D-flops that synchronize the signals (UMIREQ0, CPUREQ0 and 1). --- The pins related to wait states are: UMIREQ0 (pin 2) - High when the UV201 wants to DMA data from RAM. CPUREQ0 (pin 3) - High when the CPU writes anywhere in 800-1FFF (ASIC, RAM, cart), or reads from C00-1FFF (RAM, cart). DMAREQ (pin 6) - The UV202 pulls this high to let the UV201 perform DMA. WACK (pin 8) - Wait Ack. Goes high when the UV202 is performing a CPU based read or write. The falling edge restarts the CPU clock. /800-BFF (pin 37) - Low when the CPU is accessing 800-BFFh, high otherwise. CPUREQ1 (pin 39) - High when the CPU reads from 800-1FFFh. (ASIC, RAM, cart) BISTROBE (pin 40) - Pulses high in the middle of every buffered bus access This truth table should make it a bit clearer what happens on each pin during a specific kind of access: event: UMIREQ0 CPUREQ0 CPUREQ1 /800-BFF ------------------------------------------------- UV201 Write x 1 0 0 RAM Write x 1 0 1 UV201 Read x 0 1 0 RAM Read x 1 1 1 Cart Read x 1 1 1 DMA Read 1 0 0 0 x = don't care --- Let's start with the basics. The CPU is executing code out of the cartridge, and the UV201 is performing periodic DMA requests. CPU reads (cart/RAM) and DMA reads: UV201 DMA requests come either singly or in bursts. A burst is simply N bytes fetched in a row by the UV201. The CPU can interrupt a burst at any time, and data is read fast enough even with these interruptions to produce a glitch free display. CPU read requests only come every now and again, only once every 3 DMA requests maximum. If a CPU read and a DMA request both occur simultaniously, the CPU read is serviced first followed by the DMA. At the start of any bus access (CPU read or DMA fetch), a 1 BRCLK penalty occurs. If a DMA read follows a CPU read, a 1 BRCLK penalty is inserted. Interestingly, if a CPU read follows a DMA read, no penalty is inserted. In the event a CPU read and a DMA fetch both occur at the same time, a double setup penalty occurs: (all cycles are 1 BRCLK each) 1 penalty 3 cycle CPU read 1 penalty 3 cycle DMA read 3 cycle DMA read 3 cycle DMA read Otherwise, the following type of thing occurs: 1 penalty 3 cycle DMA read 3 cycle DMA read 3 cycle CPU read // this CPU read appears to incur no penalty 1 penalty 3 cycle DMA read // but the following DMA does 3 cycle DMA read 3 cycle CPU read 1 penalty 3 cycle DMA read The CPU read above appears to incur no setup penalty, but it IS there. The DMA access will only be replaced by a CPU read if CPUREQ went high on the rising edge of BRCLK leading into the last cycle of the DMA request. This means that during DMA fetching, the CPU will see a 4, 5, or 6 BRCLK wait while the DMA finishes. Depending on video and CPU synchronization, one of these maybe favored over another. --- UV201 reads: reads from the UV201 vary a bit. These take 6, 7, 8, or 9 BRCLKs with 1 setup BRCLK. There appears to be a modulo 4 counter that continuously runs, clocked off BRCLK. The read sequence is delayed after it starts 1, 2, or 3 extra BRCLKs depending on the value of this counter. I have confirmed this behaviour by recording the start cycle of many UV201 reads and comparing them. When I wrote down the start MCLK cycle of each read and divided it by 8 (to get BRCLKs) then modulo'ed by 4, the results are clear: 0: 9 BRCLKs 1: 8 BRCLKs 2: 7 BRCLKs 3: 6 BRCLKs This is fairly definitive proof of a divide by 4 effect going on. When HBLANK goes high, the divide by 4 contains 3. Most likely what happens is the read sequence will delay at some point while it waits for this divide by 4 to contain 00b or 11b. The usual conditions of the read during a DMA are in effect as before. The only difference is the read is stretched out from 3 BRCLKs to 4, 5, 6, or 7. Total number of BRCLKs will be 5, 6, 7, 8 (no DMA) and 9 or 10 is possible with DMA. --- UV201 writes: These follow the exact same conditions as UV201 reads, above. --- RAM writes: These follow the exact same conditions as cart/RAM reads, above. --- So the above is the "ideal". What happens on the real console, however is slightly different because of propagation delays. When running the system 28x slower than normal speed, the CPU actually is halted less (even though the CPU clock is also derived from this same 1MHz clock!) The reason is due to propagation delays. The amount of time the CPU spends halted during normal operation at normal operating speed is as follows: Total "sunk cost" for my particular Videobrain are as follows: CPUCLKs UV201R/W during DMA 4.0 (4 BRCLKs) 4.5 X X (5 BRCLKs) 5.0 X X (5 BRCLKs) mine alternated between 4.5 and 5.0 5.5 X X (6 BRCLKs) 6.0 X X (7 BRCLKs) 6.5 X X (8 BRCLKs) 7.0 X (9 or 10 BRCLKs) (the MCLK values were from falling edge of the last CPUCLK to falling edge of the first after the halt, so values shown are minus 1 CPUCLK.) The above is approximately correct. The amounts vary by 1/2 clock depending on exact synchronization, and they will change plus or minus 1/2 clock on a normal system due to the difference in frequency of the 2.0MHz CPUCLK and the 14.318MHz UV202 clock. This means cycle counted code is not possible on the Videobrain, due to the random nature of the possible wait states. Every frame, the amount of waiting will be different due to alignment of the two clocks and code relative to these clocks. Temperature and voltage variances, phase of the moon, etc. will conspire to make sure that these timings will never, ever perfectly line up from one run of a program to the next. Total "sunk cost" for RAM/cart reads and writes is 4.0 CPUCLKs, and during DMA, the total increases in line with the above chart. This pretty much sums up Videobrain wait states to my satisfaction. There's not much more to it. --- 01234567890123456789012345678901234567890123456789012345678901234567890123456789