[cctalk] Re: Great Vintage Computer Heist of 2012

[Christian Gauger-Cosgrove via cctalk]

Apologies for the off-topic.

On Wed, 19 Oct 2022 at 15:34, Nigel Johnson Ham via cctalk
 wrote:
> I got a government official to give me the legal definition and
> published it on wikipedia, quoting the official source.
>
Was it Measurement Canada's complaint form? Because they - that is,
Measurement Canada - has now published a helpful poster on the
definition of what units of volume draft beer may be sold by:

For the curious it's in the link above.

Best regards,
Christian

Re: PMI memory on an -11/93 (Was: Installing an operating system on an 11/83)

[Christian Gauger-Cosgrove via cctalk]

On Tue, 22 Feb 2022 at 16:10, Henk Gooijen via cctalk
 wrote:

> half populated with memory. I don’t think you can add memory
> externally.  But I might be wrong …
>
You are not wrong. From the KDJ11-E module user's guide (on BitSavers)
the solder-side of the CD fingers is left unpopulated, but for the +5
and ground pins.

The only PMI compatible option then would be the KTJ11-B UNIBUS
adapter. (You could probably use an MSV11-Q non-PMI memory to fill out
the last 2MB though.)

Best regards,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.

Re: PDT11/150 supported in RT11 5.7?

[Christian Gauger-Cosgrove via cctalk]

>From the freshly installed RT-11 v5.7 disk image I have available to me:

.type pd.mac
.MCALL  .MODULE
.MODULE PD,VERSION=09,COMMENT=,AUDIT=YES

On Tue, 23 Nov 2021 at 14:44, Jacob Ritorto via cctalk
 wrote:
> I was just reading the RT 11 5.7 documentation the other day and noticed the 
> mention that PDT-11s were desupported with that release. I think the follow 
> up to that was that the device drivers are still there, but no longer built 
> for you. Maybe you could build it yourself and be fine!
>
So yes, to confirm what Jake says: the handler is included as source
only, you will need to compile and link it yourself to use it. (There
are several other drivers in a similar state, including the TU-58
driver and DECtape driver.)


Best regards,

Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.

Re: IEEE-488 on the PDP-11

[Christian Gauger-Cosgrove via cctalk]

On Tue, 16 Nov 2021 at 16:27, Ethan Dicks via cctalk
 wrote:
> Fun card.  Thanks for starting this thread.  I have one too (came with
> my MINC-11) and I have experience with IEEE-488 from my many hours
> spent with Commodore PETs.
>
Hmm now that I'm reminded that a large proportion of Commodore's
"stuff" was IEEE 488 or a serialized version thereof.

I kind of want to see now if an IBV11 and Commodore 1541 can be abused
into cooperating. (There'd need to be a small "box of stuff" to turn
the real 488 bus to CBM's serial thing.)


> Thanks to all for sharing code and software.
>
I'll second this; many thanks for sharing the official DEC RT-11
drivers and code.


Best regards,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.

Re: Massbus - was: Re: VAX 11/750

[Christian Gauger-Cosgrove via cctalk]

On Thu, 25 Feb 2021 at 21:32, Rich Alderson via cctalk
 wrote:
> As for operating system support, the only DEC operating system which could put
> tapes and disks on the same Massbus was TOPS-20.  Tops-10 explicitly tells you
> in the SYSGEN process that disks and tapes must reside on different channels; 
> I
> believe that ITS follows that same principle.  WAITS, although originally a
> highly divergent offshoot of Tops-10, took the Massbus code from TOPS-20 v5
> when it was ported to a KL-10 at SAIL, so could in theory have disk and tape 
> on
> the same channel.
>
RSX-11/M+ should as well. It is possible during SYSGEN to define a
"mixed MASSBUS".

Best regards,
Christian
--
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.

Re: Text encoding Babel. Was Re: George Keremedjiev

[Christian Gauger-Cosgrove via cctalk]

On Wed, 28 Nov 2018 at 09:27, Paul Koning via cctalk
 wrote:
> I learned it about 15 years ago (OpenAPL, running on a Solaris workstation 
> with a modified Xterm that handled the APL characters).  Nice.  It made a 
> handy tool for some cryptanalysis programs I needed to write.
>
I am interested in this cryptanalysis program...


> I wonder if current APL implementations use the Unicode characters for APL, 
> that would make things easy.
>
I can confirm that both NARS 2000 and Dyalog APL both use the Unicode
APL characters.

Regards,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.

Re: Text encoding Babel. Was Re: George Keremedjiev

[Christian Gauger-Cosgrove via cctalk]

On Mon, 26 Nov 2018 at 03:44, Liam Proven via cctalk
 wrote:
> If it's in Roman, Cyrillic, or Greek, they're alphabets, so it's a letter.
>
Correct, Latin, Greek, and Cyrillic are alphabets, so each
letter/character can be a consonant or vowel.

> I can't read Arabic or Hebrew but I believe they're alphabets too.
>
Hebrew, Arabic, Syriac, Punic, Aramaic, Ugaritic, et cetera are
abjads, meaning that each character represents a consonant sound,
vowel sounds are either derived from context and knowledge of the
language, or can be added in via diacritics.

Devanagari and Thai (and Tibetan, Khmer, Sudanese, Balinese...) are
abugidas, where each character is a consonant-vowel pair, with the
"base" character being one particular vowel sound, and alternates
being indicated by modifications (example in Devanagari: "क" is "ka",
while "कि" is "ki"; another example using Canadian Aboriginal
Syllabics "ᕓ" is "vai" whereas "ᕗ" is "vu").

> I don't know anything about any Asian scripts except a tiny bit of
> Japanese and Chinese, and they get called different things, but
> "character" is probably most common.
>
Japanese actually uses three different scripts. Chinese characters
(the kanji script of Japanese, and the hanja script of Korean) are
logograms.

Japanese also has two syllabic scripts, katakana and hiragana where
each character represents a specific consonant vowel pair.

Korean hangul (or if you happen to be from the DPRK, chosŏn'gŭl) is a
mix of alphabet and syllabary, where individual characters consist of
sub parts stacked in a specific pattern. Stealing Wikipedia's example,
"kkulbeol" is written as "꿀벌", not the individual parts "ㄲㅜㄹㅂㅓㄹ".


And now for even more fun, Egyptian hieroglyphics and cuneiform (which
started with Sumerian, and then used by the Assyrians/Babylonians and
others) are a delightful mix of logographic, syllabic and alphabetic
characters. Because while China loathes you, Babylon has a truly deep
hatred of you and wishes to revel in your suffering.


Regards,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.

Re: DEC PDP-14 Programmable Controller simulator

[Christian Gauger-Cosgrove via cctalk]

On 4 April 2017 at 20:21, Charles Dickman via cctalk
 wrote:
> I have written a PDP-14 simulator using the simh framework. Paired
> with a PDP-8 simulator as a front end it passes all the DEC
> diagnostics. A pointless effort, perhaps, because there isn't much
> that can be done with it without connecting it to something to
> control.
>
Please release it! I/O access isn't too exceedingly complicated. I
just finished up a university class on industrial controllers and
networking, and we covered Modbus RTU and Modbus TCP. The latter
protocol would prove to be pretty useful for this PDP-14 emulator. The
emulator would act as one Modbus master and send out packets (in the
Modbus TCP format) to a remote/distributed I/O unit of the user's own
provision. Making it generic means it doesn't require specific
hardware; making it Modbus protocol means it talks to a gigantic swath
of hardware.

So, please do submit it to be merged into the SIMH framework, it
sounds like fun! (And sounds like practice for writing a Modbus TCP
master… to me.)

Cheers,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.

Re: Full immersion emulation

[Christian Gauger-Cosgrove via cctalk]

I'm replying to the "top level" original message just to put some
other comments in on "full immersion" emulation, without trampling
over the discussions that are going on about the sound experience.


On 1 March 2017 at 14:14, Charles Anthony via cctalk
 wrote:
> Part of the iconic mainframe experience is the cold room sounds; for early
> Multics installations (and other systems) the sound of the Selectric
> operator's console.
>
Don't forget what a machine room and the equipment looks like.


If one wanted to go "full immersion" it might be an idea to acquire an
HTC Vive and develop the it as a simulation VR experience. Then you
get the sights and the sounds. With the Vive (and not the Oculus Rift)
you also get the room scale VR "stuff" and hand tracking controllers.
You can add in more things than just the sounds of the terminal, you
can include mundane tasks like swapping disk packs, swapping tapes,
and using the various consoles and buttons on the devices.


Just to point out this kind of simulation of an location with "things
to do" has been done in VR. May I present to the list, for your
delectation: "New Retro Arcade: Neon" 
It's a VR recreation of an arcade.


Naturally, there's all kinds of hurdles to deal with in creating a
simulation like that. First of all VR (at present) needs beefy
computers (Do you have a high end gaming graphics card on a modern up
specced PC? No? Then no VR for you!) and the VR hardware itself isn't
cheap. Next there's the development time investment, and while the
Vive's hand controllers do let you manipulate things in the VR
envrionment they're most assuredly not what you'd want to use for
typing at a simulated keypunch, printing terminal, or video terminal.
(Though you can just use your PC's keyboard for that. And for machines
that have mice (workstations, anyone?) you can also use the mouse too;
light guns/light pens can be "done" with the hand controllers.


Then there's the topic of *cost* you could release it for free, but
there's a lot of work that has to go into the thing. Selling it for
cost well, the market is limited so you'd probably not really make
anything (I'd sure as hell buy it... if I could afford a beefy PC and
VR hardware).

And let's not get anywhere *near* the topic of including the software
to run on the simulated hardware with the program. Though, if it was a
simulator of an IBM System/370 ("Who wants to reimplement Hercules in
a game engine? No one? Smart move...") you could throw in MVS or
OS/360 since they're both in the public domain. You could provide the
software as just the "naked" simulator, with the user needing to
acquire disk/tape images on their own initiative, but now you've
reduced the number of people from outside of the already "expert"
community of us classic computer hobbyists who would be able to use
the software.


One could also make such a simulation in a regular 3D game engine and
then bolt on VR support later. That's a much larger "market" in terms
of people who could run it, though it wouldn't be nearly as immersive
as a VR experience. Though it would still be fun to try. (Look up "My
Summer Car" it's an indie game where a main is putting together and
then driving a beat up junker of a Datsun 100A.)



Anyways, I'm rambling.

Cheers,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.