Rod,
On Thu, Dec 29, 2016 at 8:04 PM, Rod Smallwood
<rodsmallwood52 at btinternet.com> wrote:
> Hi Guys
>
> I have had a quick word with the girls down at the silk screen
> shop.
A couple of years ago I tried to translate the DEC color standards to
RGB based on the colors in the standards on bitsavers. Here is what I
came up with:
http://www.chdickman.com/pdp8/DECcolors/
I think I posted this already.
How have you been doing your color matching? Have you published a
color list for the panels you have made? I am thinking about color
matching for switch handles for example that are in the same colors.
Some enduring standard translation for the colors would be great to
have available in the future.
I never imagined how slippery color was until I tried to do the color
matching from the DEC standards. I had to meet Munsell, Ostwald and
the CHM (Color Harmony Manual, not the Computer History Museum),
before I was done. And Pantone seems to be the Microsoft of color.
-chuck
I've updated my VHDL 1802 core and COSMAC ELF for a newer FPGA, the Xilinx
Artix 7. As usual, the source code in in the github repository:
https://github.com/brouhaha/cosmac/
On the XC7A100T-1FGG484, which is the slowest speed grade, it meets timing
at 62.5 MHz. Since my 1802 core only needs one clock per machine cycle,
versus 8 for the original CDP1802, it runs at the equivalent of a 500 MHz
CDP1802.
I was actually able to run it at 100 MHz (800 MHz equivalent), but that
doesn't meet timing so there's no guarantee that it will work; it is
"overclocking" the FPGA. I can't really imagine any reason to need an 800
MHz equivalent CDP1802. :-)
It has been tested with a few simple test programs and with CamelForth.
The interrupt support and related instructions are still untested.
Eric
> From: Tony Duell
> My first thought is to strip this RA80 (that's why I got it!). This
> will provide me with most of the missing parts
> ...
> Is there any reason to keep the bare, stripped, chassis, or should I
> let it go as scrap metal?
> ...
> Or should I preserve the RA80 as it is, and just use it as patterns for
> the missing bits.
I don't have any problem at all with the concept of stripping the parts you
need off one drive to make the other work. After all, you'd be conserving the
number of complete drives: start with one complete, and one missing some
bits; end with one complete, and one missing some bits.
However, I personally would not dispose of any of the bits, though (except
things which can be easily found, and will continue to be so, like standard
fasteners); once they are gone, they are gone forever.
UNC/UNF parts are easy to source on this side of the pond: I imagine they'd
be easy to find on eBay, or if there's something you can't locate, let me
know, and I can run over to the store and grab it and mail it off.
Noel
> From: Fritz Mueller
> I'll keep an eye out for the interrupt control module.
For your purposes, you could probably get by with an M782 or M7820 (earlier
versions of the M7821); I'm pretty sure they are pin-compatible (the earlier
ones have circuits that aren't quite as good as the one in the M7821).
Noel
> From: Fritz Mueller
> I'd like to track down a an M105 address selector and an M7821 (or
> M7820) interrupt control
These are pretty easy to find on eBait.
Noel
Hi folks:
I've been thinking about trying some PDP-11 interfacing/emulation projects in the new year. I'd like to track down a an M105 address selector and an M7821 (or M7820) interrupt control to keep things simple to start with. Anybody have surplus of these they'd be willing to sell/trade?
Thanks, and Happy New Year, all!
?FritzM.
Hi all --
Got myself a TI-990/189 single-board computer based around the TMS9980
microprocessor (actually, a variant of it, the MP9529, which apparently
differs only in that it has a lower maximum clock and only requires Vdd
of 9.3V or so...)
It was advertised as "it looks like it's working, but who knows" and so
of course it arrived and it's dead. It powers up and nothing appears on
the display, and the CR1-CR4 and SHIFT LEDs are illuminated. No
response whatsoever.
I've spent some time yesterday and today probing the thing and I think
the CPU is dead, but I wanted to run it past the braintrust here in case
anyone has any experience with the 9980...
Here's what I see:
Voltages are all nominal on the +12, +5 and -5 supply; +5 and -5 are
present at the CPU, as is 9.3V for the VDD.
At the CPU:
- CKIN is clocking at the right rate, the phi3 clock generated by the
CPU is also correct.
- IAQ is not pulsing, so the CPU is not fetching instructions
- The Address and Data lines are all zeros with no activity whatsoever
- HOLDA is low, -HOLD is high (so the CPU is not being held)
- READY is high
- MEMEN is low (so no memory accesses are taking place)
- INT0 through INT2 is 010 (which indicates that a LOAD interrupt is
active, more on this later)
I have verified that the POWERGOOD signal is going high after about a
second after power-on, as expected (this causes things on the board to
RESET appropriately). This in turn causes the -LOAD signal from the
Power Up/Reset circuit to go low, which causes INT 1 to go high. (This
is later supposed to be reset, once the CPU's IAQ line clocks after the
first instruction is executed, but since that's dead, well, nothing
happens.)
Based on this, I believe the CPU to be faulty. Anyone have any thoughts
on this?
Given the VDD difference (12V vs 9.3V), I don't think a standard TMS9980
will work; the MP9529 seems to be difficult to source, but it shouldn't
be hard to get 12V to the CPU...
Thanks,
Josh
What happens when a PDP8/e executes an IOT to a non-existent device?
My PDP8/e is skipping when it executes a printer flag test for a
device that is not present.
I tried the following FORTRAN IV program with OS/8 F4 on simh and it
worked fine.
C HELLO WORLD PROGRAM IN FORTRAN IV
C
WRITE(4,100)
100 FORMAT(" HELLOW WORLD!")
END
even with hello spelled wrong.
When I tried it on real hardware it just hung.
It looks like it is stuck in an interrupt loop.
F4 uses interrupts for IO and has its own internal handlers. From the
looks of it, there is an interrupt and it is not getting acknowledged.
When the ISR returns, the interrupt is still there and it just loops.
This is a PDP8/e and the INT BUS lamp is ON. I believe this means that
the interrupt request line on the bus is true. I trace the program and
it enters the ISR and checks a few flags. It finds the line printer
char done flag set and then determines that it was spurious and
returns, ignoring any other device that might be interrupting.
I don't have any printer devices installed, so it is strange that is
skips on the printer char done flag. When there is no device, what
does the IOT do? I would expect a NOP with maybe AC corruption, but
not a skip.
In the ISR, the printer is checked before the TTY and I think the
interrupt is from the TTY.
-chuck
How was the R80 HDA put together at the factory? From reading the printsets,
(R80, RA80, RA81, RA82 -- they all have similar HDA designs), I believe that
the spindle and platters were assembled in the lower half of the 'clamshell'
housing, then the upper part put on and bolted down. Then the positioner/heads
were fitted via the front aperture and bolted in place. Then the head
cables were
plugged into the preamp board on the front cover, this put on the front of the
HDA and fixed with the clips. All in a clean room of course.
Looking at pictures of an HDA without the top cover (search for RA80 HDA
on Google), I wonder how they fitted the positioner without damaging the heads.
There are 2 heads per arm per side on an R80/RA80. There doesn't seem
to be any way to insert a tool to keep them all off the platters. Or was there?
Surely they didn't scrape them over the disk surfaces?
Anyone know? I am not thinking of stripping mine, I am just curious....
-tony
