It is currently Tue Jul 25, 2017 7:33 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 54 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Tue May 09, 2017 1:29 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 92
Location: Sweden
The SNES-CD was certainly a case of too little, too late even at the time of its inception. As a curiosity it's pretty awesome, but that's the extent of it if no prototype software ever surfaces.

I guess we can only hope that some more information about the whole project comes to light at some point. I wonder how far along the other design(s) outlined in various magazines was, for example the one with some 32-bit processor on board. It's too bad there never was an "Ask Iwata" edition on this topic...


Top
 Profile  
 
PostPosted: Tue May 09, 2017 3:10 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3444
Location: Indianapolis
I could be wrong, but my impression was that Nintendo ditched this design and Sony, so maybe Nintendo also realized that it sucked and intended to release a different CD-ROM system (which obviously was also cancelled). It's a fascinating bit of history, but seems like an odd choice to want to reproduce. Sorry I don't have a link for it, but I remember seeing Nintendo docs that were leaked about the CD-ROM system and it didn't look like the discovered Playstation at all. Much more RAM, 21mhz 32-bit RISC CPU, 65C02. Seemed like the doc had a decent amount of info (I think it was mostly about the CD-ROM data formats and how to load), but I was a little annoyed that it never said what that 32-bit CPU was exactly.


Top
 Profile  
 
PostPosted: Tue May 09, 2017 10:00 am 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2787
lidnariq wrote:
Back-of-the-envelope calculation for "cheapest BOM I can think of with access to lots and lots of storage":
128KiB 5V BIOS ROM/@10 ≈ $1
128KiB 5V RAM/@10 ≈ $1.70
74'139 /@10 ≈ $0.30
CF socket /@10 ≈ $2.70
PCB /@10 ≈$1.5
CF card /@1 ≈ $10

→ CF design ≈ $17.2

128 KiB 3V BIOS ROM/@10 ≈ $0.80
128 KiB 3V RAM/@10 ≈ $1.60
3x 74'16244/@30 ≈ $0.50
iCE40LP384 (QFN32) /@10 ≈ $1.67
8 KiB SPI FPGA CFG ROM/@10 ≈ $0.30
microSD socket ≈ $0.70
PCB /@10 ≈ $1.5
SD card /@1 ≈ $6

→ SD design ≈ $13

... Huh. Well then.


Would that be capable of the MSU-1 or just an interface to read data from the Flash Memory Card? If that could do MSU-1 then all it needs is more RAM. There is no reason to use only 128KB. I'd consider 512KB a bare minimum. Depending on the size and mapping you could load MSU-1 hacks of some games in addition to homebrew which would help things get started.

Does MSU-1 support saving to its mass storage? Or do you still need some battery backed RAM if you were to make a RPG or other game wanting save data?


Top
 Profile  
 
PostPosted: Tue May 09, 2017 10:31 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5922
Location: Seattle
Memblers wrote:
Much more RAM, 21mhz 32-bit RISC CPU, 65C02. Seemed like the doc had a decent amount of info (I think it was mostly about the CD-ROM data formats and how to load), but I was a little annoyed that it never said what that 32-bit CPU was exactly.

So, the option for CD-ROMs that wasn't Sony was Philips, and I bizarrely I seem to have found this random catalog from Philips Semiconductor in 1996. Philips, unlike most of the other semiconductor houses, doesn't seem to have had an in-house 32-bit architecture; the only option they seem to have in this catalog is something 68k-based. And that's not RISC.

... Then again, much as the PS1 was Sony's result of being snubbed by Nintendo, the CD-i was Philips's, and it uses the https://en.wikipedia.org/wiki/Philips_68070 , and those letters "SCC" appeared again.


MottZilla wrote:
Would [that back-of-the-envelop SD card BOM] be capable of the MSU-1 or just an interface to read data from the Flash Memory Card?
I was thinking the latter, but the next step up in FPGA (iCE40LP1K, about $3 more expensive per unit) I think should have enough logic cells to implement the MSU-1.

Quote:
If that could do MSU-1 then all it needs is more RAM. There is no reason to use only 128KB. I'd consider 512KB a bare minimum.
I mean, novel games that target the MSU-1 is an entirely different design than ROM hacks that graft the MSU-1 onto an existing game. The choices one would make for the former are tremendously cheaper because the MSU-1 both supports very low seek latency and very high data transfer rates. Only having 128 KiB of RAM is a not-unreasonable reasonable choice IF you can swap out arbitrary chunks of RAM at full DMA speeds.

On the other hand, if you want to support random ROM hacks where someone added MSU-1 support to a random 32Mibit game ... well, yes, supporting that is going to require that you put at least 32Mibit of RAM on the cart, and that increases the cost. Perhaps not directly—after all I can trivially find a 3V 16 Mibit DRAM for the same cost as the 1Mibit SRAM—but I have no intuition about how many logic cells a DRAM controller would take, and so I have no intuition as to whether the complexity of "MSU-1 translator" and "DRAM translator" would fit into the fusemap or not.

Quote:
Does MSU-1 support saving to its mass storage? Or do you still need some battery backed RAM if you were to make a RPG or other game wanting save data?
I'm pretty certain it doesn't support saving. It would probably be cheapest to either partition the boot ROM into a small "boot partition" and an FPGA-unlockable remainder, and/or providing an interface to the 25xxx series SPI flash. Or maybe, if the FPGA initializes fast enough, to omit the boot ROM altogether and just use a large 25xxx SPI flash for all the nonvolatile bits.


Top
 Profile  
 
PostPosted: Tue May 09, 2017 10:54 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18671
Location: NE Indiana, USA (NTSC)
You don't even need the boot ROM if the FPGA holds the CPU in reset until it initializes and reads $00FE00-$00FFFF from the first sector on the SD card.

Then the debate becomes one of an FPGA that just interfaces with the SD vs. an FPGA that can do the whole MSU. The former would require a music engine that can stream from the SD to the SPC700, but it might make original games using the SD for large capacity cheaper to build.


Top
 Profile  
 
PostPosted: Wed May 10, 2017 3:23 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3444
Location: Indianapolis
lidnariq wrote:
Memblers wrote:
Much more RAM, 21mhz 32-bit RISC CPU, 65C02. Seemed like the doc had a decent amount of info (I think it was mostly about the CD-ROM data formats and how to load), but I was a little annoyed that it never said what that 32-bit CPU was exactly.

So, the option for CD-ROMs that wasn't Sony was Philips, and I bizarrely I seem to have found this random catalog from Philips Semiconductor in 1996. Philips, unlike most of the other semiconductor houses, doesn't seem to have had an in-house 32-bit architecture; the only option they seem to have in this catalog is something 68k-based. And that's not RISC.

... Then again, much as the PS1 was Sony's result of being snubbed by Nintendo, the CD-i was Philips's, and it uses the https://en.wikipedia.org/wiki/Philips_68070 , and those letters "SCC" appeared again.


What would be funny is if it was ARC, but who knows.


Top
 Profile  
 
PostPosted: Wed May 10, 2017 10:17 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5922
Location: Seattle
ARC certainly would have been Nintendo's in-house option. When the previous advertizing blurb mentions a "SCCP" that could have only meant that Philips would have been the foundry; that the CD-i uses a SCC68070 could have been due to suddenly having no plan for a CPU and just going with their only in-house offering.

Wikipedia has the following insinuation that Argonaut was still on good enough terms with Philips after the SNES-CD collapse:
After building the Super FX, Argonaut designed several different chips for other companies' video game machines, which were never released. This includes the following: the machines codenamed GreenPiece and CD-I 2 at Philips...


Top
 Profile  
 
PostPosted: Wed May 10, 2017 2:05 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 890
FrankenGraphics wrote:
RPG:s and the like could've benefited from having lots of recorded dialogues and phrases.

Frnakly, just having more space for written dialogue would've helped those like Secret of Mana.
TOUKO wrote:
Quote:
If someone makes a Super FX game (or an SA-1 game) it's far more interesting to see it being mixed with stock hardware tricks than just a straight up buffer.

I don't know if that count but there is a SMW mod which use the SA-1:

The "coprocessor purely for power" patch gets put into level compilations nowadays, I hear.
byuu wrote:
It would be an absolute pipe dream, but I'd love if the MSU1 passthru device had user-upgradeable firmware on it, and you could add patches to it, so when you put Chrono Trigger US on there, it played it with orchestral audio. And when you switched to Super Metroid, it'd play its music instead.

Yeah, a true patcher device rather than the three-dot Gamegenie would be great. It would also probably bring down N's wrath.


Top
 Profile  
 
PostPosted: Wed May 10, 2017 2:39 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2787
Myask wrote:
Yeah, a true patcher device rather than the three-dot Gamegenie would be great. It would also probably bring down N's wrath.


Why? There are tons of flash carts out there. They don't have any problem. Neither would a hypothetical super Game Genie for patching large amounts of original game cartridges. Not to mention the SNES is dead in the marketplace so Nintendo isn't going to spend money on any action that they not only could lose but also wouldn't stand to make any money from.


Top
 Profile  
 
PostPosted: Wed May 10, 2017 11:34 pm 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 200
Memblers wrote:
I could be wrong, but my impression was that Nintendo ditched this design and Sony, so maybe Nintendo also realized that it sucked and intended to release a different CD-ROM system (which obviously was also cancelled). It's a fascinating bit of history, but seems like an odd choice to want to reproduce. Sorry I don't have a link for it, but I remember seeing Nintendo docs that were leaked about the CD-ROM system and it didn't look like the discovered Playstation at all. Much more RAM, 21mhz 32-bit RISC CPU, 65C02. Seemed like the doc had a decent amount of info (I think it was mostly about the CD-ROM data formats and how to load), but I was a little annoyed that it never said what that 32-bit CPU was exactly.
The story goes, it was all done, and good to go. Then Yamaguchi reads the contract, which had a clause that says Sony gets control over what is published on the platform and all the licenses etc are approved by Sony. Basically so Sony steals the SNES. Yamaguchi flips the tea table.

Sony then takes it, bolts on the other components and launches the PS1, as basically they wanted in on the games market. Sony's biggest worry was Yamaguchi would be so vengeful that he would use the stock piles of cash Nintendo had, to buy up the PS1s in Japan and but them in a warehouse and that would have killed Sony. Luckily for Sony he didn't.

And if you ever look at developing for a PS1,2 or 3 and wonder why it is soo bat shit crazy, remember they were designed by the guy who made the SPC700 ;)


Top
 Profile  
 
PostPosted: Thu May 11, 2017 1:28 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 890
MottZilla wrote:
Myask wrote:
Yeah, a true patcher device rather than the three-dot Gamegenie would be great. It would also probably bring down N's wrath.


Why? There are tons of flash carts out there. They don't have any problem. Neither would a hypothetical super Game Genie for patching large amounts of original game cartridges. Not to mention the SNES is dead in the marketplace so Nintendo isn't going to spend money on any action that they not only could lose but also wouldn't stand to make any money from.

I was interpolating from N trying to get GG over "derivative works", takedowns of fangames, (and SMW hack videos around MarioMaker), their international counter-flashcart efforts, and MicroStar v. FormGen holding that user-created levels are derivative works.

Perhaps I'm not up to date and am just feeling chilled.


Top
 Profile  
 
PostPosted: Thu May 11, 2017 8:15 am 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 156
Oziphantom wrote:
And if you ever look at developing for a PS1,2 or 3 and wonder why it is soo bat shit crazy, remember they were designed by the guy who made the SPC700 ;)

The PS2 and PS3 are legendary for their insane hardware, but I'd always been under the (possibly misinformed) impression that the PS1 was a fairly pleasant platform to work on, and that's one of the reasons why developers flocked to it instead of the comparatively nasty N64 or Saturn. What's so batshit crazy about it?


Top
 Profile  
 
PostPosted: Thu May 11, 2017 9:58 am 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2787
I haven't done very much with the PS1 but the little I did it seemed like a nice system to work with. I've been under the impression like you that being easy to work with was one of its strengths. The PS2 I remember being known for development difficulty. PS3 and the whole Cell CPU I remember being mentioned too.


Top
 Profile  
 
PostPosted: Thu May 11, 2017 10:26 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18671
Location: NE Indiana, USA (NTSC)
What the Atari Jaguar, Sega Saturn, Nintendo 64, and PlayStation 2 have in common is a separate core to run the vertex shader and feed the blitter. This is Tom for the Jaguar, the second SH-2 for the Saturn, the Reality Signal Processor (RSP) for the Nintendo 64, and the Emotion Engine's vector units (VU0 and VU1) for the PlayStation 2. Back then, a programmable vertex processor was a new and unfamiliar thing, and multicore in general had largely been used for audio, which is generally less tightly coupled than graphics. Developers at the time had an easier time wrapping their heads around the more fixed-function vertex processing in the original PlayStation's Geometry Transformation Engine (GTE).


Top
 Profile  
 
PostPosted: Thu May 11, 2017 11:00 am 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2787
I've never heard that before about the Saturn's second SH-2 being used that way. I thought it was entirely general purpose as apparently some games leave it idle. But I've never seen any information on this from a reliable source like an emulation project or something like that.

But that does sound like a big advantage for the PS if it was simpler to work with back when making 3D games was still very new.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 54 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group