SNES (Playstation) finally plays CD-ROM games

Hey guys,

I thought you might want to know that Ben Heck actually got the thing to work, with the first game working from the CD-ROM being magic floor.

https://www.youtube.com/watch?v=gaIfPuziJ-0

Well that's good to see. Now will someone make a functionally equivalent clone? And hopefully the same sort of fix for Magic Floor will fix Super Boss Gaiden.

How much of a BIOS will it need? Nintendo and/or Sony still technically owns that.

Is that the 32 bits snes cd?.

It's the 16-bit version of the Super NES CD. I think the 32-bit version just became the PS-X after Sony cut out the dependency on a Super NES host.

The 16 version is only a snes with CD, and nothing more, right?.

Correct. There's not much more they could have done, as there's really no way to enhance the video hardware. I think it's unfortunate the PPUs in these systems didn't have additional busses going to either the cartridge or the expansion port, (reading from either both this and vram, or just this) but that would have cost more money. The PPUs actually take 16 bits per pixel for BGs from vram, which could have been used for a straight up 16bpp bitmap mode had the SNES been given 128KB of vram as originally intended or if what I said earlier was true, which would be more important because the transfer rate to vram is so slow.

There's no advantage the SNES PlayStation has over a standard SNES with the MSU-1. In fact, it's even worse, as CD access times are slower and there is only a 256KB buffer for CD data.

You could possibly implement your own compatible freeware BIOS. Especially since a whole two games currently exist and they probably don't depend heavily on the BIOS doing much more than loading some data into memory.

It's very unlikely anything will ever happen with it. But it's somewhat interesting to see. As Espozo said the MSU-1 is potentially more interesting for adding the features of massive storage and CD quality audio. But it's a different beast than the CD-ROM system.

You could make something using the MSU-1 that is more like the CD-ROM system idea if you implemented the MSU-1 on a stand alone cartridge that had a BIOS and some RAM to load game contents into from the SD memory card or whatever storage you were using.

@93143 And games using this CD add on would still be bottlenecked by shitty object vram management and tile uploading engines. Unless you're dealing with 3D rendering, I think there comes a point where increased CPU power won't improve the appearance of the game at all (a 20MHz 32bit ARM processor isn't going to make Donkey Kong Country look any better). However, I think there still could be one way to improve the graphics if you have extra CPU power, which would be to devote the main CPU to mid scanline raster effects. I think I heard you can't change the Mode 7 parameters mid scanline, but I'd imagine you could change the BG mode and turn the right side of the screen into a coprocessor rendered buffer for a 4 player racing game? How about for really large objects, have the middle be a BG and the edges sprites, so you don't use up an entire BG or heavily reduce the amount of sprites per scanline?

The SNES already has top of the line looking games, Star Ocean for example, using the extra power for more graphics fidelity is a moot point. Using it to improve physics and AI would be handy though. Also using it to do on the fly decode of graphics so you can do smaller loads from the Disc and pack more into RAM would probably be useful.

The other thing is the C lamers can probably just code in C on the new chip and avoid having to do ASM.

I also think if we can get the CD-ROM system working with say more RAM, that it would be a lot cheaper and easier to sell and market new games on CDs rather than expensive repro carts, or repro carts with expensive custom chips like CICs and MSUs

The "right" thing to do with todays technology would be to build a FPGA SNES.

Then there are two possibilities:

1) Utilize the MSU-1 as something purpose-built for the FPGA SNES, development can be done in emulators or with the SD2SNES on other real hardware.

2) Utilize a SNES-CDROM mode that is booted when the cartridge slot is not populated using a re-engineered bios.

So basically the FPGA boot sequence would be "check for cart, check for cd-rom image, check for msu-1 image" and load the FPGA core that works with those modes. Nobody really wants to bother with burning physical discs, and since there are no actual physical SNES CD games to worry about compatibility with, connect that to a micro-SD slot that just emulates a cd-rom with redbook audio passed through digitally. The MSU-1 core would likewise utilize a fully digital path.

Just based on what was seen of the SNES-CDROM Playstation it's pretty clear that the unit they had was meant to be something of the same idea of the PC Engine Duo. Just based on how the hardware was laid out, the CD-ROM unit was just connected to the expansion bus on the PCB itself, and the chips on the PCB would correspond with chips you find on the physical cd-rom on a PC version of the drive. Thus it was likely that an "addon" version would have been produced as well.

128KB. They reused SNES console WRAM chips, 2x64KB, inside the BIOS cartridge.

Yes, you can use the system work RAM, but then you'll have less RAM for your actual game than a stock SNES.



Yeah, it's essentially a really clunky interface to load data off CDs in very small chunks at 1X CD-ROM speeds.

The MSU1 can do 4GB instead of 700MB, at the full 2.68MB/s DMA bandwidth instead of 150KB/s, and no seek times, and you can read data and play Redbook audio at the same time, and the interface is many times simpler, and implementing it elsewhere (sd2snes, Snes9X, etc) is a lot simpler.

You can impose artificial limitations like waiting a full second for every 128KB you read from it, and not mixing data reads+audio playback, if you want the authentic "this would work on the SNES PlayStation" experience.



Eventually you would switch from using the SNES PPU directly to using it like the MSU1 uses FMV, and you'd be capped at 240x144x256 colors@30fps. Given Breath of the Wild runs at 30fps, that's ... not really all that horrible a limitation. But it really begs the question of, "why?!", to the point that even "because I can" sounds incredulous.



Everyone will instead have to buy far more expensive CD-ROM drives for their SNES expansion ports.

We can't even get adapters made for it unless we buy a minimum of 5000, plus a setup fee of $5,000+.



Why? Every person who's tried won't release their source.

And even if they did, how many people have FPGA boards and the knowledge to flash FPGA code onto them?

This would be the most practical way to make CD-like games for SNES today. Make a cartridge that just implements the MSU-1 setup with a small bootstrap or BIOS and a healthy amount of RAM. If it could be produced at low cost it might actually go somewhere. But it would be relying on homebrew creations entirely unlike the SD2SNES and MSU-1 which are interesting to people since it's all hacks to add things to existing games. It's too bad the MSU-1 was never realized as a add-on. Would it be possible or feasible to make a MSU-1 Game Genie style cartridge? So that you could just sell the MSU-1 functionality that could be used with any cartridge. I know unlike the 21fx the MSU-1 lives on the A-Bus so it would have to be a cartridge. Actually the idea of combining a Game Genie concept and MSU-1 together would be really cool to use an original cartridge with patches to play CD quality audio.

But back to the ideas of making any CD-like SNES system today I think the MSU-1 as a standalone cartridge with bootstrap and some amount of RAM would be the most viable. Far more so than any CD-ROM idea since the MSU-1 could just be a cartridge. I don't know how expensive of a FPGA or other circuitry you'd need to implement the MSU-1 but if it could be made for a reasonably low cost then maybe people might be interested.

Sure but can you get a CD "Cart" with an ARM-CortexM[something] and a cheap external USB based DVD drive + some RAM and the BIOS + SRAM is in the EEPROM/FLASH of the ARM? (Side note could maybe also be reworked as a new 1541 and a new FDS type system...hmmm )

Having MSU-1 as a platform is also nice, going "Sonic and Knuckles"/"Action Replay 3" with it would help with costs as it could also host the CIC, but you still have a Expensive Cart to put on top for the hardware users and then a download ROM for the emulators.

I will wager that the majority of users these days, the great unwashed as it were, as using Emulators, to which they put the CD into the tray and boot the emulator. Or add a USB DVD drive to their Retro Pi set-up et al. If the adapter above is feasible, then you have a cheap physical product that both Emulator and Hardware user can use. At the moment you have expensive carts for the users with hardware and "oh well its just another ROM, I will download it with the other 2000" emulator users.

The problem with the notion of aping the SNES CDROM unit is that: even though it technically already exists, it exists in such small numbers that it's effectively a creation from scratch. It'd be a complete recapitulation of the SegaCD market fragmentation without the benefit of being commercially relevant. And in terms of engineering effort, translating between any modern bus (SATA, USB, whatever) and the SNES's parallel bus is going to make it expensive and stupidly designed.

As a design, it's awful; the PCEngine CD and SegaCD both provide dramatically more RAM, helping compensate for the abysmal load rate of a 1xCDROM , while the prototype here provides such a minuscule amount that there's basically no good way to do background loading. Any game designed for this is going to feel like an awkward multicart separated with lots of redbook audio.

You're never going to get anything like the current market for homebrew SegaCD games on the SNES. It's just too rarefied to be relevant.

Even if the RAM were megabytes or the transfer rate was FastROM, what's the point? The Sega CD and PCEngine CD actually exist (one unit available to almost no one really doesn't count) and in the case of the Sega CD, actually provide a benefit outside of storage. This is just like setting arbitrary limits for yourself.

With that kind of storage, it makes me wonder if games were meant to be primarily cartridge-based but have the CD for audio and maybe some other data like title screen graphics. I don't really see the point there though; CDs are meant to be a cost effective measure, but that wouldn't matter if you had to have a cartridge anyway (although the cartridges could be smaller).

RPG:s and the like could've benefited from having lots of recorded dialogues and phrases.

Audio CDs only support a seek precision of 1 second and a 1x drive takes about a second to do the seek. So you really want to cache the audio in order to have any finer-grained control of when things play. But with only 256 (cart)+(128+64+64) total KiB of RAM in the entire system you can't really spare any significant amount of RAM for this.

In fact, that seek latency, combined with the tiny amount of RAM, makes it even worse; at 1x CDROM speeds you can fill the entire cart RAM in just 2.5 seconds. But it never gets much faster: for any size of load it's always going to be around 1.5-2 seconds.

As presented it'd be good for things you can stream from disc without pausing, e.g. soundtracks and cinematics (including yes, voice acting, but not anything that is responsive to the player), and that's really about it.

If the Analogue NT Mini can be made and support all the Famicom, NES accessories, a SNES version is not a stretch. jwdonal's at least half way there with VeriSNES. The SNES is a far more enticing target to reengineer, particularly since the SNES-CD represents a more capable version of the hardware that works with the existing cartridges. The problem is the cost.

What I'm getting at, is that if a FPGA SNES does show up at some point, having the MSU-1 and/or CD-ROM functionality built in makes the requirement to have an additional $250 accessory (another $35 FPGA) unnecessary.



Don't even bother with USB-anything. I've never seen a software emulator actually able to use a real CD-ROM. This is because modern CD-ROM/DVD-ROM drives are CAV unless in redbook audio mode. Adding USB bridges, SATA, and so forth just makes this more of a pain. Once you add USB, you run down the rabbit hole of never ending incompatibilities/speeds/sizes/filesystems with USB external storage devices. At least a SD-card standardizes on something.

Like from a homebrew point of view, a SNES-CD "clone" using a micro-sd card or something offers the most direct approach without having to add another cartridge like the MSU-1. Being able to use original cartridges still allows using the SD2SNES regardless. A more involved project could implement the MSU-1, SA-1, SuperFX, Sufami Turbo, Super Gameboy, etc.

I like what Yoshi's Island did, by incorporating Super FX effects into a standard sprite based game. 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:
https://www.youtube.com/watch?v=spVwBD6NOVI
https://www.youtube.com/watch?v=L-Gexw5l7ps
https://www.youtube.com/watch?v=-OJ_lhc-KkU&t

You can see here all his videos here:
https://www.youtube.com/user/VitorSuper ... rld/videos

Yes, it would. Should work fine to add MSU1 to any flash cartridge or retail cart release. Won't work very well for old SNES copiers, but I think only koitsu still uses those today? Of course that was six years ago so maybe not even he does anymore.



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.

But yeah, a pipe dream of a device. It would be easier for the passthru cart to just -be- a stealth flashcart that identified the inserted cart's game title and then streamed its own ROM copy like a flash cart would. You would just be wasting money on extra hardware and connectors just to add a thin air of legitimacy. And then people would put "patches" that turn the Super Mario kart into Super Metroid and ... yeah.



Yep, and it's already doable with the sd2snes today, and you can request 128KiB of SRAM.



Yeah, that's a great question. It was super overkill on the sd2snes. You can even do MSU1 + other coprocessors at the same time.

If we released the board wiring and an FPGA program, I could even see the possibility of someone eventually doing a new SNES cart release with MSU1 built into it. We have gotten a few new SNES games in cart form recently.



And being honest, given the homebrew nature ... it could take a more "sane" media format for the game cards. Whether that's SD, or a USB HID device slot, or even just an IDE connector that's easier to buy mating adapters for the daughter boards.

The CIC could also be like ikari's and work for both NTSC and PAL regions.



Yep, it would just be an inferior PC Engine CD.

... and I'd still support it in a heartbeat if even one official game disc were there for it. Maybe even a really good tech demo.

But aboslutely zero official software for it? No thank you. I'd rather make up my own devices.



That and the 68K is easy to program for, and you can write decently performing C code for it.

No SNES add-on is going to fully abstract you from having to deal with the base 65816 you have to use to talk to the PPUs, or the nasty SMP->DSP if you want to do sound effects.

Sega CD users can use Redbook audio plus PSG sound effects. They don't have to deal with the Z80 or the YM2612 if it's too complex for them.



Does it matter since jwdonal is keeping all his work to himself?

It's his right to, but is it going to help us? Is it like binaries on Windows where he can just give out 'compiled' Verilog and others can then use it on various FPGAs of their choosing?

Somewhat. A bitstream is built for a specific FPGA (for example, a Cyclone II EP2C35F672), but the distribution path for that is similar to a compiled binary for an existing platform.

Yes but I'm talking about something that doesn't have a $200 cost of entry. Certainly a smaller/lower cost chip (fpga) could be used to make something much cheaper. You just need the MSU-1 functionality with a SD card, a small bootstrap and fair amount of RAM. No need to support Cx4, DSP, Super FX, etc. You'd have your massive 4GB data storage and CD quality audio tracks, and a reasonable buffer to load data into. Making something that's under $100 to do this would probably be enough to get the interest going. With SD2SNES, you're just going to make a cartridge game with CD audio and maybe FMV. All your backgrounds, animations, levels, etc you'll just put in your ROM. With a stand alone cartridge you'd be more incentivized to store it on the SD since that's cheaper storage than FlashROM.



The PC-Engine CD format did so well and being commercially supported for many years any homebrew SNES CD could never come close. But it would be interesting to see what could be done with the SNES and the CD format. It'd be really amusing to make an adapter to hookup a PCE CD-ROM to a SNES. But back to reality, the PC-Engine CD and even Sega CD are why the concept with the SNES is so interesting.

The MSU-1 paired with even just 1 megabyte of RAM could be used to great effect since MSU-1 has extremely fast access to that 4GB of data. With some slower media like CD-ROM I can see wanting more RAM. But I really think that's the closest we'll ever see to a SNES CD-ROM being used by homebrew developers. No one is going to make an actual CD-ROM system. Too expensive for just a homebrew toy.

I think even MSU-1 might be overkill for some homebrew apps. How much would it cost to build a cart with a boot ROM, a 1 MB RAM, and a minimalist microSD interface?

How minimalist? I think sticking with MSU-1 would be a good idea since it exists already. And CD quality audio is appealing not just for the quality but also the simplification to a developer when it comes to adding music. No need to put together a SPC module that handles both music and sound effects, just sound effects.

The Super EverDrive which is a solid Flash cartridge sells for around $86USD. While it's not a great comparison I think it gives you a ballpark figure for cost. You'd need to find out how much it'd cost for the SRAM or PSRAM you want to use as well as whatever programmable logic you need. Depending on component costs it might make sense to have more than 1 megabyte of RAM. How cheaply you could make it really depends on a lot of details that would need to be worked out. It might just end up looking like another flash cart. Ofcourse it would help such a device be more useful if it could load some ROMs by having RAM mapped to be compatible maybe with LoROM up to however much RAM is on board.

Another thing about CD or MSU1 audio is that it greatly broadens the scope of what you can do with the sound effects, since you can use the system's full array of audio resources just for that.

I was considering this for the SA-1 F-Zero game I'm almost certainly never going to make, because it would allow more sophisticated sound effects, including multiple sounds from multiple nearby machines instead of just engine noise for one.

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.

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...

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.

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?

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.

—
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.

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.

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.

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.

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

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:

Frnakly, just having more space for written dialogue would've helped those like Secret of Mana.

The "coprocessor purely for power" patch gets put into level compilations nowadays, I hear.

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.

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

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.

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?

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.

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).

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.

Saturn also had a DSP in a bus management chip for doing stream calculations.

Well the PS1 is probably not "batshit" unlike the other 2, just annoying.
So no FPU, zero floating point support, on a 3D system ( sure the DS does it too but that is a handheld )
No perspective texture correction

So that is why a lot of PS1 games have the "jitters"

If you look at some meshes from PS1 games you will see where the artists had to make a bunch of "scaffolding" to move the polygons back around under and through things. Also there can be no gaps or holes in the mesh, and they needed to be single, that might have been an engine limit rather than the hardware though. I worked on a PS1 port, not an actual PS1, just when I had to ask why does the code do this, why is this like that, I usually got some hand-waving with "because it didn't have logical thing X but had Y, Kutaragi" But I did learn the "PS1 lean", to make the disc load.

Sony gave a library and wouldn't allow people to hit the hardware directly, they eventually relented. Then the graphics programmers could see why they made a lib

Compared to the Saturn the PS1 is a dream. Jaguar, 3D0 heaven

The reason to go PS1 over N64 is more to do with policy than hardware. Programmable pipeline with display lists, fpu, perspective texture correction in hardware and 4MBs with fast transfer from Cart makes the N64 at lot easier to balance, just trying to pack movie and audio and games into 64MB is pain

But to make an N64 game you had to pay for 1 million carts before Nintendo would publish it, this acted as a quality barrier, as the company had to be confident of selling said 1 million carts. Sony wooed devs with we can do runs of 50,000 if you want. So things like Vib Ribbon could be done on PS1 but not N64, this is why the PS1 becomes a glut for shovelware, Sony would do low runs, CDs were cheap, Sony wanted devs all the devs, while Nintendo were ivory tower elitists who would tell you to get stuffed ( still are I guess )
Having the cheap CD format for the SNES at the end of its life with such mentality would have been interesting, but I guess it is no different from the Flash Cart system they had in Japan for the SNES but by then most had moved on.

the PSP was mostly sane baring one strange omissions from its fixed pipeline, dest colour blend? dest stencil? and the square button Oh and the 90 degrees LCDs on the 2000,3000 models that gave red and blue lines on everything... or the PSP Go with no UMD drive...... hmmm

I've always been curious about the PS1's depth sorting and mesh formats. Do you have any links on the topic?

No sorry, back in the day I just read the official "book". The emulator programmers have probably made docs on it though.

Depth sorting is a software matter on the PS1, as there is no depth buffer. It's a "painter's algorithm" situation; a BSP tree was a common way to do it.

I wonder how the later games worked around the int precision problems, causing the jitters. Compare ff7 to ff9, they're like different consoles.

It could have been something simple like switching from integer to fixed-point vertex calculations, but I've never dug into the graphical parts of any PlayStation games' code.

I know that, that's why I asked. BSP should produce perfect sorting of world geometry and fail completely on anything that moves, which is the opposite of what I've actually observed - moving objects look fine, and world geometry is glitchy. So I'm wondering of the depth sorting was part of Sony's SDK or if every developer had to solve it independantly, and what kinds of algorithms were used to handle moving objects, especially the plethora of bendy stuff.

Google playstation polygon sorting pulls up an article about games using a bucket sort, which divides polygons into lists covering various distance ranges from the camera. Then each list is sorted and passed to the GPU.

American flag sort:
1. Count polygons in each distance range
2. Classify polygons into distance ranges
3. Sort polygons within each distance range