gilbot
Punkic Cyborg
Posts: 137
|
Post by gilbot on May 29, 2020 8:46:17 GMT
At least (I think) few SCD games (possibly none) would still use the ADPCM buffer to store other data, seeing that an additional 64 KB on top of 256 KB wouldn't help much, and I heard also that you have to be very careful to pull off the ADPCM-data trick, otherwise you'll end up with glitches and data corruptions, etc. (apart from just being slow), so it's not worth the effort in jumping through hoops anymore. Also, by the time the SCD came out more and more games would actually use the ADPCM channel for sound, so the ADPCM buffer RAM was no longer available for other hacks. (Iwasaki mentioned that initially people were having hard time to make the ADPCM samples not sounding like crap unti later, so developers were very reluctant to use ADPCM in early CD games.)
Another dream: IF the arcade card didn't just come with extra DRAM (this can't be helped, as using only SRAM would cost a fortune at that time, as if the actual asking price of arcade card wasn't high enough already) but also brought some update to the SRAM to make it 4Mb in total this could be very useful.
|
|
|
Post by Mathius on May 29, 2020 23:58:15 GMT
At least (I think) few SCD games (possibly none) would still use the ADPCM buffer to store other data, seeing that an additional 64 KB on top of 256 KB wouldn't help much, and I heard also that you have to be very careful to pull off the ADPCM-data trick, otherwise you'll end up with glitches and data corruptions, etc. (apart from just being slow), so it's not worth the effort in jumping through hoops anymore. Also, by the time the SCD came out more and more games would actually use the ADPCM channel for sound, so the ADPCM buffer RAM was no longer available for other hacks. (Iwasaki mentioned that initially people were having hard time to make the ADPCM samples not sounding like crap unti later, so developers were very reluctant to use ADPCM in early CD games.) Another dream: IF the arcade card didn't just come with extra DRAM (this can't be helped, as using only SRAM would cost a fortune at that time, as if the actual asking price of arcade card wasn't high enough already) but also brought some update to the SRAM to make it 4Mb in total this could be very useful. For me, this begs the question, "What 64Kb CD-ROM2 games actually did use the ADPCM available in the then new CD upgrade? I'm curious.
|
|
gilbot
Punkic Cyborg
Posts: 137
|
Post by gilbot on May 30, 2020 7:06:07 GMT
By using ADPCM did you mean using it for data instead of voice samples?
I never investigated, but definitely Monster Lair and Ys 1+2 used this trick. Iwasaki mentioned the president of Alfa System discovered this trick so expect it could be used in a lot of titles.
|
|
|
Post by Black_Tiger on May 30, 2020 15:03:16 GMT
Probably Ys III as well. I don't know how they pulled off that game on only CD2.
|
|
|
Post by turboxray on May 30, 2020 22:04:02 GMT
At least (I think) few SCD games (possibly none) would still use the ADPCM buffer to store other data, seeing that an additional 64 KB on top of 256 KB wouldn't help much, and I heard also that you have to be very careful to pull off the ADPCM-data trick, otherwise you'll end up with glitches and data corruptions, etc. (apart from just being slow), so it's not worth the effort in jumping through hoops anymore. Also, by the time the SCD came out more and more games would actually use the ADPCM channel for sound, so the ADPCM buffer RAM was no longer available for other hacks. (Iwasaki mentioned that initially people were having hard time to make the ADPCM samples not sounding like crap unti later, so developers were very reluctant to use ADPCM in early CD games.) Another dream: IF the arcade card didn't just come with extra DRAM (this can't be helped, as using only SRAM would cost a fortune at that time, as if the actual asking price of arcade card wasn't high enough already) but also brought some update to the SRAM to make it 4Mb in total this could be very useful. While we didn't see an upgrade to the BIOS in the system card after 3.01, later gen games had soft-bios addons/upgrades (basically a library addon) - like faster CD data read routines. There's definitely stuff for accessing ADPCM.. including decompressing LZSS data from ADPCM port to whatever memory (CD ram or directly to VRAM). I mean you can mix-up the ram layout too; use half the 64k ADPCM for samples and the other half for data. Or however you want to divide it. 32k doesn't sound like much, but that could be 3-4 backgrounds in an RPG. Or 256 16x16 sprite cells.. or twelve 32x32 sprites with 5 frames of animation. For 64k of ADPCM, simply double all of that. The Super CD card should have been a 256k upgrade at minimum- not a 192k upgrade. That missing 64k would amount to 25% more main CD RAM over all, and assuming code taking up 32k - that's means ~30% more storage for data in main CDRAM. Some of the things they say in interviews crack me up. As if it needed to be discovered or that it's a trick; it's simply port accessed ram (both read and write). The only trick I know of for ADPCM ram, is that it's the only way to 'DMA' from the CD to RAM without involving the processr, which normally hogs all the processing time polling the CD interface status and/or manually copying bytes the entire time. IIRC, the first Spriggan game does.
|
|
|
Post by Mathius on May 30, 2020 23:13:47 GMT
Spriggan doesn't surprise me. Like BT's Ys III comment, Spriggan looks and smells like a Super CD game through and through. I don't know how Compile did it.
|
|
|
Post by dshadoff on Jun 3, 2020 21:00:26 GMT
UPDATE... I added this information to the issue (thanks for the pointer to the details, elmer !), and Sorgelig reopened it. He then fixed the issue and checked in the code - although his solution requires the US BIOS to remain in original bit sequence. ...This was right after adding support for pachinko controllers... So the next release will contain these fixes (or if you can't wait, you could compile it yourself if you are set up for development). OK, the last update to the core (that was yesterday, I think) did indeed solve this, but required a US-bit-sequenced US BIOS to be in place (which are not so common). Since then, an additional improvement was added, to recognize USA BIOSes in either bit sequence. Since this won't be in an official release for several days, I will post a version here, for the original poster... just unzip and replace the MiSTer file in the root of your MiSTer's SDCard. MiSTer.zip (346.18 KB)
|
|
|
Post by elmer on Jun 3, 2020 21:43:23 GMT
OK, the last update to the core (that was yesterday, I think) did indeed solve this, but required a US-bit-sequenced US BIOS to be in place (which are not so common). Since then, an additional improvement was added, to recognize USA BIOSes in either bit sequence. Do you know what it is in the core that cares whether it is a Japanese Super System Card or a USA Super System Card, I don't understand why the "fix" would care? If the core sets $18C0..$18C7 to sane values, then either version of the BIOS will run properly, and no bit-reversal is needed.
|
|
|
Post by dshadoff on Jun 3, 2020 23:04:16 GMT
The core, up to now, had merely those registers in the way that they are mapped on a PC Engine's System 3.0 card. As you know, the second group ($18C4..C7) need to be bit-reversed for TurboGrafx because that's how they appear on the bus on a System 3.0 card (because they reside on the card itself). You can see the specific commit here: github.com/MiSTer-devel/TurboGrafx16_MiSTer/commit/41b916e416d4a6b49c598eeb164286ea7e652addSo the code needed to map them accordingly, but Sorgelig didn't know enough about the actual cards to detect which was American versus Japanese. His initial implementation keyed in on the text at the end of the card - "(c) NEC Home Electronics" (or something very close to that), and he would detect if the bit-sequence was reversed... because American cards originally were reversed. I gave him a better tactic yesterday - search for "ALL DATA" (part of the warning message for BRAM FORMAT, which only appears in the American version). This way, it doesn't matter whether the ROM is reversed or forward, he can detect the region of the BIOS. github.com/MiSTer-devel/Main_MiSTer/commit/bcff26e588a251c831191076a0fbb56f737217e3Those two repositories are the key places where the MisTer code resides, in case you want to explore it a bit more - the first one is mostly VHDL (and some Verilog) for the FPGA side; the second one is 'C' code for the ARM side of the SoC, which serves mostly framework functions. If you would like to learn more but don't know where to start, I'd recommend looking at the commit log for incremental updates for the past 2 weeks or so; these are mostly very specific fixes and might reveal some information. The good news is that there are currently no known bugs in the core... and a lot of people have been putting it through the wringer too !
|
|
|
Post by elmer on Jun 3, 2020 23:26:41 GMT
As you know, the second group ($18C4..C7) need to be bit-reversed for TurboGrafx because that's how they appear on the bus on a System 3.0 card (because they reside on the card itself). Yes, I know, I wrote about that in my post. I gave him a better tactic yesterday - search for "ALL DATA" (part of the warning message for BRAM FORMAT, which only appears in the American version). This way, it doesn't matter whether the ROM is reversed or forward, he can detect the region of the BIOS. Errr ... sorry, but IMHO that's still an unneccessarily complex way to fix the problem. You don't need to check BIOS versions or anything detailed like that, you just need to set up the 8 register values to what I listed and both versions of the BIOS (and the Arcade Card) will just work properly. That's because instead of pretending that you're a US/Japanese Super System Card HuCard that is plugged into the cartridge port, it is much easier to pretend that you're a DUO/TurboDUO/SuperCDROM/etc, and just indicate (with registers $18C0..$18C3) that you have the extra 192KB of RAM internal in the machine. Then you don't need to do any of that checking for BIOS versions at all.
|
|
|
Post by dshadoff on Jun 3, 2020 23:57:25 GMT
As I mentioned, that's how it was implemented originally, but that simply didn't work for certain titles such as Star Parodia and Downtown Nekketsu Monogatari (as this thread identified in the initial post). That doesn't mean to say I'd solve it in an identical way, but it works now.
UPDATE: OOOOOOOOOHHHHHHHHHH !!!! Now I get it. Let me see what I can do about that.
|
|
|
Post by elmer on Jun 4, 2020 2:03:10 GMT
UPDATE:OOOOOOOOOHHHHHHHHHH !!!!Now I get it. Let me see what I can do about that. I'm glad that you found it before I was ready to post! Yeah, the 1st check-in of cd.vhd was wrong (copied from Mednafen's old settings I suspect), and the latest version isn't much better. It should read something like ... when x"C0" => EXT_DO <= x"00"; when x"C1" => EXT_DO <= x"AA"; when x"C2" => EXT_DO <= x"55"; when x"C3" => EXT_DO <= x"03"; when x"C4" => EXT_DO <= x"FF"; when x"C5" => EXT_DO <= x"FF"; when x"C6" => EXT_DO <= x"FF"; when x"C7" => EXT_DO <= x"FF"; And the specific "00" and "FF" values are *important*, you can't just leave the registers unhandled in the way that cd.vhd was doing. With those settings both the Japanese and USA BIOSs will both work without any need to detect what version of the BIOS you're running.
|
|
|
Post by dshadoff on Jun 4, 2020 2:36:17 GMT
Thanks for this. I understand why you've presented all of the values except for the x"00" when x"C0". I know that writing to x"C0" is used for unlocking the memory, but what is the significance of the value which is read from it ?
|
|
|
Post by elmer on Jun 4, 2020 17:35:25 GMT
I understand why you've presented all of the values except for the x"00" when x"C0". I know that writing to x"C0" is used for unlocking the memory, but what is the significance of the value which is read from it ? You're right, setting up read values for $18C0 and $18C4 doesn't actually seem to be necessary from the code in the Super System Card BIOS, so I'm just being paranoid. Having $18C0 return $00, and $18C4 return $FF is what I see on my DUO-R and TurboDuo. There may be no significance at all to those values, but we don't actually know for sure, and I haven't inspected every single CD game on the platform. Is there a reason not to just set them anyway and thus keep the response the same as the real hardware?
The other thing is that if you're not actually going to support using real physical HuCards on the FPGA, then there's almost-certainly no reason to actually implement the unlocking sequence when writing to $18C0, and you can just permanently activate the 192KB of RAM at banks $68-$7F.
|
|
|
Post by dshadoff on Jun 4, 2020 19:03:36 GMT
I've spoken with Sorgelig, and the current stance - mostly because of the flurry of activity that's been going on for the last several weeks - is that he's not yet inclined to make changes that aren't fixing a problem. That core has been quiet for the past 2 days; perhaps he wants to rest briefly. ...Or maybe he's looking into something interesting like adding savestates... (I think the Gameboy Advance core has these, so it's possible...) I'll keep this handy as an update when things are settled. The $68-$7F RAM bank isn't currently locked/unlocked, but no issues have been logged indicating that it is necessary (echoing your thoughts). At the same time, I don't believe that the Backup RAM segment is locked either - are you aware of any issues which would require the lock on this memory ? (None have been logged so far...) UPDATE:
I was wrong about the new feature he's adding... he's adding the "extra sprites" as an option to reduce the flickering on games like R-Type
|
|