Geneve WHT Turbo Video Upgrade

[Shift838]

I found this on Fabrice Montupet's site (ti99.com/geneve/index.php?fr/article26/wht-turbo-video-chip).  This upgrade talks about a video upgrade that was released by WHT.  Basically, a video accelerator and all you need to do is replace the PAL IC (U202).  It stated the Turbo Video upgrade will inchrease video performance by about 20% depending on graphics mode used.  The page also states that some first-generation Geneve 9640 cards are not compatible.  How can we tell what generation we have?

 

Has anyone done this upgrade?  Do we know if we have the GAL code somewhere?

 

 

 

Edited January 11 by Shift838

[RickyDean]

10 minutes ago, Shift838 said:

I found this on Fabrice Montupet's site (ti99.com/geneve/index.php?fr/article26/wht-turbo-video-chip).  This upgrade talks about a video upgrade that was released by WHT.  Basically, a video accelerator and all you need to do is replace the PAL IC (U202).  It stated the Turbo Video upgrade will inchrease video performance by about 20% depending on graphics mode used.  The page also states that some first-generation Geneve 9640 cards are not compatible.  How can we tell what generation we have?

 

Has anyone done this upgrade?  Do we know if we have the GAL code somewhere?

 

 

 

This may still be a purchase part, see https://www.whtech.com/ti/ for possible details. I would like the Jedec equation to the regular pal chip, have received the .circ file, but don't know how to utilize it yet. You can ask @Jeff White, he is the founder of whtech, I believe.

Edited January 11 by RickyDean
additional content

[Shift838]

16 minutes ago, RickyDean said:

This may still be a purchase part, see https://www.whtech.com/ti/ for possible details. I would like the Jedec equation to the regular pal chip, have received the .circ file, but don't know how to utilize it yet.

I'll contact Don then.

[+9640News]

I remember I was one of the first individuals to test the chip on a GenMOD Geneve.  It involved removing VDP wait states.  The very "original" had too many wait states removed for a GenMOD Geneve and they had to add some additional wait states back.  It was still a bit faster and measureable wihen graphic modes (Graphics mode 6 comes to mind) were utilized.

 

 

[Don O'Neil]

 Yes, it was a process to dial it in for various systems, but in the end there was about a 20% boost in performance. Since nobody is actively making them, I've decided to put it in the public domain. Attached are the PLD and JEDEC files for anyone who wants to try to make one for themselves. Thanks to @Jeff White for doing the initial footwork on this over 30 years ago!!

 

TURBOVID.JED TURBOVID.PLD

Edited January 12 by Don O'Neil

[Shift838]

2 hours ago, Don O'Neil said:

 Yes, it was a process to dial it in for various systems, but in the end there was about a 20% boost in performance. Since nobody is actively making them, I've decided to put it in the public domain. Attached are the PLD and JEDEC files for anyone who wants to try to make one for themselves. Thanks to @Jeff White for doing the initial footwork on this over 30 years ago!!

 

TURBOVID.JED 1.61 kB · 4 downloads TURBOVID.PLD 1.5 kB · 3 downloads

Thanks Don!

 

Do we know how to determine which board versions of the Geneve this upgrade will and will not work on?

[Shift838]

Thanks to @Fritz442here is a file already converted to be used with a GAL16V8.

 

TURBOVID_GAL.JED

[+mizapf]

Is there a recommended GAL/EPROM programmer? (I mean, one that does not require a Centronics interface and running MSDOS.)

[Shift838]

2 minutes ago, mizapf said:

Is there a recommended GAL/EPROM programmer? (I mean, one that does not require a Centronics interface and running MSDOS.)

I use my TL866 Plus to program them.

[RickyDean]

1 hour ago, Shift838 said:

I use my TL866 Plus to program them.

Same with my TL966A

[+dhe]

Thanks @Don O'Neil that's one less chip that's an end for a Geneve!

[+mizapf]

Don said that the Geneve PAL equations were derived by reverse engineering form Jeff White. Are we sure that the equations are correct, actually?

 

The thing is that hoped to improve the video read/write timing in MAME with it. In particular, the video wait states during write accesses differ from the real machine. However, the PAL equations did not really help. This is my comment in the code:

 

The video write wait state handling is still not correct. Unfortunately,
the equations of the PAL did not help, in contrast, the problem got worse.
Problem: After initiating a video write (CSW*=0), the READY line must
remain high for the next falling clock edge so that the CPU can complete
the command cycle. By these equations, the READY line immediately goes
low when the clock line rises, and thus on the falling edge, a wait state
is produced.
The effect is that in the real machine, if all code runs in on-chip memory,
a video write does not cause any wait state, while in this emulation, it
always causes the full 14 cycles of wait states. In rare situations, this
may heavily slow down the processing.

 

A full discussion may be seen on https://www.ninerpedia.org/wiki/Geneve_video_wait_states

[Shift838]

3 hours ago, mizapf said:

Don said that the Geneve PAL equations were derived by reverse engineering form Jeff White. Are we sure that the equations are correct, actually?

 

The thing is that hoped to improve the video read/write timing in MAME with it. In particular, the video wait states during write accesses differ from the real machine. However, the PAL equations did not really help. This is my comment in the code:

 

The video write wait state handling is still not correct. Unfortunately,
the equations of the PAL did not help, in contrast, the problem got worse.
Problem: After initiating a video write (CSW*=0), the READY line must
remain high for the next falling clock edge so that the CPU can complete
the command cycle. By these equations, the READY line immediately goes
low when the clock line rises, and thus on the falling edge, a wait state
is produced.
The effect is that in the real machine, if all code runs in on-chip memory,
a video write does not cause any wait state, while in this emulation, it
always causes the full 14 cycles of wait states. In rare situations, this
may heavily slow down the processing.

 

A full discussion may be seen on https://www.ninerpedia.org/wiki/Geneve_video_wait_states

So if I interpret what you are saying is this would not be a problem on a real-iron Geneve?

[+dhe]

FWIW - Don gave me one of the very first Turbo PALs. I ran it for two or three years pretty hard, and never had a problem.

[+mizapf]

8 hours ago, Shift838 said:

So if I interpret what you are saying is this would not be a problem on a real-iron Geneve?

I'm talking about the original PAL on the Geneve, and about my hopes to improve the timing in MAME. Previously, before knowing about the equations, I tried to emulate the wait state generation by observation. Except for write operation which were one wait state off, everything was precise.

 

Now with the equations from Don, I thought that I could fix the remaining differences, but this was not the case, it became worse. I can write a test program that shows a visibly different run time on the real iron and on MAME.

 

So there are two possibilities for me:

 

1. There is an error in the equations of the original PAL. What one could do is to burn a GAL with those equations and check the wait states on a real Geneve (with my test program). Maybe I should do it myself, but this requires me to get a programmer tool like this TL866.

 

2. I still have not fully understood the behavior of the 9995 with respect to wait states.

[+9640News]

2 hours ago, mizapf said:

I'm talking about the original PAL on the Geneve, and about my hopes to improve the timing in MAME. Previously, before knowing about the equations, I tried to emulate the wait state generation by observation. Except for write operation which were one wait state off, everything was precise.

 

Now with the equations from Don, I thought that I could fix the remaining differences, but this was not the case, it became worse. I can write a test program that shows a visibly different run time on the real iron and on MAME.

 

So there are two possibilities for me:

 

1. There is an error in the equations of the original PAL. What one could do is to burn a GAL with those equations and check the wait states on a real Geneve (with my test program). Maybe I should do it myself, but this requires me to get a programmer tool like this TL866.

 

2. I still have not fully understood the behavior of the 9995 with respect to wait states.

Not knowing when you may have acquired your Geneve, any testing on a real Geneve should have confidence which PAL is in the Geneve.  I know I acquired that update, but I do not have that Geneve.  As far as my current Geneve's, I have no idea if any were updated as they were second hand.

[+InsaneMultitasker]

On 1/11/2024 at 2:42 PM, Shift838 said:

The page also states that some first-generation Geneve 9640 cards are not compatible.  How can we tell what generation we have?

@Jeff White do you recall any specific concerns from your long-ago research that might shed light on this comment? 

 

@Shift838 I am not aware of any board-specific differences that would suggest any "first generation" differences.  There was nothing indicated by Myarc/Lou when the repair/rights were transferred to Cecure, and there is nothing that I or Cecure accounted for when repairing or updating cards.  While there certainly could be a difference, it's not (well) documented if it exists. 

[RickyDean]

I would think that there maybe a few Geneve's, like the one  @Ksarul said that he had. He stated he had one that did not use the gate array, but logic chips instead, maybe these where the early generation? 

Edited January 14 by RickyDean

[+Ksarul]

47 minutes ago, RickyDean said:

I would think that there maybe a few Geneve's, like the one  @Ksarul said that he had. He stated he had one that did not use the gate array, but logic chips instead, maybe these where the early generation? 

My odd one is actually a prototype, not a production model. I know of just one other prototype in the wild (in Germany), identical to mine.

[suberbanator]

On 1/14/2024 at 12:58 AM, Ksarul said:

My odd one is actually a prototype, not a production model. I know of just one other prototype in the wild (in Germany), identical to mine.

Would love to see a high resolution picture of it

[Jeff White]

On 1/11/2024 at 3:52 PM, RickyDean said:

This may still be a purchase part, see https://www.whtech.com/ti/ for possible details. I would like the Jedec equation to the regular pal chip, have received the .circ file, but don't know how to utilize it yet. You can ask @Jeff White, he is the founder of whtech, I believe.

@Don O'Neil is the founder of Western Horizon Technologies.  I came up with “We Harness Technology”.  Reading through this thread may jog my memory.

[RickyDean]

13 minutes ago, Jeff White said:

@Don O'Neil is the founder of Western Horizon Technologies.  I came up with “We Harness Technology”.  Reading through this thread may jog my memory.

I understand, to have the Jed would be useful for others. There is a member here who can take a good PAL and decode it and he has decoded this one, I've been testing today. We were waiting on good testing before seeing if he could release it into the wild, here on Atariage. 

Edited January 19 by RickyDean
added content

[Jeff White]

@mizapf, @InsaneMultitasker, the Geneve PAL is not protected.  @Don O'Neil or, less likely, I read it out.  @Swim has my programmer and maybe the original equations from Myarc.

 

What I reverse-engineered was what the PAL was doing.  As I recall, some of the critical timing depended on how the gate array tweaked 9995 signals for reads and writes.

[RickyDean]

42 minutes ago, Jeff White said:

@mizapf, @InsaneMultitasker, the Geneve PAL is not protected.  @Don O'Neil or, less likely, I read it out.  @Swim has my programmer and maybe the original equations from Myarc.

 

What I reverse-engineered was what the PAL was doing.  As I recall, some of the critical timing depended on how the gate array tweaked 9995 signals for reads and writes.

I figured the original was a Myarc product and that you or Don had the rights to the Turbo version. I did not know the original was not read protected, never tried it.

Edited January 19 by RickyDean
spelling

[Shift838]

I have updated 3 Geneve 9640s with the WHT Turbo upgrade over the last couple of weeks.