RA-3-9600 technical specs?

[ChildOfCv]

I have the 3-page datasheet on the system RAM/Graphics/Bus Arbitrator chip and have been attempting to use it to test the chip on a system that isn't working at the moment.  So I have 2 unknowns:  1) Does the chip work?  2) How exactly does the chip work?

 

I've been bit-banging it with an Arduino, and so far I've determined that as long as BUSAK is inactive, the CPU passthrough works.  I've also written to and read back the RAM, so at least basically it works.  But so far I can only get junk for the BACKTBL output.  As far as I can tell, when BUSAK is active and SR3 has been pulsed 20 times, BUSAK should be able to go inactive and further SR3 pulses should cause the next background card from the ring buffer to appear on the STIC bus. But all I seem to get is garbage.  But I don't know if that means the chip is indeed bad, or if my test rig is wrong.

 

So, is there any more detailed documentation out there?  Well, I should mention I also found a synopsis at Spatula City, and the System RAM page at intellivision.us.

[intvnut]

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

 

[intvnut]

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.

 

[ChildOfCv]

Thanks for the additional paper.  I had seen that once but dismissed it since it only repeats the summary of the data sheet, for the most part.  But it does have extra timing diagrams, and more importantly, a section about the STIC which I could find no separate official documentation on.

 

Some things still don't match observation though:

 

10 hours ago, intvnut said:

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.

Yeah that's what the docs say, but apparently there are some timing issues involved too.  What I've observed and conjectured so far:

 

1) When the chip powers up, it seems to be in bus copy mode (SD = DB).  Initial INTAK just reinforces this.

 

2) While in this mode, you can momentarily hit it with BUSAK signals which will make the STIC outputs float while the signal is active, but ending BUSAK mode, at least maybe ending it too soon, just resumes bus copy mode.

 

3) Response to BDIR, BC1, and BC2 is dependent on Φ2.  Standard timing doctrine according to the docs is that BDIR, BC1, and BC2 are set and Φ2 goes high, then low, then high for that period.  If the command is BAR, I assume that commits the address to its internal address buffer.  I guess that should happen on the negative edge of Φ2 maybe?  Anyway, if you don't do Φ2 or you have the phase wrong, you don't read useful values from RAM on the CPU bus side either.

 

Also, as long as it's in bus copy mode, SD=DB, always, regardless of control signals.

 

On my Arduino, I use a TICK macro.  It does 3 NOPs and a toggle of Φ2 per "tick".  Each programmed state uses 4 TICKs total.  NACTs are sprinkled in as dictated by the timing diagrams, each with their own 4 TICKs.  I always use the TICK macro to wait it out, so Φ2 should be almost constantly clocking.  And this way I can make sure things happen at the correct phase.

 

4) I did manage to finally get it to enter DMA mode, but it's definitely a timing issue.  Simply asserting BUSAK is not enough--as soon as I drop it, it's back in CPU copy mode.  Perhaps once it's held for some time, the mode changes.  Or, perhaps there needs to be at least one strobe of SR3 before it enters DMA mode.

 

5) It does appear that there are two isolated clock inputs:  Φ2 and SR3.  Φ2 only controls the CPU side, and SR3 activates the STIC side (when in DMA mode).  The RAM itself, and the address counter, both appear to be static, as there is no indication of either losing state over time even though I'm not clocking it at 1.7MHz.

 

6) While in DMA mode, I finally got it to output memory contents on the STIC bus while SR3 is active.  It would go through the first 20 slots like it's supposed to.  For that matter, I can watch it churn through the entire BACKTBL by holding BUSAK the whole time.  If I go by intended use and only pull the first 20 and then inactivate BUSAK, then the 20 cards will rotate like they're supposed to.  But then the next time I bring BUSAK active again, it does not resume counting through the rest of the cards ?!?!

What I'm concluding from this is that timing is probably critical, and I am probably not in its preferred timing windows, somehow.

 

10 hours ago, intvnut said:

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

This does not seem to be documented.  Is this just observed behavior from a running system?  The timing diagram just shows that you hold BUSAK and give it 20 SR3 pulses to fill the rotating buffer, then drop BUSAK and continue the SR3 pulses another 15 * 20 times (one for each line) to repeat the same buffer, for a total of 16 lines of 20 cards.  Then hold BUSAK again to shift in the next 20 cards and so on.  Also, when I finally managed to get STIC output, it did not require a leading BUSAK/~BUSAK cycle.  But I do concede, as mentioned above, that I haven't fully achieved satisfactory results yet.
 

12 hours ago, intvnut said:

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.

This is possible, but also a lot harder to deal with.  I could easily set up a clock output line on a regular cycle for this, but my tests which rely on Φ2 timing would be much harder to accomplish since they need to be in lockstep with this clock.  But it may be what I need to do.  <sigh>

 

[intvnut]

6 hours ago, ChildOfCv said:

4) I did manage to finally get it to enter DMA mode, but it's definitely a timing issue.  Simply asserting BUSAK is not enough--as soon as I drop it, it's back in CPU copy mode.  Perhaps once it's held for some time, the mode changes.  

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.

 

6 hours ago, ChildOfCv said:

Or, perhaps there needs to be at least one strobe of SR3 before it enters DMA mode.

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.

 

6 hours ago, ChildOfCv said:

What I'm concluding from this is that timing is probably critical, and I am probably not in its preferred timing windows, somehow.

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.

 

6 hours ago, ChildOfCv said:

If I go by intended use and only pull the first 20 and then inactivate BUSAK, then the 20 cards will rotate like they're supposed to.  But then the next time I bring BUSAK active again, it does not resume counting through the rest of the cards ?!?!

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

 

6 hours ago, ChildOfCv said:

This does not seem to be documented.  Is this just observed behavior from a running system?

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.

 

18 hours ago, intvnut said:

although you can probably go closer than that.

I meant to say "go slower than that."

Edited June 16, 2020 by intvnut
add some more notes.

[intvnut]

Another weird timing behavior I observed:  

 

[intvnut]

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.

[ChildOfCv]

Ugg.  Well on the good side I was able to confirm that the RAM in this INTV1 has problems, by putting it into an INTV2.  I guess the one I have has been worked on, as I'd heard that its chips aren't socketed, but the CPU, RAM, and STIC on that one are all in sockets (the one for the RAM is installed backwards !@#!$, but at least the chip survived the ordeal).  Anyway, with the bad RAM the INTV2 gets garbage on the screen and does funky stuff.  However, with the good RAM in the INTV1, it still gets blank screen   So apparently it has multiple problems.

 

I tried the STIC swap, and no difference.  Old and new work in the INTV2, neither work in the 1.

 

So, Φ1 and Φ2 to the CPU work.  CPU does begin by asking for init vector and it seems to get a proper one from the EXEC ROM.  EXEC ROM itself tests okay (already built and ran a test on it).  All code correct, and it seems to output correct signals to external memory.  EXEC ROM 2nd chip also reads correctly.  At first the CPU was halting (asserting the halt output and everything else in a floating state), but at least now it seems to be executing instructions.  Perhaps replacing the ROM and CPU sockets made a difference there.

 

I guess what's next may be to see if the AY-3-8915 is being driven.  If so, then perhaps the GROM is next.

 

Of course it still might be a fun side project to try to fully figure the RAM out.

 

And another one to build a FPGA replacement.

[ChildOfCv]

1 hour ago, intvnut said:

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. 

Well, what I meant by bus copy mode is that I'm driving data on the DB pins and observing it duplicated on the SD pins, so this is a simulation of address or data writes, but with NACT on the control lines.  Or likely with anything but a DTB on the control lines.  Apparently you need "bus reversal" to read from the SD pins, which it doesn't explain but I assume that's a DTB control?

 

Anyway, in BUSAK mode, the SD pins go floating and I do not see what's on the DB pins (nor should I), but if I don't succeed in "latching" it into DMA mode, as soon as BUSAK drops, the SD pins again begin to mirror the DB pins.

 

Maybe I'll try this for my next experiment:  BUSAK low for a good amount of time, then BUSAK high, see if it's back to mirroring the DB pins.  Then repeat and see if it ever enters DMA mode.

[intvnut]

30 minutes ago, ChildOfCv said:

Well, what I meant by bus copy mode is that I'm driving data on the DB pins and observing it duplicated on the SD pins, so this is a simulation of address or data writes, but with NACT on the control lines.  Or likely with anything but a DTB on the control lines.  Apparently you need "bus reversal" to read from the SD pins, which it doesn't explain but I assume that's a DTB control?

 

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?

 

 

1 hour ago, ChildOfCv said:

Maybe I'll try this for my next experiment:  BUSAK low for a good amount of time, then BUSAK high, see if it's back to mirroring the DB pins.  Then repeat and see if it ever enters DMA mode.

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.

 

 

[ChildOfCv]

Okay, I realized that the first thing I need to do is purge my memory of things I "learned" while I had the SR3 and BUSAK lines backwards.  "activating" BUSAK, I was actually activating SR3 and getting CPU passthrough.  Updated:

 

1) In bus copy mode, SD lines are floating while SR3 is inactive (that was when I thought I was activating BUSAK) and they copy DB->SD while SR3 is high.  In fact, it's pretty much like they're connected straight across, as changes to DB are immediately reflected in SD as long as SR3 is active.  Φ2 is irrelevant.

 

2) Reverse bus copy mode requires DTB on the control line.  No Φ2 manipulation necessary to read the STIC bus.  Just DTB.  However, SR3 OVERRIDES the direction and chooses CPU->STIC copy.  Like in forward-copy mode, reverse-copy simply connects SD->DB so that changes to SD are immediately seen on DB.

 

3) Φ2 IS required to access RAM.  Without it, I get no data read back, and I assume no data written.

 

4) To enter DMA mode, apparently SR3 must be low first.  If SR3 is already high, even if you bring it low at the same time you activate BUSAK, that seems to nullify DMA mode.  In addition, there must be 3 positive transitions of Φ2.

 

5) Φ2 is not required to turn SD on or off, but is required to advance the card clock.  I've also confirmed that if I allow too many clocks at various locations, things go bad.  For instance, I got the first card rotated to the end by using a 12-clock SR3 cycle, but had the cards correct with an 8-clock SR3 cycle.

 

I'm hoping that it's not the speed of Φ2 but the phases/number of clocks that is the key to proper timing.  So it's time to study the diagrams keeping a close eye on how everything interacts with Φ2.

[HunterZero]

This is really useful info for anyone who might want to take on a project to create a drop-in replacement package for the RA-3-9600... Would revive quite a few dead Intys.

 

- J

[intvnut]

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.

 

Edited June 19, 2020 by intvnut
I hit "save" too soon.; also uploaded a new version of sr3_wave0 that highlights approximately how early BUSAK* could come.

[ChildOfCv]

Hmmm.  Is it accurate to say that SR3 rises or falls halfway through a Φ2 cycle then?  From your diagram, it appears that halfway between the falling edge and the rising edge is when SR3 turns on or off.  It also appears to be only one tick for SR3 on and 2 while off.

 

My own experiments never tried a halfway tick like that.  I always set SR3 state, then do paired level changes of Φ2 where the change comes at the end.  So the timing cycle looks like:

 

SR3 (or DB or whatever), tick time, Φ2 change high, tick time, Φ2 change low, tick time, Φ2 change high, tick time, Φ2 change low, then drop SR3 and do another 4 ticks.  As a result, a change in a control or data line always coincides closely with a clock tick.

 

 Maybe I should put the Φ2 level change in the middle of a tick, then try that 1 tick up, 2 ticks down to see if that makes a difference.

 

So some math says that during the active portion of a display line there are 95 Φ2 clocks.  That's an average of 4.7 per card.  I wonder if the STIC spaces the Φ2 accesses around in order to reach the proper screen width (would result in some pixels being fatter)?  Or maybe it just uses 4 ticks total and places the remainder in the border?

 

Well, I also broke down and ordered a better scope, one that comes with a 16-channel logic analyzer.  Seems like I use the scope so often as a logic analyzer anyway, it should have been what I got in the first place.  Especially since only 2 channels at once sucks.  So that should be able to generate some good timing diagrams once it all arrives.

[intvnut]

1 hour ago, ChildOfCv said:

Is it accurate to say that SR3 rises or falls halfway through a Φ2 cycle then?  From your diagram, it appears that halfway between the falling edge and the rising edge is when SR3 turns on or off.  It also appears to be only one tick for SR3 on and 2 while off.

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:

  

 

1 hour ago, ChildOfCv said:

So some math says that during the active portion of a display line there are 95 Φ2 clocks.  That's an average of 4.7 per card.  I wonder if the STIC spaces the Φ2 accesses around in order to reach the proper screen width (would result in some pixels being fatter)?  Or maybe it just uses 4 ticks total and places the remainder in the border?

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.

 

 

Edited June 19, 2020 by intvnut

[intvnut]

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.

 

 

 

Edited June 19, 2020 by intvnut
Add a dashed line to connect BUSAK to ø2.

[mr_me]

10 hours ago, HunterZero said:

This is really useful info for anyone who might want to take on a project to create a drop-in replacement package for the RA-3-9600... Would revive quite a few dead Intys.

 

- J

The entire system has been done in fpga, so if someone wants to do a replacement for one chip they could, hopefully, use some of that work.  It would be relatively expensive since there's tons of old hardware out there.

http://temlib.org/pub/mister/intv/

Edited June 19, 2020 by mr_me

[ChildOfCv]

5 hours ago, mr_me said:

The entire system has been done in fpga, so if someone wants to do a replacement for one chip they could, hopefully, use some of that work.  It would be relatively expensive since there's tons of old hardware out there.

http://temlib.org/pub/mister/intv/

Hmmm, well that directory is just a skeleton that lists the FPGA ports, no functionality.  I don't see any obvious component libraries in the parent directory either.

[intvnut]

2 minutes ago, ChildOfCv said:

Hmmm, well that directory is just a skeleton that lists the FPGA ports, no functionality.  I don't see any obvious component libraries in the parent directory either.

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.

[mr_me]

4 hours ago, ChildOfCv said:

Hmmm, well that directory is just a skeleton that lists the FPGA ports, no functionality.  I don't see any obvious component libraries in the parent directory either.

The parent folder has the intv.rbf that's installed in a Mister fpga.  There's a github page as well but I don't know if the Mister intellivision fpga is open source or closed source.  Kevtris' intellivision fpga is closed source and not available.

[ChildOfCv]

6 minutes ago, mr_me said:

The parent folder has the intv.rbf that's installed in a Mister fpga.  There's a github page as well but I don't know if the Mister intellivision fpga is open source or closed source.  Kevtris' intellivision fpga is closed source and not available.

Yeah I see that the MISTer is a hybrid solution.  The SoC is an ARM processor with FPGA added on.  The emulator seems to be a lot of C/C++ code and a little bit of VHDL.  I don't know what the RBF files are (none of the common usages of that extension seem to apply), so maybe it's a binary file that the code loads and builds its emulators with.  But if so, then it should also have a build system to create those files, assuming of course that they are also open-source.  But it's probably also a combination of both ARM code and FPGA directives.

[mr_me]

You couldn't select and load different fpga cores without a cpu and regular software so yes the mister fpga has an arm soc and software component.  Rbf is for raw binary file that mister loads in to its fpga.  If you want to know more you can ask the creator of that intellivision fpga core.

Edited June 19, 2020 by mr_me

[intvnut]

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

 

 

[ChildOfCv]

Yes, it appears that SR3 can start pulsing LONG before BUSAK is asserted.  In one capture, there are 7 (!!?!?!) pulses of SR3 before BUSAK is asserted.  The other 13 pulses appear afterwards.  So this raises a huge question about how it can even get the cards straight.  It almost makes you wonder if the graphics counter is advancing entirely due to ø2, period.  That would at least show potential, as then the STIC would be guaranteed to see the value that is intended for that pixel.  

 

This is the most extreme I've seen.  Often it's just 3 steps, or 0 before BUSAK.  Edit:  I just saw 12 SR3's before BUSAK now.  In this one, BUSAK came down while SR3 was still active.

 

Perhaps the only thing BUSAK does is begin the internal counting since it is used to mark the start of active display.

 

D0 is ø2, D1 is BUSAK, and D2 is SR3

 

Edited June 20, 2020 by ChildOfCv

[intvnut]

3 hours ago, ChildOfCv said:

Yes, it appears that SR3 can start pulsing LONG before BUSAK is asserted.  In one capture, there are 7 (!!?!?!) pulses of SR3 before BUSAK is asserted.  The other 13 pulses appear afterwards.  So this raises a huge question about how it can even get the cards straight.  It almost makes you wonder if the graphics counter is advancing entirely due to ø2, period.  That would at least show potential, as then the STIC would be guaranteed to see the value that is intended for that pixel.  

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.

Edited June 20, 2020 by intvnut
Clarify some wording, particularly in "Unknowns."