Upcoming Jaguar Game Drive Cartridge

[+CyranoJ]

One of the possibilities I'm excited about is if it'd be possible to hack Doom to play CD music. The aiff files are available for the 3DO soundtrack mentioned here: (interesting vid BTW). I can see the Jag homebrew scene becoming really interesting!

 

The Jaguar can't just start a track and have it play. It has to stream the audio via the i2c. It's retarded, but it is what it is.

[juansolo]

Ah, that's such a shame

[SainT]

I assume you'll be using a thru-hole micro-USB connector on the final board instead of the SMT mini-USB connector on the picture, right?

That's just the programmer board, hopefully I won't need to build another of those. Although I quite like that connector. Do you think there's not enough strain relief? The USB wouldn't be used much on this cart though, just for devs.

[Stage_1_Boss]

Like i said, the effort itself isnt lazy, the lack of imagination of making a brand new original game is. I think we all would appreciate seeing more original content (like orinon_'s work) on the jag as opposed to port after port from decades old systems. But if you dont want more original games and prefer ports from old systems, thats fine by me... Im not arguing that.

I prefer the existence of both. = ) I love being able to tinker around with some of the older ST games beefed up a bit for the Jaguar since I don't have an ST myself, and I enjoy trying out new games imagined for the Jaguar.

[Stage_1_Boss]

i feel original games are worth the price of admission

http://www.ebay.com/itm/Atari-Jaguar-Sea-Battle-Complete-Game-/122607018394?hash=item1c8bf2a19a:g:7qYAAOSwAANY5UVP

 

I had to, I'm sorry! = ) hehe, no hard feelings over anything though, and I don't wanna derail the SD cart thread, so let's just agree that new content for the Jaguar is always welcome! It's just whether or not you want to play or support it. = )

[Zerosquare]

That's just the programmer board, hopefully I won't need to build another of those. Although I quite like that connector. Do you think there's not enough strain relief? The USB wouldn't be used much on this cart though, just for devs.

Those SMT USB connectors are supposed to be held in place by external means ; the solder pads aren't strong enough by themselves. I've seen several homebrew projects (and even commercial products) with broken solder joints because of this - or even tracks ripped off the PCB when someone was unlucky enough to trip over the USB cable.

You could rely on the plastic case for mechanical support, but it would need to fit perfectly. It's easier to use thru-hole connectors, they're much more sturdy.

 

Regarding mini-USB vs micro-USB, it doesn't matter as much, but mini-USB is basically obsolete, and micro-USB connectors are supposed to be more robust.

[SainT]

Those SMT USB connectors are supposed to be held in place by external means ; the solder pads aren't strong enough by themselves. I've seen several homebrew projects (and even commercial products) with broken solder joints because of this - or even tracks ripped off the PCB when someone was unlucky enough to trip over the USB cable.

You could rely on the plastic case for mechanical support, but it would need to fit perfectly. It's easier to use thru-hole connectors, they're much more sturdy.

 

Regarding mini-USB vs micro-USB, it doesn't matter as much, but mini-USB is basically obsolete, and micro-USB connectors are supposed to be more robust.

 

Perfect, thanks for the info. As much as the USB isn't likely to be used much, I'll pay attention to getting a robust connector and most likely move to micro-b. I just got mini in this case as I have more mini-b cables kicking about than I do micro-b.

[Stage_1_Boss]

 

 

There IS no original content. It's all been done before.

*puts on thinking cap*

 

After I nail this programming thing which should only take a couple days, I'll get to making Jaguar's first horror-themed fishing game. It's like fishing, but instead you're going into people's nightmares through some weird futuristic contraption thing and fishing out horrifying creatures, which you then weigh on a terror scale. I'll flesh out the details later, along with learning to program, and everything else I've ever put off.

[juansolo]

You know that'll exist in Japan... Probably with some dating element added into the mix also.

[+CyranoJ]

 

Perfect, thanks for the info. As much as the USB isn't likely to be used much, I'll pay attention to getting a robust connector and most likely move to micro-b. I just got mini in this case as I have more mini-b cables kicking about than I do micro-b.

 

I'll be using the USB!

[Stage_1_Boss]

You know that'll exist in Japan... Probably with some dating element added into the mix also.

Scary things drive people closer together, it just clicks.

[+CyranoJ]

"Super Nightmare Horror Fishing Monster Deluxe Ultra FX2+"

[aminor00]

"Super Nightmare Horror Fishing Monster Deluxe Ultra FX2+"

Can we Jaguar mod a Sega Bass Fishing controller for this?

 

I think we're going to need a new forum thread for this one [emoji23]

 

Sent from my SM-G930F using Tapatalk

[grimm]

You know that'll exist in Japan... Probably with some dating element added into the mix also.

It would surprise me if it DIDNT.

[VladR]

The 16MB RAM on the cart is no faster than any other ROM access -- it will be able to be accessed as 32bit and most likely at the fastest setting (5 cycles) for external ROM. I'm not sure if I'm going to support DMA from the SD to the cart RAM as yet. It may well act like the CD system, so reading from the SD will go via I2S to one of the RISC's.

Am I interpreting the above correctly - meaning the transfer from SD to 16 MB is going to be free (in terms of performance impact), as it's the microcontroller doing all the heavy lifting between SD and 16 MB, both of which are outside of jag's bus. I'm disregarding the miniscule time it takes to fire the command, here.

 

As an engine developer, I'm personally more inclined towards having a 16 MB caching area, filled for free in parallel while game is running (at the cost of few instructions of firing a command), and incurring the run-time cost of data transfer only when really needed by a game (e.g. new screen /new area / ...).

 

Implementing SD -> 2 MB DMA transfer will surely cost you some time, no ? While in theory it's a nice feature, it only will enforce laziness in coders, so don't feel bad if it takes too long to implement and cut it.

 

I believe internal ram would be much faster though.

 

I would do it if it was a low-risk modification maybe future developers can have their programs detect the extra onboard internal Ram.

 

As for not being supported that might be a chicken or the egg thing.

I gave this some thought and for all intents and purposes of a game engine, those 16 MB are almost as good as internal RAM as you have read/write access to it (except you can't run jag code from there, but that is a minor inconvenience, as on jag you have to split and blit the code within 4 KB of GPU anyway).

 

Think of the microcontroller as another of jag's processors - like Blitter, that will transfer data from SD card to 16 MB. For free. In parallel, while your engine is running. You can't do that with CD-ROM.

 

So, it is, in fact, actually a HW / RAM upgrade of jag.

 

I just ran some numbers for a large-scale terrain (think : Morrowind / Oblivion - size), where each terrain chunk will have a unique texture:

- On SD card, the terrain can be virtually unlimited (only limited by capacity of SD card) - e.g. heightmap of 65536x65536 or even bigger, does not really matter at run-time at all due to the following:

- The 16 MB on SD will act as a cached buffer (from SD) - 24x24 terrain chunks, e.g. a heightmap 192x192

- the textures and mipmaps for this will consume 12 MB

- position of bitmaps (trees/shrubs/props) will take about 0.2 MB

- The 2 MB on jag's RAM will cache a displayable area of 9x9 chunks from those 16 MB (about 1.2 MB, rest is for code/screen buffer/etc.)

 

- Unlike CD-ROM access, filling of those 16 MB is free, performance-wise. No disc spinning, no 5-seconds of seeking and respinning. Just quietly, in parallel, fills the 16 MB with data, while the player is moving through the world, unaware of the heavy lifting going on in background.

 

 

As for the question - and how on earth you create 4+ GB of terrain data and textures ? With few clicks - http://www.world-machine.com/

I have a working C++ code that caches unlimited terrain from WorldMachine format on PC, so with few adjustments (and obvious resolution downscaling), it can be adjusted for jag.

 

This is very exciting in terms of what will now be possible on jag. It's like Falcon with GPU

[SainT]

Am I interpreting the above correctly - meaning the transfer from SD to 16 MB is going to be free (in terms of performance impact), as it's the microcontroller doing all the heavy lifting between SD and 16 MB, both of which are outside of jag's bus. I'm disregarding the miniscule time it takes to fire the command, here.

It depends if there is some kind of DMA from microcontroller to the RAM or not. At the moment in the current PCB, there isn't, and I'm running VERY low on spare pins on the CPLD. Depending on how difficult it will be to implement, and how well the microcontroller->i2s->dsp->RAM streaming works, I may or may not implement it. At worst, treat it like the CD, but much faster.

 

As for the question - and how on earth you create 4+ GB of terrain data and textures ? With few clicks - http://www.world-machine.com/

I have a working C++ code that caches unlimited terrain from WorldMachine format on PC, so with few adjustments (and obvious resolution downscaling), it can be adjusted for jag.

 

This is very exciting in terms of what will now be possible on jag. It's like Falcon with GPU

The Jag's texturing abilities are very poor, I don't see how more available cart memory will speed this up?

 

So, it is, in fact, actually a HW / RAM upgrade of jag.

 

Well, in its current state it's not much of a hardware upgrade in terms of performance. HOWEVER, there are BIG possibilities. There should be a fair bit of space left on the CPLD for other things, its quite possible that you could set a pointer in the cart RAM address space and stream data from this address via a memory address read but have the CPLD perform some processing on the data. For instance it's possible that it could do transform and lighting on a vertex stream just by setting a pointer and reading a stream of data from a DSP. Or decompress and ADPCM stream. Or whatever takes your fancy...

 

Again, this is out of scope for the initial cart design, but quite possible to add features like this later through firmware updates. If people can provide verilog code to do funky things on a data stream, I could happily integrate this into the hardware at a later date.

[leech]

Oh God, I apologize for the derailment.

 

I'm very excited to getting my hands on one of these SD Carts. I am going to need to make a better play space for my Jag, it's in a rather awkward set up now. I've bought several games I haven't even played yet (mostly due to time and other Atari related projects).

[VladR]

It depends if there is some kind of DMA from microcontroller to the RAM or not. At the moment in the current PCB, there isn't, and I'm running VERY low on spare pins on the CPLD. Depending on how difficult it will be to implement, and how well the microcontroller->i2s->dsp->RAM streaming works, I may or may not implement it. At worst, treat it like the CD, but much faster.

That's OK. I presume we [developers] will always have the following 2 abilities:

- do a transfer from cart's 16 MB to jag's 2 MB

- do a transfer from SD -> cart's 16 MB

 

 

The Jag's texturing abilities are very poor, I don't see how more available cart memory will speed this up?

Oh, it will Have you ever played a large-scale RPG that streams the world from CD ? It's a disaster - constantly spinning disc, 5+ seconds seeks (where game just freezes), ugly stuttering while it's trying to asynchronously stream data from CD.

With SD card - all these issues will be basically nonexistent. The only slowdown will be the transfer from 16 MB to jag's 2 MB. And as a coder, you can design and tweak the texture/chunk dimensions to be small and fast to transfer (just more often - or strike the balance wherever you want).

 

So, basically, your SD card will make it possible and useable. Of course, the speed of texturing will remain the same (e.g. slow - ~10-15 fps), but the visual texture variability (coming from WorldMachine), despite low texture resolution, will be tremendous.

 

BTW, it's not a complete pipe dream, as I already have a working terrain LOD code (just need to spend a day or two fixing texturing) running on jag (it's just that its chunks are arranged along a line, instead of a grid).

 

 

HOWEVER, there are BIG possibilities. There should be a fair bit of space left on the CPLD for other things, its quite possible that you could set a pointer in the cart RAM address space and stream data from this address via a memory address read but have the CPLD perform some processing on the data. For instance it's possible that it could do transform and lighting on a vertex stream just by setting a pointer and reading a stream of data from a DSP. Or decompress and ADPCM stream. Or whatever takes your fancy...

 

 

Again, this is out of scope for the initial cart design, but quite possible to add features like this later through firmware updates. If people can provide verilog code to do funky things on a data stream, I could happily integrate this into the hardware at a later date.

What kind of CPU (brand/frequency) are you using for CPLD ?

 

That new code (be it T&L, or whatever functionality we desire), is it possible to somehow "flash" it at home to the firmware, or is that the one-time-only write operation that happens at your home ? I'm not familiar with HW design very much, so apologies for the question.

 

Because if there was a way, that you could somehow "flash" that new code at home, and develop&debug new SW functionality of the microcontroller, that would be truly awesome, as that would allow for additional processing power (at a later date, of course).

[SainT]

On 8/4/2017 at 6:50 PM, VladR said:

That's OK. I presume we [developers] will always have the following 2 abilities:

- do a transfer from cart's 16 MB to jag's 2 MB

- do a transfer from SD -> cart's 16 MB

Be aware, as stated before, memory card->Cart is via the DSP at the moment. Memory card->Micro->I2S->DSP->Cart RAM.

 

On 8/4/2017 at 6:50 PM, VladR said:

What kind of CPU (brand/frequency) are you using for CPLD ?

 

That new code (be it T&L, or whatever functionality we desire), is it possible to somehow "flash" it at home to the firmware, or is that the one-time-only write operation that happens at your home ? I'm not familiar with HW design very much, so apologies for the question.

 

Because if there was a way, that you could somehow "flash" that new code at home, and develop&debug new SW functionality of the microcontroller, that would be truly awesome, as that would allow for additional processing power (at a later date, of course).

I'm using a MachXO2 1200HC currently.

 

A CPLD is basically a reprogrammable custom logic chip, not a CPU of any kind. The logic gates (macrocells) can be configured to perform any operation. It is reprogrammable from the system (Jaguar), but I wont be releasing any of the verilog (hardware description code), so updates to the CPLD will just come from me. Likewise any updates to the code of the Microcontroller will come from me. The additional power of the Microcontroller is pretty small compared to the possibilities of the CPLD, but it is possible to add additional functionality if its useful.

Edited October 25, 2019 by SainT

[VladR]

Be aware, as stated before, SD->Cart is via the DSP at the moment. SD->Micro->I2S->DSP->Cart RAM.

Ouch. There goes my theory of parallel free data transfer from SD to cart

Now I finally got what you mentioned a post above about the DMA and running out of pins. I'm not sure if there is something else you can sacrifice, but having the ability to do a free transfer without hogging DSP would be huge, If realistically possible.

 

 

I'm using a MachXO2 1200HC currently.

 

A CPLD is basically a reprogrammable custom logic chip, not a CPU of any kind. The logic gates (macrocells) can be configured to perform any operation. It is reprogrammable from the system (Jaguar), but I wont be releasing any of the verilog (hardware description code), so updates to the CPLD will just come from me. Likewise any updates to the code of the Microcontroller will come from me. The additional power of the Microcontroller is pretty small compared to the possibilities of the CPLD, but it is possible to add additional functionality if its useful.

Thanks. I've googled some docs on it, and am looking into CPLD now. Every now and then it does not hurt to learn something new from an unrelated field...

[+Sauron]

Just cleaned up this thread. Please do not derail another thread, guys.

[UHATEIT]

Just cleaned up this thread. Please do not derail another thread, guys.

Thank you! Woke up this morning to 24 emails for this thread

[SainT]

The programmer side of things is definitely working ok -- tested it properly now. It's only a 16bit reader / writer, though, so I can just read every other word of 32bit carts! Not important though, as the flash on the cart is just a 16bit flash for booting only, so it serves the purpose of writing it.

 

Have built up a bare minimum cart for just the boot flash to function but get one of the level shifters overheating when trying to write to the cart. Tracked it down to the RW line being shorted to VCC. Eurgh. Now to remove each level shifter in turn until I find out which of the vias under the chips is somehow shorted to VCC as I'm buggered if I can find any solder bridges or any issues with visible vias. Gah.

 

Ah the fun of prototype boards and crappy hand soldering...

Edited October 25, 2019 by SainT

[Glen's Retro Show]

That's great news saint!

[Glen's Retro Show]

It's Great news that such progress is being made saint!