15 Jan
2017
15 Jan
'17
8:59 a.m.
On 01/15/2017 08:02 AM, Adrian Graham wrote:
I've thought of that which is why I'm
chasing down details on the Viewdata
chip and the D8741A which I assume is being used as a keyboard controller.
There are also 3 modules on the phone side which I can't find anything
about, marked "NKT NMC1515", NMC1516 and NMC1517. 8741A is likely
keyboard controller. FYI its the eprom version of 8041A
(the a is important).
That part is easy to dump the EPROM and analyse as its only 1K.
You can use a 8048 disasembler on that, nearly the same part save for
the slave IO structure
and a few instructions.
Also there is no rule that says IO must be IO-mapped its not
uncommon
for 8085 users
to memory map IO just like 6800 and 6502 users as it offers a wider set
of instructions
for reading/writing or bit manipulation.
Ok, it never gets
interrupted then. You would also see /INTA (interrupt acknowledge) trigger.
Do find a copy (its definitely on line) of the 8085 users manual,
september 1978
as that has the best explanations and interface notes along with a detailed
explanation of the RIM/SIM addition plus the interrupt systems behaviour.
As they say its the Rosetta stone for the part. It was popular due to
the
availability of a interrupt structure adequate for small controller like
systems
and very easy to use.
One note on 8085s... they all (never found an exception) have the
"illegal opcodes"
and they are indeed useful but _most_ commercial systems didn't use them.
The vendors all of them sorta came to the conclusion that its a must to
copy
other vendors parts with all warts and weirdness.
So I found last night. It really sounds like the unit
suffered a high voltage transient
(lighting, ESD, power supply
over voltage).
Another oddity, I with very rare exception (ti part) have never seen a
high incidence of
dead CPU chips. When I have it was pretty clear any survivors on the
board were
going to be few. Best example was my NS* system back in 79 took a lightning
hit (bolt to the house antenna into the power distribution). It took
about 300 pieces
of TTL across 12 boards to bring it back to life. The only MOS device
(had a hole in it)
was a 8251A USART to the H19 terminal (also toasted). Z80 was still
good and still
in that system working to this day (along with a 8085A subprocessor).
Sockets on the other hand have caused me no small amount of bedevilment.
If its not machined pin and old its likely trouble.
Ok, blown.... that make what
I said earlier of a ESD incident likely.
Check
the DRAM too.
Indeed!
I'm doing this with absolutely zero documentation other than what
I've drawn up myself and a stack of reference books/datasheets. I did manage
to find the designer of this machine, David Leevers, and at some point he's
going to see what docs he has left though at present he can only think of a
user guide. Anything is a great help with that stuff as likely there were tricks
used.
On 15/01/2017 03:04, "allison" <ajp166 at
verizon.net> wrote:
All my life
with hardware and software or so it would seem. I was a
microprocessor
product engineer at one time so this chip is one I roll hardware and
software off
the top of may head still.
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
Apologies for all the daft sounding questions (this goes to Dwight, Tony and
Chuck too) but historically I'm a high level programmer so getting right
down into silicon level is something I've only been doing for 18 months or
so. I can sit with a reference book and read assembler listings, draw up a
logic flow, watch activity/read voltages on a scope but then there's
applying that to what the hardware is doing too, a fun learning curve. 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? 3 interrupts are in use:
TRAP is hardwired to GND.
INTR is pulled low via a 1kohm resistor.
RST7.5 is clock driven. If my disassembled code is to be believed the first
thing it does after PUSHing PSW, B, D and H onto the stack is a RIM
instruction which reads from SID, this is directly wired to one of the NKT
modules I mentioned, possibly checking for an incoming phone call.
RST6.5 is from the Teletext chip, wired to the video status outputs.
RST5.5 is from the D8741A, again from a pair of status outputs (IBF/OBF)
FYI if you read the manual on the 8085 those MAY be in use as interrupts.
The RIM instruction can read several things one is the state of the SID
pin,
also the state of the RSTx.x pins and the interrupt mask plus the status of
the global interrupt enable.
So its possible to use those pins (4 of them) as inputs without interrupts
on all or none as you can read their state. RST7.4 is also special as
its edge
triggered (and transition activates it and it sets a latch) so unlike
the other
the state of the pin can be a pulse rather than a LEVEL.
So it seems there is a keyboard interrupt and video (scan line) interrupt
plus the RTC (time keeping and ?). You also have phone line events in
there.
FYI the software structure is familiar and likely straight out of the
book for the 8085.
You are preserving cpu status (AC-PSW), BC, DE, HL pairs, then working
on the
interrupt event.
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.
That would make sense so
I'm pondering why IO/m never goes high and why the
teletext chip (and video driver) never generates a video sync which it's
supposed to do. 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. 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.
There's an
MC2342A doing the refresh and that's looking OK now that I've
swapped it. The original chip had no working outputs. 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. If you guys weren't around to put up with my
amateurish questions I'd have
never started work on it and it would've remained just another unloved bit
of kit on a table in a museum like the other 5 that are known to exist.
We try.
I enjoy working with 8048(family), 8085 and z80 have built with them for
decades
and do both HW and SW. Its fun to apply modern software techniques to
old hardware
as often they do it well even if not lighting fast.
Allison
Cheers!