Have you seen this video?

[RXB]

 

[Gary from OPA]

Interesting. I will have to search my archives I have alot of various v9958 documents but I doubt changing the vram bits from 10 to 11 would change the timing of the system.

 

sadly i only have my avpc with the v9938 and not the v9958 chip, i could try on that system and see what happens as well.

 

better these days if building a physical v9958 system is to use static ram there is a few mods out there for that, and gives you a bit more performance instead of waiting for dram cycles, plus if you designed it right might be possible to directly access the sram from cpu side bypassing the slow internal transfer system.

 

on the ti99 with the added wait-states we even run into more bottlenecks, that doing even nice demos like mayhem did on the msx with z80 not possible, without some major hardware changes on the ti99 side.

[+9640News]

Reading the comments from the posted video on youtube, that extra bit does nothing.

[RXB]

6 hours ago, 9640News said:

Reading the comments from the posted video on youtube, that extra bit does nothing.

Does anyone actually know or are they just guessing as the DEMO said they used 11 intead of 00

 

No one has duplicated what that DEMO did.

 

QUOTE: "you could potentially check if a Mayhem demo set it though, even if it wasn't implemented in the emulator."

Why could it not be emulated?

Edited March 2 by RXB

[+9640News]

3 hours ago, RXB said:

Does anyone actually know or are they just guessing as the DEMO said they used 11 intead of 00

 

No one has duplicated what that DEMO did.

 

QUOTE: "you could potentially check if a Mayhem demo set it though, even if it wasn't implemented in the emulator."

Why could it not be emulated?

Mayhem was quoted in the comments as saying it did nothing. 

[RXB]

5 hours ago, 9640News said:

Mayhem was quoted in the comments as saying it did nothing. 

LOL looking at the guys that said it does nothing, first one toggled bit 3 not bit 2 so he did not even do a test of the right bit.

Second one said he did not even watch the entire video and then said it did not work then says something opposite of the documentation!

 

Then there is this one that has the equipment with no reply yet:

@flyguille

2 hours ago

I have my msx2 upgraded to INTERNAL 4mb ram SIMM piggy wired to s1985 and v9958, idd i have 10x spare v9958 chips, brand new. And i have an osciloscope, we can try monitoring the RAS / CAS lines to check if they speed up.

 

 

[+FarmerPotato]

It's just speculation until someone tests the hypothesis. But even if tests show different DRAM timing, it's of no use unless the V9958 somehow frees more access slots for CPU access. 

 

Folks have documented, in  excruciating detail, the exact way the 9938 allocates memory access slots among CPU ports,  reading scan line data, and compositing sprites.
 

There are many reasons why it would not matter if DRAM had faster access time:
 

1. Memory cycles are  documented in the manual. I'm not aware of any 16K/64K distinction--anything?

 

2. Even shaving 50 ns off an access, the 9938 is on a rigid schedule for access slots. I expect the order of slots would be unchanged. 

3. The manual states that the use of the 16K/64K bit is to optimize refresh cycles.
 

Different DRAM require 4ms or 2ms between refresh. So the manual covers how  to get a full refresh in 2ms for the 16K chips-- (I'm still puzzled by those schematics.)

[RXB]

4 hours ago, FarmerPotato said:

It's just speculation until someone tests the hypothesis. But even if tests show different DRAM timing, it's of no use unless the V9958 somehow frees more access slots for CPU access. 

 

Folks have documented, in  excruciating detail, the exact way the 9938 allocates memory access slots among CPU ports,  reading scan line data, and compositing sprites.
 

There are many reasons why it would not matter if DRAM had faster access time:
 

1. Memory cycles are  documented in the manual. I'm not aware of any 16K/64K distinction--anything?

 

2. Even shaving 50 ns off an access, the 9938 is on a rigid schedule for access slots. I expect the order of slots would be unchanged. 

3. The manual states that the use of the 16K/64K bit is to optimize refresh cycles.
 

Different DRAM require 4ms or 2ms between refresh. So the manual covers how  to get a full refresh in 2ms for the 16K chips-- (I'm still puzzled by those schematics.)

The 9938 and 9958 are not the same chip.

Yea the 9938 is very well documented but the post is on the 9958 not the 9938

 

The 9938 is a much older chip then the 9958

The following features were added to or removed from the Yamaha V9938 specifications:

• Added horizontal scrolling registers
• Added YJK graphics modes (similar to YUV😞
  • G7 + YJK + YAE: 256 x 212, 12499 colors + 16 color palette
  • G7 + YJK: 256 × 212, 19268 colors
• Added the ability to execute hardware accelerated commands in non-bitmap screen modes
• Removed lightpen and mouse functions
• Removed composite video output function

[matthew180]

@FarmerPotato pretty much summed it up.  The VDP is a carefully timed state machine that cannot tolerate variation in timing, otherwise the display would be messed up.  If access to the DRAM chips was just a little faster, that does not magically translate into another CPU window after some amount of time.

 

17 hours ago, RXB said:

The 9938 and 9958 are not the same chip.

 

17 hours ago, RXB said:

The 9938 is a much older chip then the 9958

 

They are pretty close, and the 9958 was only release 3 years later and has very few additions (the biggest being horizontal scrolling).  The 9958 datasheet has zero information on DRAM timing, i.e. RAS, CAS, precharge, etc., which means it has to be the same as the 9938, which means its memory access to VRAM is the same.  If the DRAM timing is different between the 9938 and 9958, then, well, I have nothing good to say about Yamaha or these chips, other than that would be pretty f-ed up to not include that in the datasheet.

[+FarmerPotato]

2 hours ago, matthew180 said:

The VDP is a carefully timed state machine that cannot tolerate variation in timing, otherwise the display would be messed up. 

Matthew is someone who would know 🙂 

 

I figured something else while looking at the data sheet today. (wow what a nerd-snipe this has been.) The state transitions in a DRAM access  cycle--RAS falling, rising, write asserted, CAS falling, rising--they happen on intervals much smaller than the 21.477 MHz clock can produce. So those synchronized events must come from an analog delay line.  "Tap points" in a squiggly labyrinth where the signal emerges with different delays. 
 

That's my meager understanding. 
 

I'm not sure that is something you could switch in or out with a digital control bit. 

 

 (The 4A used some extra gates to apply a nudge to memory timing.)

 

 

[RXB]

Have you tested this on a 9958 with a scope or are you just guessing?

 

And did you even watch the video at all?

 

And to be honest over the years we have found all kinds of things NOT DOCUMENTED ON CHIPS or CARDS or DEVICES!

So I am pretty surprised for people saying nothing here as this has been proven many times to be totally wrong.

Hell on ZOOM we talked for an hour on things no one found in documentation of that we now know exists.

[OX.]

Undocumented feature?  Thought it was already a known feature of MSX Turbo R models that could be switched via an MSX Dos command.

Edited March 4 by OX.

[matthew180]

10 hours ago, RXB said:

Have you tested this on a 9958 with a scope or are you just guessing?

 

No, I have not tested on a 9958.  However, I would say we are making educated guesses based on knowing something about this line of VDP chips at a very low level, and knowing something about how DRAM works.

 

10 hours ago, RXB said:

And did you even watch the video at all?

 

Yeah, I sat through the video, designed to stretch a one sentence idea out to 10 minutes, based on nothing.  Here is the summary:

 

"Maybe bit >02 in R8 on the 9958 messes with the DRAM timing a little.  Maybe that means the VDP has a TURBO MODE!!!"

 

10 hours ago, RXB said:

And to be honest over the years we have found all kinds of things NOT DOCUMENTED ON CHIPS or CARDS or DEVICES!

 

Sometimes, sure.  But more times than not those things are side effects of using the hardware in ways not intended by the designers.  If those cases turn out to useful, then great.

 

However, in this specific case, the idea being proposed is that setting bit >02 in R8 will so drastically modify the DRAM timing on the 9958 that is acts like a "turbo mode" for VRAM access.

 

If you know anything about DRAM access or how digital circuits work at all, you can very quickly make a very safe educated guess that this idea is completely wrong.  Changing DRAM access timing will either, 1. break the VDP timing and probably cause all kinds of random behavior, or 2. do nothing at all because the internal state machine running the chip does not modify its timing based on a little faster DRAM access.

 

All the reasons have already been posted, so please read them again slowly and carefully.

 

I am ready to be proven wrong.  I would love to see a trick like this work, because if it does, I would learn some pretty awesome new digital design concepts.

 

13 hours ago, FarmerPotato said:

The state transitions in a DRAM access  cycle--RAS falling, rising, write asserted, CAS falling, rising--they happen on intervals much smaller than the 21.477 MHz clock can produce.

 

It is common to have a clock synthesizer that will make a multi-phase clock.  Not unlike what the 9904 does for the 9900, but internal to the VDP.  Any one phase is still 21.477MHz, but the time between phases would be 1/4, or about 12ns.

[RXB]

I never thought for a second that it speeded up DRAM access, my view was that is eliminated a check routine or bypassed an internal CRC routine.

Or did something like not do read before write routine that is a problem for some TI hardware and Firmware.

 

I just like facts not guesses. Until factually confirmed it is a unknown not known.

Edited March 4 by RXB
Spelling

[+OLD CS1]

55 minutes ago, RXB said:

I just like facts not guesses. Until factually confirmed it is a unknown not known.

While I get this, it is neither outside the ordinary nor unreasonable to apply previous knowledge to a present problem.  It is fair to say that the 9958 core is an evolution of the 9938 core (why re-invent the wheel?), which would imply that much of the same specifications would apply.  As well, if specifications are missing from the later generation, it would be reasonable to infer the specifications from the previous generation apply.

 

Then, go forth into experimentation with a hypothesis in mind, with the mind to disprove that thesis.

[matthew180]

5 hours ago, RXB said:

I never thought for a second that it speeded up DRAM access, ...

 

You might want to re-watch the video then.  The whole "idea" being proposed is that you can use faster DRAMs with your 9958, set bit >02 of R8, and boom, "turbo mode".  And what kind of speed-up he expects, or what "turbo mode" might mean, is not discussed.

 

5 hours ago, RXB said:

... my view was that is eliminated a check routine or bypassed an internal CRC routine.

 

There are really no "checks" or "CRC" routines to be done inside a VDP.  I don't know where you got your view, but the video is not talking about anything like that.

 

5 hours ago, RXB said:

Or did something like not do read before write routine ...

 

Nope, nothing like that going on inside the VDP, and not what was proposed in the video either.

 

5 hours ago, RXB said:

I am just like facts not guesses. Until factually confirmed it is a unknown not known.

 

Until a valid hypothesis is presented, there is nothing to test or confirm.  And since we are talking about undocumented functionality anyway, the only real way to know is to decap a 9958 and reverse engineer it enough to see what bit >02 of R8 actually does.

 

[Gary from OPA]

On 3/4/2024 at 6:21 PM, matthew180 said:

Until a valid hypothesis is presented, there is nothing to test or confirm.  And since we are talking about undocumented functionality anyway, the only real way to know is to decap a 9958 and reverse engineer it enough to see what bit >02 of R8 actually does.

 

I follow a number of Japanese MSX accounts on twitter and one of them recently decapped the v9938 and v9958 and also has obtained high quality die photos and recently been tracing out the v9958 registers and posted this today in regard to the video about this bit.

 

 

Edited May 20 by Gary from OPA

[RXB]

Well question answered. 

Thanks Gary!

[matthew180]

1 hour ago, Gary from OPA said:

I follow a number of Japanese MSX accounts on twitter and one of them recently decapped the v9938 and v9958

 

Oh nice!  Can you provide a link or two?  Do they have any place to read about their work other than "the service formally known as Twitter"?

 

I had someone decap the 9918A and make high resolution die photos for me (posted to whtech), however I have not had the time to learn how to reverse the polygons accurately enough to make any confirmations.  I can see a lot of the big features, registers and such, but otherwise I need to level up my skills (any buy more time, which is currently trading at $1M per share, which is too expensive for me).

 

[Gary from OPA]

On 5/20/2024 at 12:52 PM, matthew180 said:

 

Oh nice!  Can you provide a link or two?  Do they have any place to read about their work other than "the service formally known as Twitter"?

 

I had someone decap the 9918A and make high resolution die photos for me (posted to whtech), however I have not had the time to learn how to reverse the polygons accurately enough to make any confirmations.  I can see a lot of the big features, registers and such, but otherwise I need to level up my skills (any buy more time, which is currently trading at $1M per share, which is too expensive for me).

 

Currently, it is only on twitter, and most of the posts are in Korean, but the GitHub will slowly be updated as each section is figured out.