I don't suppose anyone has a copy of the CDC 9429 floppy drive
maintenance manual they'd be willing to scan for me?
I have reason to believe that the CDC 9428 and 9429 are identical
except that the 9429 is jumpered for 80 tracks and the 9428 is
jumpered for 40 tracks... but I'm not 100% sure. I do have a copy of
the 9428 maintenance manual, thanks to Bitsavers, but having the 9429
manual would put my mind at ease lest I follow the alignment
procedures from the 9428 manual and screw something up.
-Seth
--
Seth Morabito
seth at loomcom.com
Just picked up a Decmate 2 and have managed to get a monitor, keyboard and
boot disk (I think) setup for it, but when I attempt to boot it, I'm
getting alternating error codes 17 and 19(on different boot attempts).
I've searched and found some of the startup error codes but not these
particular ones. Anyone know where I could find such a list?
Thanks,
Tom
Has anyone ever worked up a PC parallel port to Facit 4070 paper tape
punch interface?
I found one on a Swedish website. The punch parallel input looks like
it is TTL compatible, but I can't find anything in the documentation
that describes the input voltage specifications.
Chuck
If you care, you might want to check out:
ftp://ftp.hp.com:/pub/alphaserver/firmware
I'm always updating firmware on older alphas and I've noticed this site
has undergone some changes lately. I've also noticed that HP's web sites
have been absolutely trashed for a couple of years now. However, now many
alpha related searches return 0 results on most of their portals. When you
do find something, it's often a dead link. Many of the Tru64 pages are all
a broken link, broken CSS, shambles.
Anyhow, my trust in HP is at an all-time-low (more than I even knew was
possible after I got my whopping $26 dollar settlement for them ripping
folks off on ink cartridges and getting class-action-sued for it).
Unsurprisingly, they can't even run a website anymore, and even the FTP
site seems to be feeling the shake up (directories moving around, things
obviously undergoing some major changes). So, you might want to grab
whatever you need off the post-Fiorina walking corpse of HP before they go
full zombie and eat their own brains and lose everything. There are
patches, firmware etc... many things their management would probably
remove if they were literate enough to know they still had them online in
an undamaged form (folks so often forget about FTP).
-Swift
> From: Mattis Lind
> I'll check all PROM chips on both board sets tomorrow.
Check out the Computer History wiki Web page first; I looked at a couple of
boards, and added all the chip types I could find. DEC used a vast variety,
it seems!
Noel
> From: Mattis Lind
> What about compatibility between different revisions? I.e. Is it
> possible to mix DataParh board and Control board from different
> revisions with different microcode?
Well, I don't recall seeing any mention of compatability in the manuals, but
that is not definitive either way. I had a look at the two versions of the
data path board, and it seems to me that they are basically identical in their
interface and function, so that either version would work with any control
board version.
I looked at the interconnects with i) the other CPU board (on the C-F
connectors), and ii) the front console (through the Berg connector), and as
far as I can see, both boards use the same interconnects. I didn't track down
every last pin, and check them all, but I checked many, many pins, and all
the ones I checked were the same.
The two versions don't seem that different, internally. The PROMs are the
same on the two versions of the data path board, for what that's worth -
which is probably not that much. (The PROMs on the data path board don't
contain any microcode at all; that's all on the control board.)
One major difference is that the register file chips on the older board
(which have tri-state outputs, and use that to do a mux) have been replaced
by different register file chips, and real mux chips; however, the two
versions should work identically. There are differences in the area of the
serial line clock, but those should be immaterial.
There are some other minor differences, but again, it seems like they should
also work identically. So, that's the source of my conclusion that the two
versions of the data path card are functionally identical, and can be
interchanged.
Noel
> From: Steven Malikoff
> I was lucky to find an original 11/05 print set dated 1973. For what
> it's worth, the microcode listing in my doc is Revision B
Do note that a lot of the PROMs on those boards aren't actually 'microcode',
and aren't covered in that listing. For instance, on the M7261 (control)
board, there are 7 which aren't 'microcode' (list drawn from the 11/05
article on the Computer History wiki):
A01A2 = E12 = Bus Request -> Grant processing
A02A2 = E30 = Internal address decode (first stage)
A07A1 = E68 = Internal address decode (second stage)
A09A1 = E69 = Internal address decode (second stage)
A09A2 = E101 = Branch utest service
A13A1 = E90 = Internal interrupt acknowledge
A14A1* = E100 = Console switch control
and 10 which are:
A04A2 = E92 = Next instruction (high bits)
A05A2 = E93 = Processor Status Word control
A07A2* = E95 = Bus control
A10A2 = E103 = Next instruction (low bits)
A11A2 = E104 = ALU operation select
A12A2 = E105 = Branch utest
A13A2 = E106 = Multiplexor control
A14A2 = E107 = Bus control
A15A2 = E94 = ALU control
A16A2 = E96 = Miscellaneous
And I haven't included the 11 PROM chips on the M7260 (Data paths) board,
none of which are 'microcode'. So those 'microcode' listings only cover about
1/3 of the PROM chips in the CPU; so one can't use just the microcode
revision level to tell you what's what.
E.g there are two chips different between the C and E etch levels of the
M7261: A07A2 and A14A1 (marked with a '*' above); one is 'microcode', one
isn't.
BTW, when you say that the microcode listings in your 1973 print set are
"Revision B", are you referring to the "Microprogram Flow", "Microprogram
Symbolic Listing", or "Microprogram Binary Listing", because they can be at
different revision levels (given in the box in the extreme lower right
corner)?
E.g. the ones in the KD11-B prints in the GT40 print set (dated February
1973) are 'B', 'C' and 'C', respectively; the hard-copy set I have (not dated
explicitly, but apparently mid-1972, given the modification date on the
'Index' sheet) has 'B', 'B' and 'B'.
> it is *exactly* the same printout as in the the Bitsavers doc Revision
> C
You mean the July 1976 set, the ones with microcode revision levels (as
above) of 'C', 'E', and 'E', right?
That is M7261 etch revision 'F', which uses quite a few different PROM chips
>from the earlier ones, so I'd be fairly surprised if the microcode was
actually identical. I think you'd have to look at every bit to be sure; the
data on which chips changed, here:
http://gunkies.org/wiki/PDP-11/05#Control_PROMs
would allow anyone who wanted to actually do that to focus in on specific
columns of the microprogram to look for differences.
(In fact, the 'F' etch rev has one less PROM chip than the 'E' etch rev, but
I suspect - i.e. I haven't checked the exact function of each chip on those
etch levels - that it's not a micro-program chip, though: there's one less
32x8 PROM chip, and those are generally used for control functions, the
microprogram chips are all 256x4.)
Noel
Has anyone used any modern hardware to interface with HP-HIL gear? (HIL is Human Interface Link, not to be confused with HP-IL.) I?d like to interface an HP 46085A Control Dial Box <http://www.hpmuseum.net/display_item.php?hw=684> with my Mac via USB.
But before I go any further in this?I?ve already put a bunch of effort into trying to get it to work?I realized I should probably ask here to see if anyone else has done it. Has anyone?
HP-HIL uses what *should* be a pretty basic serial protocol with available docs. (Thanks, Bitsavers!) The only odd things about it are (1) a data rate of 100Kbps (rather than say 115Kbps) and (2) the use of 12/O/1 framing (rather than say two 8/E/1 frames per packet and (3) a 12V supply line for what?s otherwise a TTL-compatible bus.
Getting the actual host interface IC is just about impossible without removing it from existing equipment, and the client interface IC doesn?t really seem like it would act as a host. The weird framing means virtually no common UART will work, and the data rate means something like an Arduino only has 160 cycles/bit to work with.
It looks like I might be looking at either using either an Arduino or a CPLD to implement a 12/O/1 UART to talk to the control dial box, and using a second Arduino to communicate with that (via a parallel interface) to actually implement the USB HID via the builtin HID stack functionality on some models of Arduino.
-- Chris
Dear Experts,
during discussing the Rolms I came accross the following question:
What was the first (Minicomputer) architecture which offered
memory- and IO protection? I'd define the minimum requirements as:
- Existence of a superuser mode (Rolm calls this Executive mode)
- Existence of a user mode (With at least two users, Rolm offers 4)
- In superuser mode, IO and memory protection for each user can be
set up individually.
- Any access violation is trapped and handeled by superuser code.
- Of course commands for mode switching and setting up the
memory and IO ranges must exist.
I have got a real machine (Rolm 1602) having this implemented
and dating from 1975. A document on this "Access Protection Module" as
Rolm calls it also is dated 1975. It consists of a microcode module
which realizes an extension of the 16 bit Nova instruction set and an
additinoal CPU module, taking care of the new modes and supervising
the IO- and memory accesses.
My question is not regarding virtual memory memory, but regarding
protection (IO and memory) to ensure capsulation of indivitual
processes - not necessarily for multi user environments but e.g.
for safety critical applications...
Probably OS/2 in 1987 was one of the first home computer OSes to
support memory protection (how about IO protection?), BSD on some
Digital PDP-* was earlier (1977?) but still after the 1602.
Any hints out there on other "Mini" architectures of that era
having someting similar?
Erik.
> From: Mattis Lind
> Now I am convinced that if I program a new A04A2 PROM the machine
> should behave much better.
Indeed! I have annotated the PROM tables on the Computer History wiki page
with the function of each, and that PROM is the high part of the 'next
microinstruction' field, so if it's bad, the computer will be acting very
strangely indeed! :-)
> The failing chip was yet another NS chip in plastic
Can you see the type? I'd like to add to the page lists of all the alternate
chip types DEC used in place of the Intersil chips specified in the drawings.
>> the 'F' etch rev has one less PROM chip than the 'E' etch rev, but I
>> suspect .. that it's not a micro-program chip, though
My guess was correct; the missing chip is the one I called "Internal
interrupt acknowledge"; it was replaced with a 74154 4->16 demux.
Noel
This one has a failed BCACHE, but I am told it will still boot and run VMS,
albeit slowly. I have not tried this myself, but I have verified that it
boots to the console. It is in a BA42B enclosure (i.e. desktop not
rackmount).
Is there any interest or should I just take out the bits I want from it and
then throw it away?
It is in Manchester, UK. I do occasionally travel to the East Midlands and
to the Reading area though. Not keen on shipping it, but will do so if it
means not throwing it away. The machine is free, any shipping would have to
be paid for of course.
Regards
Rob
I want to read the DROM chip with my programmer, but I can't ID the chip. Does anyone know what kind it is? It is in a PLCC32 package and the label on it is:
369E7
AYOMA
49/95
I am sure at least some of that is DEC stuff, unrelated to the type of chip. However, none of those parts of the label seem to correspond to any EPROM I can find. My programmer's software has an auto detect feature, but that also failed to ID the chip. I don't really want to remove the label if I can avoid it.
The underside is marked
76394-23
Singapore
C4
522 (might be 322)
512X
None of these appear to match anything either.
Any ideas what it might be?
Thanks
Rob
> From: Mattis Lind
> Has anyone dumped the microcode of the PDP-11/05?
> ...
> When tracing the microprogram flow it looks very suspicious. Comparing
> the same sequence with a better working pair reveal a few differences.
> All these can be narrowed down to one single PROM chip.
Josh had an 11/05 that had a uROM fail, and he had to blow a new one (IIRC he
sent in a report, it's in the list archive). I'm not sure if it's the same one
as the one you need, but if his post doesn't give the chip ID, no doubt he can
let us know.
> There are microcode listings in the manual but they need to be treated
> to get into a dump.
Which is exactly what Josh did.
Speaking of which, is there any chance we can get those machine-readable
listings online? I can host them with my other DEC material, and I can also
put them in the Computer History wiki.
Noel
Request for information about a Facit 4070.
Yes, it can be hooked up to a parallel port interface. It takes a single 74LS00 chip to generate the proper signals, and the ACK signals. I did it in a simple jumper wire block (it has a male and female connector along with a jumper field.
At the moment I have lost my documentation, but I have a working unit ready to be dissected to produce the proper diagram (it may take a while). I have connected it to a "real" and a USB parallel port and used direct writes to the parallel port device under Linux with no modification.
Also if you are interested, I have a program that sends out block letters to be punched on the tape (along with leader). The letters are 5x7 and the 8th is the descender for lower case letters.
The various docs for the 4070 are on Bitsavers, and you want to be sure that the "option" board just has jumpers on it (as it comes from the factory).
Al mentioned the 940 so I thought I would fill in the details:
Lichtenberger and Pirtle extended the hardware to include a page map: 14
bits of VA was divided into 3 bits of page # and 11 bits of offset. The 8
pages were held in 2 x 24 bit words divided into a 8 x 6 bit page numbers.
The high order bit of the mapped page number served as the Read Only bit.
This meant that "subsystems" (a.k.a. applications) could be shared between
users.
Additionally, the instruction set was protected against users with specific
prohibition against using the I/O instructions.
This was described in FJCC 1965 with modifications done in 1964.
> From: William Degnan
>> I would need a dump of .. at least A04A2 / E102 on the Control board.
> Can you clarify? Is this a typo?
No, there are two different major versions of the M7261 Control board; see
http://gunkies.org/wiki/PDP-11/05#CPU_board_versions
A04A2 is inded E102 on the later major version of the board; on the earlier
version (prints for that version are in the GT40 prints online, pg. 162 and
on) A04A2 is E92.
Speaking of the two major versions, though, I wonder if the ucode in the two
versions is identical? The uROM chip numbers should give it, (if they are the
same on both versions, albeit in different locations on the board), but I have
yet to check. Does anyone happen to know?
Noel
Before there were books of kids doing thins with computers there was:
The Radio Boys and Girls: Radio,
Telegraph, Telephone and Wireless
Adventures for Juvenile Readers,
1890-1945 - A View Though Literature
By Mike Adams
A Review By Ed Sharpe Director and Lead Archivist for Southwest Museum
of Engineering Communications and Computation
Glendale Daily Planet / KKAT-IPTV
Read At
http://glendaledailyplanet.com/the-radio-boys-and-girls-radio-telegraph-tele
phone-and-wireless-adventu-p570-154.htm
Has anyone dumped the microcode of the PDP-11/05?
I am looking into a CPU board pair that are not behaving that well. The
only switch that does anything is the START switch. The rest is doing
nothing. The CPU clock is stopped.
When tracing the microprogram flow it looks very suspicious. Comparing the
same sequence with a better working pair reveal a few differences. All
these can be narrowed down to one single PROM chip.
It doesn't look like it is something else that is wire-ored onto the micor
address bus since the enable signals for all those are inactive. And one
signal is already low so wire-ORing would not change it.
I would need a dump of the chips or at least A04A2 / E102 on the Control
board. There are microcode listings in the manual but they need to be
treated to get into a dump. So if someone already have a dump that would be
highly appreciated.
/Mattis
fido news when he became editor and they are lamenting the Internet
taking away from fido net....
https://gopherproxy.meulie.net/gopher.meulie.net/0/fidonews/2002/fido1902.nw
s
In a message dated 4/30/2016 7:43:59 P.M. Mountain Standard Time,
geneb at deltasoft.com writes:
On Sun, 1 May 2016, Tomasz Rola wrote:
> On Wed, Apr 27, 2016 at 10:07:34AM -0700, geneb wrote:
>> On Wed, 27 Apr 2016, Sean Conner wrote:
>>
> [...]
>>> Just look into the political machinations of what was known as FidoNet
to
>>> see how this could end up.
>>>
>> What IS known as FidoNet (1:138/142 here. :) ) and it's still a
>> political shit-show, mostly due to people from Zone 2. *sigh*
>
> Pardon my ignorant question but is there a place on the net where I
> could read some more about it? Or maybe it is short enough to explain
> here?
>
Books could be written about it unfortunately, One of the more annoying
aspects is Bjorn Felten, the current editor of FidoNews - he's refused
repeated requests to pass on his editor duties for various reasons and
he's refused - for at least the last 10 years. Find a telnetable BBS
that's a member of FidoNet and start reading the FidoNews echo for a taste
of the insanity. The Fido Sysop (FNSYSOP) is also a pretty deranged
place.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
Are there any archived issues of _Processor_ from the 80's or early 90's, online anywhere?
I seem to recall it went through at least one major printing format change (from newsprint to cheap bound magazine or the other way around).
It sometimes had articles but was mostly ads from second-hand minicomputer vendors. Most of what I remember was DEC-aftermarket of course, but there was also overlap with DG, IBM aftermarket, various office machines, and later PC-clones and Sun stuff.
I just received from S&H a PDF copy of the TSX 6.50 Release Notes - and
Jay has posted it to the http://tsxplus.classiccmp.org website.
Lots of interesting/helpful information for all you TSX-Plus buffs...
Cheers,
Lyle
--
73 AF6WS
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
> From: Erik Baigar
> very interesting reading
If you want to see a great example of why it was important, check out the
so-called 'Berlin Tunnel':
https://en.wikipedia.org/wiki/Operation_Goldhttp://www.fas.org/irp/cia/product/tunnel-200702.pdf
Some of the traffic that was intercepted was teletype traffic - which had
been encrypted. However, the equipment that connected the gear to the line
allowed a tiny electronic whisper of the original plain-text onto the line,
along with the encrypted form, and it was possible to read the plaintext off
the line with suitable gear.
Noel
> From: Erik Baigar
>> as was coming up with something that could be both EMP-survivable and
>> TEMPEST-worthy.
> TEMPEST?
A set of standards for allowed levels of emissions (in particular,
electro-magnetic radiation) from communication/computing gear, intended to
prevent listening to the activity of that gear:
https://en.wikipedia.org/wiki/Tempest_(codename)
Noel
At 11:24 PM 5/4/2016, Andy Holt wrote:
>Could someone with access to the OED please check up the first use of the term "minicomputer"
I am not the OED, but when I first saw the TX-0 and the PDP-1 at MIT in late 1964 or early 1965 I believe that I heard the term minicomputer applied to them. Certainly when I next saw them in the summer of 1967 both were being called minicomputers by the staff there.
Dale H. Cook, Roanoke/Lynchburg, VA
Osborne 1 / Kaypro 4-84 / Kaypro 1 / Amstrad PPC-640
http://plymouthcolony.net/starcity/radios/index.html
> From: Erik Baigar
> I wanted to have a computer using core memory and so I bought a black
> box from the Tornado aircraft which contained core. This started a 10
> year yourney of analyzing it, decyphering the command set and building
> tools to program it. ... I have a project page on this:
> http://www.baigar.de/TornadoComputerUnit/index.html
I am absolutely, completely, blown away. This has got to be one of the most
amazing projects I have ever come across. I'm utterly awed by the work you
did to reverse engineer this thing.
Everyone should check out this site - especially the detailed time-line
Noel
On Tue, May 3, 2016 at 10:14 AM, Mike Stein <mhs.stein at gmail.com> wrote:
> What's the best commonly available solvent for cleaning the rubber goo that used to be pressure
> rollers, belts, feet etc.?
On a similar note, does any have a solution to firm up rubber that is
just starting to gooify?
I have some joystick feet that are just starting to get sticky.
--
--
tim lindner
"Proper User Policy apparently means Simon Says."
I was skimming the Wikipedia article for tsx-plus, some of it seemed off to
me. Anyone know the facts for sure?
1) They suggest tsxplus generally didn't support more than 8 users
well. At my high school, we had 16 users on it constantly and it seemed to
perform very well. Anyone have experience along those lines?
2) They say LEX-11 (wordprocessing) was included. I don't believe so.
3) They say a spreadsheet program from Saturn Software was included. I
don't think so. Saturn had a wordprocessor, but it was a chargeable product
and I don't think S&H distributed it.
4) They say the latest version of TSX-Plus has TCP/IP support. That's
not true, at least not built in. There was a TCP/IP stack done by a 3rd
party (actually, think it was a person that ported one and put it in a
public contributed library) but that wasn't "included" by S&H.
Do I have those things wrong?
J
Reminds me of a challenge I had in the early 80's The place I worked
made IC test and evaluation systems, starting price in 1980 was around
$300K and many where close to $1.5 million. This one was for IBM. They
were designing a 288K bit ram and one thing they wanted was to be able
to 'see' failed bits as parameters such as supply voltage were
changed. If you looked at the die it was 9 'squares' of i think 128 x
256 ( i think that was the size) cell or bits. The 9 th was for
parity. The memory was read by the system and a 0 or 1 was stored in a
buffer in the system. The system was run by a PDP11/44 the display was
a Tektronix GMA125 with option 42/43. The GMA 125 was the OEM display
used in the 4116, a 25" DVST terminal. Option 42/43 was feed from a
DR11. The 42/43 could be driven in Tek 401x format (that's the same
you still see today when you put your X11 display into Tek mode) which
had a point plotting set of commands.
So one had to read in a loop this external memory which came back in
some long forgotten 16 bits per something mode, calculate the position
of the 'bit' which was in memory block x and position x and y in each
block and either display a dot or plus or something at the respective
location on the CRT. Doing it all in some time IBM wanted it done in
.. loops within loops within loops and finally a test for 1 or 0 and
out the DR11W.
The only way I could get the code to meet IBM speed requirement was to
do the unthinkable. Upon start the inner most work that was test for
'display if zero' or display if one' was modified to be branch of true
or branch if false.
Sometimes you just have to violate all the rules. Other fun things
were using shifting bits and using indexing for some of the coordinate
translations.
oh well when every instruction time made a difference.
it was challenging but fun
-pete
On Wed, May 4, 2016 at 9:56 AM, Bill Sudbrink <wh.sudbrink at verizon.net> wrote:
> I took a peek at the access logs for the Cromemco Dazzler
> files that I recently put up on my web server. I'm
> gratified to see that a lot of people are taking advantage
> of the availability of these documents, that have not
> recently (if ever) been easily available on the web. I
> also see that a lot of people took the Dazzlemation HEX
> file and the Magenta Martini paper tape image, presumably
> to run on Udo Monk's great Windows Cromemco Z1 simulator.
>
> Also, thanks to everyone that generated pdf files for me!
>
> One thing I noticed is that not many people looked at the
> disassembly of Dazzlemation. If you are an 8080 or Z80
> programmer (or any 8-bitter for that matter) I really
> recommend that you take a look, it's a real treat. I'm
> reliably informed that Mr. Dompier hand wrote that program
> LITERALLY (hand, pencil, paper), no editor, no assembler.
> He then toggled it in (or maybe raw keyed it in with a
> primitive ROM monitor) and went through a few iterations of:
>
> 1) store to paper tape
> 2) modify in memory
> 3) test
> 4) go to 1
>
> It's neat to see some of the "tricks" he used and also the
> level of sophistication of the code. It does a lot of
> stuff in not a lot of bytes. Also, here and there, in
> "dead" areas, you can also see the debris of ideas that he
> started and then abandoned.
>
> Bill S.
>
>
>
I took a peek at the access logs for the Cromemco Dazzler
files that I recently put up on my web server. I'm
gratified to see that a lot of people are taking advantage
of the availability of these documents, that have not
recently (if ever) been easily available on the web. I
also see that a lot of people took the Dazzlemation HEX
file and the Magenta Martini paper tape image, presumably
to run on Udo Monk's great Windows Cromemco Z1 simulator.
Also, thanks to everyone that generated pdf files for me!
One thing I noticed is that not many people looked at the
disassembly of Dazzlemation. If you are an 8080 or Z80
programmer (or any 8-bitter for that matter) I really
recommend that you take a look, it's a real treat. I'm
reliably informed that Mr. Dompier hand wrote that program
LITERALLY (hand, pencil, paper), no editor, no assembler.
He then toggled it in (or maybe raw keyed it in with a
primitive ROM monitor) and went through a few iterations of:
1) store to paper tape
2) modify in memory
3) test
4) go to 1
It's neat to see some of the "tricks" he used and also the
level of sophistication of the code. It does a lot of
stuff in not a lot of bytes. Also, here and there, in
"dead" areas, you can also see the debris of ideas that he
started and then abandoned.
Bill S.
Back in the early 90's I remember that many times I'd see a print
advertisement for a Video Toaster or a new genlock card, they'd say things
like "features you'd have to pay thousands for in a professional paintbox
or titler!" I always wondered what they were talking about, since I'd
never seen how broadcast was done back then (and still don't know). So,
I'm really talking about the tech of the 80's (since that's what the
marketing folks were referring to, I assume).
Here's what I could find that I'm speculating were the "competition" of
the time:
The Quantel Paintbox:
https://en.wikipedia.org/wiki/Quantel_Paintbox
Superpaint running on a DG Nova 800
https://en.wikipedia.org/wiki/Superpaint
The Bosch FGS 4000
https://www.youtube.com/watch?v=9oyGaEu7D7s
These are about the only ones I could find. Does anyone know of any
others?
Also, here are my favorite paint and 2D animation programs of yore. If you
guys have others that you loved and remember, what were they?
DOS
1. Deluxe Paint II Enhanced
2. PC Paintbrush
3. Autodesk Animator
4. Paul Mace's GRASP
5. Deluxe Paint Animation
Amiga
1. Photogenics
2. Photon Paint
3. TVPaint
4. Brilliance
5. Disney Animation Studio
Sorry, I didn't use the Mac enough to form any favorites, though I did
love Fractal Design Painter (now Corel Painter).
-Swift
> I have a Visual Basic 4 application that I need to run on modern 64-bit
> hardware I can do this in a VM, but I really need this VM to be wicked
> small, like under a gig. The smallest XP VM I?ve seen is 600MB (which
> might
> be good) but XP is becoming very hard to source these days.
VB4 was a bridge between 16-bit Windows 3.1 applications and 32-bit
everything later (such as the DOS-based Win-95, -98, and -ME, and all of the
NT-based operating systems, which is everything else through Win-10 64-bit).
As such, the package included both a 16-bit an 32-bit compiler. If your
application was compiled using the 16-bit version, you're pretty much stuck
with XP-32 or earlier (in a VM, if necessary), as it will automatically
spawn a 16-bit virtual environment (ntvdm.exe) to run the 16-bit
applications. Win7 and beyond, and all 64-bit versions, do not support this
feature (I supported a VB3 application for 20 years; Win7 was what finally
broke it for good.)
If it was compiled to 32-bit, then you should be pretty much good to go; you
may run into a few insurmountable problems with some now unsupported OCX's.
Other than those, all of the 32-bit code should run fine on anything
current.
If you have the source, you're also in pretty good shape. VB4 is very easy
to port to VB6; there were almost no backward-incompatible features of the
later Visual Basic classic languages. Find an old copy of VB6 SP6,
re-compile it (perhaps replacing some of the failed OCXs with others that
will work - a common one was DBGrid, which is quite easy to replace with
FlexGrid), and you're golden. I currently support just such an application,
and although the development environment requires a couple of tricks to get
working smoothly, the compiled application works just fine on Win10-64.
Drop me a note off-line if you'd like any additional or more specific help
with this; I have a reasonable amount of experience with just this problem.
Of course, there are always older versions of Wine...
~~
Mark Moulding
Anyone here do any transformer specification or design and would be
interested in some consulting dollars to help me source/create a weird
transformer option?
What I need is a 12V primary, 12V:12V center tapped secondary that can
support 12VA of power. Higher voltages are OK, but not needed. I am
struggling on the Xformer details, but I know it needs to be center
tapped, 1:1:1 @12VA
Jim
--
Jim Brain
brain at jbrain.comwww.jbrain.com
Yet another nice color brochure.
https://dl.dropboxusercontent.com/u/96935524/Datormusuem/lab11.pdf
Has anyone seen a VR20 in real? Rather interesting to be able to do a red
and green X/Y screen based on different energy levels. Someone care to
explain how that works?
If I read the fine print on the back correctly (and comparing with the
others) I would guess that this brochure is from 1971.
For those of you running DECnet/E on simulators...
paul
> Begin forwarded message:
>
> From: Paul Koning <paulkoning at comcast.net>
> Subject: Re: RSTS and slow DECnet operation in SIMH
> Date: May 2, 2016 at 1:37:45 PM EDT
> To: SIMH <simh at trailing-edge.com>
>
>>
>> On Apr 19, 2016, at 2:46 PM, Paul Koning <paulkoning at comcast.net> wrote:
>>
>> With help from Mark Pizzolato, I've been looking at why RSTS (DECnet/E) operates so slowly when it's dealing with one way transfers. This is independent of protocol and datalink type; it shows up very clearly in NFT (any kind of file transfer or directory listing) and also in NET (Set Host). The symptom is that data comes across in fairly short bursts, separated by about a second of pause.
>>
>> This turns out to be an interaction between the DECnet/E queueing rules and the very fast operation of SIMH on modern hosts. DECnet/E will queue up to some small number of NSP segments for any given connection, set by the executor parameter "data transmit queue max". The default value is 4 or 5, but it can be set higher, and that helps some.
>>
>> The trouble is this: if you have a one way data flow, for example NFT or FAL doing a copy, the sending program simply fires off a sequence of send-packet operations until it gets a "queue full" reject from the kernel. At that point it delays, but the delay is one second since sleep operations have one second granularity. The other end acks all that data quite promptly, but since the emulation runs so fast, the whole transmit queue can fill up before the ack from the other end arrives, so the queue full condition occurs, then a one second delay, then the process starts over.
>>
>> This sort of thing doesn't happen on request/response exchanges; for example the NCP command LOOP NODE runs at top speed because traffic is going both ways.
>>
>> I tried fiddling with the data queue limit to see if increasing it would help. It seems to, but it's not sufficient. What does work is a larger queue limit (32 looks good) combined with CPU throttling to slow things down a bit. I used "set throttle 2000/1" (which produces a 1 ms delay every 2000 instructions, i.e., roughly 2 MIPS processing speed which is at the high end of what real PDP-11s can do). Those two changes combined make file transfer run smoothly and fast.
>>
>> Ideally DECnet/E should cancel the program sleep when the queue transitions from full to not-full, but that's not part of the existing logic (at least not unless the program explicitly asks for "link status notifications"). I could probably add that; the question is how large a change it is -- does it exceed what's feasible for a patch. I may still do that, but at least for now the above should be helpful.
>
> Followup: I created a patch that implements the "wake up when the queue goes not-full". Or more precisely, it wakes up the process whenever an ack is received; that covers the probem case and probably doesn't create many other wakeups since the program is unlikely to be sleeping otherwise.
>
> The attached patch script does the job. This is for RSTS V10.1. I will take a look at RSTS 9.6; the patch is unlikely to apply there (offsets probably don't match) but the concept will apply there too. I don't have other DECnet/E versions, let alone source listings which is what's needed to create the patch.
>
> With this patch, you can run at full emulation speed, with the default queue limit (5). In fact, I would recommend setting that limit; if you make the queue limit significantly larger, the patch doesn't help and things are still slow. I suspect that comes from overrunning the queue limits at the receiving end. (Note that DECnet/E leaves the flow control choice to the application, and most use "no" flow control, i.e., on/off only which isn't effective if the sender can overrun the buffer pool of the receiver.)
>
> To apply the patch, give it to ONLPAT and select the monitor SIL (just <CR> will give you the installed one). Or you can do it with the PATCH option at boot time, in that case enter the information manually. The manual will spell this out some more, I expect.
>
> I have no idea if this issue can appear on real PDP-11 systems. Possibly, if you have a fast CPU, a fast network (Ethernet) and enough latency to make the issue visible (more than a few milliseconds but way under a second). In any case, it's unlikely to hurt, and it clearly helps a great deal in emulated systems.
>
> paul
>
On Thu, 4/28/16, Liam Proven <lproven at gmail.com> wrote:
>>> The efforts to fix and improve Unix -- Plan 9, Inferno -- forgotten.
>
> It is, true, but it's a sideline now. And the steps made by Inferno
> seem to have had even less impact. I'd like to see the 2 merged back
> into 1.
Actually, it's best not to think of Inferno as a successor to Plan 9, but
as an offshoot. The real story has more to do with Lucent internal
dynamics than to do with attempting to develop a better research
platform. Plan 9 has always been a good platform for research, and
the fact that it's the most pleasant development environment I've
ever used is a nice plus. However, Inferno was created to be a
platform for products. The Inferno kernel was basically forked from
the 2nd Edition Plan9 kernel, and naturally there are some places
that differ from the current 4th Edition Plan 9 kernel. However, a
number of the differences have been resolved over the years, and
the same guy does most of the maintenance of the compiler suite that's
used for native Inferno builds and for Plan 9. Although you usually
can't just drop driver code from one kernel into the other, the differences
are not so great as to make the port difficult. So both still exist and
both still get some development as people who care decide to make
changes, but they've never really been in a position to merge.
And BTW, if you like the objectives of the Limbo language in Inferno,
you'll find a lot of the ideas and lessons learned from it in Go. After
all, Rob Pike and Ken Thompson were two of the main people behind
Go and, of course, they had been at the labs, primarily working on
Plan 9, before moving to Google.
BLS
>Date: Mon, 2 May 2016 12:37:43 +0200
>From: Mattis Lind <mattislind at gmail.com>
>To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
>Subject: Re: PDP8 MAINDEC ?
> Selling, trading, giving away. What ever works. Rather than the garbage
> bin. I have no need for multiple copies. Just checking if someone like to
> play with the real paper tapes.
> When it comes to digital copies the plan is to check what is already online
> and then scan / read those that aren't. But it is a long time plan since it
> takes quite a while. Unless you feel like helping out... A page feed
scanner and a couple of thousands of pages.
>
> /Mattis
I can take good care of (some part of) it, a bit depending on which tapes
and documents you have.
/Anders
> From: Pontus Pihlgren
> I wonder what the three leftmost cabinets contains. I don't recall what
> peripherals have the blinkenlights at the top. RK05 and TU10
> controllers perhaps?
I have a half-done page with images of all the 5-1/4 inch indicator panels
(PDP-8, -11, -15); so I can identify the indicator panel on the right (above
to the two DECTape drives), which is a TC08 DECTape controller (I have a large
picture of one of those, for the page, and that's definitely it), which makes
sense, given it's in the same cabinet as the DECTape drives.
The other one, I have no idea - anyone?
I'm pretty sure it's not an RK08. The RK08, like the RK11-C, was wired for an
indicator panel, but like the TM08, it only used two rows of lights. (I've
never seen an image of one: this is deduced from reading the engineering
drawings.)
The partial page is here:
http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html
if anyone is interested. Good images of the missing 5-1/4" indicator panels
(which also include the RF11 and FP15, as well as the mythical RK11, which may
not exist) gratefully accepted!
Noel
We have quite a lot of PDP-8 MAINDEC which are duplicates even when taking
different versions into account. This include the paper listing and the
actual paper tape.
Is there an interest in such tapes / documentation?
Just to let folks know that I just received the prototype boards for the MEM11A (FedEx just left).
The boards look great! The parts from Digikey arrived late last week, so once I get my soldering
station set up (new microscope and new Metcal soldering iron) I?ll start to build a couple of boards
to test out. Once I have a couple working *and* I get firm orders for at least 25 boards (hint, hint)
I?ll do a production run.
TTFN - Guy
> From: Guy Sotomayor
> The reality is that an SPC board will be more expensive because of the
> gold edge fingers.
Oh, right, forgot about that. Yeah, six of one...
> I was originally thinking that if I do have to split the board up, that
> I'd make them completely independent. But that has the issue of
> requiring 2x the number of UNIBUS transceiver parts (which are all but
> unobtainium as of now).
Actually, 8641's (at least) are still around for not much. See below.
> some of the signals I'm running are pretty fast between the FPGA and
> some of the other components ... I wouldn't want to run those signals
> very far and certainly not across any sort of cabling.
For sure. We've been having issues (although we think we have it licked now)
with signals running across a flat cable between the prototype QSIC's
mother-card (a QBUS wire-wrap card) and its daughter-card (an bought-in FPGA
devel card), and that's for much slower signals (the only thing on the
mother-card are QBUS transceivers and level converters). Of course, the fact
that the interface doesn't put a ground wire between each pair signals wires
doesn't help! :-)
> From: Ethan Dicks
> I'm starting to get sorry I sold off my surplus NS8641s from Software
> Results 20 years ago. To be fair, I did get over $4 each for them, so at the
> time, it was a good deal for me (ISTR retail was $7.50 even then, so I
> got a good spread on the price).
> I do have some left, but handfuls, not armloads.
NS8641's are still available. I got a bunch from a guy in Hong Kong for
US$1.50 each - considering the source, I built a test card to make sure they
met specs, and they do, so I'm pretty sure they aren't counterfeits. :-)
When I was worried he couldn't find enough, I checked with a supplier (4 Star
Electronics, I think) and they had like 50K available, and quoted me a price
in about the same region, so I don't think UNIBUS transceivers actually are a
problem, at least, not at the moment.
Noel
Sounds like some of the SMR stuff Seagate is working on. Not sure if HAMR needs fs changes or not, but I know SMR does for certain.
Sent from my T-Mobile 4G LTE Device
-------- Original message --------
From: Eric Christopherson <echristopherson at gmail.com>
Date: 5/1/2016 1:44 AM (GMT-05:00)
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
Subject: Re: File systems expert for a news article (urgent)
On Fri, Apr 29, 2016, Evan Koblentz wrote:
> >>Anyone here on cctalk consider themselves a file systems expert and have
> >>the credentials or job title to vouch for it? If so, then I need to
> >>interview you ASAP today (in the next hour-ish) for a TechRepublic.com
> >>article. Contact me offline: news at snarc.net.
> >>
> >>Not going to discuss the story itself here in public.
> >>
> >
> >Can you be a little more specific?? File systems is quite broad
> >
>
> One of the hard disk standards bodies is working on a new feature (which I'm
> not going to post here) that would require changes to file systems,
> otherwise the new feature is academic and useless in the real world. So I am
> looking for someone with FS chops to comment on whether the changes can
> reasonably happen. Cannot say more except in private.
Hopefully not something that would require said filesystem
implementators to pay licensing fees or sign NDAs or take affirmative
action to limit users' use of data, or onerous things like that.
--
??????? Eric Christopherson
hilpert at cs.ubc.ca
that is a valid idea....
or a replacement also for TSS-8 using pdp8s but would timeshare
Ed Sharpe Archivist for SMECC
In a message dated 5/1/2016 2:20:53 P.M. US Mountain Standard Time,
hilpert at cs.ubc.ca writes:
On 2016-May-01, at 1:55 PM, Paul Koning wrote:
>> On May 1, 2016, at 4:37 PM, Warner Losh <imp at bsdimp.com> wrote:
>>
>> Cool brochure. When was this price list in force?
>
> Judging by what it advertises, probably 1972, maybe 1973. Unlikely to
be later than that.
I wonder if this MINI-RSTS/BASIC-PLUS was a marketing response to HP's
timeshared BASIC system for the 2100s.