> From: Robert Jarratt
> When the power is OK the output of the inverters is low, so the
> transistors are off, presumably allowing the signals to float high.
> When the power is not OK, the inverters are high, turning on the
> transistors and shorting the signal to ground.
That is correct.
One thing to watch for: in a machine which does not have bus pullups on the
backplane (some do, but many, especially early DEC ones, do not), if you run
it without a CPU card plugged in (e.g. to test the power supply), BPOK/BDCOK
will be at 0V even if the power is OK because there's no pullup to pull it
high (unless driven low).
This may also affect some of the lights, e.g. the 'Power OK' light in some
DEC boxes - it won't come on, even though power is in fact fine, and
working.
Noel
While I look into what is wrong with my H7864, I'd like to use a modern PSU
to power my machine (actually an rtVAX 1000).
I think I would need to deal with the following problems:
1. Finding the right connectors (ideally, I am sure I could rig up
something more temporary).
2. A way to power the fans, which I believe are 15V, perhaps they
would run on 12V as I wouldn't run the machine for long periods anyway, or I
could just use PC fans.
3. Emulate the DC OK and P OK signals, I suspect these would be simple
+5V signals which could perhaps just come from the +5V of the PSU anyway
(unless there is a problem with that).
4. The most difficult bit, I suspect, would be the PSU LTC signal ,
which I believe is some kind of clock. I don't know what the spec of the
signal is, but I will get a scope on a working one to see (NB don't want to
risk a working PSU on this machine in case it was a problem with the machine
itself that caused the first PSU to fail, I don't mind sacrificing a modern
PSU if need be).
Has anyone done this before?
Regards
Rob
Hi there,
I'm working on reverse engineering a radio navigation receiver
(surprisingly not GPS, something else... Datatrak if anyone's heard of
it) for the purpose of either repurposing the hardware or building up
some kind of demo rig.
A lot of my effort at the moment seems to be identifying C Library
functions and naming them. Ideally, I'd like to identify the compiler
and CLib and feed that into the disassembler to eliminate that work.
Does anyone know which 68000 compilers were available in 1993, and which
could produce ROM code? Or a few?
I've looked at Aztec C68K but ruled it out on the basis that the _strlen
library function doesn't match up -- this is the one from the ROM:
_strlen:
movea.l 4(sp), a0
move.l a0, d0
_strlen_l001:
tst.b (a0+)
bne.s _strlen_l001
sub.l a0, d0
not.l d0
rts
Aztec is identical up to the bne, then:
sub.l d0, a0
move.l a0, d0
sub,l #1, d0
rts
Which is one instruction longer... so it's not Aztec.
Other parts of the system apparently used VME-bus modules... so this
wasn't a small operation.
Anyway, whatever compiler this is, it pulls in Motorola's Fast Floating
Point library.
Thanks,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
I have an aftermarket hard drive system for the TRS-80 Color Computer. It includes a Miniscribe 3425 5.25" hard drive and a Xebec S1410 SASI disk controller. This Miniscribe hard drive has a stepper motor positioner, and Miniscribe actually sprang for an optical track 0 sensor... unlike the 3.5" Miniscribe 20M drive in my first Amiga hard drive system, which simply slammed the stepper against a hard stop to find track 0. I'd like to image this drive with the MFM Reader/Emulator card if I can get it to work. Actually getting the whole system working with one of my CoCos would be even cooler, of course. I have no idea what might be on the hard drive; it was an eBay purchase, back when eBay and I were still on speaking terms.
The hard drive is blinking an error code on its LED, reporting that it cannot cover the track 0 sensor. Measuring the sensor pins with a DMM while the drive is powered makes me believe that the optical sensor itself is working correctly. Its output disappears into a Miniscribe-marked, presumably custom IC, so I don't have high hopes of debugging this further within the bounds of my gumption.
Interestingly, the interruptor on the external stepper shaft appears to cover the sensor on the final step against a hard stop, so it's not clear why this drive even needs the sensor.
Does anybody have a donor Miniscribe 3425 available for sale or trade? The heads can be rattling around in drifts of aluminum filings for all I care, as long as the logic board is somewhat likely to be functioning. Or maybe has one sitting around that they might like to loan to me to image for them, and they don't mind if I risk board swaps after making a valiant effort to get the data off their drive for them first?
So far, I've only used my new MFM Reader/Emulator to image and emulate a Tandon TM503 in a Tandy Fifteen Meg Disk System, and it worked wonderfully in that role.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
Hi Guys
Ok our front panels are going into production.
Meeting went well. We finally worked out how they did the matte layer on
the front
It appears to be a transparent or translucent white. Its ink base with
no colour
The effect is like a steamed up window or shower glass panel.
It looks a matt grey colour that transmits light but obscures objects
behind it.
as the panel behind it is black except where the holes are you see a
matt black
and diffused white light from the lamps are. Neat trick!
Rod(Panelman)Smallwood
> From: Phil Budne
>>> allow the board to be connected to a modern computer as a peripheral?
>> Not sure I see the purpose?
> Simulated serial port to MCU "console" and/or simulated q/unibus SLU(s)
Yes, but... what's the point of being able to gain access to SLU's on the QBUS
>from a modern machine? Just plug serial ports into the modern machine. Etc,
etc. If you meant 'a simulated console for the -11 that some other machine can
get to', just run a serial cable from that machine to the real -11 console
line.
(BTW, which expansion of the "MCU" acronym did you have in mind?)
> Simulated ethernet to MCU internal network and/or simulated
> q/unibus NIC
Not sure I entirely follow this?
We had talked about eventually writing code to support a common USB Ethernet
interface, and have the QSIC emulate the Interlan NI2010 etc cards, which
were very nice to program (unlike all the DEC native Ethernet interfaces).
> Block device access to "unmounted" flash partitions
Like I said, plug the storage unit (we don't have any that are physically
built into the QSIC) directly into the other machine.
The QSIC is not intended to provide an SD port for some other kind of machine
that doesn't have a native SD port; you can justq buy an SD carrier that is a
USB device.
Sorry, I'm just not into the whole 'desert topping / floor wax' concept (and
a tip of the hatly hat to Marshall Rose for the phrase).
'Can do something' != 'good idea to do something'!!
> I suppose "host" ports can used to support physical USB dongles of
> various sorts (serial, ethernet), but I guess my orientation is "why
> connect extra hardware that can be simulated?"
Simulated, how? It's not clear that it's easier to do the simulation (via
some complex lash-up) than have the QSIC provide something that looks,
programming-wise, just like the DEC originals.
Although there are no plans to to serial lines. In general, my philosophy is
not to provide things which are still _readily_ available for real - and
serial lines fall into that cateory.
> ability to halt/reset the q/unibus (PDP-11) processor
> (making the MCU into a "front end")
If the LSI-11 console is i) plugged into something else, and has 'halt on
break' enabled, you pretty much already have that.
> If it's possible to make a board that's operable without an MCU
Huh? The QSIC is planned to be a standalone QBUS card - i.e. take a running
QBUS system with CPU, memory, etc, and plug in a QSIC for 'disk' storage.
Or by 'MCU' were you referring to the -11 CPU? Bridgham has at times wanted to
do that, but I'm not enthusiastic - see desert-topping/floor-wax point, plus
my point about 'only doing things that aren't easily available' - and QBUS
PDP-11 CPUs are readily available.
> design the board so that it accepts a processor in "gumstix" or SODIMM
> form factor, and expose connections for USB/ethernet.
More desert-topping/floor-wax.
> Linux has "gadget" support for simulating various flavors of USB
> devices on a 'device' port.
I have zero, none, nada interest in doing a board that can run Linux.
> From: David Bridgham
> It could then halt the processor and examine memory
Not sure about that. I don't know if the CPU processes DMA requests when it's
stopped. You can't use go ahead and use the bus without asking because the
processor is in tight loop issuing DATI's to the console CSR.
Noel
Hi,
a year ago or so an inventory of several thousand DEC flip-chip modules
appeared in the neighbourhood.
"Yesss, my precioussss, it came too me !!!"
But I couldn't acquire them. At least I help selling them now.
The inventory is here:
retrocmp.com/flipshipshop
It was a 2-months-project: most fun was sorting and counting the
modules, then taking the pictures.
A webshop solution seemed the best for online presentation. (Very
interesting, I never did that before)
Functionality of the shop software is good. On the other hand this
project appears a bit too commercial now.
You even should be able to buy online over Paypal, but I'd prefer
personal contact.
Joerg
Hello,
I have some unibus machines that always need some way to interface to
modern disks.
I always dream to make an universal board that could act as disk and/or
tape interface to a modern medium (scsi or cf/sd card), but also ram,
network, I/O, whatever...
It would be very nice to design a system based on fpga + cpu (arm), so you
can load linux on it and avoid the hassle of handling file systems for the
sd card, management and configuration, etc.
The low level part, the access to the bus, address decoding, and all the
parts that need real time reactions could be handled by the fpga.
The good part is that I could really help to design a system like this.
The bad is that it is expensive, specially because you have to use bga
components that need to be mounted by smd assembling machines.
But: there's always the possibility to choose a commercial development
board, and mount it as SOM over a larger board that would include only psu
and bus level translators.
This way could be cheaper and can be mounted by skilled hands...
If there's a number of people that would invest some money on it, to repay
tooling and minimum lot costs for the pcb and components, we could
definitely work together to make it.
Anybody interested?
Andrea
> From: Phil Budne
> Any plans to allow USB "target" (as opposed to "host" -- I dunno if
> those are the correct terms)
'host' and 'device' are the two modes for USB, IIRC.
> to allow the board to be connected to a modern computer as a
> peripheral?
Not sure I see the purpose? Any of the storage devices (SD card, or thumb
drive) can of course be pulled out and plugged into another machine.
> From: Andrea
> there's always the possibility to choose a commercial development
> board, and mount it as SOM over a larger board that would include only
> psu and bus level translators. This way could be cheaper
That's basically what we're doing for the prototypes, except that our
prototype motherboard is wire-wrapped. The mobo (currently) has only i) bus
transceivers, ii) level converters from +5V logic to +3.3V (nobody supports
+5V in any modern FPGA part, and QBUS transceivers are pretty much only
available in +5V - although we'd be happy to be informed otherwise), and iii)
a pair of 64-pin DuPont connectors to a FPGA/uC board from ZTEX.
(We may add more, e.g. when we get to debugging the indicator panels, we'll
probably put the drivers on the prototype motherboard. Etc, etc. That's part
of the reason for going with wire-wrap, it's easy to add stuff like that.)
It is, alas, not that cheap overall. We think the production models, with all
the circuity on a single custom PCB, will be somewhat cheaper. In addition,
you can't really stack the ZTEX boards on another board, and meet the QBUS
inter-board spacing.
Noel
