Hi. I have a V9958 die shot and take a look at how it works. It's not hard to reverse engineer its silicon and it's probably not a special feature. I'll check an address decoder and the register file first, to see if that bit is really used.
@@andyhu9542 Confirmed from the die shot. The register storing that bit exists, but the output doesn't go anywhere. V9938 has the exact same structure. Writing a datum to the register doesn't mean anything.
The thing is, slot timming are tie to ntsc / pal signal timmings, except if is runs the bus x2 twice faster which normal vram chips will output unreliable data, and not being able to draw anything in screen. But it will be measurable in scope and take the advantage soldering chips from SIMM cards which are faster.
This is what I was actually hoping for (again there is a cut section dedicated to that). I was hoping people reporting corrupt screen when switching on High-Speed VRAM. (Sadly, for now there seems be no change) Nowadays a faster and maybe cheaper way is to do a SRAM+ latch swap.
this is fascinating! its kinda awesome to see how many hidden features there are/were in consumer products, especially things like this. excited to see more!
I don't see any changes in any of the signals of the VRAM chips when I toggle the bit. I'm doing it in a MSX2 from basic with VDP(9)=VDP(9) or &B00000100
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.
UPDATE: I tried it out on my SRAM-based card.. my method was not very scientific, I will describe it below. But from what I can tell, setting that bit didn't break anything, but it didn't help either. Step 1: Test with original settings (LDA #%00101000 ;STA VREG;LDA #$88;STA VREG) during cold boot. Screen looks good, not glitchy when scrolling screen in BASIC. Step 2: Keep same setting, comment out NOP's from text screen update function in VBLANK ISR until small glitches occur when scrolling text screen in BASIC. Ended up being -3 NOP's) Step 3: Set Bit 2 in Reg 8 (LDA #%00101100 ;STA VREG;LDA #$88;STA VREG) during cold boot. Noted no obvious change. (Still had the text screen in BASIC, and still had occasional small glitches when scrolling the screen.)
I cut off an entire section from this video about that. Unfortunately, the only demo I can find online is the 1995 apology demo, and it obviously uses the H-scroll and V-scroll register to accomplish its effects. The bit is not used.
Well, there's supposed to be quite a quantity of new-old stock of Yamaha V9958/59s floating around. There has to be _somebory_ willing to hook one up to a chip data analyzer and find out for certain...
I wonder if it would worthwhile to write a test (say against an MSX emulator) that could confirm the function of this bit on real hardware. I'm not sure if the test would work on the emulator though, as it would depend on if the emulator was based on actual hardware reverse engineering or just documentation.
@@andyhu9542 OpenMSX is pretty accurate and ran by hardcode MSX-sceners; if it turns out to be 'a thing', I'm pretty sure it will start supporting it 😇
@@andyhu9542 OpenMSX is usually pretty accurate and also ran by dedicated MSX sceners; if it turns out to be a thing, it will probably start supporting it; if it doesn't already ...
Just a remark: in the original Yamaha docs, it says that bit 3 is used to inform the type of DRAM you're using, whether a 16k x 1 bit or 16k x 4 bits (value 0) or 64k x 1 bit or 64k x 4 bits (value 1), in order to optimize refresh timing. It then goes on to provide many examples of VRAM interfacing, with various memory sizes and configurations, so at least it is aware of all those possibilities. But then, in practice most MSX2 computers, if not all, use exclusively 64k x 4 bits memory, mainly because it needs only four chips to reach 128kB of VRAM. To me the Mayhem doc makes no sense, since we don't need to set bit 2 in any of the current MSX2 and MSX2+ computers. If the meaning of bit 2 is incorrect, it stands to reason that the meaning of the combined bits 2 and 3 is also incorrect. But I'm curious to see how this will eventually turn out.
Did we reach a verdict on this? My DIY V9958 card has one SRAM and a latch instead of DRAMs, and it should be capable of higher speeds if the VDP can do it. (I currently have to insert 7 or more NOP's between writes to the data register.)
I think the verdict is a no. But before the die shot analysis comes out, there is a chance (which I'm not holding out hope for). On the other hand, what frequency are your CPU running at? 7 NOPs are a lot.
@@andyhu9542 The CPU is a HD63C09, and the rate of NOP's is 3.57MHz. (I do have some iffy timing on the /CAS signal, and should have added some gate delay to it. The next rev will have some.) You've inspired me to check the timing diagram and count clock cycles and see if all these NOPs are my fault. :D
@@andyhu9542 the CPU is an HD63C09P with a 14.318MHz crystal (3.57MHz bus clock, NOP rate) Does 7 NOP's seem more reasonable then? I do have iffy timing on the CAS signal. It needs a gate delay, which is planned for the next rev. I hope I can get rid of some NOPs after fixing that issue!
@@andyhu9542 Someone in the MSX scene contacted Mayhem himself and he replied to it. There is a screenshot of it in a MSX WhatsApp group. Secondly, I also wrote MSX testcode to monitor performance of the blitter with the bit set and reset (on a real machine), no difference.
@@andyhu9542Someone in the MSX scene contacted Mayhem himself and he replied to it. There is a screenshot of it in a MSX WhatsApp group. Secondly, I also wrote MSX testcode to monitor performance of the blitter with the bit set and reset (on a real machine), no difference.
@@andyhu9542 Arnaud de Klerk, from The File Hunter and demogroup FONY said so in the MSX Resource Center forum. He is personally acquainted with people from Mayhem, since some of them also were members of FONY. It's possible they have only checked via software, though.
I have msx2 "AX350" , I heard the VDP can be upgraded easily and make it an MSX2+ , is that true?! .. still love the nostalgia with konami games, hyper rally, knightmare, zanac..etc
There wasn't such thing as "kibi bytes" at the time those chips and documents where written. You should have read kilo. That's what was written. MSX computers had 180/360/720kB floppy disks at its disposal following IBM's adopted disk architecture of 40/80 tracks, 1/2 sides, 9 sectors per track, 512 bytes per sector, (yes, FAT12 formatted disks that you can directly open on MS-DOS and windows versions up until it dropped floppy drive support on... Vista? can't remember... boot sector was different, but you can read from or write to without almost any hassle) and a 3.5" 720kB "DOS formatted" disk had 80*2*9*512B=737280B, exactly 720kB. (yes, it's a bit strange that k in kilo is lowercase where every single "greater than zero" multiplier is uppercase, but there's what it is) The same "3.5" 720kB disk" when formatted on a Commodore Amiga featured a whopping 880kB due the possibility of handling 11 sectors per track natively. (80*2*11*512=901120B=880kB) But WHY this (Binary quantity multipliers being multiplied by 2^10 instead of just multiplying by 10) only begun to matter when people begun questioning mass storage device manufacturers about unavailable capacity? why you only have 931GB at your disposal when you bought a 1TB or even a 1000GB (0,976TB) device? sketchy, isn't it? So I'm rebelling and I'm not only don't follow the SI (International System of Units) on this one (I'd have to mentally reprogram myself and I'm not willing to), but I also expect any mass storage vendor to deliver the god damn storage capacity advertised down to the byte.
You have no idea how much I struggled when writing the script for that part. First, memory is usually measured in bits, but most people usually think in bytes. Calling a 16K * 4bit chip a '64K DRAM' would confuse a lot of people, for example. Second, the original document has incorrect wording, '4 * 64KB' should mean 256 kilo/kibi bytes, which is clearly not supported by the V9958. Finally, I can assure you if I used kilo instead of kibi here, there will be way more people in the comment section correcting me for not 'accurately used SI units', and I have to reply to each of them that the notion of kibi/mibi/gibi... was invented later.
As for the storage devices, you can still open 1.44MB ones on Windows 10. I think people also did it on Windows 11. Even older 1.2MB ones work as well (3.5-inch USB drives produced in 2000s are sometimes unreliable and trashes the data though, beware of that). As for hard disks, SSD manufacturers will tell you all about wear and reserved space and all those stuffs and that the storage dies themselves are actually labeled size. But again, why can't they put extra cells in for spares?
@@andyhu9542 My bad. we can still use the disks, only we don't have access to old disk drives unless you have either a USB disk drive or a old motherboard with pci (not pcie) slots (the same kind you can't install Windows 10/11 because there's no longer support for the CPU it supports). Also, some motherboards / USB drivers can't deal with double density disks (5.25" 360k/ 3.5" 720k), just high density ones (5.25" 1.2M/3.5" 1.44M). This is relevant because there's no support for high density disks on MSX disk BIOS routines, a Z80 @ 3.57MHz (with one wait state included during each M1 cycle). From what I saw people commenting, you would actually need a Panasonic FS-A1ST/A1GT on R800 mode as it is fast enough to PIO read/write from/to the drive
Hi. I have a V9958 die shot and take a look at how it works.
It's not hard to reverse engineer its silicon and it's probably not a special feature. I'll check an address decoder and the register file first, to see if that bit is really used.
I'm looking forward this follow-up 😊
I'm also looking forward to this follow-up!
The whole world's watching! And wondering. ;)
@@andyhu9542 Confirmed from the die shot. The register storing that bit exists, but the output doesn't go anywhere. V9938 has the exact same structure. Writing a datum to the register doesn't mean anything.
@@RakiLegacyWorld Wow! That's amazing insight! Thank you for sharing this!
The thing is, slot timming are tie to ntsc / pal signal timmings, except if is runs the bus x2 twice faster which normal vram chips will output unreliable data, and not being able to draw anything in screen. But it will be measurable in scope and take the advantage soldering chips from SIMM cards which are faster.
The other problem , there is no enough cooling performance inside most normal msx2+., if speeding up impact in termals, it will be a no no.
This is what I was actually hoping for (again there is a cut section dedicated to that). I was hoping people reporting corrupt screen when switching on High-Speed VRAM. (Sadly, for now there seems be no change) Nowadays a faster and maybe cheaper way is to do a SRAM+ latch swap.
this is fascinating! its kinda awesome to see how many hidden features there are/were in consumer products, especially things like this. excited to see more!
This sounds like a classic setup for an April 1st prank. But we're only at March 1st today! 😅
Now after you said it, it does sound like a prank... But this video should come up earlier and is meant to be taken with all seriousness.
I don't see any changes in any of the signals of the VRAM chips when I toggle the bit. I'm doing it in a MSX2 from basic with VDP(9)=VDP(9) or &B00000100
Thanks a lot! Unfortunately, this seems to be in agreement with comments made by others.
This is pretty exciting even for a guy who doesn't have this as a hobby
Sure Daniel Padilla from Spain could check this with his equipment
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.
Very interesting lets try.
I wrote a comment, but TH-cam decided to censor it. No clue why :(
UPDATE: I tried it out on my SRAM-based card.. my method was not very scientific, I will describe it below. But from what I can tell, setting that bit didn't break anything, but it didn't help either.
Step 1: Test with original settings (LDA #%00101000 ;STA VREG;LDA #$88;STA VREG) during cold boot. Screen looks good, not glitchy when scrolling screen in BASIC.
Step 2: Keep same setting, comment out NOP's from text screen update function in VBLANK ISR until small glitches occur when scrolling text screen in BASIC. Ended up being -3 NOP's)
Step 3: Set Bit 2 in Reg 8 (LDA #%00101100 ;STA VREG;LDA #$88;STA VREG) during cold boot.
Noted no obvious change. (Still had the text screen in BASIC, and still had occasional small glitches when scrolling the screen.)
Would it be worth looking at the Mayhem demos to see if they're setting that bit?
I cut off an entire section from this video about that. Unfortunately, the only demo I can find online is the 1995 apology demo, and it obviously uses the H-scroll and V-scroll register to accomplish its effects. The bit is not used.
Well, there's supposed to be quite a quantity of new-old stock of Yamaha V9958/59s floating around. There has to be _somebory_ willing to hook one up to a chip data analyzer and find out for certain...
I wonder if it would worthwhile to write a test (say against an MSX emulator) that could confirm the function of this bit on real hardware. I'm not sure if the test would work on the emulator though, as it would depend on if the emulator was based on actual hardware reverse engineering or just documentation.
The problem is, as far as I know, there is no discussion anywhere online about this bit. Therefore, no emulator would implement it.
@@andyhu9542 True, but you could use an emulator to write code against to send to someone with an actual MSX machine with this chip. :)
@@andyhu9542 OpenMSX is pretty accurate and ran by hardcore MSX-scene people; so we'll make sure to check it out !
@@andyhu9542 OpenMSX is pretty accurate and ran by hardcode MSX-sceners; if it turns out to be 'a thing', I'm pretty sure it will start supporting it 😇
@@andyhu9542 OpenMSX is usually pretty accurate and also ran by dedicated MSX sceners; if it turns out to be a thing, it will probably start supporting it; if it doesn't already ...
Cool a youtuber talking about what I know in deep.
Just a remark: in the original Yamaha docs, it says that bit 3 is used to inform the type of DRAM you're using, whether a 16k x 1 bit or 16k x 4 bits (value 0) or 64k x 1 bit or 64k x 4 bits (value 1), in order to optimize refresh timing. It then goes on to provide many examples of VRAM interfacing, with various memory sizes and configurations, so at least it is aware of all those possibilities. But then, in practice most MSX2 computers, if not all, use exclusively 64k x 4 bits memory, mainly because it needs only four chips to reach 128kB of VRAM. To me the Mayhem doc makes no sense, since we don't need to set bit 2 in any of the current MSX2 and MSX2+ computers. If the meaning of bit 2 is incorrect, it stands to reason that the meaning of the combined bits 2 and 3 is also incorrect. But I'm curious to see how this will eventually turn out.
Did we reach a verdict on this? My DIY V9958 card has one SRAM and a latch instead of DRAMs, and it should be capable of higher speeds if the VDP can do it. (I currently have to insert 7 or more NOP's between writes to the data register.)
I think the verdict is a no. But before the die shot analysis comes out, there is a chance (which I'm not holding out hope for). On the other hand, what frequency are your CPU running at? 7 NOPs are a lot.
@@andyhu9542 The CPU is a HD63C09, and the rate of NOP's is 3.57MHz. (I do have some iffy timing on the /CAS signal, and should have added some gate delay to it. The next rev will have some.) You've inspired me to check the timing diagram and count clock cycles and see if all these NOPs are my fault. :D
@@andyhu9542 the CPU is an HD63C09P with a 14.318MHz crystal (3.57MHz bus clock, NOP rate) Does 7 NOP's seem more reasonable then? I do have iffy timing on the CAS signal. It needs a gate delay, which is planned for the next rev. I hope I can get rid of some NOPs after fixing that issue!
Info has that Mayhem has been contacted and the bit is useless... It doesn't do anything.
Do you know the source for the info?
@@andyhu9542 Someone in the MSX scene contacted Mayhem himself and he replied to it. There is a screenshot of it in a MSX WhatsApp group.
Secondly, I also wrote MSX testcode to monitor performance of the blitter with the bit set and reset (on a real machine), no difference.
@@andyhu9542Someone in the MSX scene contacted Mayhem himself and he replied to it. There is a screenshot of it in a MSX WhatsApp group.
Secondly, I also wrote MSX testcode to monitor performance of the blitter with the bit set and reset (on a real machine), no difference.
@@andyhu9542 Arnaud de Klerk, from The File Hunter and demogroup FONY said so in the MSX Resource Center forum. He is personally acquainted with people from Mayhem, since some of them also were members of FONY. It's possible they have only checked via software, though.
@@andyhu9542MRC forum.
I have msx2 "AX350" , I heard the VDP can be upgraded easily and make it an MSX2+ , is that true?! .. still love the nostalgia with konami games, hyper rally, knightmare, zanac..etc
Yeah, probably. There are some traces that need to be changed though to match the pinout of the V9958, but nothing prohibitively difficult.
I don't know what you are saying but I sure like the way you are saying it - Peter Quill's Mom probably
Silicon archaeology at it's best.
There wasn't such thing as "kibi bytes" at the time those chips and documents where written. You should have read kilo. That's what was written.
MSX computers had 180/360/720kB floppy disks at its disposal following IBM's adopted disk architecture of 40/80 tracks, 1/2 sides, 9 sectors per track, 512 bytes per sector, (yes, FAT12 formatted disks that you can directly open on MS-DOS and windows versions up until it dropped floppy drive support on... Vista? can't remember... boot sector was different, but you can read from or write to without almost any hassle) and a 3.5" 720kB "DOS formatted" disk had 80*2*9*512B=737280B, exactly 720kB. (yes, it's a bit strange that k in kilo is lowercase where every single "greater than zero" multiplier is uppercase, but there's what it is)
The same "3.5" 720kB disk" when formatted on a Commodore Amiga featured a whopping 880kB due the possibility of handling 11 sectors per track natively. (80*2*11*512=901120B=880kB)
But WHY this (Binary quantity multipliers being multiplied by 2^10 instead of just multiplying by 10) only begun to matter when people begun questioning mass storage device manufacturers about unavailable capacity? why you only have 931GB at your disposal when you bought a 1TB or even a 1000GB (0,976TB) device? sketchy, isn't it? So I'm rebelling and I'm not only don't follow the SI (International System of Units) on this one (I'd have to mentally reprogram myself and I'm not willing to), but I also expect any mass storage vendor to deliver the god damn storage capacity advertised down to the byte.
You have no idea how much I struggled when writing the script for that part. First, memory is usually measured in bits, but most people usually think in bytes. Calling a 16K * 4bit chip a '64K DRAM' would confuse a lot of people, for example. Second, the original document has incorrect wording, '4 * 64KB' should mean 256 kilo/kibi bytes, which is clearly not supported by the V9958. Finally, I can assure you if I used kilo instead of kibi here, there will be way more people in the comment section correcting me for not 'accurately used SI units', and I have to reply to each of them that the notion of kibi/mibi/gibi... was invented later.
As for the storage devices, you can still open 1.44MB ones on Windows 10. I think people also did it on Windows 11. Even older 1.2MB ones work as well (3.5-inch USB drives produced in 2000s are sometimes unreliable and trashes the data though, beware of that). As for hard disks, SSD manufacturers will tell you all about wear and reserved space and all those stuffs and that the storage dies themselves are actually labeled size. But again, why can't they put extra cells in for spares?
@@andyhu9542 I can still read & write MSX DD 720kB floppies on my external USB HDD on Win11 Pro...
@@andyhu9542 My bad. we can still use the disks, only we don't have access to old disk drives unless you have either a USB disk drive or a old motherboard with pci (not pcie) slots (the same kind you can't install Windows 10/11 because there's no longer support for the CPU it supports). Also, some motherboards / USB drivers can't deal with double density disks (5.25" 360k/ 3.5" 720k), just high density ones (5.25" 1.2M/3.5" 1.44M). This is relevant because there's no support for high density disks on MSX disk BIOS routines, a Z80 @ 3.57MHz (with one wait state included during each M1 cycle). From what I saw people commenting, you would actually need a Panasonic FS-A1ST/A1GT on R800 mode as it is fast enough to PIO read/write from/to the drive
@@Dawwwg USB disk drives are one of the best things if you're into old computers
great