Welcome aboard! There's been a lot of discussion recently over a lost second level for Sonic CD, and it was your PC version and its seemingly missing "R2" folder that started the mystery There is one little detail I noticed: Early screenshots of the game have palette problems, with black water and black skies. Amazingly they made it onto the US box and were being reprinted for years. I don't suppose your prototype has this issue, does it?
Okay, so I have been sent the beta Dino library and late Sonic CD beta. I'm just wanting a confirmation from PixelTheCat to share them both publicly for other people to see. Also would definitely want to make the time to archive the files saved after installation, because the EXEs are in New Executable format, which cannot be run on modern Windows.
I have no idea on 30Hz vs. 60Hz. I'd thought we were 60Hz since that's what the VGA screen refresh was. Then again, this was a long time ago. Maybe windowed mode was 30Hz and full screen (bypassing Win95 for the display) was 60Hz? I think the artwork came from Sega at 320x224; us Intel folks just provided graphics and sound libraries that were Pentium assembly optimized. At the time, video cards had standardized modes that they all supported, but many cards had additional modes that were proprietary. Some games had options for different video cards. We all had a copy of "The Programmers Guide to the EGA, VGA and Super VGA Cards" for reference, since one would set modes by just writing various values to registers on the cards directly. VGA gave a standardized set of registers for doing this. Sega wanted 256 color, so we needed to use the lower resolution mode to make sure that we could rely on just VGA card support, but the standard modes were limited to 320x200x256. However there was a universally supported 'hidden' mode 320x240 called Mode X popularized by Michael Abrash (https://en.wikipedia.org/wiki/Mode_X) that we used and I think this was due to a) could just have an empty strip of 8 pixels at the top and the bottom and b) preserved the aspect ratio (was Genesis using square pixels maybe?) Memory under Win95 was kinda virtualized; each process had its own memory space, but could still write to a range of hardware memory addresses directly. This was used for the full screen mode(*). Intel had already been working on direct-to-frame buffer access prior to me joining the group, and Dino was a 2D/2.5D optimized library to use this direct access, later ported to DirectX. Another reference that can provide clues to the archeologists digging through the code is the Michael Abrash Graphics Programming Black Book (https://www.drdobbs.com/parallel/graphics-programming-black-book/184404919 I'm sure you've all come across it but just in case). In particular, the sections on Pentium optimization explain why the assembly code is out-of-order in a lot of the critical speed sections. The Pentium chip had two instruction pipelines that could operate in the same clock; out-of-order instructions were used to keep the pipelines full and running to avoid at least two cases: 1) the second pipeline had limited instructions it could execute 2) the pipelines would stall if a result from a prior instruction hadn't yet resulted. (*) Notably this could also be used for debugging. We had software called SoftICE that wedged itself under Win95 to provide low-level debugging, and could display debug information (stack trace, code trace, memory contents, registers, etc) on a second monochrome display. Monochrome address space started at 0xB0000 while VGA cards were at 0xA0000, even without SoftICE but with a monochrome monitor and card as well you could write text straight to the mono monitor by just writing direct to memory without messing up the full-screen graphics you were debugging on the main monitor
The files are still owned by Intel/Sega from a copyright perspective. I offer them up in the context of preserving a small part of the historical record from that era that could otherwise be lost.
Having installed and tested it, no those palette issues are not in this build. I just want to make sure that we both understand each other correctly: would it be a personal problem to you if I allowed the public to also view this stuff, or are you more or less just saying it's not really your problem with how it's handled outside of you? There are definitely folks who also would love to take a look as well and make sure it's properly preserved, but I also would wanna be okay to respect any wishes you have. I will say, I really don't foresee any harm with this stuff being publicly available at all, and could be of use for other stuff.
Having reviewed what you all are doing, it really does seem akin to archeology and study rather than pirating. I think that in this context it's ok to let people see the development process before this knowledge is lost. The only way to preserve this information for future study is to make copies - the burned CDs can and do decay. Of course if the lawyers get involved and disagree we shall naturally take it down. Also if any company needs hardware level programmers for anything, they could do worse than to recruit on these forums.
In the case of piracy, it would be quite difficult anyways, because this beta build can't even run on a modern PC; there's far easier options to play Sonic CD, so it's HIGHLY unlikely anyone would want to use this as a means for piracy. But yeah, the interest in the publication of this stuff is in preservation and study. So, I guess in this case... This was what I was provided with. It is a ZIP file containing the files copied from the disc (which means that the music data for Sonic CD is not included). Personally, I think BIN/CUE rips would be better for the sake of completion, but this is still great.
For what it's worth, if you just wanted to pirate Sonic CD on PC there are far easier ways to do so than a beta build of the original Windows 95 version. Thank you very much for this! Fascinating peek behind the curtain of the game's development.
This is really great stuff! I've been playing this game on PC since it came out at retail, still have the disc, and I've poked around at the game's files and code a few times over the years, made a sprite editor and level editor for it. I probably would have made a mod loader for it if the DLL-based system it uses didn't make it so difficult to work with, and the 2011 remake wasn't vastly easier to use. I'd love to know if you have any insight into how the game's code was converted from 68000 assembly to C.
Thank you so much not only for the release, but for your insight. Very rarely do we get first-hand accounts from someone who was "in the trenches", so to speak.
Who wouldve guessed a random Sonic CD thread would lead to a beta version of said original PC port being archived and the developer of said version helping fill in some blanks Only Sonic Retro things
So... how about a BIN/CUE rip of the Sonic CD PC beta disc? Also archive.org links: Sonic CD (Beta v0.992) Intel Dino 2.0 (Beta)
Do you remember how the port was done from the original Sega CD codebase (i.e. automatic 68000 assembly to C source translation, or a manual rewrite)?
I don't explicitly remember their codebase. However, given that they used our graphics/sprite libraries for the first version (library was codenamed Dino, became Intel RDX on release) it was more likely a rewrite.
It was a direct translation of the 68000 code to C (like, seriously, a lot of it is 1:1). I'm pretty sure they did it by hand, too, because there are some errors, alongside additional modifications and other strange oddities.
Yeah, that makes sense with the Jim Trethaway interview: "The amazing bit was how they translated the game from assembler to C, because the code was very funny -- when I read it on the screen (I don't have a copy) in the office in Tokyo, it was obvious that the C code was "emulating" the assembler code logic, rather than being a "fresh re-design"."
Yeah, take a look at this example comparison between a decompiled function from the PC version vs the same function from the original Sega CD version in my disassembly: Yes, they used 68000 registers as variable names... a lot. They would often keep certain operations that could be done on a single line broken down like in the 68000 code, too. Also, if anyone is curious, I used the Gems Collection version's unstripped debug data to dump a file structure that also contains all of the variables, data structures, function signatures, function variables, and addresses <-> line numbers. Gives you a sense on how the original Sega CD's version was structured, alongside the PC port. I've been using that for decompiling code as faithfully to the original source code as I possibly can.
