intvnut

Could you clarify what you mean? What exactly did you do, and what did you see? More to the point, is it something we could try to trigger on a real Intellivision from the CPU? I'm thinking: use non-interruptible instructions to control when the CPU asserts BUSAK*. We should have control within 2 ø2 clocks. Ah, I think I get it: Because SR3 arrives every 8 ø2 cycles 4 ø2 cycles during the BACKTAB portion of the scanline, then counting to 9 ø2 cycles w/out SR3 would "filter out" the early BUSAK*. That doesn't seem like it was designed. That seems like it was hacked in when they realized they had a problem. [Edited to say 4, not 8 ø2 cycles. It's 8 pixel-clock cycles. That makes me wonder why they need to count to 9?] I guess I had tacitly assumed this detail. BTW, can you confirm that ADAR behaves exactly like BAR, even for addresses in $0200 - $035F? Based on what we've observed on real hardware, you can not execute direct-mode instructions from the RA-3-9600. The CP-1600 uses the ADAR bus phase as a combination DTB + BAR. The currently addressed device puts its data on the bus (the DTB part), and all devices latch this as the next address (the BAR part). It looks like RA-3-9600 only does the BAR part of this. CP-1600 direct mode instructions use ADAR to latch the direct address into all of the memories. If you execute a direct-mode instruction on the RA-3-9600, because it doesn't do the DTB part, the memory access ends up going to whatever float-value was on the bus (usu. $FFFF). Does the RAM respond on $0360 - $03FF, or just $0200 - $035F? On the RA-3-9600A, we've seen garbage values, but on RA-3-9600 and RA-3-9600-1, we see dead air. For the RA-3-9600A garbage values: They're mostly but not entirely static. That is, I see a random bit pattern where some of the bits "flicker." Each device has a different random pattern. The rest of the address map—$0000 - $007F, $3000 - $3FFF—matches what I expect. BTW, on the real Intellivision, GROM locations $3040 - $307F are visible at $0040 - $007F, from what I recall. That somewhat makes sense if the STIC chooses what addresses to assert BAR' / DTB' for, but it doesn't entirely jibe with the RO-3-9503 docs. I'm able to decode some structures but not others. I don't have the patience or time to trace out a lot of the poly and metal. But, you can still get a good sense of the structure often times even without fully decoding it. I found a die shot of the SP0250, the predecessor to the SP0256. It was designed around the same time as the RA-3-9600, and should use similar techniques and have similar constraints. It has an 8-bit ⨉ 15-entry parameter FIFO Looking at its die shot, I believe that really is implemented as a shift register. If you look closely, there are 15 columns grouped into 8 horizontal structures. Looking even closer at one of these: And the corresponding region after the metal was removed with acid: Data flows from left to right. These photos are unfortunately not high enough res for me to completely make everything out. But basically, this looks like a pair of 15-bit shift registers, one of which has a recirculate path from front to back, and the other which has a recirculate from each bit to itself. This makes sense, as it appears the SP0250 double buffers its input FIFO, so it can replay the coefficients during speech generation while accepting a new pair of coefficients. Along the bottom is the input FIFO. There are two non-overlapping clock lines that run as a pair. These control pass-transistors (the little bumps along the clock lines) that feed inverters. The circuit appears to be a standard NMOS dynamic shift register like this: A dynamic shift register relies on the node capacitance of the subsequent gate to hold the bit value. It can't hold it forever, since eventually the charge will leak away. Therefore, the shift register needs to keep shifting. That explains the third line in the lower half that also has pass transistors. This is most likely a "local recirculate" that couples the output of each shift register stage back to its own input. That would provide a refresh capability for when the lower shift register isn't shifting. The lower shift register only shifts when the outside processor loads data, and when the next speech frame begins. These shifts might be distant in time, so refresh is necessary. The top half is the mirror image of the bottom, minus the refresh line. In its place is a line which connects the right edge to the left, which I guess acts as a recirculate from 14 back to 0. It makes sense the upper half wouldn't need to refresh each bit locally, as the speech core will continually cycle all the bits. The missing refresh circulate also explains why the load transistors are laid out slightly differently. Thus, if I understood this FIFO structure correctly, its total capacity is actually 16 bits bit ⨉ 15-entries = 240 bits. It takes up a significant amount of die area relative to the whole chip. So what does all this have to do with the RA-3-9600? It's a really long winded, data-driven way for me to say: Yes, @ChildOfCv, I think it's quite possible and probably very likely that the RA-3-9600 uses an actual dynamic shift register for the line buffer. The line buffer on the RA-3-9600 is 14 bits ⨉ 20 entries. It would be a little shorter top to bottom, and almost 1/3rd wider. It wouldn't need the refresh line, but it would need the recirculate line. The logic at the right end would be different, but comparable in size. That's still pretty huge, but also still quite livable. Imagine taking a 8K-bit RAM (512 ⨉ 16-bit), chopping off the upper rows of the RAM cell, and plopping in this pricey FIFO and some control logic and an extra set of bus drivers. Et voila! You have an RA-3-9600. 352 is 68.75% of 512. So, if you started with a 512-word RAM and displaced about 30% of its RAM area with the FIFO and control logic, that sounds plausible. And judging from the SP0250, if the RA-3-9600's die is comparable in size, 30% sounds about right. (One last note on the SP0250: the rest of the chip has a huge shift register delay line at the upper right. It uses a different aspect-ratio design that takes advantage of not needing a reset input. It follows the same principle of using inverters connected by pass gates, with two-phase clocks. I used a higher-res photo of the SP0256 to understand how it worked, so I could verify the structures on the SP0250 FIFO matched the general structure, even if I couldn't make out all of the detail in the SP0250 photo. If you'd like me to trace out a shift register stage for you in more detail, to show where the gate, drain, source are on the NMOS, and where the load transistor is, let me know.) Now I wish I could find an 8K-bit RAM from the same era to compare with.

It's possible that the RA-3-9600 does not switch into isolation mode fully without an SR3 pulse, provided the STIC itself stops decoding the CPU's bus phases into BAR', DTB', and DWS'. BUSAK* would keep the CPU off the STIC bus during the object fetches. As long as the STIC doesn't CPU bus phases any longer, then the CPU would not be able to see GRAM and GROM. That's sufficient to match my observations from software. Foreground object position and attributes are stored entirely within the STIC. The only data the STIC fetches is GRAM/GROM data. No foreground object data comes from the RA-3-9600 or anything on the CPU side of the world. That's true in a logical sense. It could also be implemented as register file with circular indexing, like the SPB640's FIFO. (diagram from page 34 here: http://papaintellivision.com/pdfs/CCF10232011_00021.pdf) The speech FIFO is a 64 x 10 structure (640 bits), with circular read/write pointers. It only has a shift register for the 10 bits at the output. The RA-3-9600 line buffer is 280 bits, so less than half the size, but it seems likely they might use a register file here. Then again, the SP0256 is a giant 156 bit linear shift register, effectively... If it's a literal shift register, then they will need to couple the output back to the input. Granted, when it's loaded initially, the RAM itself is coupled to the output, so the input to the line buffer (whether it's a shift register or a register file) is always coupled to the output bus. I don't think we can tell, short of decapping the chip and observing the die, which implementation method was used, provided the read/write pointer is a strict 0 - 19 circular counter. BTW, lots of decap'd chip pics here if you're bored. I like to look at GI's other chips to get a sense of their design style, since they have some commonalities. I wonder if we can talk Sean Riddle (whose blog that is) into decapping the CP1600, RA-3-9600, and STIC. 🙂 I don't see how that would allow for BUSAK* arriving before you've finished the previous scanline of a row of cards. I think you still need a mod 20 counter. Whenever I force the CPU to delay BUSAK* with non-interruptible instructions, the only behavior I ever see is that the same row of 20 cards gets repeated exactly if I delay it too long. I never see a different effect, such as shifting to the left by some number of cards. There's no MSYNC* input to the RA-3-9600, so there isn't really a way for it to know if we're in TS2 or TS4. But, the design may expect certain signals to be held for some number of ø cycles to allow an internal state machine to do evaluate and writeback in separate clocks. I think that goes hand-in-hand with the fact you needed ø2 to make RAM accesses work from the CPU side, if I remember right. It almost feels like there's a dynamically refreshed structure in here, rather than truly static RAM. You usually don't need a clock on an asynchronous memory unless it's a DRAM. I guess one way to find out is to fill the memory from the CPU side, don't clock ø2 for a long time (like, say, a full second or maybe several seconds), and then see if you can still read the data out. If nothing else, its possible there's some state machines that need ø cycles to coordinate actions. Maybe it's just multiplexing some internal buses. Space is tight in these old 1970s chips.

Yes, it does. Since BUSRQ* goes low one scanline early and only one scanline early, perhaps the logic is as simple as: the line buffer index must wrap from 19 to 0 while BUSAK* is low to move to the next row of cards. That actually makes a lot of sense. That would also make it easy to support different numbers of scanlines, such as the planned STIC revision for the PAL market that would stretch the image vertically (presumably by repeating every 5th or 6th scanline, or something like that). The STIC controls the LSBs of the GRAM/GROM addresses, so the RA-3-9600 wouldn't need to change in that case.

This is embarrassing. I had BUSRQ* going low one scanline too soon. I had numbered my spreadsheet 1 to 16 rather than 0 to 15, and that threw me off. BUSRQ* goes low one scanline early, not two, and is low for about 2 scanlines, not 3. I've corrected the first portion of the spreadsheet. Nothing else has changed. And, as always, you can see whatever the latest is at this link.

tl;dr version of everything below: I think you're seeing it backwards. BUSAK* can be asserted long before we've finished displaying all 16 scanlines of the previous row of background cards. It's the BUSAK* that's early, not the SR3 pulses. This implies that RA-3-9600 is a card counter, so to speak. Is this an arbitrary row of cards in the middle of the screen, or the very first row? If it's in the middle of the screen—which I expect it is—those pulses are for replay scanlines. The waveform looks entirely as expected to me. I am convinced the RA-3-9600 keeps a pair of counters, one that counts cards in a line, and one that counts scanlines between line buffer reloads. BUSAK* can go low almost two scanlines before we fetch the next line of cards from BACKTAB, while we're replaying the previous line. That's what my spreadsheet was meant to capture. I flubbed the ø2 because I wasn't focused on that as closely as I should have been. Mainly, I wanted to highlight that BUSAK* alone doesn't advance us to the next row of cards. There must be some additional internal state in the RA-3-9600. Here's is my mental model of how INTRM, SR3, and BUSAK work. I'll give some names to things that I've selected for convenience. Some names are based on what I see in the datasheets/specs or programmer docs. Internal state: backtab[240]: 240 memory locations comprising the background display. backidx: 8 bits, index into BACKTAB for loading the line buffer. linebuf[20]: 20 element line buffer used to replay scanlines 1 to 15. lineidx: 5 bits, counts 0 to 19 and repeats. Next card to display in the current scanline. scancnt: 4 bits, counts 0 to 15 and repeats. Counts which scanline we're on. Scanline 0 is the scanline that loads the FIFO, while 1 to 15 replay the same line already loaded. fetchact: When false, we're replaying cards from the line buffer. When true, we're fetching new cards from BACKTAB into the line buffer. dispact: When false, we're in CPU-controlled mode. When true, we're generating active display. State transitions: Upon observing INTAK: dispact = false, backidx = 0, lineidx = 0, scancnt = 0. TBD: Rising or falling edge? One or more pulses of ø2 required during INTAK? When dispact == false: (Implicitly, BUSAK* is high.) RA-3-9600 copies DB to SD. CPU's DTB reverses bus direction. SR3 acts an enable for SD bus, asserted during BAR, ADAR, and DWS. STIC's BAR' latches CPU address. STIC's DTB' performs a prefetch read during CPU's NACT (SR3 low). STIC's DWS' captures write data from CPU on during CPU's DWS bus phase. (Note: SR3, DTB', and DWS' asserted during CPU's DWS.) On falling edge of BUSAK*: Set dispact = true. This is required to allow foreground object fetches (MOBs, sprites) on scanline 258. ( @kevtris's Xcount = 258, Ycount = 162) This must happen, otherwise the CPU could interfere with those object fetches. When BUSAK* low and scancnt == 0 and cardcnt == 0: Set fetchact = true. This starts a fetch of new cards from BACKTAB. When dispact == true, irrespective of BUSAK*: When SR3 goes high and fetchact == true: copy backtab[backidx++] to both linebuf[lineidx++] and SD pins. When SR3 goes high and fetchact == false: copy linebuf[lineidx++] to SD pins. When lineidx wraps from 19 to 0: Increment scancnt, wrapping from 15 to 0 when necessary. Based on updated scancnt, set fetchact = (scancnt == 0 && BUSAK* == 0). That is, set fetctact = false, unless the scancnt is 0 and BUSAK* is low, in which case set fetchact = true. Unknowns: What role ø2 timing plays in each of these steps. It seems to play a role in some steps. To what degree ø2's phase matters relative SR3's rising and falling edges. Whether certain actions, such as pointer increments, happen in response to an edge on ø2 or a particular edge of SR3. For example, the actual increment steps above may occur relative to ø2, or on the falling edge of SR3. The key idea here I'm trying to convey: The combination of BUSAK* low, scancnt == 0, lineidx == 0 is what determines whether we start fetching new cards from BACKTAB, or we replay the previous cards. If all three conditions aren't met, we will keep replaying the same linebuffer contents rather than fetching new linebuffer contents. This allows BUSAK* to go low arbitrarily early relative to playing out the scanlines. The CPU can take a long time to halt, due to non-interruptible instruction sequences, which is why BUSRQ* goes out so early, and why BUSAK* can come in so early. This also implies you need a minimum of 240 * 16 = 3840 SR3 pulses to read out the entire BACKTAB, no matter what.

I realized after I typed up @kevtris's notes that we do actually have a little more information on where BUSRQ* goes low and high than I realized. I was focused more on SR3 and less on BUSRQ*. I've updated the spreadsheet with more precise information on BUSRQ*. One outcome is that BUSAK* should go high before the first "replay" of a newly fetched row of cards when I move the BUSRQ* deassert earlier. I don't know if that ends up being material or not. The CP1610 has a minimum 9 T-state delay (4.5 ø clocks) before releasing BUSAK*, since it always samples on TS1, and always releases on the third subsequent TS2, based on this waveform from the CP1600 Microprocessor User's Manual. A given ø2 high pulse is either TS2 or TS4, so there's only two possible places the CPU could release relative to BUSRQ* deassertion. Let me know what you think. (And as always, click to enlarge.)

I don't know what that link is about, but I concur it doesn't look like much. I know @kevtris does have a complete FPGA implementation, since 2011. I've been relying on his notes. I did get permission to post his notes on signal timing. I've edited his notes for clarity and conciseness. I hope he doesn't mind. Cycle counts below are all at the STIC 3.579545MHz rate. Definitions: X counter that counts 0 - 227 at 3.579MHz. (Corresponds to pixels.) Y counter that counts 0 - 261. (Corresponds to scanlines.) Scanline timing of the STIC: Card fetches, cycles 0 - 159. 20 GRAM/GROM accesses per scanline. Each access takes 8 cycles, including BAR' and DTB'. The data is then shifted out 1 pixel at a time at the 3.579MHz clock rate. Thus, first portion of scanline is 160 clocks composed of 20 card fetches. After the 20 card fetches there are 2 idle cycles. (cycles 160, 161) Object fetches, cycles 162 - 225. (64 cycles) One fetch per object. 8 cycles per fetch. Object fetches "look just like the card fetches."* After the object fetches there are 2 idle cycles (cycles 226, 227). Objects are fetched at the end of the previous scanline in this nomenclature. You could also consider object fetch to be start of the scanline, in which case you need to shift all the numbering accordingly. Objects are loaded into shift registers, ready to be rendered during the following scanline. Frame structure: (Note, scanline 0 is defined as the first visible scanline of pixels, in Kevtris' numbering.) 0 - 191: Rendering. The screen is rendered for 192 scanlines. 192 - 215: Bottom border. 216 - 235: Blanking. Vsynch is on scanlines 219 - 221. 236 - 261: Top border. "The real hardware most likely does it vastly different than this, but again since frames are cyclical it makes no difference where we start counting. If I had to guess, the Ycount = 0 point is most likely 7 pixels above the first rendered scanline, because the sprite Y positions would then be easier to calculate." Major event details, by scanline number: Scanline 192: SR1 goes active on Xcount = 210 and Ycount = 192, near the end of the first scanline into the border. Speculation: This allows the STIC time to compute object collisions for the bottom border. This also explains why the bottom border is 1 scanline thick. Kevtris did not measure when SR1 goes inactive. Scanline 258: SR2: The first bus request (SR2) occurs at Xcount = 146, Ycount = 258, and is canceled at Xcount = 146, Ycount = 259. "This resets the RAM's FIFO to get it ready for rendering the first scanline." The sprite engine is started for the first time. "Sprite engine" means the object fetches at Xcount = 162 onward. Scanline 259: Sprites start being processed, 3 scanlines before rendering occurs. Scanline 260: The first true bus request occurs at Xcount = 227, Ycount = 260 to load in the first row of cards into the FIFO. Scanline 261: An idle scanline to allow the CPU time to halt. Scanline 0: Rendering starts. STIC displays first scanline worth of cards and fills the FIFO. At Xcount = 211, Ycount = 0, it cancels the bus request. Scanlines 1 - 14: Render the display, replaying cards from the FIFO. Scanline 15 - 16: Similar to scanlines 261 and 0 above, except that STIC is also still rendering the first row of cards. Scanlines 17 - 190: Repeat of the above every 16 scanlines. At Xcount = 227, Ycount = 190, SR2 goes active again to read the next (nonexistent) row of cards, as usual. Scanline 191: Similar to scanline 261, 15, etc. However, at Xcount = 211, Ycount = 191, STIC deasserts SR2. * Note: I am certain the object fetches do not assert SR3, and Kevtris mainly refers to the overall 8-cycle timing pattern and using BAR', DTB'. This would be consistent with GI's waveform.

Ok, I think I've corrected it now. I got interrupted earlier while I was putting it together, and I totally whiffed it on the ø2. How embarrassing. I had meant to do something different with the clock and forgot to fix it. Now each spreadsheet square is one NTSC pixel.

I should have drawn my ø2 differently in the spreadsheet. If you look at the waveform I copied from the PDF, SR3 goes high with the falling edge of ø1, just ahead of the rising edge of ø2. SR3 goes low with the falling edge of the next ø2. Looking at it more closely, I think I just drew it wrong and then copy/pasted the mistake. Let me correct it. In the meantime, trust the scanned waveform. The timing looks a bit different on a CPU write. The BAR ⇒ SR3/BAR' conversion has BAR' going high with SR3 (rather than one STIC cycle later), but SR3 has the same timing. The DW/DWS ⇒ SR3/DWS', however, holds SR3 high one STIC clock longer (4 STIC clocks, or 2 ø2 clocks). For DW/DWS, SR3 rises with the rising edge of the first ø2, and falls with the rising edge of the third ø2. See this waveform on page 134: STIC output pixels are ~280ns wide (one 3.579545MHz cycle). All pixels are the same size. Each card gets exactly 8 STIC cycles (4 ø2 cycles) at that rate. Card fetches are back to back. The cycle sequence is, in terms of STIC clock cycles (~280ns, twice the rate of ø2 cycles) for one line is as follows, from what I can tell: 160 cycles back-to-back card fetches, 8 cycles per card. SR3 high for cycles 0, 1, 2. BAR' high for cycles 1, 2 DTB' high for cycle 3, 4, 5, 6. Nothing on cycle 7. 2 dead cycles 64 cycles back-to-back object fetches, 8 cycles per object. Same timing as above, without SR3 asserted. 2 dead cycles That's the sequence observed from the actual STIC by Kevtris, although he didn't give the exact breakdown for how long SR3, BAR', DTB' were high. I pulled that from GI's spec. The top-level bullets come from Kevtris. In terms of ø2 clocks, divide those numbers in half. The object fetches occur during horizontal border / horizontal retrace, so the active field is 159 out of the 228 cycles in the scanline. (The 160th column of BACKTAB is blanked.) The scanline period is 3579545 / 228 ≈ 15700 Hz. What that also means is that the BACKTAB is only 44.7µs wide, out of the ~52.6µs active video period. The total STIC scanline is 63.7µs—slightly longer than NTSC's prescribed 63.5µs. I'm getting the 52.6µs and 63.5µs numbers from this: If I did my math right, that means the video portion of the signal is 188 pixels wide, and the BACKTAB cards occupy 159 of those pixels. The other 29 pixels are border colored. The remaining 40 pixels are horizontal retrace. Also, according to the math, the STIC's scanline is actually 63.7µs, so it's slightly too long. The actual scanline length is supposed to be 227.5 periods of 3.579545MHz according to this, but STIC outputs 228. It's also supposed to be interlaced, achieved by sending a half-line at the end of each field, and the STIC doesn't do that either.

OK, so here's something to keep in mind: The STIC asserts SR2 (BUSRQ*) two full scanlines before it needs new card data. The CPU responds sometime before the critical point where the STIC needs to start fetching new data. This implies that the RA-3-9600 is keeping a replay counter of some form, to switch to a new row of cards only every 16th scanline. Below is a waveform I drew from information I gathered from the spec linked above, as well as the CP-1600 Microprocessor User's Manual, and a couple more details from Kevtris. The waveform is actually in a Google Docs Spreadsheet. It might be easier to follow there. If you want comment access on the spreadsheet, PM a Google account and I can share the doc. I didn't want to share comment access with the whole Internet. This is how I understand it's supposed to work. I haven't actually put this on a scope. It may explain, though, why the RA-3-9600 doesn't advance between rows when you expect. The purple shaded areas are where I compressed time. The main thing to note is that BUSAK* alone can't be what triggers the RA-3-9600 to advance to the next row of cards, since its timing relative to the scanline is very flexible, and it can come up to two scanlines early. From Kevtris' notes: Each scanline is 228 STIC clock cycles long (114 ø2 cycles, or 57 CPU microcycles) 160 STIC clock cycles to fetch 20 cards. (80 ø2 cycles) 2 STIC clock cycles dead time. (1 ø2 cycle) 64 STIC clock cycles object fetch time. (32 ø2 cycles) 2 STIC clock cycles dead time. (1 ø2 cycle) From the STIC spec, I referred to this waveform on page 135 for a SR3 fetch cycle. The data from the RA-3-9600 serves as the address for BAR' on the GROM and GRAM. "Valid Descriptor" is the SD bus on the RA-3-9600. "For background" refers to BACKTAB fetches. "For foreground" refers to object fetches. SR3 is not used for object fetches.

My statement only applies to the game ending. The original game ending falls into an infinite loop, as opposed to following the usual EXEC convention of returning to the EXEC. If I'm not mistaken, the net result is that the EXEC won't blank the display after a sufficient idle period in the first version. Someone will have to check for me, since I don't have the time to play a game right now. The EXEC is structured primarily as a series of callbacks into your game. You set up timer processes, object dispatches, etc. that get called by the EXEC as appropriate. Auto Racing is no exception. It does most of its work on one or two timer driven tasks. (2 for intuitive/directional, 1 for realistic-only. The latter merged the two.) The EXEC's default model expects most game code—basically anything outside a replacement interrupt handler—to run in a "dispatch context." EXEC calls that block effectively implement a yield by "returning to your caller's caller," making it even funkier. For example, if you call the EXEC for numeric input from a keypad, you're really yielding, and falling back into the EXEC idle loop. For example: Decimal input blocks until the user inputs a number. When you call it, it sets up a special controller dispatch to collect digits, and "returns to caller's caller" to fall into the EXEC idle loop. As the player types digits, the keypad dispatch collects them. Once the keypad dispatch sees "ENTER", it "returns" to you by clearing the special controller dispatch and branching after the original call site. (Again, still in a "dispatch" context.) It steals one interrupt every tick. So, at the fastest speed setting (DISC), it drops to 15Hz. The game speed in location $103 is the same (3), but the game itself steals an interrupt from the EXEC by rewriting the vector at $100-$101 every tick, for one interrupt.

I'm not sure I answered this: jzIntv already has a PAL palette and has had one for awhile. It selects this palette when you launch jzIntv in PAL mode. (--pal)

I suspected these were Intellivoice-era PCBs. I thought they looked familiar. Nearly all of my bare PCBs are packed away somewhere, and there's a precious lack of photos of them online. (At least, that Google Image Search can find.) Yours matches the one on the right in BSRSteve's original post. Notice the tiny hole near pins 3 & 4, another tiny hole in the upper right, and the logo in the upper left. I wonder what the significance of 3883 (BSRSteve's) vs. 3884 (mr_me's) stamped on these is? I think that's what mine had as well. All of my loose, bare PCBs are packed away in a storage unit, unfortunately. Or 8K + 16K, I suppose. e.g. one non-paged ROM for 5/6/D/E, and one paged ROM for F:0/F:1. 12K + 12K is more likely of course.

I wonder if that was for 6K games (3 x 2K), or 12K games (3 x 4K), or some other configuration? I suppose with 3 8K ROMs, you could go to 24K I'm going to go with 12K - 24K given the date, and the fact that the Intellivoice-related pins on the component side are not grounded. In any case, it looks like it's still designed for the standard original-layout Mattel shells—the kind that take screws. Point of comparison: Here's a World Series Major League Baseball board that has some similarities (including the grounding capacitor pad pattern to one side), but doesn't have the same set of notches, or the two holes at the top. I guess WSMLB had two 12K ROMs? This is 2610-4219, so perhaps a follow-on to 2610-3219 for 3-chip games?

If you had the "intuitive / screen-directional" steering version, the tall grass slows your vehicle down by a lot less than the "realistic steering" version does. Also, in the regular game, that grass looks the same as any other grass. I just have it shaded to make it obvious where it exists.

Well, the description of "Mode 1" pretty much says: Unless it's DTB, the RAM copies from CPU toward STIC. That said, this figure suggests it should only actually drive the SD (aka. SB) side when SR3 is asserted. This fits with the STIC's "prefetch read" methodology, and with the idea that SR3 serves double-duty as an output enable. The STIC spec backs this up on page 113: What level are you driving SR3 to when you make accesses from the CPU side? Based on what I saw, it should only need to go low for at most one NTSC display scan-line, and probably quite a bit less.

Couple minor additional details: BUSRQ goes low a couple scanlines before the STIC needs the CPU to assert BUSAK. That means the BUSAK could come up to 2 scanlines early. (I forgot about that!) This further implies that the RA-3-9600 actually keeps count of scanlines to a degree, perhaps a simple 0-15 counter. The whole-line-jumping behavior I have observed is probably due to suppressing the "start next row fetch" state machine when the scanline 0-15 counter wraps, but BUSAK isn't asserted. Kevtris' notes confirm the "short BUSRQ." It goes low for precisely one scanline with no SR3 pulses.

Not that I know of.

Necro-bump: IIRC, SDBD + MVI performs a mix of MVI + SDBD MVII. From what I remember @Carl Mueller Jr said, it's something like this: Opcode sequence is 4 words: SDBD; MVI; <address>; <data> Result: Reads lower byte at <address> into lower byte of target register (like MVI). Reads lower byte of <data> into upper byte of target register (like second part of SDBD MVII). I still haven't implemented this in jzIntv, FWIW. If I had to guess at a cycle count, it's probably 17 cycles total for SDBD + MVI.

Another weird timing behavior I observed:

The CPU can always read the STIC side of the data bus, even during active display. If the CPU reads from the STIC address range (either $0000 - $007F or $3000 - $3FFF), it will see whatever's going on on the STIC bus at that moment. The real test is whether the CPU can write to the STIC side of the data bus after that first BUSAK. Isolation only means that RA-3-9600 won't reverse its bus drivers to let the CPU side drive the STIC side. That does not match my observations. If this depended on issuing an actual DMA request (pulsing SR3), then the bus-copy time would depend on the vertical offset register setting. In all my measurements, it does not. This is consistent with the first SR2/BUSAK coming at the very start of the active field, even though character fetches are delayed by the vertical offset register. In contrast, it does vary with the vertical delay register on the TutorVision! The TutorVision only issues 12 BUSRQs, and doesn't have this short BUSRQ. The TutorVision doesn't use the AY-3-8900 and RA-3-9600, though. It's rather different hardware built around a custom ASIC. There are lots of weird timing issues with the RA-3-9600 in a real system. I discovered a way to get weird artifacts along the left edge of the screen, that seem to be due to some residual charge. They're easy to reproduce if I power off my Intellivision for several minutes. They fade away over time. I took the video several years ago. IIRC, this required pushing the CPU's BUSAK fairly late relative to when the STIC started its fetch. VID_20140725_013952.mp4 One of the things I've noticed over the years: If the CPU doesn't BUSAK soon enough, the display will jump. It always jumps by a full row of cards. It's never just a one card shift. So, I think the RA-3-9600 might only increment the row if the circular buffer pointer is at zero? (e.g. exactly 20 clocks of SR3 while BUSAK is low.) Observed behavior. It's also hinted at in the STIC specification and RA-3-9600 specification I linked to, as well as the official published data sheets. I admit, though, it's a bit like reading tea leaves and entrails to divine the meaning fully from the text. First, the mention of that "SR2 is issued 13 or 14 times per picture:" (p113) "The Vertical Retrace Period extends [...] unil a period two lines before the restart of the active picture." (p126) Both SR1/SR2 waveforms show 13 SR2 pulses (p136 in the STIC spec; p70 in the RA-3-9600 spec): I've experimented with overrunning the first BUSRQ in the past (so that BUSAK didn't get signaled). IIRC, the result was garbage in the first couple scanlines from CPU writes, but the display didn't jump. I think this matches your data that the extra short pulse at the beginning isn't necessary. Several years ago, I did actually examine SR1 and BUSAK on an oscilloscope via the cartridge port. This was probably 20 years ago now. I drew up what I observed in this diagram: Notably, that first BUSAK always occurs in the same spot, while the others shift based on the horizontal/vertical offset registers. The 14th BUSAK disappears if you set vertical offset to 1 or larger. The net result is that bus-copy mode is always active for a fixed amount of time. Somewhere, I have notes from Kevin Horton (kevtris), who did a much more thorough timing analysis. I meant to say "go slower than that."

When I analyzed the ROM images, I came to the same conclusion. Lots of posts starting about here: Lots of low level tidbits here: Evidence that the Real Steering Only version is newer: Splash sound effect when hitting water. More sophisticated handling for driving out of water. Two grass "depths" that actually work. (Support is in both versions, but it works more effectively in the Real Steering Only version.) More responsive/sophisticated controller input handling. The "real steering" hidden in the Intuitive/Directional dual-mode version was more primitive. Game ending re-enables the EXEC event loop (and therefore allows the screen to blank when idle). Dead code in the Real Steering Only version left over from the Intuitive/Directional version. Generally more optimized, clever code sequences. At least the part about a row with no trees has been confirmed. (The checkerboard bits are "tall grass", exposed by a ROM patch.)

Actually, pages 133 - 134 look even more useful for bus-copy reads and writes: And for STIC reads via SR3, page 135: It's also worth noting the RA-3-9600 does have a clock input. This is atypical for a RAM, but probably necessary for this RAM. The datasheet does list a minimum clock period, although you can probably go closer than that. I know that the STIC will lose many register settings if it doesn't see INTAK regularly. I imagine the clock input here may drive some internal refresh signals as well, or perhaps qualify certain signals' validity.

You need an INTAK to switch the RA-3-9600 from isolation to copy mode. The first BUSAK will switch it back to isolation mode. INTAK I believe also resets the internal BACKTAB pointer back to $200. INTAK is BC1 = 1, BC2 = 1, BDIR = 1. The STIC issues 13 or 14 BUSRQs per frame, resulting in a corresponding number of BUSAKs. The first BUSRQ/BUSAK is not accompanied by any pulses on SR3. The STIC issues this BUSRQ at the start of active display during the portion of the field hidden off the top of the screen. (This portion is exposed by setting the vertical delay register for vertical scrolling.) The second BUSRQ/BUSAK should do the trick. While that's held, you should be able to shift out the next 20 cards. BTW, the only other real spec I have for the RA-3-9600 is in this procurement specification on PapaIntellivision: http://papaintellivision.com/pdfs/CCF10232011_00012.pdf Pages 64 - 74 describe the RA-3-9600 and RA-3-9600 - 1. Pages 69 - 70 have some relevant waveforms for you. Page 111 - 138 describe the AY-3-8900-1 STIC. Pages 133 - 136 include some relevant waveforms. Here's a waveform showing that INTAK is necessary, from page 70. Note "CPU Interrupt Response" and the "Graphics Counter Reset." The interrupt response engages the reset, and the first BUSAK releases it. Also, the text mentions the STIC bus tri-states® (goes to high impedance) when SR3 is low. The graphic counter reset is important: When the RA-3-9600 is in bus-copy mode, the STIC apparently decodes DTB to drive SR3. See page 69: This means that the meaning of SR3 changes depending on whether you're in CPU-controlled or STIC-controlled modes. That also should give you some idea how to test bus-copy mode. ---- TRI-STATE® is a registered trademark of Texas Instruments (formerly National Semiconductor).

Going through more of my old mail, Decle had outlined it for me, and pointed to the docs. Page 33 of http://papaintellivision.com/pdfs/CCF10232011_00020.pdf It seems there isn't a Mattel term for the 37-bit structure. But a group of 15 of them is a chunk, and a group of chunks is a record. If we have to pick a really descriptive term, how about bitplane word?