"Practical" Jaguar Hardware Upgrades

[phoboz]

5 minutes ago, CyranoJ said:

The backdrop in Downfall+ is being streamed from ROM.

I guess you do that by copying only the visible part of it to a sprite in RAM. That sounds like a good job for the blitter. Is it done the same way in Gravitic Mines?

Becuase I imagine you cannot fit the whole level at once in RAM?

Edited October 29, 2021 by phoboz

[phoboz]

15 hours ago, Zerosquare said:

I'm not sure the issue is technical in nature. Orion_ stopped developing on the Jaguar several years ago, and IIRC it predates the release of Zia and the godesses of magic.

I cannot imagine that anyone would like to stop developing games for the Jaguar?

 

There is just so much I would like to add to it's library.

Edited October 29, 2021 by phoboz

[Clint Thompson]

One of a million quick'n'dirty late night tests last year to see what I could get away with in regards to 16-bit graphics from ROM while playing music. Non-interactive, though I did have it to where you could scale it and cycle forward/backward faster or slower to see if any nasty side effects presented themselves. Also not the limit in graphic size either, just one of many tried. Stuff I generally wouldn't release publicly but since we're on the topic... or off topic at this point but still relevant to discussion.

 

Skunk only (it's not setup to run on GD) - stay away if you're allergic to inadequately clothed women cityx.rom

[Cyprian]

@Clint Thompson nice demo.

 

I wonder what happen to the RAM bus when the Object Processor gets graphic data from the ROM.

Is it locked or free for the CPU/GPU/blitter

[Zerosquare]

RAM and ROM don't have separate buses -- there's only one bus for everything.

[Atariman]

35 minutes ago, Zerosquare said:

RAM and ROM don't have separate buses -- there's only one bus for everything.

Speaking of RAM... Although no current games could use it, do you think that a RAM expansion design would be welcomed to the Jaguar?  The CoJag schematics have made me think about what it would take to interface "modern" SDRAM with the DRAM interface of TOM and I'm thinking about what signal manipulation it would take to bridge that gap.  SRAM looks like it's still too expensive (which, too, would require more hardware to make it work, anyway) and DRAM seems like it's just getting harder and harder to acquire in any size.  SDRAM is plentiful, cheap, and fast at least.  If I can figure out a strategy for tackling the signal translation, I would be willing to develop something on an FPGA and lay out a PCB for the upgrade that would attempt to reduce the amount of pain introduced from installation.

 

On a similar note, maybe my calculations are incorrect or perhaps I haven't found the right errata information yet, but shouldn't TOM be able to address 16MB of RAM?  I've seen 8MB thrown around and that IS that maximum that was accounted for on the CoJag, but I was wondering how much of that is a limitation of TOM and how much of it came from the fact that they used the same RAM in the CoJag as they did the Jaguar which looks like it required some finagling to get it to work.  The datasheet says RAM can be 64-bits wide (which, when all of the current RAM ICs are strung together, it currently has) and up to 2M columns, calculating out to my 16MB value.  Although the last address pin for RAM isn't connected to anything, it does appear to go to a test point which would be easier to solder a wire to than a pin on the chunky QFP that is TOM.

 

Not sure how excited software folks would get about that, but it seems like that would be awfully nice to be able to have everything in ROM transferred to RAM, decompression be damned.  At this point I guess the biggest benefit would be for future homebrew CD titles?  Anyway, just one of the things I've been chewing on for the last few days.

[Zerosquare]

You wouldn't get access to the whole 16 MB of RAM: the address space itself is only 16 MB (24-bit wide address bus), and the upper 2 MB are reserved for the internal ROM, hardware registers, GPU/DSP local memory, etc. I don't know what happens if you actually attempt this, but I assume only the lower 8 MB of RAM would be accessible.

 

If you want to extend memory, the easiest way I could think of would be piggybacking off the original DRAM chips, either by soldering directly on them, or by using upside-down sockets if you want to make things easier and cleaner. Finding old stock of those DRAM chips is probably significantly cheaper and easier than using a FPGA and modern RAM.

 

Of course, as it's been discussed above, there's a chicken-and-egg problem: existing games won't benefit from extra RAM, and new homebrews won't use it until there's a significant proportion of people with modified consoles... but people won't pay to modify their console if there are no games that use it. Unless there's a real homebrew "killer game" that absolutely requires more memory, I don't see how it could become popular.

 

On the other hand, there's nothing wrong with making new things, even if you're the only one in the world that can use them

[+cubanismo]

1 hour ago, Zerosquare said:

I assume only the lower 8 MB of RAM would be accessible.

Yeah, if you had 16MiB of RAM, you wouldn't be able to access the cartridge or CD unit to load stuff iInto that RAM. So... I think what @Zerosquare is trying to say is you should work out some RAM bank switching scheme ?. I'd say go with one that leaves the bottom 2MiB always pointed at the original lower 2MiB, but allow software to toggle the upper 6MB between two banks. Somehow get them both to refresh. If you can't get it done with 14MiB instead of 16MiB of RAM, your code probably wasn't going to run well on the Jag anyway.

[Atariman]

1 hour ago, cubanismo said:

Yeah, if you had 16MiB of RAM, you wouldn't be able to access the cartridge or CD unit to load stuff iInto that RAM. So... I think what @Zerosquare is trying to say is you should work out some RAM bank switching scheme ?. I'd say go with one that leaves the bottom 2MiB always pointed at the original lower 2MiB, but allow software to toggle the upper 6MB between two banks. Somehow get them both to refresh. If you can't get it done with 14MiB instead of 16MiB of RAM, your code probably wasn't going to run well on the Jag anyway.

? Yes, RAM bank switching sounds just fabulous... but I do see where I went wrong in my interpretation of the memory maps.  Yes, I see that 8MB is the maximum based on the memory map - I suspect that if I were to devise a way make that happen it might make a few people happy, though.  Let me see what I can cook up, though!

[Cyprian]

7 hours ago, Zerosquare said:

RAM and ROM don't have separate buses -- there's only one bus for everything.

it could mean that the RAM is locked longer (due to 5 or more cycles access to the ROM) when the OP is using the ROM than when it gets all graphics data from the RAM.

Edited October 29, 2021 by Cyprian

[+CyranoJ]

13 hours ago, phoboz said:

I guess you do that by copying only the visible part of it to a sprite in RAM. That sounds like a good job for the blitter. Is it done the same way in Gravitic Mines?

Becuase I imagine you cannot fit the whole level at once in RAM?

No, in downfall the background object data stays in ROM.

 

and also, no, Gravitic Mines is a whole other kettle of fish which does fit in RAM (just!) (barely!) (no you can't add another frame of animation, Ander!) (oh, go on then, found some more RAM for you) (stop it!)

 

 

[philipj]

On 10/29/2021 at 12:38 PM, Atariman said:

Not sure how excited software folks would get about that, but it seems like that would be awfully nice to be able to have everything in ROM transferred to RAM, decompression be damned.  At this point I guess the biggest benefit would be for future homebrew CD titles?  Anyway, just one of the things I've been chewing on for the last few days.

Compression seemed to have the way of the world during the Jaguar's heyday and probably for good reason... Back in my music making days compression was how I packed a lot of stuff to fit on diskettes that I should've never been able to save otherwise. It would be nice, however, to add ram similar to how the N64 was able to do so using ram modules... You still have the "cartridge port" and the back "extension port" on the Atari Jaguar where the DSP have access to both ports... Not very sure if the GPU would have access to the back port in the same way the DSP does; the only thing GPU seem to have access to back there is the video/display chip that's so famously mentioned in the old "Atari Docs". As far as schematics goes, it's still a bit foreign to me; I haven't looked at the Jag schematics in ages; all in all it would be very neat to put a ram module through the back "extension port" for (at least) the DSP to have access; Not sure if it would be 64-bit access, but at least that's one way to add extra memory.

[Zerosquare]

3 hours ago, philipj said:

Not sure if it would be 64-bit access

Hint: look at the what signals are on it. Or just count the number of pins.

[phoenixdownita]

On 11/11/2021 at 8:12 PM, philipj said:

Compression seemed to have the way of the world during the Jaguar's heyday and probably for good reason... Back in my music making days compression was how I packed a lot of stuff to fit on diskettes that I should've never been able to save otherwise. It would be nice, however, to add ram similar to how the N64 was able to do so using ram modules... You still have the "cartridge port" and the back "extension port" on the Atari Jaguar where the DSP have access to both ports... Not very sure if the GPU would have access to the back port in the same way the DSP does; the only thing GPU seem to have access to back there is the video/display chip that's so famously mentioned in the old "Atari Docs". As far as schematics goes, it's still a bit foreign to me; I haven't looked at the Jag schematics in ages; all in all it would be very neat to put a ram module through the back "extension port" for (at least) the DSP to have access; Not sure if it would be 64-bit access, but at least that's one way to add extra memory.

 

 

 

most definitely not 64bits ... "as-if"

[philipj]

Never the less... No need in throwing a good idea to waste... 12-bits is better than nothing at all, or you can just continue to use the 2MB of RAM that's already in there... Beggar's can't be choosers unless there's another way; probably the best way is to add memory is on a cartridge, which is the most obvious choice... Just putting some options out there... That is all.

 

Oh one more thing, can the "Jaguar Gamedrive" flash/write to SD such as for saving for high score...? If so, the flash drive can serve as a type of virtual memory of some type especially if it's really fast or make a custom cartridge that uses fast flash memory to serve as a fast ram system.

[phoenixdownita]

23 minutes ago, philipj said:

Never the less... No need in throwing a good idea to waste... 12-bits is better than nothing at all, or you can just continue to use the 2MB of RAM that's already in there... Beggar's can't be choosers unless there's another way; probably the best way is to add memory is on a cartridge, which is the most obvious choice... Just putting some options out there... That is all.

 

Oh one more thing, can the "Jaguar Gamedrive" flash/write to SD such as for saving for high score...? If so, the flash drive can serve as a type of virtual memory of some type especially if it's really fast or make a custom cartridge that uses fast flash memory to serve as a fast ram system.

Where do you see 12 bits?

 

Here:

 

 

[philipj]

 

53 minutes ago, phoenixdownita said:

Where do you see 12 bits?

Well I assumed that 12-pins meant 12-bits, but it look more like 8-bits rather than 12-bits with "2 Transmit Data Pins" and "2 Receive Data Pins" on each side of the external connector for the DSP. Also there's the two "Reserved Pins (Pin 4 and 5)", but doesn't look like it's being used for anything from the looks of it... 

Edited November 16, 2021 by philipj

[+CyranoJ]

Great idea.

 

Maybe it can use XMODEM to get maximum speed......

[philipj]

17 hours ago, CyranoJ said:

Great idea.

 

Maybe it can use XMODEM to get maximum speed......

Well... Actually, all jokes aside, I have a few ideas experimenting with the Jag and the Sega Genesis concerning interfacing the ST to both machines using an altered version of the old BJL program. The model 1 version of the Genesis has a serial port in the back, but requires an 8bit chip to communicate to the Geny, which the ST just so happen to have a (BJL Behind Jaggy Lines / BGL Behind Geny Lines)... At least that's on my to do list.

[+CyranoJ]

1 minute ago, philipj said:

Well... Actually, all jokes aside, I have a few ideas experimenting with the Jag and the Sega Genesis concerning interfacing the ST to both machines using an altered version of the old BJL program. The model 1 version of the Genesis has a serial port in the back, but requires an 8bit chip to communicate to the Geny, which the ST just so happen to have a (BJL Behind Jaggy Lines / BGL Behind Geny Lines)... At least that's on my to do list.

How long is this todo list of yours?  I'm imagining a toilet roll... in more ways than one.

[philipj]

35 minutes ago, CyranoJ said:

How long is this todo list of yours?  I'm imagining a toilet roll... in more ways than one.

 

At one time it was... Been rethinking and consolidating many of them; some of them I probably won't even use... It all depends the game project because that's what it's all for at the end... But all of those great ideas won't do any good, if I can't make a good game thus my plans on taking the more simpler approach with QB64 hasn't changed so I can just make games, but I have a few good ideas that I'm not ready to throw away just yet, but for now I'm a bit tight lipped about that doesn't make for a good game; the game should justify the idea and not the other way around. However if I ever do get to work on them, I'll make the experiments small and simple, but for now, I just want to make great games and release them; that's it.

[Atariman]

On 11/15/2021 at 10:25 PM, phoenixdownita said:

Where do you see 12 bits?

I had meant to respond to the concept of adding RAM to the DSP connector earlier.  I was scratching my head, especially when I actually looked on the schematic and was met with essentially what I expected... just... DSP stuff.  Might be nice for interfacing with a MIDI device, but... Erm... Or was I missing a joke somewhere?

Edited November 19, 2021 by Atariman
Crap sentence structure

[phoenixdownita]

2 hours ago, Atariman said:

I had meant to respond to the concept of adding RAM to the DSP connector earlier.  I was scratching my head, especially when I actually looked on the schematic and was met with essentially what I expected... just... DSP stuff.  Might be nice for interfacing with a MIDI device, but... Erm... Or was I missing a joke somewhere?

No joke, I was just asking how from that schematic he concluded there were 12bits, it literally shows 2 separate serial lines, a sync one and an async one and that's it. It has 12 connections pad on top and 12 on the bottom, so 24 totals across the DSP and AV edge connector.

Not sure why on his next answer he stated that it looks more like an 8bits layout.

[Atariman]

Minor update:  I'm working on a few different concepts, but as for a memory upgrade, I started drawing up a schematic for an 8MB board.

It's incomplete, but I've got it down to about 11 ICs and a 3.3v regulator.  General strategy is to demux the address coming from Tom and use SRAM.  It's a little pricey, but considering the premium and/or difficulty in getting drop-in replacements, I thought it was worth a shot.  The other ICs are bi-directional level shifters since 5V parts, at least in my search, have been a little rare.  My goal is to create something with parts that don't appear to be nearing their end-of-life and seem to be available from multiple suppliers.  Once I'm working on layout, I'm going to try to line up the board/pins with the existing pads that they'll need to be soldered to since my thought would be that it would require removal of the existing RAM and then soldering pins to some of the pads.  It would also require a jumper or two to some test points on the board.

 

I still need to go through and double-check how I think it would work, but what I have so far seems feasible and wouldn't be a total nightmare to solder since it would require minimal jumper wires.  I think it ought to work with any Fast Page Mode accesses as well since that would just be updating part of the demuxed address and there shouldn't be any performance issues jumping from one address to another. 

 

If anybody is interested in the parts that I'm thinking about using, I'm willing to share that information. 

 

Once I've put together a couple prototypes and modified the boot rom, I should be able to test it out and see if it works.  First test will just be trying out an existing game to make sure that it still works, then I can move on and try my hand at creating something that would access the additional memory.  Next steps after that are unknown.  I've been pursuing some other leads on CoJag information that could lead to other concepts, but wanted to share this for now.  Thoughts?  Comments?  I know this isn't as easy as piggybacking parts and running jumper wires, but I'm hoping that this could be beneficial for more than just me. 

Edited November 26, 2021 by Atariman
Clarifying

[JagChris]

How about a cart with expanded ram? Either for its own use or in conjunction with the CD?