Eprom switcher
Clare Snyder
clsnyde at ibm.net
Wed Aug 13 12:29:39 GMT 1997
I missed the start of this thread. What are you trying to accomplish? I have
two eproms in the disk controller of my old COCO. They are connected in
parallel, pin for pin, except for the enable pin, which has a simple spdt
switch to select which prom is being accessed. This allowed use of two
different operating systems, RSDOS and ADOS. I likely still have the diagram
in an old Rainbow magazine somewhere.
>Hi,
>I promised to make some suggestions to improve the eprom switcher. Here
>they are.
>The main problem is to make shure that the adress data does not become
>instabil while there is an access to the eprom. The result may be only a
>hickup or even worse. My idea now is to allow changings to the two relevant
>adress lines only when there is no access.
>The parts are a 7474 (double flipflop) and a bunch of or-gatters. Connect
>each two normal adress line to a or-gatter and connect all gatter outputs
>together to the Clock line of the 7474. On the input sides of the 7474 are
>the two switches with their 4.7k pulldown resistors. The outputs of the
>7474 go to the relevant adress lines of the eprom. The preset and reset
>lines are always high.
>My thought is, that when the adress status changes from low to high there
>will soon be an access. At that moment the status of the switches is added
>to the other lines and does what it shall do. I also thought of connecting
>Clock with inverter direct to the active low OE of the eprom, because the
>7474 has a very short delay of around 15ns, but maybe that is a bit to
>late. (Maybe someone wants to test it with a fast osci; i have none) It is
>still important to use bounceless switches (scsi id-selector) and program
>codes that are only different in the table section. If you use totally
>different eprom contents even that wont work.
>Just some thoughts, every improvement welcome. Maybe there is another way
>to get rid of the or-gatters.
>Peter Rueb
>s68558 at stud-mail.uni-wuerzburg.de
>
>
More information about the Diy_efi
mailing list