> Early 3rd generation machines had special instructions to finagle their
> way around self-modifying code:
And some didn't: The HP 2100 and the PDP-8 (and I think the Honeywell
x16s), instead of a stack, would store the return address of subroutine
calls in the first word of the subroutine; obviously, this made recursive
subroutines impossible without handling a stack manually.
> Few CDCers of the time even knew that the STAR-100 existed. I remember
Reading up on the early history of CDC, I stumbled across the "Little
Character" - Seymour Cray's six-bit proof of concept for his first computer
designs at CDC. Apparently, one was actually built, because it's now at the
CHM. However, I haven't been able to find any significant information about
this on the Web (my Google-fu must be failing me).
Does anyone know where I could find some documentation about this machine?
Performance specs (memory size, speed, etc.) would be nice, but I'd really
like a detailed architecture and instruction set description - you know, in
case someone wanted to make an emulator or something...
~~
Mark Moulding
yes ET! the one in the with the head in the yoke although anything
blue and pretty would be better than nothing! Our Eclipse is not as
grand as some photos ,,, and the tape drive is a small side by side
reel unit that fits in the single rack here is a photo of ours....
http://www.smecc.org/data_general.htm
had it for years need manuals etc and maybe some sales lit. or
scans of advertising material to display with it... but yea... it
cries out to have a terminal with it!
In a message dated 9/22/2015 9:08:14 A.M. US Mountain Standard Time,
jwest at classiccmp.org writes:
Jay Jaeger wrote...
----
??? What do you mean by "blue dg et head looking terminal" ???
----
I'd bet that he's referring to the Data General Dasher D200 terminal.
I have one:
https://www.flickr.com/photos/131070638 at N02/21058074082
But perhaps a better picture:
http://maben.homeip.net/static/s100/data%20general/photos/DG%20dasher%20d200
%20front.jpg
The D200 isn't always on ebay, but usually they show up mildly frequently
there and seem to go around $200 to $250.
There was another common terminal on eclipse systems. I'm not sure if it
was
in the Dasher series, but I believe it was called a "5821". I have one of
these as well.
http://www.museumwaalsdorp.nl/computer/images/GRP.jpg
Lastly, a common combination system console (terminal)/printer that is VERY
cool looking was the Dasher TP1 and TP2. Mine is a TP1.
http://www.foxdata.com/blog/wp-content/uploads/2011/05/IMG_0210.jpg
J
that may have been the one i had....
In a message dated 9/22/2015 11:59:29 A.M. US Mountain Standard Time,
jwest at classiccmp.org writes:
On mine, there is no "blank panel space" to the right of the screen. The
screen takes up the entire horizontal width. Diagonally, the terminal
"head"
measures 21 inches so it's slightly unusually large for a terminal. On the
back, under model number it says "5821NT".
Recently, there have been a number of references to using
overlays on the PDP-11. There have also been strong suggestions
that overlays were structured differently under the 3 operating
systems: RSTS/E, RSX-11 and RT-11.
Obviously, I understand how RT-11 overlays were set up, but
for those readers who don't:
ROOT
- contains overlay code subroutines and data tables
- data used by more than one overlay
FIRST Overlay Region - size of the largest overlay in the region
- one or more overlays and the data used by just that overlay
SECOND Overlay Region - size of the largest overlay in the region
- one or more overlays and the data used by just that overlay
THIRD Overlay Region - size of the largest overlay in the region
- one or more overlays and the data used by just that overlay
FREE MEMORY
Any overlay could be called from any location. About the only
requirement was that the calling instruction code (specifically the
code which followed the calling instruction) had to be in memory
when the code returned from the overlay. In practice, the usual
protocol was that an overlay in a higher region was only called
>from a lower region or the root.
I understand that RSTS/E and RSX-11 were a bit more complex.
Can anyone briefly summarize and also provide a link to the
details in the appropriate manual if it is available on the internet?
Jerome Fine
>Rod Smallwood wrote:
> >On 21/09/2015 10:30, Johnny Billquist wrote:
>
>> >On 2015-09-21 02:11, Jerome H. Fine wrote:
>>
>>> You bring up a VERY notable lack of support by DEC of that
>>> situation!!!!!!!!!!!!!!!!!!!!!!
>>>
>>> For both the DEC RX01 and the DEC RX02 8" floppy drives,
>>> while it might have been possible that DEC engineers were unable
>>> to initially figure out how to allow users to perform an LLF (Low
>>> Level Format) on the 8" floppy drives, it seems certain that after
>>> 3rd party manufactures figured out, DEC could also have supported
>>> that function as well.
>>>
>>> Instead, DEC pretended that all 8" floppy media HAD to be
>>> purchased PRE-FORMATTED from DEC. Well, if you
>>> ever discussed that option with a DEC person, it certainly
>>> did not seem like the individual was pretending.
>>>
>>> After I managed to locate a DSD (Data Systems Design)
>>> drive which supported the DEC RX02 floppy drive function,
>>> it was game over for that particular DEC monopoly. The
>>> DSD drive was able to perform an LLF for either single
>>> density or double density in addition to being both single
>>> sided and double sided.
>>
>> Not that tricky. All you needed was a way to format into RX01 format,
>> which is plain simple IBM single side, single density format.
>> RX02 floppies have the same low level formatting. To use them in RX02
>> mode just requires flipping a bit in the sector header, and the RX02
>> drive is able to do that.
>
I am not sure that I understand your suggestion. While I agree
that the RX02 was able to switch a single-density floppy to a
double-density floppy (and visa versa), the difficulty, as you
pointed out, was performing the initial LLF (Low Level
Formatting) in the first place on Un-Formatted 8" floppies.
That may have been easy with IBM hardware, but DEC
made that impossible if all the user had was a DEC system.
For readers unfamiliar with DEC vocabulary, the FORMAT
command did NOT create a file structure! That command
in RT-11 was INITIALIZE and something similar was
probably used for RSTS/E and RSX-11. Note that under
RT-11, the FORMAT command for the RX02 did NOT
perform an LLF, but did set the density bit in each sector
if an LLF had already been performed and was sufficiently
intact to support clearing out all the data in the sector setting
and the density bit to the value requested by the user.
In practice, I found that when an RX02 floppy started having
problems, the LLF was VERY rarely a problem. For reasons
which were not understood, when the floppy media started to
have read and or write errors, it was usually possible to have
the RX02 floppy drive perform the software command which
DEC called FORMAT and re-initialize all the sectors so that
the media could be used again without any read and or write
errors. That obviously would have required the LLF to be
sufficiently present for the software and hardware to repair
the problems and reset all the sectors as either single-density
or double-density depending on what the user requested.
I am not sure what conclusions can be drawn from this example.
>>> Note that the RX50 was the same. DEC finally changed
>>> their marketing policy with the RX33 drive which used the
>>> same 3.5" HD floppy media as the PC. It was actually
>>> possible to FORMAT those floppies under RT-11.
>>
>> No, DEC actually did support users formatting RX50 floppies on their
>> own, but only on the Rainbow.
>>
>> Johnny
>
If it was possible to perform a LLF using the same RX50 drive on
the Rainbow, what was the reason why an LLF could not also be
performed on a PDP-11? There seems to be a number of possibilities:
(a) There was some hardware that the Rainbow had which was missing
on the PDP-11 systems
(b) The firmware in the controller on the Rainbow supported an LLF,
but the firmware in the controller on the RQDX1, RQDX2 or RQDX3
on the PDP-11 did not support an LLF
(c) The Rainbow used a program which DEC supplied that could
perform an LLF, but DEC did not supply such a program for
the PDP-11 systems
(d) Another possibility of which I am not aware.
Is there an answer as to which possibility supported the Rainbow
being able to perform an LLF using an RX50 drive, but that the
PDP-11 systems with that same RX50 could not perform an LLF?
>> Take me back to my desk in DECPark thirty years ago and I could have
>> pulled out the internal documents on this.
>
> I cant do that so we will have to make do with my dodgy memory.
> When floppy disks first appeared end users just wanted to take the
> disk out of the box and use it.
> They could not see why they should waste time preparing every new one.
> They did not need matching to a particular drive as DEC's
> manufacturing tolerances made sure any disk would work on any drive.
>
> In fact it was more difficult and expensive to provide pre-formatted
> disks.
> It was more about customer service and making sure the equipment kept
> running.
>
> I heard the following story
>
> One customer went out and got a huge pile of unformatted (and
> untested) floppys and a third party format program.
> He expected DEC to make it work.
>
> The account manager asked to see his DEC maintainance contract and had
> to be restrained from tearing it up.
> Through the window of the office was building site and the inevitable
> 50 gallon oil drum burning rubbish.
> He was offered a choice; he could put the disks or the contract in the
> burning drum.
>
> Rod Smallwood
>
>
>
>
> DEC supplied pre formatted disks
I don't know how to respond since different individuals will
interpret your story in the opposite manner, So I will add
my own experience when I used the RX02 drive from DEC
along with the DSD RX03 floppy drive.
Around 1990 after I had acquired the DSD RX03 floppy
drive in a DSD 880/30 system, I also managed to acquire
many brands of 8" floppy media. At that point, I had not
yet managed to acquire any tape hardware such as the TK25
which supported a 32 MB disk image, so the floppies were
my primary backup. I probably had about a dozen different
brands of 8" floppies that required an LLF before they could
be used. And since a double-density, double-sided 8" floppy
media held about 1 MB (1976 blocks) as opposed to about
1/2 MB (988 blocks) for double-density, single-sided media,
I set set about the task of enhancing the DEC DY.MAC RX02
device driver after I found the code in V04.00 of RT-11 which
included support for double-sided media.
What may be called "interesting" was that DEC had removed
all of that optional code in DY.MAC by the time V05.00 of
RT-11 was released. That might have had something to do
with the fact that DEC never sold (that I heard of) an RX03
drive.
In any case, adding and correcting the extra code was quite
easy. The challenge was to also add support for a user buffer
being above the 1/4 MB boundary in a PDP-11 with all 4 MB
of memory when a Mapped RT-11 Monitor was used since
the controller supported only 18-bit addresses.
Another problem was that the index hole for single-sided floppies
was offset about 1/2" from the index hole for double-sided
floppies. That challenge was solved by using a DPDT switch
to flip the sensors that were used on the DSD 880/30 and
that supported using, as double-sided, floppies with the single-
sided index hole. While a number of 8" floppies had been
purchased that had the double-sided index hole, that was less
than 10% of the total and after punching the extra pair of holes
in single-sided floppies just a few times, it was very quickly
apparent that the DPDT switch was a much better one-time
solution. What was initially a surprise was that EITHER the
single-sided OR double-sided index hole could be used with
the same floppy to access the sectors even though the holes
were in different positions. The timing did not seem to matter.
Only the device driver software cared if the bit was set one
way or the other, so flipping the sensors which were activated
was an excellent one-time solution when the user (me!!)
wanted to use a floppy with a single-sided index hole as a
double-sided floppy.
In any case, the code was enhanced, my version of DYX.SYS
supported the RX03 double-density, double-sided floppy drive
under a 22-bit RT-11 monitor. So I set about the job of the
LLFs for double-sided 8" floppy media. As mentioned above,
in addition to a couple of dozen 8" DEC floppies, I had about
a dozen other brands. To make a long story short at this point,
the results were "interesting". Every non-DEC branded 8" floppy
could hold an LLF for double-sided, double-density. On the other
hand, I seem to remember that only about 2/3 of the DEC 8"
floppies managed to complete the LLF. The other 1/3 of the
DEC 8" floppies could hold an LLF on the normal first side,
but not on the second side.
Obviously this story was somewhat different since it was not
necessary to ask DEC maintenance to make the LLF capability
with the DSD 880/30 to work - it already worked. In addition,
there was no DEC maintenance contract in the first place and
there was no 50 gallon oil drum. There was also no refusal
by DEC to enhance the DY.MAC device driver to support
the RX03 floppy drive since DEC was not asked.
Over the decades since, I have always wondered how it was
even possible for ONLY the DEC 8" floppies to be unable to
take an LLF double-sided when every other brand managed
to do so. There was probably one floppy that was so severely
damaged that it would not take an LLF on either side, but that
was a specific exception. Any 8" floppy which could take a
double-sided, double-density LLF held the data successfully
when used in practice.
In any case, I also ask the questions:
(a) Was it more difficult and expensive to provide pre-formatted
disks?
(b) FOR WHOM was it more difficult and expensive to provide
pre-formatted disks (DEC or the user)?
(c) Was it more about customer service and making sure the
equipment kept running?
(d) Was it more about DEC charging about TEN times the price
for pre-formatted disks over the price for un-formatted disks
and having a technician take the time to do the LLF (about
2 minutes for each double-sided, double-density floppy or
about 30 floppies an hour)? At the time, I seem to remember
that a box of 10 pre-formatted 8" floppies from DEC was
about $ 50 while a box of 10 un-formatted 8" floppies was
about $ 5 a box. If a technician could format 3 boxes of
8" floppies in an hour, that would seem to save that user
about $ 135 which would probably be less expensive for
the user.
(e) Was it equally reliable and less expensive to use non-DEC
unformatted 8" floppies if the user had the necessary
hardware and or software to pre-format the floppies?
Also, I want to be sure to add that in my experience, RT-11
is probably the best written and documented operating system
that I have encountered. While there are still a few bugs that
can actually crash the operating system and many enhancements
were and are still needed, RT-11 is mostly stable and easy to
use. RT-11 obviously lacks any security when running under
an UnMapped Monitor since the user has access to all of the
memory. Even with a Mapped Monitor, a user program can
gain access to the Monitor. But RT-11 was not designed to
be secure in the first place. So I still think that DEC did an
exceptional job - especially since almost all programs written
for the very first version of RT-11 can still run under the latest
version.
Jerome Fine
Someone was kind enough to mail me the masked ROM out of his HP 9895
floppy drive. I've read it and mailed it back. It's an MK36000 series
24-pin 8KB masked ROM, with the same pinout as the Motorola MC68764
EPROM, so reading it with an EPROM programmer set for the Motorola
part should work fine. In read mode, no programming voltage is
applied, so there should be no risk of damage to the part.
Unfortunately my Data I/O Unisite does too good a job trying to
protect devices against reverse or misaligned insertion or incorrect
device configuration; if it thinks the current drawn by the device is
too low or too high, it aborts with a device insertion error. The
MK36000 draws significantly less current than the MCM68764. I tried
putting an appropriately valued resistor in parallel, but still got
the error.
I ended up kludging the masked ROM to the expansion bus interface of a
TI Launchpad board with a Tiva TM4C1294 microcontroller (ARM Cortex-M4
based), using an SN74LVC245A buffer on the data bus because the Tiva
is not 5V-tolerant. I wrote C code to read the ROM and send a hex dump
out the USB-serial interface.
Photo: https://www.flickr.com/photos/22368471 at N04/21611518545/
As I've needed to use the expansion bus interface of the Tiva for
other projects, even though this was a lot of work to read one ROM,
the experience and maybe even the code may be useful in the future.
The next issue is that it appears that the 9895 may permute the
address and/or data busses, as the contents of the ROM don't actually
look like reasonable Z80 code.
This is sort-of off topic, but not entirely...
I've seen a fair amount of furniture like in the following picture:
http://dooki.com/supercomputers/ibm/ibm.s390g4.gif
It looks well-made, industrial, and vintage (sort of). Anyone know who makes such things?
Did IBM have a go-to desk manufacturer for their stuff, or just whatever the customer provided?
Thanks!
-Ben
> From: Jay West
> A couple items in my holdings have rust ... The only good solution I
> could see is having the existing metalwork sandblasted and then
> repainted. I've not checked, but I suspect that's "non-trivial-$".
> Thoughts?
Iff you have access to an air compressor, small sandblast units can be had at
Harbour Freight for less than $50. If you don't have a compressor... well,
that's considerably more money, but I find a compressor is a very useful
thing to have.
I feed our sandblast unit (one of the HF ones) with playground sand, a couple
of $ per bag, which I feed through a sieve made of 4 pieces of scrap wood
(frame) and some plastic door/window screen. (If you don't sieve it, the
cheapo play sand has larger bits in it which tend to jam the nozzle.) And the
sieve allows me to be _really_ cheap and sweep up the sand and recycle it.
I refinished an H960 which I got which was in pretty nasty condition (very
severe rust on the bottom surface, some rust elsewhere, e.g. on the uprights)
using this rig, and some tins of spray paint (Rustoleum flat black), and it
came out looking brand spanking new. (My attempt to do the same with a BA11
ran into some shoals, I screwed up the spray-painting - definitely an art! :-)
Anyway, if you're up for doing it yourself, it's a useful capability to have
in-house.
Noel
Hello,
you have a very nice lot of DG stuff, indeed!
I have a Nova 3 sitting on the garage, waiting for proper repair.
However it's missing all the front panel switch levers,
so I would need to rebuild them, not having had the luck of finding some at
reasonable price.
I have some picture of the original Nova 3 levers, however I didn't manged
to
have the exact size to fit an obtained plastic model very well.
Would you mind to take one cover apart, and put it on a flat-bed scanner
together with a clear ruler (in the same picture), so I can measure from
the image
the exact sizes?
The profile is not the same, but I can obtain it from the camera pictures I
already have,
using your images as size reference for rescaling.
Thanks
Andrea
And we have a winner of the overlay competition .....
From the CBASIC manual
The CHAINstatement can load two types of programs:
an overlay program generated by the linker,
or a directly executable file.
As I used CBASIC this must be where I got it from
Rod Smallwood
--
Wanted : KDJ11-E M8981 KK8-E M8300 KK8-E M8310 KK8-E M8320 KK8-E M8330