Does anyone have an extra copy of the Mostek Z80 Microcomputer System
Micro-Reference Manual (a small 30ish page reference booklet, Mostek
publication number MK78516) that they'd be willing to part with? I'd like
to have an original, but a good scan would be the next best thing. There
doesn't appear to be a decent scan of it online. There's a common scan of
it that missing pages, poor registration, etc.
Also looking for the Zilog Z80 DMA Technical Manual (not the data sheet).
The more recent (late 80s through present) Zilog documentation is
absolutely riddled with errors. It looks like it went through several
generations of conversions between typesetting systems, getting worse at
each step.
I'm willing to pay modest prices and postage for those, and for other 70s
and early 80s Z80 family documentation from either Mostek or Zilog, in
order to produce good quality scans.
I still haven't figured out how to get interrupts from the uPD765 FDC in
the Quay. I think they're probably routed via a Z80-PIO input, but no luck
so far.
While the DMA support in the uPD765 is by design optional, they clearly
*really* intended that interrupts be used. The Quay boot ROM just uses a
very long fixed delay after the recal before doing a read. That's
obviously not great if you want good performance.
I tried several unsuccessful approaches to waiting for a recal or seek to
complete before finally noticing that the FDC will reject the "sense
interrupt status" command as illegal if there isn't a pending interrupt.
Now my code issues that command repeatedly until it does not report an
illegal command.
Has anyone found an easier way to use the uPD765 without interrupts?
I'd noticed that one, it looked promising. No mention of support for
the E signals, but it seems likely that they'd available somehow.
Given
your signature, it's interesting that the main target is my Bally
'Doctor Who' pinball machine!
On 3/07/2014 7:28 a.m., The Doctor wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 07/01/2014
09:34 PM, Mike van Bokhoven wrote:
>
>> Now there's a suggestion that
has my attention. I have thought
>> about this before, but I have no
FPGA experience at all, and
>> wouldn't know how to start. If it's just
a matter of taking a a
>> core model,
>
> For what it's worth, there's
one out there right now:
>
>
http://opencores.org/project,6809_6309_compatible_core
>
> I don't know
if it's sufficiently developed to be of use to you (I
> haven't tried to
synthesize it), but it's a place to start.
>
> - --
> The Doctor
[412/724/301/703] [ZS]
>
> PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F
DD89 3BD8 FF2B 807B 17C1
> WWW: https://drwho.virtadpt.net/
>
> "Why
couldn't you put the bunny back in the box?"
Anyone happen to have the schematic for the original SuperBrain's power
supply / I/O board? I thought I'd found it on Bitsavers (see here:
http://bitsavers.trailing-edge.com/pdf/intertec/schematic.pdf, pages 11
and 12) but now that I've sat down to do some debugging the two don't
appear to match (the schematic is dated 1981, so it's likely describing
a later revision than the one in my machine...)
Mine's labeled:
Intertec Data Systems
(c) 1979
Power I/O Board
1424002-04
Rev. 04
Currently the +12V rail is only reading a couple of volts under load and
a schematic'd help trace down the fault. (I will get better at
debugging power supplies, I will...)
Thanks,
- Josh
I am still gathering info on the Sun-1 (or -2 in a -1 box) I posted
about recently. I expect I'll be doing so for some time but I have
gathered some interesting clues as well as historical bits that I will
assemble at some point.
For now, I have a board inventory and photographs for the Multibus
voyeurs out there:
http://silent700.blogspot.com/2014/07/sun-1-board-inventory.html
- jht
Trying to help out some folks on the cbm hackers list read the 6500/1
ROM in the 1520 plotter. It turns out, based on the data sheet, there
is a way to put the CPU in a "test" mode and send opcode data to the
CPU, and we are going to try to to use that to read the contents of the ROM.
The test mode is engaged by placing 10V on the RESET pin.
And, you know, before tonight, I thought I was at least average on
transistor theory and application, but I'm stumped, and I'm hoping
someone can help.
To support 3 voltages on RESET (0,5,10), I placed a 2n3904 with the
collector on the RESET pin, and emitter on ground. base is biased via
10K resistor to an IO pin on an AVR uC I am using the drive the CPU.
That works fine.
TO support putting 10V on the RESET, I built a PNP/NPN pair. PNP has E
on 10V, C on RESET, and B is biased via 10K to C on NPN. B on NPN is
biased via 100K to another IO pin, and E is at GND.
The thought was that driving the IO pin high, the NPN will pull the PNP
base to ground, thus turning on the PNP, and placing 10V on RESET.
And, it works, but it "fades". Over 2ms, RESET slow falls from 10V to
~6V. If I turn the transistor off and then back on, the cycle repeats.
So, I obviously am doing it wrong, but I can't seem to determine where
my theory fails me, and I thought someone on here could help (or suggest
another simple way to support 3 voltages on the RESET pin under SW control.
Jim
--
Jim Brain
brain at jbrain.comwww.jbrain.com
At 01:28 PM 7/6/2014, Mattis Lind wrote:
>When repairing a TU60 drive that had faulty DEC8881 I replaced them with
>DM7439. They were $2.76 each when buying 25 pieces. The original faulty
>chips were marked 7439 on the backside.
By way of confirmation, I have a bunch of (I think Signetics) 8881
chips marked 7439 on the bottom as well.
-Rick