Jump to content
IGNORED

"extra" RAM


Otto1980

Recommended Posts

Hi all,

 

just had a nice abstract idea that could maybe help the jag having a little more ram for its CD games.

(while reading the CD <> Module thread)

 

would it be technical possible to make an "Memorytrack like" Module that contains for example 4 megs of RAM that also contains eeprom to save CD stats?

This way you could use 2megs internal PLUS the 4 megs (in this example) from the module

that would be a SupermemorytrackPlusExtensionpack :-o

 

i dont know the read write speed of the moduleport comparet to the internal 2meg RAM

of course i know this could only work if RWspeed is siutable and the jag could do a workaround to write into module adressspace

 

would that make sense??

Think about it :grin:

 

greets to all

 

Link to comment
Share on other sites

For all infos about speed, SCPCD is surely the people who know that.

 

Thinking to make a module for JagCD isn't a good idea i think. Because JagCD aren't very cheap and reliable. In some years a running JagCD will be awesome !!

 

The Jaguar is a rock, and i think in 10 years lot of them will be always running, loosing time for an extra module to take dust on a desk isn't a good idea :) because JagCD will be only for telling : i've got it !!

 

It's a personnal opinion :)

Link to comment
Share on other sites

yea.. but sense or senseless is another topic :-D

 

just curious if it would be technical possible due the bus limitations, module/cartridge interface, read write speed, or even access to a possible RAM on a Module

 

reading and writing the eeprom of a memory track is also possible... so maybe also to ram...

that was the idea

 

:thumbsup: :thumbsup: :thumbsup: :thumbsup: :thumbsup:

Link to comment
Share on other sites

Here in this thread they found out it was possible to add 8mb of ram to the Jaguar via cartridge.

 

http://atariage.com/forums/topic/43179-could-the-atari-jaguar-ever-handle-the-quake-engine/page-3?do=findComment&comment=527003

 

I can't remember if its 8mb total or 8 more megabytes on top of the Jaguars existing two. Either way the on cart ram would be slower than the normal ram but still useful.

  • Like 2
Link to comment
Share on other sites

You have six megs of space allocated to the cart slot. If you want more, you have to bank select it. That's what the V2/3 Skunkboards do - you have one bank of 6MB of flash, or two banks of 4MB of flash. Most of the time, the Skunkboard operates in the two bank mode, with one bank or the other selected and containing a game. A homebrew game could handle the bank selecting itself, allowing it a full 8MB of storage for the game.

Link to comment
Share on other sites

Ideally, you want a cart with like 16 to 32 MB of ram (bank selected), and something like an SD card port. Have a small amount of flash to load a menu off the SD card, which would then allow loading homebrew and the like off the SD card. An SD interface would be more reliable than a CD - with enough hardware you could even stream digital audio off the SD card.

Link to comment
Share on other sites

Hi,

 

I still don't know why there was never a cartridge build for the Jaguar that indeed did something like the memory track but that has a special banking technique with 256MB or even much more.

Memory/ laptop memory is very cheap to get the memory modules are nice, just load and decompress data in the cart for games.

 

Even the 8-bit Atari has 1MB or even 4/16Mb upgrades. With these upgrades there is much more possible. The technique is memory in banks $4000 - $7FFF switches.

Some kind of technique could be build for the Jaguar aswell...

Link to comment
Share on other sites

Because:

- it needs a memory controller which is neither simple nor cheap

- the performance would be severely limited by the cartridge bus

You could do the DRAM refresh using the GPU. If you believe some people around here, homebrewers don't use it, so you might as well do something useful with it.

  • Like 1
Link to comment
Share on other sites

As long as we're all huffing glue I may as well contribute my sky high idea.

 

What about a cart with a TF slot that loads a 6mb binary into onboard RAM mapped to where the cart ROM usually is. No need for a separate ROM programmer. Still would fit nicely in a salvaged cart. If the Jag allows writes to cart ROM I could see plenty of evil self modifying code being used!

Link to comment
Share on other sites

 

Why "evil" self modifying code ?

 

I have yet used self modifying code, even generated one and it's not 'evil code', just a great tool in a coder boxtools :)

 

 

 

Nah. I was just talking out of my rear speaker. I love self modifying code. I also love GOTOs. It's up to the programmer to make clear, functional code: not the language.

Link to comment
Share on other sites

I don't see why it's very more expensive to build simple upgrades for the Jaguar compared to other Atari systems like ST and 8-bit series, even there lot's of very advanced hardware with CLPD/FPGA and other things with SD/RAM and more is developed for prices under the $100.

 

But it's mostly time consuming to develop things, I know. The jag community isn't using any new types of hardware so everything is new, but when you want to try something new someone should start, who knows what it will bring.

To build a cartridge is the only way I see the Jaguar HW can be expanded because then everyone can do it, also people without HW skills... and you still can play your existing games...

 

On the 8-bit Atari I lost track of how many upgrades there are...

 

to bad I would love to see insane hacks like adding a cassete recorder to the Jaguar to save/load games from tape just for fun :-)

Link to comment
Share on other sites

cool feedback

 

basicly i posted this topic under the jaguar "programming" section because i really wanted to discuss the technical theory of this idea

senseless or not ;-)

 

the question is:

could it be fast enough and helpfull to solve the limited RAM problem of the Jag?

 

greets to all

Link to comment
Share on other sites

  • 3 years later...

One big consideration for RAM expansion on the Jaguar wouldn't be for sheer added storage capacity considerations, but for speed improvements. Even a relatively small chunk of 75 ns SRAM or PSRAM (like 64 or 128 kB) 16-bits wide on a RAM cart for the CD (or hypothetically slapped as an add-on for a ROM based game) could dramatically speed up texture mapping and potentially make the 68000 a bit more useful as well.

 

The blitter can only render one pixel at a time in DRAM, and does so slowly, using 5 cycles per read and write (10 cycles per pixel). You can speed this up by loading small textures into GPU RAM, but that seriously hampers the GPU itself (contention for the GPU scratchpad will kill GPU performance), but having textures stored outside of the 2MB 64-bit wide DRAM bank would allow writes to DRAM in page-mode (2-cycles) and fast 2-cycle memory accesses to SRAM or PSRAM for 4 cycles per textel rendered (possibly 2-cycles per textel with SRAM; I forget if the blitter can interleave read and write cycles in separate memory banks ... it'd be 4-cycles with PSRAM in any case, due to the slower random read/write cycle times than SRAM). Worst-case would be on page-breaks in DRAM, where you'd end up with 5 cycles per textel, but that's still 2x as fast as normal Jaguar Texture mapping. I also forget if the cart bus has a locked minimum cycle time, but that might also be 4-cycles. (these are all 26.6 MHz cycles, mind you)

 

Use of the 68k would be aided when working in 16-bit P/SRAM by not contending for DRAM and allowing interleaved DRAM accesses within 68k cycles ST/Amiga style, sort of. (the difference being separate memory banks and use of page-mode DRAM access) You could nest up to 3 page-mode DRAM accesses into a single 68000 bus cycle and have it working in the little P/SRAM bank without waits. The DSP also has a 16-bit bus and somewhat slow/broken due to bugs, so it's a bus hog in main DRAM too, but could be a fair bit more useful doing some parallel processing in added P/SRAM. (in typical games it's best just working from ROM for the same reason, loading sound data and such)

 

You also don't need anything wider than 16-bits for texture mapping (straight, uncompressed 16bpp textures) and likewise nothing wider than that for helping with the 68k, or DSP for that matter (also only 16-bit access)

 

Throwing a RAM cart like that bundled with the Jaguar CD would've made it a much more substantial upgrade back in '95, but it'd still be neat to see for homebrew stuff today. (more likely to see SRAM + ROM arrangements, though) They could've also built it into the CD unit, but given all the delays it saw and the added (if simple) logic required to disable the RAM when a cart was inserted would've made lumping it into a cartridge make much more sense.

 

They could've put SRAM or PSRAM on normal ROM game carts back in the day too, but it didn't make sense with the sort of sales volumes they were dealing with, and the most demanding games would've been better on CD anyway. (stuff like Quake and Tomb Raider would've seriously been aided by something like that and would've been hardpressed to fit on carts anyway, especially at sane price points ... added RAM aside)

 

 

It's also worth noting that the Jaguar itself supported 2 DRAM banks, but only one was populated. (so two pages could be kept open at once and some interleaved accesses without nearly as much of a hit to the bus) This isn't relevant for a cart-based expansion and they didn't include a dedicated RAM expansion slot, either, but it's an interesting missed opportunity to consider. (putting the DRAM control and address pins on an expansion port ... even limited to 16-bits wide would've been significant and much more cost effective than an SRAM expansion) Though given the added pin count and traces needed for a dedicated expansion port, it would've made far more sense to just add the DRAM control lines to the cart slot and allowed for up to 32-bit DRAM to be added on that end mapped to the empty 4MB DRAM bank address space. (they'd planned the Jag CD before the base system was test-marketed, and the Jag cart slot has a pretty hefty pin-count, so that would've made a great deal of sense)

*The Jaguar's memory map includes 2 banks of 4MB each for DRAM and a single 6MB bank for cartridges (ROM or P/SRAM) with the remainder of address space dedicated to internal registers, I/O, and such.

 

They also could've used a different base DRAM configuration and populated both banks, but that either would've added to cost (like 2.5 MB with just a 5th 512kB 16-bit DRAM chip added) or required a mix of different DRAM chips to be used with less total RAM. (say 4x 128kB chips for a 64-bit bank and 2 515kB 16-bit chips for a 1MB 32-bit bank ... less RAM and less cost-effective smaller DRAMs for the 64-bit chunk, more board space taken up, but potentially slightly lower initial price point and substantially better use of texture mapping as well as more flexible use of the 68k and DSP ... you could also drop down to 1 MB total system RAM with just a single 512kB chip 16-bits wide, which would be fine for a lot of early/mid 90s cart games, arcade games and SOME PC/Amiga ports, but you'd definitely want RAM expansion on a CD based console in that case; the lower initial price point might have been worthwhile)

 

Oh, and Doom might have still been easier to code on a 1 MB (.5 MB 64-bit .5 MB 16-bit) Jaguar in spite of the lower RAM quantity due to better use of 68k and DSP, as well as ability to keep textures in the 16-bit bank for faster access. (and given how much profanity Carmack left in his comments of Jag Doom's source code, you can bet the bugs /and/ broken DSP bus controller were high on his lists of complaints) That's also still way more RAM than the 32x port had to work with slightly later (adapted from Jag Doom's source code no less) and that port also had to make do with less ROM (3 vs 4 MB). Jag Doom probably would've had some nice music in such a situation as well. (though 32x Doom also has a 7.67 MHz 68000 with its own private bus and 64 kB of PSRAM to work in totally in parallel, though I think 32x Doom just slaves the 68k to I/O and sound and leaves the brunt of things to the 32x side)

 

In case you're interested:

https://console5.com/wiki/Genesis_2

https://console5.com/wiki/SRAM_512Kb:_32K_x_16-bit

 

Sega was using 64kB 16-bit wide PSRAM chips by Sanyo in later model Mega Drive 2s. (and other varities of 32kx16-bit PSRAMs on all but the really early revisions: the VA0 model 2 had a pair of 32kx8-bit PSRAMs instead)

The Sanyo LC331632M was offered in 70 ns speeds as well. (the MD mostly used 120 ns)

 

And also a neat resource for DRAM pricing up through the 1990s:

https://phe.rockefeller.edu/LogletLab/DRAM/dram.htm

  • Like 2
Link to comment
Share on other sites

Still be sharing the same physical data bus internally, so you are still going to have CPUs fighting for access to the memory, only one can control the bus at any one time.

 

If you were to add additional RAM 16bit wide for the purpose of CD enhancement, you would have a few extra things to do. Games now need to be more complicated, as they have to support with and without the extra RAM, or simply require anyone using them has the cart. Developing for those games requires you have some way of connecting the extra ram cart whilst you are developing, (BJL, or some form of riser/splitter card).

Plus, anything that wants to talk to the CD-Unit and the memory is going to need to keep toggling the cart bus configuration in the memcon registers to switch between 8bit and 16bit mode. That *might* get messy if you have multiple CPUs vying for bus access, need to be very careful one of them doesn't leave the configuration in an unexpected state for when the next one comes along (68K loses bus control as it is lowest priority whilst a blit happens).

 

It's extra complexity for no real benefit.

  • Like 3
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...