RAM 320XL

[abbotkinneydude]

Is there any ETA for RAM 320XE ? Thanks.

[ctirad]

Is there any ETA for RAM 320XE ? Thanks.

 

A half year ago ;(

It is truly overmature infant now. I spent hundreds of hours by routing the PCB and many times started again with a different placement of the key components. When I had almost ready the final layout, someone asked me if I can add an RTC via a parellel Epson chip backupped by an battery. OK, great idea. So I did. And when there is a battery why don't to backup the SRAM as well and don't use the 192kB of the unused space for the cartridge/SDX emulation? Ok, another great idea. So I started again.. After another hours I ended up with a totally bloated crap which doesn't satisfy my perfectionalistic mind at all. In addition I found the parallel RTC chips are obsolete and very expensive. So I decided to give up all the RTC/CART/SDX stuff and return to the original concept. Then I needed some break from the PCB routing, really

 

BTW, I still did not found a suitable enclosure. I tried farnell, tme and some local suppliers but no one have anything similar to ~10cm wide cartridge box. Any ideas?

[Rybags]

IMO just allowing the spare RAM to be used as a banked "cart" @ A000-BFFF would be sufficient. Maybe have a jumper which enables/disables the feature, use some non-defined address in the D5 page to do bank-select.

 

If enough of these things got out there, it'd probably give incentive for RAMDisk extensions, or even a DOS version that can run entirely from it.

[pixelmischief]

Scope creep. It can kill any project. Learn to love version cutoffs. It's the only way to actually finish. But then, I can see you have already learned this the hard way.

[Frankie]

RAM 320XL available again!

 

Aer these still available? I sent a PM but no response. I'm looking for the 320XL full version.

 

Frank

Edited February 19, 2011 by Frankie

[Frankie]

Mine is on the way!

 

RAM 320XL available again!

 

Aer these still available? I sent a PM but no response. I'm looking for the 320XL full version.

 

Frank

[UNIXcoffee928]

Has anyone ever made a Battery-Backed RAM Expansion? What are the complexities involved, and do you think that it's a do-able modification to your current project?

 

I'm asking this, because Flashjazzcat, in the GUI thread, is trying to determine the best place for the code to reside. I wasn't sure if anyone had ever made a battery-backed, banked memory module for the Atari, but you seem like the person to ask.

 

Aside from that, what is the Maximum amount of memory that has been/can be added via your banking method? Thanks.

[+bob1200xl]

Like this, 512K?

 

 

Bob

 

 

 

Has anyone ever made a Battery-Backed RAM Expansion? What are the complexities involved, and do you think that it's a do-able modification to your current project?

 

I'm asking this, because Flashjazzcat, in the GUI thread, is trying to determine the best place for the code to reside. I wasn't sure if anyone had ever made a battery-backed, banked memory module for the Atari, but you seem like the person to ask.

 

Aside from that, what is the Maximum amount of memory that has been/can be added via your banking method? Thanks.

[HiassofT]

Has anyone ever made a Battery-Backed RAM Expansion?

Schematics are on my website http://www.horus.com/~hias/atari/#sram512k

 

You just have to hook a DS1210 (plus battery, of course :-) into the CS line of the SRAM and you are done (this part is marked optional in my schematics).

 

so long,

 

Hias

[+bf2k+]

Has anyone ever made a Battery-Backed RAM Expansion? What are the complexities involved, and do you think that it's a do-able modification to your current project?

 

I'm asking this, because Flashjazzcat, in the GUI thread, is trying to determine the best place for the code to reside. I wasn't sure if anyone had ever made a battery-backed, banked memory module for the Atari, but you seem like the person to ask.

 

Aside from that, what is the Maximum amount of memory that has been/can be added via your banking method? Thanks.

 

Mega-HZ makes a nice one too... I have one here... it is switchable between 256k & 512k in a couple of different combinations.

[ctirad]

What are the complexities involved, and do you think that it's a do-able modification to your current project?

 

The RAM320XL has the power connector, thus you can easily plug some battery there.

The RAM 320XE is powered from the cart port and I don't plan to add such option (any more).

 

I'm asking this, because Flashjazzcat, in the GUI thread, is trying to determine the best place for the code to reside.

 

Why to not just boot it into any standard expansion RAM from a drive? The devices like SDrive + high speed SIO or Qmeg are really fast. And for the people, who still prefer old slow and small floppies and want instant start, there can be some kind of a flash cartridge.

 

Aside from that, what is the Maximum amount of memory that has been/can be added via your banking method? Thanks.

 

For the unmodified XL and XE and standard banking, the limit is 320kB of total RAM (64 + 256).

Optionally the RAM 320XE and RAM 320XL PLUS will allow 576kB with a simple hardware modification (of the atari).

[UNIXcoffee928]

What are the complexities involved, and do you think that it's a do-able modification to your current project?

 

The RAM320XL has the power connector, thus you can easily plug some battery there.

The RAM 320XE is powered from the cart port and I don't plan to add such option (any more).

 

I'm asking this, because Flashjazzcat, in the GUI thread, is trying to determine the best place for the code to reside.

 

Why to not just boot it into any standard expansion RAM from a drive? The devices like SDrive + high speed SIO or Qmeg are really fast. And for the people, who still prefer old slow and small floppies and want instant start, there can be some kind of a flash cartridge.

 

Aside from that, what is the Maximum amount of memory that has been/can be added via your banking method? Thanks.

 

For the unmodified XL and XE and standard banking, the limit is 320kB of total RAM (64 + 256).

Optionally the RAM 320XE and RAM 320XL PLUS will allow 576kB with a simple hardware modification (of the atari).

This is specifically to ensure compatibility. If the GUI always resides within a specific address range, that is ONLY used as an area for the GUI, there can never be a problem with it conflicting with other software.

 

The other thing to consider is the form-factor. If the GUI is on any kind of cart, it will be more expensive, and it will take up the cartridge port (or have an ugly pass-through). This is clearly a bad idea, because the GUI is being designed to work with SpartaDOS. In any case, even if the GUI resided on a multi-cart, it must ensure that it has a conflict-free region of RAM to occupy, that will be large enough to ensure it's current size, and any modifications made to it during it's software lifecycle.

 

The concept of actually distributing it (or future upgrades of the GUI) on an inexpensive SD card might be a viable option, but the problem is that not everyone has an SD card reader, and they are more expensive than a RAM upgrade would be. The other problem is that it does not guarantee that the end-user has an appropriate amount of ram, where the GUI code can reside, without causing a potential conflict.

 

Many people just have stock hardware. Considering that it is possible to have a battery-backed 320K-576K RAM subsystem, this is what I propose:

 

Release a special battery-backed RAM upgrade that INCLUDES the pre-installed FJC GUI, along with, say, "The Last Word", and/or other GUI-apps. Just work out a deal with Flashjazzcat to decide on the price, and those type of details.

 

This way, anyone with a plain-vanilla system can simultaneously upgrade to a battery-backed RAM expansion, while also upgrading to the New Atari GUI. It benefits both the hardware designer & the software engineer, while providing maximum bang-for-the-buck for the end-user, and can be accomplished with one payment, and a simple installation.

 

The beauty of this concept is that everyone who is running the GUI will be running it on an identical, compatible platform, and it would be a defacto standard for all of this great stuff. The end-user pays in one place, gets it delivered & instantly has Christmas 1984.

 

That's why I suggested that it would be the way to go.

 

With the distribution model that I'm suggesting today, we, the end-users, have just One Expenditure; just like when you bought your first 1050... costs some money, but not too much, and in the end, it completely makes your computing experience many times better.

 

It would be an upgrade that was easily understood by everyone, and it could have very broad appeal amongst all Atari 8-Bit users.

[flashjazzcat]

How can you have an area of the 6502's addressable memory which is guaranteed never to be used by any other software? Unless you mean banked RAM which is switched in with a completely different banking scheme to the one we currently use... that could be useful: the GUI on a banked flash cart which also has 256KB of on-board RAM which nothing but the GUI will ever "see" because it isn't banked with PORTB...

[ctirad]

The other thing to consider is the form-factor. If the GUI is on any kind of cart, it will be more expensive, and it will take up the cartridge port (or have an ugly pass-through).

 

If the gui will require any special hardware except a standard ram expansion, it will be even more expensive and it will take up either cart + eci, pbi or will requiere a lot of soldering.

 

This is clearly a bad idea, because the GUI is being designed to work with SpartaDOS.

 

Then it should be a part of the SDX cart/expansion or bootable. I really think no one will want to use a software, which will reqire two (or even three if we count the expanded RAM) dedicated different hardware expansions installed.

 

The concept of actually distributing it (or future upgrades of the GUI) on an inexpensive SD card might be a viable option, but the problem is that not everyone has an SD card reader, and they are more expensive than a RAM upgrade would be.

 

SDrive is much simpler and cheaper, than any RAM upgrade and it is definitely a must have for any user who wants to use any of the modern software.

Edited March 4, 2011 by ctirad

[UNIXcoffee928]

How can you have an area of the 6502's addressable memory which is guaranteed never to be used by any other software? Unless you mean banked RAM which is switched in with a completely different banking scheme to the one we currently use... that could be useful: the GUI on a banked flash cart which also has 256KB of on-board RAM which nothing but the GUI will ever "see" because it isn't banked with PORTB...

Got busy for a bit, remodeling a room in the house. To pick up where I left off....

 

 

I was considering a theoretical scheme that:

 

 

- Treated a small, safe address range in a method analogous to Memory Mapped Device I/O

 

- Allowed a definable (& perhaps movable) "Working Set" address range area, in the base 64K

 

- Utilized the battery backed Extended RAM as BOTH a switchable set of banks AND a collection of RAMdisks

 

- Allowed for an "up to you" foo factor that could utilize both Interleaved Memory concepts AND Swapfile concepts, to increase performance

 

 

So, what I was essentially trying to get at is: That it is entirely possible to create a small, efficient Custom Memory Management Scheme as a module of your overall GUI, that could be implemented in a cost effective manner, directly on a Battery Backed RAM expansion unit.

 

A programmer's analogy might be the Special Disk Formats, and Copy Protection Techniques that were done with physical disks, back in the old days... the programmers created their own (somewhat obscure) methods of filesystem creation, and basically created their own mini-OS/Monitor to read from / write to the disks. In short, they did it differently, & often with schemes that displayed a lot of ingenuity. If the GUI was in RAM, with it's own software-implemented mini-MMU, it could open up interesting avenues that haven' really been explored on the Atari.

 

Other than that, I had stated that the GUI, itself, could be shipped, preloaded, into a RAMdisk on a battery-backed RAM expansion (provided that there is no technical reason that this wouldn't work)... A separate configuration utility could then pull anything that it needed from the RAMdisk, to "Install" the GUI as a usable program.

 

Bear in mind that all of this is completely theoretical, but I did study OS design academically, and I'm pretty good at looking for creative solutions to problems, in general.

 

If no one's interested, that's cool too. In the least, hopefully, I've described enough to be able to get people thinking, out-of-the-box, about other ways to do things, and perhaps some of these ideas will be used, in one form or another, to make the FJC GUI even better... & that's all that matters, really, each of us contributing our knowledge, to help to make this landmark software the best that it can be.

 

I have found, as a general rule, that sometimes, when you hear about doing things completely differently, it sets thought-processes in motion that allow you to really think creatively about solving a problem. As it turns out, probably half of the time, the solutions that YOU come up with, after reading something like this will be completely different than what you read... but they will also be completely different than your original plan. It's an Strategy Optimization Trick. That's just the beauty of Human Cognitive Processes.

 

You will find excellent information on RAM Banking here: http://www.atarimax....rg/acarts2.html

[flashjazzcat]

I hear ya. I just needed you to elucidate some.

 

I've really taken on board your suggestions about "thinking outside the box", and it appears that a perfect and novel solution is going to present itself in a very timely manner. I can't go into detail at the moment since the technolohgy doesn't yet exist, but it will absolutely be the ideal delivery method for the GUI, will completely solve the legacy app problem in one fell swoop, will enable the GUI to run on any machine regardless of memory size, and will have myriad applications even for folks who don't want to use the GUI. I won't be pressed into going into more detail now, but suffice it to say that I'll developoing the GUI to work on this hardware. Perhaps not exclusively so, but depending on the price point of the hardware, it may even prove that that's the best thing to do.

 

The last piece of the puzzle having fallen into place, back to the coding...

[UNIXcoffee928]

Glad to help out, best of luck with your work!

[yerzmyey]

ctirad:

 

> Also, an unexpanded 16kB 600XLs can be upgraded to 320XL without any additional work.

---------------------

1) I have a 600XL with internal 64Kb.

Can I plug the 320XL expansion to the machine and would it work without any additional soldering?

2) For my 800XL I would be interested in 320XL full version, with a power cable (to joystick, as I understand). Will the expansion work also on 600XL (when the cable isn't plugged-in)?

 

Thanx dude.

Y

[Rybags]

Power cable isn't needed on 600XL, it has power to the relevant PBI pin by default. It can easily be added to the 800XL (1 wire).

 

The 320XL has a jumper switch - either override all internal RAM, or only override $4000-$7FFF addresses. That allows compatability with VBXE, and allows for overriding all internal RAM e.g. if you have a system with faulty RAM it can be left in there without bad effects.

[+Philsan]

I don't know if this information is useful.

 

I've found that my 320XL expansion doesn't work with jumper on (computer internal memory disabled) with a

800XL PAL Rev. D PBT 374

800XL PAL Rev. D PBT 414

 

My 320XL expansion works with jumper on with a

800XL PAL Rev. A (no PBT # written on MB)

[Faicuai]

What are the complexities involved, and do you think that it's a do-able modification to your current project?

 

The RAM320XL has the power connector, thus you can easily plug some battery there.

The RAM 320XE is powered from the cart port and I don't plan to add such option (any more).

 

I'm asking this, because Flashjazzcat, in the GUI thread, is trying to determine the best place for the code to reside.

 

Why to not just boot it into any standard expansion RAM from a drive? The devices like SDrive + high speed SIO or Qmeg are really fast. And for the people, who still prefer old slow and small floppies and want instant start, there can be some kind of a flash cartridge.

 

Aside from that, what is the Maximum amount of memory that has been/can be added via your banking method? Thanks.

 

For the unmodified XL and XE and standard banking, the limit is 320kB of total RAM (64 + 256).

Optionally the RAM 320XE and RAM 320XL PLUS will allow 576kB with a simple hardware modification (of the atari).

This is specifically to ensure compatibility. If the GUI always resides within a specific address range, that is ONLY used as an area for the GUI, there can never be a problem with it conflicting with other software.

 

The other thing to consider is the form-factor. If the GUI is on any kind of cart, it will be more expensive, and it will take up the cartridge port (or have an ugly pass-through). This is clearly a bad idea, because the GUI is being designed to work with SpartaDOS. In any case, even if the GUI resided on a multi-cart, it must ensure that it has a conflict-free region of RAM to occupy, that will be large enough to ensure it's current size, and any modifications made to it during it's software lifecycle.

 

The concept of actually distributing it (or future upgrades of the GUI) on an inexpensive SD card might be a viable option, but the problem is that not everyone has an SD card reader, and they are more expensive than a RAM upgrade would be. The other problem is that it does not guarantee that the end-user has an appropriate amount of ram, where the GUI code can reside, without causing a potential conflict.

 

Many people just have stock hardware. Considering that it is possible to have a battery-backed 320K-576K RAM subsystem, this is what I propose:

 

Release a special battery-backed RAM upgrade that INCLUDES the pre-installed FJC GUI, along with, say, "The Last Word", and/or other GUI-apps. Just work out a deal with Flashjazzcat to decide on the price, and those type of details.

 

This way, anyone with a plain-vanilla system can simultaneously upgrade to a battery-backed RAM expansion, while also upgrading to the New Atari GUI. It benefits both the hardware designer & the software engineer, while providing maximum bang-for-the-buck for the end-user, and can be accomplished with one payment, and a simple installation.

 

The beauty of this concept is that everyone who is running the GUI will be running it on an identical, compatible platform, and it would be a defacto standard for all of this great stuff. The end-user pays in one place, gets it delivered & instantly has Christmas 1984.

 

That's why I suggested that it would be the way to go.

 

With the distribution model that I'm suggesting today, we, the end-users, have just One Expenditure; just like when you bought your first 1050... costs some money, but not too much, and in the end, it completely makes your computing experience many times better.

 

It would be an upgrade that was easily understood by everyone, and it could have very broad appeal amongst all Atari 8-Bit users.

 

 

...This is among the most cohesive and well thought-out posts that I have read, so far, in terms of an integrated, viable commercial approach to juice-out the functional potential and usability of these upgrades.

 

We would only be left with the necessary HW-counterparts to bring these great SW/HW enhancement to the A800 "JayMiner", so we can all enjoy from this wonderful (and unique) machines' full potential.

 

WHERE IN THE WORLD IS WARERAT?

 

F.

[+Stephen]

WHERE IN THE WORLD IS WARERAT?

 

F.

Retired and vacationing in Maui

[+orpheuswaking]

WHERE IN THE WORLD IS WARERAT?

 

F.

Retired and vacationing in Maui

 

 

Nah, I heard it was O'ahu

[fibrewire]

The last piece of the puzzle having fallen into place, back to the coding...

When in doubt - delete.

[MEtalGuy66]

Warerat did not PROMISE you guys that he would produce that upgrade at any given deadline. Nor did he take any money from any of you. I've been to his house very recently, and he does have the prototype in plain view, and easily accessible. He also has a LIFE.. And what he chooses to do with his time is not for you to question. When he does make the 800 upgrade available, it will be done in a manner that meets his personal satisfaction, as the best possible solution.

 

Fiberwire.. I'm not gonna speak for Warerat.. But I'm telling you for your own good: YOU NEED TO REALIZE THE VALUE OF SHUTTING YOUR MOUTH