Was Seth the person looking for this stuff? I finally found it! I sent him
an email, but it might not be a current address.
Seth, if you still want this stuff, please let me know!
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
AOL IM elcpls
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Hi,
The PAL vrs NTSC TV standard complicated things when collecting home
computers from other countries.
In New Zealand we are on PAL. PAL Atari 800s are rarer in the world that
NTSC ones. That being the case I recently settled on an NTSC one for my
collection. Hooking it up to a couple of my PAL TVs (via composite video)
I was surprised to see a reasonable colour image. I then dropped in a UAV
video enhancement board and was surprised to see a very good colour image!
I'm assuming it's because composite input into "relatively" modern can
handle NTSC and PAL? Is this a reasonable thought? The UAV is not an NTSC
converter, and even the inventor was surprised this worked.
Those interested can read about the adventure here:
https://www.classic-computers.org.nz/blog/2018-03-06-Converting%20-NTSC-Ata…
Terry (Tez)
> From: Cindy Croxton
> I finally found it!
Oh, that is so awesome! Thank you for keeping an eye out!
(I'm sure somehow it will get saved - Seth, let us know if you do, otherwise
we can organize something.)
Noel
So I have an M837 (KM8-E Memory Extension and Time-Share option for the
PDP-8/E, -8/F & -8/M) available; got it with a group of other cards, and I
have no use for it.
Anyone want it, and have (or can acquire :-) anything PDP-11ish (boards,
mounting hardware, manuals, prints, I'm not picky - although it has to be
something I need/want, I'm already knee-deep in DL11's :-) to trade for it?
Noel
Hey, all, a quick update on recent progress.
I now have a working prototype to match Dave's (although he's still doing all
the real work), and we've made a minor improvement in them (re-wired things so
we can use shorter cables to the FPGA daughter-card).
I got my indicator panel working, it looks quite nice:
http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/jpg/DasBlinken2F.jpghttp://ana-3.lcs.mit.edu/~jnc/tech/QSIC/jpg/DasBlinken2NF.jpg
The inlay is an original from a TS08 that I happened to have lying around; Rod
S has made us a large batch of new blanks, but silk-screening of the captions
on the front of those is yet to happen. The bezel is also an original. (I have
a large stock of those, so it'll be a while before we need to work out how to
make new ones - probably resin casting, although 3D printing will be an option
too.) However, the guts are all new, and as you can see, the result looks just
like the real originals.
Dave has also worked out how to connect up the RKV12 (our name for the 22-bit
RK controller, by analogy with the RLV11/RLV12) to the internal 'block' RAM in
the FPGA, and then did the stuff to connect it to both the uSD card and the
internal RAM at the same time, with one drive connected to the RAM, so things
like swapping, etc don't 'waste' uSD writes.
Both of these are working quite reliably; the exciser/tester runs until we get
tired of the noise, and turn the machines off! :-)
His current project is to work out how to talk to the larger external RAM on
the FPGA daughter-board (the internal RAM isn't large enough for even a single
complete RK pack). I'm so looking forward to putting swapping, /tmp, pipes,
etc all on different platters, so as the system (Unix V6, natch :-) runs I can
watch the lights and see _exactly_ what's going on!
After that: turning the RK into an 'RPV12' (which should be pretty easy, the
RK11 and RP11 are very similar), and adding a mux so that the two controllers
can share the storage devices, etc. Those should both be done soon after the
external RAM (and maybe before, if Dave needs a break from that :-).
We also intend to do an 'extended RP11' (name not yet chosen, although I like
'RPV-12D - DEC's last was the RP11-C), which extends all the disk address
fields in the register to use the unused bits, giving us pretty massive
storage capability. With 16 bits of cylinder (up 7), 8 bits of surface (up 3),
4 bits of sector, that gives 28 bits of block number per drive; and with 8
drives per extended RP11, that's a total of 31 bits of block number per
controller. Convert the blocks to bytes, that's 9 bits more, so 2^40 bytes per
extended RP11, or 1TB!
Very shortly now we'll need to turn to starting on the design of the
'production' hardware.
Noel
In doing some research on the operating system for MU5, MUSS, I have been
told that a UK company called Membrain may have acquired it at some point in
the late 70's. Membrain were based in the South of England and made
Automatic Test Equipment.
Does anyone have any information on Membrain? Any software artefacts? Source
code even? I have had a look on BitSavers and Membrain does not feature at
all.
Thanks
Rob
Someone had ?asked me ?about ?they were looking ?for Claude Shannon Bell ?Labs ? ?publications ?for a ?display? Please email me ?off?list
Thanks ?Ed Sharpe archivist? for SMECC