Jump to content
IGNORED

Upcoming Jaguar Game Drive Cartridge


SainT

Recommended Posts

Yeah, US and EU is the general plan.
 
I may or may not cover UK and possibly any other rest-of-world stuff not covered by others. If it doesn’t prove too much work. I’m trying my best to give myself the ability to spend my time doing useful things like new products and expanding current products (like the fabled Jag CD support).
Do you consider it likely that you'll create a new preorder list and dump the old one? I just need to know if I need to start checking this thread and your twitter every day again!
Link to comment
Share on other sites

13 hours ago, hypochondriac said:
On 11/1/2019 at 7:02 PM, SainT said:
Yeah, US and EU is the general plan.
 
I may or may not cover UK and possibly any other rest-of-world stuff not covered by others. If it doesn’t prove too much work. I’m trying my best to give myself the ability to spend my time doing useful things like new products and expanding current products (like the fabled Jag CD support).

Do you consider it likely that you'll create a new preorder list and dump the old one? I just need to know if I need to start checking this thread and your twitter every day again!

I want to know that to,only 18 before it was my turn.

 

Link to comment
Share on other sites

On 11/2/2019 at 7:15 PM, hypochondriac said:

Do you consider it likely that you'll create a new preorder list and dump the old one? I just need to know if I need to start checking this thread and your twitter every day again!

He said IF he chooses to begin hammering some out, it would come from the existing list.

 

 

 

Link to comment
Share on other sites

This is really disappointing news.

I'm not sure why you didn't just extend the already existing delay to include sorting out a manufacturer instead of spooking your customers by creating the impression that you're having some kind of meltdown. Since people were already aware that they had to wait for the cart, extending that wait would hardly have been the end of the world. I'd imagine most customers wouldn't have given it a second thought.

 

Actions like this negatively impact a seller's credibility so... perhaps there were additional factors involved in forcing you to take such action. Whatever the case, I hope the project gets back on track soon.

  • Haha 1
  • Confused 1
  • Sad 5
Link to comment
Share on other sites

1 hour ago, g4r37h said:

 

 

Actions like this negatively impact a seller's credibility.

 

Maybe to you, not to everyone. SainT owes you nothing. If you don't want what he has to offer, don't buy it when the chance comes around. It's not like he has any of your money being held hostage nor is he or anyone else forcing you to buy his product. If you don't like what's happening that is your choice and your loss.

  • Like 13
  • Haha 1
Link to comment
Share on other sites

3 hours ago, g4r37h said:

This is really disappointing news.

I'm not sure why you didn't just extend the already existing delay to include sorting out a manufacturer instead of spooking your customers by creating the impression that you're having some kind of meltdown. Since people were already aware that they had to wait for the cart, extending that wait would hardly have been the end of the world. I'd imagine most customers wouldn't have given it a second thought.

 

Actions like this negatively impact a seller's credibility so... perhaps there were additional factors involved in forcing you to take such action. Whatever the case, I hope the project gets back on track soon.

 

It's called burnout. Physical and mental stress over prolonged periods causes decision making to be impaired. Couple this with the fact there are some people in the "scene" (read back a few pages) out to deliberately cause others further stress and harm, and it eventually makes you wonder why on earth you bother doing these things. Trust me, it's not for the money -- if it were, I would never have even started. At that point in time I was quite happy to jack it all in, and very nearly did.

 

And its very easy to make the "correct" decision when you are not furnished with the facts of the matter and you make the decision in retrospect, isn't it?

  • Like 30
  • Thanks 1
Link to comment
Share on other sites

I'm sure posts like 3109 are not helping.  Let's try to keep things in perspective here.  You are placing a man's health and physical well being above the ability to have a multi-game cart for a 25 year old console?

^^^This^^^

 

Sent from my Nokia 9 using Tapatalk

 

 

 

  • Like 3
Link to comment
Share on other sites

I hope things get better for you SainT.  There's always someone that feels the need to be the first person to say something sucks on the internet.  Makes them feel important.  Not to mention those that feel entitled to someone's hard work.   I'll just wait patiently with my fingers crossed.  :)

  • Like 6
Link to comment
Share on other sites

Wish there was an Angry smiley available for the forum and that dumb ass post.  Keep in mind the fool has barely any on this board.  Also, SainT is a HOBBYIST.  Repeat.....HOBBYIST!!!!  He's not Terra Onion, Stone Age Gamer or Krikzz, who operate warehouses, stores, development teams, whatever. 

Edited by Greg2600
  • Like 6
  • Haha 1
Link to comment
Share on other sites

21 hours ago, g4r37h said:

This is really disappointing news.

I'm not sure why you didn't just extend the already existing delay to include sorting out a manufacturer instead of spooking your customers by creating the impression that you're having some kind of meltdown. Since people were already aware that they had to wait for the cart, extending that wait would hardly have been the end of the world. I'd imagine most customers wouldn't have given it a second thought.

 

Actions like this negatively impact a seller's credibility so... perhaps there were additional factors involved in forcing you to take such action. Whatever the case, I hope the project gets back on track soon.

Well done, sir.

asshole-merit-badge.jpg.c50fb47b2f5afcd8363030105706f056.jpg

  • Like 9
  • Haha 3
Link to comment
Share on other sites

I just wish anyone that has anything negative to say would take a few steps back and try to gain some perspective before posting. I have been happily waiting all of this time and will continue to do so. The amount of time and effort that SainT has willingly put into developing this cart is to be commended, yet here he is, having to basically defend himself from what I can only hope are the fringes of "the scene." SainT has delivered other products in the past, so I really don't think his customers are "spooked" in any way. News of delays and uncertainty is usually disappointing, but after seeing the attacks, all I can really do at this point is shake my head and hand it to the man for dealing with it as well as he is. I'd love to have a Jaguar Game Drive cart, but not at the cost of another human being's health and happiness.

  • Like 5
Link to comment
Share on other sites

On 8/7/2019 at 4:30 AM, SainT said:

I don't believe it's possible, its pushing it a bit at 10. I'm using SDRAM, so there is some latency in random reads -- it's better suited for burst reads. Plus you have the refresh cycles to take into account for latency and the fact memory access is asynchronous, so there's no waiting for the cart ROM to return the correct value. You either get it there in time, or everything dies.

 

On 8/8/2019 at 2:39 AM, CyranoJ said:

Everything we have tested (and, believe me, that is a LOT) has worked.

So the 5-cycle access timing did work? That'd have some significant implications on blitter texture mapping performance among other things. (tests Kskunk ran years ago came to the conclusion that the blitter tops out at 5-cycles per pixel/textel while doing scaling/rotation or texture mapping, so you can do way faster than from DRAM, which takes 11 cycles, but won't be able to use the full speed of any of the onboard SRAM: and using the GPU scratchpad or even trying to reserve line buffer space as texture buffer/cache has other performance implications, too, like blocking GPU access to SRAM and depriving the GPU from what little high-speed RAM it has to work with anyway)

 

The cheapest SDRAM currently on Mouser (https://www.mouser.com/ProductDetail/Winbond/W9712G6KB-25?qs=sGAEpiMZZMu4dzSHpcLNgnY7VH5pAzisodYhy9hoWwFIaNTUkscd%2Bg%3D%3D a 4-bank interleaved 64 Mbit 16-bit wide DDR-2 800 chip, $1.37/100 ) is specced at 57.5 ns random read/write times at 800 MHz, so well below the 188 ns 5-cycle limit (and 75 ns 2-cycle one for that matter) though that's also DRAM controller speed dependent.

Still from the old SDR SDRAM datasheets I've looked at, pretty much everything is going to be way below that limit. The 70 ns FPM DRAM used in many Jaguars (some used 80 ns) can even do better than that with a fast DRAM controller, with the spec limit at 130 ns RC (but the Jaguar does 188 ns), but you can fudge that sometimes too, like Atari had with the 150 ns DRAM RAM in the ST doing 250 ns RC when it was rated for 260. (I'm pretty sure the issue is the Jaguar having only 3-cycle RC as the next step beyond 5-cycles, and 3 is too fast, especially the 1-cycle RAS-to-CAS: you'd need 60 or 50 ns DRAM for that, so you get 3+2 and 2+1 but not 2+2 cycle precharge + RAS-CAS setting, and 2+2 would've worked fine with the RAM they used, even the 80 ns stuff and that's the timing Flare used on the 1993 version of their Slipsteam ASIC; I suspect they were hoping for 32~33 MHz out of the Jaguar, probably using the same 32.216 MHz NTSC clock from the Panther and STe, but couldn't get the chips fast enough for it)

 

 

If the firmware is updatable on the SDRAM cart, and the SDRAM could be reconfigured so the Jaguar can actually see it some or all of it as RAM (treating it as slow SRAM/PSRAM) that'd be super useful. Not as cool as if the 2 cycle mode worked, but still cool. (it'd let you keep the DSP and 68k out of 64-bit DRAM as much as possible, much more than what ROM access already would allow)

 

I don't think the Jagua's memory interface would let you map cartridge RAM into the unused DRAM address space (particularly the unpopulated second 4 MB bank) but that'd be neat. The full 24-bit address bus is on the cartridge slot, but it'd be more a matter of what TOM's memory map actually allows across the cartridge port, and if it only expects DRAM in that address range. (including the multiplexed DRAM address lines not present on the cartridge slot, sadly ... otherwise it'd have been relatively easy to add DRAM to games, too, though they also could've just run the DRAM connections to another super-cheap edge connector expansion port routed to the back or side)

 

 

Texture mapping from alternate memory gives you other boosts to blitter performance, too, like avoiding any page breaks or read/write changes to DRAM access while rendering, which means you mix and match texture mapping and gouraud shaded fill operations within the same drawing operation or even mid-line, plus you'd be able to read the Z buffer faster as well (though you have the 1-cycle read/write change overhead for that). One case probably useful for mixing textured and untextured surfaces and Z-buffer reads would be using untextured polygons in the distance (sort of like low-detail textures used in the distance on platforms that relied heavily on texture cache space and bandwidth and especially if they did bilinear filtering) so instead of blurry, smudgy lowres distance detail drop, you'd get just plain, neutral-colored polygons fading into the distance.

 

I assume the 2-cycle ROM mode is also broken for on-cart SRAM and using the various other I/O timings also isn't possible, otherwise that'd be really useful. (and small-ish chunks of on-cart RAM is sort of a retro-savvy trick too, ie relatively common on cartridge based game consoles with significant RAM limitations) 

 

150 ns SRAM or 100 ns (maybe 120 ns) PSRAM would max out that 188 ns (5-cycle) cartridge bus timing, too, which would've been on the cheap/low end when the Jaguar was actually out there, but it just had nowhere near the support/backing (first or third party) that the likes of even the 7800 had (with the variety of games using 8kB and 2 or 3 using 32kB SRAMs onboard).

 

The Jaguar CD didn't include any either, though I wonder if John Carmack had considered including some RAM on-cart to help with Quake on the Jaguar given the very serious performance boost it would provide and potentially even allow a smaller and/or slower ROM to be used, or keep from needing more and faster ROM. (probably 64kB as 2 8-bit chips or a single 32kx16-bit PSRAM like the Sanyo ones Sega was using in the Mega Drive/Genesis Model 2)

Faster texture mapping also means more bus time free to the other processors, so all sorts of nice gains there. (including more time/resource to spend doing some sneaky realtime or intermittent hidden decompression loads from ROM, both to DRAM and to update the texture buffer)

 

Oh right, and the Blitter only does one pixel read/write at a time when texture mapping, so any wider than 16 bits won't gain you anything.

 

You could also let the 68000 work in that added RAM at times (along with ROM) and reduce the headache it gives to GPU/OPL/blitter accesses to DRAM. (and when the 68k is under higher priority, namely during an interrupt routine, the time it normally spends hogging the bus might actually allow some cycles free for GPU/OPL/Blitter activity ... I'm not sure how well TOM's memory interface is set up for interleaved bus access: ie if it at least has bus latches on the various bus masters to allow some parallelism a la ST/Amiga or Flare's own Slipstream from version 2.0 onward)

 

On 8/8/2019 at 2:48 AM, SainT said:

Yes, it's my old mantra of supporting the software which exists, not the software that doesn't. It really helps to cut down the workload! :)

 

On 8/8/2019 at 2:10 PM, xucaen said:

It's like I was always told as a software developer - solve the problems you have, not the problems you don't have. ;-)

Yep, but sometimes those problems can get fixed on the developer end by hardware and not just programming. Add a little bank-switching or memory mapping logic, some RAM, a sound chip here or there ... an I/O chip for extra controller ports. Or, of course, tons of extra ROM that was totally impractical early in the platforms life (or, as with homebrew, was totally impractical for all of its original life).

 

You just see the 'use more RAM' 'cheating' on home computer (including old IBM-compatibles) platforms more often. 

 

The irony with the Jaguar is that it had tons of RAM for a game console at the time it was test-marketed in 1993 or launched in '94, but to do that they also made some big trade-offs that didn't pay off, including not expecting the DRAM market to drastically jump up in price in mid/late 1993 and then stagnate for 2-3 years after that. (that burned Atari big time back in 1988/89 and it was happening all over again)

 

The hardware itself is pretty fexible and could've had other configurations/uses (like on a graphics accelerator card) and supported 2 DRAM banks and variable bus sizing, plus a wide range of CPU architectures. It's really optimized for high bandwidth serial bus usage which is great for fast, wide heavily buffered or cached burst operations, but horrible for the few things that aren't supported for that (and horrible for any activity the DSP or 68000 have on the bus as both have horribly slow bus interfaces on top of being limited to 16-bits width, and the 68k has no cache or local RAM of any kind to work in). Populating the second DRAM bank with 16-bit (or wider) DRAM would've allowed full-speed texture mapping and a nice big chunk of DRAM to pull textures from, but having the DSP and 68k work in that (or on-cart RAM even) helps somewhat but not nearly as much as if they'd been given their own slow bus to work on. (and probably putting the cartridge interface on that slow bus, could be just 16-bits wide to cut cost and allow less fragile/finicky connectors to be used, more like the Mega Drive or ISA cards use ... less like PCI or VLB) Atari just would've had to cut corners elsewhere to push towards the $150 price point they wanted. (which, of course, that 2MB configuration failed to meet until 1995) They also didn't work around any of those main bottlenecks with the CD add-on. (like slapping a CPU-stand-in microcontroller and some RAM on there, or just another 68000 and a small ASIC handling interfacing with a shared block of RAM or something like that; another J-RISC chip as the MCU would've been neat, but made no sense with the low volumes Atari was dealing with by that point; licensing the Phillips CD-ROM chipset was enough of a mistake from that standpoint: rather than buying totally off the shelf parts)

 

Or perhaps the more conservatively sensible move of using the minimal 512 kB of 64-bit RAM (4x 1Mbit DRAMs instead of 4x 4Mbit ones) and sticking an expansion port on the back or side to add more later, especially to hedge their best for the limited test market period. You'd want a local CPU bus there too to hedge bets over the 'is the CPU really acceptable on the shared bus?' question.

I'd say Jack Tramiel-esque conservative, except planning for modular expansion was one thing the ST line had chronic problems with. (though the 130 XE and European 800XE at least had the PBI interface to mostly carry over the XL PBI ... and that's more than any standard model ST ever got, or even the Falcon for that matter)

 

Jaguar owners didn't take to soldering RAM on the motherboard themselves, either. Or installing clip-on biggyback RAM or CPU upgrades from 3rd party kits. :P

 

Wait ... actually, an ST/Amiga style 68000 accelerator board with cache would actually be pretty interesting. Or ... I wonder how well asynchronous overclocks work. (they're common on the Mega Drive, but that's with PSRAM and SRAM ... and VRAM through I/O ports, and ROM + wait states that's only sometimes fast enough to cope)

I've seen full system Jaguar overclocks with modified BIOS ROMs, but not just asynch 68k clocks using an external oscillator and halt button + turbo switch, which might work depending how wait states are dealt with. (or not even an external oscillator, but tapping the 26.6 MHz signal from the board; a lot more stable than the 10.7/13.4 MHz video clock signal sometimes used on the Mega Drive)

 

 

Someone could still potentially fix that with some sort of Jaguar Expansion module, maybe as part of some future flash cart project, and it might not be all that expensive to do with some savvy use of components, but then you'd need enough community interest to actually pursue it. (that and these days, the cheap add-on CPU/MCU + I/O + DRAM interface chip would usually be an ARM MCU/SOC, which can be very cheap but also way way overkill: ie you'd want to consciously throttle the CPU performance to be realistic outside of just wanting to max out the Jaguar's native graphics+sound pushing abilities, sort of like installing an old S3 ViRGE graphics card or Rage II mated to a 1 GHz Pentium 3 system ... or a 1.4 GHz Tualatin server chip)

 

There's a couple open-source 68000 FPGA core projects out there too and that would be more retro-savvy for a Jaguar add-on, but I'm not sure it'd be realistic cost-wise compared to using an embedded ARM chip. (it'd have to be in the sub $5 range in bulk given there's a number of pretty versatile ARM cores below that, some not even in the bulk category, and I mean like 900 MHz Cortex A7 MCUs, 64 kB cache, DDR/2/3 SDRAM interface, flash interface, USB, UART, etc)

Albeit all the cheap modern stuff (including DRAMs) require I/O rail voltage conversion, though I don't think that's a big deal. 

Small-ish asynchronous SRAM chips were the only thing I found in the 5V I/O compatible range that'd be relevant to a Jaguar cart or expansion module project. (mostly 16-bit wide 1Mbit and 4Mbit chips in the $1.5-3.75 range, with, which might even be relevant to homebrew developers actually considering hard copy cartridge releases:  12 ns 64kx16-bit, that's 128kB, at $1.45 per 100 units caught my eye while browsing)

https://www.mouser.com/ProductDetail/ISSI/IS61C6416AL-12TLI?qs=sGAEpiMZZMt9mBA6nIyysK9MWTGEIBNWCJ0f%2B8johDE%3D)

 

Having a C-friendly CPU/MCU with at least a modest chunk of RAM to work in (let alone a big chunk of SDRAM) would also open the doors to a number of homebrew developers who've had an interest in the Jaguar but passed it up at some point in part due to portability of other projects. (I know Chilly Willy was looking at the Jaguar before he decided to go for Sega 32x and Sega CD development work back around 2009, and some of the Game Boy Advance homebrew scene ended up spilling over to the 32x, and for that matter, a cheap ARM-based chip in a Jaguar cart would create a good deal of potential overlap there and with the Nintendo DS homebrew scene for that matter, among other ARM platforms: but especially quirky, interesting game console hardware platforms) 

 

 

 

 

 

Anyway, too bad this project is stalled for now, but I totally get crappy life stress issues and unfortunate turns of events. (it's one of the reasons I've been pretty much absent around my old forum hangouts and extremely sporadic for the last 5-ish years)


I actually thought I'd dropped a brief comment in this thread last year after stumbling on it, but I guess I didn't.

 

I also assume it's way too late to make any comments/suggestions on what might be worth including to the card given it's at the ready-for-manufacture state, aside maybe from modifications to the firmware end, though if that's flashable, those updates can continue after the boards ship, too.

 

 

 

That said, I did think it was at least interesting that there's a fairly cheap 8 MB (4Mx16-bit) PSRAM chip available on Mouser at $1.98 /100 units currently, and that seems like a particularly appealing way to go about things. (it's 133 MHz rated, but random read/write speed is 70 ns, but that's still plenty fast for the Jaguar, and a small interface ASIC acting as a memory mapper and 32-bit bus latch could treat it as 140 ns 32-bit SRAM, still plenty fast for the Jaguar's 5, 6, or 10 cycle ROM modes, though at 16-bits it could use the fastROM 2 cycle mode if not for the bugs ... or depending what those bugs actually involve)

 

 

It's barely more expensive than the cheapest 16 MB SDRAM I could find on there and interfacing is a lot simpler, but then you still need the bus latch and memory mapping logic along with the SD card interface.

 

 

 

I also haven't been watching prices or doing any sort of prototype builds or projects myself that involve those sorts of parts, so I'm not sure how much those prices fluctuate. 

 

OTOH, that PSRAM chip might be appealing to other designers out there, or even some homebew cart game developers. (if you're already capable of using 5V compatible ROM chips at acceptable prices then a smaller 5V rated SRAM would make more sense, but if you're dealing with ~1.8 volt I/O translation already, that PSRAM seems potentially intriguing)

 

 

  • Confused 2
Link to comment
Share on other sites

I came here initially to check in about the aforementioned possibility that a Jaguar CD core would be added to Mister eventually - news is out now a beta or WIP Jaguar core is available. 

 

That said, now that I read some of the back posts since I have not caught up with this thread, I'd rather wish SainT the best of health and happiness. I am sorry to hear of your stress and some of the comments that might add to that.  

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...