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.
> On 15 Feb 2025 18:41:21 -0800,Van Snyder <van.snyder(a)sbcglobal.net <mailto:van.snyder@sbcglobal.net>> wrote:
>
> Harry Husky, the G15 designer, was one of the computer design pioneers.
> He became a professor (maybe adjunct) at UC Berkeley.
As far as I know, Huskey was a regular professor. Two of his Ph.D. students went on to win the ACM Turing Award: Niklaus Wirth and Butler Lampson:
https://mathgenealogy.org/id.php?id=10185
Huskey went on to found the Computer Science department at U.C. Santa Cruz.
> On 16 Feb 2025 18:00:35 -0700,ben <bfranchuk(a)jetnet.ab.ca <mailto:bfranchuk@jetnet.ab.ca>> wrote:
>
> I have trouble understanding the fine points of accessing a local
> variable in Algol with a display. Books tend to spend more time
> on the evils of a dangling else, and gloss over the run time action of
> a display.
> Have a good example or reference book I can find free on line.
The original book on that subject is ALGOL 60 Implementation by B. Randell and L. J. Russell. It’s available here with permission from the copyright holder:
https://www.softwarepreservation.org/projects/ALGOL/algol60impl/#ALGOL_60_I…
I am an old mainframe guy. I could give you my COBOL deck of cards or the compile listing. You could pour through the code looking for nefarious/malicious code. I then hand you the object deck. You have no idea if it matches the code you looked at. The only way you could be sure is to compile the code I gave you and use your own object deck.
So why is open source these days such a beneficial thing? DeepSeek may be open source but I have no way to create my own executable. Besides, I don’t know what language it is written in but I bet I have no expertise in it. No way to for me to identify nasty code.
Yes, many people may have reviewed the code but that does not mean what I am running is the result of that code.
Hi Van,
just wanted to point out, that there is a 803 emulator out there:
https://www.peteronion.org.uk/Elliott/
I have got a real 900 series machine running, which is from the very
early 1970ies and also runs a form of Elliott Algol:
https://www.youtube.com/watch?v=v-gF5g0nnoE
Best wishes,
Erik.
----------------------------------------------------------------------
''~``
( o o )
+--------------------------.oooO--(_)--Oooo.-------------------------+
| Dr. Erik Baigar Inertial Navigation & |
| Salzstrasse 1 .oooO Vintage Computer |
| D87616 Marktoberdorf ( ) Oooo. Hobbyist / Physicist |
| erik(a)baigar.de +------\ (----( )---------------------------+
| www.baigar.de | \_) ) /
+----------------------+ (_/
>Message: 31
>Date: Sun, 2 Feb 2025 07:29:15 +0000
>From: Tony Duell <ard.p850ug1(a)gmail.com>
>Subject: [cctalk] Re: RS232 then and now
>
>On Sat, Feb 1, 2025 at 10:54 PM Fred Cisin via cctalk
><cctalk(a)classiccmp.org> wrote:
>
>
>>
>> IBM used a DB25 socket for their printer port at the computer end,
>> (male on the card for serial, female on the card for parallel "Centronics")
>> THAT, of course caused some idiots to attempt to use the parallel port for
>> serial and vice versa. "I just need a 'gender changer'!" :-)
>
>The worst screw-up there (IMHO) came from HP in the HP150 series. This
>machine had 2 RS232 serial ports as standard on DB25 sockets, wired
>for some inexplicable reason as DTEs. There was an add-on board that
>included a parallel printer port. To avoid confusion, this was a DB25
>plug. But the board had been laid out for a DB25 socket using the IBM
>PC pinout. The result was that stb/ ended up on pin 13, D0 on pin 12,
>and so on.
>
>-tony
>
My vote for the worst connector screw-up is the AT&T (Olivetti) 6300. Its monochrome monitor used a DB25 to supply both the signals and 12 volts to power the monitor.
Bob
I was about to ask if anyone ever built a "Parallel Modem" - but I searched
around first, and lo and behold, Microcom did ! (v.fast / v.34 era, c.
1996)
The drivers refer to Win3.1/Win95 era (I'm not seeing where they had DOS
support).
But I'm still not sure if I'm understanding the product (which I found
described here
Microcom Parallel Port Modem <https://strom.com/pubwork/cw294.html>
From a programming perspective, you just set your parallel bits and mash
the STROBE pin, right? Then figure some reasonable delay between
iterations of doing that. You don't need starts/stop or parity bits. So
I get how that is more efficient (but question is, why wasn't it built
sooner? I think it's a long answer when you look at the historical build up
of modems, and that serial-port based modems were "fast enough" at the time)
So.. If you had a slow system that couldn't really take advantage of a
~7MHz 16550 serial card (or I guess like a laptop that was stuck with an
older UART) That might be the use-case where this parallel v.fast might
help (by being able to "feed the modem" fast enough to actually take
advantage of the faster modem speed?) Or is there some other scenario
NOTE, in the articled linked above, it does mention that it is only "value
added" if you have this parallel-modem on both sides of the connection.
(this is because you'll be flow controlled to whatever is the slower device
in the connection?)
Related but different question:
Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400
baud-equivalent modem an accelerated-by-enhanced-encoding version of 300
bps? and 9600 likewise an accelerated-by-encoding version of 2400? is
300bps itself some kind of special accelerated-by-encoding? I see 1200
baud was also still sub 3KHz (did any modem protocol go above 3KHz?).
Or maybe I need to ask it this way: did 300 baud modems use a more 1:1
translation of the data-word bits into Hz signal over the modem (giving a
more "natural" translation rate?) But then beyond that speed, does a modem
need to "cache" a few bytes and determine some encoding scheme to then give
modems an apparent speed boost? (is that "kind-of" like USB's 8B/10B?
(not in implementation, but in the general concept that a different
encoding can result in improved data throughput, without actual faster
movement of that data?)
I guess it gets into the "secret sauce" approaches of how vendors figured
out these encoding approaches (v.32bis, etc), and give their product
competitive advantages (but only if you could convince enough ISPs to adopt
your protocol, by buying your modem device).
My daughter made me finally watch Blackberry recently, it's an interesting
telling of that story (of a small business selling their tech to USR, and
also that they tackled a version of encryption)
-Steve
Al has a reader at CHM. They can read tapes too, my 7-track setup is now at System Source.
Paul
> On Sat, 2025-02-15 at 14:52 +0000, Sid Jones via cctalk wrote:
> > IIRC, I have a copy of the Elliot 803 A-103 Algol compiler on a five-
> > hole
> > tape in a drawer somewhere in my untidy office...
> >
> > As used in UCNW Bangor, 1971-1974.
>
> There might be a reader somewhere. If anybody has (or developes) an
> 803B emulator, it would be nice to have the compiler.
>
> Paul Pierce read several IBM 1401 tapes. The Computer History Museum in
> Mountain View, CA has two operating 1401s, and the SimH project has an
> emulator. It's nice to have the Autocoder assembler, FORTRAN II and
> FORTRAN IV compilers, COBOL compiler, ⦠to use. There are students at
> San Jose State University who go to classes in 1401 programming at CHM.
>
> Maybe Paul has a paper tape reader too.
>
>
>
>
