8085 IO ports

[allison]

On 01/14/2017 08:18 PM, dwight wrote:
> If it is not doing I/O and waiting for something, it is likely waiting for an interrupt.
>
> Dwight
>
>
> ________________________________
> From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Adrian Graham <witchy at binarydinosaurs.co.uk>
> Sent: Saturday, January 14, 2017 12:01:32 PM
> To: Discussion: On-Topic and Off-Topic Posts
> Subject: 8085 IO ports
>
> Hi folks,
>
> STC Executel fun continues and I'm at the point where I'm fairly sure code
> is running but it's stuck in a tight loop waiting for something to happen.
And maybe waiting for a interrupt?

That's what I di when I'm building simple 8085 that interrupt driven. 
Let it loop
doing repetitive stuff if anything, an example is the old days
refreshing Dram.
Then use RSTx.5 to force it into a active do something mode and when done
back to the loop.

A current project for myself has the 8085 runnign a simple multitasking OS
and the loop runs through the task table and every task retruns to the loop.
Interrupts are real time events or priority events that need out of
sequence
attention.  The 8085 makes that fairly simple.

I'd bet the Executel is doing that, refershing display and scanning for
events
with some interrupt driven for out of sequence response.

>
> The 8085A reference tells me a non-memory I/O is signalled by IO/M going
> high while it puts the port number on the address bus (0xE3 to 0xE8 in this
> case), 8 bits on the data bus and sets S0/S1 to be WRITE. If that's the case
> then this machine in its current state doesn't do any non-memory I/O - IO/M
> is the only signal that stays low. It's not a failed CPU since I have 3
> different ones and they all do this.
Correct.  IO/m will only stay high for an IO cycle for all memory cycles
it goes
low (instruction fetch, execute plus memory read or writes ).

IO/m (there is a bar over the m) also goes high during a RST 5.5, 6.5,
7.5 and Trap
if interrupts are enabled along with INTR.
> I've pondered if one of the 3 chips the IO/M signal goes to is pulling it
> down; presumably I can test this by lifting the IO/M pin out of its socket
> then briefly touching a 1Kohm resistor connected to +5V to the 3 inputs and
> watch what the outputs do while the machine is running?
It could be you have a chip with a blown input (stuck low)..   However
doing that
test is rather inconclusive as there is so much other state activity to
track.

> With my little logic analyser on the address bus it's continually active so
> it's not a stuck bit either, at least not at the CPU. I can watch the
> repetitive patterns while the code runs through 3 delay loops then the
> patterns alter while it's off doing....something. All the 4116 RAM chips
> seem to be OK too.
Note during IO the a0-7 is mirrored to A8-15.

Hummm...  4116 dram, that means you have external refresh logic or they are
going cheap and doing refersh on a interrupt (or maybe) timed loop.
> I'm also guessing things would be a lot easier if I had a memory map...
A real schematic is likely a great aid too.

Allison
> Cheers!
>
> --
> Adrian/Witchy
> Binary Dinosaurs creator/curator
> Www.binarydinosaurs.co.uk - the UK's biggest private home computer
> collection?
>
>
>