A8 Cartridge Memory Expansion?

[+bob1200xl]

You are making it sound like the extended memory is NOT available to the CPU - you can only request the DMA controller to copy data to/from the extended memory. So, if I want to run some code that resides in the extended memory, I have to save away some space in my 64K, move the code into that space, execute the routine, page it back out again, and then restore the original data?

 

This is virtual memory, isn't it? Why would you do it like that? Just as a ramdisk? Is all memory in the expansion card or does the original 64K still act as CPU memory. If you were going to DMA into main memory from external memory, yes, you would need a buss with control lines and such. What happens with interrupts? If DMA is moving 2K of data, will the latency be 2K-odd cycles?

 

Bob

 

 

Well, yes - we can put all sorts of hardware externally that does any number of things, but how does the 6502 in the computer access expanded memory? Don't you have to map a range of addresses in the base 64K with a block of extended memory? If I put a memory expansion on the Atari PBI, it will access just like an internal upgrade or a cartridge one. It has to. So does the C64, doesn't it?

As I said: The DMA controller can copy/swap memory from/to C64 system memory.

 

Why in the world would you want a DMA controller to copy or swap anything? Copy to what - flash memory? That isn't going to be at clock speed...

Copying is what you normally do on extended memory anyway since in most cases you simply use it as RAM-disk. The copy/swap itself is at CPU clock speed, 1 byte per cycle. It can even write to IO registers (for example: the color registers).

 

Doesn't matter. How does the system CPU get to memory? That's all that matters.

The CPU only has access to the hardware registers of the DMA controller.

[Fröhn]

You are making it sound like the extended memory is NOT available to the CPU - you can only request the DMA controller to copy data to/from the extended memory. So, if I want to run some code that resides in the extended memory, I have to save away some space in my 64K, move the code into that space, execute the routine, page it back out again, and then restore the original data?

Yes, that's how it works. However, that's also the way you usually work with extended RAM (copy stuff to system RAM, then use) because when you code something you usually have the 64k system RAM in mind and don't want to care about a lot of banking trouble. Even most game cartridges with more than 8 or 16k do that because banking during complex code is REALLY troublesome.

 

This is virtual memory, isn't it? Why would you do it like that? Just as a ramdisk? Is all memory in the expansion card or does the original 64K still act as CPU memory. If you were going to DMA into main memory from external memory, yes, you would need a buss with control lines and such. What happens with interrupts? If DMA is moving 2K of data, will the latency be 2K-odd cycles?

The CPU still uses the 64k (or 128k in the C128) system RAM. If you copy 2000 bytes it will take 2000 cycles, still a lot better than copying by CPU since that would take a minimum of 16000 cycles (usually more than that due to loop/address counters etc). IRQs would have to wait.

 

Btw there also was a "compare"-feature and there was even a program which made use of that . It was a LZ-based packing program which took only about 1 minute (older programs would easily take 1-3 hours) for approx 50k. Back then I bought the RAM expansion just to be able to use that program, spent too many hours on crunching before

[oracle_jedi]

The UK one was the yorkie (256k upgrade), later re-released by richard gore/DGS in the early-mid 90's, it was basically a take on the atari 1064 but with more memory

 

Does anyone own a Yorky?

 

I remember seeing the ads for them but I have never seen a picture of one.

 

Are they memory compatible with the 130XE? Would they let an 800XL run software that would otherwise need the Claus B 256K upgrade?

 

 

Graham

[+bob1200xl]

Well, the banked Atari carts don't do that, for sure. The PBI doesn't do that, either. Some (most?) programs may move ramdisk data into main memory in order to do directory lookups, for example, but that is probably just to be compatible with disk code running a real drive. The code doesn't realize that it is not talking to a floppy, otherwise it wouldn't move data under some circumstances.

 

The C128 has 128K? How does he access more than 64K?

 

Bob

 

 

 

You are making it sound like the extended memory is NOT available to the CPU - you can only request the DMA controller to copy data to/from the extended memory. So, if I want to run some code that resides in the extended memory, I have to save away some space in my 64K, move the code into that space, execute the routine, page it back out again, and then restore the original data?

Yes, that's how it works. However, that's also the way you usually work with extended RAM (copy stuff to system RAM, then use) because when you code something you usually have the 64k system RAM in mind and don't want to care about a lot of banking trouble. Even most game cartridges with more than 8 or 16k do that because banking during complex code is REALLY troublesome.

 

This is virtual memory, isn't it? Why would you do it like that? Just as a ramdisk? Is all memory in the expansion card or does the original 64K still act as CPU memory. If you were going to DMA into main memory from external memory, yes, you would need a buss with control lines and such. What happens with interrupts? If DMA is moving 2K of data, will the latency be 2K-odd cycles?

The CPU still uses the 64k (or 128k in the C128) system RAM. If you copy 2000 bytes it will take 2000 cycles, still a lot better than copying by CPU since that would take a minimum of 16000 cycles (usually more than that due to loop/address counters etc). IRQs would have to wait.

 

Btw there also was a "compare"-feature and there was even a program which made use of that . It was a LZ-based packing program which took only about 1 minute (older programs would easily take 1-3 hours) for approx 50k. Back then I bought the RAM expansion just to be able to use that program, spent too many hours on crunching before

[Rybags]

I don't think full 130XE mode could be done on the XL without internal mods.

 

The PBI doesn't seem to output anything from PORTB although I imagine it could be shadowed and the decoding done offboard.

That could cover the bank selecting, but there also seems no way of distinguishing between Antic or CPU reads.

 

The XE ECI has the /HALT signal though, so it should be possible there.

[Fröhn]

Well, the banked Atari carts don't do that, for sure.

Most Atari cart games are probably very small, something like 8 or 16k. Just like most C64 cart games. Those ofcourse do not need to copy anything to RAM because there is no banking hell going on. If you remove the copy protection (usually a few writes to ROM-banking-area) they simply work if you run them from RAM.

 

The C128 has 128K? How does he access more than 64K?

Via banking of 1/4/8/16k shared areas and banking the entire 64k. Also, video chip area, zeropage and stack can be moved in memory independent from the current CPU bank.

Edited March 6, 2009 by Fröhn

[Mathy]

Hello Frohn

 

AFAIK the videochip in the C128 has it's own video-memory. Either 16kB or 64kB. These are the same RAMchips that are used in the 600XL and the XEGS respectively.

 

greetings

 

Mathy (who copied the C128 video stuff onto a small perfboard, plugged it into his XE's cartridge port, but managed only to change the backgrond colors.)

[Garak]

Hello Frohn

 

AFAIK the videochip in the C128 has it's own video-memory. Either 16kB or 64kB. These are the same RAMchips that are used in the 600XL and the XEGS respectively.

 

Fröhn is talking about the VIC-II. You're talking about the VDC. The C128 has two video chips. It's the VDC that has it's own video ram that's either 16k (flat C128) or 64k (C128D).

 

Garak

 

Edit: I re-read Fröhn's post, I'm assuming he was thinking about the VIC-II. IIRC, I don't think the VDC registers can be moved around in memory? It's been a while. But irregardless the C128 has two video chips.

Edited March 6, 2009 by Garak

[doctorclu]

The Commodore part has pins for most (all?) of the system bus, including clocks, interrupts and all the address lines. ...

 

And if you shoved a penny in the Commodore cartridge slot you could short it out and blow it real nice.

 

At least that is what I was told by some friends who liked Atari, hated Commodore, and wanted to K.O. the school's commodore comptuers...

[+rdemming]

I don't think full 130XE mode could be done on the XL without internal mods.

 

The PBI doesn't seem to output anything from PORTB although I imagine it could be shadowed and the decoding done offboard.

That could cover the bank selecting, but there also seems no way of distinguishing between Antic or CPU reads.

 

The XE ECI has the /HALT signal though, so it should be possible there.

 

Yes, the original Turbo Freezer XL was a PBI device that optionally came with extra memory. It shadowed writes to PORTB to implement 130XE style bank-switching. But to make it compatible with the Antic/CPU mode, you needed to solder an extra wire (I believe the HALT line) to the PBI bus.

 

Robert

[carmel_andrews]

Oracle Jedi...the yorkie XL upgrade was re-launched a few years ago by richard gore (who also re-released John harris's 'Jaw breaker') I think he was doing it through DGS (Dean Garraghty Software) but I can't remember exactly

[YSG2020]

It’s a shame the PBI port on the back of the XL’s was never fully adopted and  utilized by developers as an expansion port like it was on the Commodores.  Backward hardware compatibility concerns to the 400/800 seems to have been a major strategic architecture error and downfall for Atari. The Atari was a better computer than the C64 in many ways, but was not competitively priced until too late, and was marketed horribly to a confused public that thought it was a game machine.

Edited February 22, 2020 by YSG2020

[Mathy]

Hello YSG2020

 

Even Atari itself was confused and thought it was a game machine.  That's why most serious stuff was cancelled.

 

Sincerely

 

Mathy

[+CharlieChaplin]

Well,

 

if you are interested in obtaining XRAM via cartridge, then order (or show your interest) in a re-release of the RAMcart. Note that this cart is not compatible to 130XE (port B / $D301) XRAM and thus a lot of software already out there will not support or recognize it.

 

Afaik, there are some DOS drivers for the Ramcart available, including Bewe-DOS and DOS II+D (V6.1 or V6.4 or both) and maybe others. If the re-release will be successfull, maybe there will be also drivers for SDX and other DOS versions ?!? However, most >=128k programs will still require a patch (or a complete re-write?) to work with a Ramcart instead of 130XE compatible XRAM...

 

The original Ramcarts were (afaik) 64k and 128k in size, but later there were also 256k and 1024k Ramcarts; the re-release should be available in a) original sizes and b) larger sizes (even larger than 1MB).

 

[+Larry]

Was the Megamax Modul (from Mega-Hz IIRC) one of these?  I have a 1MB version that I haven't used in a long time, but I think it could be used as an 8K or 16K cartridge and the whole 1 MB could be accessed in 256-byte mini-chunks by toggling one byte via BASIC. (?)  Someone more creative and dedicated than me could probably come up with better ways to use it, but I did get the BASIC thing working. (Sorry for the glare!)

Larry

 

Edit: Found an old thread about this cartridge. Evidently, the ram could be accessed in 8K chunks (not 256 byte increments).  I'm looking for my TBXL program that used this.