"Nice rack", as they say. I have an HP 7970E and was wondering what to put
it into. That is the right solution... I've seen in pictures that HP also
had some special desk-like looking furniture to put the early 7970's in,
with a slanted panel in which the tape drive would go. Never seen one of
these in the flesh.
Marc
>From: "Jay West" <jwest at classiccmp.org>
>And if you want to follow the build of the 2000/Access IO-rack (which holds
>tape, terminal controller and bulkhead, and disk controller subsystem):
>http://www.ezwind.net/hp2000/IO-Rack/
>J
Thanks to Lyle mentioning Manuals Plus, I acquired all of the docs that they still had
on the Futuredata 2300, which is now up under http://bitsavers.org/pdf/futuredata
If anyone still has a 2300, 01, or 02 I would like to archive the prom and floppies from them.
I've also been working through or rescanning at a higher resolution, 64100/110 docs. Information
on the 64120/64000-UX system would be interesting to find. In addition I've made progress on the
64700A/B. There is very little information on the earlier 64700A on line. Surviving software for
those emulators would be good to find. I did pick up a B3763-14604 CD from 1997 which appears to
have the PC version of the software (and the flash files). We'll see what happens when I try to
get a 68030 pod working on a 64700B that had a 68332 pod on it.
Mike wrote...
----
Someone needs to come up with the hardware equivalent of HPDrive so we don't
need to dedicate an entire Windoze system just to emulate a drive.
----
To which I replied...
----
I am not 100% positive, but I think this was already done [snip]
----
Here is the magic:
http://newton.freehostia.com/hp/
Note that this implementation uses a standard off the shelf dup reg board.
That choice has major pluses, but the downside means you have to write a
driver for any OS you want to use it with (RTE, HP2K, etc.). Maybe it's a
starting point anyways....
J
ANyone have a part like this:
"you might have the item i am looking for (from your vast collection of
parts) which is the RF Shield for the A1200. Looking for only the UPPER
or even UPPER/LOWER."
I don't have Amiga parts, but would like to help this person.
>
> Date: Mon, 19 Jan 2015 21:27:59 -0800
> From: Guy Sotomayor <ggs at shiresoft.com>
> To: cctalk at classiccmp.org
> Subject: MEM11 Status Update
>
> As some of you know I've been working (on and off again) a
> multi-function Unibus board that contains all of the more difficult
> items to allow a PDP-11/20 to run Unix V1 entirely within the CPU
> chassis. Other than the CPU and the RK11-D controller, everything else
> will be on the MEM11 board. Here's the background on what the MEM11 is
> and the current progress.
>
> What's on the board is the following:
>
> * Up to 124KW of non-volatile memory
> * Console Emulator ROM
> * 4 Boot ROMs selected from 32 images on the board
> * 2 DL11 SLUs
> * RF11 controller with non-volatile memory emulating 8 RS11 drives
> * KE11 EAE
> * KW11K
> * KW11L
> * KW11P
> * KW11W
>
>
> TTFN - Guy
>
> ******************
>
I am working on a similar project for the Omnibus. I am connecting a
Microsemi SmartFusion FPGA to the Omnibus, and doing the peripheral
emulation in a combination of the FPGA and Linux running on the ARM
Cortex-M3 hard core in the FPGA. Anything with timing restrictions goes in
the FPGA. Everything else goes in Linux as a combination of a device driver
and an application.
For simplicity, I am starting with programmed I/O devices, with the paper
tape reader/punch first. I should be able to add serial ports, printer
ports, analog I/O, diskettes, card reader, and maybe DECtape. Later I will
add data break (DMA) and add disks and mag tape. I am planning to keep the
disk images in flash, load them into RAM and run from there, and save them
back to flash if the processor is halted.
The MI8E bootloader wiggles the same Omnibus signals as the front panel. I
could have the FPGA do the same, and load any one of a selection of
bootloaders.
I am not adding memory, because a nice 32kW RAM board already exists.
--
Michael Thompson
On 20 January 2015 at 17:38, David Brownlee <abs at absd.org> wrote:
> IIRC there was a bug filed against VMS to the effect that dates past
> 9999 were not supported. Have to be impressed by that belief in future
> engineering :)
There are, or were, some other forward-thinking people out there..
>from Wikipedia:
"St. James's Gate Brewery (Irish: Gr?dlann Gheata Naomh S?amuis) is a
brewery founded in 1759 in Dublin, Ireland, by Arthur Guinness. [..]
The main product of the brewery is Guinness Draught.[..]
Originally leased in 1759 to Arthur Guinness at ?45 per year for 9,000 years"
(So although it looks like our decendants may run out of Guinness
before VMS runs into date problems, no worries, they've since bought
out the originally leased property. But good thinking still.)
-Tor
I am noticing something odd in SimH when sending a 0377 (all ones)
character. It seems to be duplicating the byte. I haven't read anything
regarding this behavior. I'm away from my hardware PDP-8 at the moment, so
I can't confirm that this is not the behavior that I would experience on
the real thing.
Here's how I reproduced it:
test.pal:
*200
CLA OSR
JMS SEND
JMP 200
SEND, 0
6416
6411
JMP .-1
CLA
JMP I SEND
$
pdp8.ini:
at ttix 2222
set ttox0 8b
load test.bin
br 200
d sr 0377
Run 'nc localhost 2222 | od -to1' in a terminal, then 'go 200' and
repeatedly press 'c', seeing how many times it takes to generate a line of
characters in 'od'. Then, 'd sr 0376' and confirm that it takes twice as
many presses, indicating half as many characters being sent per TLS
instruction with the latter.
Can anyone else confirm this for me?
Thanks,
Kyle
I've been attempting to interface with SimH in the least invasive way
possible, by connecting two programs together via a pseudo-TTY created by
socat connected to one of the telnet ports of a TTIX device. Something like
this: TTIX -> telnet port -> socat -> /dev/ttyPDP (pty)
This works fine for the console port. I personally like having minicom
pulled up for the serial terminal but keep the other window cluttered with
SimH backend commands. I have been able to manipulate EDIT.SV with a simple
C program to transfer text files, character by character, which is neat.
I wanted to extend this to a VC8-E emulator, again in the simplest way
possible. I am sending out the X- and Y-coordinates for the point over
TTOX0, but seem to be encountering some problems. I noticed that it likes
to get hung up on a TSF (6411) instruction, causing it to keep looping even
in single-step mode! Assuming everything is buffered, I would be under the
assumption that TSF would almost always skip with a successful device send.
[...]
Step expired, PC: 00313 (IOT 411) \ a lot more of these (~50)
Step expired, PC: 00314 (JMP 313) /
Step expired, PC: 00313 (IOT 411)
Step expired, PC: 00314 (JMP 313)
Step expired, PC: 00313 (IOT 411)
Step expired, PC: 00314 (JMP 313)
Step expired, PC: 00313 (IOT 411)
Step expired, PC: 00315 (IOT 416) <- finally skips!
By the way, I am initializing the device with a CLA; TLS (6416) at the
beginning of the program.
I noticed David Gesswein opened up a somewhat related issue, now marked as
closed, in October 2013. https://github.com/simh/simh/issues/85
Once I'm back to the real hardware, I intend to try it there to verify. I
am running V3.9-0, by the way.
Any insight into what might be holding TSF up would be much appreciated.
Thanks,
Kyle
> From: Henk Gooijen
> but RP11 will never be possible, isn't that MASSBUSS!?
Maybe you're thinking of the RH70, the MASSBUS <-> PDP-11/70 memory bus
interface? But there was also the RH11, a MASSBUS <-> UNIBUS interface, which
supported all the same devices (RP04-6, etc) as the RH70, but plugged into a
UNIBUS. (The two were programming-wise almost identical, the RH70 had an extra
register for the extended memory address bits, plus a 'CSR3'.)
But I was speaking of the RP11, a UNIBUS interface for the RP03 (different
beast from the RH11, although very similar).
Noel