+mizapf Posted September 15, 2019 Share Posted September 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted September 15, 2019 Share Posted September 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted September 15, 2019 Share Posted September 15, 2019 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 */ Quote Link to comment Share on other sites More sharing options...
+mizapf Posted September 15, 2019 Share Posted September 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted September 15, 2019 Share Posted September 15, 2019 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- Quote Link to comment Share on other sites More sharing options...
+9640News Posted September 15, 2019 Share Posted September 15, 2019 The MDOS buyout only focused on the software. Nothing on the hardware. I did reach out to Lou. He was going to look at his stuff as time permitted. That could be months or more. 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted September 15, 2019 Share Posted September 15, 2019 Maybe just in time for Christmas? 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted September 19, 2019 Author Share Posted September 19, 2019 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 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted September 19, 2019 Share Posted September 19, 2019 1 hour ago, FarmerPotato said: Do any Geneve software use the 9995's Decrementer? Not the Geneve but the 99/2 and the Tomy Tutor, possibly other 9995 arcade systems. 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted September 19, 2019 Share Posted September 19, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted September 19, 2019 Share Posted September 19, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted September 19, 2019 Share Posted September 19, 2019 4 hours ago, BeeryMiller said: The CRU >1EE0 sounds familiar. But it must be bit 0 or bit 1 to be relevant with respect to the decrementer. The base address 1EE0 does appear here and there, right, typically for the other flags, I guess. Quote Link to comment Share on other sites More sharing options...
RickyDean Posted December 27, 2023 Share Posted December 27, 2023 Is the Pal that was posted here on page 1 the final one? Would the Pal.circ file burn as a jedec file, or does it need further refinement? Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 8 Author Share Posted January 8 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.