Sega CD technical introduction

Ask anything your want about Mega/SegaCD programming.

Moderator: Mask of Destiny

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Sega CD technical introduction

Post by sheath » Sat Sep 08, 2007 6:24 pm

Hello all,

You were all very helpful in my Silpheed question, so I thought that I would field my general introduction to the Sega CD to you all for feedback. My audience is not programmers, but gamers and anyone else who might be looking for a starting place to learn more about older systems. So, I am trying to avoid as much technical talk as possible, without over simplifying anything. Any and all comments and corrections are welcome.


The Sega CD was released in November of 1992 for $299 and was eventually the first CD-ROM add-on to sell over 1 million units. The initial media reception for the Genesis Add-On was positive, but its presence was quickly overshadowed by Nintendo's gradually increasing promises for the, never released, SNES CD-ROM add-on. Nevertheless, CD-ROM was to prove its staying power as a game console medium for the rest of the decade. The core of the Sega CD architecture was a central 68000 processor that ran at 12Mhz and could operate in tandem with the 7.6Mhz Genesis' 68000 CPU. The Sega CD's CPU, however, is not considered to be significantly more capable than that of the Genesis CPU. Furthermore, both processors can not be employed in processing the same code simultaneously. This meant that most games would use the Sega CD's central processor for game code which would then be streamed to the Genesis RAM and displayed by the Genesis VDP. As a result, the Sega CD can not be considered a dual processor system. This complex approach to game architecture stems from Sega's own arcade business, with its well known dual MC68000 boards.

Because the Sega CD could also not stream game data from the CD-ROM on to the screen in real time the architecture included 768KB of RAM. What this meant for developers was that, while a standard Genesis cartridge of the time could hold a total of 1024KB, any given level of a Sega CD title could hold over two-thirds that amount of data. Despite this advantage, Sega initially only requested that third party developers prepare standard Genesis games with CD audio music and updated cutscenes.

This fact was exacerbated by the Sega CD's inclusion of special scaling and rotation effects chips. The effects that these chips could produce would later be utilized to a far more technically impressive effect than anything on the Super Nintendo. Early potential buyers were won by Full Motion Video of live actors, or cartoon cinematics, live voice actors, and CD quality music and sound only. Launch Sega CD software failed to take advantage of the Sega CD's technical advantage over older systems like the Genesis and SNES. So, game magazines gave the Sega CD a mediocre reception despite the system's technical strengths.

Regardless of the possibilities, the game media tended to focus on early Sega CD games' failure to produce stark improvements over comparable cartridge titles. Included in the criticisms was one that was common to the Genesis itself, a limitation to only 64 colors on screen out of a palette of 512 colors. The Genesis was already becoming known in game magazines more by its weaknesses than its strengths in relation to the SNES. The Sega CD was, therefore, presented by game magazines as an attempt by Sega to upgrade the Genesis in order to remain competitive with the SNES. So, Sega's "failure" to increase the on screen colors and color palette of the Genesis with its CD-ROM add-on became the media's favorite whipping post.

As noted in the Genesis-vs-SNES page, the Genesis did not need an upgrade in order to compete with the SNES. The Genesis had an advantage over the SNES in its relative speed and variety of background effects. Sega's system was only increasing in sales by the time of the Sega CD's launch. A CD-ROM upgrade had already been released for the TurboGrafx-16 two years earlier, and the industry expected add-on upgrades in general. Simply put, Sega designed and released the Sega CD with the Genesis in mind as its complement, not its predecessor. Evidence of this is in every press release by Sega at the time, as well as the hardware itself.

If anything was a motivating factor in creating the Sega CD, it was Sega's desire to maintain its cutting edge image. Blazoned on the top of every Model 1 Genesis were the words "High Definition Graphics" and a chromed logo stating "16-bit." Appropriately, the Sega CD's very name contained its most important cutting edge characteristic, the CD-ROM medium. Secondarily to this motivator, Sega had to keep the system's costs and the installation process as user friendly as possible. In doing so, the decision not to replace the Genesis video chip as the primary display output became a forgone conclusion.

Mask of Destiny
Very interested
Posts: 591
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Tue Sep 11, 2007 2:21 am

The core of the Sega CD architecture was a central 68000 processor that ran at 12Mhz and could operate in tandem with the 7.6Mhz Genesis' 68000 CPU. The Sega CD's CPU, however, is not considered to be significantly more capable than that of the Genesis CPU.
I could be mistaken, but I believe it's 12.5MHz not 12. As to whether or not it's significantly more capable, I suppose that depends on what you consider significant. Unless there are some wait states on the memory I don't know about, the Sega CD should be a bit over 1.6 times as fast as the Genesis CPU (FSB speed is equal to core clock speed and there are no funny cache or pipeline effects to worry about, so performance should scale linearly with clock speed).
Furthermore, both processors can not be employed in processing the same code simultaneously.
That's not completely true. The fundamental problem is that the system doesn't support shared memory access. In other words, both processors can't use the same chunks of memory simultaneously. They could run the same code (provided a copy was made in two different regions of RAM), but they can't really operate on the same data set at a time.
This meant that most games would use the Sega CD's central processor for game code which would then be streamed to the Genesis RAM and displayed by the Genesis VDP.
I can't say that I've disassembled most games, but I get the impression that most non-FMV games did most of their business on the Genesis CPU with the Sega CD CPU handling stuff specific to the Sega CD hardware (retrieving files off the CD, using the PCM chip, playing audio tracks etc.). In games with compressed video, I would imagine the Sega CD CPU probably did the bulk of the decoding. It's faster, it can access more RAM, and it doesn't have a huge chunk of it's time eaten up by DMA to the VDP.
As a result, the Sega CD can not be considered a dual processor system.
I'm not sure if this is entirely fair. Obviously, it can't support SMP, but it does have 2 object code compatible processors that can work together on processing.
What this meant for developers was that, while a standard Genesis cartridge of the time could hold a total of 1024KB, any given level of a Sega CD title could hold over two-thirds that amount of data.
But the Genesis CPU can only access 256KB of this normally (or none of it if Word RAM is configured to be used completely by the Sub CPU). Since the Sega CD CPU doesn't have access to the VDP, graphics generally need to be stored in (or streamed to) memory the Genesis side can see. While the Sega CD obviously has a huge advantage in overall storage. Cartridge games still had a pretty big advantage in amount of data available all at once.
Despite this advantage, Sega initially only requested that third party developers prepare standard Genesis games with CD audio music and updated cutscenes.
Did Sega actually request this or did developers deliver this simply because it was the easiest thing to do?

On the whole, it's not a bad writeup. Certainly better than the dreck that is the current Wikipedia article.

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Tue Sep 11, 2007 3:33 am

I could be mistaken, but I believe it's 12.5MHz not 12. As to whether or not it's significantly more capable, I suppose that depends on what you consider significant. Unless there are some wait states on the memory I don't know about, the Sega CD should be a bit over 1.6 times as fast as the Genesis CPU (FSB speed is equal to core clock speed and there are no funny cache or pipeline effects to worry about, so performance should scale linearly with clock speed).
You are not mistaken, it is 12.5 MHz, that must have been a typo. The discussions that I have seen, on the subject of whether it was significantly more powerful than the Genesis CPU, seemed to expect a 1:1 increase per Megahert. The rest of the discussions pointed to the fact that some Genesis CPUs could actually be overclocked to that speed, which seemed to imply that the CPUs were the same but that the die selected for the Sega CDs were of a higher reliability at higher speeds. I have always been of the opinion that the Sega CD CPU had to have been more powerful than the Genesis CPU, as you say, by at least 1.6 times. Your point, however, that you make later on in this post seems to negate that advantage...
That's not completely true. The fundamental problem is that the system doesn't support shared memory access. In other words, both processors can't use the same chunks of memory simultaneously. They could run the same code (provided a copy was made in two different regions of RAM), but they can't really operate on the same data set at a time.
Do you think that an added comment that this was probably not possible in game software would cause the statement to remain accurate?

I can't say that I've disassembled most games, but I get the impression that most non-FMV games did most of their business on the Genesis CPU with the Sega CD CPU handling stuff specific to the Sega CD hardware (retrieving files off the CD, using the PCM chip, playing audio tracks etc.). In games with compressed video, I would imagine the Sega CD CPU probably did the bulk of the decoding. It's faster, it can access more RAM, and it doesn't have a huge chunk of it's time eaten up by DMA to the VDP.
That makes the Sega CD CPU sound more like the 16MHz chip in the Turbo CD. It sounds like a control processor, rather than a central processor for graphics and sound. I think that you are probably right, that the Sega CD CPU in most games handled data being read off of the disc, sent data to the other Sega CD components, and then sent the results to the Genesis CPU for final processing and display. That, however, is too complex for the average reader that might be trying to compare systems. Your point is well made though, and I will have to compensate for the fact that the Genesis CPU remained the primary processor in the bunch.

How does this sound:
"The core of the Sega CD architecture was a central 68000 processor that ran at 12.5 Mhz and could operate in tandem with the 7.6Mhz Genesis' 68000 CPU. The Sega CD's CPU, however, is not considered to be significantly more capable in game releated software than that of the Genesis CPU. Furthermore, both processors were not employed in processing the same code simultaneously. The Genesis has exclusive control of displaying the graphics and can only access the Sega CD's memory in 256KB junks. This meant that most games would use the Sega CD's central processor for game code which would then be streamed to the Genesis RAM and displayed by the Genesis itself."
As a result, the Sega CD can not be considered a dual processor system.
I'm not sure if this is entirely fair. Obviously, it can't support SMP, but it does have 2 object code compatible processors that can work together on processing.
For the purpose of comparing the architecture to others, can you say that this potential was used in any software? If this approached was both used, and made a difference in performance for even one game it is significant. If it is only theoretically possible, then it is a detail that I might be able to footnote only.
But the Genesis CPU can only access 256KB of this normally (or none of it if Word RAM is configured to be used completely by the Sub CPU). Since the Sega CD CPU doesn't have access to the VDP, graphics generally need to be stored in (or streamed to) memory the Genesis side can see. While the Sega CD obviously has a huge advantage in overall storage. Cartridge games still had a pretty big advantage in amount of data available all at once.
That is very interesting. So, it cannot be said that any given Sega CD title could display 6 Megabits per level, it could really only display 2 Megabits per level/load?
Did Sega actually request this or did developers deliver this simply because it was the easiest thing to do?
Good catch. I thought that I had a source for this one, but it was apparently just a speculative writer. I'll change this on the double.
On the whole, it's not a bad writeup. Certainly better than the dreck that is the current Wikipedia article.
I appreciate this. Especially since most wikipedia articles have no respect for historical accuracy. If there is anything else you think needs to be corrected, please let me know.

Fonzie
Genny lover
Posts: 323
Joined: Tue Aug 29, 2006 11:17 am
Contact:

Post by Fonzie » Fri Nov 23, 2007 12:22 am

That is very interesting. So, it cannot be said that any given Sega CD title could display 6 Megabits per level, it could really only display 2 Megabits per level/load?
That's the idea... more over, the code itself can take a lot of space, so it reduce even more the gfx power.
Do you think that an added comment that this was probably not possible in game software would cause the statement to remain accurate?
Giving the fact I barely see a game system running a "same" code on both cpu... I would say that the megacd configuration isn't so bad compared to 32x or sega saturn.
Mind you, in impressive games, the bottleneck isn't really the communication between megadrive and megacd cpu, its more because the megacd can't display anything (because the megadrive was never designed to receive an external video source).
The bottleneck for this system is about display power, not code processing power.

I clearly understand why most games were just audio+fmv enhanced from the cartridge version, it's just because it was more handy like that... exactly like Mod said...

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Wed Jun 23, 2010 1:07 pm

It's been, um, a few years but I thought I'd use this thread for some further questions. I ended up only using the above writeup as research notes as I read through the magazines and record the games chronologically. I have found some interesting contrary facts to what is commonly believed today already. For instance most US game magazines gave monthly updates on the Sega/Mega CD from summer of '91 that promoted the add-on as positively as EGM had the SNES prior to its launch.

I've also gained the impression that the Sega CD was engineered to operate like a specialized game cartridge. SNES SFX and DSP chipped games and the Sega CD are only different in that the Sega CD had more additional chips, additional RAM and ROM, and a CD-ROM drive. I am sure there are low level technical differences, but the principle is too similar to ignore. Both approaches process intensive game code handled by the SFX or Sega CD CPU/GCP and then stream data to the main CPU as a regular cart would. This becomes even more intriguing in light of some of the non-existent SNES CD-ROM specs ending up looking very similar to SFX or SFX-2.

One thing that I have started doing with other consoles is recording how much ROM space was used or available to the individual games. Be it 4-megabit, 8-megabit, Super CD-ROM, and so on, I think it is significant in any comparison. I'm looking for a simple way to see how much game code is actually on a CD-ROM game and haven't had much luck. Simply inserting the disk into my PC's drive doesn't seem to give me reliable numbers, and I would rather not have to rip the CDs to disk just to see the ISO size. I think it would be worthwhile to know that, say, Ecco the Dolphin was 1024KB and Ecco CD used 50 MegaBytes even if that included data for the cutscenes. But I see no purpose in including CDA file size.

If anybody's bored, I will be updating the Sega CD history page with whatever I find from magazines and games through 1992. Any and all constructive feedback will be greatly appreciated, especially if somebody knows a reliable way to measure the game data on CDs.

Chilly Willy
Very interested
Posts: 2847
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Jun 23, 2010 5:49 pm

Seeing as SEGA CDs are ISO9660 based, start with a simple directory listing... here's Sonic CD:
total 118122
-r-xr-xr-x 1 root root 22 1993-10-12 18:39 abs.txt
-r-xr-xr-x 1 root root 2302 1993-10-12 18:39 attack.bin
-r-xr-xr-x 1 root root 131072 1993-10-12 18:39 attack.mmd
-r-xr-xr-x 1 root root 640 1993-10-12 18:39 badend.bin
-r-xr-xr-x 1 root root 38129664 1993-10-12 18:39 badend.stm
-r-xr-xr-x 1 root root 1 1993-10-12 18:39 bib.txt
-r-xr-xr-x 1 root root 10998 1993-10-12 18:39 braminit.mmd
-r-xr-xr-x 1 root root 31328 1993-10-12 18:39 brammain.mmd
-r-xr-xr-x 1 root root 2592 1993-10-12 18:39 bramsub.bin
-r-xr-xr-x 1 root root 8952 1993-10-12 18:39 come__.mmd
-r-xr-xr-x 1 root root 15 1993-10-12 18:39 cpy.txt
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 demo11a.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 demo43c.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 demo82a.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 dummy0.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 dummy1.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 dummy2.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 dummy3.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 dummy4.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 dummy5.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 dummy6.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 dummy7.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 dummy8.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 dummy9.mmd
-r-xr-xr-x 1 root root 44052 1993-10-12 18:39 ending.mmd
-r-xr-xr-x 1 root root 640 1993-10-12 18:39 goodend.bin
-r-xr-xr-x 1 root root 38129664 1993-10-12 18:39 goodend.stm
-r-xr-xr-x 1 root root 4096 1993-10-12 18:39 ipx___.mmd
-r-xr-xr-x 1 root root 7514 1993-10-12 18:39 mdinit.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 nisi.mmd
-r-xr-xr-x 1 root root 10026 1993-10-12 18:39 open_m.mmd
-r-xr-xr-x 1 root root 590 1993-10-12 18:39 open_s.bin
-r-xr-xr-x 1 root root 14014464 1993-10-12 18:39 opn.stm
-r-xr-xr-x 1 root root 7420 1993-10-12 18:39 planet_d.bin
-r-xr-xr-x 1 root root 22248 1993-10-12 18:39 planet_m.mmd
-r-xr-xr-x 1 root root 39728 1993-10-12 18:39 planet_s.bin
-r-xr-xr-x 1 root root 286 1993-10-12 18:39 ptest.bin
-r-xr-xr-x 1 root root 10646 1993-10-12 18:39 ptest.mmd
-r-xr-xr-x 1 root root 8601600 1993-10-12 18:39 ptest.stm
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r11a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r11b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r11c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r11d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r12a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r12b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r12c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r12d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r13c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r13d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r31a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r31b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r31c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r31d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r32a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r32b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r32c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r32d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r33c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r33d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r41a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r41b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r41c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r41d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r42a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r42b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r42c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r42d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r43c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r43d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r51a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r51b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r51c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r51d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r52a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r52b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r52c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r52d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r53c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r53d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r61a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r61b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r61c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r61d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r62a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r62b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r62c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r62d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r63c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r63d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r71a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r71b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r71c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r71d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r72a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r72b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r72c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r72d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r73c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r73d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r81a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r81b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r81c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r81d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r82a__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r82b__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r82c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r82d__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r83c__.mmd
-r-xr-xr-x 1 root root 262144 1993-10-12 18:39 r83d__.mmd
-r-xr-xr-x 1 root root 217866 1993-10-12 18:39 sncbnk1b.bin
-r-xr-xr-x 1 root root 242597 1993-10-12 18:39 sncbnk3b.bin
-r-xr-xr-x 1 root root 201562 1993-10-12 18:39 sncbnk4b.bin
-r-xr-xr-x 1 root root 199035 1993-10-12 18:39 sncbnk5b.bin
-r-xr-xr-x 1 root root 217454 1993-10-12 18:39 sncbnk6b.bin
-r-xr-xr-x 1 root root 212897 1993-10-12 18:39 sncbnk7b.bin
-r-xr-xr-x 1 root root 219249 1993-10-12 18:39 sncbnk8b.bin
-r-xr-xr-x 1 root root 181787 1993-10-12 18:39 sncbnkb1.bin
-r-xr-xr-x 1 root root 198665 1993-10-12 18:39 sncbnkb2.bin
-r-xr-xr-x 1 root root 12544 1993-10-12 18:39 sosel_.mmd
-r-xr-xr-x 1 root root 16640 1993-10-12 18:39 speend.mmd
-r-xr-xr-x 1 root root 27904 1993-10-12 18:39 spmm__.mmd
-r-xr-xr-x 1 root root 327680 1993-10-12 18:39 spss__.bin
-r-xr-xr-x 1 root root 17408 1993-10-12 18:39 spx___.bin
-r-xr-xr-x 1 root root 12544 1993-10-12 18:39 stsel_.mmd
-r-xr-xr-x 1 root root 25112 1993-10-12 18:39 thanks_d.bin
-r-xr-xr-x 1 root root 20144 1993-10-12 18:39 thanks_m.mmd
-r-xr-xr-x 1 root root 2366 1993-10-12 18:39 thanks_s.bin
-r-xr-xr-x 1 root root 27484 1993-10-12 18:39 titlem.mmd
-r-xr-xr-x 1 root root 8090 1993-10-12 18:39 titles.bin
-r-xr-xr-x 1 root root 15774 1993-10-12 18:39 vm____.mmd
-r-xr-xr-x 1 root root 7242 1993-10-12 18:39 warp__.mmd

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Thu Jun 24, 2010 4:10 am

Right, and in Windows those are all expressed in KiloBytes. Looking at a TurboGrafx CD produces a totally different kind of list that made it seem to me that the comparison would not be accurate. Also, if I right click, in Windows again, the CD Drive with a disk in the tray the properties will tell me a total memory used. I might incorrectly assume this is a sum of all of the files listed in the directory minus the CDAudio.

Sonic CD reports 121,059,328 bytes. I would assume that count doesn't include all of the CDA music. But does it include the chip audio for the past levels and other digital samples that might have made it into a cart version?

I'm not trying to make this more complicated than it needs to be, but I do want to accurately report how much game data is on a disk as is comparable to cartridge based games.

Chilly Willy
Very interested
Posts: 2847
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Jun 24, 2010 4:48 am

Right, that's everything but the CDDA tracks. Notice the dummy files - companies like to put them on CDs for one reason or another. Many times, the only difference between a rip that's small and the BIG original was they tossed the dummy files.

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Thu Jun 24, 2010 10:47 pm

Thanks for the confirmation, That works from Sega CD games, but not for PCE/Turbo CD games. I haven't checked 3DO, Saturn or PS1 games yet but I think they might all work differently in a PC's optical drive.

Chilly Willy
Very interested
Posts: 2847
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Jun 25, 2010 1:01 am

Saturn should be VERY similar to SCD... they just have some protection on the outer edge the Saturn can check for. Many PSX games are also plain ISO discs (but PSX puts their protection on the inside instead of the outside). Many PSX games can just be read on a PC like normal... if your drive can handle the fact that PSX disc aren't sputter coated in aluminum. They are plain plastic... it looks black to us, but is reflective in the infrared, which is what CD lasers are. They don't reflect as well as aluminum, so some drives can't read them.

I have no idea about 3DO or PCE discs.

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Fri Jun 25, 2010 3:52 pm

Thanks again. I'll have to figure out first if I can measure all disk based games in this way. If PCE is the only one that shows up blank I can easily just list it as what system card the game used. Then there's Dreamcast GDs to contend with. I don't like collecting data that doesn't mean anything across platforms, so I'll see what I can figure out.

Shiru
Very interested
Posts: 786
Joined: Sat Apr 07, 2007 3:11 am
Location: Russia, Moscow
Contact:

Post by Shiru » Fri Jun 25, 2010 5:29 pm

3DO has some non-ISO9660 file system, which also includes a few copies of the same data in different locations of the disc, to reduce access time.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Fri Jun 25, 2010 8:43 pm

sheath wrote:Thanks again. I'll have to figure out first if I can measure all disk based games in this way. If PCE is the only one that shows up blank I can easily just list it as what system card the game used. Then there's Dreamcast GDs to contend with. I don't like collecting data that doesn't mean anything across platforms, so I'll see what I can figure out.
PCE CD bios has no support for the CDFS table that ISO-9660 structure uses. Not that you couldn't make such disks, it's just that they didn't.

As for figuring out the size of data used for PCECD disks, good luck there. Measuring the just the data tracks won't give you even the slightest indication of what's actually used. Not that other CD ISO-9660 games couldn't waste files too (data that is there but not accessed or fully used, etc), but I would bet it's a much better indicator on a CDFS layout. But, that doesn't really give any indication of redundant data either. A CD layout is huge compared to carts and since sequential access is the fast you can get on a CD system (and very important back then), games tend to take advantage of this and waste sector space for redundant information. Not to mention probably uncompressed for some games (compared to a cart).

For PCECD games, they use LBA offsets relative to the current selected data track (but can access passed it, data track is just the relative starting point to add the LBA request to). They are hardcoded at assemble time. No file system. They used hard drives to simulate the data tracks on the development systems and developers tended to pick areas in large gaps of each other (which means you can find stuff in between the 'real' data. Left over source code, game code, even CDDA in raw PCM form of other games or even the original game). In other words, just looking at the data track won't reveal much unless it's tiny (like Jim Power or some such title).

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Sat Jun 26, 2010 12:59 am

Thank you sir. I think that pretty much negates the idea of comparing CD-ROM data file totals to cartridge ROM sizes, or even sizes between CD based systems. I'll stick to the "format" idea, and only post distinctions if it is applicable to each individual system.

Meaning that the Turbo/PCE CD games have their system cards, Saturn has CDs that use RAM carts, but most every other disk based system is just going to be ambiguous as far as storage space goes.

Chilly Willy
Very interested
Posts: 2847
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sat Jun 26, 2010 3:18 am

Even with something like the SCD, you can't directly compare graphics data files on the CD against a cart. A cart has all the graphics in one lump - the rom. A CD will only have those graphics needed for that specific level... but if it's in every level, it will be in every file, not just one file. You you usually have lots of repetition on CD games, making it seem larger than it really is.

Post Reply