Upcoming Jaguar Game Drive Cartridge

[Jagosaurus]

Can you imagine someone coming close to 100,000 writes? Your fingerprints would wear out before the chip!

By the time someone uses 100K flashes, all the Jaguars will be dead anyway

[leech]

Haha, high levels of ADHD could breeze through that fairly quickly. "I want to play Rayman, no, I want to play Doom, nah, I am im the mood for Skyhammer..."

 

Probably why I have only won Doom out of any of those.

[SainT]

Haha, high levels of ADHD could breeze through that fairly quickly. "I want to play Rayman, no, I want to play Doom, nah, I am im the mood for Skyhammer..."

 

Probably why I have only won Doom out of any of those.

 

Sorry, I've confused this thread by answering a question relating to the NeoGeo cart.

 

The Jaguar will be using a RAM solution for the cart, you can play as much as you like.

[VladR]

Oh, and iPhone's for example use standard FLASH memory for their App storage. I've not heard of this being an issue?

Yeah, but who's using their same iPhone for 10-20 years (like we expect with this SD card) ?

 

 

I still find it hard to believe someone would wear out a FLASH chip due to erase cycles, 100,000 is a hell of a lot!

Uhm, not really hell of a lot.

 

When I was coding in C, I dd maybe 4 Skunk deploys per hour.

When I switched to GPU RISC coding and had to start debugging (and hunting for that single offending scoreboarding bug), I had weekends when I did over 1,500 deploys (literally every 2-3 minutes). That's 1 weekend. And 1,500 / 100,000. Suddenly, those 100k cycles don't seem so far...

 

And those 100,000 writes are probably just MTBF estimate. It's entirely feasible, a chip could start "misbehaving" at 80,000 cycles.

 

Granted, creating ~20,000 builds per year is different activity than flashing 20,000 games onto SD card, but 10-15 years from now, even mild usage of SD card will eventually wear it out.

 

I would love to be proven wrong, but the odds of having another similar device on Jag in next decade are slim to zero (unless done by you). So, this is it.

[SainT]

I would love to be proven wrong, but the odds of having another similar device on Jag in next decade are slim to zero (unless done by you). So, this is it.

 

Have you read what I wrote above?

 

For the Jag I'm using RAM for the cart, so there's going to be no issues there. I didn't really want to use FLASH on the NGP really, but the system is actually heavily tied to FLASH memory, so I had no choice due to space, cost and complexity constraints.

 

I still find it hard to believe someone would wear out a FLASH chip due to erase cycles, 100,000 is a hell of a lot!

 

Oh, and iPhone's for example use standard FLASH memory for their App storage. I've not heard of this being an issue?

[VladR]

Well, so far I've been under the impression that the games will be copied from SD card (say, 4 GB) into the RAM you mention.

 

is that a fundamental misunderstanding on my part ? Unfortunately, I never used (or read technical info on them) about everdrives on other consoles, so I don't exactly know how they work. I merely presumed they remapped the filesystem and buffered it into memory via the chip.

 

If, however, each game has to be flashed first (like with Skunk), that's alright too. Which one is it then ?

[JagChris]

I still find it hard to believe someone would wear out a FLASH chip due to erase cycles, 100,000 is a hell of a lot!

 

 

I always figured they used the 100k almost as an arbitrary designation, just to be on the really really cautious side.

[SainT]

On 3/2/2017 at 11:44 PM, VladR said:

Well, so far I've been under the impression that the games will be copied from SD card (say, 4 GB) into the RAM you mention.

 

is that a fundamental misunderstanding on my part ? Unfortunately, I never used (or read technical info on them) about everdrives on other consoles, so I don't exactly know how they work. I merely presumed they remapped the filesystem and buffered it into memory via the chip.

 

If, however, each game has to be flashed first (like with Skunk), that's alright too. Which one is it then ?

 

Ok, let me explain it in more detail.

 

There is 16MB of RAM on the cart, which is used to hold the data for the ROM image. This data can be written directly from the Jag and there is no "remapping" going on of any kind, it's just RAM. You cant access a memory card as ROM, it's a serial device.

 

The cart also has an SPI interface to communicate with the memory card, this is what will be used to read from the memory card and populate the RAM in the cartridge memory space.

 

Each game will have to be programmed to the cart immediately before running it. As the cart is RAM based this process should only take a few seconds to populate the memory, unlike FLASH which is pretty slow to write to.

 

And I agree with JagChris on the 100k erase cycles of FLASH, this figure will be a conservative minimum. Datasheets always specify conservative tolerances, not what you can expect if you push the device to the max.

Edited October 25, 2019 by SainT

[saboteur]

does'nt matter anyway - just buy three or four , use one & store the others. when the first dies on it's arse in 20 years then open up the second one etc.

 

There yoiu go should be good for 80 years

 

Looking forward to seeing the fruits of SaintT's labour - oh and i'm just down the road in Oxfordshire.

[SainT]

does'nt matter anyway - just buy three or four , use one & store the others. when the first dies on it's arse in 20 years then open up the second one etc.

 

Looking forward to seeing the fruits of SaintT's labour - oh and i'm just down the road in Oxfordshire.

 

Lol, yes, I'd recommend everyone do this...

 

I know Oxford a bit, worked in Summertown for a couple of years and lived up in Bicester at one point.

[+rdemming]

When I was coding in C, I dd maybe 4 Skunk deploys per hour.

When I switched to GPU RISC coding and had to start debugging (and hunting for that single offending scoreboarding bug), I had weekends when I did over 1,500 deploys (literally every 2-3 minutes). That's 1 weekend. And 1,500 / 100,000. Suddenly, those 100k cycles don't seem so far...

 

Since Jaguar code is usually not run off the cart directly but copied to RAM, you could during development just USB upload your code to RAM for testing thus saving write cycles in the flash. This is also much faster that flashing your code every build. When everything is debugged and you are ready to finalise the cart, you could put the code in cart space and copy it to RAM.

A combination is possible too. Put the asset data (graphics, music, etc) that does not change often on the Skunk flash and upload only your code to RAM that is using the assets on flash. That is even faster as you only have to upload your code every build and not the data anymore.

 

 

The Jaguar will be using a RAM solution for the cart, you can play as much as you like.

 

[nitpick mode]Due to Electromigration, even RAM has a limited life time. But probably only your grand-grand-grand children will notice that if they are still playing Jaguar games [/nitpick mode]

 

Robert

[VladR]

just buy three or four , use one & store the others. when the first dies on it's arse in 20 years then open up the second one etc.

I'm hoping one will be able to order more than one SD-cart upon its release (e.g. use one, preserve the second one)!

 

 

Since Jaguar code is usually not run off the cart directly but copied to RAM, you could during development just USB upload your code to RAM for testing thus saving write cycles in the flash. This is also much faster that flashing your code every build. When everything is debugged and you are ready to finalise the cart, you could put the code in cart space and copy it to RAM.

A combination is possible too. Put the asset data (graphics, music, etc) that does not change often on the Skunk flash and upload only your code to RAM that is using the assets on flash. That is even faster as you only have to upload your code every build and not the data anymore.

Are you talking about a feature of SD-cart or an existing feature of Skunk ? If it's the Skunk, then I want to smack myself for not reading its docs and realizing you can access jag's RAM from commandline via jcp. Thanks a ton !!!

 

 

 

Ok, let me explain it in more detail.

 

There is 16MB of RAM on the cart, which is used to hold the data for the ROM image. This data can be written directly from the Jag and there is no "remapping" going on of any kind, it's just RAM. You cant access an SD card as ROM, it's a serial device.

 

The cart also has an SPI interface to communicate with the SD card, this is what will be used to read from the SD card and populate the RAM in the cartridge memory space.

 

Each game will have to be programmed to the cart immediately before running it. As the cart is RAM based this process should only take a few seconds to populate the memory, unlike FLASH which is pretty slow to write to.

 

And I agree with JagChris on the 100k erase cycles of FLASH, this figure will be a conservative minimum. Datasheets always specify conservative tolerances, not what you can expect if you push the device to the max.

Thanks a lot for confirming how it works ! Very helpful.

 

 

There is 16MB of RAM on the cart, which is used to hold the data for the ROM image. This data can be written directly from the Jag

Am I reading this correctly, that I'll be able to use those 16 MB (minus 2 MB for ROM image) as a RAM extension as a developer ? E.g. at game's run-time, loadstore (though, certainly not execute code , correct?) additional data (via memory-mapped registers, or I2S bus) into (16-2) = 14 MB ?

 

I understand that SD-access will be native (and unlimited - e.g. 2TB+), but those 16-2 = 14 MB of RAM certainly have faster read/write speed (than SD card), so it would be a preferable temporary storage area (from coder's standpoint).

 

Thanks.

[JagChris]

I always thought ram, except SRAM had to be refreshed(I.e. need a power source or it all goes blank).

 

I guess things have changed. Will have to do some reading.

[+rdemming]

Are you talking about a feature of SD-cart or an existing feature of Skunk ? If it's the Skunk, then I want to smack myself for not reading its docs and realizing you can access jag's RAM from commandline via jcp. Thanks a ton !!!

 

It is a feature of the SkunkBoard. See page 14 & 15 of the Skunk manual. The command "jcp <filename> [$<address>]" uploads the file to ram instead of flashing it.

[+rdemming]

I always thought ram, except SRAM had to be refreshed(I.e. need a power source or it all goes blank).

 

I guess things have changed. Will have to do some reading.

 

Both SRAM (static RAM) and DRAM (Dynamic RAM) needs a power source to keep its memory. But SRAM can store it without doing anything but applying power (it is based on a flipflop where the output is fed back to the input to keep its state). But DRAM needs to be refreshed because its charge leaks away (each bit is a little capacitor). Compare it with a water bucket that it leaking, to keep its "full" state you need to see if it is empty or partially filled. When it is partially filled, you need to add water to compensate the leaking. Old DRAM chips needed external refresh circuitry but modern chips have build-in refresh circuitry.

 

EPROM, EEPROM, FLASH ROMS do not need a power source to keep its value but writing those are slow compared to SRAM/DRAM. There are new kinds of RAM chips that are non-volatile and have fast writing speed like MRAM.

 

Robert

[VladR]

It is a feature of the SkunkBoard. See page 14 & 15 of the Skunk manual. The command "jcp <filename> [$<address>]" uploads the file to ram instead of flashing it.

Yep, I checked the manual yesterday night, and apparently there's a whooole page devoted to "Commands that load to RAM", that I -ehm- *facepalm* missed Thanks a ton! You've just saved my Skunk

 

 

 

 

I always thought ram, except SRAM had to be refreshed(I.e. need a power source or it all goes blank).

 

I guess things have changed. Will have to do some reading.

And why is that exactly a problem that the 16 MB RAM looses its content after you loose the power ? At that point you don't play jag anyway. Or did you mean something else ?

 

Just check the visual differences between games on PC, what technology you can achieve when you had 16 MB of RAM instead of just 2 MB. Granted, this 16 MB won't probably have word-resolution direct access (I'm guessing that it'll be only via memory-mapped registers and you will only be able to transfer blocks of memory (e.g. 64 KB at a time) - but still - you could store results of intermediate stages in the 3D pipeline, or precompute things that take a lot of memory (impossible to do on 2 MBs), but will improve framerate for example). You could have for example large levels that you would almost instantly stream off the 16 MB (preloaded from SD card at level-load-time). Possibilities are endless.

 

Also, if you have a lot of RAM, you do not have to waste precious development time by trying to squeeze everything. You just write the first version that works and is "good enough" and don't have to burn the time (often double or triple of initial effort) to fit the thing into small RAM you have. Debugging the first bruteforce version of any algorithm is also an order of magnitude faster, than when you mess with bits, or combine high-low word with 2 different things. And so on.

 

 

 

[JagChris]

Also, if you have a lot of RAM, you do not have to waste precious development time by trying to squeeze everything. You just write the first version that works and is "good enough" and don't have to burn the time (often double or triple of initial effort) to fit the thing into small RAM you have. Debugging the first bruteforce version of any algorithm is also an order of magnitude faster, than when you mess with bits, or combine high-low word with 2 different things. And so on.

 

Yeah you don't even have to be a good coder, you just need to wait for PC s to get faster so they can run crap code decently and have slop that takes an hour to install. Carmack was bitching about this the other day.

[npturton]

yup im interested as well

[Hastor]

Just found this thread. Definitely want one of these myself!

[SainT]

I've finally had some time to get stuck into the Jag cart again, hurrah!

 

I'm waiting on the (hopefully) final PCB's to come back for the NeoGeo Pocket FLASH cart, so while I've been waiting I have made some very good progress on laying out the PCB and finalising a load of minor details which I've been procrastinating over for ages.

 

Hopefully should be able to get the first prototype PCB's produced in the next couple of weeks.

[cjameslv]

Thanks for the update. It's awesome to see how fast your working on this!

[doctorclu]

Still interested in this.

[SainT]

Yet more PCB layout work going on at the moment, not much left to do now, I'm just routing the final left-over bits and double checking everything...

[TheNameOfTheGame]

Also still interested! Hope I'm on the list

[Hastor]

Nvm originally posted looking for the NGO thread but found it. I definitely want both!

 

Is there a list I'm supposed to be on?

Edited March 20, 2017 by Hastor