i feel like a youtube series where i look at the technical specifications of old hardware and propose changes would be fun
the atari jaguar, for example, had ITS OWN INSTRUCTION SET ARCHITECTURE for the two coprocessors, separate from the one for the main processor!!, presumably because designing and building something in-house was cheaper than buying and/or licensing something else, but... FUCKING WHY. I'VE LITERALLY NEVER SEEN ANYTHING MORE DEVELOPER-HOSTILE IN MY LIFE. LMAO. (plus they were apparently notoriously buggy? i wouldn't know anything about that) to the less tech literate, imagine everything you've heard about the sega saturn being hard to program for... and multiply it by ten. a lot of games didn't even touch these chips!
so my proposed change is scrap the whole design, scrap the pivot back to video games (which was founded entirely on the "promise" of this design and making the rest up as they went along), maybe even scrap the falcon, and develop a new line of powerpc computers running unix (which they had a license for) and market it to amiga and mac users, in particular pointing out that the new power macs had to use the same emulation software for legacy software that would enable their computers to run legacy mac software, and did not have proper multitasking like them. either commodore (well, not so much commodore- all of their weird decisions in their last years came from desperate attempts to grab cash because they were flat broke) or atari could have easily done this and survived, probably surpassing and maybe eliminating apple, but they both ran into the same kinds of technological dead-ends for similar reasons and both bungled a pivot to video games in 1993 and both bit the dust in hilariously similar fashion.
like, this is straight-up, canto XX. beyond just 'cursed', this is total sorcery, disfigured and grotesque. wrought into a slithering heap of expensive ASICs and unconventional system design, while staring directly at the most sensible and cost-effective outcome (use a plain, cheap CD-ROM drive and connect it to the system bus!), Atari diverges greatly from the unilateral course of time, and proceeds instead to march backwards, ever deeper into the hell they've dug into with an entirely custom, software-controlled and software-decoding CD drive. the only thing that hasn't changed between a "CD-ROM" drive proper or a cheapass CD player, and the Jaguar CD, is the laser/transport mech itself, which is the cheapest part of a CD player by this point.
so, the justification given, is that the jaguar is going to expect to be streaming data, code, models and assets, and music from the CD directly. "CD-ROM" filesystems like ISO-9660 and the various CD-XA standards either cause too much overhead for the JERRY DSP to have to process (more on this in a bit), or they hadn't been standardized or invented yet. and it was expected that most CD datapaths would wind up being mostly longer, linear DMA transfers, running independently of the DSP or the CPU, streaming directly to a block of memory. this "feature" was mothballed before release, because the engineers couldn't debug the DMA controller and there were bus conflicts which would randomly, and with no warning, corrupt data on the fly between the CD and memory. I believe it's in the reference manual with a "DO NOT USE" and all associated documentation or references redacted or outright stricken.
so, because it is stream-oriented, rather than file- or block-oriented, atari jaguar CD games are not CD-ROM, they are CD-DA, or CD audio. every set of data is loaded, seeked or streamed as a track number or track number and offset. there's a Jaguar-specific "TOC" 'file' in the Boot Track, which.... maps locations in the tracks/streams... to file names OH SO THEY NEEDED FILES ANYWAY. O.K.
the atari jaguar CD is infamous in that its entire I/O bus and control is handled by the DSP. you had to use an Atari-provided library to "throw bits over the wall" from the DSP chip, on a realtime interrupt servicing basis, 16 bits at a time (remember! DMA is DOA!), permanently sacrificing a not insignificant amount of graphics/sound capability (both DSP chips were often serving roles in graphics pipelines) to service disc timings and interrupts, instead. the disc hardware, itself, was little more than the "front" part of a CD player - spindle drive, pickup head (laser diode/power, laser optics/tracking/servo, photodiode), EFM decoder, and laser carriage mech) with a straight 16-bit multiplex bus. all the tracking, including servo loop and motor control and feedback, and some of the channel decode (but thankfully not the raw EFM decode) were DSP programs managed by the JERRY chip.
oh, also
they threw away error correction because it was too complex.
on an audio disc, that's not too bad; you interpolate a sample or two and carry on. if it's really bad, you might skip a bit. for data, that's intolerable and inexcusable. the slightest scratch or a mote of dust could render the entire game unplayable. oops. hey, at least it makes their discs a whole 794MB in size :V
except, in practice most Jaguar CD games were much smaller, and either written redundantly (with duplicate tracks, and an error handler to change the active track set on invalid data) or just hoping that scratches would land closer to the blank parts of the CD where the game isn't written. hell, some Jag CD games don't stretch past 10-50MB total, compressed.
