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

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