Thousands of new documents have been added to the DG legacy preservation
web site [www.NovasAreForever.org], including new sections for the Nova,
SuperNova, Nova 2, Nova 3, microNova, MPT, Eclipse S/130, Eclipse S/140,
Eclipse S/230, Eclipse C/330, Eclipse S/280, and Desktop Generation
computers.(!) Separate areas also now exist for DG disks, tapes and
other peripherals.
New archives for 3rd-party, DG-compatible hardware vendors have been
started with this release, including those for Keronix, DCC, Bytronix
and ROLM.
This update reflects Wild Hare's continuing dedication [obsession?] to
preserve Data General's significant part of computer history, and to
help museums, universities and "restorationists" preserve DG systems
worldwide.
Bruce Ray
www.NovasAreForever.org
--
Bruce Ray, President
Wild Hare Computer Systems, Inc.
Denver, Colorado USA
bkr(a)WildHareComputers.com
...preserving the Data General legacy: www.NovasAreForever.org
I have two SPST time delay 12-volt relays packaged like vacuum tubes
with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five
seconds).
They're in their original boxes.
I have no idea what devices used them.
It seems a shame to throw them in a recycle bin.
Does anybody want them?
Van Snyder
I have been trying to diagnose a video fault on my Rainbow 100A for some
time now. The monitor shows an error message and some of the attributes
displayed are wrong and displayed incorrectly on every line down the screen.
However, the attributes being presented to the DC012 appear to be correct
and the DC012 is good (I have replaced it with a spare and with a known good
one, all have the same behaviour), and yet the display is wrong.
I have posted this on VCF, but would like to reach a wider audience as I am
really at a loss now as to what the problem could be.
Picture of the problem here:
https://forum.vcfed.org/index.php?threads/video-ram-fault-on-a-rainbow-100a.
1250713/post-1418966
Description of what I have found here:
https://forum.vcfed.org/index.php?threads/video-ram-fault-on-a-rainbow-100a.
1250713/post-1433618
Thanks
Rob
As those of us with a few years will know, Tony Hoare (and Jill's)
implementation of Algol 60 on the Elliott 803 was a highly significant
event in the history of computer languages. It was the first practical
commercial Algol compiler, launched block structures languages, and
played a part in Elliott selling nearly 300 803B computers at a time
when 300 computers was a big number.
Obviously the US preferred Fortran and COBOL for commercial use, and
there were other Algol compilers in some shape or other knocking about
in universities. But I'd say this implementation put block structured
programming into the mainstream. (And it was the first high level
language I used, but that's beside the point).
Now some kid on Wikipedia thinks it's not notable and is trying to
delete it because he can't find much on it doing a Google search.
Wikipedia may be sinking under activists and egos, but I think we need
to put this misapprehension straight. Unfortunately we may be arguing
with an idiot.
https://en.wikipedia.org/wiki/Elliott_ALGOL
If course, if anyone thinks it wasn't significant, that's an opinion
too, but I'd like to hear why.
Thanks, Frank.
On Fri, 21 Feb 2025 12:00:07 -0600
Paul Koning <paulkoning(a)comcast.net> wrote:
> > What is the problem with ISRs running in a user stack? The ISR
> > runs, exits, the stack is cut back, and net effect on the user's
> > stack is zero.
>
> A stack access fault in user mode kills the process, in kernel mode
> (certainly in an ISR) it kills the whole system. You can't leave the
> integrity of the OS at the mercy of the application having a valid
> stack.
Additionally, the ISR could leave potentially sensitive information in
user memory, depending on exactly how the stack and memory protection
are implemented. Consider an architecture where the stack pointer is a
normal address register (as on the -11, the 68k, etc.) and protection
is on a per-page basis with no bounds checking (i.e. there's no special
address space for the stack, just a particular chunk mapped into normal
user memory.) It'd be trivial for a user program to sit and "scrape"
the stack for stray bits left by passing ISRs - say, waiting to see if
the UART service routine happens to jot down something that looks like
an admin password coming off one of the terminals.
> On19 Feb 2025 18:39:08 -0500, Chuck Guzis via cctalk wrote:
>
>>>
>>>> One of most ingenious coding tricks to me was the problem of saving and
>>>> restoring all registers without resorting to an exchange jump. We used
>>>> that one as a test for applicants.
>>>
>>> Argh... I know I've seen this trick, but it's been too many years. How
>>> about a hint?
>>
>> It uses the RJ instruction to record register content, bit-by-bit.
>> Think about it--RJ is about the only instruction that can modify memory
>> without fiddling with the A6 and A7 registers.
>>
>
> Of course... I vaguely recalled there was a bit-by-bit save, but didn't
> think of the RJ. Thanks.
A full example of this code is in the DEBUG package of CAL SNOBOL <https://mcjones.org/CAL_SNOBOL/>, starting at label SAVEREG:
Original version: https://mcjones.org/CAL_SNOBOL/UArizona/SNOBOL.MAC.html
Revised version: https://mcjones.org/CAL_SNOBOL/UTexas/DEBUG.html
I saw an email posted to the predecessor mail list asking if anyone had a picture of an IBM 4506 terminal. I was looking through the September 1973 issue Modern Data and saw an article on page 70 about the New York Times’s indexing efforts. It said that they were using IBM 4506 terminals and it has a picture of a large workroom (identified as “The Times index room”) with a bunch of terminals which I assume must be 4506’s (although the caption does not explicitly state that). The magazine is available on BitSavers. Look for the issue with file name Modern_Data_1973_07.pdf.
Tommy Chang
Did any classic computers have a subroutine call as (S++)=PC, PC=(EFA)
as well as the standard call (--S)=PC,PC=(EFA) ?
One could have a virtual stack machine, using helper functions without
having to deal with return addresses on the stack.
Ben.
On Tue, 18 Feb 2025 12:00:10 -0600
cctalk-request(a)classiccmp.org wrote:
> On the more than "one stack pointer" in the subject, it was a bit
> arbitrary on the PDP-11 (or VAX) as the pre/post indexed indirect
> addressing made every register a stack pointer. But this is where I
> get hazy between DEC and 68K, and I did a lot more 68K. I'm pretty
> sure you could do a move.l PC, An and you could certainly do an
> indirect jmp (An), so effectively you could have multiple call stacks
> if you wanted.
Almost, kinda-sorta. The JSR and RTS instructions are hard-wired to use
R6/SP, and there's nothing you can do about that. You *can* implement a
return off another "stack" by doing e.g. MOV @(Rn)+, PC as long as you
save the return address by hand, first - but this affects the flags,
unlike JSR/RTS.
