RAM Upgrade Applications

[MEtalGuy66]

What Im asking is what other considerations are there? I mean, The MIO uses the $D1xx range for it's operating variables & registers. So this is one area you'd want to avoid for the sake of PBI device compatability..

Howbout page $D7? Neither the 800 nor the XL brought out the decode signals for pages $D1 and $D7, so any hardware that uses them must decode them itself. You said MIO uses $D1 and $D6. Is $D7 free?

 

I spoke with warerat about it, and we were thinking of using the unused PIA adress space.. (like $D3FF)...

[dmlloyd]

In theory, $D100-D1FF and $D600-D7FF are reserved for use by PBI devices. So you shouldn't use those ranges if you plan to coexist with other possible PBI devices.

[ClausB]

I spoke with warerat about it, and we were thinking of using the unused PIA adress space.. (like $D3FF)...

Wouldn't you have to intercept and modify the existing PIA select signal so that it would not react to $D3FF?

 

Not if you use address lines A2 thru A7 as the bank number instead of the data lines. For example, writing the usual PIA data to $D3CD would select bank # $33 ($33*4+$D301 = $D3CD). Of course, that would limit you to 64 banks instead of 256, but it might simplify the circuit. The code would be like:

LDA BANK

ASL A

ASL A

TAX

LDA $D301

STA $D301,X

[MEtalGuy66]

I spoke with warerat about it, and we were thinking of using the unused PIA adress space.. (like $D3FF)...

Wouldn't you have to intercept and modify the existing PIA select signal so that it would not react to $D3FF?

 

Not if you use address lines A2 thru A7 as the bank number instead of the data lines. For example, writing the usual PIA data to $D3CD would select bank # $33 ($33*4+$D301 = $D3CD). Of course, that would limit you to 64 banks instead of 256, but it might simplify the circuit. The code would be like:

LDA BANK

ASL A

ASL A

TAX

LDA $D301

STA $D301,X

 

Heh. What?!?! You people are making this alot more complicated than it is.. There is no existing register on $D3FF..

 

The way it would work is that whatever value you wrote here (8 bits) would control the state of A8, A9, A10, and A11 on the 16meg SIMM.. The first 8-bits of adressing (A0-A7)would be controlled by the 130XE in the exact same manner that it already does..

 

So with any given value, written to $D3FF, you would have an independant set of 4 16k banks that could be switched using PORTB... This means (256 * 4 =) 1024 16k banks... 16megabytes...

 

And if you left $D3FF alone (dont change the value written here,) youve still got a 100% compatable bone-stock 130xe...

 

Is this really THAT hard to understand?

[DamageX]

the question is... if you write to $D3FF won't you also hit $D303 and make unwanted changes there? Because the PIA registers are mirrored throughout the $D3xx space (A2-A7 not connected to it)? If so then you might need to add some logic to PIA's chip select signal or use an alternate scheme like Claus suggested.

[+warerat]

the question is... if you write to $D3FF won't you also hit $D303 and make unwanted changes there? Because the PIA registers are mirrored throughout the $D3xx space (A2-A7 not connected to it)? If so then you might need to add some logic to PIA's chip select signal or use an alternate scheme like Claus suggested.

 

Yes, the PIA is obviously disabled during a write to $D3FF. The 6520 has three chip selects-- two active-high, and one active low. A stock machine with a single PIA would only be using the active-low select and the other two are strapped to VCC. All that's happening here is that A0-A7 are being fully decoded in conjunction with the standard D3XX- signal to generate an additional select to disable the PIA while the latch is enabled during a write.

[ClausB]

the question is... if you write to $D3FF won't you also hit $D303 and make unwanted changes there? Because the PIA registers are mirrored throughout the $D3xx space (A2-A7 not connected to it)? If so then you might need to add some logic to PIA's chip select signal or use an alternate scheme like Claus suggested.

 

Yes, the PIA is obviously disabled during a write to $D3FF. The 6520 has three chip selects-- two active-high, and one active low. A stock machine with a single PIA would only be using the active-low select and the other two are strapped to VCC. All that's happening here is that A0-A7 are being fully decoded in conjunction with the standard D3XX- signal to generate an additional select to disable the PIA while the latch is enabled during a write.

Right. But to do that, you need to wire A0-A7 and D0-D7 and -PIACS and +PIACS to your register, 18 wires. The method above needs just A2-A7 and -PIACS, just 7 wires. If you still want 256*4 16K banks instead of 64*4, use PB6 and PB7 to make up the difference.

 

Heh. What?!?! You people are making this alot more complicated than it is.

Hey, Ken, we "people" are trying to make this a lot LESS complicated than it is. Less hardware at the expense of a few more software instructions. (Woz rules! Well, ruled.)

Edited June 5, 2008 by ClausB

[dmlloyd]

Heh. What?!?! You people are making this alot more complicated than it is.. There is no existing register on $D3FF..

 

Yes there is. The select signal for the PIA is derived from A8-15; therefor the PIA is selected for any access in the entire $D3xx range. Since it only has two address lines of its own, the effect is that you see the PIA registers repeated 64 times inside this address range. DamageX and ClausB are referring to this. In order to put your own register here, and not have any side effects, you must take care to deselect the PIA. ClausB's idea was to use the address bits while the chip is selected, much like some bank-switching carts do. This way you can avoid having extra logic to deselect the PIA and decode $xxFF.

[MEtalGuy66]

Heh. What?!?! You people are making this alot more complicated than it is.. There is no existing register on $D3FF..

 

Yes there is. The select signal for the PIA is derived from A8-15; therefor the PIA is selected for any access in the entire $D3xx range. Since it only has two address lines of its own, the effect is that you see the PIA registers repeated 64 times inside this address range. DamageX and ClausB are referring to this. In order to put your own register here, and not have any side effects, you must take care to deselect the PIA. ClausB's idea was to use the address bits while the chip is selected, much like some bank-switching carts do. This way you can avoid having extra logic to deselect the PIA and decode $xxFF.

 

Yeah.. Heh. We already discussed that in the above 3 messages.

[MEtalGuy66]

the question is... if you write to $D3FF won't you also hit $D303 and make unwanted changes there? Because the PIA registers are mirrored throughout the $D3xx space (A2-A7 not connected to it)? If so then you might need to add some logic to PIA's chip select signal or use an alternate scheme like Claus suggested.

 

Yes, the PIA is obviously disabled during a write to $D3FF. The 6520 has three chip selects-- two active-high, and one active low. A stock machine with a single PIA would only be using the active-low select and the other two are strapped to VCC. All that's happening here is that A0-A7 are being fully decoded in conjunction with the standard D3XX- signal to generate an additional select to disable the PIA while the latch is enabled during a write.

Right. But to do that, you need to wire A0-A7 and D0-D7 and -PIACS and +PIACS to your register, 18 wires. The method above needs just A2-A7 and -PIACS, just 7 wires. If you still want 256*4 16K banks instead of 64*4, use PB6 and PB7 to make up the difference.

 

Heh. What?!?! You people are making this alot more complicated than it is.

Hey, Ken, we "people" are trying to make this a lot LESS complicated than it is. Less hardware at the expense of a few more software instructions. (Woz rules! Well, ruled.)

 

Well, this would be assembled on a board that plugs into the PIA socket and has a ribbon cable that goes to a dip-insert that sits in one of the DRAM sockets.. I wasnt planning on hand wiring this inside the machine.. Also, the entire circuit would be implemented on a CPLD, so your looking at basically a simm socket, a small PLCC socket for the CPLD, a tiny 3.3v regulator, and a couple of caps..

 

The whole Idea of this expansion was NOT to use any bits of the PIA PORTB register.. Leave them exactly the way the 130XE uses them.

 

As far as making it require more software to save hardware complexity.. pfft.. Thats whats wrong with 90% of the atari expansions out there...

Edited June 5, 2008 by MEtalGuy66

[ClausB]

As far as making it require more software to save hardware complexity.. pfft.. Thats whats wrong with 90% of the atari expansions out there...

OK. You originally asked for suggestions and that's what I offered. I did not mean to offend. Good luck with it.

[DamageX]

why not piggy-back another PIA? It's easy, and we could then have enough lines for at least 4GB...

[+bob1200xl]

The problem isn't the hardware - it's software. There are no addresses in the Atari that are 'safe' from being corrupted by some program that steps on your registers. The $D3xx addresses, for example, have $00 stored in them by the OS when it boots - even though there is nothing gained by repeating the base addresses. As a result, if you used $D3FF for a configuration register and then jumped to Cold Start, all your data would get wiped out. What you want is an address that nobody can access but you. Problem is: there aren't any.

 

Bob

 

 

 

 

why not piggy-back another PIA? It's easy, and we could then have enough lines for at least 4GB...

[MEtalGuy66]

why not piggy-back another PIA? It's easy, and we could then have enough lines for at least 4GB...

 

Heh. Because thats a huge waste, Why do I need 2 complete 8-bit registers, and an additional 4-bit register when all we are using is an 8-bit register to utilize the maximum size 8-bit memory device that is commonly available for any decent price? (also the largest partition size that any DOS supported "ramdisk" can be)...

 

Also, with a second PIA, you could get a whole lot more than 4GB.. But... It takes the atari 20 minutes to fill 16megabytes (copy from one ramdisk to another)...

 

Also.. A 6520 PIA chip costs $3.50 from Jameco... A 74LS244 or 74LS374 costs about $.50 or less.. So if what you want is a "second PORTB," why use an entire 6520 PIA?

Why are ATARI people obsessed with using the PIA chip and ONLY the PIA chip to control bank switching on the atari? This is what has led to the inception of 15 different incompatble extended ram upgrade standards... everyone has got their own scheme for utilizing the outputs of PORTB on the PIA.... heh.. How does the 8meg upgrade board that apple released for the Apple IIc worK? I'll give you a hint.. Theres no PIA chip involved..

 

 

 

Also, you are still stuck in the mode of thinking that we are going to hand-wire this upgrade using discreet logic.

 

I'm not trying to create YET ANOTHER "wiring hack" memory upgrade... What I want is an upgrade that produces max ram-size/functionality without sacrificing compatability with the only extended ram standard ever officially released/endorsed by ATARI.. (That would be the 130xe) ANd lastly, is cheap to produce and easy to install..

 

The CPLD that I am going to use which has alot MORE inputs and outputs than a 6520 PIA, and is infinitely configurable, logic-wise, costs $1.33.... So.. I think I'll go with the CPLD and have my entire PCB include a sim socket, one chip, a tiny smt regulator, and a couple of decoupling caps.. This SINGLE chip will handle the adress decoding (for both reads and writes to the register), the chip enable/disable toggling depending on the stock PIA, the buffering of the register state, the multiplexing of the register into memory adress lines, and the generation of appropriate "cas before ras" refresh signals for the SIMM... All in one chip....

 

I have given it some more thought, and this can all be done with 2 small PCBs, connected by a ribbon cable.. One will sit under the PIA, and the other will sit under the Freddie.

True, you have to socket these 2 chips in your XE to use the upgrade... But in my oppinion, all XEs should be socketed.. and I'm not gonna design an upgrade where the average user has to solder a rats nest of wiring all over the place.. Anything worth putting inside your machine (eg. Megahz SRAM upgrade, internal MyIDE, 32-in one, SmartOS, SmartIDE, etc. etc..) requires a socket to plug it into.. So...

 

 

Ok.. In response to Bob's post... Zeroing the register on a cold-start doesnt wipe out my data in extended ram.. It just resets the bank selection to zero..

 

Without the ramdisk handler loaded (or any software that specifically writes to $D3FF), youd have a completely stock 130XE...

Edited June 6, 2008 by MEtalGuy66

[kenfused]

The problem isn't the hardware - it's software. There are no addresses in the Atari that are 'safe' from being corrupted by some program that steps on your registers. The $D3xx addresses, for example, have $00 stored in them by the OS when it boots - even though there is nothing gained by repeating the base addresses. As a result, if you used $D3FF for a configuration register and then jumped to Cold Start, all your data would get wiped out. What you want is an address that nobody can access but you. Problem is: there aren't any.

 

Bob

Well using enough logic you could probably make it so you have to write a series of a few values to an address or a couple address to enable write mode to the RAMDISK memory, and another register or value to lock the RAM from writing. You could also update the OS ROMs to be sure writing is disabled on reset. This wouldn't be fool proof but would help (somewhere in memory there will be code to do the switch and you always could have a crash accidentally hit it). It is probably not worth the effort since anything you really want to keep should probably write to a real disk before too long anyways.

 

Ken

[carmel_andrews]

Metalguy66...what you just said about the PIA and A8 bank switching surprises me ...and this is coming from a 'non' code/tech head ...I would have thought that even you know that the xl/xe bank switch (not the old 4/800 one) is a PIA ram location (D301h)...and unless your suggesting a number of 'software' based bank switch locations (that work across all A8's), xl/xe users only have one choice ...doing bank switching using the above mentioned PIA location...unless there's a bank switch location on the xl/xe that i don't know about (not incl. the cart bank switcher and page D5xxh)

[MEtalGuy66]

Metalguy66...what you just said about the PIA and A8 bank switching surprises me ...and this is coming from a 'non' code/tech head ...I would have thought that even you know that the xl/xe bank switch (not the old 4/800 one) is a PIA ram location (D301h)...and unless your suggesting a number of 'software' based bank switch locations (that work across all A8's), xl/xe users only have one choice ...doing bank switching using the above mentioned PIA location...unless there's a bank switch location on the xl/xe that i don't know about (not incl. the cart bank switcher and page D5xxh)

 

 

HAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAHAHAHAHAHAHA....

 

 

Thank you, Carmel... I needed that...

[Rybags]

I think Metalguy's idea is a good one. One of the things holding me back from doing a RAM expansion is the rediculous bastardisation of PORTB to do the bigger ones. Kinda pointless having all that extra RAM if it makes a whole lot of programs incompatible.

 

Another idea, albeit maybe a bit rediculous - allow expanded RAM to be swapped as already described. But also allow main RAM to be switched among 16 or so banks. Hey presto! Cheap multitasking!

[carmel_andrews]

Metalguy...Your'e holding something back, what is it

[+warerat]

I think Metalguy's idea is a good one. One of the things holding me back from doing a RAM expansion is the rediculous bastardisation of PORTB to do the bigger ones. Kinda pointless having all that extra RAM if it makes a whole lot of programs incompatible.

 

Another idea, albeit maybe a bit rediculous - allow expanded RAM to be swapped as already described. But also allow main RAM to be switched among 16 or so banks. Hey presto! Cheap multitasking!

 

That could have some interesting applications. Keep a common area like zero page and switch the rest out, including the stack.

[Shawn Jefferson]

I agree, a nice plug in SIMM upgrade like this would be great, IMO. I'm not a purist in the sense that I think all RAM upgrades need to conform to the "standard" that Atari put forward with their 130XE computer. If you ask me, the REAL standard was created by all the hardware hackers out there who basically decided to use all of portb. Most software that uses extended RAM is going to have some sort of autodetect function anyway. Still, if you want to create a new "standard" for upgrades over 1meg, I think that's great, I'd think about purchasing one.

 

Will your upgrade only provide 128k bankable via portb then, replicating the portb layout of the 130XE exactly? If that's the case, most software written for the other upgrades (demos, some games, etc..) will not work with your upgrade, which would be too bad.

 

On the topic of Atari's standard for memory upgrade, I always thought that banking out 16k was dumb. It would be easier to manage an 8k or 4k bank area.

[MEtalGuy66]

I agree, a nice plug in SIMM upgrade like this would be great, IMO. I'm not a purist in the sense that I think all RAM upgrades need to conform to the "standard" that Atari put forward with their 130XE computer. If you ask me, the REAL standard was created by all the hardware hackers out there who basically decided to use all of portb. Most software that uses extended RAM is going to have some sort of autodetect function anyway. Still, if you want to create a new "standard" for upgrades over 1meg, I think that's great, I'd think about purchasing one.

 

Will your upgrade only provide 128k bankable via portb then, replicating the portb layout of the 130XE exactly? If that's the case, most software written for the other upgrades (demos, some games, etc..) will not work with your upgrade, which would be too bad.

 

On the topic of Atari's standard for memory upgrade, I always thought that banking out 16k was dumb. It would be easier to manage an 8k or 4k bank area.

 

All of software written for the 130xe WILL work.. and It will be extremely easy to modify other software to work due to the fact that we are using a single 8-bit register..

 

heh. you call that a "standard"? The way that alll the "hackers" use the portb outputs on the PIA is anything BUT "standard".

[Shawn Jefferson]

All of software written for the 130xe WILL work.. and It will be extremely easy to modify other software to work due to the fact that we are using a single 8-bit register..

 

Yes, I guess you could modify existing software so instead of writing to $D301 to bank memory, it writes to $D3FF instead. But now we've got multiple versions of the software floating around... damned if you do and damned if you don't!

 

heh. you call that a "standard"? The way that alll the "hackers" use the portb outputs on the PIA is anything BUT "standard".

 

I'd call it a "de facto" standard. Writing a $D301 autodetect function isn't that difficult...

 

Don't take this the wrong way, I think your upgrade sounds great, and I also think it's a shame that seperate ANTIC banking got thrown out. There's a lot of potential there that wasn't utilized. However, your upgrade will suffer the same problem as 130XE compatibility-any software written specifically for it will immediately cut out anybody that doesn't have it.

 

A RAMdisk driver is one way to utilize it, but seriously, how many people even use these any more?

 

Though, I'm not and never have really argued for practicality in this hobby, I think it's all about what you WANT to do.

[MEtalGuy66]

All of software written for the 130xe WILL work.. and It will be extremely easy to modify other software to work due to the fact that we are using a single 8-bit register..

 

Yes, I guess you could modify existing software so instead of writing to $D301 to bank memory, it writes to $D3FF instead. But now we've got multiple versions of the software floating around... damned if you do and damned if you don't!

 

heh. you call that a "standard"? The way that alll the "hackers" use the portb outputs on the PIA is anything BUT "standard".

 

I'd call it a "de facto" standard. Writing a $D301 autodetect function isn't that difficult...

 

Don't take this the wrong way, I think your upgrade sounds great, and I also think it's a shame that seperate ANTIC banking got thrown out. There's a lot of potential there that wasn't utilized. However, your upgrade will suffer the same problem as 130XE compatibility-any software written specifically for it will immediately cut out anybody that doesn't have it.

 

A RAMdisk driver is one way to utilize it, but seriously, how many people even use these any more?

 

Though, I'm not and never have really argued for practicality in this hobby, I think it's all about what you WANT to do.

 

Well, your definition of a "defacto standard" doesnt match mine, thats for sure..

 

Rather than write a routine to try and figure out the level of bastardization of a register that was intended by the manufacturer to control other things, I'd prefer to write my software for a common denominator such as the 130XE, and in the event that I NEED more memory, I'll use the extra 8-bit register, which is much easier to detect the presence of, and much easier to implement the use of.

 

True, none of the previous demos and apps will find or use my additional ram.. But look at how few coders have actually utilized a routine to auto-detect which PORTB based ram expansion is installed. (All of the demo scene sites have huge lists defining what actually works on what particular ram-hack.) And even the ones that did, would not detect every possible upgrade out there. Theres too many variations in not only the utilization of PORTB bits, but how they are treated in different states of the machine and/or upgrade logic. Some guys actually went to the extent of adding a routine to allow the user to select their own PORTB useage scheme.. All of this is a wonderful exercise in flexible coding, but it strikes me as a damn shame that it's necessary..

 

 

 

Even if the only thing that EVER gets written for it is my ramdisk handler, the prospect of having a 16meg ramdisk is well worth the trouble... And as I said before, the fact that it simply implements an additional full 8-bit read/write register makes it extremely easy to adapt existing software to take advantage of..

[Shawn Jefferson]

Well, your definition of a "defacto standard" doesnt match mine, thats for sure..

 

I'd always known "de facto" standard to mean something that's in common practice, but isn't necessarily a written standard ("de jure"). In this case, I think that utilizing bits of portb to do ram banking definitely fits the description of "de facto".

 

I'd be interested in your upgrade, I always cringed at doing a SIMM upgrade with all the wires hanging all over the place, even though I have a box of 30-pin 1MB SIMMs I've been saving for that purpose. A plug-in option is so much cleaner!