Anyone got a user manual for the above? Online or willing to place it
online? I have a couple of those, working, and struggling to figure
out how to change the setup. I've got as far holding the setup key,
then ctrl-8 to get it to print the current settings, but can't figure
out how to change baud rates and ports etc.
Thanks
Mike
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
Hi Guys
Happy Thanksgiving to all my US friends on the list.
A nicer more helpful bunch of people I have yet to meet.
It looks like I'm coming over next fall to go the 2016 Chicago vintage show.
I'll be bringing my traveling panel exhibit with me.
Rod (Panelman) Smallwood
Many moons ago I had a small fleet of pdp-11/04s, pulled out of a
research synchrotron.
(well, not *literally* out of the synchrotron, they probably wouldn't
work if they had been...)
They all had disk subsystems made by a company called Baydel; a 19"
rack module, half-height like an 11/04, containing an 8" hard disk and
power supply, hooked up to a quad-size Unibus card. Emulated a bunch
of RK05s. Can't recall the nature of the interface between the card
and the drive.
Over the years I appear to have carelessly and unintentionally traded
or given away ALL the bloody things! Anyone else have one, had one, or
know someone who might? I've Googled and there's a deafening silence,
apart from me asking the same question on Usenet ten years ago!
Mike
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
Here's the opportunity to buy&save batches of DEC flip chip modules.
It must be several thousands, I estimate the total weight of the boxes
to over 100kg.
Most are "red" logic series, but other colors are there too.
Apparently they are plugged from different machine types, maybe even
PDP-10s or -12s.
Of course I'm greedy!
But while we have a PDP-12 and some DECtapes here, this amount is mostly
useless and will occupy much precious space until the end of my days.
So question: Is there any reasonable demand for flip chips in the community?
And more difficult: any hint about the price I can offer?
Thanks for your opinion,
Joerg
Hello,
Interesting, but could you provide a complete link.
>From the short link you gave, I found nothing related ???
---
L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le logiciel antivirus Avast.
https://www.avast.com/antivirus
> For a classic/straightforward programming interface, the Massbus disks (RP04 and successors) are a good choice. That will take you just over 500 MB, if you emulate the layout of the RP07.
Current thinking (at least my current thinking) is RK11 first then
probably RP11, both optionally extended to support Q22 addresses. Also
something we're calling the RQ11 which will be our "native" interface
with variable sized disks with a 32-bit linear block address giving 2TB
disks for those who are willing and able to write their own device
drivers. Finally, most likely the RH11 for some Massbus disks with
22-bit addressing. After that, I'm thinking to call it good and move on
to other projects though I'm certainly willing to talk to anyone who has
a particular disk controller they want to implement.
> From: Toby Thain
> it would be easy to interface to a board exposing such USB features
> *from a separate Linux system* - because of that driver.
Ah, OK - I'm so used to people putting Linux on the embedded processor in
their rice cooker that, not clearly understanding what was being talked
about, I assumed it was wanted to run Linux on the uC.
Still, I guess I don't really see the value in making the QSIC, or some
things plugged into it, 'available' from some other machine. AFAIAC, it's
only a peripheral to the PDP-11.
> I did end up studying MSCP ... in some detail though.
Ah, we'll put you in charge of implementing the MSCP controller emulations,
then! :-) (Those are something I oersonally have no interest in, but I can
see a viable case for doing them.)
Noel
> 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
I recently acquired a small pile of 8" floppy disks which appear to be for IBM 4341 and 3880 hardware:
https://twitter.com/nf6x/status/669240958492372992
They're on my "to be imaged" pile. I don't have any hardware to go with them, and would be happy to trade them away after imaging them. They apparently came from a military surplus commo shelter whose innards were being scrapped out. I don't think that the hardware is still in the shelter owner's hands, and I wouldn't have wanted to acquire it anyway, but I thought it would be fun to try to preserve the contents of the disks he had in there.
Based on the label picture linked to above, do any of you IBM fans know whether the contents of these are likely to be interesting to anybody?
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
Folks,
I've been offered an IBM System/32. Location is close to LA. Condition
appears pretty decent.
If I can't take the offer up, would anyone else be interested?
Thanks
Mike
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
{Catching up, after being on the road all day yesterday... Replies
to quite a few people in this, sorry you'll have to read through it
to find yours, didn't want to inundate the list with 17 replies.}
> From: Jacob Ritort
> Are you on keeping bits and/or status for these projects on github or
> anywhere else that might encourage participation and contribution?
We're going to make it public, but at the moment, it's a bit early for that;
for one thing, we are working with hand-wire-wrapped prototypes, front-ending
a ZTEX FPGA/uC (micro-controller) board, not a PCB card. And the 'software'
(which includes FPGA code, we don't have any code for the uC yet) is in a
very primitive state. We'll probably get a couple of controllers done (RK11,
RP11, probably RL11, qetc) and then turn it loose for people to add others.
> I'd be glad to pitch in if I can.
We we get to the stage of turning it into a production PCB, we are definitely
going to really encourage help for that step - doing PCB layout, etc, is sort
of terra incognita for us both.
> Actually, I (and I bet others) would love to see an up to date wiki
> entry or somesuch listing folks' retro projects like these
Well, we'd need the wiki first! But I hope to have some news on that front
soon - I've located an existing one, and am discussing with the person who
runs it, using it for material from CCTalk.
> From: Henk Gooijen
> Tell us more ... and keep us posted Noel.
Not much more to say, at the moment.
The plan is that it will be a dual QBUS card, with slots for two SD cards,
and also one (or more) USB 2.0 connectors; although it will be possible to
plug in memory sticks (to the USB), the SD cards will probably offer higher
performance. Oh, and one will be able to configure virtual disks on on-board
RAM; the contents won't survive a power cycle, but they will be very high
performance, useful for swapping disks.
We will definitely keep CCTalk posted when there is any news.
> We *love* blinkenlights !!
Why do you think they are in our plan? :-) We love them too! :-)
> if you have a blank front panel this "fills nicely"
Well, like the originals, they will be half-panels (i.e. 5-1/4 inches).
They will not be electrically compatible with the original DEC indicator
panels (we plan on driving them like Guy, with just a clock and data on a
couple of wires, not one wire per light - in fact, I'd like to use a common
connector and electrical spec with Guy's, so they are compatible); making
them electrically compatible would be a _lot_ of work, and I don't see that
it would be worth it.
However, they will be mechanically compatible with the DEC originals; our
plan is that if someone has an original indicator panel PCB (I know at least
one person here does), they could mount it with one of our new production
bezel/inserts (with the light captions on it), and the whole thing will work.
I.e. in the original DEC design, we're just replacing the PCB.
> Heck, why not address (all 22) and data too?
Although 'classic' RP11/etc panels will probably be available (for purists),
we intend to also do 'updated' panels which will drop a lot of lights that
make no sense when you don't have a real disk (e.g. the shift registers) and
replace them with useful lights that the originals don't have (e.g. full
memory address, on the RP11).
> From: Paul Koning
> For a classic/straightforward programming interface, the Massbus disks
> (RP04 and successors) are a good choice. That will take you just over
> 500 MB, if you emulate the layout of the RP07.
We'll probably do those too, but before that, we're thinking of doing an
RP11+, i.e. an RP11 with the cyclinder address extended to 16 bits; i.e
without changing the register format _other than using unused bits_ in the
cyclinder address register. (Very easy for us to do, of course.)
For those with the ability to tweak drivers, that will produce disks with
2^28 blocks, or 2^36 bytes, or 64GB. That's most of a large SD card... :-)
> Sure, you can throw in a microcontroller, but interfacing that is
> likely to take far more gates than doing the mapping in the device
> directly.
Alas, we pretty much have to have a uC; it's pretty much mandator to support
USB. And once you have one, there's a lot of stuff that's easier to do in a
uC, e.g. reading the configuration of the virtual controllers, and
configuring the FPGA to match, etc, etc.
> From: Rich Alderson
> Why bother with the RP11?
Because, for FPGA implementation, it's basically an RK11 with a few tweaks
--> very easy to do! And with the RP11+ variant, it will support up to 65GB
disks.. :-)
> From: Mike Ross
> Because, blinkenlights! :-)
That too! Although there's nothing to stop us doing light panels for
controllers that never had them, e.g. RL11's!
> From: Johnny Billquist
> 22-bit addressing is not possible on the Unibus.
True, but my concept is that the eventual UNIBUS version will include ENABLE
functionality (i.e. mapping boxes to 4MB memory, one for the CPU, and an
11/70-compatible UNIBUS map for DMA devices), and it could therefore _also_
'emulate' a MASSBUS RP11, i.e. an RP11 with an additional 'extended memory
address' like the identical registers on e.g. the MASSBUS RP04. (And yes, I
know no such device ever existed, so unmodified DEC OS's won't support it,
but...).
> Your native interface have the additional problem that in addition to
> requiring people to write their own device driver for any OS usage, it
> will be rather difficult to get booting from it, since that require
> special support.
Right, but since adding another controller on the QSIC will be a trivial
configuration option, we assume no machines will have _only_ an RQ11 (our
aname for the 'native' interface), but rather an RK11 and RQ11, RL11 and RQ11
etc. Boot off the first, only use the second once the OS is running.
> RK11 and RP11, while fairly simple, are also very small devices.
Well, there's always the RP11+! :-)
And the 'RPV21' (again, I know this never existed) will, like the RLV21, have
native 22-bit addressing.
> Massbus is a bit more useful, as it at least gives some larger devices,
> but you need to implement each device.
It's all 'software' (in the FPGA and the uC); so if we (in the community
sense) upgrade the 'software' to support more controllers/disks, all boards
could be upgraded to support them.
Let's get the RK11 and RP11 working to start with, and then we'll figure out
where to go from there.
> However, if you want to write a device driver for a device you want to
> boot from, you need to modify SAV as well, which is *not* documented,
> and very non-trivial. Not recommended for the faint of heart.
Which is why it's probably easier to just _also_ configure a standard
RK11/RP11 whatever, and boot off that. (It's all 'software'! With the
right FPGA load, you could have 127 RK11 controllers! :-)
Noel
I know most of you have or are searching for the real thing.
But for those of you that still don't have what your looking for, the arcade
emulator MAME has now included most old computers in their emulation
program.
I have seen everything from apple computers to vax systems, while
searching for game roms.
Most are still non functioning as of this version but they are working
on making them work.
one that does work is a pdp1.
http://mamedev.org/ emulator
http://www.mameui.info/ windows gui front end
http://retroroms.net most current list of roms in the download
section, free reg required
I have been collecting roms for years for repair of my huge collection
of game board
but this is the first time i have seen the retro computers in the rom sets.
maybe if they are in need of a rom dump for some obscure computer one of
you have
you can contribute to the scene by dumping and sending the rom they are
looking for.
As always happy retro computing.
--
The contents of this e-mail and any attachments are intended solely for the use of the named
addressee(s) and may contain confidential and/or privileged information. Any unauthorized use,
copying, disclosure, or distribution of the contents of this e-mail is strictly prohibited by
the sender and may be unlawful. If you are not the intended recipient, please notify the sender
immediately and delete this e-mail.
>
> Just a hit . . scanning/printing without having to go to kinkos etc....
> to any of you needing something that will
>
> print--- nice photos
> print 11 x 17
> scan a tad larger than 11 x 17
> fax
> reasonable price
> free OCR software
> built in duplex printing
> has a bin sheet feeder too for doc size
>
> get a hp officejet 7612
>
> I got mine on sale for $160
>
> not a speed demon but a helpful device
> it is handy. there are times we need to print something larger than
> legal size for museum displays etc or scan large magazine cover,
> schematics etc... it has worked well.
>
> we use this for pretty much in house use.
>
> patrons needing lots of something scanned we have still have to
> contract with one of our offsite vendors.
> (shoemakers children analogy etc.)
>
> Ed Sharpe archivist for SMECC
>
Are you formatting your outgoing emails like this in retaliation for not
getting [cctech]/[cctalk] in the subject line in order to be able to sort
your incoming AOL mail?
Regards,
Peter Coghlan.
> Otherwise it's the RM05 at 256 Meg, if I remember right. But all those
> disks are also expected to expose the actual geometry of the disk. While
> fairly straight forward, it do expose you to a rather low level
> interface, where you need to do a lot of calculations all the time.
All those old disk controllers expose the disk geometry. I've looked at
it for the specific case of the RK11 and it doesn't look too bad. If it
does turn into a problem, then we'll have a microcontroller on the board
too and I'll punt the calculations to it rather than doing them in the
FPGA. And my third option is to just do the trivial mapping of the
sector/surface/cylinder numbers to LBA and waste space on the flash
device. It's not we're so short of storage space in emulating any
number of RK, RP, or RM class disk packs.
From: Paul Koning
Sent: Monday, November 23, 2015 11:26 AM
>> On Nov 23, 2015, at 1:00 PM, Johnny Billquist <bqt at Update.UU.SE>> wrote:
>> As far as I can tell, disks fall into two groups, as far as massbus control
>> is concerned. The RM02, RM03, RM05, RM80 and RP07 is one group. The RP04,
>> RP05, RP06 is another. A few register addresses between the groups are the
>> same, but the actual register at that address is different. But if I
>> remember right, it's registers that have to do with error recovery, so
>> potentially not something people would care about in emulation anyway. But
>> it still means there are different drivers in the OS for them.
[snip]
>> And of course, you also have the TM02/TM03 and TM78, which have yet again
>> different registers on the massbus.
> Yes. And mixing disk and tape on a massbus is something that I don't think
> was done on PDP-11s. It certainly could have been done, and it was on VMS
> and/or TOPS if I remember right.
Two things.
1) There is not such things as "TOPS". The 2 operating systems for the PDP-10
provided by DEC are Tops-10 and TOPS-20. The only thing they have in common
is the first 4 letters (modulo case) of the names. They share exactly no
code in the monitor ("kernel"), and do not even have the same origins.
Tops-10 started as the monitor on the PDP-6, in 1964, and was in continuous
development until 1988 (and in maintenance until 1993+), while TOPS-20 began
life as the TENEX operating system from BBN c. 1969, licensed for the new
KL-10 processor while that was under development. TOPS-20 v1 appeared in 1975.
BBN developed a run time package for TENEX called PA1050 which handled a
subset of the Tops-10 system calls by merging into user-mode programs and
intercepting them; DEC carried on the same mechanism to allow Tops-10 compilers
and other utilities to run on the new OS while native versions were developed.
2) Having stated all that, Tops-10 does not allow mixing tapes and disks on a
channel, but it does allow mixing disk drive types. TOPS-20 has always
allowed mixing tapes and disks on a channel.
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/
> This is great news, Noel. Are you on keeping bits and/or status for these
> projects on github or anywhere else that might encourage participation and
> contribution? I'd be glad to pitch in if I can. Actually, I (and I bet
> others) would love to see an up to date wiki entry or somesuch listing
> folks' retro projects like these and would be happy to create it if you'd
> provide a couple of pointers.
I have the little code I've written so far in a private git server but
not on github. Eventually the plan is to do something like that but
we're pretty early in the process. Certainly nothing is running yet.
Even though I've set up a git server, I still have to learn how to
actually use git.
However, once we get a prototype doing something interesting, we were
talking about looking around for people interested in helping out.
We'll do a couple disk controllers but if someone wants to add others,
great. Especially if someone wants to add MSCP. We're happy to skip
that one ourselves.
But the real thing we'll want help with is circuit board design and
manufacturing. We can do easy things but I'd really like to use BGA
parts for the FPGA and memory chips so if someone has a handle on that,
we'd like to talk. A I said, our plan was to get a prototype working
before going in search of this kind of assistance. We're using an FPGA
module from ZTEX right now to sidestep the issue.
Is there a wiki out there that holds this kind of information? It seems
like a great idea and I'll put some information together on our project
if there is. Or maybe, now that news is spreading that we're doing
this, it's time to write up a web page describing what we're up to.
-Dave
Trying to build up an IMD floppy disk imaging workstation, i.e. a PC with 3.5, 5 and 8 floppy drives.
The 8 inch drive I have is a Toshiba MKM0142E , dual side, a very late model.
( Datecodes on the ICs range from 1984 to 1991 )
Anyone has a manual for that beast, or maybe just jumpering info ?
thanks Jos
Hi Guys
I'm due at the screen printers on Wednesday.
I've now incorporated what I have gleaned from the loan panel into
the drawing set.
For 8/e panels we now have the following layers to be printed.
_On the front: _
First will be a translucent matte base coat to give a satin finish.
It looks black because of the black layer on the back of the panel.
Then either the Terracotta or the Amber and finally white.
At this point the panel is neither a Type A or Type B .
White only detail in the selector switch area and the dividers between
lamp groups can then be added to give the panel its identity.
There are two small screen separations to allow this to be done.
_On the back:_
The 8/e back side (/f and /m differ I'll explain that later) has a
heavy black layer with clear round areas for the lamps / LEDS to shine
through.
In just the lamp area there's another translucent matte layer. This and
the one on the front act to diffuse the light coming from the lamps/LEDS.
Thats seven layers in total and they have to be dried after each layer
goes on.
Each one needs a silk screen and when being printed registration is
critical.
Its a skilled job and not one I would care to have to do.
More news when I have it.
Rod (Panelman) Smallwood
> As Tom Lehrer not-so-delicately put it "more, more, more! I'm still not
> satisfied ..." :->.
We'll do our best. How about we add indicator panels?
> My thanks to you and Bridgham (who has a second name, perhaps)!
My second name is David but it comes first. I'm just funny that way.
> From: Jay West
> I'm looking for a modern storage ... device for an 11
Aren't we all! :-)
> I think I have seen a few hobbyist projects that were flash based, I
> thought I saw one that was an IDE interface....
I think that was probably Brad Parker's prototype?
> Anyone know of a good project to add some modern storage
Available today, no. But there are a number of projects which will probably
be cranking out UNIBUS DEC controller emulators with modern storage backends.
I gather Guy's MEM11 project will probably eventually spin off a version with
a larger disk, and Bridgham and I are planning on doing a UNIBUS version of
our card once the QBUS version is done. (Actually, ours is planned to include
an ENABLE too, with 4MB of memory, for those of us with 34's, 40's, 45's,
etc.) Any more?
Noel
I'm looking for a modern storage (ie. anywhere from 100mb to "huge") device
for an 11/44. I think I have seen a few hobbyist projects that were flash
based, I thought I saw one that was an IDE interface....
Long story short I've satisfied the purist in me by putting an RL02 on the
machine, but that's just not enough storage for that particular system.
Anyone know of a good project to add some modern storage to get me over the
available storage on the RL02?
J
I have an I/O Selectric device which is badged as, and was originally, an
IBM 2970 Reservation Terminal.
For better or worse, it was one of those bought up in the late 1970s by a
company called 'Western I/O", based out of Scottsdale Arizona. They
converted them for home use. One version used a Motorola 6800 to make a
nifty-sounding terminal with selectable baud rates etc. I appear to have
the 'other' version; a cheap and nasty printer-only conversion with some
form of parallel port.
Anybody else got one? Docs about them? Parts? Schematics? I'd like to get
hold of one of the 'proper' terminal conversion versions... Must be some
squirreled away in garages!
Alternatively, any doc on the original 2970? There's an incredible dearth
of information about what we're once very common devices...
Might not really be old enough for this audience but it's an obscure
enough question! I have an AS/400 9406-S20 - mid 1990s vintage. These
things could have what IBM called an 'Integrated Netfinity Server' -
basically an Intel PC on a board, using space on AS/400 disk etc. Two
such boards work in this machine: the 2852 (Pentium Pro) and 2865
(Pentium II).
Both ran NT, and that's well-documented in a Redbook. Both could also
allegedly run OS/2 and Netware.
it wasn't officially supported I know, but did anyone ever succeed in
shoehorning Linux onto either of these boards? If so, how? Official
support only came with the next iteration of hardware (which my system
can't use), and relied on the 'PC on a board' having USB ports, and
involved the use of a USB floppy drive (!) to complete the Linux
install process!
(I'm at V5R2 btw, and have had NT running on this board)
Mike
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
list of groups please!?! neat! Ed#
In a message dated 11/22/2015 9:05:14 P.M. US Mountain Standard Time,
dave.g4ugm at gmail.com writes:
There are a couple of Yahoo groups for Selectric Typewriters and some have
the docs for the IO selectrics.
On Nov 22, 2015 6:51 PM, "Mike Ross" <tmfdmike at gmail.com> wrote:
> I have an I/O Selectric device which is badged as, and was originally, an
> IBM 2970 Reservation Terminal.
>
> For better or worse, it was one of those bought up in the late 1970s by a
> company called 'Western I/O", based out of Scottsdale Arizona. They
> converted them for home use. One version used a Motorola 6800 to make a
> nifty-sounding terminal with selectable baud rates etc. I appear to have
> the 'other' version; a cheap and nasty printer-only conversion with some
> form of parallel port.
>
> Anybody else got one? Docs about them? Parts? Schematics? I'd like to get
> hold of one of the 'proper' terminal conversion versions... Must be some
> squirreled away in garages!
>
> Alternatively, any doc on the original 2970? There's an incredible dearth
> of information about what we're once very common devices...
>
Hi!
I found an ICL Quattro desktop computer.
It looks in good shape, I had to repair only the PSU.
Powering it up, I see disk activity, but I haven't his (proprietary?)
monitor.
On the back, I see a bunch of serial ports (DCE? DTE?) and a DB15
connector, I guess for monitor/kbd attachment.
I tried to connect a terminal to the serial ports, with null modem and
straight settings, but I had no answers.
Do someone have some infos about the proprietary monitor/kbd port?
Can it be run without the original monitor/kbd system?
Or should I think about it as a... doorstopper? :D
Thanks!
--
Vincenzo (aka Supervinx)
--==ooOoo==--
My computer collection:
http://www.supervinx.com/OnlineMuseum
--==ooOoo==--
You can reach me at:
www.supervinx.comwww.facebook.com/supervinxhttp://www.youtube.com/user/supervinxhttp://www.myspace.com/supervinx
Hello all,
I'm looking for a PDF copy of IBM manual GC26-3792-8. The System
Generation manual for MVS 3.8; the only PDF I found of GC26-3792 is of
the -1 version, which is not particularly helpful.
I found a DjVu of the manual (via this site:
<http://tk3.comlu.com/mvs380/Vintage_Manuals.html>) namely here:
<www.classiccmp.org/softlib/manuals/GC26-3792-8/GC26-3792-8.djvu>
Unfortunately, downloading the DjVu file does nothing (SumatraPDF on
Windows can't render any of the pages, and Evince on Debian 8.2.0 just
ignores the file); the Java applet to view it works... except it
doesn't play nice with my accessibility needs.
So, anyone have a PDF of that manual?
Cheers,
Christian
Stephan, referring to the article in The New York Times, mentions
Amdal, Cray and Wozniak: Pioneers in computing whether large,
super-large or small(micro). Who knows of, in the microcomputing
world, Amdahl and Cray? One wonders!
Happy computing,
Murray :)
Hi all -
As noted in a mail last week, I now have my PDP-11/05 running with working
core (8KW). I had some time last night to try loading in some "real"
software, and I started with the PDP-11 paper-tape BASIC, which I've
successfully loaded into memory (in theory). At this point, it became
clear that there's still an issue or two to iron out in the CPU; BASIC
behaves extremely erratically, spewing random error messages, listing
garbage, and corrupting itself and crashing pretty quickly.
I'd run the memory exerciser MAINDECs previously (and I ran them again for
good measure) and there are no obvious issues with the memory. The system
exerciser diagnostic (ZQKB) passes, but the "11 family instruction
exerciser" (ZQKC) fails after a minute or so at PC=016014.
I have the listing for the diagnostic (though I'm not precisely sure
whether it's exactly the same revision) from here:
http://bitsavers.trailing-edge.com/pdf/dec/pdp11/xxdp/diag_listings/MAINDEC…
The doc is pretty grainy but the code at 016012 doesn't actually seem to
match what I've got in memory (I disabled relocation in the test just to be
sure things didn't get moved around) and there's no failure check at that
particular point in memory either.
I've tried the paper-tape images from Bitsavers as well as the ones on the
XXDP RL02 images floating around out there and they all yield the same
results; I suppose it's possible the CPU is failing in such a way as to
make the test reporting incorrect but it seems more likely that (a) I have
an outdated listing or (b) I'm misinterpreting the results somehow.
Anyone have any experience with this particular diagnostic?
Thanks,
Josh
Oh dear, look at all this COBOL (and DIBOL, too.) This is pretty dry
stuff, folks. But there isn't much out there from this vendor, so
here it is:
http://chiclassiccomp.org/docs/index.php?dir=%2Fcomputing/MCBA
Free to add to your collection, as always.
I have some 9-track tapes that may or may not contain some MCBA
software, as well, which I'll get to someday.
-j
I have a board from a HP 7914 disc drive (07914-60001). No clue how I
obtained it, as I've never owned a 7914 (but did have a hard luck case 7912,
which is long gone). In any case... free for shipping if anyone wants it.
J
Hi Guys
Well the original panel arrived yesterday and revealed one
or two interesting features.
It was from an 8/m but as the underlying programmers console (apart from
the change from bulb to LED) is the same for all of versions I am
making. Its a good example
What it reveals was that they silk screened the panel first then routed
or milled out the openings using the markings as a guide. This is the
source of much complained of chipping and peeling.
This means that they did not have to be too fussy with the placement of
the silk screening in relation to the edges of the blank. Any small
offset would be hidden by the bezel anyway. in addition there is plenty
of tolerance on the key lock - there's provision to adjust its position
on the mounting.
The hole for the select switch is drilled over size (0.38" for a 0.25"
shaft) so more room to move things about
In the spirit of "measure twice and cut once" would all those with
orders please do the following. Take off the selector switch knob.
Remove the bezel and take the old front panel out. Measure from the
bottom edge of the panel to the bottom of the row of switch openings.
Then from the left hand side to the first switch opening. Finally from
the right hand side to the last switch opening.
Please send the three measurements with the type of system its off plus
any part numbers on the back of the panel to me.
Regards
Rod
Just saw this on the rescue list. I *believe* the location would be
North Carolina, US.
E-mail them, not me.
---------- Forwarded message ----------
From: Lenore Ramm via TriLUG <trilug at trilug.org>
Date: Thu, Nov 19, 2015 at 8:20 PM
Subject: [TriLUG] Vintage Hardware (Everything Must Go NOW!)
To: Triangle Linux Users Group General Discussion <trilug at trilug.org>
A friend and former TriLUG member is looking for a new home for the
MicroVAX 3100 and associated hardware. It lacks drives. It needs to be
given away to whomever is willing to take it.
The lot includes the drive-less VAX, one DECserver 300, two DECserver
200/MC, a tape drive, and a few other related bits, as pictured in the
links below. If you are interested, you must meet to pick it up or provide
funds for shipping, before it gets recycled in the next few days.
If you are interested, email me (lenore.ramm at gmail.com))(*NOW, before
it's too late*) and I will provide contact information.
There are pics! http://trilug.org/~eronel/decpics
It may or may not have a pleasing amber display.
Lenore
Just a hit . . scanning/printing without having to go to kinkos etc....
to any of you needing something that will
print--- nice photos
print 11 x 17
scan a tad larger than 11 x 17
fax
reasonable price
free OCR software
built in duplex printing
has a bin sheet feeder too for doc size
get a hp officejet 7612
I got mine on sale for $160
not a speed demon but a helpful device
it is handy. there are times we need to print something larger than
legal size for museum displays etc or scan large magazine cover,
schematics etc... it has worked well.
we use this for pretty much in house use.
patrons needing lots of something scanned we have still have to
contract with one of our offsite vendors.
(shoemakers children analogy etc.)
Ed Sharpe archivist for SMECC
In a message dated 11/20/2015 12:22:50 P.M. US Mountain Standard Tim,
billdegnan at gmail.com writes:
> As usual, while looking for something else I finally happened to find
the
> LA100
> docs and ROMs and I've sent the ROM images to Jonathan separately; the
> print set
> is 11" x 17" and I'll contact Noel off-list regarding scanning.
>
> From: Mike Stein
> I don't think I can scan the print set; IIRC the pages were longer
> than 14".
How much longer? My A3 scanner will take up to 17". I'd be happy to scan them
for you (and return them afterwards) if you send them to me.
(BTW, this offer is open to everyone/anyone - although if I get 23 sets of
prints, please don't expect instant service! Please contact me first.)
Noel
Hello,
By any chance could someone configure the mailing list to add [cctalk]
or [cc] or [cct] into the beginning of the subject line? Not looking to
filter, just not looking to delete messages.
--
Ethan O'Toole