What kind of RAM upgrades are there for the 800XL

[Havok69]

Very cool - keep us posted!

[Atari8guy]

Yes do keep us posted...I would have interest in one of these too!

[+Philsan]

I will buy one cased.

 

What about a similar expansion for 130XE?

 

If this simple (no soldering) and low priced memory expansion could be available for XL/XE computers I think 320KB would become the standard RAM for A8.

Edited April 17, 2010 by Philsan

[ctirad]

What about a similar expansion for 130XE?

 

It's theoretically possible, but it would occupy both cartridge and expansion ports, which I don't like. Instead of that I'm going to design an internal XL/XE expansion which will simply plug under CPU (or solder above, when CPU is not socketed) and will need to solder only two or three additional wires.

[kurtm]

What about a similar expansion for 130XE?

 

It's theoretically possible, but it would occupy both cartridge and expansion ports, which I don't like. Instead of that I'm going to design an internal XL/XE expansion which will simply plug under CPU (or solder above, when CPU is not socketed) and will need to solder only two or three additional wires.

 

Couldn't you just throw a passthru port on the back?

[+Philsan]

What about a similar expansion for 130XE?

 

It's theoretically possible, but it would occupy both cartridge and expansion ports, which I don't like. Instead of that I'm going to design an internal XL/XE expansion which will simply plug under CPU (or solder above, when CPU is not socketed) and will need to solder only two or three additional wires.

Couldn't you just throw a passthru port on the back?

I agree.

Moreover, with SDrive, SIO2SD, SIO2PC, many XE users don't use cartridges.

 

As written, a plug and play external solution would set A8 standard memory to 320 KB.

[+MrFish]

OK, here we go. Here you can see the new 320XL plug and play RAM expansion plugged into 600XL:

 

http://krupkaj.ic.cz...riada2010&obr=8

http://krupkaj.ic.cz...riada2010&obr=9

 

I will add some detailed info soon.

 

OK, that settles it, I need an 800XL. I've always wanted to see something like this done. Crap, I should have snagged one or more of those XLs that came into work not too long ago (shakes head in disgust).

[+wood_jl]

I had always hoped - in the back of my mind - that the XL would prevail over the XE. Looks like this finally does it!!!!! I like the XE too, but everybody knew they screwed up with that "ECI" connector.

 

This looks AWESOME!

[ctirad]

OK, OK, I will design the XE version too, sooner or later. I swear It will be quite difficult though, because there is no "CASINH" signal on the XE expansion port, which means I will have to replicate all the MMU part in the CPLD.

 

Anyway, in present time I'm focused to pruduction version of the 320XL card. I changed the layout a little bit and removed the possibility to not remap internal 64kB RAM onto card. Thus, now the good old and often faulty internal RAM is allways disabled and the new RAM is used instead. BTW, I found this is the killer feature perhaps even better than RAM upgrade itself, because there are many dead XL computers around which can be almost magically fixed by that. I brought back to life two 800Xl and one 600Xl last week

 

In additon it saved me two pins of the CPLD, so now I have three of them in total available for some additional features. Firstly I thinked about COVOX with dual PWM output, but this needs many register bits which don't fit into used CPLD. Thus I will add only some LEDs for an activity and basic status indication. Or have someone a better idea?

[Rybags]

Always disabling internal RAM will probably mean that it won't work with VBXE.

 

VBXE allows mapping of part of it's RAM in preference to internal RAM. But, I'd guess you use EXTSEL to disable internal RAM? That will also disable access to VBXE RAM.

[+wood_jl]

I suppose you'd have to put a cartridge slot on the 130XE version, then?

 

It would be cool if the board could be designed to fit inside an "off-the-shelf" type case - kind of like the Sdrive NUXX was.

 

I don't think making it work with VBXE should be much of a concern, as VBXE is a high-end hardcore type device; anybody who's savvy enough to have VBXE is probably not phased in the slightest by internal RAM upgrades (or the VBXE lol). The utility of this design would be for those who are not, by virtue of the fact that it's a plug-in design. Quite genius, I say!

[ctirad]

Always disabling internal RAM will probably mean that it won't work with VBXE.VBXE allows mapping of part of it's RAM in preference to internal RAM. But, I'd guess you use EXTSEL to disable internal RAM? That will also disable access to VBXE RAM.

 

If the VBXE sets the EXTSEL signal, it will not work together in any case, remaped or not. There is impossible to drive one signal with two devices. The correct solution would be to alter the EXTINH signal instead. Then the VBXE and RAM 320XL could cooperate nicely.

[Rybags]

I'm fairly sure VBXE only monitors EXTSEL, such that it will always give precedence to external/other RAM expansions.

 

Most normal XL/XE RAM expansions usually only use the $4000-$7FFF bank area, so there isn't really a problem.

 

But if an expansion takes precedence over all 64K of RAM, then VBXE RAM won't be accessable at all.

[ctirad]

I'm fairly sure VBXE only monitors EXTSEL, such that it will always give precedence to external/other RAM expansions.

 

That would be electrically correct, but it does not make much sense in the aspect of a function. If the VBXE or another device want to remap any part of the RAM space, it must disable the onboard RAM when the remaped window is accessed. It can be done by setting the EXSTSEL to LOW state, which is the most clean way and also the only way which can be used by an external device without any motherboard modification. The problem is that it cannot be used by more than one device. The other possible way is to alter the CASINH signal, which means cut one trace on the motherboard and generate some CASINH' signal whis will go LOW when the VBEXE will access and remaped RAM. This solution would work nicely for VBXE + RAM 320XL combo.

[Rybags]

I think VBXE uses CASINH in both query and assert modes, ie so it knows to stay quiet if a ROM or I/O space access is taking place, and asserts it to prevent system RAM accesses if it's window is active in the same place.

 

I'd say that all your upgrade needs is the option to not disable internal RAM, then VBXE should be fine with it.

 

Of course, candle would be the best qualified to answer queries about compatability... and the docs available from the links in the VBXE2 thread give a few clues as to how it interfaces with the system.

[+Philsan]

Does this game (128KB) work with the expansion?

With Altirra emulator set to 320KB, car's selection shows garbage.

Perhaps it is an emulator problem but I want to be sure that with this new memory expansion I will be able to use all 128KB software (otherwise I would keep connected 130XE instead of 800XL).

[ctirad]

Does this game (128KB) work with the expansion?

With Altirra emulator set to 320KB, car's selection shows garbage.

 

Same here I tested it also on my second XL with 1MB RAM, and it behaves also the same. Perhaps it does use separate CPU/ANTIC bank access mode? I'wll try it with Atari800 in RAMBO/COMPY compatible 320kB mode.....

....So it seems that it works correctly only in 130XE and CompyShop 320kB mode. All other expansions of various sizes show garbage instead of a car and also durning loading. So it's rather an software bug and it should be fixed.

[AtariNerd]

I know very little about Atari hardware or the capability of it's ports so I'm not sure how to phrase this very hypothetical question, but since the memory is external anyways, would there be theoretically some possible way to build in a memory storage expansion that could feed data to that memory at very rapid speeds, bypassing the current limits? Something like a flash adapter. Or would the data need to cross the normal data lines regardless? If so, might there be a way for the computer to control the I/O protocals, but have the data pass more directly into memory through an expansion like this?

 

I'm not asking for it to be built, just a passing vague semblance of a thought that I had.

[Rybags]

Theoretically, sure.

 

VBXE already does that (kinda). It runs at 14 MHz and the controller acts kind of like a PC Northbridge. So, you're running at 8 times normal speeds, so there's 7 spare cycles which are used by the blitter and showing VBXE graphics - and the 8th cycle is also spare if Antic or the CPU doesn't use it.

 

In theory a similar device might interface with an SD card and under program control could do I/O on those spare cycles.

But, I'd say the expansion would be "intrusive" in a similar manner to VBXE, ie - you'd probably remove the Atari's master crystal and use a 14 MHz crystal on the device which would in turn supply the clock back to the Atari.

Edited April 21, 2010 by Rybags

[candle]

VBXE uses CASINH to detect possible bus combustions with other devices in system - mostly ROM chips and cartridges

EXTSEL is only asserted (or rather activated, as its active low) if VBXE sees than on given bus cycle there is no other device trying to do that (thats 14mhz advatage)

 

one of my 1mb expansions is using extsel style mapping for expanded memory mapping - there are no issues with vbxe

[+bob1200xl]

What you're describing is called Direct Memory Addressing - DMA. You could do that on an Atari. As long as ANTIC (or Refresh) doesn't want the buss, you can allow the memory controller (that you get to build) to move data in and out of memory.

 

Works better on a 65816 than a 6502...

 

I think a CF card can be programmed to do Read Multiple sectors in DMA mode. This would allow you to read up to 255 sectors at pretty much CLK/2 bytes per second.

 

Movies, anyone?

 

Bob

 

 

I know very little about Atari hardware or the capability of it's ports so I'm not sure how to phrase this very hypothetical question, but since the memory is external anyways, would there be theoretically some possible way to build in a memory storage expansion that could feed data to that memory at very rapid speeds, bypassing the current limits? Something like a flash adapter. Or would the data need to cross the normal data lines regardless? If so, might there be a way for the computer to control the I/O protocals, but have the data pass more directly into memory through an expansion like this?

 

I'm not asking for it to be built, just a passing vague semblance of a thought that I had.

[ctirad]

I know very little about Atari hardware or the capability of it's ports so I'm not sure how to phrase this very hypothetical question, but since the memory is external anyways, would there be theoretically some possible way to build in a memory storage expansion that could feed data to that memory at very rapid speeds, bypassing the current limits?

 

Sure. The CPLD and RAM chip can be clocked multiple times faster than the 6502 bus, so there is plenty of room for fast transfers between RAM, CPLD and some other device as flash interface, dma audio, blitting or such. All without affecting the 6502 bus.

[ctirad]

VBXE uses CASINH to detect possible bus combustions with other devices in system - mostly ROM chips and cartridges

EXTSEL is only asserted (or rather activated, as its active low) if VBXE sees than on given bus cycle there is no other device trying to do that (thats 14mhz advatage)

 

I see. But how would does the VBXE behave when the EXTSEL will by allways down (=grouned) by an external RAM upgrade?

[ctirad]

I suppose you'd have to put a cartridge slot on the 130XE version, then?

 

Yes. I just hope, that the connector is commonly available.

[candle]

ctirad: it will never map its memory - also - any PBI device won't work