> From: Fritz Mueller
PPS:
> I could work to extract the core file
I just checked, and the binary for the 'ls' command is what's called 'pure
code'; i.e. the instructions are in a separate (potentially shared) block of
memory from the process' data (un-shared).
I don't recall off the top of my head whether the location of that shared
block of memory is in the per-process swappable kernel data (which is included
in the process core dump). I'll check tomorrow, when I'm not sick as a dog
(pretty miserable right at the moment).
It would be east to mod the OS to print all that info when that illegal
instruction trap happens - but that will change the size of the OS, so will
probably change the location the process is at; so that might cause the
symptoms to change. Ditto for recompilling 'ls' to make it a unified blob.
> Assuming that doesn't create another core file... :-)
:-) Don't worry, we'll nail it!
Noel
At 11:05 PM 8/01/2019 +0000, you wrote:
>While tidying up I've found a few Irman infrared to serial dongles
>
>https://web.archive.org/web/20060314052558/http://www.evation.com/irman/ind…
>
>they connect via a 9 pin serial plug and then convert any consumer
>remote IR signals they receive into serial.
>
>No additional power required, good wide angle reception, open source
>driver still available
>
>https://sourceforge.net/projects/libirman/
>
>Could make an interesting project for anyone who wants to control
>their VAX / S-100 / homebrew retro board with a serial port via a
>remote :)
>
>The company making them went away about a decade ago, so I'm counting
>that as in retro territory.
>
>I have four for the price of shipping if anyone is interested, based
>in London/UK.
>
>(Around 2000 we had an office music system based around a DNARD/Shark
>running mserv & irman where everyone had a random remote at their desk
>and could use it to rate/skip/queue something they liked, and the
>system generally trid to pick from music which most of the people
>currently connected liked... ahh, fun days :)
>
>David
I'll definitely take one. Or preferably two, if that doesn't clash with anyone
else wanting one.
I'll send my address via private email.
Can you accept Paypal for the postage?
Guy
Chuck we would like a couple..? ed at smecc
Sent from AOL Mobile Mail
On Tuesday, January 8, 2019 Chuck Guzis via cctalk <cclist at sydex.com; cctalk at classiccmp.org> wrote:
On 1/8/19 3:05 PM, David Brownlee via cctalk wrote:
> While tidying up I've found a few Irman infrared to serial dongles
>
> https://web.archive.org/web/20060314052558/http://www.evation.com/irman/ind…
>
> they connect via a 9 pin serial plug and then convert any consumer
> remote IR signals they receive into serial.
I just posted on github a little project that takes a cheap surplus (my
last ones cost $5 NOS) IBM iPoint IR keyboard and converts it to PS/2
keyboard protocol using a cheap STM32F103 "Blue Pill" and a 3-terminal
38KHz IR receiver.? I'm currently writing the USB version which will
support the "nipple mouse" as well.
The keyboards aren't bad--they're made by Silitek ca. 1992 and have a
decent feel for a rubber dome keyboard.
The point is that with modern MCUs, any IR stuff is easy-peasy.? My
little Chinese LCR tester even reads and displays IR codes.
--Chuck
While tidying up I've found a few Irman infrared to serial dongles
https://web.archive.org/web/20060314052558/http://www.evation.com/irman/ind…
they connect via a 9 pin serial plug and then convert any consumer
remote IR signals they receive into serial.
No additional power required, good wide angle reception, open source
driver still available
https://sourceforge.net/projects/libirman/
Could make an interesting project for anyone who wants to control
their VAX / S-100 / homebrew retro board with a serial port via a
remote :)
The company making them went away about a decade ago, so I'm counting
that as in retro territory.
I have four for the price of shipping if anyone is interested, based
in London/UK.
(Around 2000 we had an office music system based around a DNARD/Shark
running mserv & irman where everyone had a random remote at their desk
and could use it to rate/skip/queue something they liked, and the
system generally trid to pick from music which most of the people
currently connected liked... ahh, fun days :)
David
> From: Fritz Mueller
PS:
> I could work to extract the core file
Can PDP11GUI save output from the -11's console? If so, just say 'od core',
and send me the output.
Noel
> From: Fritz Mueller
>> the last microinstruction for RTI/RTT has been moved from 002 -> 744.
> So what's at 002 now? Maybe something new was required there by micro
> branch/fork logic, so the original contents had to be moved?
Well, it turns out I've been transcribing the ucode flow diagrams from the 34,
as part of a deeper look at the 34. (Dave B and I need a PDP-11 in the FPGA on
the QSIC, to run the USB protocol on; rather than using a microcontroller, we
decided the hack value of putting an -11 in there was too much to resist. It's
also practical, though - we're already very familiar with it, have a good
toolchain for it, etc. One option for that - we know about the existing FPGA
-11's - was cloning the /34.)
So according to that table:
http://gunkies.org/wiki/KD11-E/EA_microcode
there is no uinst at 002 now! So I have no idea why they moved it. (The place
they moved it to, 0744, seems like it was the first empty location.)
There is a dump of the 34A microcode here:
http://www.bitsavers.org/pdf/dec/pdp11/1134/m8266_ucode.out.txt
and for 002 it gives
Called by......... = IR or BUT only
NEXT MPC.......... = 015
but 015 doesn't seem like a useful place to branch to? Maybe location 002 was
just abandoned (I have no idea why), and that's some leftover trash?
BTW, the engineering drawings contain three errors (fixed in the table above;
see the notes there), so I suspect they were drawn up by looking at a set of
the listings. I wonder if the actual source has survived? Probably not,
alas...
Noel
> From: Fritz Mueller
> Kernel boots on my actual hardware, but an "ls" in single-user mode
> generates a "Memory error -- core dumped".
Oh, yeah, your hardware definitely has issues, then.
> So evidence is mounting that I really do have some sort of issue with
> my MS11-L.
If so, I'm rather suprised that the DEC diagnostics didn't pick it up.
> Tried a multi-user boot for kicks
You're stu^H^H^Hbrave!
> I'm actually able to "ls" under that.
Yeah, probably your process wound up at a different place in physical memory
(although there are a zillion other ways one could get that effect, depending
on exactly what the issue is - e.g. maybe a bad bit in the memory word where
the process table happened to wind up).
> I could work to extract the core file
The 'ls' one, please (shorter/simpler); I can poke around in that, and see if
I can find any clues as to the cause.
> probably the best application of effort would be to do develop/run more
> diagnostics on the MS11-L
OK.
I also have a little memory diag that I wrote myself that you could try. Let
me know if you'd like it; it's currently for the /23+/73 (and it would
probably work on the /70, I'd have to check) so I'd have to tweak a few
things to get it to run on a /45. Best way to get it to you would be to send
you the Unix assembler source, if you can get that onto the disk, then you
could:
as memptst.s
mv a.out /memptst
and just boot it.
Noel
> From: Fritz Mueller
> I should go read up on QSIC.
There's not much on the Web, alas. We have two working prototypes (a wirewrap
QBUS mother-board with bus transceivers, level converters, etc, connected to
an FPGA prototyp ung card by flat cables), and working FPGA code to emulate an
RK11, using a uSD card for actual storage. It's good enough that the /23 can
boot and run V6. We also have working indicator panels:
http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html
but the inlay we've done:
http://pdp10.froghouse.org/qsic/indicator-panel-printed.jpg
is not a straight copy of an existing panel (those all have lots of lights
that only make sense with a real drive, and leave out others that would
be really useful, e.g. the address). Here:
http://pdp10.froghouse.org/qsic/manual.pdf
is the firat crack at the manual for the production version (the RP11 is not
done yet).
> I could really use a "USIC"... :-)
That's next, after the QSIC is out. It will include Able ENABLE:
http://gunkies.org/wiki/Able_ENABLE
functionality, so UNIBUS machines can have more than 256KB of main memory.
> Probably the best thing would be to pop a ROM out of a working /34 and
> read it out? Is that how you've gotten your authoritative version?
I didn't get it, I found it on BitSavers - I assume that was what whoever
provided it did. But it's actually stored in 12 4-bit wide PROMs, U95-U118
(roughly).
Noel
> From: Fritz Mueller
>> http://www.tuhs.org/Archive/PDP-11/Distributions/research/Ken_Wellsch_v6/
> Hmm, this link didn't work for me
Arggh, sorry. I simply copied the link from my page:
http://www.chiappa.net/~jnc/tech/V6Unix.html
and didn't check it. :-( I'm a bit suprised that Warren broke everyone's deep
links by re-organizing...
> I found I think equivalent mirrored at:
> https://www.tuhs.org/Archive/Distributions/Research/Ken_Wellsch_v6/
> ...which directory contains several file system images and one tape
> image, "v6.tape".
Argh. I thought there _used_ to be disk images there - maybe they got removed?
Anyway, the one you want is now here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/V6Root
Just decant all the bits onto a RK pack, starting at block 0, and you should
be able to boot that pack.
(I'll fix my page a little later, burned out after the microcode
transcription!)
> Is that tape image maybe not compatible with SIMH's tape format?
It's just a plain copy of the contents of a V6 distribution tape. IIRC, SIMH
wants 'tape' files with meta-data such as the length of each tape record, file
marks, etc.
Noel
> From: Fritz Mueller
> Oh, one last thing: if anybody else out there has a real working '11/45
> + RK05 and wants to try this RSTS image, let me know, and I'll send you
> a copy (all 2.5MB of it, hah). It'd be interesting to see if this a
> really just limited to my machine?
Good idea. Two more along the same lines:
Try running your RSTS image on Ersatz-11, see if it's a simulator issue.
And try bringing up Unix V6 on your machine; if it's a hardware issue with
your machine, it might show with that, too. (I can help with fault analysis
on V6, if _anything_ doesn't work properly.) It will need a single RK pack,
I can help with providing the image, if needed.
Noel
