More Sega Channel prototypes dumped.

Yes... you're right... I'd heard of it before... if you can find it we'd be grateful...

 

I couldn't mount it on Linux either, I did try an old High Sierra disc image (Microsoft Bookshelf) which did mount, so I guess it's using some obscure or proprietary file system.

 

Yeah... I already suspected that... and the SA Format should be “Scientific Atlanta Format”... and you can see why Sega chose Scientific Atlanta as a partner in the development of the Sega Channel, because before there were games streamed over satellite... Scientific Atlanta was already doing something similar, but with music (DMX, Digital Music Express)... it's basically the same technology...

 

This is my assumption looking through the documents posted here. But I think it might be crackable.


What they appear to have produced is some sort of CD format that when inserted into a computer (which they're calling the SEGA GAME SERVER), is automatically read, the contents copied, and data is subsequently sent to a network of "other" computers responsible for delivering the data to satellites or whatever (i.e. the actual "distribution"). All the operator needs to do is swap the disc every month - it's a neat little system. Most of that documentation covers the processes of the server talking to clients(?) - the "CD -> server" process is glossed over, presumably because of trade secrets.

That server is specced out to be a 486 66MHz PC, so the hardware is probably "standard" if nothing else.


I would guess the "server" is running some fancy software developed by Scientific Atlanta (which must be the "SA" as mentioned) - something that checks the CD drive every five minutes, and expects data to be formatted in a very specific way, which is interpreted through software (it probably arrived in that state, e.g. SA set it up). However, it does talk about a folder structure, and while throwing that IMG file in a hex editor doesn't reveal much, there are at least vague patterns, which suggests at least that bit isn't encrypted (unlike what happens later down the food chain).

One option is to find one of these servers, still equipped with the software, and see what it's doing. That's probably not going to happen, though if it transpires that SA used this system for other purposes, maybe we could reverse engineer something else.

The second is probably to brute force the contents and see if we can get something to happen. If we start seeing ROM headers, we're on the right track.

 

As promised, here's the CD-X or DMX info that I have, in no particulate order..

https://retrocdn.net/images/6/6e/CD-X_DMX_Digital_Audio_System_Applications_Guide.PDF

https://retrocdn.net/images/d/dc/DMX_Music_Teriminal_Users_Guide_Part_1.PDF

https://retrocdn.net/images/7/73/DMX_Music_Terminal_Users_Guide_Part_2.PDF

Umm, maybe I should have mentioned this before but there is one more file on that disc named SCHEDULE.DAT. I didn't give it much thought before and kinda forgot about it but just maybe it contains some sort of code to unlock the .img file? I really doubt it but here it is just in case it looks familiar to anyone..

https://retrocdn.net/images/7/70/SCHEDULE.DAT

 

Oh, I thought the .IMG file was a disc image, not a file on the disc, doh!

 

I thought that too...

 

SCHEDULE.DAT tells the game server what time to use each .IMG file. Some months had special events such as competition versions of games being available for certain days, so they would have multiple .IMG files. That doesn't seem to be the case for this month as there is only one .IMG file.

The game data and menus are in the .IMG file, which may or not be compressed (which it seems this one isn't going by Black Squirel's look at the hex).

 

Yep, that's what I figured as well and ignored it. The SA file server computer features does state that it "reads compressed, unencrypted, multiplexed data from the CD-ROM to hard drive". whatever they mean by "multiplexed data" on the drive..

 

Seems to be in blocks of 1440 bytes. Might be tricky to decode if it's both compressed and multiplexed.

Edit:

I guess it's using a form of Time-division multiplexing. Maybe each rom gets it's own stream which the Sega Channel adapter downloads. It might be too fast for the adapter to deal with if they just streamed one rom after the next. This way they can stream the games at a pace the adapter can handle whilst not reducing the total number of games.

Each 1440 byte "packet" seems to have a 28 byte header which might have info on which rom it is from and which part it is. I wonder if the contents of these packets are compressed and get decompressed by the adapter/Genesis. A Sega Channel adapter bios disassembly would shed some light on this.

 

It's nothing new... and probably won't help us with what we really want, but the guys at The Cutting Room Floor have an interesting page on the bios of both adaptors...

Edit: This was found by @Sik years ago... I don't understand it at all because I'm not a "tech guy", but I also find it interesting...

 

Ah yeah, probably some of this data is contained in the packet headers;

Code (Text):

1.  
2. *
3. * Game Data Structure
4. *
5.                 offset  0
6. DownloadAddress ds.l    1                       ; Address to download to
7. UncompSize      ds.l    1                       ; Uncompressed size in bytes
8. CompSize        ds.l    1                       ; Compressed size in bytes
9. SuperPackets    ds.w    1                       ; number of super packets
10. GameCRC         ds.l    1
11. GameID          ds.w    1                       ; 0 for MenuData
12. GameServiceID   ds.b    1
13. PacketID        ds.b    1
14. StationNumber   ds.b    1
15. LogicalChannel  ds.b    1
16. GameTimeout     ds.b    1
17. PPDSlot         ds.b    1                       ; Play-per-Day Game
18. HelpId          ds.w    1
19. ClearSRAMFlag   ds.b    1
20. SRAMPatternFill ds.b    1
21. CompressionFlag ds.b    1                       ; 0=none,1=comp,2=newload
22. HelpFlag        ds.b    1
23. DLIndicator     ds.l    1                       ; Lptr DownloadIndicatorTable
24. SIZEOF_GAMEDATA ds.w    0

Looking at the Scientific Atlanta and General Instruments implementations they're quite a bit different, General Instruments seems to do more processing of the data on the servers and computers whilst some of that has already been done to the Scientific Atlanta data on the disc. There's also interleaving to take into account. It sounds like a "GI Format" disc would be less obfuscated.

Looking at the dev disc there are .BIN, .GI, and .SA versions of the same games. The .GI and .SA versions are compressed, although with different sizes, so they're doing something different. That could be a Rosetta Stone for working out what compression they're using.

 

In the Sega dev disc there's a program called "GAMUNCMP.EXE" (PCX folder/directory)... maybe "game uncompressor" or something like that?

Edit: the Sega Channel dev disc has been available since 2017 and there's so much to discover... and without meaning to be rude I find it amazing how amazed people are to find a "Sonic turd hidden behind the third palm tree in the Green Hill Zone" and yet nobody cares about this disc...

 

Yeah, you're right, it even boots on modern Windows, but I couldn't make it decompress or compress anything (there's also GAMEEDIT.EXE which looks the same, but maybe that one compresses). The options are "Max Compression", "Variable Compression", and "No Compression". I'm not sure if this is what compresses to the SA and GI format roms. I noticed one of the roms "DANTO.BIN" has an archived version "DANTO.BIN.cpgz" which opens in 7zip and has DANTO.BIN inside. It's better compression than the .GI and .SA files.

The compression used for .GI and .SA is pretty light-weight, it just seems to compress repeated data, you can still read the game's header in a hex editor. Maybe some variant of this.

Bonus Sonic ...

 

Sir Dragon, "El Mágico" ... Cool stuff ... That's what needs to be done... we need to go through it because there's so much we've never seen... these are basically historical artefacts... just don't count on me to do it because I'm not a genius in these matters... ...

 

I'm a bit out of depth myself ...

 

At least you tried... and that's a good thing... ...

 

So looking through the dev stuff I have a better understanding of how the .IMG file is created;

ROMS compressed to .SA files
Data assigned to .SA files (Game Identifier, Pipe, Repeat #, Size, Service code, and something else (all are "1" except for the menus which are "0", so maybe that sets for returning to menu from game)
.SA files split into "SuperPackets" and assigned to one of ten "Pipes"
SuperPackets mapped for each Pipe
"SuperFrames" created

About 200,000 SuperPackets
About 25,000 SuperFrames

I guess the pipes are the multiplexing, basically 10 streams of data.
I think a SuperFrame consists of 8 SuperPackets (taking into account that the menu rom is repeated ~12x)

I think it should be doable, although obviously not manually.

 

Well... you don't seem to be out of depth at all right now!... ... Godspeed, Sir Dragon!... Godspeed!...

 

disregard, got too excited and missed a previous post