fragmare
Punkic Cyborg
Posts: 116
Homebrew skills: Graphics, Music, Level Design, Annoying Programmers
|
Post by fragmare on Mar 5, 2019 22:54:55 GMT
EDIT: never mind, i forgot who i'm asking. lol
|
|
|
Post by elmer on Mar 7, 2019 0:40:17 GMT
I've checked what the registers at $18C0..$18C7 return on Duo-R, a TurboDuo, and a CoreGrafx (just for comparison). The values for the 8 bytes should be 00 AA 55 03 FF FF FF FF. Even *more* interesting, I found some definitions in a Japanese header file that help to explain those registers, and exactly *why* the ex_memopen functions in the US and Japanese Super System Cards function the way that they do (and why they are different). Registers $18C0..$18C3 are for the internal SCD memory built into the Duo & SuperCDROM2 hardware. Registers $18C5..$18C7 are for the external SCD memory built into the Japanese and US Super System Cards. The hardware in the US Super System Card is identical to the hardware in the Japanese Super System Card, and so reading any ports on the card will give reversed bits because of the swapping of the data lines on the US cartridge port. That's why the Turbografx Super System Card checks $18C5/$18C6 for $55 & $AA, instead of Japanese Super System Card checking for $AA & $55. It also explains what ex_memopen is returning in the X register, and *why* it sets bit 7 of X if it detects internal memory. The value in bits 0..6 of X is the amount of SCD memory in 64Kbyte increments. Bit 7 is used to differentiate whether a Duo/SuperCDROM2 has found SCD memory in a cartridge (from $18C5..$18C7) or in internal memory (from $18C1..$18C3), so that it doesn't unlock the internal memory if it is using external memory instead. Phew ... that's probably just boring gobbledegook to most folks, but it totally clears up my understanding of exactly how the SCD memory works on all of the different PCE/TGX hardware variations, and it shows just how thoughtful the designers at Hudson/NEC were being. Neat!
|
|
|
Post by dshadoff on Mar 7, 2019 1:01:06 GMT
Wait... the count is in 64KB units, yet 6 bits are accommodated ? You're saying that the regular SuperCD number would be 3 (or perhaps 4 if regular CD ROM mem is counted) ?
|
|
|
Post by elmer on Mar 7, 2019 1:55:57 GMT
Wait... the count is in 64KB units, yet 6 bits are accommodated ? You're saying that the regular SuperCD number would be 3 (or perhaps 4 if regular CD ROM mem is counted) ? Yep, the value to use is read from the internal memory/cartridge itself, from either $18C3 or $18C7. So larger external memory cartridges are allowed for in the design, and would be used instead of the internal memory on a Duo. The value is 3 for the Super System Card, because it has 192KB of RAM (in cartridge space). It's probably only using bit 7 for the internal/external reporting because bit 7 is so easy to check for. It's hard to imagine that they really planned for allowing the cartridge to report up to 8MBytes of RAM!
|
|
|
Post by dshadoff on Mar 7, 2019 2:04:14 GMT
yeah, but how did they plan to support the maximum amount ? ...I guess that's left as "to be specified"...
|
|
|
Post by elmer on Mar 7, 2019 2:18:35 GMT
yeah, but how did they plan to support the maximum amount ? ...I guess that's left as "to be specified"... I'm more interested in why certain games are checking that return value to make sure that it is 3 or larger (for 192KB). Were some developers ever given cards with 64KB or 128KB? I wonder if there was a plan for a 512KB card at some point (before they went with the DRAM-based Arcade Card instead)?
|
|
gilbot
Punkic Cyborg
Posts: 137
|
Post by gilbot on Mar 7, 2019 3:39:37 GMT
I wonder if there was a plan for a 512KB card at some point (before they went with the DRAM-based Arcade Card instead)? Yes. You may get an idea from the various notes Iwasaki made about the development of Far East of Eden II. The abridged version is roughly like this: - They wanted to put out another killer soft to rival with the coming Super Famicom.
- They settled on a sequel of Far East of Eden, but felt that the awful disc accesses in the first game was frustrating. Also, when developing Ys I+II they already capped out the system's storage by using even the 64kb ADPCM buffer for data, so a memory upgrade was essential.
- They wanted to have a large map loaded and at the same time all the battle stuff so that there would be no disc access in between and enabled them to have a CDDA track as the field music.
- They wanted to have 4Mb(i.e. 512KB) which was the limit of SRAM they could put on the card but knew that it could be expensive.
- Then Iwasaki went on to brainstorm with the creative minds of Red about the game, with the memory expansion in mind, but not knowing how much RAM they could use at the end.
- later, Nakamoto Shinichi told them that 4Mb was out of the question as the card would then cost 10,000 yen, so they were left with the choices of 1Mb or 2Mb. 1Mb was obviously not good enough so they settled with 2Mb.
If they had chosen 4MB I think the game could have retained the battle backgrounds like in the first game. I always wonder what would happen if the Arcade Card was made with RAM that could be bank switched directly into the main memory map like regular Hucards or the Super CD (though the result was obviously due to cost). One use I could think of is to have quickly accessible HUGE look-up tables for whatever reasons(maybe for 3-D?).
|
|
fragmare
Punkic Cyborg
Posts: 116
Homebrew skills: Graphics, Music, Level Design, Annoying Programmers
|
Post by fragmare on Mar 7, 2019 6:14:52 GMT
I just know, from my days on the high seas, that there didn't used to be a verified [!] dump of the US ROM. You are one of the old-timers that have been contibuting to the PCE scene for many, many years! That's something worthy of great respect. It is the continued interest and very existence of the original fans that keeps the memory of the PCE alive in a country that only seems to care about Nintendo (and *maybe* Sega). Uhh, thanks? I guess?
|
|
|
Post by elmer on Mar 8, 2019 0:22:04 GMT
EDIT: never mind, i forgot who i'm asking. lol Hahaha ... are you really going to be grumpy that the 3 programmers in this thread didn't immediately drop everything that they had going on in their lives in order to search for Bonknuts's bug within the first 36hrs of you posting the problem? You may get an idea from the various notes Iwasaki made about the development of Far East of Eden II. Thank you for posting all those interesting links! Unfortunately Google Translate really did a poor job on that blog, so I could only make out enough of what Iwasaki was saying to see that he was talking about the same events that you detailed. I've mentioned this before ... the history of the whole computing/games industry in the 1980s and early 1990s was tightly coupled to the price and availability of RAM. Especially the cost of the expensive SRAM chips, since a lot of CPUs couldn't easily use the cheaper DRAM chips. Each generation of consoles was tied to the die-shrinks in RAM production ... from 16Kbit chips (2Kbytes), to 64Kbit chips (8KBytes), to 256Kbit chips (32KBytes), to 1Mbit chips (128KBytes). I always wonder what would happen if the Arcade Card was made with RAM that could be bank switched directly into the main memory map like regular Hucards or the Super CD (though the result was obviously due to cost). One use I could think of is to have quickly accessible HUGE look-up tables for whatever reasons(maybe for 3-D?). I really doubt that it would have made much of a practical difference in the end, because (IMHO) you still have plenty of SCD memory available as well for things that need truly random-access ... but we'll never really know unless someone writes something new that really tries to stretch the limits of the ACD system, and can then report back.
|
|
fragmare
Punkic Cyborg
Posts: 116
Homebrew skills: Graphics, Music, Level Design, Annoying Programmers
|
Post by fragmare on Mar 8, 2019 5:39:32 GMT
EDIT: never mind, i forgot who i'm asking. lol Hahaha ... are you really going to be grumpy that the 3 programmers in this thread didn't immediately drop everything that they had going on in their lives in order to search for Bonknuts's bug within the first 36hrs of you posting the problem? No, I took the link down because no one was going to look at it. I'll figure it out myself. Your dismissive and condescending posturing earlier in this thread was a little irritating, though.
|
|
|
Post by elmer on Mar 8, 2019 20:26:29 GMT
No, I took the link down because no one was going to look at it. Isn't that a rather self-fulfilling prophecy? Your dismissive and condescending posturing earlier in this thread was a little irritating, though. If you want to see it that way, then that's up to you, but I was actually trying to be polite in the face of a specious argument. You're in good company though ... Arkhan finds me irritating, too.
|
|
fragmare
Punkic Cyborg
Posts: 116
Homebrew skills: Graphics, Music, Level Design, Annoying Programmers
|
Post by fragmare on Mar 8, 2019 20:54:28 GMT
No, I took the link down because no one was going to look at it. Isn't that a rather self-fulfilling prophecy? Some things can be deduced without being a psychic. You're in good company though ... Arkhan finds me irritating, too. Shocker...
|
|
|
Post by ccovell on Mar 9, 2019 4:40:23 GMT
C'mon, guys, Elmer was being humorous, not condescending. (Though when one is in a bad mood, one will never take any joke.)
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 11, 2019 2:52:26 GMT
Anyway, fighting aside we've fixed the Raiden Anniversary patch. Bonknuts was jumping directly to the JP address for EX_JOYSNS instead of JSR into the BIOS jumptable. Fraggy's fixing up the OST and will release it later.
|
|
|
Post by elmer on Mar 11, 2019 3:33:19 GMT
I'm glad that you could help out and get it fixed!
|
|