date:20150921

I have an LA120. It's working fine, and I haven't looked inside yet.

I also have one of the little Correspondents (I forget the LA number), waiting 
for me to get around to rebuilding a ribbon for it.

I'm not sure if I have a convenient way to dump the 23xx ROMs yet. I don't have 
my Data-I/O 212 handy to look at its supported device list. 

-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

would like to find blue dg et head looking terminal to go with small eclipse

2015-09-21 Thread COURYHOUSE

would like to find  blue dg et head  looking terminal to go with  small 
eclipse 
this  thing is a beauty and has a tiny side by  side reel   to reel deck
 
just  would be nice to have a terminal to  display with it   in the museum.
drop us a line  offlinst...
ed sharpe archivist for   smecc

Re: PDP-11 Overlays


On 2015-09-21 23:16, Jerome H. Fine wrote:

 >Paul Koning wrote:


On Sep 21, 2015, at 3:14 PM, Jerome H. Fine wrote:


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?



RSTS has no specific structure of its own.  It provided both RT-11 and
RSX emulation, and as a result would offer the structures from both of
those, depending on which environment you chose for a particular
application.

RSX uses a tree structure.  For details (lots of details) see the TKB
manual.

Suppose you have main which calls o1.  o1 calls o2 which calls o3, and
o1 also calls o5 which calls o6.
In the RSX case, you could specify a tree with two branches: main to
o1 and from there o2 to o3, and o5 to o6.  In the RT11 case, you might
put o1 in region 1, o2 and o5 in region 2, and o3 and o6 in region 3.

The memory requirements would be:

rt11: main + o1 + max (o2, o5) + max (o3, o6)
rsx:  main + o1 + max (o2 + o3, o5 + o6)

If o2 and o6 are large while o3 and o5 are small, then the RSX case
gives you a smaller memory footprint.


In RT-11, you can also put o5 in region three and o6 in region two
and still have o5 call o6.  If TKB does not allow that, then it is
more restrictive in some ways than RT-11.  So the memory
requirements would be:

RT-11:  main + max (o2, o6) + max (o3, o5)

This is probably better than the RT-11 memory requirement which
you suggested, but likely not as good as the RSX-11 memory
requirement.

Also, my example is rarely that simple in actual practice.

Another important aspect is that RT-11 has a few extra instructions
in the overlay handler which determines if the overlay is already in
memory.  The linker assigns an overlay number to each overlay and
places that value (actually *6) in the first word of each overlay as a
data value that the user program does not see.  When the overlay
handler is invoked and the address to be used for the .ReadF request
is found, the overlay handler checks to determine if that value *6 is
still in the first word.  If so, the overlay handler can assume that the
overlay is still in memory and the call can jump to the normal entry
address for that subroutine call without the overhead of reading the
overlay  NOTE that this check depends on a region which has
the same starting address for all overlays within the region and
no overlap between regions.  This allows for that extra word
which the user code is unaware of and never accesses.

In MACRO-11 which executes under RT-11, I modified the
overlay handler to keep track of how many times the overlay
was called and how may times it needed to be read.  99% of the
time, the overlay was already in memory and the code was ready
to be executed.  The number of calls can be so large that a 32-bit
entry was required to track the number of calls.  It was very easy
to add the additional code since the instructions to test for the
overlay being present were already there along with an extra
register (having already been saved) that pointed to the 32-bit
entry that kept track of the number of calls as well as the number
of times that the overlay needed to be read.

My question is if TKB overlays also have these extra instructions?
For example, if there are three trees with only two trees having a
second overlay, does the overlay handler know if the second overlay
for a different tree is still there?  It seems doubtful since a data value
could, by chance, have the same value that was being checked.

So each overlay handler has advantages and disadvantages.
I wonder if in RSX-11 the MACRO-11 assembler takes longer
than in RT-11 when it needs to always read in the overlay?


I don't have the energy to respond in much detail. Suffice to say

Re: PDP-11 Overlays

On 2015-09-22 02:09, Jerome H. Fine wrote:

>Paul Koning wrote:

On Sep 21, 2015, at 5:16 PM, Jerome H. Fine
wrote:

...
Another important aspect is that RT-11 has a few extra instructions
in the overlay handler which determines if the overlay is already in
memory. ...

My question is if TKB overlays also have these extra instructions?

Yes, it also tracks if something is already resident. I haven't
looked into the details. (The only overlay machinery I studied to any
significant extent is the RT-11 one.)

Is there any documentation as to the actual details?

http://bitsavers.trailing-edge.com/pdf/dec/pdp11/rsx11/RSX11Mplus_V4.x/4b/AA-JS08A-TC_RSX-11M-PLUS_and_Micro_RSX_4.0_Task_Builder_Manual_Sep87.pdf

Chapter 3 and 4 give the basics. Chapter 5 through 9 give details in
relations to what the respective chapter is about. Figures on pages 3-5
and 3-6 might give you a goo starting idea of what you can do.

As I mentioned, For the RT-11 overlay handler integrated with
the LINK program (both are essential), when those aspects
are combined with overlay regions defined by the maximum
size of the overlay in a given region, the first word of every
region is devoted to the overlay (*6) number. Since that
location is not available to the overlay and is unique to the
overlay, the overlay handler can check to determine which
overlay is resident in the region.

With overlay trees in TKB, that method can't be used unless
the line up the tree is intact. I am attempting to visualize the
code which could determine if that is true, but at the moment
it escapes me. Can anyone provide any details?

Otherwise, I can see where the first overlay in any tree can
be determined, but unless a given tree is enforced, there does
not seem to be any way to check if overlays further up the tree
are also resident?

There are no checks that the tree is intact at runtime. This is checked
during the task build. You cannot refer to symbols that are outside you
call tree if you look upwards.

Is there a manual available on overlays using TKB that is
on the internet?

Gave it above.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

RE: Multi-platform distribution format (Was: Backups [was

> HOWEVER, while the PDP-11 is still unable to perform an
> LLF on an RX50 when an RQDX3 is present, it is possible
> to perform an LLF on a floppy in an RX33.  Does that still
> seem compatible with your explanation?

Yes, that confused me too. The RQDX3 is clearly capable of
LLFing a floppy. So either (unlikely) DEC specifically do
not allow the right set of commands to LLF an RX50 or
(more likely) that bit of software you have doesn't do it
(although others can) possibly so as not to cut into DEC's
sales of pre-formatted disks.

Sorry I don't know more, the RQDXs are too modern for me.

-tony

Re: vintage datacenter furniture

2015-09-21 Thread Jason T

On Mon, Sep 21, 2015 at 5:54 PM, Benjamin Huntsman
 wrote:
> 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?

Don't know if IBM used them, but Wright-Line was huge in datacenter
equipment, both furniture and storage.

DEC had some of their own (I have a catalog somewhere) that
matched their corporate rack cabinets (brown/beige scheme.)

Reading a masked ROM the hard way (was Re: Wanted: ROM images from HP 9895, 82901/82902, and other HP-IB disk drives)

2015-09-21 Thread Eric Smith

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@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.

Re: Multi-platform distribution format (Was: Backups [was


On 2015-09-21 22:27, Paul Koning wrote:



On Sep 21, 2015, at 3:49 PM, Jerome H. Fine  wrote:


Johnny Billquist wrote:



On 2015-09-21 17:03, Paul Koning wrote:



And it would certainly be possible to write a driver that can handle both 
controllers; it would start by determining which controller it's dealing with, 
and then run the one or the other set of algorithms.  Since a boot block is 
just a small driver, the same is true there, so long as the whole body of code 
fits in the available space.  I suspect in this case that's doable; most 
bootloaders (other than MSCP ones) require only a small fraction of the 
available space.


You are absolutely right.
And I don't know the actual size of the boot blocks. It might very well be that 
they both fits in the same boot block, which would be nice.
I know that the M9312 have separate boot roms for the RX11 and the RX211, but 
those boot roms are pretty tiny...

And I don't know if the RX211 boot rom also deals with RX01 floppies, but I 
would assume it does.


I don't know how RSX-11 and RSTS/E manage their device
drivers and allocate the memory for that code.  BUT, under
RT-11, each device driver uses memory which the user program
can't use. ...
Finally, while the boot code could certainly support both
the RX01 and the RX02 drive, there would be no point
since the code in the device driver supports only one
drive.


RSTS isn't as frugal with memory as RT11 is.  It has a bit of per-unit memory 
whether the device is present or not.  But the kernel can be built with all 
sorts of device drivers for devices that aren't actually present.  If so, those 
are disabled at boot.


RSX does it somewhat different, but the basic idea is similar. At boot 
time, devices are mark offline or online depending on whether they 
actually exists. And in addition, you can always load and unload drivers 
while the system is running. So, you can do as you choose.
The drivers for RX11 and RX211 are separate and different. You might 
have both loaded at the same time, and just have one online, depending 
on which controller you actually have.
Or, if you have a multiprocessor system, you can always hot-plug them as 
well, and bring devices on- and offline as you feel like it, just as 
easily as you can change what CSR address and vector to use.



So for RSTS, it certainly makes sense to have a multi-lingual boot block, if 
you're dealing with a medium that can be installed into several types of drives 
with different controllers.


Also true for RSX, whenever possible. Unfortunately, not all devices can 
be booted by the same bootblock, but the most common ones can.



The RX01/RX02 case doesn't occur for RSTS since those aren't supported as boot 
devices.  But the analogous scenario does apply to magtape.  The RSTS magtape 
boot block works with every PDP-11 controller capable of supporting that tape, 
so 1600 BPI tapes can boot on TU16, TS80 (gag) and TMSCP controllers.  Yes, 
that's a fun bit of code.


Same with RSX. RX01/RX02 are too small to even be possible to boot from. 
All magtapes use the same bootblock. MSCP and Massbus disks also share a 
common boot block. RL01/RL02 have its own boot block, as do the 
RK06/RK07. And those are the only available options for booting.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: DEC Alpha 3000 Model 600

2015-09-21 Thread william degnan

I have Moasic on my Alpha 2100 running VMS

On Mon, Sep 21, 2015 at 12:36 AM, Sean Caron  wrote:

> I am pretty sure I remember a Netscape build for VMS long ago ... but I
> can't say for sure. I may have just been running on a UNIX machine with
> remote X to the VAX ... I don't recall. All my VMS systems run just in text
> mode nowadays so I can't really do a lot of first-hand experimentation. I
> definitely remember running Netscape on an old DECpc AXP 150 with 128 Meg
> RAM (under Tru64) and it worked well enough.
>
> Best,
>
> Sean
>
>
> On Sun, Sep 20, 2015 at 9:08 PM, Jason Howe  wrote:
>
> >
> > On 09/20/2015 05:41 PM, Rod Smallwood wrote:
> >
> >> I'm pleased to be able to report the successful installation of OpenVMS
> >> 8.3 - Alpha on my  3000 M600
> >> It now runs Dec Windows on the graphics screen and a terminal on the
> >> serial port.
> >> TCPIP works and I can get to my local network OK.
> >>
> >> Now to find a browser. There must have been one
> >>
> >> Rod
> >>
> >>
> >> Rod,
> >
> > There is the Compaq Secure Web Browser, which is a horribly ancient
> > compile of netscape? Mozilla?  can't remember at the moment.
> >
> > http://h71000.www7.hp.com/openvms/products/ips/cswbs/cswbs.html
> >
> > It barely runs on my Dec 3000 w/ 192 MB of memory.
> >
> > There are VMS builds of lynx/links out there for VMS which run much
> > better, but as with all terminal based text web browsers are of dubious
> > utility.
> >
> > --Jason
> >
>



-- 
Bill
vintagecomputer.net

Backups [was Re: Is tape dead?]

2015-09-21 Thread Noel Chiappa

> From: tony duell

> In some cases it should be possible to write a machine code program
> that executes on 2 processors with wildly different instruciton sets.

I have this bit set that I was told (or something, the memory is _very_
vague) that early versions of the KL-10 had this hack; the root block on the
disk was the boot block both the PDP-10 and the PDP-11 front end machine, and
the first instruction or two was very cleverly construced and sent the two
machines different ways. Alas, I looked in the front-end PDP-11 code (in the
KLDCP; directory) and saw no signs of this, so maybe it was an urban legend?

Noel

Re: Calcomp 1039 plotter docs?

2015-09-21 Thread simon


Spot on. it HAS the 2114 ram chips. now to find replacements..

strange enough there are 12 positions for ram chips and two of them are 
left unpopulated: pos 1 and pos 7.



On 20-09-15 20:02, tony duell wrote:

Hi All,

we have a 1039 in our space with the user guide, but without any service
docs. Our specimen does not react to buttons except the reset and test
buttons. the four statusleds light up on a reset and after a second the
center two leds start blinking in sequence. paper and pens are loaded as
per the user guide.


Silly question... It doesn't happen to use 2114 RAMs does it? If so, check 
and/or
replace them. I've foudn such RAM in printers/plotters from many manufacturers
and perhaps 90%+ of electronic problems are caused by them.

-tony



--
Met vriendelijke Groet,

Simon Claessen
drukknop.nl

RE: Multi-platform distribution format (Was: Backups [was


>
> > Epson PX8?
> 
> That's a commercial or industrial system?  Did it run an EDM setup,
> turret lathe  or vacuforming machine?  Anyone keep their AR, AP, GL,
> payroll and inventory on one?   I doubt that one could run a PBX.

I guess it depends on what you call a 'commercial' system. I certainly
wouldn't class the PX8 as a home computer.

> I never looked at the Geneva or QX-10 as much more than word processing
> setups.

Then IMHO you didn't look at them carefully. I think the QX10 is one of the 
best 
all-in-one (as opposed to S100 bus, say) CP/M machines. Good graphics, 256k
(bank switched) RAM, those nice Epson voice-coil drives, RS232 and Centronics
interfaces, expansion slots if you need more, good documentation, etc, etc, etc
It certainly is a lot more than a word processing system.

-tony



--Chuck

Re: Backups [was Re: Is tape dead?]

2015-09-21 Thread Pontus Pihlgren

On Mon, Sep 21, 2015 at 09:15:13AM -0400, Noel Chiappa wrote:
> > From: tony duell
> 
> > In some cases it should be possible to write a machine code program
> > that executes on 2 processors with wildly different instruciton sets.
> 
> I have this bit set that I was told (or something, the memory is _very_
> vague) that early versions of the KL-10 had this hack; the root block on the
> disk was the boot block both the PDP-10 and the PDP-11 front end machine, and
> the first instruction or two was very cleverly construced and sent the two
> machines different ways. Alas, I looked in the front-end PDP-11 code (in the
> KLDCP; directory) and saw no signs of this, so maybe it was an urban legend?
> 
>   Noel


Perhaps you are thinking of the 1984 ioccc winner:

http://www.ioccc.org/1984/mullender.c
http://www.ioccc.org/1984/mullender.hint

/P

Re: Calcomp 1039 plotter docs?

2015-09-21 Thread simon


Sounds good. Docs are much appriciated.

Our printer has three boards inside, one processor, one pen driver and i 
forgot what the thirdt was. Next time i will take photo's of that card 
as well.


simon

On 21-09-15 08:45, Erik Baigar wrote:


Hi All,

the 1039 is an interesting plotter I have got a 1038/1039 as well: There are two
big
PCBs inside - one is for the low level functions (essentally driving the servos
and
drawing lines using TTL implemented Bresenham) the second one contains the
computer (68xx based) which is handling the communication.

So for simply moving the pens with the arrow buttons, the computer PCB may not
be
necessary. Have you tried this?

The computer PCB controls the LEDs and blinking may well indicate a problem on
the computer PCB - I thinke I have got a set of documentation. But unfortunately
it is
stored away, but surely I can do a search within the next four weeks if there is
real interest. I even read out the bipolar PROMs of the processor card for
safety
some years ago...

 Erik, e...@baigar.de



tony duell  hat am 20. September 2015 um 20:02
geschrieben:



Hi All,

we have a 1039 in our space with the user guide, but without any service
docs. Our specimen does not react to buttons except the reset and test
buttons. the four statusleds light up on a reset and after a second the
center two leds start blinking in sequence. paper and pens are loaded as
per the user guide.


Silly question... It doesn't happen to use 2114 RAMs does it? If so, check
and/or
replace them. I've foudn such RAM in printers/plotters from many manufacturers
and perhaps 90%+ of electronic problems are caused by them.

-tony




--
Met vriendelijke Groet,

Simon Claessen
drukknop.nl

Some amount of DG goodness

I decided to raid the front panel of my S/200 to get a switch cover and a
switch for the S/130; what can I say - I got antsy to see if the S/130
worked ;) When taking the S/200 front panel apart I found it really wasn't
in great shape as it had appeared to be from the outside. A large number of
the incandescents had broken off and were sitting loose and one of the
switch covers was broken so someday I'll return to the S/200 but the S/130
restoration was completed as a result. 

Pictures (completely out of order) are at
https://www.flickr.com/photos/131070638@N02 but the first picture shows the
cpu up.

Once or twice, running the microcoded self-test produced a "Rom Error", but
almost always it produces the desired result and loops on that test (checks
microcode checksum, ability to execute and step microcode, a few CPU
instructions & paths, and tests the lowest 16Kw of ram). Raising switch 0
halts cpu at microcode address 2 just as it should.

I also noticed that on rare occasion, hitting "examine" on AC1 produces no
result - but other than that I can store and read AC0-3 as well as several
different sections of memory. 

Next step is to locate a 4045 board and see if I can get a console hooked
up. After that, I'll need some way to get diagnostics into the machine. To
that end, I could try restoring a HD, 8" diskette, paper tape, or dual
cassette drive - but I'm wondering if there is any previous art for entering
a front panel ditty and stuffing diags down the console port (from a PC)?
Yes, google is my next stop ;)

Thanks to several listmembers and especially Bruce for pointers and advice,
as documentation is scarce and not organized the way my brain works. 

Best,

J

Structured Fortran - was Re: Self modifying code, lambda calculus

2015-09-21 Thread Toby Thain


On 2015-09-21 5:58 PM, Paul Koning wrote:



On Sep 21, 2015, at 5:33 PM, Chuck Guzis  wrote:

On 09/21/2015 01:37 PM, Dave G4UGM wrote:


I wrote X.25 software in Fortran:-(. We had some machine specific
routines to allow the Fortran code to wait for a packet to arrive.
There was also a huge vector of strings with matching integer arrays
that allowed them to be chained together, and to have types allocated
to them There were also a large number of "INCLUDE" files with a
parameters which defined the structure of data stored in the
character vectors


PASCAL was first implemented in FORTRAN.


Really? I find it hard to imagine that Wirth would use Fortran for a

compiler. Never mind his background in structured languages -- writing a
compiler in Fortran is just much harder. Not as hard as writing one in
COBOL, but still...




Almost bearable in Ratfor/WATFOR/WATFIV though. Ref: "Elements of 
Programming Style."


https://en.wikipedia.org/wiki/Ratfor

--Toby


paul

Re: Multi-platform distribution format (Was: Backups [was


>Johnny Billquist wrote:


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. 


This would be the Qbus controller. And that is an annoying detail, 
yes. You need a bounce buffer in the low part of memory. One of a few 
Qbus controllers with 18-bit addressing for DMA.


Well, it was an early controller and since it was for a floppy
drive and the problem was really only with a Mapped RT-11
Monitor when the user buffer was in extended memory above
1/4 MB, it really was not a major problem.   What actually
might be more of a problem (if I ever finish the job of placing
the code and bounce buffer into extended memory) is making
sure that the portion of extended memory is below 1/4 MB.
That would be the responsibility of the installation code to
allocate the memory and check to make sure that the bounce
buffer is below 1/4 MB. 


I guess that could also be done with the RK05 controller
and the original RL01 / RL02 controller.  The latter versions
of the RL01 / RL02 controller support 22-bit user buffer
addresses.  What about tape controllers?

And then there is the problem of making sure that other programs
and device drivers don't gobble up the memory below 1/4 MB
which they don't actually require.  That aspect, it turns out is
actually very easy to solve.  The code to allocate any extended
memory in RT-11 normally allocates memory from the bottom
up.  However, it is possible to change a single word of just one
of the instructions in the XALLOC subroutine in RT-11 so that
all of the memory is allocated from the top down!  And since it
is a single word being changed, it is not even necessary to stop
interrupts while it is being done.  Eventually I want to write the
code for XAX.SYS which will support:
SET  XA  HIGH
SET  XA  LOW
SET  XA  TOGGLE
SET  XA  BOOT=[LOW,HIGH]
SET  XA  SHOW
SET  XA  HELP
and allow the user to control how extended memory is allocated
under a Mapped RT-11 Monitor.

R  RESORC /Z
already provides the current setting, otherwise provided by:
SHOW  CONFIGURATION

I guess I could check the setting in DYX.SYS before I allocate
the extended memory and toggle the setting back after the
extended memory is allocated.


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,

Re: Multi-platform distribution format (Was: Backups [was


On 2015-09-21 19:20, Paul Koning wrote:



On Sep 21, 2015, at 12:47 PM, Johnny Billquist  wrote:
...

I suppose you could on a Pro, since that had its own particularly disgusting 
junk controller.  But I haven't seen RX50 formatting there.  My impression was 
that they came factory formatted, with the DEC-specific 10 sector per track 
format.


Ugh! The PRO controller probably was weird enough to not allow you, even though 
as far as I understand, it was also way more primitive than MSCP.


Way more primitive is a polite way of putting it.  Just like all other PRO 
controllers DEC ever built, it uses programmed I/O.  The curious thing is that 
the PRO bus actually appears to support DMA, but it was never used, not even 
for the hard drive or network interface.  All those devices do I/O to on-card 
memory, and then the driver has to move it to/from host memory.


DECs various decisions related to the PRO are probably a mystery to all.


I haven't tried this, but the PRO technical manual (on Bitsavers) shows that 
(a) there is no way to do formatting, but (b) you can configure the controller 
to accept, for reading but not writing, various non-RX50 formats.


Interesting. I haven't even tried digging that deep into the 
documentation. If I ever found the drivers for the hardisk and floppy 
for P/OS I could possibly consider trying to build something more purely 
RSX-like, but I doubt that will happen.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: Self modifying code, lambda calculus - Re: ENIAC programming


On 2015-09-21 21:18, Fred Cisin wrote:

[...] a first encounter with the notion, at least for me, involved
FORTRAN, not any language.  [...]

I've always thought of FORTRAN as a language, so I am clearly
missing something here.  What?

Probably a misspeak.   But FORTRAN is more than simply a
language--it's a way of life.  :)


A REAL programmer can write a FORTRAN program in any language.


And GOD is REAL unless declared INTEGER... Yes, FORTRAN is fun. :-)

Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: PDP-11 Overlays


On 2015-09-21 21:41, Paul Koning wrote:



On Sep 21, 2015, at 3:14 PM, Jerome H. Fine  wrote:

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?


RSTS has no specific structure of its own.  It provided both RT-11 and RSX 
emulation, and as a result would offer the structures from both of those, 
depending on which environment you chose for a particular application.


Right. In a way you could say that in RSTS/E you pick the best solution 
for the job. No need to tie yourself one way or the other. I wonder, did 
anyone ever write a Unix RTS for RSTS/E? It should be doable...



RSX uses a tree structure.  For details (lots of details) see the TKB manual.


Indeed. The TKB manuals is what Jerome needs to read if he really wants 
to know...



Suppose you have main which calls o1.  o1 calls o2 which calls o3, and o1 also 
calls o5 which calls o6.

In the RSX case, you could specify a tree with two branches: main to o1 and 
from there o2 to o3, and o5 to o6.  In the RT11 case, you might put o1 in 
region 1, o2 and o5 in region 2, and o3 and o6 in region 3.

The memory requirements would be:

rt11: main + o1 + max (o2, o5) + max (o3, o6)
rsx:  main + o1 + max (o2 + o3, o5 + o6)

If o2 and o6 are large while o3 and o5 are small, then the RSX case gives you a 
smaller memory footprint.


No need to stop there. Like you said, it is a tree. And exactly how many 
branches, how deep, or how much you put in each "node" is up to you. But 
in addition, you also have co-trees. No need for just one tree. You can 
have many. The only rules are that you cannot call something up the 
tree, except to the root.
With co-trees, you get several roots. Which means, in turn, that you can 
have several branches that all call the same routine, even though that 
routine is also in an overlay, since this will not break the tree 
structure. (Assuming the routine you call is in another co-tree.)
In addition, overlays in RSX can be either autoloading, or you can write 
your own code to actually do the loading. And overlays can either be 
disk resident, or memory resident. Memory resident overlays are way 
faster, since they work by instead doing PLAS calls to just change the 
task mappings, and do not involve the disk at all. However, that also 
means that your overlays always start on an even 8K.
The whole thing can become very complex, and you have a whole language 
to describe how your overlays are laid out, relates to each other, how 
they are loaded, and so on. It's called the Overlay Description 
Language, or ODL. The largest ODL-file I've ever done was for DUNGEON 
version 3.2 (sorry, will only fit on RSX-11M-PLUS), and that thing is 70 
lines of stuff. A few empty lines, but mostly code.
The largest I've touched is for RMD, which weights in at 177 lines to 
describe the overlay structure.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: Backups [was Re: Is tape dead?]


On 2015-09-21 23:32, David Brownlee wrote:

On 21 September 2015 at 01:55, Jerome H. Fine  wrote:

Fred Cisin wrote:



On Sun, 20 Sep 2015, Jon Elson wrote:


Well, one would assume this is also OS specific.  I would guess it would
be incredibly hard to make a "disk" virus that would work on greatly
differing OS's like Linux AND Windows.  No telling what would happen if one
of these disk viruses got onto a hard drive on a Windows system and then the
drive was reformatted and loaded with Linux.
Most likely you'd have odd crashes or something.




It is possible to create an executable file that identifies the OS that it
is running on and does a conditional jump to different code, assuming that
the processor uses the same instruction set.

How different the OS's are would determine how much code could be shared.
If they are very different, then the executable file could be twice as
large, with no code in common.


It is even possible to make a disk that is readable as multiple disk
formats, so long as each is expecting the DIRectory tracks to be in
different places.
One of the many projects that I never got ready for market was to make a
multi-platform distribution format for software.  "Save a few cents on media
costs by putting all of your platforms on one disk"  But, after August 1981,
it eventually became apparent that the need for such was not going to be
around much longer.

If the boot code is short enough, it is even possible to have an FM, an
MFM, and a GCR boot sector in the same boot track, since each will not even
see any except its own.  Formatting/recording a track with mixed densities
and/or encodings and multiple sector sizes is not a supported function in
most operating systems, nor even FDCs, but can be done with some flux
transition controllers.



I used the above example when I created a CD which had files to be used
with RT-11 in addition to being a normal CD under Windows.  I found that
for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
on the CD were empty.  I don't know if that area is reserved for boot code
under Windows when the CD is bootable, but my goal did not require the
CD to be bootable under Windows.

Under RT-11, the first six hard disk blocks (0 to 5) are reserved for boot
code (when that is present) and hard disk blocks from 6 up to 67 are used
for an RT-11 directory.  RT-11 rarely uses that large a directory and the
minimum directory is only two hard disk block long.  For the CD, that
allowed an RT-11 directory from hard disk blocks 6 to 63 or up to
sector 15.

What may have been unique was that only the RT-11 directory and the
CD  ISO directory were distinct.  Otherwise, all the files were the same
with each directory pointing to the same location on the ISO image.

In practice, the same CD could be used as a data CD under Windows
in addition to being a boot disk on a real DEC  RT-11 system which
supported that operating system.  I was actually on the phone at one
point when the first individual who received a copy of the CD used
it to boot RT-11 on a CDROM drive configured to support 512 byte
blocks using a CQD 220/TM host adapter.

The same ISO image file can also be used under both SimH and Ersatz-11
in the same manner, although it is STRONGLY recommended that the
ATTACH or MOUNT command use the ISO image file as READ  ONLY.
Ersatz-11 is also able to MOUNT the actual RAW CD on a CDROM
SCSI drive and boot RT-11 from the CD.  Of course, the Windows
operating system under which Ersatz-11 is also able to see all the same
files on the CD as well, BUT  NOT  AT  THE  SAME  TIME - at
least I never did attempt that possibility.

If this can be done with Windows and RT-11 which have completely
different file structures and instructions sets, it certainly seems likely
that other operating systems and system hardware can also be supported.
The one thing that seemed reasonable from a security point of view is
that the CD is READ  ONLY, so no virus can be introduced on the
CD after it is burned.

Tim Shoppa did almost the same thing with his RT-11  Freeware CD
when an RT-11 directory was added at the end of the ISO image file
for the CD.

If anyone finds this interesting and has additional questions, please ask.


Before the price of media and storage dropped so much NetBSD install
ISOs were multiboot - one image which booted on alpha, i386, pmax, and
sparc (and I think theoretically also macppc, vax and sun2, sun3 and
sun3x if it hadn't run out of room for the install files :)
http://www.netbsd.org/docs/bootcd.html#multiimage

So much cool stuff no-one bothers with now days...


I actually did boot NetBSD/vax from CD at one point, so it worked in 
practice as well.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: Multi-platform distribution format (Was: Backups [was


On 2015-09-22 03:09, Jerome H. Fine wrote:

 >Johnny Billquist wrote:


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.


This would be the Qbus controller. And that is an annoying detail,
yes. You need a bounce buffer in the low part of memory. One of a few
Qbus controllers with 18-bit addressing for DMA.


Well, it was an early controller and since it was for a floppy
drive and the problem was really only with a Mapped RT-11
Monitor when the user buffer was in extended memory above
1/4 MB, it really was not a major problem.   What actually
might be more of a problem (if I ever finish the job of placing
the code and bounce buffer into extended memory) is making
sure that the portion of extended memory is below 1/4 MB.
That would be the responsibility of the installation code to
allocate the memory and check to make sure that the bounce
buffer is below 1/4 MB.
I guess that could also be done with the RK05 controller
and the original RL01 / RL02 controller.  The latter versions
of the RL01 / RL02 controller support 22-bit user buffer
addresses.  What about tape controllers?


Yes, it was an early controller, from before the Qbus actually was 
22-bit addressed.


RSX solves this by creating a partition when the driver comes online, 
and making sure this memory partition is below 256K. And then all DMA 
goes through that memory partition, and then the drive copies the data 
to the final destination when DMA finishes (or the reverse on writes).

All done only in the case it detects it's an RXV21 and not an RX211.


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.


Probably qualification differences. DEC only cared if one side was
good. So floppies with one bad side were still acceptable for DEC,
since they only used one side anyway.
Floppies sold as double sided needed to pass testing on both sides.


I would agree with your analysis if any of the other non-DEC floppy
brands had even a couple of floppies which had not accepted an LLF
for double-sided operation.  BUT,  NOT  EVEN  ONE??
It seems a bit unlikely unless DEC specifically managed to locate a
shipment at an excellent cost advantage and the

Re: Self modifying code, lambda calculus - Re: ENIAC programming


On 09/21/2015 06:23 PM, Mouse wrote:

Wirth & Co. started the project in FORTRAN, but gave up, particularly
when it was realized that implementing data structures and recursion
in FORTRAN was going to be a bit of a task.


I think that if I wanted to build a Pascal compiler in FORTRAN I would
build a p-code engine in FORTRAN and implement the compiler in that.

But I don't know if they had the concepts to do that.  Not that I think
that inventing a p-code engine was beyond them, but it certainly would
have raised the bar.


Wirth and Co. didn't invent P-code.  I worked with a fellow who did a 
P-code implementation of COBOL back in the 60s (it ran in a 6600 PP).


--Chuck

RE: The desk has arrived - WAS: Somewhat OT: Freighting Items

2015-09-21 Thread Ali

> Thanks for sharing the pictures, and I'm glad that the freighting
> worked out! Freight shipment is a bit weird at first, until you get
> used to it.

Mark,

I am excited to get it home! The seller sent me the keys separately and
unfortunately they just arrived today. So it may be a week or two until I
can open it up and see how the inside did

Re: The desk has arrived - WAS: Somewhat OT: Freighting Items


> On Sep 21, 2015, at 18:55, Ali  wrote:
> I am excited to get it home! The seller sent me the keys separately and
> unfortunately they just arrived today. So it may be a week or two until I
> can open it up and see how the inside did

I would have picked the locks, but that's just how I roll. :)


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Self modifying code, lambda calculus - Re: ENIAC programming

2015-09-21 Thread Al Kossow


On 9/21/15 2:33 PM, Chuck Guzis wrote:


PASCAL was first implemented in FORTRAN.



Was there something before 
http://bitsavers.org/pdf/eth/pascal/ETH_Pascal_Listing_Nov72.pdf ?

looks like 6600 assembler to me

RE: vintage datacenter furniture

2015-09-21 Thread Ali

> 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?
> 
Ben,

Funny you should ask. I just made a minis post about it here:
http://megacube.classiccmp.org/Synergetix/Synergetix.html

The web page is very preliminary but should give you an idea

-Ali

Re: Self modifying code, lambda calculus - Re: ENIAC programming


On 09/21/2015 02:58 PM, Paul Koning wrote:


PASCAL was first implemented in FORTRAN.


Really?  I find it hard to imagine that Wirth would use Fortran for a
compiler.  Never mind his background in structured languages --
writing a compiler in Fortran is just much harder.  Not as hard as
writing one in COBOL, but still...


Well, that was a wink-wink-nudge-nudge statement from yours truly. 
Wirth & Co. started the project in FORTRAN, but gave up, particularly 
when it was realized that implementing data structures and recursion in 
FORTRAN was going to be a bit of a task.  I think the result was 
bootstrapped.  I've got a copy of the ETH CDC compiler from 1976, 
bearing Urs Amann's name as the author.  It isn't exactly Pascal, either.


But if the issue really was data structures, maybe COBOL would have been 
a better choice.  I do recall that there was at least an Algol-60 
compiler on CDC iron at that time.


--Chuck

vintage datacenter furniture

2015-09-21 Thread Benjamin Huntsman

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

Re: Multi-platform distribution format (Was: Backups [was


>tony duell wrote:


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


It is. Remember the RX50 is just a drive, it does not include any of
the controller electronics.


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

It's more the reverse!. The Rainbow just has a standard controller chip on the 
processor bus (I forget which processor, I can look at the schematics if you

want). The controller chip can do what is needed for a LLF, and there is
nothing in the way to prevent software from sending the commands to do
that.


Well that is a reverse explanation!  Completely opposite of
what I thought might be the actual situation.


On the PDP11 there is a lot more stuff between the processor and the disk
controller chip. Even the Pro 300 series has a microcontroller (8051?) on
the floppy controller board. Therefore the processor you can program
(PDP11) can't do arbitrary things to the disk controller chip, it is very likely
that sending the right commands to do an LLF is one of the things you
can't do.


HOWEVER, while the PDP-11 is still unable to perform an
LLF on an RX50 when an RQDX3 is present, it is possible
to perform an LLF on a floppy in an RX33.  Does that still
seem compatible with your explanation?

I would not attempt a trick question with you since I don't
know enough to set one up.  Again, I am just trying to
understand what DEC did and how DEC managed to
still avoid being able to perform an LLF on an RX50
using an RQDX3, yet supported an LLF right from
RT-11 on the RX33 using an RQDX3?

The one time I watched it being done, I nearly fell off
my chair in astonishment.  After all those decades using
the PDP-11, I was finally allowed to FORMAT a floppy
and it actually worked.  Of course, the floppy in question
was identical to a HD 5 1/4" PC floppy which any PC
at that time would also be able to FORMAT.  And in
any case, the floppies were usually sold with a FORMAT.
So all that would normally be needed would be the
INITIALIZE command.  But it would be nice to be
able to understand how the RQDX3 can FORMAT
an RX33, but not an RX50.  I also have an RX23
drive on a CQD 220/TM which I have never tried.
But since that is a non-DEC host adapter, I don't
think it counts,

Jerome Fine

Re: Reading a masked ROM the hard way (was Re: Wanted: ROM images from HP 9895, 82901/82902, and other HP-IB disk drives)

2015-09-21 Thread Eric Smith

Of course, that's not the hardest way. You could also do this:
http://www.pmonta.com/calculators/hp-35/

I have a few chips that I'll need to do that to, where the ROM is
embedded and can't be read out electrically. Unfortunately the chips
are in a much finer geometry than the HP-35 chips, so it's much more
difficult.

Re: Self modifying code, lambda calculus - Re: ENIAC programming


> On Sep 21, 2015, at 5:33 PM, Chuck Guzis  wrote:
> 
> On 09/21/2015 01:37 PM, Dave G4UGM wrote:
> 
>> I wrote X.25 software in Fortran:-(. We had some machine specific
>> routines to allow the Fortran code to wait for a packet to arrive.
>> There was also a huge vector of strings with matching integer arrays
>> that allowed them to be chained together, and to have types allocated
>> to them There were also a large number of "INCLUDE" files with a
>> parameters which defined the structure of data stored in the
>> character vectors
> 
> PASCAL was first implemented in FORTRAN.

Really?  I find it hard to imagine that Wirth would use Fortran for a compiler. 
 Never mind his background in structured languages -- writing a compiler in 
Fortran is just much harder.  Not as hard as writing one in COBOL, but still...

paul

Re: Calcomp 1039 plotter docs?

2015-09-21 Thread Jon Elson


On 09/21/2015 01:45 AM, Erik Baigar wrote:
  
Hi All,
  
the 1039 is an interesting plotter I have got a 1038/1039 as well: There are two

big
PCBs inside - one is for the low level functions (essentally driving the servos
and
drawing lines using TTL implemented Bresenham) the second one contains the
computer (68xx based) which is handling the communication.
  
Hmm, that sounds like my 1076C.  One board had a 68000 that 
ran the plotter servos, the other was the "plot manager" 
that had a big RAM buffer and sorted the plot vectors for 
optimum speed.  I think it mostly communicated with the host 
computer and plotter main board by serial.  Both boards had 
68K processors.


Jon

Re: DG S/130 front panel switches?

I will contact you off-list.

JRJ

On 9/19/2015 11:46 AM, Jay West wrote:
> So does anyone have a trashed/dead front panel for a Data General S/130
> (S/200 would also work) that can be a donor? All I need are two
> switches/paddles/Covers, but my S/200 front panel is perfect so I don't want
> to rob from that for the S/130 project. One light blue, one dark blue...
> Crossing my fingers.
> 
> J
> 
> 
>

Re: Calcomp 1039 plotter docs?

2015-09-21 Thread Erik Baigar


> Jon Elson  hat am 21. September 2015 um 17:47
> geschrieben:
> Hmm, that sounds like my 1076C. One board had a 68000 that
> ran the plotter servos, the other was the "plot manager"
> that had a big RAM buffer and sorted the plot vectors for
> optimum speed. I think it mostly communicated with the host
> computer and plotter main board by serial. Both boards had
> 68K processors.
 
Well, the 103x really had the 68xx, not the 68xxx. I think it was a 6802, but
not sure now...

Re: Multi-platform distribution format (Was: Backups [was

> On Sep 21, 2015, at 12:28 PM, Jay Jaeger  wrote:
> 
> On 9/21/2015 4:30 AM, Johnny Billquist wrote:
> 
>> On 2015-09-21 02:11, Jerome H. Fine wrote:
 Chuck Guzis wrote:
>>> 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
>> 
> 
> There was also a standalone PDP-11 diagnostic program available that
> could do it.

For RX50?  On standard PDP11s, those used an MSCP controller, which means the 
controller would have to do it.  Did it?  The only MSCP controller I remember 
that did formatting was the UDA50.

I suppose you could on a Pro, since that had its own particularly disgusting 
junk controller.  But I haven't seen RX50 formatting there.  My impression was 
that they came factory formatted, with the DEC-specific 10 sector per track 
format.

paul

RE: Multi-platform distribution format (Was: Backups [was

> 
> Not CP/M admittedly, but small contemporary
> Burroughs machines certainly used cassettes, both
> for program and data storage. I wrote several
> fairly complex diskless accounting systems using
> four cassette drives, one or two card readers and
> a line printer (in addition to the console
> printer).
> 
> Why not; not much different conceptually after all
> from early systems using open-reel mag tape, or
> even punch(ed) cards.

I feel there are 2 distinct types of cassette system from the
user perspective. 

The first is the sort used on 1980s home computers with a
standard or slightly modified (Commodore, Atari) audio
cassette recorder. These needed considerable manual
intervention to position the tape (rewind, fast forward),
select record or play mode, etc. Essentially only useable
for loading/saving programs and sequential files

The second has the tape mechanism under computer control
like the HP9830 (HP9865 add-on drive too), this Burroughs
the PX8, etc. With these you can load particular files, rewrite
files, possibly have a block-structured file system. Often these
units (but not the PX8) used a special tape with a different
coercivity to audio tape.

The second type would seem to be entirely useable for
'business' computing before floppy drives were 
available. I am not so sure about the first type :-)

-tony

Re: Multi-platform distribution format (Was: Backups [was

2015-09-21 Thread Mike Stein


Not CP/M admittedly, but small contemporary
Burroughs machines certainly used cassettes, both
for program and data storage. I wrote several
fairly complex diskless accounting systems using
four cassette drives, one or two card readers and
a line printer (in addition to the console
printer).

Why not; not much different conceptually after all
from early systems using open-reel mag tape, or
even punch(ed) cards.

m

- Original Message - 
From: "Chuck Guzis" 

To: "General Discussion: On-Topic and Off-Topic
Posts" 
Sent: Monday, September 21, 2015 1:42 AM
Subject: Re: Multi-platform distribution format
(Was: Backups [was



On 09/20/2015 09:55 PM, tony duell wrote:




Gee, I thought we were talking about CP/M
here.  How many CP/M
systems used cassette for storage.  Better
yet, how many
commerical/industrial CP/M systems used
cassettes for program
storage.


Epson PX8?


That's a commercial or industrial system?  Did
it run an EDM setup, turret lathe  or
vacuforming machine?  Anyone keep their AR, AP,
GL, payroll and inventory on one?   I doubt that
one could run a PBX.

I never looked at the Geneva or QX-10 as much
more than word processing setups.

--Chuck

Re: IBM 026 - Decision Data 8010 card punch on Ebay in

2015-09-21 Thread Marc Verdiell

Wow. Thanks for sharing. What a beautiful looking machine. I hope one of us
gets it.
Marc

=
Date: Mon, 21 Sep 2015 18:36:20 +0200
From: Mattis Lind 
Not really a 026 but maybe contemporary with the 029:
http://www.ebay.de/itm/Historische-EDV-Lochkartenstanzer-Card-Punch-von-1973
-2000-Lochkarten-/371439456530?hash=item567b845112
Not mine.

RE: Multi-platform distribution format (Was: Backups [was

> Why not; not much different conceptually after all
> from early systems using open-reel mag tape, or
> even punch(ed) cards.

On Mon, 21 Sep 2015, tony duell wrote:

I feel there are 2 distinct types of cassette system from the
user perspective. 

The first is the sort used on 1980s home computers with a
standard or slightly modified (Commodore, Atari) audio
cassette recorder. These needed considerable manual
. . . 
The second has the tape mechanism under computer control
. . . 
The second type would seem to be entirely useable for
'business' computing before floppy drives were 
available. I am not so sure about the first type :-)

and, of course, as a third type, Exatron Stringy-Floppy
computer based, but NOT entirely usable.

Sheet Metal Fabrication Options?

2015-09-21 Thread Jim Brain

I was wondering if anyone has or knows anyone who has experience with 
low volume sheet metal enclosure fabrication?  I am looking for a 
fabricator to build small (think game cartridge enclosure sizes) 
clamshell units (or similar).


I thought before I start cold calling folks, I'd see if someone has 
already had some success.


--
Jim Brain
br...@jbrain.com
www.jbrain.com

Re: Sheet Metal Fabrication Options?

2015-09-21 Thread Sue Skonetski

There are a lot of folks in VMS on the metal fabrication and I just happen to 
know someone that has opened a small volume fabrication company on Cape Cod.  
Do I have your ok to forward?

Sue


> On Sep 21, 2015, at 1:51 PM, Jim Brain  wrote:
> 
> I was wondering if anyone has or knows anyone who has experience with low 
> volume sheet metal enclosure fabrication?  I am looking for a fabricator to 
> build small (think game cartridge enclosure sizes) clamshell units (or 
> similar).
> 
> I thought before I start cold calling folks, I'd see if someone has already 
> had some success.
> 
> -- 
> Jim Brain
> br...@jbrain.com
> www.jbrain.com
> 

Sue Skonetski

VP of Customer Advocacy
sue.skonet...@vmssoftware.com
Office: +1 (978) 451-0116
Mobile: +1 (603) 494-9886







Mit freundlichen Grüßen – Avec mes meilleures salutations

Re: Sheet Metal Fabrication Options?

2015-09-21 Thread Jim Brain


On 9/21/2015 12:54 PM, Sue Skonetski wrote:

There are a lot of folks in VMS on the metal fabrication and I just happen to 
know someone that has opened a small volume fabrication company on Cape Cod.  
Do I have your ok to forward?

Yep, please do.

Jim

Re: Multi-platform distribution format (Was: Backups [was


On 09/21/2015 10:22 AM, tony duell wrote:


Have you ever read the technical manual for the QX10?

It appears there were 2 keyboards sold for it. One had Valdocs-specific
keys, the other (which seems more common over here, not that the QX10
is a common machine) doesn't and was used for a more standard
CP/M system.


Yes, as well as a fair amount of TP/M source code.  It's just that the 
QX-10s strong selling point was Valdocs and that's mostly why people 
bought the thing.


On the subject of cassette machines, here's one:

https://www.youtube.com/watch?v=G8oXxO5FT3A

1991, 68K-based controller, dual color CRT with graphics.  Some have 
been upgraded to floppy--if so, they're running CP/M 68K, but this 
appears to be the original cassette model.


--Chuck

Re: Multi-platform distribution format (Was: Backups [was

>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

Re: IBM 026 - Decision Data 8010 card punch on Ebay in Germany

2015-09-21 Thread Mattis Lind

Not really a 026 but maybe contemporary with the 029:

http://www.ebay.de/itm/Historische-EDV-Lochkartenstanzer-Card-Punch-von-1973-2000-Lochkarten-/371439456530?hash=item567b845112

Not mine.

RE: IBM 026 - Decision Data 8010 card punch on Ebay in Germany

That is simply gorgeous.

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/21/2015 02:24 AM, Johnny Billquist wrote:

CHAIN is in no way similar to overlays. COMMONs, if available, is a
nice way to preserve some data between different programs running.
CHAIN is (like someone said), about the same as a LOAD followed by a
RUN.

So, how is this different than overlays? Well, with overlays, you
only replace parts of your code. Some other parts stay around, as
well as all volatile data. So, you can still call code that is in the
resident part of memory, and which is not replaced by a different
overlay.

And yes, there are BASICs that can work with overlays. See DECs
BASIC+2. Has both commons, overlays and CHAIN. And if run under
RSTS/E if also have a core common block, which can be used to pass
data between programs when CHAINing.

I wonder what FORTRAN-style overlay hierarchy means. I know of
overlays, and on DEC OSes, it is a common technique, provided by the
linker, and is not tied to a specific language.

That's true--but a first encounter with the notion, at least for me,
involved FORTRAN, not any language. For example, consider that in the
CDC FTN reference, overlays are put ahead of I/O.

http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/lang/fortran/60174900F_FTN_2.3_Ref_Jul72.pdf

PDF page 77 et seq.

I did say that the CHAIN statement was the equivalent of overlaying the
(0,0) overlay and perhaps the above reference shows what I mean.

COBOL also used overlays, and they were part of the standard language
and worked somewhat differently. See

http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/lang/cobol/60191200_COBOL_Reference_Jun67.pdf

PDF page 73 et seq.

I do know what the BASIC CHAIN statement means.

In the early 80s, I headed a team that implemented a multi-user
commercial BASIC on an 8085 micro system, eventually migrated to XENIX
and was in use in some places up until a few years ago. I still have a
couple of the design documents in my files--as well as the mandatory
(for then) t-shirt and coffee mug.

One of the lessons I learned from the experience is that compilation to
native machine code does not always result in faster code than P-code
implementations.

--Chuck

RE: Multi-platform distribution format (Was: Backups [was


> 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

It is. Remember the RX50 is just a drive, it does not include any of
the controller electronics.

> 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

It's more the reverse!. The Rainbow just has a standard controller chip on the 
processor bus (I forget which processor, I can look at the schematics if you
want). The controller chip can do what is needed for a LLF, and there is
nothing in the way to prevent software from sending the commands to do
that.

On the PDP11 there is a lot more stuff between the processor and the disk
controller chip. Even the Pro 300 series has a microcontroller (8051?) on
the floppy controller board. Therefore the processor you can program
(PDP11) can't do arbitrary things to the disk controller chip, it is very likely
that sending the right commands to do an LLF is one of the things you
can't do.

-tony

Re: Multi-platform distribution format (Was: Backups [was

> On Sep 21, 2015, at 12:47 PM, Johnny Billquist  wrote:
> ...
>> I suppose you could on a Pro, since that had its own particularly disgusting 
>> junk controller.  But I haven't seen RX50 formatting there.  My impression 
>> was that they came factory formatted, with the DEC-specific 10 sector per 
>> track format.
> 
> Ugh! The PRO controller probably was weird enough to not allow you, even 
> though as far as I understand, it was also way more primitive than MSCP.

Way more primitive is a polite way of putting it.  Just like all other PRO 
controllers DEC ever built, it uses programmed I/O.  The curious thing is that 
the PRO bus actually appears to support DMA, but it was never used, not even 
for the hard drive or network interface.  All those devices do I/O to on-card 
memory, and then the driver has to move it to/from host memory.

I haven't tried this, but the PRO technical manual (on Bitsavers) shows that 
(a) there is no way to do formatting, but (b) you can configure the controller 
to accept, for reading but not writing, various non-RX50 formats.

paul

Re: Backups [was Re: Is tape dead?]

On 2015-09-21 15:15, Noel Chiappa wrote:

 > From: tony duell

 > In some cases it should be possible to write a machine code program
 > that executes on 2 processors with wildly different instruciton sets.

I have this bit set that I was told (or something, the memory is _very_
vague) that early versions of the KL-10 had this hack; the root block on the
disk was the boot block both the PDP-10 and the PDP-11 front end machine, and
the first instruction or two was very cleverly construced and sent the two
machines different ways. Alas, I looked in the front-end PDP-11 code (in the
KLDCP; directory) and saw no signs of this, so maybe it was an urban legend?

I suspect that would be an urband legend, as the KL10 is booted by the 
PDP-11, and does not, on its own, start reading something from the disk 
to start executing. Or at least that is how I remember things...

However, the PDP-11 FE filesystem exists, as a plain file, in the 
PDP-10s file system (TOPS-10 or Tops-20).

Johnny

RE: Calcomp 1039 plotter docs?



> Spot on. it HAS the 2114 ram chips. now to find replacements..

The slight delay after power-on before giving the error indication suggested
a memory test to me...

Of course it might not be 2114 problems, but I have replaced so many of those
ICs over the years in all sorts of devices that I suspect them on sight now :-)


> strange enough there are 12 positions for ram chips and two of them are
> left unpopulated: pos 1 and pos 7.

2114s are normally used in pairs,, of course. They are 1K*4 RAMs, so it takes 2 
to make a byte. I hope some kind person hasn't 'borrowed' a couple of RAMs
from the plotter, that would be nasty.

-tony

Re: Backups [was Re: Is tape dead?]

> On Sep 20, 2015, at 8:55 PM, Jerome H. Fine  wrote:
> 
>> ...
> 
> I used the above example when I created a CD which had files to be used
> with RT-11 in addition to being a normal CD under Windows.  I found that
> for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
> on the CD were empty.  I don't know if that area is reserved for boot code
> under Windows when the CD is bootable, but my goal did not require the
> CD to be bootable under Windows.

I did something similar a long time ago, when some people at DEC were working 
to create an "Everything for RSTS/E" CD (similar, I think, to what was done for 
VMS at that time).  In my utility "rstsflx" I added a mode to produce a split 
structure somewhat like what you mentioned, but simpler.  The RSTS file system 
looked like a CD file, and the rest of the CD looked like allocated space to 
the RSTS file system.

I heard rumors that the CD it was meant for was created, but I never actually 
saw one.

paul

RE: Multi-platform distribution format (Was: Backups [was

> 
> and, of course, as a third type, Exatron Stringy-Floppy
> computer based, but NOT entirely usable.

Along with its inferior friend the Sinclair Microdrive
which was entirely NOT useable.

-tony

Re: Multi-platform distribution format (Was: Backups [was

On 9/21/2015 11:34 AM, Paul Koning wrote:

> For RX50?  On standard PDP11s, those used an MSCP controller, which means the 
> controller would have to do it.  Did it?  The only MSCP controller I remember 
> that did formatting was the UDA50.
> 
> I suppose you could on a Pro, since that had its own particularly disgusting 
> junk controller.  But I haven't seen RX50 formatting there.  My impression 
> was that they came factory formatted, with the DEC-specific 10 sector per 
> track format.
> 
>   paul
> 

Acch.  Bad memory cells.  This actually was discussed back in 2002.
Some of the correspondents in that discussion are also denizens of this
mailing list, may recall I made the same mistake back then:

The diagnostic was/is:

BL-FN7AP-MC CZFNAP0 M-11 FORMTR RX50

So, just to verify, I fired up my 11/23 (which hasn't been on in YEARS),
which came right up, and inserted the floppy and booted it:

It formats:

RD51, RD52, RD53 on an RQDX1 or RQDX2
RD51, RD52, RD53, RD54, RD31, RD32, RX33 on an RQDDX2

Sorry for the confusion.

JRJ

Re: Multi-platform distribution format (Was: Backups [was

> On Sep 21, 2015, at 3:49 PM, Jerome H. Fine  wrote:
> 
> >Johnny Billquist wrote:
> 
>> >On 2015-09-21 17:03, Paul Koning wrote:
>> 
>>> And it would certainly be possible to write a driver that can handle both 
>>> controllers; it would start by determining which controller it's dealing 
>>> with, and then run the one or the other set of algorithms.  Since a boot 
>>> block is just a small driver, the same is true there, so long as the whole 
>>> body of code fits in the available space.  I suspect in this case that's 
>>> doable; most bootloaders (other than MSCP ones) require only a small 
>>> fraction of the available space. 
>> 
>> You are absolutely right.
>> And I don't know the actual size of the boot blocks. It might very well be 
>> that they both fits in the same boot block, which would be nice.
>> I know that the M9312 have separate boot roms for the RX11 and the RX211, 
>> but those boot roms are pretty tiny...
>> 
>> And I don't know if the RX211 boot rom also deals with RX01 floppies, but I 
>> would assume it does. 
> 
> I don't know how RSX-11 and RSTS/E manage their device
> drivers and allocate the memory for that code.  BUT, under
> RT-11, each device driver uses memory which the user program
> can't use. ...
> Finally, while the boot code could certainly support both
> the RX01 and the RX02 drive, there would be no point
> since the code in the device driver supports only one
> drive.

RSTS isn't as frugal with memory as RT11 is.  It has a bit of per-unit memory 
whether the device is present or not.  But the kernel can be built with all 
sorts of device drivers for devices that aren't actually present.  If so, those 
are disabled at boot.

So for RSTS, it certainly makes sense to have a multi-lingual boot block, if 
you're dealing with a medium that can be installed into several types of drives 
with different controllers.

The RX01/RX02 case doesn't occur for RSTS since those aren't supported as boot 
devices.  But the analogous scenario does apply to magtape.  The RSTS magtape 
boot block works with every PDP-11 controller capable of supporting that tape, 
so 1600 BPI tapes can boot on TU16, TS80 (gag) and TMSCP controllers.  Yes, 
that's a fun bit of code.

paul

RE: Self modifying code, lambda calculus - Re: ENIAC programming

2015-09-21 Thread Dave G4UGM

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck
> Guzis
> Sent: 21 September 2015 20:29
> To: General Discussion: On-Topic and Off-Topic Posts
> 
> Subject: Re: Self modifying code, lambda calculus - Re: ENIAC programming
> 
> On 09/21/2015 12:18 PM, Fred Cisin wrote:
> 
> > A REAL programmer can write a FORTRAN program in any language.
> 
> Conversely, several languages were initially written in FORTRAN--it was
> among the most portable in the early days.   Remember those programs
> that started out with a statement something like this?
> 
> 
> C  FIRST, GET THE CHARACTER SET
> 
> DIMENSION IALPHA(80)
> 
> READ 100,IALPHA
> 100FORMAT (80A1)
> 
> Not everyone spoke USASCII or EBCDIC back in the day--and character
> constants weren't part of most FORTRANs.
> 
> --Chuck

I wrote X.25 software in Fortran:-(. We had some machine specific routines
to allow the Fortran code to wait for a packet to arrive.
There was also a huge vector of strings with matching integer arrays that
allowed them to be chained together, and to have types allocated to them
There were also a large number of "INCLUDE" files with a parameters which
defined the structure of data stored in the character vectors

Dave

Re: Self modifying code, lambda calculus - Re: ENIAC programming


On 09/21/2015 12:18 PM, Fred Cisin wrote:


A REAL programmer can write a FORTRAN program in any language.


Conversely, several languages were initially written in FORTRAN--it was 
among the most portable in the early days.   Remember those programs 
that started out with a statement something like this?



C  FIRST, GET THE CHARACTER SET

   DIMENSION IALPHA(80)

   READ 100,IALPHA
100FORMAT (80A1)

Not everyone spoke USASCII or EBCDIC back in the day--and character 
constants weren't part of most FORTRANs.


--Chuck

Re: PDP-11 Overlays


> On Sep 21, 2015, at 3:14 PM, Jerome H. Fine  wrote:
> 
> 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?

RSTS has no specific structure of its own.  It provided both RT-11 and RSX 
emulation, and as a result would offer the structures from both of those, 
depending on which environment you chose for a particular application.

RSX uses a tree structure.  For details (lots of details) see the TKB manual.

Suppose you have main which calls o1.  o1 calls o2 which calls o3, and o1 also 
calls o5 which calls o6.  

In the RSX case, you could specify a tree with two branches: main to o1 and 
from there o2 to o3, and o5 to o6.  In the RT11 case, you might put o1 in 
region 1, o2 and o5 in region 2, and o3 and o6 in region 3.

The memory requirements would be:

rt11: main + o1 + max (o2, o5) + max (o3, o6)
rsx:  main + o1 + max (o2 + o3, o5 + o6)

If o2 and o6 are large while o3 and o5 are small, then the RSX case gives you a 
smaller memory footprint.

paul

Re: Multi-platform distribution format (Was: Backups [was

2015-09-21 Thread Holm Tiffe

Holm Tiffe wrote:
[..]

..forgot to mention one interesting thing:
The E60 is that PDP11 clone on which Alexei Paschitnow wrote the original
of Tetris...

Regards,

Holm

-- 
  Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
 Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
  www.tsht.de, i...@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Re: IBM 026 - Decision Data 8010 card punch on Ebay in Germany

> On Sep 21, 2015, at 2:37 PM, jwsmobile  wrote:
> 
> 
> 
> On 9/21/2015 10:14 AM, Dave G4UGM wrote:
>> Pretty sure that’s later than an 029, but really nice.
> I used 029's in 1971, and they had been around for at least a year or two at 
> the school.  The auction say 1973, which is probably right.
>>> 
>>> Not really a 026 but maybe contemporary with the 029:
>>> 
>>> http://www.ebay.de/itm/371439456530
>>> 
>>> Not mine.
> Trimmed the URL so it doesn't wrap.
> 
> Google translate text of description.

Let me try a manual translation, because as usual machine translation leaves a 
bit to be desired.

> 
> Another nit, I think the auction states no shipment to the US (translation 
> leaves a bit to be desired).  Currently sitting @ 1 euro.  Needs Repair.

The statement on the tab "shipping and payment methods" is: "The seller has not 
stated a method for shipment to the USA.  Contact the sender and ask for 
information on shipment to your location."  But in the item description it says 
"pickup only because it's heavy".

The description reads:

Experience the beginnings of EDT and punch your own punched cards.

Here is a keypunch (Interpreting Data Recorder) of Decision Data, type 8010 
offered for sale.

This keypunch was introduced in 1973 and has very many features.  The device 
was made with such high operating speed that it could punch in real time even 
with the fastest data entry by experienced keypunch operators.  The appearance 
of the device is very good, almost as new.

The device is not operational, it requires repair.

The sale includes a manual in German and 2000 original (unpunched) cards, so 
that after repair you can immediately punch cards (including printing).  The 
manual includes all related schematics and details.

Dimensions: height = 98cm, width = 119cm, depth = 68cm Weight estimated: 80-100 
kg.  Therefore only be picked up in [postal code] 65779 near Frankfurt / Main. 

Private sale to shrink collection without guarantee and no returns. Similar 
offers will follow soon.

paul

> 
> Experience the EDP the early period and even punch cards punching
> 
> Here is a keypunch (Interpreting Data Recorder) of Decision Data, type 8010 
> available.
> This card-punch came in 1973 on the market and had very many features.
> 
> The device was made so quickly,  that it practiced by Locher inside could 
> still mitstanzen in real time even at the fastest input.
>  the fastest input> (my interpretation)
> 
> The optical condition   of the device is very good, almost as 
> good as new.
> 
> Technically, it is not functional. It needs to be fixed.
> 
> For auction includes a German manual and 2000 original punch card (uncut), so 
> that for once can punch card repair (incl. Lettering). In addition, the 
> Manual is one with all the detailed schematics and explanations.
> 
> Dimensions: H = 98cm, B = 119cm, T estimated = 68cm Weight: 80-100 kg.
> 
> Therefore only be collected in 65779 near Frankfurt / Main. Private sale of 
> collection reducing without guarantee and no redemption. Similar offers will 
> follow soon.
> 
> Thanks
> Jim

Re: Self modifying code, lambda calculus - Re: ENIAC programming


[...] a first encounter with the notion, at least for me, involved
FORTRAN, not any language.  [...]

I've always thought of FORTRAN as a language, so I am clearly
missing something here.  What?
Probably a misspeak.   But FORTRAN is more than simply a language--it's a way 
of life.  :)


A REAL programmer can write a FORTRAN program in any language.

Re: Multi-platform distribution format (Was: Backups [was

Ah, but when people with Valdocs wanted to change to another 
word-processing system, as was likely to happen often in business, they 
would contact, Chuck, me, or any of our colleagues in the disk format 
conversion field.


The CP/M users might not have as frequent a conversion need, and/or might 
be more likely to make use of other options, such as XMODEM.


Accordingly, WE saw Valdocs users more often than the other QX-10 users.



On Mon, 21 Sep 2015, Chuck Guzis wrote:


On 09/21/2015 10:22 AM, tony duell wrote:


Have you ever read the technical manual for the QX10?

It appears there were 2 keyboards sold for it. One had Valdocs-specific
keys, the other (which seems more common over here, not that the QX10
is a common machine) doesn't and was used for a more standard
CP/M system.


Yes, as well as a fair amount of TP/M source code.  It's just that the QX-10s 
strong selling point was Valdocs and that's mostly why people bought the 
thing.

Re: IBM 026 - Decision Data 8010 card punch on Ebay in


> On Sep 21, 2015, at 10:52 , Marc Verdiell  wrote:
> 
> Wow. Thanks for sharing. What a beautiful looking machine. I hope one of us
> gets it.

It looks like it is in pristine condition!


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Overlay - one answer

2015-09-21 Thread Rod Smallwood



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

Re: Self modifying code, lambda calculus - Re: ENIAC programming


On 09/21/2015 11:49 AM, Mouse wrote:

[...] a first encounter with the notion, at least for me, involved
FORTRAN, not any language.  [...]


I've always thought of FORTRAN as a language, so I am clearly
missing something here.  What?


Probably a misspeak.   But FORTRAN is more than simply a language--it's 
a way of life.  :)


The gist was that the notion of an overlay tree was first brought to my 
notice with FORTRAN.  It could be that it had been presented in earlier 
documents as such and evaded my notice., It did take the form of a set 
of subroutine calls, and was not an element of standard FORTRAN.


As mentioned, COBOL had a similar scheme that was embedded in the 
language itself.


--Chuck

PDP-11 Overlays


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

Re: IBM 026 - Decision Data 8010 card punch on Ebay in Germany

2015-09-21 Thread jwsmobile




On 9/21/2015 10:14 AM, Dave G4UGM wrote:

Pretty sure that’s later than an 029, but really nice.
I used 029's in 1971, and they had been around for at least a year or 
two at the school.  The auction say 1973, which is probably right.


Not really a 026 but maybe contemporary with the 029:

http://www.ebay.de/itm/371439456530

Not mine.

Trimmed the URL so it doesn't wrap.

Google translate text of description.  I'd love to see Bitsavers get a 
scan of the documents.


Another nit, I think the auction states no shipment to the US 
(translation leaves a bit to be desired).  Currently sitting @ 1 euro.  
Needs Repair.


Experience the EDP the early period and even punch cards punching

Here is a keypunch (Interpreting Data Recorder) of Decision Data, type 
8010 available.

This card-punch came in 1973 on the market and had very many features.

The device was made so quickly,  that it practiced by Locher inside 
could still mitstanzen in real time even at the fastest input.
with the fastest input> (my interpretation)


The optical condition   of the device is very good, almost 
as good as new.


Technically, it is not functional. It needs to be fixed.

For auction includes a German manual and 2000 original punch card 
(uncut), so that for once can punch card repair (incl. Lettering). In 
addition, the Manual is one with all the detailed schematics and 
explanations.


Dimensions: H = 98cm, B = 119cm, T estimated = 68cm Weight: 80-100 kg.

Therefore only be collected in 65779 near Frankfurt / Main. Private sale 
of collection reducing without guarantee and no redemption. Similar 
offers will follow soon.


Thanks
Jim

Re: Multi-platform distribution format (Was: Backups [was


and, of course, as a third type, Exatron Stringy-Floppy computer
based, but NOT entirely usable.


The department chair at one of the colleges attempted to convert an entire 
TRS80 based student computer lab over to stringy floppy.
He was the same one who later had a lab full of TRS80 model 3s converted 
into model 4s at a slightly higher price per unit than buying model 4s. 
Nodel 3s were still quite in demand in that lab, and the student 
technicians were quite capable of adding memory and disk drives.  The same 
expenditure could have resulted in almost twice as many usable machines, 
plus a few 3s waiting for funding for RAM and drives.
Later, he thought that it would be cool to have all of the 5150 PCs on 
their sides, ("to look more professional"), with the switch on the 
underside.
And, of course, although it meant far fewer machines, all of the AT 
machines used for teaching spreadsheets, word processing, and beginning 
programming HAD TO have color monitors.

Query for dec teleprinter roms

2015-09-21 Thread Jonathan Gevaryahu

Does anyone have an LA36, LA120 or LAS12, LA34, LA100, or LA210 
somewhere which they could dump the ROMs from?


Notes:
The LA36 uses several proms for its discrete cpu, and 2 character set 
roms which I believe have an 'odd' pinout.


The LA120, one of the roms on the '2 rom version' is an 8k 2364 24 pin 
chip which is a bit annoying to dump, since you either need a 2364->2764 
24->28 pin adapter, or (better) a programmer which can dump MC68764 or 
MC68766 24-pin 8k eproms (which have the same pinout as 2364). The other 
rom on the 2 rom version is a 2k 2316 24 pin chip.
The oldest LA120 version uses 5 roms, all 2k 2316s. The code on the 
5-rom version and the 2-rom version may very well be the same (the first 
4 2k chips consolidated to one 8k chip), I'm not sure. Would be nice to 
get dumps of both versions.
The LAS12 uses different code from the LA120 and to the best of my 
knowledge all LAS12s use 2 roms, one 8k and one 2k.


LA34, theres at LEAST five firmware versions, almost certainly six, and 
possibly as many as seven. There is also a special firmware for a 'rom 
expansion' daughterboard.
The 1978 LA34 "54-13374" motherboard has a bizarre Intel i8355 mask 
rom+io chip in it, plus a separate rom as well. (there are at least two 
versions of said i8355+rom firmware). Dumping the i8355 is not for the 
faint of heart, it would likely be easier to insert a 'dumping program' 
eprom into the single rom's socket, and use the LA34's cpu to spit its 
own rom contents out via serial.
The 1980 LA34 "54-13747" motherboard lacks the i8355 and uses 2 or 3 
mask roms or eproms on it instead (and 74xx logic for the i/o). There 
are at least three rom revisions for this, possibly four or five.


LA100 (AKA LW100)... I have no idea. There's definitely at least one rom 
revision. Also to the best of my knowledge neither the maintenance print 
set nor the technical manual for the LA100 are scanned (they certainly 
don't appear at 
http://bitsavers.trailing-edge.com/pdf/dec/terminal/la100/ ), which 
makes it difficult to know.


--
Jonathan Gevaryahu
jgevary...@gmail.com
jgevary...@hotmail.com

Re: Some amount of DG goodness

2015-09-21 Thread shadoooo

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

Re: Query for dec teleprinter roms

2015-09-21 Thread william degnan

What are you going to do with these?  Is there a ROM archive for DEC
printer ROMs?

On Mon, Sep 21, 2015 at 3:14 PM, Jonathan Gevaryahu 
wrote:

> Does anyone have an LA36, LA120 or LAS12, LA34, LA100, or LA210 somewhere
> which they could dump the ROMs from?
>
> Notes:
> The LA36 uses several proms for its discrete cpu, and 2 character set roms
> which I believe have an 'odd' pinout.
>
> The LA120, one of the roms on the '2 rom version' is an 8k 2364 24 pin
> chip which is a bit annoying to dump, since you either need a 2364->2764
> 24->28 pin adapter, or (better) a programmer which can dump MC68764 or
> MC68766 24-pin 8k eproms (which have the same pinout as 2364). The other
> rom on the 2 rom version is a 2k 2316 24 pin chip.
> The oldest LA120 version uses 5 roms, all 2k 2316s. The code on the 5-rom
> version and the 2-rom version may very well be the same (the first 4 2k
> chips consolidated to one 8k chip), I'm not sure. Would be nice to get
> dumps of both versions.
> The LAS12 uses different code from the LA120 and to the best of my
> knowledge all LAS12s use 2 roms, one 8k and one 2k.
>
> LA34, theres at LEAST five firmware versions, almost certainly six, and
> possibly as many as seven. There is also a special firmware for a 'rom
> expansion' daughterboard.
> The 1978 LA34 "54-13374" motherboard has a bizarre Intel i8355 mask rom+io
> chip in it, plus a separate rom as well. (there are at least two versions
> of said i8355+rom firmware). Dumping the i8355 is not for the faint of
> heart, it would likely be easier to insert a 'dumping program' eprom into
> the single rom's socket, and use the LA34's cpu to spit its own rom
> contents out via serial.
> The 1980 LA34 "54-13747" motherboard lacks the i8355 and uses 2 or 3 mask
> roms or eproms on it instead (and 74xx logic for the i/o). There are at
> least three rom revisions for this, possibly four or five.
>
> LA100 (AKA LW100)... I have no idea. There's definitely at least one rom
> revision. Also to the best of my knowledge neither the maintenance print
> set nor the technical manual for the LA100 are scanned (they certainly
> don't appear at http://bitsavers.trailing-edge.com/pdf/dec/terminal/la100/
> ), which makes it difficult to know.
>
> --
> Jonathan Gevaryahu
> jgevary...@gmail.com
> jgevary...@hotmail.com
>
>


-- 
Bill
vintagecomputer.net

Re: Some amount of DG goodness

My own DG rack is taking up a lot of space in a very tiny room, but it came 
along with a nice little PDP-11/03 in a short rack that I wanted. I bought them 
from the stepson of their original owner (who passed away in 2008 if I recall 
correctly), and they came with a cool story. So even though I don't have any 
prior history with DG gear, this rack won my heart:

http://www.nf6x.net/2014/03/data-general-nova-3-and-dec-pdp-11v03-l/


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

RE: Some amount of DG goodness

Shadoo wrote

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.

As a safety net, I was going to send one to another listmember that has a 3d 
scanner/printer and see if they can reproduce. Won't match from a color 
perspective, but maybe from a functional one.

J

Re: Query for dec teleprinter roms

On 9/21/2015 2:19 PM, william degnan wrote:
> What are you going to do with these?  Is there a ROM archive for DEC
> printer ROMs?
> 

Well, I expect bitsavers would happily host them in .../bits ;)

Re: Multi-platform distribution format (Was: Backups [was


>Jay Jaeger wrote:


On 9/21/2015 11:34 AM, Paul Koning wrote:



For RX50?  On standard PDP11s, those used an MSCP controller, which means the 
controller would have to do it.  Did it?  The only MSCP controller I remember 
that did formatting was the UDA50.

I suppose you could on a Pro, since that had its own particularly disgusting 
junk controller.  But I haven't seen RX50 formatting there.  My impression was 
that they came factory formatted, with the DEC-specific 10 sector per track 
format.


Acch.  Bad memory cells.  This actually was discussed back in 2002.
Some of the correspondents in that discussion are also denizens of this
mailing list, may recall I made the same mistake back then:

The diagnostic was/is:

BL-FN7AP-MC CZFNAP0 M-11 FORMTR RX50

So, just to verify, I fired up my 11/23 (which hasn't been on in YEARS),
which came right up, and inserted the floppy and booted it:

It formats:

RD51, RD52, RD53 on an RQDX1 or RQDX2
RD51, RD52, RD53, RD54, RD31, RD32, RX33 on an RQDDX2

Sorry for the confusion.

JRJ


Then you have answered the question!!

But it there may be some possible confusion.  If I remember
correctly, the RQDX3 was used with the RD54 and RX33
and the RQDX2 or RQDX3 was used with the RD53.

I could be wrong, but that is what I seem to remember.

So on a PDP-11 Qbus system, it is not possible to FORMAT the
RX50 which uses an RQDX1, RQDX2 or an RQDX3.

BUT, how is it possible to FORMAT the 5 1/4" RX33  HD floppy
which uses an RQDX3 controller?

If it can be dome with the RX33, why not with the RX50?

Jerome Fine

Re: Backups [was Re: Is tape dead?]

2015-09-21 Thread David Brownlee

On 21 September 2015 at 01:55, Jerome H. Fine  wrote:
>>Fred Cisin wrote:
>
>> On Sun, 20 Sep 2015, Jon Elson wrote:
>>
>>> Well, one would assume this is also OS specific.  I would guess it would
>>> be incredibly hard to make a "disk" virus that would work on greatly
>>> differing OS's like Linux AND Windows.  No telling what would happen if one
>>> of these disk viruses got onto a hard drive on a Windows system and then the
>>> drive was reformatted and loaded with Linux.
>>> Most likely you'd have odd crashes or something.
>>
>>
>>
>> It is possible to create an executable file that identifies the OS that it
>> is running on and does a conditional jump to different code, assuming that
>> the processor uses the same instruction set.
>>
>> How different the OS's are would determine how much code could be shared.
>> If they are very different, then the executable file could be twice as
>> large, with no code in common.
>>
>>
>> It is even possible to make a disk that is readable as multiple disk
>> formats, so long as each is expecting the DIRectory tracks to be in
>> different places.
>> One of the many projects that I never got ready for market was to make a
>> multi-platform distribution format for software.  "Save a few cents on media
>> costs by putting all of your platforms on one disk"  But, after August 1981,
>> it eventually became apparent that the need for such was not going to be
>> around much longer.
>>
>> If the boot code is short enough, it is even possible to have an FM, an
>> MFM, and a GCR boot sector in the same boot track, since each will not even
>> see any except its own.  Formatting/recording a track with mixed densities
>> and/or encodings and multiple sector sizes is not a supported function in
>> most operating systems, nor even FDCs, but can be done with some flux
>> transition controllers.
>
>
> I used the above example when I created a CD which had files to be used
> with RT-11 in addition to being a normal CD under Windows.  I found that
> for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
> on the CD were empty.  I don't know if that area is reserved for boot code
> under Windows when the CD is bootable, but my goal did not require the
> CD to be bootable under Windows.
>
> Under RT-11, the first six hard disk blocks (0 to 5) are reserved for boot
> code (when that is present) and hard disk blocks from 6 up to 67 are used
> for an RT-11 directory.  RT-11 rarely uses that large a directory and the
> minimum directory is only two hard disk block long.  For the CD, that
> allowed an RT-11 directory from hard disk blocks 6 to 63 or up to
> sector 15.
>
> What may have been unique was that only the RT-11 directory and the
> CD  ISO directory were distinct.  Otherwise, all the files were the same
> with each directory pointing to the same location on the ISO image.
>
> In practice, the same CD could be used as a data CD under Windows
> in addition to being a boot disk on a real DEC  RT-11 system which
> supported that operating system.  I was actually on the phone at one
> point when the first individual who received a copy of the CD used
> it to boot RT-11 on a CDROM drive configured to support 512 byte
> blocks using a CQD 220/TM host adapter.
>
> The same ISO image file can also be used under both SimH and Ersatz-11
> in the same manner, although it is STRONGLY recommended that the
> ATTACH or MOUNT command use the ISO image file as READ  ONLY.
> Ersatz-11 is also able to MOUNT the actual RAW CD on a CDROM
> SCSI drive and boot RT-11 from the CD.  Of course, the Windows
> operating system under which Ersatz-11 is also able to see all the same
> files on the CD as well, BUT  NOT  AT  THE  SAME  TIME - at
> least I never did attempt that possibility.
>
> If this can be done with Windows and RT-11 which have completely
> different file structures and instructions sets, it certainly seems likely
> that other operating systems and system hardware can also be supported.
> The one thing that seemed reasonable from a security point of view is
> that the CD is READ  ONLY, so no virus can be introduced on the
> CD after it is burned.
>
> Tim Shoppa did almost the same thing with his RT-11  Freeware CD
> when an RT-11 directory was added at the end of the ISO image file
> for the CD.
>
> If anyone finds this interesting and has additional questions, please ask.

Before the price of media and storage dropped so much NetBSD install
ISOs were multiboot - one image which booted on alpha, i386, pmax, and
sparc (and I think theoretically also macppc, vax and sun2, sun3 and
sun3x if it hadn't run out of room for the install files :)
http://www.netbsd.org/docs/bootcd.html#multiimage

So much cool stuff no-one bothers with now days...

David

Re: The desk has arrived - WAS: Somewhat OT: Freighting Items


> On Sep 21, 2015, at 14:24 , Ali  wrote:
> 
> Well,
> 
> In case anyone is still interested the desk arrived on Friday. The seller
> did a very good job of packing it and it arrived in tact. Thanks to everyone
> for their input, tips, and bits of wisdom. BTW: If anyone is interested you
> can check out some quick pictures here:
> 
> http://megacube.classiccmp.org/Synergetix/Synergetix.html
> 
> The web page is very rudimentary and will be expanded. Once I get it cleaned
> up it will house an IBM 5150 A, a 5151, a 5152-002 and a Cipher 5120.

Thanks for sharing the pictures, and I'm glad that the freighting worked out! 
Freight shipment is a bit weird at first, until you get used to it.


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Some amount of DG goodness

I have a Nova 3. Maybe if I can find the time, I can sit down with a caliper 
and a CAD program, and create a solid model of a switch lever? Then I could put 
it up for sale at ShapeWays for convenience, as well as sharing the model in a 
GitHub repository.

Also, that heap of DG stuff in the pictures looks really lovely!

-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Some amount of DG goodness

Well, I have (what I think is) an entire Nova 3, also sitting in a
garage (mine, of course), that we could discuss.  Where are you located?

(Mine is in Madison,  WI  USA)

JRJ

On 9/21/2015 2:35 PM, shad wrote:
> 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
>

RE: Some amount of DG goodness

Mark wrote...

Also, that heap of DG stuff in the pictures looks really lovely!

Thank you... Those pictures don't even show a quarter of the DG gear
floating around here.

But honestly-unfortunately, it's simply WAY too much. Soon as I get one or
two good working Eclipses and one or two good working Nova 800/1200/2's,
each in a rack with a compliment of peripherals the rest is available
for trade and such. I need the space badly, and the DG gear accounts for a
very substantial amount of floorspace here.

I do know that at the top of my want-list is a couple multi-async boards ;)
And I just came across two *cases* of core boards that will likely be
available at some point...

J

Re: Self modifying code, lambda calculus - Re: ENIAC programming


On 09/21/2015 01:37 PM, Dave G4UGM wrote:


I wrote X.25 software in Fortran:-(. We had some machine specific
routines to allow the Fortran code to wait for a packet to arrive.
There was also a huge vector of strings with matching integer arrays
that allowed them to be chained together, and to have types allocated
to them There were also a large number of "INCLUDE" files with a
parameters which defined the structure of data stored in the
character vectors



PASCAL was first implemented in FORTRAN.

--Chuck

Re: Sheet Metal Fabrication Options?

2015-09-21 Thread Noel Chiappa

> 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

Re: Self modifying code, lambda calculus - Re: ENIAC programming