320k Parallel Port RAM Upgrade for 600XL & 800XL

[reifsnyderb]

5 hours ago, TGB1718 said:

 

Here's a link to what I made

Appreciate it could be done a lot easier these days, but I used what was available back then.

The Ay-3-1015 is not available new.   ?    

[+DjayBee]

Regarding a Centronics port over PBI you could also check @pancio's Viatronics interface:

https://systemembedded.eu/viewtopic.php?f=28&t=48

 

[TGB1718]

Just a slight deviation, but still on the Printer subject, I have one of those SIO->Centronics interfaces and not having any

printers with a Centronics interface these days, I built this using an Arduino Nano.

 

The output from the Nano goes to a Serial Terminal connected to my PC (obviously can't do graphics characters.)

Only reason for the 7473 is that the Nano is a little slow responding to the Strobe from the interface and it was missing

characters, so using the TTL chip sends BUSY via hardware and is reset by the Nano once the data has been read.

 

 

 

[reifsnyderb]

12 minutes ago, TGB1718 said:

Just a slight deviation, but still on the Printer subject, I have one of those SIO->Centronics interfaces and not having any

printers with a Centronics interface these days, I built this using an Arduino Nano.

 

The output from the Nano goes to a Serial Terminal connected to my PC (obviously can't do graphics characters.)

Only reason for the 7473 is that the Nano is a little slow responding to the Strobe from the interface and it was missing

characters, so using the TTL chip sends BUSY via hardware and is reset by the Nano once the data has been read.

 

 

 

Maybe a Raspberry Pi Pico would work, too?  It has programmable PIO.  (Once I figure out how to get a working dev. environment...which is another story.)  Given the rather slow speed of a printer, emulating hardware with micro controllers sounds like a great idea.  People are using the Raspberry Pi Pico to produce a composite TV signal with the programmable PIO.

[TGB1718]

1 hour ago, reifsnyderb said:

Maybe a Raspberry Pi Pico would work, too?  It has programmable PIO.  (Once I figure out how to get a working dev. environment...which is another story.)

I have a couple of Pico's, but built this using an Arduino mainly as it uses 5V inputs, the Pico is 3.3V and is not 5V tolerant.

As the Pico is faster might not need the 7473, but you would have to use either a resistor drop network or voltage shifters

to use the Pico.

 

As for a working environment, I tried Visual Studio Code (what a mess that thing is), every sketch I tried ended up

compiling the complete example set. I couldn't figure out how to create a fresh environment and start over.

 

There is good support using the Arduino IDE which is what I use, once you get past the initial problems getting your first sketch uploaded ?,

after the first one it's a piece of cake, I've still to finish using one for a 1050 track display, there's a thread about doing it, I have it all programmed

and display attached, but need to open one of my 1050's and hook it up

 

[reifsnyderb]

On 5/31/2022 at 10:37 AM, TGB1718 said:

I have a couple of Pico's, but built this using an Arduino mainly as it uses 5V inputs, the Pico is 3.3V and is not 5V tolerant.

As the Pico is faster might not need the 7473, but you would have to use either a resistor drop network or voltage shifters

to use the Pico.

 

As for a working environment, I tried Visual Studio Code (what a mess that thing is), every sketch I tried ended up

compiling the complete example set. I couldn't figure out how to create a fresh environment and start over.

 

There is good support using the Arduino IDE which is what I use, once you get past the initial problems getting your first sketch uploaded ?,

after the first one it's a piece of cake, I've still to finish using one for a 1050 track display, there's a thread about doing it, I have it all programmed

and display attached, but need to open one of my 1050's and hook it up

 

I didn't bother about the Visual Studio Code as I saw the install instructions.  I tried the Linux instructions but one of the scripts didn't run and I didn't get back to it.  The PIO appears to be a great feature but I'd rather be programming it than spending days figuring out how to setup the development enviroment.

 

Were you able to program the PIO with the Arduino IDE?

[TGB1718]

You can program the Pico in the Arduino IDE exactly the same as any other micro-controller, support

is very good now, all the ports are accessible, interrupts work and of course it's dual core and that works too.

 

I managed to read the PIO port directly and it seemed to work fine, I didn't have any success writing directly

to the port, however what I was using it for only required reading, so haven't followed up on trying to

do a port write, I think it's just a little more involved, when I get time I will re-visit it.

[reifsnyderb]

4 hours ago, TGB1718 said:

You can program the Pico in the Arduino IDE exactly the same as any other micro-controller, support

is very good now, all the ports are accessible, interrupts work and of course it's dual core and that works too.

 

I managed to read the PIO port directly and it seemed to work fine, I didn't have any success writing directly

to the port, however what I was using it for only required reading, so haven't followed up on trying to

do a port write, I think it's just a little more involved, when I get time I will re-visit it.

I'll try out PIO programming with the Arduino IDE.  Thanks!

[bandit]

I Think just having your memory alone would be great. Iam sure alot would like it, I would buy one when the XL plug in is ready.

[reifsnyderb]

Boards will be in soon and are in the US.  I might get them tomorrow or Monday.  I'll be testing them shortly afterwards.

[E474]

Hi @reifsnyderb,

 

   I got Visual Studio up and running on Debian Bullseye (64 bit), I just did (in a shell script): 

 

#!/bin/bash
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential git python3-venv python3-distutils wget apt-transport-https cc65
wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > packages.microsoft.gpg
sudo install -o root -g root -m 644 packages.microsoft.gpg /etc/apt/trusted.gpg.d/
sudo sh -c 'echo "deb [arch=amd64,arm64,armhf signed-by=/etc/apt/trusted.gpg.d/packages.microsoft.gpg] https://packages.microsoft.com/repos/code stable main" > /etc/apt/sources.list.d/vscode.list'
rm -f packages.microsoft.gpg
sudo apt update
sudo apt install code

sudo usermod -aG dialout ${USER}

 

Though that also includes installing cc65. I cribbed adding the Visual Studio Code repositories from: https://code.visualstudio.com/docs/setup/linux - which also includes steps for other Linux distributions.

 

This came up in a FujiNet thread: 

 

 

[reifsnyderb]

5 minutes ago, E474 said:

Hi @reifsnyderb,

 

   I got Visual Studio up and running on Debian Bullseye (64 bit), I just did (in a shell script): 

 

#!/bin/bash
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential git python3-venv python3-distutils wget apt-transport-https cc65
wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > packages.microsoft.gpg
sudo install -o root -g root -m 644 packages.microsoft.gpg /etc/apt/trusted.gpg.d/
sudo sh -c 'echo "deb [arch=amd64,arm64,armhf signed-by=/etc/apt/trusted.gpg.d/packages.microsoft.gpg] https://packages.microsoft.com/repos/code stable main" > /etc/apt/sources.list.d/vscode.list'
rm -f packages.microsoft.gpg
sudo apt update
sudo apt install code

sudo usermod -aG dialout ${USER}

 

Though that also includes installing cc65. I cribbed adding the Visual Studio Code repositories from: https://code.visualstudio.com/docs/setup/linux - which also includes steps for other Linux distributions.

 

This came up in a FujiNet thread: 

 

 

Thanks for the update.  When I get back around to it, I am going to go back to trying the Arduino IDE development environment as the code it generates should be rather fast.  Supposedly the PIO compiler is pre-compiled for Windows and should work.  Getting the PIO code to work is important due to it's ability to easily generate composite video output.

 

  

[kenames99]

On 5/29/2022 at 11:44 AM, reifsnyderb said:

Sounds like there would be a lot of complexity in the cabling.  How about I make a version of this that plugs into a 1090 board then other boards could be developed for the 1090 so as to use that for those that would like to do so?

I would second the idea of making it plug into the 1090XL as it is a functional board.

[reifsnyderb]

6 hours ago, kenames99 said:

I would second the idea of making it plug into the 1090XL as it is a functional board.

I've got a board to test delivered today.  Well, actually I've got 3 boards to test.

 

The first board is the 320k board.  I've been working on it most of the day.  There is some sort of odd timing problem whereby if I have a 74F04 chip as the inverter it doesn't work.  But if I use a 74LS04 chip as the inverter it works for a while then evenutally crashes the machine.  I've proven that a 74F04 will work fine without the banking logic.  (I removed the 74F138.)  But when I add the banking logic with a 74F04 the computer immediately goes into self test mode on boot-up even though there shouldn't be any banking.  Self test mode then reports some of the memory failed.  (Possibly in the banking region.)  As the inverter chip has 6 NOT gates on it, the same inverter chip is used in the banking logic as well as the chip enable logic.  My current working theory is that the 74LS04, being a slower chip, works marginally then eventually fails due to a timing problem with the chip enable logic.  The 74F04 might interfere with the flip-flop preset on boot-up in that it's a faster chip and sending a signal to the flip-flop chips at the wrong time.  So, my next plan is to mess around with the timing of the resistor and capacitor that preset the flip flops.  Looking at the schematic, I can't imagine any other reason why the banking circuitry would screw with the main memory when the banking circuitry isn't being used in the first place.  The only other gate on the 74F04 is also used with the banking circuitry and, since there is an AND gate involved, the 74F04's output won't matter unless banking is turned on....which it is not.  If changing the preset timing doesn't work, I'll have to get out the scope and see if I can figure out what is doing what.

 

The second board is a 64k PBI board.  I stripped the 320k board down to 64k, removed the banking circuitry, and ended up with a 2-chip 64k PBI board for the 600xl only.  It uses the 74F04 chip, ran for a couple hours today, and therefore proved the 74F04 works perfectly.  (The 320k board, above, with a 74LS04 would fail within the hour...if not within minutes.  A demo game of M.U.L.E. only ever almost finished once with this chip.)

 

The third board is a 320k board that should, theoretically, work in the 1090XL.  It is very similar to the first board, above.  So, once I get to the bottom of the reason for the first board not working right, I'll put the same fix on this board and see what happens when this board is installed in my 1090XL reproduction board.

 

I'll post some pictures soon....

Edited June 11, 2022 by reifsnyderb

[reifsnyderb]

<sigh>

 

Ok.  I think I am closer to getting to the bottom of why the 320k upgrade isn't working reliably.  Going back to the prototype, it would work for up to an hour then crash.  As I had wires running everywhere I figured they could be the problem and a final board would work fine.  Short term testing was usually great.  After testing it, I bumped a wired and it fell off.  So, I figured there could also be a bad connection.  But it worked well enough that I was pretty confident that the problem was either all those wires or a bad connection.  Now that I've got a "fixed" board in hand the best I can do is to replicate the problem on the prototype.  It works for a while then crashes.  So, after a lot of thought, I think I finally found a good explanation.  So, here goes:

 

The 6502 has an address hold time of 30ns after phi2 (the clock) falls to 0.  So the memory bank needs to be set in this 30ns.  (The write data hold is 60ns after phi2 2 falls.  But with the address hold time being 30ns, my guess is not to rely on the write data hold time.)

 

Currently, the chips that would have be involved in storing the bank, after phi2 falls, are as follows:

 

74F32 / 74F138 / 74F04 or 74LS04 / 74F74 & 74F174

(This is in the order of the "flow" of the circuit in the schematic.  So, the 74F32 gets a signal and sends a signal to the 74F138 which sends a signal to the 74F04, etc.)

 

So, there are basically, 4 layers of chips that need to act in 30 ns.

 

If a 74F04 is used, the minimum and maximum propagation times are as follows:

Note:  The numbers are in the same order as I listed the chips, above.

 

3 + 3.5 + 1 + 2.7 = 10.2 ns

7.5 + 9.5 + 6 + 11 = 34 ns

 

If a 74LS04 is used, the minimum and maximum propagation times are as follows:

3 + 3.5 + 8 + 2.7 = 17.2 ns

7.5 + 9.5 + 22 + 11 = 50 ns

 

So, with the exception of tolerance stacking on the chip propagation times, a 74F04 should work as the average of 10.2 ns and 34 ns is 22ns.   

 

Using a 74LS04, which works for a while then fails, results in anywhere from 17.2ns to 50ns propagation times.  This is an average of 33.6 ns.  Given my results with this chip, I am theorizing the total propagation times are probably just slightly under the address hold time and sometimes exceed the address hold time...resulting in a system crash.

 

Since the 74F04 doesn't work at all with the 320k boards but the 74LS04 does...for a while...at first I didn't understand what the problem was.  After looking further, I think the problem has to do with the clock pulse time on the 74F74 (and 74F174) chips.  They have a clock pulse requirement of at least 4 to 5 ns.  At this time, my belief is that due to the higher speed of the 74F04, the clock pulse is too short.

 

So, this will require more work to get working.

 

On a more positive note, the 64k 600XL PBI upgrade board is working great.  I'll post about it a little later.

 

 

 

 

 

Edited June 12, 2022 by reifsnyderb

[+DrVenkman]

This is one of the (rare) instances that a multi-channel logic analyzer could be of great help in a retrocomputer hardware design. You could see all the logic pulses in real-time and watch for when they get out of sync due to timing tolerances and propagation delays. 

[reifsnyderb]

1 hour ago, DrVenkman said:

This is one of the (rare) instances that a multi-channel logic analyzer could be of great help in a retrocomputer hardware design. You could see all the logic pulses in real-time and watch for when they get out of sync due to timing tolerances and propagation delays. 

Sounds like a good tool to have.  In short-term, I'll see if I can hack the board I have and get it to work more reliably.  

Edited June 12, 2022 by reifsnyderb

[HiassofT]

6 hours ago, reifsnyderb said:

The 6502 has an address hold time of 30ns after phi2 (the clock) falls to 0.  So the memory bank needs to be set in this 30ns.  (The write data hold is 60ns after phi2 2 falls.  But with the address hold time being 30ns, my guess is not to rely on the write data hold time.)

While 6502 would have address hold time Atari messed this up when halting the 6502 and giving Antic bus access. The LS04 buffer in the PHI2 signal makes this even worse.

 

So expect zero or even negative address hold time relative to the PHI2 signal on PBI.

 

BTW: when calculating delays also keep in mind that rise/fall times can be pretty long (esp rise).

 

You are not the first one to hit this infamous Atari "PHi2 issue". An easy countermeasure is to use an LS/HCT123 to generate a shortened PHI2 signal and use that for writes (register on the falling edge).

 

so long,

 

Hias

[reifsnyderb]

5 hours ago, HiassofT said:

While 6502 would have address hold time Atari messed this up when halting the 6502 and giving Antic bus access. The LS04 buffer in the PHI2 signal makes this even worse.

 

So expect zero or even negative address hold time relative to the PHI2 signal on PBI.

 

BTW: when calculating delays also keep in mind that rise/fall times can be pretty long (esp rise).

 

You are not the first one to hit this infamous Atari "PHi2 issue". An easy countermeasure is to use an LS/HCT123 to generate a shortened PHI2 signal and use that for writes (register on the falling edge).

 

so long,

 

Hias

I think you are talking about the 74LS02 buffer between the sally chip and the PBI bus.  But I get the idea.  Yeah, it doesn't help and I didn't consider it.  Looking at the datasheet it would screw up the timing by up to anywhere from 3 to 18 nanoseconds.  Go figure.  This helps to explain why people have reported that swapping the 74LS08 with a 74F08 is a fix for some upgrades.  It's also interesting that Atari used the "raw" PHI2 signal for the delay line only and the buffered PHI2 signal everywhere else.

 

I've experimented with the LS/HCT123 and was completely unable to generate a shortened PHI2 signal.  The oscilloscope showed that the "shortened" PHI2 was exactly the same length as the PHI2 signal and just slightly offset.  Looking through the datasheet I only saw where the LS/HCT123 could lengthen a signal but nothing about shortening it.  Also, according to the datasheet, a signal like PHI2 as an input would keep setting the LS/HCT123 to high while it was high and set it low as soon as PHI2 dropped.  I understand the theory on how that circuit was supposed to work but it wasn't working for me and the datasheet didn't suggest any way it would work to provide a shortened signal.  (I spent the better part of a day working with it without any success and verified that I had it connected correctly multiple times.)  If anyone has a better idea how to generate a shortened PHI2 signal that would be great.

 

The biggest surprise I found was discovering that a 74F04 won't work with the clock pulse input on the 74F74 and 74F174 chips but a 74LS04 will.  That surprise is very unpleasant and I never suspected there would be such a problem.  Quite frankly, I don't have a great way to confirm this but after my experiments it's the only thing that would make sense and the datasheets on the 74_74/74_174 chips seem to confirm this suspicion.  I've confirmed that using a 74F04 on the SRAM chip select works fine and the other places on my board where an inverter was used didn't apply unless the bank was being changed in my experiments...and it wasn't being changed.  I also forced this issue by removing the resistors and capacitors, on the board, and holding the set/reset on the flipflop chips high.  If the 74F04 worked, I think this board would be working perfectly.

 

It's possible for me to remove an OR gate from the decode logic where PHI2 is concerned.  This would improve the timing situation and should be able to be confirmed by a stability improvement if a 74LS04 chip is used on the board.  But it will require an ugly hack with jumper wires.  Looking at my calculations, the timing would be improved by 3 to 7.5 nanoseconds.  It would be ideal, though, to find a way to reduce the number of chips for the the final decode and pulse for the flip flops chips.  Ideally a CPLD would work great for all this but they really are hard to get.   

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Edited June 12, 2022 by reifsnyderb

[HiassofT]

A 74HCT123 with 33pF capacitor and 5k6 resistor is a good starting point, that's what we've been using in various projects (TurboFreezer, The!Cart). Note that exact timing might vary depending on manufacturer and/or batch of the '123, cap tolerance, parasitic board capacitance etc. You might need to tweak the R value a bit to get a signal which has it's falling edge some 20-50ns before the falling edge of PHI2.
 

See eg the Turbo Freezer 2011 schematics (ignore the R, C values and IC number, I've mentioned the correct ones in the errata)

so long,

 

Hias

[reifsnyderb]

32 minutes ago, HiassofT said:

A 74HCT123 with 33pF capacitor and 5k6 resistor is a good starting point, that's what we've been using in various projects (TurboFreezer, The!Cart). Note that exact timing might vary depending on manufacturer and/or batch of the '123, cap tolerance, parasitic board capacitance etc. You might need to tweak the R value a bit to get a signal which has it's falling edge some 20-50ns before the falling edge of PHI2.
 

See eg the Turbo Freezer 2011 schematics (ignore the R, C values and IC number, I've mentioned the correct ones in the errata)

so long,

 

Hias

That's the exact circuit I tried....wired exactly as shown.  The oscilloscope showed it wasn't working.  Changing the R value didn't work, either.  I really don't understand how it's working as the datasheet does not show that it should provide for a short pulse.  The R and C values used match the datasheet perfectly and should work perfectly for that timeframe....if phi2 just sent a short pulse and dropped to zero.  When I tested it, phi2 holding high kept the output high for as long as phi2 was high.  I had 2 probes attached to the oscilloscope and could compare phi2 with output perfectly.  I also checked the connections multiple times to make sure I didn't wire it wrong.  I'd love to put an oscilloscope on a circuit that is working and compare with what I did.

[reifsnyderb]

I need to do some testing but I think I can move 2 gates in the banking circuit such that they are no longer part of the chain of gates triggered on the falling edge of phi2.  With F chips this has the potential to reduce the transition time to under 21 nanoseconds, worst case.  (6.2 ns, best case.)  Given the problems with the 74F74/74F174 chips and the clock rise time I am not sure if I can use a 74F138 chip or not.  If I can use a 74F138 this should fix the timing problem.   

[ivop]

20 hours ago, reifsnyderb said:

When I tested it, phi2 holding high kept the output high for as long as phi2 was high.

That's really weird. I have built the LS123/R/C circuit on a small board and my knock-off 8-channel Saleae definitely shows a shortened Phi2

[reifsnyderb]

28 minutes ago, ivop said:

That's really weird. I have built the LS123/R/C circuit on a small board and my knock-off 8-channel Saleae definitely shows a shortened Phi2

I thought it was weird, too.  I spent a lot of time on it and lost track of how many times I verified the circuit to make sure I didn't wire something wrong.

[ivop]

Extracted the circuit for clarity.

 

NEU (pronounce NOY) is German for NEW.

 

Quote

I thought it was weird, too.  I spent a lot of time on it and lost track of how many times I verified the circuit to make sure I didn't wire something wrong.

Just a wild guess, did you connect pin 9,10 and 11 to GND? With an LS part it shouldn't matter, but with a CMOS part it does. You need to pull down 6(C) and 7(R/C), too, with a CMOS part.

Edited June 13, 2022 by ivop