Sega CD thread? Sega CD thread. I've been digging through this... interesting add-on, and wanted to share some stuff I came across. Some stuff probably has been documented in the past, and I missed it, but regardless, I do think it should be talked about more. Let's start off with... A Bug with SCDPQ/SCDPQL (US Model 1/2 BIOS, Possibly More) So, these 2 BIOS functions are supposed to retrieve the P and Q subcode data for the current sector being processed. But, there is a bug that causes slight corruption, at least in the US model 1/2 BIOS revisions. I have no idea if this was fixed in any other revisions, but this bug exists here. According to the manual, this is the expected result: Note the "P" flag entry. That's the P subcode flag. Everything else is from the Q subcode data. As it is stated, there are 3 Q subcode data modes that dictate what the data contains and how it's arranged. Mode 1 basically describes the current track/sector, mode 2 describes the catalogue number, and mode 3 describes the ISRC code. The "P" flag's location depends on this mode, due to the varying data lengths, and the BIOS tries to take that into account, but fails. Let's see what it does... Code (Text): move.b 0(a1),d1 ; Get Q subcode data mode andi.b #$F,d1 cmpi.b #1,d1 ; Is it mode 1? beq.s .Mode1 ; If so, branch cmpi.b #2,d1 ; Is it mode 2? beq.s .Mode1 ; If so, branch (BUG: WRONG LABEL!) cmpi.b #3,d1 ; Is it mode 3? beq.s .Mode1 ; If so, branch (BUG: WRONG LABEL!) bra.s .StoredPFlag ; If it's none of the above, skip ; --------------------------------------------------------------------------- .Mode1: move.b d0,6(a1) ; Store P subcode flag for mode 1 bra.s .StoredPFlag ; --------------------------------------------------------------------------- .Mode2: ; UNREFERENCED! move.b d0,8(a1) ; Store P subcode flag for mode 2 bra.s .StoredPFlag ; --------------------------------------------------------------------------- .Mode3: ; UNREFERENCED! move.b 8(a1),d1 ; Store P subcode flag for mode 3 andi.b #$F0,d1 andi.b #$F,d0 or.b d1,d0 move.b d0,8(a1) ; --------------------------------------------------------------------------- .StoredPFlag: Oh dear. Yeah, looks like they just copied and pasted the checks for modes 2 and 3... but forgot to change the label to go to the correct code. As a result, if you wanted to get the catalogue number or ISRC code for whatever reason, I hope you enjoy it being slightly corrupted! The Curious Case of the Initial Program Loader So, if you've ever looked at the leaked official Sega CD documentation, you may have come across this and probably thought that it didn't make much sense at all. Turns out, this page is mainly just speculation on how the BIOS loads the initial program (IP). While the step to change the IP load address is actually correct, the reasoning for it isn't. Let's take a look at the BIOS (the behavior I am about to explain applies to all BIOS revisions). First, let's take a look at how it reads the IP load parameters and uses them to load the IP on the Sub CPU side. Code (Text): loadInitialProgram: movea.l ipDstAddress(a5), a0 bsr.w copySector0 move.l a0, dataBufferAddress(a5) movea.l bootHeaderAddress(a5), a0 movea.l SYSTEMHEADER.ipAddress(a0), a1 cmpa.l #$200, a1 bne.s loc_3C80 cmpi.l #$600, SYSTEMHEADER.ipSize(a0) bne.s loc_3C80 bra.w loc_3C88 ; --------------------------------------------------------------------------- loc_3C80: ; Read IP from disc ; d1 is most likely $FFFF if we get here, so we read 32 sectors (64 KiB) bsr.w readSectorsFromDisc ; Jump back if error bcs.w loc_3A84 First, it calls copySector0: Code (Text): ; Copy bytes $200-$7FF (relative to bootHeaderAddress) copySector0: movea.l bootHeaderAddress(a5), a1 adda.w #$200, a1 move.w #95, d1 @loc_3DC8: move.l (a1)+, (a0)+ move.l (a1)+, (a0)+ move.l (a1)+, (a0)+ move.l (a1)+, (a0)+ dbf d1, @loc_3DC8 rts ; End of function copySector0 Which loads the data from $200-$7FF in the first CD sector into the top of Word RAM. It does this no matter what. The next set of code checks if the IP load address is $200 and if the IP load size is $600. If both conditions are met, the procedure is done. However, if either one of those parameters are changed, it'll loads 32 sectors (64 KiB) of data, starting from the top of the sector where the IP load address is set in. This effectively makes the IP loading parameters more IP extension loading parameters. This also means that the IP load size does pretty much absolutely nothing. The last loading bit happens on the Main CPU side, where it transfers the data stored in Word RAM into Genesis RAM to be executed. Code (Text): @loc_687A: move.w #$1FFF, d0 lea ($FFFF0000).l, a1 lea (WordRAM_Bank0).l, a0 ; Copy from WordRAM to $FF0000-$FF8000 (32 KiB) @loc_688A: move.l (a0)+, (a1)+ dbf d0, @loc_688A It copies 32 KiB from there, no matter what. So, in conclusion, for loading the IP, if it's less than or equal to $600 bytes, then just store it at $200 in the CD image, and set the IP load address to $200, and the IP load size to $600. If it's any larger, set the IP load address to $800, so that it will load the data after the first sector. The maximum size of the IP is 32 KiB. IP load size can be left alone. It is also possible to split up the IP by storing the first $600 bytes in the first sector at $200, and placing the rest of the IP at the start of another sector, but quite frankly, there is absolutely no reason to do that.
How Mode 1 Actually Works Let's talk about how Mode 1 on the Sega CD actually works. Hint: it's more than "CD audio in cartridge games" Basically, it boils down to the /CART pin on the cartridge port. According this page on Plutiedev, this pin basically dictates how the Genesis' 68000 address space is arranged in regards to the cartridge and expansion port. If it is pulled low, then the cartridge memory is placed into 0x000000-0x3FFFFF, with the expansion memory being placed in 0x400000-0x7FFFFF. If not, they're swapped. The Genesis' 68000 looks for whatever vector table is at address 0x000000. If a game cartridge is inserted, then its vector table will be visible there. Otherwise, whatever the expansion port puts there is instead. In the case of the Sega CD, it would be its BIOS. This is precisely how the booting modes work: "Mode 1" just puts the cartridge memory first in the 68000 address space, and thus boots the cartridge game, and "Mode 2" boots into the Sega CD BIOS. CD Backup RAM cartridges don't really utilize the /CART pin, hence why the console doesn't attempt to boot into it. This also means that, no matter which booting mode you use, both the cartridge and expansion memory are visible to the Genesis' 68000. All that really changes is where they are placed in the address space. The CD BIOS automatically sets up the CD hardware and boots into the CD game, but cartridge games usually don't. If you boot into a cartridge game, but want to use the Sega CD hardware, you'll have to manually set it up yourself. If you want to use the Sub CPU BIOS code, you'll have to track it down yourself and decompress it into the CD's PRG RAM. When booting from BIOS, of course, it already knows where its own Sub CPU BIOS code is. From cartridge, though, the BIOS used changes depending on which Sega CD you are using, and the location of the Sub CPU BIOS code isn't exactly consistent between models and regions, so it can be a bit tricky. In the end, though, once you have it all set up in Mode 1, you have all of the Sega CD hardware to play with. Of course, you can use it to play back CD audio if there's a CD in the drive, but you can also utilize the graphics chip and the 8 channel PCM sound chip. You can also read whatever other data from a CD as you please. The Sub CPU side does not change at all from the booting mode. Whatever you can do in a CD game, you can do in Mode 1. The official technical documentation does make mention of Mode 1 in the BIOS manual: Spoiler And also, at the start of the hardware manual: Spoiler I'll go ahead and shill my Mode 1 library, which handles detecting a known BIOS and loading Sub CPU data and code, if you ever wanted to get started with utilizing Mode 1. Here's also a quick demo that does "SNES Mode 7" rendering and also stereo PCM streaming in Mode 1, all without a CD image to go with it. All the relevant data is stored in the cartridge ROM. Cartridge Boot in Mode 2 This depends on the BIOS revision; not all of them support it. For the ones that support it, during bootup, if it finds the string "SEGA" at $400100 (address $100 in cartridge memory space), and a variation of the security block code at $400200, it'll jump there instead of continuing on with the rest of the BIOS sequence, effectively booting into the cartridge, but from Mode 2. This honestly just seems like some kind of debugging feature only meant for the engineers. This is not documented officially anywhere, as far as my knowledge goes. Here's the code for it in an American BIOS ("cartBoot" = 0x400200): Spoiler: Main check code Code (Text): movem.l d0-d1, -(sp) bsr.w testCartBootBlock bne.w sub_640 ; Boot block didn't match, bail out move.l (_EXCPT + 2).w, d0 bcs.w finishInit bootCartridge: st (byte_FFFFFE54).w bsr.w setupGenHardware move.w #INST_JMP, (_EXCPT).w move.l #finishInit, (_EXCPT + 2).w jmp cartBoot ; --------------------------------------------------------------------------- loc_598: ; CODE XREF: ROM:00000552j ; Cold boot jsr (loadDefaultVdpRegs).w jsr (clearAllVram).w bsr.w checkRegion bsr.w clearSubCpuPrg bsr.w clearWordRam2M finishInit: ; CODE XREF: ROM:00000578j sub_640+38j m_disableInterrupts bsr.w testCartBootBlock beq.s bootCartridge Spoiler: Cartridge check routine Code (Text): testCartBootBlock: lea (cartBoot).l, a0 cmpi.l #'SEGA', -$100(a0) bne.s @locret_6DEC ; Bail if it doesn't start with SEGA lea regionBootBlock(pc), a1 move.w #706, d0 @loc_6DE6: cmpm.w (a0)+, (a1)+ dbne d0, @loc_6DE6 @locret_6DEC: rts ; End of function testCartBootBlock ; --------------------------------------------------------------------------- regionBootBlock: ; DATA XREF: testCartBootBlock+10o incbin "us_boot_block.bin" Backup RAM On regular Genesis games, save data was usually handled by a battery that's on the cartridge. However, you can't really put a battery on a CD. Instead, the Sega CD itself has its own backup RAM, alongside supporting RAM cartridges that can hold additional save data (like memory cards in later consoles). Internal Backup RAM The Sega CD's internal Backup RAM is managed by the Sub CPU. The internal Backup RAM can only hold up to 8 KiB of data. It can be directly accessed at address 0xFE0001-0xFE3FFF, at odd addresses only. However, this isn't exactly the proper way of managing it. Rather, the BIOS comes with a set of functions specifically for managing Backup RAM data. You just set the function ID and parameters, and call the function entry point called "_BURAM", located at address 0x5F16. Said functions are initialization (BRMINIT), checking the status of Backup RAM (BRMSTAT), searching for a file (BRMSERCH), reading data from a file into a buffer (BRMREAD), writing data from a buffer to a file (BRMWRITE), deleting a file (BRMDEL), formatting Backup RAM (BRMFORMAT), retrieving a directory of files (BRMDIR), and verifying written data (BRMVERIFY). RAM Cartridges As of October of 2022, there's hardly any official documentation that's been released that explains how they work, as far as I know, so all information on this is done via reverse engineering efforts. Spoiler: This is the only thing I could find RAM cartridges are managed by the Main CPU. The Main CPU's _BURAM function entry point at 0xFFFDAE (called MBURAM, it seems). Function IDs and parameters are pretty much identical. There are two types of RAM cartridges. We'll start with the standard one: Data is mapped at odd addresses only. There is an identifier defined at 0x400001 which describes the size of the cartridge's memory. The number of bytes is calculated with 0x2000 << identifier size. The 0x6xxxxx address range holds the cartridge memory, and is limited to this region. The maximum supported size is 512 KB (maximum identifier value is 6). The 0x7xxxxx address range is just for the write enable flag. Set bit 0 to 1 to any byte in this region(?) to enable writing, and clear it to disable writing. The second type of RAM cartridge goes as follows: Data is mapped on both even and odd addresses. If the identifier specifically at 0x400001 has bit 7 set (0x80-0xFF), then it indicates this type. "RAM_CARTRIDG" is also expected at 0x400010 in order to be recognized. If detected, then the BIOS will override its _BURAM handler address to be at 0x400020, meaning that the cartridge controls how it manages its RAM. Spoiler: Backup RAM cartridge initialization in the BIOS From the US BIOS disassembly, found in the "installErrorVectors" routine: Code (Text): move.w d0, (a0)+ move.l #sub_88F0, (a0) lea asc_40E(pc), a1 ; "RAM_CARTRIDG" lea (byte_400001).l, a2 tst.b (a2) bpl.s @locret_40C lea $F(a2), a2 moveq #5, d1 @loc_3FE: cmpm.w (a1)+, (a2)+ dbne d1, @loc_3FE bne.s @locret_40C move.l #byte_400020, (a0) @locret_40C: rts RAM Cartridges with the 32X If 32X mode is set (ADEN=1), then cartridge memory is basically taken over by the 32X (with the 32X having the highest level of access priority, if I recall correctly), with it being moved to the 0x880000-0x9FFFFF address space. Of course, this causes issues with RAM cartridge access; the Sega CD was created before the 32X was, and thus, does not handle the 32X. A BIOS revision could probably have been made, but that would introduce potential compatibility issues. So, to fix this, set the RV flag to 1 before accessing the RAM cartridge, and then set it back to 0 when you are done, like how you would in a cartridge game if you needed to perform a DMA with the VDP from cartridge memory.
Lovely info and great work. Always thought the Mode 7 style floor effect was the weak part of the Mega CD ASIC chip, I didn't like it at all in Sonic CD, NBA Hangtime was ok I guess. I still think John O'Biren ASIC work in Batman Returns and Cliffhanger was the most impressive use of the ASIC chip. Those games really felt, played and looked like a SEGA sprite scaler coin-up, though I would guess SoulStar is pushing the Mega CD to the max.
Honestly, Sonic CD is a terrible benchmark for the Sega CD, with it being an early title not making full use of the hardware and also being generally poorly programmed/not thought out very well. The graphics operation is a bit on the slow side (although, it's not as bad as Sonic CD makes it out to be. Again, it's just not very well set up. It's also dependent on the size of the rendered image(s)), but is generally pretty simple to operate. You basically just set up a tilemap as the source image and for each line rendered in the output, a set of starting coordinates and delta values for each axis is set to dictate how to do the rendering. It then generates a rendered image in Word RAM for you to copy to VRAM (the copying to VRAM bit is also another contender for why it's not very speedy). You can also set a priority mode for the render to appear above or below previously rendered graphics.
Sonic CD is really a terrible advert for the extra hardware on the Mega CD, other than the CD-DA music. The FMV intro was of terrible quality and not smooth at all, it makes no use of the PCM sound chip for better quality sound effects in-game and hardly any use was made of the ASIC chip, other than on the cloud for the title screen, the not so impressive bonus stages (which didn't even scale the UFO's) and the impressive D.A Garden extra, for finishing the game. I don't know why Sonic Team looked to use the Mode 7 style effect, much less make it near full screen and not make use of HUD's to mask the screen size Ect,ect... I love Sonic CD as a game, but it could and should been a better showcase for the ASIC chip. I also, don't think it was really that early of a title, given it came out in 1993 and after Batman Returns. It's shame too, because when ASIC chip was made and planned out well, the results were so much better than what Mode 7 could offer, over that speed and full screen. The 3D effect in Batman Returns was utterly increabile and showed what could be done. Core Desgin also showed how you could use the ASIC chip for better spot effects in Son Of Chuck 2 over the MD. Sonic CD should have been using the ASIC chip on Sonic and all the bosses in Sonic CD for me.
The PCM chip does get used for various other sound effects like the voice clips, and also the bumper and glass/ice shattering sounds. It's also used for the past music, although the quality of the driver isn't great (realistically in game, only 7 music channels can be used, because SFX support is complete crap and doesn't properly override channels). This would have required the graphics operation to do more work on a larger canvas. With how the game is set up, it would've run even slower.
I forgot about the voice, but one hardly ever heard that played. I also always thought the glass shatter sounds were FM . I knew that the past levels used the chip. I would have rathered saw high quality PCM sound effects like that in Fifa or Pitfall on the Mega CD, which were much better than the MD counterparts. I get what you say about the bonus sections because Hangtime on the Mega CD had much the same issue, though it did look impressive bar the lack of scaling on the Hoop. I think the only game that used the Mega CD Mode 7 like effect and also scailed object's, was in the bonus sections of Wild Woddy. I would have rathred saw the Sonic 2 bonus like sections only with scaling like that in Batman Returns or Cliffhanger. I loved Sonic CD, but it should have been a better showcase for the ASIC and PCM chip IMO. What game impressed you the most on the Mega CD for ASIC and PCM use mate?
Regarding the graphics operation, besides the obligatory Batman Returns pick, someone sent me this that I thought was pretty neat Regarding PCM, the only thing that comes to mind at the moment is Lunar: Blue Eternal with how basically all of the gameplay music and cutscene audio are streamed from the CD to PCM RAM, with what seems to be seamless looping support!
I like 3 Ninjas on the Mega CD, I just find it very hard and can't get to the 3D ASIC bonus sections without a cheat. GameArts were awesome on the Mega CD and really pushed the 1st. I think they were the 1st to use FMV on the Mega CD , their Lunar games are amazing, Mr Dear friend is an utter showcase for the system and their port of Wing Commander was amazing and made use of every part of the Mega CD (its such an overlook game/port) For me, the best use of the PCM chip was in Fifa on the Mega CD The sound effects are so good and of such high quality. Sometimes, just using the Mega CD sound chip would make a different to a game, like in Pitfall, Final Fight and Fifa along with the CD-DA music/samples. I would also say Adv Of Batman on Mega CD had the most impressive FMV, it looked better than a lot of early Saturn FMV IMO This use of ASIC chip just looked so good at the time, if only SEGA made more use of it... I think it would have made a difference back then
There is a weird claim by one the Sega CD's tech bulletins that states that the Z80 cannot access PSG: However, there, so far from what I've seen, has been no evidence to support this (in fact, there's evidence for the opposite), and really, it makes no sense. The Sega CD doesn't really mess around much with the Genesis side of things. It doesn't even touch the Z80 or VDP/PSG, as far as I know, and just exist in the expansion and I/O spaces. The only thing I can think of at all is how the PSG is part of the VDP, and thus the Z80 accesses it through the 68000 bus, so maybe there's some kind of edge case? Paranoia? I don't know...
Maybe they didn't want composers to use the PSG! Hit 'em with the good ol' "make people believe carrots are good for your eyesight" trick.
SEGA Japan In House teams more than most should have been showibg This was in In-House SEGA Japan team and the game came out 2 years after the Mega CD 1st hit Japan. One might expect an In-House team to know about the Hardware and have every technical tool and resource at their disposal and if not they could just call up to the floor above and call on SEGA's technical team and the people who made the actual Hardware to help out Contrast that to what John O'Brien and Malibu did for SEGA America with Batman Returns; their 1st Mega CD game and one of the 1st SOA games shoed off, despite total inexperience with the hardware, not an In-House team, they were able to push the Mega CD with their 1st game with amazing use of the ASIC chip and also unlike CORE 1st game used the ASIC chip using more than 16 colours It was just bad planning for me because other than the fancy music and storage, Sonic CD could basically be done on a cart, it made no use of the MEGA CD extra hardware for the main levels be that fancy ASIC effects or PCM sound it was all very disappointing. I was also a SNES owner and would always look forward to the Mode 7 setpiece with its use in Boss battles (like in Mario IV, Contra 3) I so wanted that with the Mega CD more so given, it go even better effects than Mode 7, Mode 7 couldn't even handle the Pal Mega-CD boot up given it was scaling and rotating 2 independent objects at the same time It wasn't like the game stages and boss stages for each zone were loaded in all in one go, they were loaded separately and the team really should have planned that each boss stage would have enough data to handle some fancy ASIC effects. Like I said I the last boss battle metal panels should have been smoothly rotated and then in the boss battle to Tidal, should have the bubbles smoothly rotate using the ASIC chip Ect, Ect. The bonus stages were an utter letdown IMO and totally outclassed by Mode 7 and worse still, it didn't even scale the UFO's using the ASIC chip At least SOA were able to scale in the objects to the bonus zone's in Wild Woody That was the issue for the Mega CD to me; Far too many games basically little more than a Mega Drive game with a lovely CD soundtrack. When I wanted more games to use the ASIC chip and do fancy effects. Sorry to go into a little rant, but I love the Mega CD think its a great system with lovely hardware, just criminally underused, especially by SEGA Japan: other than the amazing Switch and F1 BTW
One would expect that, maybe, but development history and the sloppy, unoptimized, hacked together codebase tell a different tale, in my opinion. Spoiler: List of notable issues off the top of my head Earlier prototypes (such as v0.02 and 510) have a date set to April of 1993 in the header. Obviously, it didn't make that date (in fact, the 510 prototype from May 1993 shows the game in a very incomplete state), and didn't go gold until August 1993. From what's been revealed from the Gems Collection symbol dumps, they had a tendency to copy and paste files of code. Each zone got their own copy of things like the scrolling engine, core functions copied and everything, some even slightly modified. They even made a full copy of Sonic's object code for Wacky Workbench specifically. As for the code itself, things like object engine or even the graphics decompression function are inconsistent between segments of the game. Stages of course used Naka's code. The title screen got its own (buggy) object engine. The special stages and time warp shared their own. DA Garden/Visual Mode menu/"Thank You For Your Playing" also shared their own. The graphics decompression function also had slight variations between files. Some had NOPs added at the end of the function. Some uses jsr (pc) instead of bsr.w. Point is, there was a lack of proper consistency. The system program is very bloated and not very well designed. For instance, instead of just passing an additional argument to play a music track, for instance, every single music track in the game got their own dedicated function, alongside COPIES of them for the sound test! DA Garden also has its own copy of music playing functions, because when you load a Sub CPU program for a game section, it overrides the core system program, so you can't really use the core system program commands. Loading a stage file is also a mess, because instead of using a second argument, it uses the actual command ID itself to dictate which file to load, and as a result, you have a LOT of command entries that point to the same function. Earlier prototypes show that the system program did fit within the first $8000 bytes on the disc, but because it got so bad, they had to split a lot of it off into a separate file (SPX). The DA Garden and Visual Mode menu contain the most noobish code of the entire game. I had a whole post in this thread about how the person who was working on DA Garden didn't even know that the (stock) controller reading function sets a variable for buttons that were just tapped, so they opted to manually check when a button is released, which in turn, in combination with a broken communication synchronization loop, caused a fatal crash if the start button was held down during initialization. The Visual Mode menu uses the DA Garden object engine to run a very basic and static menu, and also uses those were manual button release checks. The chief programmer couldn't figure out how to at least get a smooth transition between time zones done with Naka's engine. Instantaneous transitions would have been impossible with the disc reads, but it is possible to get something smoother and faster done. The graphics operation calculations were very much designed with large tilemaps in mind, and not sprites. It was only made so that it can render 1 thing in a frame, and that's it, and then the render is shipped off to the Main CPU for it to be copied to a buffer in VRAM in H32 mode. And lemme repeat: they would have had to refactor a lot of Naka's code for them to be able to be able to use the graphics operation in stages, namely getting to code to not run from Word RAM, and transferred over to the Sub CPU, with added communication with the Main CPU to get graphics, audio, and I/O to work. On top of all this, the entire game is littered with all kinds of weird unoptimal code and decisions. I still don't understand why they use the graphics compression algorithm for the 16x16 block data. The peelout and spindash are also pretty badly implemented, being hacked on top of the rolling and idle code, and also incredibly broken in the v0.02 prototype. Also add the fact that, from what I've looked up, this is the only Sega CD project that the chief programmer Matsuhide Mizoguchi worked on, alongside Yuichi Matsuoka and Keiichi Yamamoto. I can't really seem to find much info on Hiroshi Takei, besides the fact that he worked on Sonic CD and a Sega AM1 arcade game. 2 additional programmers (Tatsuya Satoh and Noritaka Yakita) were added on from HIC, according to the credits. To add on to this, Sega's in-house SMPS driver for the PCM chip (which is used in the BIOS and Sonic CD) is also buggy and lacks features, and their very own BIOS code is also a mess. I'm sorry to say, but from all that I've seen while looking things up and disassembling the game, and seeing how the prototypes were constructed, development seemed to be very, very messy and the game is just not very well put together from top to bottom. I think what Ohshima said about Naka being able to produce something better and closer to what he envisioned has truth to it. Indeed yes, it was bad planning, but it was also in combination with a proper lack of direction in how development should be handled and programming skill compared to other developers.
You could say that about a lot of SEGA In-House games. I don't think the Virtual Cop Team Saturn team were that experienced, and yet early in, they were expected to port a state-of-the-art Model 2 game to the Saturn. TA Panzer Dragoon team had quite a lot of new staff and drafted in AM#1 members, to work on a game that was to sell the Saturn and show off its graphics of Saturn, which was even more, complicated hardware than the Mega CD. It should have been planned from the start of Sonic CD, that we must have area's that show off the extra Mega CD hardware even if it was a little like Mario IV, using Mode 7 for the boss battles. Sonic CD should have looked to do the same IMO. I even think the Special Stages were badly planned too, rather than look to do a Mode 7 effect, that looked worse than Mode 7 (which made it even more pointless). It would have been far better to have a 3D straight ahead stage, with full ASIC scaling like the 3D sections in Cliffhanger and a bit like Sonic 2 Special stages on the MD, if you get me
I do agree that Sonic CD is a lackluster showcase of the Sega CD hardware, I really do, and I do agree that there was some poor planning decisions from the start. I can't speak for anything regarding Panzer Dragoon's development, I'm just speaking about what I've observed from Sonic CD's code in the final and in prototypes, and how that would have affected the usage of the Sega CD hardware. Better development planning and a better team of programmers would've been very beneficial. The Sega CD is quite a different environment to deal with than with the Genesis, particularly with how code has to be loaded and ran from RAM instead of a ROM, and in the case of graphics transformation, the fact Word RAM specifically cannot be accessed by the Main CPU while the render is happening. Naka's engine was not made with that in mind, since it was designed for a cartridge game. Getting the most out of the Sega CD requires better planning than what was actually planned, along with better direction and skills to put it into action. It's not exactly what I would call a "beginner's" system, either. In the end, it's of my opinion that it was more than bad planning at the start that was completely responsible for Sonic CD's lackluster output, considering just how badly put together the game is and how limited the overall engine is, on top of the complexity of the Sega CD hardware (Though, perhaps the choice in programmers could be considered "bad planning". Also, I do realize I'm basically both roasting the devs and giving them the benefit of the doubt at the same time lmao)
I read an interview with the CORE lads and I get that the Mega CD wasn't that easy to work with, with the memory bandwidth being singled out as the major pain and why most developers didn't look to go that extra mile, of talking the time, to use the ASIC chip . But if John O' Biren and the likes of CORE Design (which were small at the time) could push and use the Mega CD tech one would have hopped and really expected the might of the In-House teams at SEGA Japan to have done the same Son Of Chuck was made as Cart game and yet CORE were able to make small use of the ASIC chip for better effects; like smoothly rotating bolders and super smooth sailing on the bird. Puggsy was also made as a Cart game and TT were able to use the ASIC chip for better scaling on the boss battle and also use the ASIC chip for a exclusivel boss battle to the Mega CD version that rotated Ok, it was small simple use of the chip, but really the Sonic Team should have planned out the boss battle to use the ASIC chip and you didn't really need Naka code for those sections and the special stages needed to be a better showcase for the ASIC chip rather than a simple Mode 7 stage that run far worse than a Mode 7 game . Sonic Team didn't even look to have a hud to make the screen smaller due to issues with the widows for ASIC effects Sonic CD really needed to be a better showcase for the ASIC chip and the PCM chip IMO
There could be all sorts of factors that neither of us know regarding Sonic CD's development team and also the people you've listed. Although, it should be noted that with Son of Chuck and Puggsy, those ports were done within the same development companies, so they had the benefit of already knowing how those games work (or at least more direct access to whoever did the programming). Sonic CD didn't have the same team from Sonic 1 outside of Ohshima. They had to learn Naka's engine first. We can speculate on this all we like, but, in the end, what we got is what we got, as disappointing and frustrating as it is.
Well technically they were still part of the same consumer division inside SEGA and would have full access to all the code and libraries, the Mega CD version of Puggy did have a brand new programmer. I get there were issues with Sonic CD development for a while and in the likes of Megatech, I was reading it was going to be an improved version of Sonic 2 In the end 'for me' it could and should have been a better showcase for the ASIC and PCM chips, even if they were only used, for boss battles. I also would have liked the PCM chip to be used on the time travel loading screen, the FM sound used on that, melted my ears at the time
Less about access to the code and documentation, and moreso access to the original programmer(s) who could provide direct support, I mean. In the end, it's still Naka's engine that's being used, and it still had to be learned first before it was ported over to the Sega CD, and Naka was not in the development team. Though, I also cannot say for certain the circumstances with Puggsy, then, as I don't know how much Jon Burton was involved in helping with the port. So many different factors can be at play on why 1 development studio had less trouble than another, including Sega's in-house developers, and a lot of it we just simply don't know and probably never will. Hell, I could be dead wrong on a lot of things myself, and I wouldn't know it. All I can do is look at what's already out there and try to connect the dots. Those other developers probably just had a better grasp on how the hardware operated than the programmers that were brought on for Sonic CD. Honestly, just because they were in-house, doesn't mean that they can fully be assumed to have understood every piece of Sega hardware from the get-go. I also spent all this time going about on the programmers' perspective, but perhaps the real reason the hardware wasn't fully utilized was that the game designers didn't care to try and aim for that. Maybe it really was just bad planning from the designers. Or maybe they did, and the programmers said "no" (like with the more instantaneous time travel idea). We'll truly never know... again, I could be dead wrong in everything myself. This is all just silly speculation in the end, and it's all in the past now. At this point, I feel we're just running in circles. We can get upset about how the game turned out all we want, but it doesn't mean that new software can't be made to truly show off more of what the hardware was capable of. Maybe a hack would be in order (preferably using a custom port of Sonic 1 instead of using Sonic CD)? They did at one point try to use a CD audio track (which also proves that nothing is actually being loaded when that screen is running, since CD data read and CD audio playback cannot happen at the same time), after scrapping the even more wretched FM sound that they were using in v0.02 and 510, but then that got replaced with another FM sound.