When the 6522 is held in reset (low), what is the state of all of the port pins at that time? When a 1541 disk drive is held in reset, the LED and motor both turn on. The schematic shows that in order for this to be the case, the port lines would have to be outputs and they would have to be driven high. The schematic (attached) shows ACT (activity LED) connected to an inverter which drives the negative side of the LED. The +5v for the LED is next to the inverted (and current limited) output on connector P6. The MTR output from the VIA goes to an ASIC that inverts the output (/MTR) and that passes through a 7417 buffer to negative side of the motor. The +12v for the motor is next to the /MTR line on connector P5.

It's hard to believe that the port pins would be deliberately set as output and driven high during a reset state. Is this documented somewhere?

If that were true, it would cause contention in some cases, and very high currents during reset. To my disappointment, what I found years ago is that even the CMOS 65c22 (except WDC) port inputs were similar to 74LS, not true high-impedance inputs like you would expect from a CMOS part. When they're not pulled low externally, they naturally pull up to a logic "1". I don't have an easy way to check an NMOS 6522 at the moment, but I tried it again just now on a Rockwell R65C22, and got 1.5mA when I shorted an input port pin to ground, even though they give more than ten times that much current as outputs when trying to pull up into a dead short . WDC's 65c22S has true CMOS inputs on the ports.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Jim, you've perhaps overlooked one of the basic aspects of how TTL inputs work. Their behavior is such that the LED would go on even if the 6522 were entirely disconnected!

Somewhat counter-intuitively, if the input of a TTL chip (such as the 7406 that drives the LED) isn't connected to anything then the input's internal circuitry will pull it up to 3V or so, which is a valid logic high. IOW the input won't drop to zero volts (logic low). For that to occur, an external current path from the input to ground would have to be present. The 6522 fails to provide such a path to ground because the pins are inputs during reset. (Garth correctly notes that some but not all 6522s have i-o port pins with pullups to +5, which is good to know but slightly OT. (If the 6522 pin does have a pullup then it'll just reinforce the TTL gate's already-existing tendency to rise to a logic high. In any case there's no path to ground because reset put the 6522 pin into input mode.)

On the schematic I see the ACT signal originates on PB3 of the 6522 and drives the pin 13 input of the 7406. During reset pin 13 will pull itself high, causing the 7406's pin 12 to go low and illuminate the LED.

(To be clear, TTL chips are those such as 74_ 74S_ 74LS_ etc. -- not 74HC_ 74AC_ etc, which are CMOS. MOS and CMOS chips typically don't have inputs which show this "pull themselves high" behavior. Neither can they be relied upon to drop to zero volts when left unconnected, so watch out! MOS and CMOS chips have extremely high input impedance, and if left unconnected an input can drift either high or low, causing unexpected results.)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Ok, thanks guys. What matters to me from an emualtion stand point is the fact that the port pins are all driven high while in a reset state (by way of an internal pull-up or some other magic). This would cause contention for this to occur (be it an output driver or pull-up resistor). I wonder what the drive current is of the NMOS 6522 version. Garth, if you need one to test I would be happy to send you one. I have seen nothing in any datasheet from any manufacturer that states the pins are actually inputs with pull-up resistors while being held in reset. How was this information obtained?

By the way, the LED and motor do not come on when the 6522 is removed from its socket - unless you started touching the empty socket pins. This is what led me to posting this question. I never considered internal pull-ups.

I have 6522's, but they're too slow to simply drop into my workbench computer. More changes would be needed, and I can't take the time at the moment.

Slightly off-topic, but related, you can see from this diagram of TTL in a 7400 that there are no pull-up resistors, but that the input is naturally high if you don't pull it down:


From my data books, it looks like many of the VIA brands and types (NMOS or CMOS) do actually have a pull-up resistor, and some have no active pull-up at all on port A. I can't believe they did that. Going with WDC's W65C22S will get you a high-impedance input though, with the maximum input leakage current being 10uA, for the bus-holding devices they use.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

If there's the effect of a weak pullup, it might be better to think of that as a default value for an undriven signal, rather than as contention.

I don't deal with non-NMOS chips, and what works for a 'C' model does not usually work with the NMOS version. I am doing a cycle exact emulation of a MOS6502 and dual MOS6522s, including the undocumented opcodes for the CPU (which are valid instructions for most of these in the 65C02) and the shift register bug in the VIAs. I want the reset state to be correct so the virtual hardware (LED, motor, data separator, etc.) operates exactly as it should.

I appreciate everyone's input!

I found some undocumented 6522 behaviour when getting the 6522 emulation correct in jsbeeb (which emulates a BBC Micro with a 2MHz 6502 and two 1MHz 6522s; access to the 1MHz hardware performs cycle stretching in order to sync the clock to 1MHz).

I found that reading from T1-L would not acknowledge the IRQ if the timer was at FFFF (and hence had just triggered the IRQ half a clock previously), causing the interrupt to be taken after the following instruction.

This was in contrast with a write to T1-H at the same moment, which does acknowledge the IRQ immediately after it's generated, meaning the interrupt is never taken.

You might want to try running some tests for this on C64 hardware to make sure that this was not some artifact of the cycle stretching done by the BBC Micro's hardware. I put together some results here showing how BBC Micro hardware responds to a bunch of different test cases.

The first case I mentioned (not acknowledging the IRQ on a read from T1-L when the timer is at FFFF) is like rows 11 and 12. The second case (acknowledging the IRQ as soon as it's generated, causing no IRQ to be taken) is like rows 6 and 7. Note also that there are several cases where the IRQ is taken but the corresponding bit in the IFR is not set.

Hope this is helpful in getting the 6522 emulation spot on!

(Edit: just realised that this is in the wrong thread really... never mind)

Rich, thanks for the interesting info. I will check these cases on real hardware.