Jump to content
Sign in to follow this  
FarmerPotato

Geneve PAL reverse engineering

Recommended Posts

This is my progress so far in deciphering the Geneve PAL16R4 chip. 

 

I stress this is all guesswork, based on pin names and knowledge of how the memory bus works.
I have not tested any of it with a logic analyzer.
 

Geneve PAL Logic

 

Language: CUPL, the PAL programming language. Input or Output are inferred based on assignment statements and pin capability (some are input, some are input/output).

 

A "/" indicates active low, so  CUPL treats 0 as 1 and 1 as 0. 

Example: /CRUCLK in CUPL is CRUCLK* on the schematic.

 

/******** READY logic ***********/
PIN 3  /SNDRDY      ;   /* i2                         */
PIN 8  /GA_RDY      ;   /* i7  from GA pin 36 "MEBS"  */
PIN 18 /READY       ;   /* io2 to 9995 READY          */

READY = SNDRDY * GA_RDY; /* undeciphered: slight chance depends on 19 and 5 somehow */

/* this is some real guesswork */
PIN 4  /CSR         ;   /* VDP read                   */ 
PIN 9  /CSW         ;   /* VDP write                  */ 

/READY = /SNDRDY * /GA_RDY; /* undeciphered: slight chance depends on 19 and 5 somehow */

Impossible, this will not work (what releases CSW or CSR if READY is active?)

/READY = /SNDRDY * /GA_RDY * /CSW * /CSR;

/******** Pbox WE and CRUCLK logic *********/
PIN 2 /GA_WECRUCLK ;   /* i1  buffered WE*/CRUCLK* from TMS9995 */
PIN 6  /GA_MEMEN   ;   /* i5  from GA /MEMEN          */
PIN 12 /WE         ;   /* io1 to 244 and PBOX /WE     */
PIN 13 /CRUCLK     ;   /* io2 to 244 and PBOX /CRUCLK */ 

/CRUCLK = /GA_WECRUCLK * /GA_MEMEN;   /* AND function. */
/WE     = /GA_WECRUCLK # /GA_MEMEN;   /* OR function   */


WHAT'S LEFT on the PAL16R4

 

What's deciphered:   1 2 3 6 8 11 12  13 18 
Unused: 14 15 16 17
   
Not deciphered:  4 5 7 9 19 */
   5 and 19: CRU connections, maybe two input bits for settings? or one input, one output
   7 DBEN* possibly means DBIN but what is it an input to? 
   4 csr and 9 csw: Looks like  VDP read and write
   */

 

BACKGROUND on WE*/CRUCLK*

On the TMS9900 (and PBOX plane)

    MEMEN WE DBIN CRUCLK
    1     1  0    1   read CRU
    1     1  0    0   write CRU
    0     1  1    1   read memory
    0     0  0    1   write memory

 

On the TMS9995, output pin WE*/CRUCLK* is AND(WE*, CRUCLK*).  They had to save pins on the 40-pin package.

 

If MEMEN is high, it's CRUCLK. if MEMEN is low, it's WE.

 

They are easy to separate:

    CRUCLK* = AND(WE*/CRUCLK*, MEMEN)
    WE*     = OR(WE*/CRUCLK*, MEMEN)


GATE ARRAY GUESSES

 

And in the GA itself (guesses)

/* SNDRDY logic */
PIN 32 /PBOXRDY   ; /* from buffered PBOX 4 READY* with pullup */
PIN x /SNDRDY     ; /* output to PAL */
PIN 36 /MEBS      ; /* output low to PAL when the GA is generating wait states */
PIN x /SNDRDYIN   ; /* must be somewhere */

/SNDRDY = /SNDRDYIN * /PBOXRDY;

Combining the PAL and GA, the TMS9995 READY is
/READY = /SNDRDY * /PBOXRDY * /MEBS

 

I stress this is all guesswork, based on pin names and knowledge of how the memory bus works.
I have not tested any of it with a logic analyzer.

 

REFERENCE

 

http://ftp.whtech.com/Geneve/schematics/
http://ftp.whtech.com/datasheets and manuals/Datasheets - TI/TMS9995.pdf
https://www.ti.com/lit/ds/symlink/pal16r4am.pdf

  • Like 1

Share this post


Link to post
Share on other sites


WILD GUESS

 

What if the PAL is the chip that generates extra wait states? Not the GA.

 

Pins 5 and 19 would be system settings for # of wait states needed in GPLMODE.

 

Two bits gives values of N = 0, 1, 2, or 3 wait states.

 

Two unused io pins are used as register bits to count the number of clock cycles (pin 1) since /CSR, /CSW, /WE or /DBEN was asserted. When it matches the input N, READY is released.

 

This would invoke wait states on VDP access, any memory access. It explains why these pins are needed: The remaining signals are needed to pull READY down, and release it after N cycles. 

 

They could not possibly be tied directly into the READY signal, or the CPU would go into an infinite number of wait states.

 

  • Like 1

Share this post


Link to post
Share on other sites

CRU pinning

 

PAL input i4 goes to CRU INT15*/P7. This must be an output from the CRU, therefore, not an interrupt pin.

PAL io8 goes to CRU INT13*/P9. This could be an input or output (for an interrupt pin.)

 

I don't see why the PAL would generate interrupts. Nothing else in its inputs relates to interrupts. INT13 is pretty weird. How many interrupt levels does MDOS actually use? Just INT1 like the 4A?

 

Interrupts are disabled on 9901 reset. By default P7 and P9 are i/o.

 

If the pins are used as I/O then there will be these type of statements:

 

SBO 23    * send a 1 to the PAL input pin 5
SBZ 23    * send a 0 to the PAL input pin 5

 

If they are wait states this could be how they are set:

 

* set wait state bits for R1 states (0,1,2 or 3)
* assume P7 is least significant, P9 is most significant
LI   R12,23  * bit 23 is P7
LDCR R1,1
LI   R12,25  * bit 25 is P9
SRL  R1,1
LDCR R1,1

 

Or equivalently:

CLR R12

SBZ 23   * clear P7
SRL R1,1
JNC $+4
SBO 23   * set P7

SBZ 25   * clear P9
SRL R1,1
JNC $+4
SBO 25   * set P9


REFERENCE
TMS9901 PROGRAMMABLE SYSTEMS INTERFACE, Table 1 page 4

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Pretty sure SBO/SBZ 25 (R12==0) is video wait state enable/disable.  MDOS source code may provide some more clues and Michael may have these identified in his wiki and/or mame source?

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

https://www.ninerpedia.org/wiki/Geneve_CRU_definitions

 

The TMS9995 only uses 5 interrupt levels, unlike the 9900. The 9901 cannot pass the interrupt level to the 9995, as the 9995 only has the interrupt inputs INT1* and INT4* and no ICx interrupt level inputs. All 9901 interrupts are level 1 (as in the TI-99/4A).

 

0 = RESET, NMI

1 = INT1*

2 = MID or Overflow (inactive)

3 = Decrementer

4 = INT4*

Edited by mizapf
  • Like 1

Share this post


Link to post
Share on other sites

 During TIPI testing I think we tried to figure out what the external memory cycle bit (23) affected without much luck. Here is some general info from the boot eprom source.

CRUMOD EQU  >1EE0        CRU BASE FOR 16 BITS CONCERNING MODE, ETC.
*
NTSCVD EQU  5            0 IF NTSC, 1 IF PAL VIDEO
CLKKB  EQU  8            ALLOW KEYBOARD CLOCK
CLRKB  EQU  9            CLEAR KEYBOARD INPUT
NCMOD  EQU  10           NEW COMPUTER MODE=1, 4A=0
MAPMOD EQU  11           MAP MODE=1,  ROM MODE=0
*
CR9901 EQU  0            BASE OF INTERNAL 9901 CHIP
*
INTXT  EQU  1            ENABLE EXTERNAL INT TO 9901=1, NOT ENABLE=0
INTVDP EQU  2            ENABLE VDP INT TO 9901=1, NOT ENABLE=0
INTKB  EQU  8            ENABLE KEY BOARD INT TO 9901=1, NOT ENABLE=0
CPEBRS EQU  16           PE BOX RESET 1=ACTIVE, 0=INACTIVE
C9938  EQU  17           RESET TO AVDP CHIP
KBREST EQU  22           BIT TO RESET EXTERNAL KEYBOARD IF AVAILABLE
XMEMCY EQU  23           EXTERNAL MEM CYCLES 0=LONG, 1=SHORT
VDPWAT EQU  25           VDP WAIT CYCLES 1=ADD 15 CYCLES, 0=ADD NONE

 

  • Thanks 1

Share this post


Link to post
Share on other sites

Yes, MAME does not implement the external memory cycle bit either: When you run it with -oslog, one line is

 

[:] External bus wait states set to 1, not implemented yet.

 

This is because I also failed to find any measurable difference when this bit is set or not. If I remember correctly, I read bytes from a PEB card ROM with bit set and unset. This could also be a glitch in the Gate Array definition, turning this bit ineffective.

Share this post


Link to post
Share on other sites
39 minutes ago, InsaneMultitasker said:

 During TIPI testing I think we tried to figure out what the external memory cycle bit (23) affected without much luck. Here is some general info from the boot eprom source.

CRUMOD EQU  >1EE0        CRU BASE FOR 16 BITS CONCERNING MODE, ETC.
*
NTSCVD EQU  5            0 IF NTSC, 1 IF PAL VIDEO
CLKKB  EQU  8            ALLOW KEYBOARD CLOCK
CLRKB  EQU  9            CLEAR KEYBOARD INPUT
NCMOD  EQU  10           NEW COMPUTER MODE=1, 4A=0
MAPMOD EQU  11           MAP MODE=1,  ROM MODE=0
*
CR9901 EQU  0            BASE OF INTERNAL 9901 CHIP
*
INTXT  EQU  1            ENABLE EXTERNAL INT TO 9901=1, NOT ENABLE=0
INTVDP EQU  2            ENABLE VDP INT TO 9901=1, NOT ENABLE=0
INTKB  EQU  8            ENABLE KEY BOARD INT TO 9901=1, NOT ENABLE=0
CPEBRS EQU  16           PE BOX RESET 1=ACTIVE, 0=INACTIVE
C9938  EQU  17           RESET TO AVDP CHIP
KBREST EQU  22           BIT TO RESET EXTERNAL KEYBOARD IF AVAILABLE
XMEMCY EQU  23           EXTERNAL MEM CYCLES 0=LONG, 1=SHORT
VDPWAT EQU  25           VDP WAIT CYCLES 1=ADD 15 CYCLES, 0=ADD NONE

 

That's the info I needed! Based on mizapf's input, I speculate that XMEMCY does nothing in the PAL, or at most feeds back for 1 wait state. My reasoning is: the unused 4 bits would be needed to count to 15 for VDPWAT.

 

 

Share this post


Link to post
Share on other sites
1 hour ago, mizapf said:

https://www.ninerpedia.org/wiki/Geneve_CRU_definitions

 

The TMS9995 only uses 5 interrupt levels, unlike the 9900. The 9901 cannot pass the interrupt level to the 9995, as the 9995 only has the interrupt inputs INT1* and INT4* and no ICx interrupt level inputs. All 9901 interrupts are level 1 (as in the TI-99/4A).

 

0 = RESET, NMI

1 = INT1*

2 = MID or Overflow (inactive)

3 = Decrementer

4 = INT4*

It's settled then: 9901 P7 and P9 are outputs. Not interrupts. 

Share this post


Link to post
Share on other sites
Posted (edited)

There is one

On 7/30/2019 at 12:26 PM, FarmerPotato said:


WILD GUESS

 

What if the PAL is the chip that generates extra wait states? Not the GA.

 

 

Reasonable guess; though perhaps both are capable of generating - directly or indirectly.

 

GA pin 37 is not identified on the schematic but is connected to the PAL. 

 

The WHT "Turbo video" PAL provides for slightly faster video. Maybe by reducing wait states for video processing?  I don't have literature.  Which then begs the question would Don (who supports the WHT ftp site) have the equations for the PAL?

 

Edited by InsaneMultitasker
WHT, not WHY. typo

Share this post


Link to post
Share on other sites
43 minutes ago, InsaneMultitasker said:

There is one

Reasonable guess; though perhaps both are capable of generating - directly or indirectly.

 

GA pin 37 is not identified on the schematic but is connected to the PAL. 

 

The WHY "Turbo video" PAL provides for slightly faster video. Maybe by reducing wait states for video processing?  I don't have literature.  Which then begs the question would Don (who supports the WHT ftp site) have the equations for the PAL?

 

Got it, maybe the GA adds some wait states in some circumstance, but the PAL adds its own for VDP and waits for SND, and sends the result to the 9995.

Perhaps they left that detail in the PAL for fine tuning, as in the WHY you brought up .

 

Your code snippet said 15 VDP wait states. That seems like too much.

 

Each cycle is 333 ns, so 15*333 ns = 5 uS.

 

I'm kind of confused about how to add up the minimum times for V9938-CPU interface. Maybe it adds up to 270 ns, I'm not sure. One line indicates V9938 total memory cycle time is typ 700 ns, max 2 us. There is also a multi-byte access that saves time.  So 5 us is way overkill. 

Perhaps cycle + 2 wait states is enough, just like the 9918 on the 4A. (Then the 9995 wastes a cycle writing the LSB. Hopefully that goes nowhere.)

 

Reference

V9938 MSX Video Technical Data Book p .121

 

I think I can reverse engineer the rest of the PAL by taking an actual chip onto a breadboard. I'm assuming its protected from easily reading in a programmer.

It would be nice to attach my logic analyzer to your Geneve riser card to record exactly how many wait states occur.

 

Share this post


Link to post
Share on other sites

On Ninerpedia I collected my findings concerning wait states on the Geneve. I did a lot of tests, measuring the runtime using loops.

 

If you manage to reverse-engineer the PAL, this may clarify some of my open questions as well.

 

https://www.ninerpedia.org/wiki/Geneve_wait_state_generation

 

https://www.ninerpedia.org/wiki/Geneve_video_wait_states

  • Like 1

Share this post


Link to post
Share on other sites

I have an extra riser card if you want to put it together and use it. 

 

I also appear to have one of the PALs from the Cecure days.  It is unlikely but possible that it isn't protected.  If anyone communicates with Don (WHT) it would be worth asking him about the WHT PAL as well.

Share this post


Link to post
Share on other sites

I've been looking at the schematics during the past days, and I found some interesting points, but a lot is still obscure to me. In contrast to my earlier texts on Ninerpedia, the wait state creation is not a task of the gate array but of the PAL, as the READY input of the CPU is only served by the PAL and nothing else.

 

1. The outputs 14, 15, 16, 17 of the PAL are the outputs of the four internal flipflops, according to the specs of the PAL16R4ACN. I suppose that those FF are used to count from 15 to 0 for the video waitstates (or from 0 to 15). They could, of course, as well be started on 1 or 2 and count up to 15. This could be easily found out with a logic analyzer.

2. I found that only the pages E8-EF run by 0 waitstates. Everything else gets 1 WS (except sound and video, which have more). This surprised me in particular, since the EPROM does not need any WS, and also the page area C0-E7, which is intended for SRAM expansion, should be 0 WS, but is 1 WS.

3. How does the PAL know that we are accessing SRAM? Or, in other words, which lines signal to the PAL that we have 0 WS?

4. Why is SNDRDY fed back into the Gate array?

 

Share this post


Link to post
Share on other sites

I took notice at something on your latest board.  Not knowing what kind of power is being fed onto the board, I have concerns about the heatsink area.  On the Geneve, there are multiple heatsinks and most everyone is aware of the scorched areas and damaged traces on the board.  Not knowing how much voltage regulation/power is going to be managed, I wonder if maybe standoff's from the main board onto a daughter board, new power supply cabling, or something needs to be considered to minimize potential heat damage to the main board and traces????

 

Again, just thinking out loud here as there may not be that much power being regulated to be of concern.

Share this post


Link to post
Share on other sites

Here are the equations from reverse engineering, with permission from Don O'Neil, and credits to Jeff White who did the RE.

 

title {   Function:         Geneve Pal16R4A.
          Designer:         Western Horizon Technology.
          Specifications:    Standard wait states/Geneve default
      Date:             12 May 1992.
}


include p16r4;

 


/* input signals */

pin19.oe = 0;

/* output signals */

pin18.oe = 1;

!pin18 = ( !pin4 & !pin3 ) |
         ( !pin9 & !pin3 ) |
         ( pin9 & pin4 & !pin14.q ) |
         ( pin5 & pin4 & !pin15.q ) |
         ( pin5 & pin4 & !pin16.q ) |
         ( pin9 & pin4 & !pin17.q );

pin17.d = ( pin9 &     pin4    & !pin17.q &  !pin14.q ) |
          ( pin9 &     pin4    & !pin17.q &  !pin15.q ) |
          ( pin9 &     pin4    & !pin17.q &  !pin16.q ) |
          ( pin9 &     pin4    & pin3     &  pin16.q & pin15.q  & pin14.q ) |
          ( !pin19   & !pin17.q  & !pin14.q ) |
          ( !pin19   & !pin17.q  &  !pin15.q ) |
          ( !pin19   & !pin17.q  &  !pin16.q ) |
          ( pin3     & !pin19    & pin16.q & pin15.q  & pin14.q ) ;
      
pin16.d = ( pin9 & pin4 &   pin17.q & !pin16.q ) |
          ( pin9 & pin4 &  !pin17.q &  pin16.q ) |
          ( pin9 & pin4 &   pin16.q &  pin15.q &  pin14.q ) |
           !pin19;

pin15.d =  ( pin9  & pin4 &  pin15.q   &  pin14.q ) |
           ( pin9  & pin4 &  !pin16.q  &  pin15.q ) |
           ( pin9  & pin4 &  !pin17.q  &  pin15.q ) |
           ( pin9  & pin4 &  pin17.q   &  pin16.q & !pin15.q ) |
             !pin19;
        
pin14.d =  ( pin9 & pin4 &  pin14.q ) |
           ( pin9 & pin4 &  pin17.q &  pin16.q &  pin15.q ) |
           !pin19;

pin13.oe = 1;

!pin13 =   ( !pin6 & !pin5 ) |
           ( !pin8 & pin5 ) ;

pin12.oe = 1;

!pin12 =   !pin7 & !pin2;

 

/* PIN19 = CRU BIT FOR VDP WAIT STATES */
/* PIN04 & PIN09 = VDP CHIP SELECTS FOR READ AND WRITE */
/* PIN03 = NOT READY, CONNECTED TO GATE ARRAY AND SOUND CHIP */
/* PIN11 = CLOCK */
/* PIN06 = WRITE ENABLE */
/* PIN05 = MEMEN */
/* THE ABOVE TWO MAY BE REVERSED */

 

I created a logical circuit using Logisim from these equations; see the attached circ file (zipped). Logisim is a great Java-based tool for drawing logical circuits and for doing simulations with them: https://sourceforge.net/projects/circuit/

 

For easier interpretation: The *.q pins are the outputs of the respective flipflops, while the *.d pins are their inputs.

 

pal.circ.zip

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

Here is the logic circuit from above, exported as a PNG file. Using Logisim, you can turn on and off the input signals and watch the outputs.

pal.png

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Nicely done, Michael. This is extremely helpful! 

 

I compared your logic circuit to the schematic. I did not look closely at the labels (i.e., VWRITE vs. CSW).

 

1. In the logic circuit, CRU bit 23 is not labeled.  Label this pin as #5?

2. In the schematic, pin 11 is +5; in the logic diagram it is something else (CLK?)

3. In the schematic, pin 1 is the CLK. See #2.

4. In the schematic, pins 14,15,16,17 show as not connected.

5. In the schematic, pin 2 is tied to WE and CRUCLK.

6. Pin 8 is tied to gate array pin 36 but there is no documented function/label for this pin.

 

 

Share this post


Link to post
Share on other sites

Hi Tim,

 

thanks for checking. I used pin 11 according to the PLD file, but pin 1 is indeed correct. Also, in the PLD file there is a pin 8, although we don't know the meaning of that pin. Pins 14-17 are disabled outputs.

 

If you are interested in studying the function of the pins, use Logisim and turn on/off the inputs and watch the behavior. I used Logisim to understand the 99/8 Hexbus interface chip OSO in the same way (and obviously succeeded 🙂 ). And it's really more fun than tracing the logic diagram.

pal.png

pal.circ.zip

Share this post


Link to post
Share on other sites

While we're at it, could someone please check where the PAL pin 13 connects to? On the schematic, the lines are bundled and hard to tell apart. I guess it goes to the output driver LS244 (U29), possibly to one of its pins 2, 4, 6, or 8.

Share this post


Link to post
Share on other sites

Do you have a good enough idea of what the PAL is doing to write up a short 'operational' description?

 

PAL pin 13 ties to U29 Pin 4, MEMEN to the bus.  PAL pin 6 is MEMEN via the gate array. 

 

Could GA36 be the CRU bit mentioned in the boot EPROM source code?  "XMEMCY EQU  23           EXTERNAL MEM CYCLES 0=LONG, 1=SHORT" is the mystery we tried to figure out in a TIPI (iirc) thread a while back.

 

 

 

Share this post


Link to post
Share on other sites

About the GA36, I guess not. The line (for CRU bit 23 = P7 = address >002E) goes directly from the 9901 to pin 5 of the PAL. No feedback to the GA.

 

It seems to have an interesting effect. When set to 1, the READY line is pulled down after a video access (when CSR/CSW go back to 1 again), the PAL counts to 14 and releases READY when reaching 15. When set to 0, the PAL releases the READY line when reaching 9, and alternates between 0 and 1 until reaching 15 (the READY line reflects the LSB of the PAL counter). I'll check whether I can create a test program to verify this behavior.

 

My previous test programs (see Ninerpedia) were based on the fact that on-chip accesses are immune against the READY input, so you can measure the wait state period by stuffing instructions into the wait time after the video access and watching when they affect the loop time.

Share this post


Link to post
Share on other sites
46 minutes ago, mizapf said:

About the GA36, I guess not. The line (for CRU bit 23 = P7 = address >002E) goes directly from the 9901 to pin 5 of the PAL. No feedback to the GA.

 

Ah, yes, got my lines crossed (hah!) while looking at the schematic and your circuit.  There are actually two inputs that require further observation and testing.

 

The 'set to 0' effect is most interesting.  Is it allowing the 9995 to process interrupts or do some other processing that would otherwise be inhibited by the '1' setting?  I never did look further into the Genmod modification for any clues, to see if Ron Walters used either GA36 or 9901 bit 23 to implement the 0-wait state 2mb configuration.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...