I'm currently pulling the CIS-local code out of DECWAR in aid of installing
it on the DECsystem-1070 (KI-10 #587) running at the museum. It would be
very helpful to (1) talk to someone who programmed in Macro-10 on the CIS
systems, or (2) at least find someone with UUO and programming environment
manuals. (I don't see either CIS or CompuServe on Bitsavers, but I may be
missing something.)
Does anyone reading CCtech/CCtalk want to confess to having experience in
these matters? Privately or publicly?
Thanks,
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.orghttp://www.LivingComputerMuseum.org/
Hi,
I've decided to have a clear out to raise some funds for the school club I
run teaching 7-11 year olds computer programming, electrics and engineering.
So here is what I have looking for a new home:
- Lots of micro-vaxes (pizza box style)
- Lots of microVax chassis (mostly unpopulated with cards)
- Various Apple IIs and Apple II peripherals
- Various terminals
- SMD drives
- BBC micros, Spectrums and ZX81s
- Atari 2600's (woodies, darth vaders and jr's)
- IBM PC/XTs
- Misc PDP-11 parts (a few QBUS chassis, RX50s, TU58s, TK50s, QBUS cards,
UNIBUS cards, PDP-11/44, RD,RF,RZ series hard drives)
- Lots of other assorted items
If anyone is interested in anything or would like to visit and dig through
the stash get in contact.
All the best,
Toby
Here is a first draft. Anything wrong/missing architecturally?
Ethernet Bus Interface Board
2013-12-21 aek
+--------------+
| 4Mx16 BBSRAM |
+------+ | AS6C1616 |
| | +------+-------+
LEDs - + ARM | |
SD -- + uCtl | JTAG +------+-------+
USB -- + +-----------+ | -> Simulated Peripheral Registers
ENET - + +-----------+ FPGA | Bus Monitor / Adr Mapper
SER?-- | | ARM intf | | Bus Master Controler
+------+ +------+-------+
|
+------+-------+
| |
| 5v<->3.3v |
| Bus Buffers |
+--------------+
The entire address space of the host is maintained in the SRAM
ARM performs DMA by placing the data to be transfered where it
will appear on the host. If the local memory is the system memory,
we're done, just clean up the DMA registers. If not the FPGA does DMA
to synchronize local memory with core. 3 cycle data break side effects
will have to be investigated. Does any driver watch the value of ADR,WC
in memory while a DMA is occurring?
Bus transactions are snooped to maintain consistency on the PDP-8
where some core memory is on the Omnibus. This may work OK on small
11's, too but won't be the right thing to do on an 11/70 where
memory transactions occur that are invisible to the Unibus.
It should be possible to simulate all the front panel functions of
an Omnibus machine and to capture all of the state in real time for
all of the major registers from watching Omnibus transactions.
It is also possible to adapt the board to be a dedicated bus analyzer or
soft front panel or peripheral/ memory exerciser for any supported bus
architecture.
All registers and supported peripherals are obviously soft. The configuration
is stored on the SD, along with the FPGA bitstream. Everything should be
reconfigurable through transactions across the Ethernet by updating files on
the SD card.
Battery-backed SRAM was chosen over FRAM because of cost.
I'm not sure if a local serial interface would be that useful other than
for debugging messages.
There are a small number of LEDs hung off of a STP08DP05
Small local SPI NOVRAM for configuration/bitstream storage? SD hot-swap?
Larger local storage? Is performance an issue on Omnibus/Qbus/Unibus CPUs?
They are slow enough busses that they'll saturate in the couple MB/sec range.
Write-through track caching in SRAM?
Block mode on QBus
.. and on and on
Ethernet Peripheral Controller
This is the mirror of the Bus Interface Board. It provides block-level data
that the Bus Interface sends into the computer. In its simplest form, there
is no hardware at all, it is just a simulation running on a computer on the
network. The second simplest is hardware that understands the Ethernet
peripheral command protocol but has a simple enough interface to the physical
device that no FPGA is required. It may also not need any local storage. The
most complicated could look like the Bus Interface Board, with local SRAM and
FPGA. A Diskferret-like forensic disk interface would be an example of this.
I'm looking for a BC80J-20 cable... that's the one that goes from the
RL controller card to the first drive, with a 40 pin header on one end
and that big quick-release connector on the other end.
(I am tired of failures and damage to the rigged ribbon cable/IDC
header I've been using, and now that I'm chasing a fault in my two-
RL02 system, I can't swap drives without taking the cover off to get
to the header connectors inside).
thanks
Charles
Hi!
It's mandatory to connect the printer?
Trying to access the internal drives leads in 013 error (Device not
attached), both for D80 and D40.
I've not opened it yet.
The drives spin, I can hear the noise inserting a disk.
Thanks!
(I'm not subscribed to the list, but I'm passing this along because I
thought it would be of interest to list members.)
The Chicago Transit Authority is auctioning off a whole load of
miscellaneous stuff (including a couple of rail cars!). One of the items
being auctioned is what appears to be an Intel MDS 225 "Blue Box" (4 MHz
8085A system) complete with an MDS 720 disk expansion unit and some sort of
Control Data hard disk.
The specific lot is here:
http://ricklevin.nextlot.com/public/lot/15005194?section=photos
No idea whether any of the hardware is functional.
Bids for the whole lot currently stand at $60. Auction for this lot ends
December 18th (Wednesday), 11:10 AM local time (Central Standard Time).
More info on the auction can be found via the link above.
General news story on the auction:
http://www.dnainfo.com/chicago/20131212/downtown/cta-selling-bus-signs-trai…
Colin Howell
>
>Subject: VT-180 (Robin) EPROM images?
> From: "Robert Armstrong" <bob at jfcl.com>
> Date: Sat, 10 Mar 2007 20:23:04 -0800
> To: <cctech at classiccmp.org>
>
> Does anybody have images of the v2.1 Z-80 firmware for the VT-180 (aka
>Robin) ? At least, I think 2.1 was the last version ever released. They
>should be DEC part numbers 23-017E3-00 and 23-021E3-00.
>
>Thanks,
>Bob Armstrong
I have enough of them laying around I could supply the actual roms. I've
never imaged them as It's easier to replace the code outright.
Curious why are you looking for them?
Allison
I have managed to break one of the wires in the ribbon cable of the DSSI
cabinet kit in my BA213 MicroVAX 3400. It looks like it would be fairly easy
to replace with any 50-way ribbon cable with a male connector and multiple
female connectors. The only problem is the connector to the front panel, the
ribbon is split into two at the external connector and goes into two
separate halves of the back of the connector. Is it possible to open up the
back of the connector without damaging it?
The alternative would be either to find a replacement cable (anyone have
one?) or try to repair the broken wire
Regards
Rob
Over the last year or so, I've been researching the history of the Commodore SuperPET.
I've just pushed a couple of things that I've been working on out to my website, and I thought people here might find them interesting.
First is a narrative about how the SuperPET came to be, and how work on academic software at the University of Waterloo culminated in a collaboration with Commodore. Much of the information stems from new research which I conducted in the UW Archives this past summer.
It also traces the origin and fate of the MICROWAT, a precursor hardware design that had a great deal of influence on the SuperPET. The whole thing can be found here: How the SuperPET came to be
Second, I've written a timeline that documents significant events in the birth, life and decline of the SuperPET. That's here: The Commodore SuperPET: a timeline
Third, one of the more interesting -- and mostly undocumented -- features of the SuperPET was its built-in ability to be a client to a remote fileserver; this relied on an RPC-like facility called HOSTCM that used the serial line as a transport. I have reverse engineered the protocol, and written a program that acts as a HOSTCM fileserver for the SuperPET. It runs on a variety of modern machines, including Mac OS X, FreeBSD and Linux.
Among other things, this means that you can use a SuperPET without an attached diskette drive, and that you can move disk images, files and programs between the SuperPET and modern machines without specialized hardware. You can find the program here: HOSTCM and the protocol documentation here: The HOSTCM protocol
Finally, I've written a couple of utilities that are useful for manipulating archived Commodore disk images for use with my HOSTCM implementation. That can be found here: Utilities for HOSTCM
Oh, and there are some good pictures, too.
If anyone has comments or questions, please let me know.
Cheers,
Rob Ferguson