Page 3 of 3
Re: 6502/65C02 multiplexing
Posted: Thu Oct 06, 2016 4:36 am
by GARTHWILSON
I see what happened. I took the 74xx32's to be AND gates, because that's how you drew them. The '32 is an OR gate, not an AND. Here's an OR gate:
The input side is curved, the the output comes to a little point, both unlike the AND gate.
Re: 6502/65C02 multiplexing
Posted: Thu Oct 06, 2016 7:11 am
by Klaus2m5
There are different symbol sets for logic gates. The original one was a DIN symbol, yours is the ANSI symbol.
https://en.wikipedia.org/wiki/OR_gate
Re: 6502/65C02 multiplexing
Posted: Thu Oct 06, 2016 5:38 pm
by GARTHWILSON
I've never seen that before. I've been in this for about 35 years, and all along, I thought that DIN symbol was just a wrong way to draw an AND gate! I strongly recommend sticking with the ANSI symbol.
Re: 6502/65C02 multiplexing
Posted: Thu Oct 06, 2016 5:54 pm
by BigDumbDinosaur
I've never seen that before. I've been in this for about 35 years, and all along, I thought that DIN symbol was just a wrong way to draw an AND gate! I strongly recommend sticking with the ANSI symbol.
The DIN symbols (DIN 40700) have been around since at least the mid-1970s but are now considered obsolete. These days. the preferred symbology is the IEC 617-12 derivative, which I personally find confusing and in some cases meaningless. Like Garth, I'm old school and continue to use the "military" symbology (originally MIL-STD-806 and later defined in ANSI/IEEE Std 91-1984) that I've known since around 1966.
Re: 6502/65C02 multiplexing
Posted: Fri Oct 07, 2016 5:12 am
by Tor
I remember learning the DIN symbols as a student, but I've mainly used the ANSI symbols myself. Fortunately those horrible IEC symbols are exceedingly rare. I don't know why the DIN symbols are obsolete and the IEC are not. It should have been the other way around.
Re: 6502/65C02 multiplexing
Posted: Fri Oct 07, 2016 5:17 am
by Klaus2m5
I didn“t say I like it better. However, it is in the standard Eagle libraries so you should be aware.
Remember Hubble, the space telescope? Measuring in inches or cm - you have to be aware or you send scrap metal into orbit.
Re: 6502/65C02 multiplexing
Posted: Fri Oct 07, 2016 6:57 am
by BigDumbDinosaur
Remember Hubble, the space telescope? Measuring in inches or cm - you have to be aware or you send scrap metal into orbit.
...or into the ground.
Air Canada nearly crashed a Boeing 767 in 1983 due to imperial vs. metric conversion errors.
During the fueling of the plane in Montreal, the required fuel load for the trip had to be converted from pounds to liters, as Air Canada 767s were built to the metric system. The conversion was in error and compounding the problem, the plane's flight computer was told that the correct amount of fuel had been loaded. So the pilots unknowingly took off with about half of the required fuel load to make it from Montreal to Edmonton, plus the required reserve. The plane's engines flamed out while cruising at high altitude over northern Ontario, however the pilots were able to deadstick to a rough landing at the old Royal Canadian Air Force base near Gimli, Manitoba. The plane was banged up pretty badly from the landing. but there were only minor injuries to passengers. When investigators arrived they discovered the plane had run out of gas in mid-flight.
Re: 6502/65C02 multiplexing
Posted: Sat Oct 08, 2016 12:08 pm
by kakemoms
I see what happened. I took the 74xx32's to be AND gates, because that's how you drew them. The '32 is an OR gate, not an AND. Here's an OR gate:
(picture)
The input side is curved, the the output comes to a little point, both unlike the AND gate.
Oh I see. For some reason Eagle CAD seems to draw it the way I posted. I will try to change it to make less confusion here.
Anyway, the circuit doesn't work and I am leaning towards that being a timing problem. The actual tested circuit has a 50ns delay between BEL and BER:
Code: Select all
BEL 111100000000001111 (left BE=MBE)
BER 000001111111100000 (right BE)
Without the small delay in switching from one bus to the other, I got bus contention (which I originally thought was the problem). I have tested different writing pulse delays but no luck yet. Basically it should write on the rising edge of WE, but it is not doing so very often.
The first design (which worked better, but still error-prone) used a combined OE signal and put that through a NAND with the CLK on the other input to generate WE. That was stable if I only ran one processor at a time (e.g. no same-cycle access).
At time being I am testing my first CPLD designs (Lattice breakboard) to get a more dynamic logic (read: easy to change). I want to run the two processors at different speeds, so a CPLD helps in that it has its own clock. Once I get some more results I will post it here.