zlchxo

draguar, (aus.) shepherd, leopard

Well, haven't been on social media for a bit, so here goes nothing. Passionate, polyamorous, non-binary, neo-taíno + 20th century sephardic heritage critter, with Southern roots and Opinions about activism and justice. I don't know what to make of myself any more, so I'll leave it to you. The headmates might also show up occasionally. Don't worry, they're nice.

--

Posts will include: retro tech, retro game archeology, The Funny, blogging, longposts, tagged porn and vore, occasionally political theory, and creative writing c:

--

contact info can be found at my link. You can also "DM" me via e-mail (right-click copy link address).

oh god oh fuck: @zlchxxxo


x, the nothing app
twitter.com/sunny_zilchie
burner email
sunnyalwaysvibes@gmail.com
discord
zilchexo
telegram
zilchexo

zlchxo
@zlchxo

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.


sirocyl
@sirocyl

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.


You must log in to comment.

in reply to @sirocyl's post:

I LITERALLY ALMOST WENT INTO THE JAG CD but i was like "nahh i don't want to be here all day" so bless you. the jag was already the absolute epitome of NIH syndrome (WHO DESIGNS AN ISA FOR A VIDEO GAME CONSOLE??) but it is just a single story underneath the tower of giant toilets ascending infinitely into the sky and through space that is the jag cd... reality-warping hubris. good job on putting out an expansion that makes the base console measurably worse, ya really saved those manufacturing costs guys!
did not know that stuff about the rationale for the jag cd's design! i figured it was just some weird, over-engineered attempt to avoid royalties and/or do copy protection. maybe that's how it was sold to the tramiels- wouldn't be the first time flare hacks span their incompetence into a promotion. (everyone who knows what flare technologies was seems to have a positive impression of them, i disagree, these guys did a hack job on the konix multisystem, they did a hack job on the panther, they did a hack job on the jaguar and they did a hack job on the jaguar cd.) a bigger bus would have helped the jaguar for sure on many counts (for example the baffling lack of music on many titles). architecturally, the jaguar cd format reminds me a lot of the cd-i. would you have any thoughts on how the two compare? it seems the cd-i had error correction at least.
it's very funny to me when atariage fogeys act like the jaguar was a supercomputer that could run circles around the playstation. if that's the case, where are the examples of that? battlesphere? a game with like one object on screen at any given time in the pitch dark? i agree with you that jaguar cd software is quite lacking, not even just for typical jaguar quality issues reasons or technical reasons but just because, for a fucking 1995 release, the low-budget games smack of the dregs of sega cd or amiga cd32 in that all they can think to do to show off being a "cd game" is add fmvs and redbook audio, not even voice acting (yes i know there are SOMEHOW games for every early cd platform that don't even have redbook). highlander has maybe the most modern use of the format and it has... pre-rendered jpegs and clips from a cartoon. i read a review of robinson's requiem on jag cd that stated it was superior to the 3do version because the 3do version has "fog" to hide draw distance issues. the 3do version does not have fog. the jaguar cd version, though, has absolutely terrible draw distance, mountains maybe 20 feet away magically getting taller as you walk towards them. old fanboys die hard i suppose, even when their hardware was explicitly marketed as a budget alternative.

whereas the jaguar CD was done entirely ad-hoc nihil standards, opting instead to abuse CD audio formats to carry data without overhead, the CD-i was overstandardized. It has its own Green Book, in the "rainbow books" series of Compact Disc standards published by Philips. It uses features of the CD and ISO CD-ROM formats, such as subchannel data and multiple version/multisession filesystems, that even PlayStation didn't largely bother with. the parts that PlayStation did bother with, are called CD-ROM XA, and those were a good idea on the table.

Philips put a lot of work into changing and extending the Compact Disc specifications and architecture, essentially to do the things Atari wanted to do with the Jaguar CD by hacking all the data into redbook/CDDA tracks.

Oh, and because of the cost-cutting on the Jaguar CD hardware, and the minimal operating overhead on the DSP, it would only be able to play Red Book CDDA music or data tracks, it likely would never be able to understand CD-ROM formats without cutting into the DSP's processing power even more.

The function that Jaguar CD combo uses to "throw bits over the wall" wasn't even intended for programs or data - it was there to allow things like VLM to pop samples from the CD as it is playing music, for DSP or visualization reasons, or to stream some linear content, perhaps an FMV.

I suspect the JCD was intended as more of an "enhanced CD player for your games", rather than a CD-based game console. its design implies that it was able to stream music or encoded FMVs or extra assets over a game, but would've depended on cartridge games to actually run the game program... but they hacked a program loader into it, and wrote mastering tools to package single-disc games this way.