SuperDisc BIOS released + analysis [attn: nocash]

[LuigiBlood]

Okay, got the thing emulated & documented. Booting from CDROM works fine, and even the Tray eject button is emulated as extra gimmick. Documentation should cover about everything, from component list, memory and I/O map, and volume/bootsector info and specs for the BIOS functions at 00h:Exxxh.

For the CDROM emulation part, I'll still need to add something that avoids problems with zerofilled SRAM (that makes the BIOS think that the checksum is good, and 0 files exist... and 0 bytes are free). And, I've a few other CDROM-unrelated details on my todo-list (like adding some final notes to the NSS and Nintendo power specs). I hope to get a no$sns update released next some days.

Anyways, before somebody else releases the first SNES CD game, here's one: http://problemkaputt.de/magicflr.htm (with binary and source code included). For the records: That is the first-ever SNES CD / Super Disc game released ever! The image is in burnable CUE/BIN format, although no$sns is simply ignoring the CUE file's content (supports only MODE1 .bin with 800h-byte sectors). Alternately, ISO will be also supported, allowing to use MODE1/MODE2 discs with 920h-byte sectors, that would also support ADPCM discs (haven't emulated ADPCM or CD-DA playback yet though).

Just for curiosity, here's the mechacon command log from no$sns TTY debug message window, recorded when booting the above game:

Code: Select all

Mechacon: D51F01234F --> FFFF10B00F (Status Request)
Mechacon: D51F01234F --> FFFF10B00F (Status Request)
Mechacon: D01F --> FFFF (Stop)
Mechacon: D51F01234F --> FFFF10100F (Status Request)
Mechacon: D51F01234F --> FFFF10100F (Status Request)
Mechacon: D51F01234F --> FFFF10100F (Status Request)
Mechacon: D51F01234F --> FFFF10100F (Status Request)
Mechacon: D51F01234F --> FFFF10100F (Status Request)
Mechacon: B000216F --> FFFFFFFF (Access MM/SS/FF)
Mechacon: D02F --> FFFF (Play)
Mechacon: D51F01234F --> FFFF10200F (Status Request)
Mechacon: D03F --> FFFF (Pause)
Mechacon: B000200F --> FFFFFFFF (Access MM/SS/FF)
Mechacon: D02F --> FFFF (Play)
Mechacon: D51F01234F --> FFFF10200F (Status Request)
Mechacon: D03F --> FFFF (Pause)
Mechacon: B000217F --> FFFFFFFF (Access MM/SS/FF)
Mechacon: D02F --> FFFF (Play)
Mechacon: D51F01234F --> FFFF10200F (Status Request)
Mechacon: D51F01234F --> FFFF10200F (Status Request)
Mechacon: D03F --> FFFF (Pause)
Mechacon: D01F --> FFFF (Stop)

I knew you would port Magic Floor. I knew it. Welp. Gotta wait for NO$SNS update now.
Anyway because I actually checked the source code, here's a picture of the Backup RAM Manager:


It can be accessed by pressing Select ONLY if the CD-ROM System is detected.

[nocash]

Really, there is no escape, one day Magicflr will get ported to your pillows and toothbrushes to be played all night long :- )

Oh, yes, you are right, SELECT for SRAM Manager works only if the cdrom is detected (unlike A+X for Test screen, which works any time). I've been already wondering a bit why I've missed the SRAM feature until seeing it in the disassembly.

Btw. is there anything known about the Disc that was found togther with the SNES CD console? Was it dumped? Is it still intact? Does it contain SNES CD software at all (with the SUPERDISC string in volume descriptor on sector 00:02:16? And if so, it would be neat to know if it contains Audio tracks (easy to determine), or ADPCM sectors (more difficult to see). If that features are known to be used by an existing disc, then it'd feel a bit silly to release an emu that doesn't support that stuff. Then on the other hand, I'd tend to ignore CUE sheets and TOC emulation for Audio tracks if there aren't any multi-track discs at all.

Oh, and thanks for the notes about the sinc function and tapering window, I don't really understand what it's all about, but it sounds as if there might have been some reason for using that zigzagging. On the PSX it's done in conjunction with ADPCM to 44.1kHz resampling, which probably doesn't occur on SNES CD as it could feed the CD-DA and ADPCM stuff to one of the LC78815M chips at their own sample rates (and then mix it with the 32kHz SNES audio on analog level). Hmmm, or maybe, although not really needed for the SNES, maybe Decoder chip is held to output always 44.1kHz for both CD-DA and ADPCM, too.

[LuigiBlood]

Btw. is there anything known about the Disc that was found togther with the SNES CD console? Was it dumped? Is it still intact? Does it contain SNES CD software at all (with the SUPERDISC string in volume descriptor on sector 00:02:16? And if so, it would be neat to know if it contains Audio tracks (easy to determine), or ADPCM sectors (more difficult to see). If that features are known to be used by an existing disc, then it'd feel a bit silly to release an emu that doesn't support that stuff. Then on the other hand, I'd tend to ignore CUE sheets and TOC emulation for Audio tracks if there aren't any multi-track discs at all.

He couldn't find the disc anymore, unfortunately.

[nocash]

Oops. So the disc was last seen at some point several years ago? Too bad, but good to know about that either.
Well, then, magicflr is the only currently existing Super Disc game :-)

[tepples]

Oh, and thanks for the notes about the sinc function and tapering window, I don't really understand what it's all about, but it sounds as if there might have been some reason for using that zigzagging.

If you're curious about zigzagging and have an hour to spare looking at oscilloscope pr0n, try this:

1. Watch the video A Digital Media Primer for Geeks (30 minutes).
2. Read about the Gibbs phenomenon.
3. Watch the video Digital Show & Tell (24 minutes).

[d4s]

Just wanted to take a minute and thank you guys for the effort you put into this so far,
especially byuu and nocash of course!
Finally getting a long-standing mystery like that revealed feels really satisfying.

Also congratulations for writing the first homebrew software for it, nocash!

I'm kind of intrigued by the opportunity of creating homebrew software for this thing, even though it's a lot less appealing than the MSU-1 in terms of raw specs and installed user base.
The thought of having your software run on the single survivor of a system thought to be extinct really is something, though.
If they can get their unit to work, that is.
We'll see...

Documentation should cover about everything, from component list, memory and I/O map, and volume/bootsector info and specs for the BIOS functions at 00h:Exxxh.

I'll be able to find this in your fullsnes files in the future, I assume?

[edit]Just saw the update, thanks alot![/edit]

A couple of questions on your opinions/educated guesses regarding the actual hardware:
-Do you find it likely that the 256kbyte cartridge RAM can be accessed at fastROM-speed ($420D.0 = 1) reliably?
I understand it's mapped to fastROM-area, but WRAM-accesses on the SNES are always slowROM as far as I know, and It seems to be using the same chips...
-Do you find it likely that this device has some sort of copy protection (Similar to the SCEx wobble on PSX discs) that would prevent a burned CD-R to boot?
-Do you think it's possible to emulate ADPCM/CD-audio faithfully with the current information available, i.e. if no original Super Disc software with said features surfaces?

Personally, I hope that the recent interest in the system will lead to the rediscovery of some more software and maybe even another unit sooner or later.

Anyway, keep it up! =)

[nocash]

Just released the CD emulation viewtopic.php?f=12&t=13983 a few minutes ago. And also the CD hardware documentation http://problemkaputt.de/fullsnes.htm#snescartcdromdrive

For WRAM speed, I haven't checked if the BIOS cart sets port 420Dh to fast mode. Theoretically it could do that. I've tested mirroring the normal WRAM from normal SNES consoles to "fast" memory banks some years ago - and that seemed to work stable. The WRAM accessed via port 2180h is also "fast". Don't know Nintendo used "slow" access for bank 7Eh/7Fh, maybe it's more reliable at certain temperatures, or would be required when using cheaper memory chips, or maybe there was no real/good reason for doing so at all.

If I should guess: I would assume that the prototype didn't (yet) have any copy-protection. But if there's something like the PSX "SCEx" strings hidden on the discs, then that part should be visible in the mechacon ROM, which will probably dumped if anybody does ever seriously try to repair that console.

ADPCM and CD-DA: I've added that stuff as final detail in the no$sns emulation: It's roughly working (the timing/sync isn't perfect, producing some clicks during playback). Some cautions on using CD-DA and ADPCM in no$sns or on real hardware:
- no$sns supports 930h-byte sectors only for .ISO files (not .CUE/.BIN), so CD-DA and ADPCM would work only with .ISO's
- no$sns supports only one track (so playing "CD-DA sectors in Track 1" works, but seeking regular "CD-DA tracks" won't work)
- the BIOS cart doesn't unmute sounds (unless first running the selftest which is doing so) (without unmuting the external audio input from CD-DA and ADPCM should be muted (unless the prototype console works different as normal SNES mainboards)
- the BIOS cart doesn't seem to contain a ready-to-use function for CD-DA (though the six-button panel on the mechacon might allow doing so... as long as the APU isn't forcefully muting the cd-audio)
- the BIOS cart can play ADPCM from PSX discs in .ISO format (do the unmute trick, then enter the ADPCM test, and key in the same File/Channel and MM:SS:FF values as used by the PSX game (the values can be seen in no$psx I/O Map window for example, but beware: The SNES BIOS wants File/Channel in decimal (eg. File 28h would be File 40 on the SNES). And don't forget to toggle to double-speed mode (Y button) since most or all PSX games use that speed.

[Near]

> And also the CD hardware documentation http://problemkaputt.de/fullsnes.htm#snescartcdromdrive

Excellent, thanks so much for all your help with this! :D

> Don't know Nintendo used "slow" access for bank 7Eh/7Fh, maybe it's more reliable at certain temperatures, or would be required when using cheaper memory chips, or maybe there was no real/good reason for doing so at all.

When I was dumping my US carts, I tried repeatedly to hammer several carts marked as SlowROM as fast as I could in FastROM mode to see if I ever ended up with a read error, and I never did. It was my intention to log the ROM speed in my game manifests (I never trust the ROM headers, they're wrong too often) and emulate the behavior of reading too quickly, but not being able to trigger it, I wasn't able to do so.

I suspect the tolerance was just extreme paranoia or future proofing (being able to release systems with cheaper chips at slower speeds later on.)

> I'm kind of intrigued by the opportunity of creating homebrew software for this thing, even though it's a lot less appealing than the MSU-1 in terms of raw specs and installed user base.

Oooooh! I didn't want to nag you, but I figured you were probably the only person capable of doing something really cool with the SNES-CD :D

But yeah, it does suck that it's basically a super crippled MSU1. You can't add a coprocessor of your choosing*, you're stuck with only 256KiB at a time for loaded disc data, you can only read at 150KiB/s (or maybe 300KiB/s in double-speed mode??) so no MSU1 video scenes, you can't play CD audio while reading data from another area of the disc, you have only the 8KiB of SRAM to share for every game on the system, and the interface is nightmarishly complex (the documented BIOS calls really help, though!)

(* well, technically the base unit is separate from the cart. So if you write your own BIOS, or make a new manifest for the existing one, you could add such a thing ... but that's much less 'official' then.)

It literally doesn't do a single thing better than MSU1, although I guess you might be able to make the audio smaller (and lower quality) through the ADPCM.

Anyway ... still cool to try and emulate. But I'm afraid I'm unlikely to succeed in doing this on my own. I've never worked with CDs before. I don't know anything about them, or their rip formats (ISO/BIN/etc), or the various modes (1/2/etc), or about LBA vs MSF addressing, or anything else like that.

Obviously, I'm going to try and learn this stuff where I have time. But I'm also incredibly busy with WonderSwan emulation, work on my debugger (loki), and then the FEoEZ translation, so this won't be a high priority for me. So if it's to be emulated, I'm going to need some help. Hoping LuigiBlood's up for it, but if anyone else were interested, I'd be highly appreciative. I think the WonderSwan emulation's about good enough now, so I can probably post a new build with the WIP SNES-CD work here soon.

It's also going to be a really weird setup in higan to load and eject CD-ROMs. So that's gonna be a fun design challenge for sure.

> http://problemkaputt.de/fullsnes.htm#sn ... rmcpu1game

So you finally added ARMv3/ST018, eh? Awesome!

Now then, how soon can I expect emulation of the NTT modem and a network simulation of it? :D

I want to place horse racing bets on no$RA PAT! ^_^

[93143]

technically the base unit is separate from the cart. So if you write your own BIOS, or make a new manifest for the existing one, you could add such a thing ... but that's much less 'official' then.

Like I said earlier, I don't see why you couldn't do a cart+disc combo game, with the BIOS as part of the game code. Less "official", sure, but is it actually implausible? As in, is there any reason someone couldn't have sold such a thing back in the day?

With a hefty add-on chip like the SA-1, it might be possible to manage a half-decent video codec...

...or if somebody digs up an example of the version with the 21 MHz 32-bit RISC coprocessor and over a megabyte of RAM, you could just use that...

[Near]

As in, is there any reason someone couldn't have sold such a thing back in the day?

Nintendo would most likely deny them licensing for that. But if they paid enough money, sure. And then you'd pay them $100+ for the game.

There is also the weaker possibility that even if they released this without a coprocessor, or with a weak one, that they could sell an "enhanced system cartridge" that would up the power and remain backward compatible. Similar to SGB2 in a sense.

...or if somebody digs up an example of the version with the 21 MHz 32-bit RISC coprocessor and over a megabyte of RAM, you could just use that...

The best bet for a bullshit coprocessor would be the ARMv3 with an added DMA port between ARM RAM and the SNES bus. Combined with specifying the frequency of the ARM chip in the manifest, and you'd basically have all the power you could ever want. And compile your own C programs for it, too.

But again, it'd be even better if you combined that with the MSU1 instead of the SNES-CD.

[93143]

Nintendo would most likely deny them licensing for that.

...right. Nintendo was paranoid about its own developers knowing too much about how the system worked, weren't they? Hence the microcode issue with the N64...

But would they really have prevented the developers from being able to write their own control software? Or are you just talking about licensing the official BIOS code?

There is also the weaker possibility that even if they released this without a coprocessor, or with a weak one, that they could sell an "enhanced system cartridge" that would up the power and remain backward compatible. Similar to SGB2 in a sense.

So, kinda like a 32X that required a Mega CD to run?

...huh. The 1992 EGM article on the SNES CD-ROM actually mentions this possibility. I hadn't remembered that...

...or if somebody digs up an example of the version with the 21 MHz 32-bit RISC coprocessor and over a megabyte of RAM, you could just use that...

The best bet for a bullshit coprocessor

But if we had an actual prototype or even good enough technical data on the Nintendo Disc system in that 1993 paper, it wouldn't be a bullshit coprocessor. It'd be real period hardware that didn't happen to get to market, just like the PlayStation this thread is about.

[Sik]

Nintendo was paranoid about its own developers knowing too much about how the system worked, weren't they? Hence the microcode issue with the N64...

For the record, I heard somewhare that the problem may have been more SGI than Nintendo on this one.

[nocash]

I've found the "CD-ROM control board"! TriMesh told me that it would be in the Engadget teardown gallery, http://www.engadget.com/2015/11/06/nint ... de=3690482 (which leads to some interview with a defunct link to an absent teardown gallery with "22 photos"). But the interview mentioned "Daniel Cheung" doing the teardown, which led me to this page http://www.p-nintendo.com/news/playstat ... ste-242528 with several photos that don't seem to be available anywhere else.

Looks as if the drive tray has been opened someway, apparently without any disc being found inside of it. The cart-eject lever is visible on some photos, though without any signs of the Reset button (not that that part would be very important).

And, the "CD-ROM control board" is on this photo, http://images.p-nintendo.com/o/2015/11/ ... c01cca.jpg not the best resolution but enough to confirm that all those missing cdrom-chips do actually exists. The one chip with legible part number being a Sony CXA1372AQ (RF Signal Processing Servo Amplifier for CD Player), which implies that the other 48pin chip (IC203 on mainboard) must be something else, ie. obviously something that decodes port 21Exh, probably also including an UART or whatever is being wired to the NEXT connector at the rear side of the console.

[d4s]

Allow me to revive this thread and leave something here before returning to work on more pressing issues.

A couple of friends and me (under the pseudonym "Dieter von Laser") developed and released a new game for the Super Disc:
https://www.youtube.com/watch?v=99-v8lkoOdo

The downloadable file linked in above video includes both the Playstation Super Disc version and a regular SNES ROM version (to enable everybody to play it on real hardware).
Paradoxically, the Super Disc version is inferior to the ROM version (less animations, longer load times).

I had a lot of trouble getting the disc loading to work, to the point of almost giving up on the CD version for good.
If it hadn't been for nocash's help, I could never have done it.
Thanks again, Martin!

We had tons of fun developing this game and I sincerely hope you'll enjoy playing it, too!

Btw: I heard through the grapevine that the actual prototype might have been repaired already.
I have high hopes that we'll see Magic Floor and the Super Disc version of this game running on real hardware some time in the future.

[Drew Sebastino]

I didn't even think this were even close to being possible... Congrats!

I am curious though, how much memory is in the disk? You said that there's actually less animation in the CD version.

Oh yeah, really random, but I like how the BG3 status bar employs a gradient. It looks so much nicer. The spinning window layer is also awesome. I like little graphical touches like that.