512k SRAM upgrade V1.3

[wildstar87]

Thanks!  My assumption is that this should work in a 600XL, using both 64Kb and 512Kb SRAM from the 576NUC.  After looking over the schematics for 1088XEL, 600XL, and the 576NUC.  The XEGS MMU, is the functionality the same as the XL MMU?

[Mathy]

Hello Wildstar

 

2 minutes ago, wildstar87 said:

The XEGS MMU, is the functionality the same as the XL MMU?

 

No, they are different.  One of the inputs on one of them is an output on the other.

 

Sincerely

 

Mathy

 

[wildstar87]

Ok thanks, I'll have to investigate some more.

[wildstar87]

I've been looking over all the schematics, and they all do things slightly differently.  I sort of understand what's going on, but is there a handy reference on how the Atari 8 bits address ram?

[Stephen J Carden]

On 12/14/2010 at 4:36 PM, HiassofT said:

I uploaded V1.3 of my 512k SRAM upgrade to my website:

http://www.horus.com/~hias/atari/#sram512k

 

A small update to the GAL logic fixes issues with newer BSI SRAM chips (CE is now gated with PHI0 OR PHI2 instead of just PHI2).

 

so long,

 

Hias

Hi all!

   Check out my Ramdisk upgrade. I have been using this upgrade since 1997. http://www.realdos.net/576kxe battery backed.html

 

Stephen J. Carden

[wildstar87]

On 4/18/2021 at 8:44 AM, mytek said:

For the 576NUC+ version of this extended memory upgrade this is the PLD EMMU code that was used thanks to @tf_hh: 576NUC_512K_EMMU.jed

Uses Microchip/Atmel ATF22V10C-15PU PLD.

 

And here's the 576NUC+ schematic with @tf_hh's implementation (reference page 2): 576NUCplus_schema_only_3-3-2021.pdf

 

Keep in mind that this is an altered version of Hias's circuit and GAL code and is therefore incompatible, but it's one that has been extensively tested and works well.

 

Edit: For @HiassofT's version, here's a link to his website which has links to the GAL jed, GAL source, and schematic (scroll down to see it): https://www.horus.com/~hias/atari/

Edit2: The TL866 Plus will program the ATF22V10C-15PU, but the older MiniPro TL866C will not.

 

Ok if I wanted to use this with a stock MMU and XL OS, would it be possible using the same setup?

[+mytek]

1 hour ago, wildstar87 said:

Ok if I wanted to use this with a stock MMU and XL OS, would it be possible using the same setup?

Should work even better, since PB6 isn't needed by the MMU in an XL (or standard XE).

[wildstar87]

So this is what I've come up with.  At first I couldn't figure out why the double inverters, and how that differed from the 1088XEL scheme, but then I realized it's basically the same circuit, you were just using one chip to handle both the inverter and buffering.  I used a 74LS04 in place of the SN74F04DR, since it had the same symbology, but I will probably end up using the SMD part.  I didn't buffer PH0, since the original circuit is already doing it with the 74LS08, I didn't see the point in buffering it again, not sure if that's recommended or not.  The original HiassofT circuit had a two switch selection, giving 3 different memory configurations, this has been modified in the 576NUC to get a signal from TK-II, and just two modes I believe, and since I wouldn't be using that circuit, I put it back to a physical switch, connected to the Rambo line, I believe this is the equivalent?  How does it look?

576Kb upgrade.pdf

Edited April 26, 2021 by wildstar87

[+mytek]

4 hours ago, wildstar87 said:

So this is what I've come up with.  At first I couldn't figure out why the double inverters, and how that differed from the 1088XEL scheme, but then I realized it's basically the same circuit, you were just using one chip to handle both the inverter and buffering.  I used a 74LS04 in place of the SN74F04DR, since it had the same symbology, but I will probably end up using the SMD part.  I didn't buffer PH0, since the original circuit is already doing it with the 74LS08, I didn't see the point in buffering it again, not sure if that's recommended or not.  The original HiassofT circuit had a two switch selection, giving 3 different memory configurations, this has been modified in the 576NUC to get a signal from TK-II, and just two modes I believe, and since I wouldn't be using that circuit, I put it back to a physical switch, connected to the Rambo line, I believe this is the equivalent?  How does it look?

576Kb upgrade.pdf 66.49 kB · 4 downloads

It looks good. And if you also want the stock 64K mode, you could provide another switch and pull-up resistor on pin 11 of the PLD (both switches off = 64K, same as Hias's ckt). I didn't do that on the NUC because I was limited in the number of I/O pins that were available from the TK-II chip.

 

Make sure to use a 74F04 (or SN74F04DR) and not the 74LS04 you have shown. Because of the double inverters used to form a buffer, you'll definitely need the increased speed of the F04 device.

 

4 hours ago, wildstar87 said:

I didn't buffer PH0, since the original circuit is already doing it with the 74LS08, I didn't see the point in buffering it again, not sure if that's recommended or not.

If you see any timing issues, I recommend changing the 74LS08 to a 74F08 instead. In fact I always recommend doing that whenever any kind of bus connected upgrade is to be installed (e.g., U1MB).

[wildstar87]

15 hours ago, mytek said:

It looks good. And if you also want the stock 64K mode, you could provide another switch and pull-up resistor on pin 11 of the PLD (both switches off = 64K, same as Hias's ckt). I didn't do that on the NUC because I was limited in the number of I/O pins that were available from the TK-II chip.

 

Make sure to use a 74F04 (or SN74F04DR) and not the 74LS04 you have shown. Because of the double inverters used to form a buffer, you'll definitely need the increased speed of the F04 device.

 

If you see any timing issues, I recommend changing the 74LS08 to a 74F08 instead. In fact I always recommend doing that whenever any kind of bus connected upgrade is to be installed (e.g., U1MB).

Many thanks for looking this over.  Yeah I'm going to use the SN74F04DR, I was just too impatient to add the part into Kicad, and the 74F04 was in the default library.  I'll just change to the 74F08 to begin with, to avoid issues, thanks for the advice.  Won't really need to use the original 16k/64k, because well 16k 600xl, bad 64k 800xl, lol..  Now I just have to layout the board and wait for parts.  Is it weird that I'm really excited to do this?

[wildstar87]

I got my TL866II+, and the ATF22V10C, programming finishes fine, but I'm getting an error when I verify. 

 

Pins Detected Passed!

Verify Error!    FUSE bit:44     Buff_val: 1     IC_val: 0

Verify Error!

 

Since this is all new to me, wasn't sure if this was a problem.  I was going to try the vector testing that Hias put in the JED file (I'm trying that initially), but looks like I'm going to have to put it in manually.  The TL866 uses the following values.

0:Input Low

1:Input High

L:Out Low

H:Out High

C:Pulse Input

Z:High impedance OC High or 3S

X:Ignore

G:GND

V:VCC

 

I'm assuming that in the JED file the lines that begin with V are going to be the vector test configuration.  The first line for example:

V0001 XXXXX111111N1HH1HHHLLLLN*

 

Most of it seems self explanatory, but what does the N map to, since the 866 doesn't use that notation?

 

Ok, I think I figured it out, helps when I look at the right chip in the schematic.  The two N are VCC and GND.  Also the program automatically encrypts the chip, which was causing the verify error, once I disabled that, it verified fine.

 

Now I just need to enter all this into the vector test section.  Would have been nice if they had allowed a CSV import/export, instead of a proprietary file.

Edited May 5, 2021 by wildstar87
Figured it out

[wildstar87]

Hias, I'm running into problems with the vector test, on V0025, and ones below that.  The test program is highlighting the same pins in all failures.  I did have some errors that I fixed in some of the lines before that, but after quadruple checking 25, it looks exactly the same as the line in the JED file.  Just wondering if you might know why? Just to be clear, I flashed this with the sram13.jed file, and input the vector tests listed in that file.  I've attach an exported logic file from the Xgpro program that is used with the TL866II+, just in case.

 

sram13.lgc

Edited May 5, 2021 by wildstar87
Attach exported logic file

[HiassofT]

On 5/6/2021 at 12:52 AM, wildstar87 said:

Hias, I'm running into problems with the vector test, on V0025, and ones below that.  The test program is highlighting the same pins in all failures.

sram13.lgc 3.14 kB · 2 downloads

It took me a while to figure it out but I think I know now what's going wrong:

 

You need to change the "X" in the first 5 columns/pins to "0".

 

These are inputs, and "X" in JEDEC test vectors means "use default value" for input pins (on outputs it means "don't care"). The default "X" value is set to "0" in the JED file before the test vectors (with the "X" field in the file):

X0*
V0001 XXXXX111111N1HH1HHHLLLLN*
...

BTW: substituting the "N" VCC/GND pin values with "G" and "V" looks OK to me.

 

so long,

 

Hias

[wildstar87]

This worked thanks much Hias.  I've updated the logic file for anyone who wants this.  This works for the Xgpro software for the TL866II+ so you don't have to put it in manually, which is a pain with the interface, and doesn't allow for a simple CSV import.

 

sram13.lgc

[wildstar87]

So, I've been working on this, on and off.  Having some issues with implementation, but one thing that would help, is if I had test vectors for the 576 NUC EMMU, so I can verify that the GAL is correctly functioning.  It seems that the A14-A18 lines are connected differently, than in the original Hias design.  I'm definitely curious why the difference in connections, but also how to modify the test vectors from the Hias, to the 576 NUC implementation.

[a8isa1]

On 5/7/2021 at 8:37 PM, wildstar87 said:

This worked thanks much Hias.  I've updated the logic file for anyone who wants this.  This works for the Xgpro software for the TL866II+ so you don't have to put it in manually, which is a pain with the interface, and doesn't allow for a simple CSV import.

 

sram13.lgc 3.14 kB · 12 downloads

worked great!  thanks!

 

-SteveS