RA-3-9600 technical specs?

[intvnut]

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.  

 

[ChildOfCv]

I took your advice and pretended that BUSAK went low at the end of the active display instead of just before loading cards.  So then there were 114-80 ticks left for the "line" without pumping SR3.  Then I started pulsing SR3 and the counter finally started going again.  There's still a weird circumstance where read back 0's for some of the cards at random times though.  The number and position are random, but it's always a consecutive block.

 

Now, for the fun of it, I tried making it read more cards without going through 16 scan lines.  Well guess what?  That worked too, though with the same caveat as above.  I tried as few as 2 lines between reloads.  So apparently it's not a scan line counter at least.  That makes it simpler.

 

So apparently, the trigger to load a new set of cards is to have BUSAK come on some number of ticks before the start of the active line.  Now, I know I've done that before without success, but I also wasn't attempting to get a full 114 ticks per line either.  It is possible that that is significant.

 

Of course with such ridiculous BUSAK times that even start before active display on the previous line, it seems like the STIC is stealing a lot more bus cycles than it ought to be.

Edited June 20, 2020 by ChildOfCv

[intvnut]

3 minutes ago, ChildOfCv said:

Now, for the fun of it, I tried making it read more cards without going through 16 scan lines.  Well guess what?  That worked too, though with the same caveat as above.  I tried as few as 2 lines between reloads.  So apparently it's not a scan line counter at least.  That makes it simpler.

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.

[ChildOfCv]

1 hour ago, intvnut said:

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

You're likely right about the backidx.  Backtab is simply the RAM though.  backidx is used as the RAM address when it digs up a new value for the next card.

 

linebuf is actually described as a shift register.  When SR3 falls, the shift register pushes every value into the next register.  The last register pushes back into the first.  The difference is that when it's set to pull in new values, the second register takes its value from memory instead of from the first register.  Also, the output is that memory instead of the first register.  This is easy to implement in silicon and doesn't require a counter.  I bet if I only pulled 19 cards at a time, it would still work "correctly" other than only advancing by 19 registers with each round of card pulls.

1 hour ago, intvnut said:

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

This probably doesn't exist, as noted in my previous observations.  Instead it looks like the trigger for advancing cards is a long period of clock pulses with no SR3 pulses.  It's undetermined as of yet whether this also requires a multiple of 114 ticks.

1 hour ago, intvnut said:

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

Yep, I believe those exist.

1 hour ago, intvnut said:

• 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?

It may not be necessary to do a full CPU cycle for it to see an INTAK.  It may be good enough to see INTAK on a positive ø2.  At least, that would make the electronics simpler.  I also doubt that the memory is on the same 4-cycle clock as the CPU anyway.  If it were, it would need some synchronization circuits to ensure that it's on the same schedule that the CPU is.

1 hour ago, intvnut said:

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

It takes more than a falling edge though.  It probably takes some number of cycles of ø2 before it latches into dispact.  Maybe even SR3 pulses.  I have not been able to make it change mode without completing at least one card draw.  BUSAK does at least leave the CPU out of the equation though, since it is obviously waiting idle while it holds BUSAK.  But this probably does not mean that the foreground fetches require dispact mode.  Does it get MOB data from GRAM or from the SRAM chip?  If it's the latter, then the only way I can see that happening is if the STIC does a memory read on the CPU bus side.  As far as I can tell, there is no random access to the SRAM on the STIC bus side.

 

1 hour ago, intvnut said:

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

ø2 is not needed at all for passthrough in CPU mode.  I set my passthrough test to use delays instead of ø2 toggles, and it just mirrored DB->SD.  However, ø2 is an integral part of shifting modes, as well as in getting the card fetch going again.

 

The manual says that the card shift happens on the falling edge of SR3, but of course we don't know for sure that the manual is correct.  It could have been a design parameter that turned out not to work out.

[intvnut]

2 minutes ago, ChildOfCv said:

It takes more than a falling edge though.  It probably takes some number of cycles of ø2 before it latches into dispact.  Maybe even SR3 pulses.  I have not been able to make it change mode without completing at least one card draw.  BUSAK does at least leave the CPU out of the equation though, since it is obviously waiting idle while it holds BUSAK.  But this probably does not mean that the foreground fetches require dispact mode.  

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.

5 minutes ago, ChildOfCv said:

Does it get MOB data from GRAM or from the SRAM chip?  If it's the latter, then the only way I can see that happening is if the STIC does a memory read on the CPU bus side.  As far as I can tell, there is no random access to the SRAM on the STIC bus side.

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.

 

6 minutes ago, ChildOfCv said:

linebuf is actually described as a shift register.  When SR3 falls, the shift register pushes every value into the next register.

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

 

26 minutes ago, ChildOfCv said:

This is easy to implement in silicon and doesn't require a counter.  I bet if I only pulled 19 cards at a time, it would still work "correctly" other than only advancing by 19 registers with each round of card pulls.

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.

 

29 minutes ago, ChildOfCv said:

It may not be necessary to do a full CPU cycle for it to see an INTAK.  It may be good enough to see INTAK on a positive ø2.  At least, that would make the electronics simpler.  I also doubt that the memory is on the same 4-cycle clock as the CPU anyway.  If it were, it would need some synchronization circuits to ensure that it's on the same schedule that the CPU is.

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.

 

 

32 minutes ago, ChildOfCv said:

However, ø2 is an integral part of shifting modes, as well as in getting the card fetch going again.

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.

 

[+Lathe26]

1 hour ago, intvnut said:

 

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

 

Side note: If you ever do get a bunch of chips decap'd, add the ECS's glob top chip into the mix as well. 

[ChildOfCv]

I just realized that reverse passthrough (reading the STIC bus from the CPU side) is more complex than sending a DTB command.  Of course, now it seems like it should have been obvious from the start.  You don't want the SRAM forwarding the contents of the STIC bus to the CPU bus every time the RAM sees a DTB, or it would interfere with the other chips too.

 

You must actually send an address to RAM that it will respond to with a BAR, then a DTB to retrieve the STIC bus.  SR3 is not involved.

 

It responds to address 0-0x7f, but not 0x80-0x1ff.  0x200-0x3ff is of course the RAM region.  By the way, I confirmed that ø2 is required to keep RAM.  I decided to forego reprogramming the RAM between runs (no power off since last time it was programmed), and got nothing but 0xffff's back on read.  0x400-0x2fff are no response.  0x3000-0x3fff respond.  0x4000 and up do not.

 

 

Also, the 19-card gambit worked.  So "fetch" mode must be turned on by BUSAK followed by a number of ø2's without SR3's.  That number seems to be 9 according to my experiments.  So the logic seems to be that once BUSAK is enabled, it begins counting ø2's.  SR3 resets that counter.  Once the counter reaches 9, it enables fetch mode.  Fetch mode is reset when BUSAK goes inactive.

[ChildOfCv]

10 hours ago, intvnut said:

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 wish I knew enough to be able to identify and reverse engineer these things.  Even looking at the Visual 6502 I get lost.

[intvnut]

4 hours ago, ChildOfCv said:

Also, the 19-card gambit worked. 

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.

 

4 hours ago, ChildOfCv said:

So "fetch" mode must be turned on by BUSAK followed by a number of ø2's without SR3's.  That number seems to be 9 according to my experiments.  So the logic seems to be that once BUSAK is enabled, it begins counting ø2's.  SR3 resets that counter.  Once the counter reaches 9, it enables fetch mode.  Fetch mode is reset when BUSAK goes inactive.

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?]

 

4 hours ago, ChildOfCv said:

I just realized that reverse passthrough (reading the STIC bus from the CPU side) is more complex than sending a DTB command.  Of course, now it seems like it should have been obvious from the start.  You don't want the SRAM forwarding the contents of the STIC bus to the CPU bus every time the RAM sees a DTB, or it would interfere with the other chips too.

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

 

4 hours ago, ChildOfCv said:

It responds to address 0-0x7f, but not 0x80-0x1ff.  0x200-0x3ff is of course the RAM region.

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.

 

4 hours ago, ChildOfCv said:

I wish I knew enough to be able to identify and reverse engineer these things.  Even looking at the Visual 6502 I get lost.

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.

 

Edited June 20, 2020 by intvnut
change 8 ø2 cycles to 4 ø2 cycles.

[intvnut]

I've updated the waveform spreadsheet with the "minimum ø2 cycles" detail on BUSAK*.

 

[ChildOfCv]

1 hour ago, intvnut said:

Could you clarify what you mean?  What exactly did you do, and what did you see?

What I mean is I only did 19 rotations to load cards, then dropped BUSAK, then did 19 rotations per round of repeat.  The remaining card in this case was 0 from initialization, so the first shift after dropping BUSAK was 0, then a repeat of the first 18.  The second time around was card 19, then the 0 in the 20th, then the next 17 cards.  Since I was still only doing 2 repeat lines, BUSAK returned at that point, 9 ticks, and then it started loading new values into the next 19 cards in the rotation, and so on.  So what I mean is that it didn't need a counter to decide when it was on 0.

[ChildOfCv]

Speaking of decapping, CuriousMarc's channel on YT had a video about some guy (I think from France) who found a fairly easy and mostly successful way to open them up for viewing.  Basically, hold the chip over a hot air gun until the plastic begins to soften, then start biting it apart with needle nose pliers.  At first you'd be pulling the pin frame out, but eventually it should allow the chip die to almost fall out.

 

They did have occasional trouble with the die breaking, but more often than not he got a complete die.  As a hobby the guy doing it has been pulling and photographing the dies of any chip he could find, though the results aren't (or at least weren't) posted publicly.

[ChildOfCv]

1 hour ago, intvnut said:

BTW, can you confirm that ADAR behaves exactly like BAR, even for addresses in $0200 - $035F?

So, from what I understand, ADAR should be equivalent to DTB for the source chip, but every other chip watches for an address in their range.

 

Are you asking me to check whether it latches an ADAR as an input address?  Or that it outputs its data upon receipt of ADAR when it has latched an address in its range?

[intvnut]

2 minutes ago, ChildOfCv said:

So, from what I understand, ADAR should be equivalent to DTB for the source chip, but every other chip watches for an address in their range.

 

Are you asking me to check whether it latches an ADAR as an input address?  Or that it outputs its data upon receipt of ADAR when it has latched an address in its range?

 

ADAR does two things:

• Whatever memory is currently addressed should put its data on the bus, like DTB.
• Every address latch should latch this value as the new address, like BAR.

What I've observed with RA-3-9600 is that it does the BAR part, but not the DTB part.  I know I can read and write System RAM with direct-mode instructions.  For example, MVI $200, R0 works, when executing from a game ROM.  But, if I put a MVI $200, R0 instruction in System RAM and try to execute it from there, that doesn't work.  It behaves more like MVI $FFFF, R0, although I'm not even 100% sure of that.

 

What I expect, given that:

1. If you assert BAR with an address outside $0200 - $035F, followed by ADAR with an address within $0200 - $035F, followed by DTB, you read the corresponding contents of System RAM.  This would match what we see from the CPU.
2. If you assert BAR with an address within $0200 - $035F, followed by ADAR, the System RAM will not drive any data out.
   • An alternate possibility is that it copies SD to DB, which honestly seems unlikely.

So, what I'm more interested in is bullet #2.

 

 

[ChildOfCv]

Yep, it makes no attempt at output with ADAR even after having an address latched in its RAM range.  It doesn't drive the DB output at all.  I just read back the residual from setting the BAR address.

 

In case you're wondering, here is my test sketch (Mega2560).  I used the Inty power supply for the VDD, VCC, and VBB.

 

inty_ram.ino

Edited June 21, 2020 by ChildOfCv

[ChildOfCv]

On 6/20/2020 at 4:42 PM, intvnut said:

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.

I realized I forgot to answer this question.  The RAM does respond even outside of the range of usable RAM, but I only got FFFF's for readback.

 

On 6/20/2020 at 4:42 PM, intvnut said:

That seems like it was hacked in when they realized they had a problem.

Yeah a lot of the architecture seems like a kid doodling with legos, for that matter.  A RAM chip that also does bus arbitration.  A ROM chip that also gives access to external memory and peripherals.  Another ROM chip that also steers the STIC RAM.

 

Now looking closely at the schematic, I see that the ENABLE for the sound/peripheral chip is supposed to be pins 24 and 25.  But the Inty leaves them disconnected and uses pin 26 (TEST 2, do not use!) as its enable.

 

Then on the RO-3-9502, it supposedly only has 10 address output lines for external memory.  But pin 14 (NC on the datasheet) is labeled as A10 and connected to the OR gate.  So, two WTFs.

[intvnut]

4 minutes ago, ChildOfCv said:

Then on the RO-3-9502, it supposedly only has 10 address output lines for external memory.  But pin 14 (NC on the datasheet) is labeled as A10 and connected to the OR gate.  So, two WTFs.

I believe pins 14, 12, 10, 8, 6, and 4 are the upper 6 bits of the address bus.  Decoding up through A10 would be necessary if the external RAM area is decoded at 2K granularity like the ROM itself. That seems like the most likely explanation.  Even the RO-3-9502 description in the CPS (CCF10232011_00012.pdf from PapaIntellivision) lists those pins as NC.  However, it also says it latches as 16 bit address for the external memory.  Direct quote:  "16 bit static address outputs for external memory."

 

The section on "Operation with External Memory" in the CPS doesn't list any decode sizes below 2K.

 

 

The 240 byte scratchpad RAM was a last-minute addition to the "GIMINI Deluxe 8900" architecture.  If you find older sales pitch documents, it's not shown.  

This earlier data sheet describes the RO-3-9501 (ever hear of that one?) and RO-3-9502, indicating the latter latches all 16 lines, and it shows all 16 lines documented properly. 

 

 

 

 

13 minutes ago, ChildOfCv said:

Now looking closely at the schematic, I see that the ENABLE for the sound/peripheral chip is supposed to be pins 24 and 25.  But the Inty leaves them disconnected and uses pin 26 (TEST 2, do not use!) as its enable.

I've seen multiple versions of the data sheet for both the AY-3-8910 and AY-3-8914, including a very early datasheet for AY-3-8910 that actually has the AY-3-8914 address map and 2-bit shift on the envelope volume.  I've seen die photos of both, and can see where they removed that 2-bit shifter.  At least one of the data-sheets (I think the one I got for the AY-3-8910 from Jameco back in the '80s) listed all three pins as a 3-bit address input that could be mask programmed to whatever address you prefer to map it in a 256-address range.  I vaguely remember that data sheet also mentioned that the pins had internal pull-ups/pull-downs to act as "default selected" if left unconnected.    The CPS's description of pins 24, 25, and 26 is funny:

 

If you read starting at page 100 here, you'll see those three pins are listed as chip selects.  Note, this is the AY-3-8910 preliminary data sheet with the AY-3-8914 address map and two-bit envelope volume shift (see page 101).  I suspect GI wanted to change the address map to the more familiar AY-3-8910 production address map, but had to preserve the original for Mattel.  Hence the AY-3-8914 was born. 

 

The follow-ons (AY-3-8914A, AY-3-8916, AY-3-8917) apparently came from Mattel.  Mattel requested the I/O direction control be removed from the PSG so it was always input, and a change so that the counters counted up and compared, rather than counting down and reloading at 0.  This is the source of the most commonly noticed sound effects bugs on the Intellivision II, BTW.

 

It's weird, but sometimes the earlier data sheets are more accurate than what came later.

 

39 minutes ago, ChildOfCv said:

I realized I forgot to answer this question.  The RAM does respond even outside of the range of usable RAM, but I only got FFFF's for readback.

Ah, so it does respond to $360 - $3FF?    That's good to know.   I won't ever put anything there unless it's write-only.

[Walter Ives]

On 6/15/2020 at 7:34 PM, intvnut said:

The TutorVision doesn't use the AY-3-8900 and RA-3-9600, though.  It's rather different hardware built around a custom ASIC.

Hey! Show some respect! That part you blithely dismiss as some sort of generic "custom ASIC" has a proper name. It is the vaunted STIC 1a, specified and designed by APh and laid out by Toshiba, whose first silicon was ready in the Spring of 1983. Prodromou was rather proud of that result. Unfortunately, he was unproudly sitting on a rather huge stash of original chipsets…

On 6/15/2020 at 7:34 PM, intvnut said:

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.

You've got it backwards. The specifications you linked to ARE the official data sheets, in that GI was contractually obligated to deliver to Mattel devices that met those specifications. And Mattel was GI's only customer for the parts. The information in the catalogs was, shall we say, preliminary, somewhat vague and less than definitive. A teaser, if you will.

 

On 6/15/2020 at 7:34 PM, intvnut said:

I admit, though, it's a bit like reading tea leaves and entrails to divine the meaning fully from the text.

There were only eight people in the world who fully understood the STIC timing, or needed to. Three of them worked for GI and the others were involved in designing the Keyboard Component, STIC 1a and STIC 1b. The documents you are agonizing over were written by Harrower, who actually had better things to do at the time but was pulled off them to hurriedly rewrite updated and hopefully correct versions to attach to the contract.

 

On 6/19/2020 at 1:52 AM, intvnut said:

What that also means is that the BACKTAB is only 44.7µs wide, out of the ~52.6µs active video period.

That is correct. TV's never displayed the full 52.6 us—part of the active picture always disappeared under the bezel. Broadcasters used the term "action safe" do describe the area of the picture that almost all TV sets could be counted on to display. The production crew did their best to keep the action within that area. The "action safe" area was about 46 us wide, but that was not a published standard and varied from studio to studio, and even on different programs within a studio. Studio monitors had "overscan" buttons you could push to see the entire image. If BACKTAB were the full 52.6 us wide part of the displayed image would be hidden under the bezel—a waste of the very costly bits used to generate it. If you look at the Intellivision picture on old TV's you will see that the border is barely a half dozen pixels wide on either side. There's a little more unused picture space vertically—there you could almost squeeze in an extra card.

 

On 6/19/2020 at 1:52 AM, intvnut said:

The total STIC scanline is 63.7µs—slightly longer than NTSC's prescribed 63.5µs.

Not just slightly longer—EXACTLY one-half color carrier cycle longer. The NTSC standard calls for the color carrier to change phase every scan line, but pixelated graphic images of that resolution look better if you don't follow that convention.

 

On 6/19/2020 at 1:52 AM, intvnut said:

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.

Nor did any other video game of the era. Again, the graphic images of that resolution looked better.

 

On 6/19/2020 at 11:39 PM, ChildOfCv said:

Of course with such ridiculous BUSAK times that even start before active display on the previous line, it seems like the STIC is stealing a lot more bus cycles than it ought to be.

It is, but the early BUSRQ was needed to accommodate long strings of the CP1600's plethora of non-interruptible instructions. Cartridge programs were subjected to a diagnostic that identified such strings before release.

 

On 6/20/2020 at 12:11 AM, ChildOfCv said:

linebuf is actually described as a shift register.

It is not only so described, it so is. Shift register memory takes much less chip space than random access memory because each cell communicates only with its neighbor and you don't need all the traces running into each cell. Those extra traces take up much more space than do the transistors that make up the cell. (For those unfamiliar with VLSI layout: transistors are formed when two traces cross, so they're tiny. Most of the room of an IC is taken up routing the traces to the appropriate place.)

 

On 6/19/2020 at 11:46 PM, intvnut said:

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

A terrible idea. Proposed by heathens with no soul.

 

On 6/20/2020 at 1:24 AM, intvnut said:

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.

There was a package pin limitation—even after eliminating MSYNC there were only enough pins to route 14 data bus lines to the STIC. But no problem, the bus control lines change state during TS1, so you know the next state is TS2.

 

 

On 6/20/2020 at 3:42 PM, intvnut said:

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.

You are absolutely correct. The ADAR cycle was a royal pain in the buttinski. Often sardonically referred to as "Sidline's better idea."

 

On 6/20/2020 at 3:42 PM, intvnut said:

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.

Bingo! It exists as certainly as love and generosity and devotion exist, and you know that they abound and give to your life its highest beauty and joy.

 

On 6/21/2020 at 11:31 PM, ChildOfCv said:

Yeah a lot of the architecture seems like a kid doodling with legos, for that matter.  A RAM chip that also does bus arbitration.  A ROM chip that also gives access to external memory and peripherals.  Another ROM chip that also steers the STIC RAM. Now looking closely at the schematic, I see that the ENABLE for the sound/peripheral chip is supposed to be pins 24 and 25.  But the Inty leaves them disconnected and uses pin 26 (TEST 2, do not use!) as its enable. Then on the RO-3-9502, it supposedly only has 10 address output lines for external memory.  But pin 14 (NC on the datasheet) is labeled as A10 and connected to the OR gate.  So, two WTFs.

All right. Let's get this clear for once and for all. (1) Maine, Harrower, Behrman, Dunn, Naif and Butler made chip layout changes as easily as you make posts to this website. (2) The only data sheets that even sort of matter are the customer procurement specifications. (3) The customer procurement specifications you have were written long after deliveries had begun. (4) Even if the customer procurement specifications had errors, there was only one customer for the chipset, and only one product in which it was going to be used. The executives didn't care about the details as long as the parts in the chipset played well together. If the spec was wrong, who was even going to notice? (5) Tempus Fugit. The only really important thing was to have working systems in Fresno by December 2nd, 1979. Damn the datasheets, full speed ahead!

 

On 6/22/2020 at 12:12 AM, intvnut said:

The 240 byte scratchpad RAM was a last-minute addition to the "GIMINI Deluxe 8900" architecture.  If you find older sales pitch documents, it's not shown. 

The "architecture" shown in the catalog is merely illustrative. Indeed, it would be kind of cheeky to put a particular customer's specific block diagram in your catalog. Customers were free to add things according to their needs and desires. Add a modem if you like, or a sound chip (did you notice there was no sound chip in the diagram?). Or even a Keyboard Component.

 

 

[+DZ-Jay]

On 12/3/2022 at 8:15 AM, Walter Ives said:

Bingo! It exists as certainly as love and generosity and devotion exist, and you know that they abound and give to your life its highest beauty and joy.

This must be my favorite comment on an AtariAge post, ever!

 

And that it comes during the Christmas season, feels even more special and à propos.

 

     dZ.

[ChildOfCv]

On 12/3/2022 at 6:15 AM, Walter Ives said:

It is not only so described, it so is. Shift register memory takes much less chip space than random access memory because each cell communicates only with its neighbor and you don't need all the traces running into each cell. Those extra traces take up much more space than do the transistors that make up the cell. (For those unfamiliar with VLSI layout: transistors are formed when two traces cross, so they're tiny. Most of the room of an IC is taken up routing the traces to the appropriate place.)

Nice to see some confirmation from someone who seems to know the ins and outs (and the politics behind them).

 

One of these days, I'd love to try to build a FPGA replacement for that chip, especially since I have an Inty that needs one.  Alas, FPGAs that support 5V are pretty much gonesky, and the Verilog software always expects things to happen on every clock cycle and freaks out when operations are expected to cross clock timing thresholds.

 

One thing of note though:

On 12/3/2022 at 6:15 AM, Walter Ives said:

There was a package pin limitation—even after eliminating MSYNC there were only enough pins to route 14 data bus lines to the STIC. But no problem, the bus control lines change state during TS1, so you know the next state is TS2.

Assuming my code is "correct", it turns out you don't even need to know when it's TS1 vs TS3 or TS2 vs TS4.  The simplicity of the chip and its reactions to the bus lines makes it a moot point.

[Walter Ives]

On 12/14/2022 at 9:46 PM, ChildOfCv said:

Assuming my code is "correct", it turns out you don't even need to know when it's TS1 vs TS3 or TS2 vs TS4.  The simplicity of the chip and its reactions to the bus lines makes it a moot point.

I was thinking generally, but you're right for the 9600. Its RAM portion is really just a 16-bit wide RAM with a built-in address latch for which the bus control lines are sufficient, it doesn't even need Phi2. Phi2 is only needed as a clock for the DMA/recirculating shift register portion. That portion is controlled by a system of counters that are reset and enabled by INTAK, BUSAK and SR3 in what you by now must recognize as a more-or-less straightforward way. Those control signals happen to be synchronized with the CPU T-states but, as you infer, the 9600 itself doesn't know that and doesn't care.

 

WJI

[Walter Ives]

On 12/14/2022 at 9:46 PM, ChildOfCv said:

One of these days, I'd love to try to build a FPGA replacement for that chip, especially since I have an Inty that needs one.  Alas, FPGAs that support 5V are pretty much gonesky

That's definitely a doable project as a little daughterboard. The 9600 is slow enough that the delay of off-chip level conversion will be inconsequential.

 

As mentioned in another post, the 9600 was the last chip of the set to be finished and in 1979 APh built circuit boards that plugged into the Master Component socket while waiting for it to become available. Master Components using these boards were used for development and at trade shows.

 

WJI