Jump to content
IGNORED

Geneve PAL reverse engineering


FarmerPotato

Recommended Posts

GA 36:

What I deduce from the equations is that GA 36 and MEMEN* have the same semantics; CRU bit 23 switches between both.

 

So we can say that when CRU bit 23 is 0, GA 36 is masked away, and MEMEN* from the CPU is in control. When CRU bit 23 is 1, MEMEN* is masked away, and GA 36 is in control. Since in both cases, a proper memory access to the Pbox must be ensured, GA 36 must be a MEMEN* signal generated by the Gate Array.

 

GA 63:

GA 63 (SNDRDY) should be an output, and probably better labeled as READY (as seen in Fabrice's cleaned-up schematics). The READY line of the sound chip is an open-collector line; it is pulled down by the sound chip, and there are pull-up resistors (RN37). GA 63 forms a wired-AND with the sound READY line.

The reason why it cannot be an input (or it must be bidirectional) is that there seems to be no other way to create 1 WS for non-SRAM access. It can only come from this pin:

 

- The READY line of the processor is exclusively controlled by the PAL, so the wait state must be an effect of the PAL.

- The RAMEN* line does not connect to the PAL.

- The PAL has the input lines WE*/CRUCLK, DBEN*, MEMEN*, Pin 8, Pin 5, SNDRDY, VREAD* (aka CSR*), VWRITE* (aka CSW*), and VWAITEN. The first four lines do not have any effect on READY. VREAD* and VWRITE* cannot be used, since that would trigger the V9938. VWAITEN has no effect on RAM access; neither has Pin 5. So the only line that remains is SNDRDY.

 

My guess is that GA 63 is pulled down for one cycle for all memory accesses outside of the SRAM area.

Link to comment
Share on other sites

Sigh ... I cannot detect any effect of CRU bit 23 on the real system. If it would work as shown in the equations and in the diagram, it should only insert 9 WS after the video access. But I always get the same amount of wait states for SBZ 23 or SBO 23.

 

Either the equations are wrong, or my PAL behaves wrong, or the line on my board is broken, or there is another effect that we just don't see.

Link to comment
Share on other sites

34 minutes ago, mizapf said:

Sigh ... I cannot detect any effect of CRU bit 23 on the real system. If it would work as shown in the equations and in the diagram, it should only insert 9 WS after the video access. But I always get the same amount of wait states for SBZ 23 or SBO 23.

 

Either the equations are wrong, or my PAL behaves wrong, or the line on my board is broken, or there is another effect that we just don't see.

 

Is it confirmed that CRU bit 23 is tied to pin 5?  In the PAL equations document, pin 5 and 6 are noted as WE or MEMEN, with a possible 'reversal'.  I still have my Geneve on the bench and will verify a little later this afternoon.

 

On a related note, I will confirm that VDPWAITEN(19) is tied to CRU bit 25.  This bit is used to enable/disable video wait states.

/* PIN06 = WRITE ENABLE */
/* PIN05 = MEMEN */

 

Link to comment
Share on other sites

According to the schematics, PAL pin 5 is connected to the 9901's pin 23 (P7 = bit 23); should be verifiable with a multimeter. The comments at the end of the PLD file are not fully correct (as you see with pin 11).

 

I mean, isn't there on Earth a document about the Gate Array, kept by someone of Myarc? There was a MDOS buyout, but no hardware information included? I just cannot imagine that this information is lost, that someone took it to the grave.

Link to comment
Share on other sites

I am fairly certain the hardware was excluded from Beery's negotiations for the OS and related files.  When Cecure obtained rights to become the official repair/service center for Myarc equipment, we received gate arrays and other hardware.  I don't recall ever seeing or receiving gate array documentation for the Geneve or HFDC.  No source to hardware or software, with possible exception of copyable PALs, was provided.

 

Didn't someone reach out to Lou recently?

 

Anyway, here is what I was able to validate with one exception:  I need to check SNDRDY on another Geneve.  The card I'm working on doesn't seem to match the schematic.

 

1 - CLK (via U203/12)
2 - Write Enable / CRUCLK (DRAM / SRAM / SRAM Expansion + 9995/19)
3 - RDY/SNDRDY (GA#53 + SoundChip/4 + pullupRN)
4 - CSR (GA#55 + Video Read 9938/31)
5 - cru bit 23 (9901/23)
6 - MEMEN (GA#78 + 9995/20)
7 - DBEN (GA#38 + LS245/19)
8 - GA#36 (unknown)
9 - CSW (GA#56 + Video Write 9938/30)
10- 
11-+5/OE
12- WE to bus via U29/6
13- MEMEN to bus via U29/4 
14- NC
15- NC
16- NC
17- NC
18- RDY (9995/23)
19- cru bit 25 Video Wait States (9901/28)
20- 
 

Link to comment
Share on other sites

On 7/30/2019 at 4:55 PM, 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*

 

Do any Geneve software use the 9995's Decrementer?

 

Background

 

The 9995 included a timer/event counter similar to the one on the 9901. The register was memory mapped at >FFFA 

 

Mention of the 9901 Decrementer here:
https://atariage.com/forums/topic/273872-camel99-forth-information-goes-here/?do=findComment&comment=4275848

 

 

I ask because the 99110 does not include the decrementer feature, and is not backwards compatible in that respect.
 

My understanding is that this how to configure the 9995 Decrementer as a timer:

FLAGS  EQU >1EE0       internal CRU flags

TIMER  EQU >FFFA       decrementer memory-mapped internal address

       LI   R2,256     period will be 256 x 1.33 us, because tick is 3Mhz CLKOUT/4
       MOV  R2,@TIMER
       LI   R12,FLAGS
       SBO  0          choose timer, not event counter
       SBO  1          begin running decrementer

 

Link to comment
Share on other sites

The CRU >1EE0 sounds familiar.  Is it possibly used in some XMODEM routines as a timer waiting for a timeout during byte transfers?  If not there, maybe I have seen it in the Eprom source code though it may be just to set a state and not actually used anywhere.

 

I was looking at Tim's PORT source code last night and it seems like I came across that CRU in something when trying to debug the Xmodem upload capability with the TIPI.  I've got downloading working, just struggling with the uploading with a timeout issue I haven't identified yet.

 

Beery

 

  • Like 1
Link to comment
Share on other sites

I guess the number of programs that use the decrementer on the Geneve is comparably low. If you ask me, I would gratefully sacrifice those programs for a TMS99105/TMS99110.

 

The decrementer is typically used when there is no VDP that delivers the 10.738 MHz clock. The cassette routine of the 99/2 makes use of the decrementer, for example.

  • Like 1
Link to comment
Share on other sites

  • 4 years later...
  • 2 weeks later...
On 9/19/2019 at 3:05 PM, mizapf said:

I guess the number of programs that use the decrementer on the Geneve is comparably low. If you ask me, I would gratefully sacrifice those programs for a TMS99105/TMS99110.

 

The decrementer is typically used when there is no VDP that delivers the 10.738 MHz clock. The cassette routine of the 99/2 makes use of the decrementer, for example.

since RickyDean ressurected this thread, I recall that I solved this problem.  Geneve 2020 faults on a write to FFFA, then loads the value into the spare 9901 timer. Not quite equivalent but. 

 

 

 

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...