I have seen multiple posts over time speculating about flooding in the
warehouse. I would like to assure everyone that the warehouse has never
flooded, and that any posts to the contrary are inaccurate or greatly
exaggerated.
I have cleared a significant area inside the warehouse and have not seen
any indications at all of floodwaters entering the building. Additionally,
the landlord has also confirmed that the building has never flooded.
The only moisture-related damage that has occurred at all happened to paper
articles in direct contact with the cement floor (The floor is bare cement,
and gets moist during heavy rains). Such items have all been discarded. The
computers, even those that touched the ground, are undamaged. If I were to
find a computer with water damage, it would be clearly labeled as such when
being sold.
If you have any questions, please email me directly, and I will gladly
answer them to the best of my knowledge.
Thomas Raguso
I might have had something to do with
https://www.sinenomine.net/products/vm/njeip
And as far as I remember, at least some of it was BSD licensed, so if
that's what floats your boat...knock yerself out.
So, on this Model III I'm working on the following keycaps are missing:
1/! key
right shift key
Looks like keycaps from a Model III, and possibly a model I would work.
Probably a Model IV keycap for 1/! would work, but I think the right
shift key would be different between a Model III and Model IV.
I also need one of the ALPS switches as the '+' part of the stem is
broken off.
In addition, on the drive (Texas Peripherals), there is a plastic
component that screws onto the aluminum arm with the diskette retaining
hub with 2 screws.... it then accepts two plastic pins that connect this
piece to the drive door. I am missing on of the plastic pins and the
plastic piece is cracking.
Anyone have any of these parts kicking around.
On a Model III upgraded to a Model IV I have, the ribbon cable to the
serial/com board has 'self destructed' as the glue failed, so once
removed it could not be reconnected. Interestingly the cable for the
floppy controller did not deteriorate ?????
Sadly on the upgraded Model III someone converted it to 3 drives, using
an original full height drive for the 1st drive (at the bottom), and put
2 HH drives in the top bay. To make room for the eject control on the
top drive, the upper case has been notched. It would be nice to find an
upper case for a Model III and do away with that notch.... or
alternately an empty Model IV case (top and bottom).
Thanks to anyone with any TRS-80 'parts vault' that may have these
parts available.... It has been a long time since I have touched a
Model I/III (last time was probably 1983 :-) ). Looking forward to
getting the 3 systems I have up and running (Model I with Expansion,
Model III, and a Model III upgraded to a Model IV).
Thanks in advance,
-- Curt
Daniel,
>>
>> Yes, can (get a kit with SMT work done)
>
> OK, that?s the answer I needed;
> If I want to put one of these in a KS10, can the parity lines be
hacked from the software
> (the KS10 uses them as two extra data bits) or are they hard-wired to
parity?
Several people asked to make UniBone PDP-10able, it should be not problem.
UNIBUS PA,PB are (like all other signals) just pins on a GPIO
multiplier, no interpretation is done in hardware.
On software side the PRU must sample 18bit instead of 16bit for DATA,
then lots of "uint16_t" must be changed to "uint32_t" in the whole
software stack.
Not clear what to do with existing device emulators: did DEC construct
18bit mutants for a few PDP-11 peripherals to run them in KS10?
UNIBUS on a PDP-10 makes only sense to me if the big pool of PDP-11
peripherals can be used directly.
regards,
Joerg
-------- Forwarded Message --------
Subject: 3270 controller simulation
Date: Mon, 18 Nov 2019 19:43:24 -0600
From: Andrew Kay
To: aek at bitsavers.org
Hi Al,
I'm waiting for approval to join the cctalk mailing list but I heard
on IRC you were interested in my project so hope you don't mind me
reaching out to you directly.
Unfortunately I don't have much in the way of useful documentation
other than the code itself right now - I am planning on putting some
documentation on the protocol together as well as a basic write-up on
what I've discovered.
Anyway - everything I've built so far can be found at
https://github.com/lowobservable/oec and the linked projects (for the
coax interface and TN3270 library).
It's still pretty basic at this point but can do enough TN3270 and
VT100 emulation to be usable. Here is a more recent photograph
showing it connected to the Master the Mainframe server -
https://i.redd.it/1kpbe3muvbz31.jpg.
For the coax interface I'm using two obsolete ICs from National
Semiconductor - the DP8340 and DP8341 and using an Arduino to connect
these to a PC. I was really excited to see somebody on the mailing
list mention they were working on an FPGA interface - building an
interface that didn't depend on obsolete components is my plan for
next year but I have to learn some electronics first.
Please feel free to copy the above to the mailing list - I definitely
want to join (do you know if it is possible to join with a GMail
account, the last I heard was I was waiting to be approved), I had no
idea there were so many people interested in 3270 things :-)
Andrew
On 11/18/19 11:10 AM, Paul Koning wrote:
> Open systems may be distributed, distributed systems may be open, but
> they are not synonyms.
Okay. Fair enough.
I don't think the people using "Open Systems" as in Mainframe vs Open
Systems vs Wintel were differentiating between "open" vs "distributed".
> For example, I'm not sure anyone would call VMS an open system, yet
> clearly it's distributed (VAXcluster).
What is "open" in this context? Is it open source? Is it open
communications protocols? (As in OSI / POSIX.) Is it something else?
I suspect that OpenVMS qualifies as the OSI / POSIX meaning of "open".
;-) But OpenVMS is decidedly not open source.
OpenMVS (a.k.a. USS) on the mainframe comes to mind too. }:)
--
Grant. . . .
unix || die
Hi all,
Some time ago I've got from a friend a defective ECB Bus Card named
GRIP-4, that's a ancient Z80 based graphic display controller Card
using the MC6845/HD6345 CRT Controller made by the (still existing)
german Company Conitec in the 80s.
Additional I've got an empty extension PCB called Grip-Color..the for
color needed Memory, shift and palette registers.
I've phoned the CEO from Conitec in the meantime and he will send the
paperwork regarding the GRIP-4 that he still could find to me for
scanning, unfortunately he couldn't find anything for the Grip-Color card.
I have a running ECB bus system with an REH-CPU280, an Z280 based System
that could run CP/M-3 and UZI280, has an FDC on board and an IDE Interface
with an 128MB Flash disk, I whish to extend that with the GRIP Cards..
Is here someone that could please provide some Information related to the
Grip-Color Card? I think I've repaired the GRIP-4 in the meantime (still
have to connect an CRT, just replaced the FBT [different Model and
Make] in the Monitor that I want to connect), but the oscillograms are
looking good.
I whish complete the Grip-Color card, any helpful information is welcome,
even a picture where I can see which ICs are soldered in.
https://www.z80cpu.eu/mirrors/oldcomputers.dyndns.org/public/pub/rechner/co…
Thanks in Advance,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
info at tsht.de Fax +49 3731 74200 Tel +49 3731 74222 Mobil: 0172 8790 741
Finally got my xxdp+ floppy in the mail. The RX50 is flakey (probably
needs a head cleaning, 95% isopropyl safe on these heads?) but I have it
booted. Problem is in the RQDX3 formatter the drive shows up as drive 0,
but generates an FCT write error.
Questions:
1) I assume all cables in the BA23 chassis should have pin 1 to the left
(away from fans), correct?
2) On the RD54 should it be jumpered as drive 1, or drive 4, or
something in-between?
3) On the BA23 panel I assume the ready light should be on, the ready
buttom for the RD54 should not be pressed, and the write protect light
should be off with the write protect button not pressed, correct?
One step at a time, as they say....
C
I have made the module available at https://github.com/cwsimmons/raw3270
For now it probably looks like a mess, but I hope to add comments and build the coax circuit later this week. I just wanted to get it out there now since I know there is interest.
Chris
On 11/18/19 3:14 PM, Ethan Dicks wrote:
> I could fill books about the topic... we sold hundreds of Unibus and Qbus
> boards (and a few VAXBI boards) for bisync, and dozens of boards for SNA.
~chuckle~
> I have all the hardware and software and documentation from Software
> Results, but there is nobody left out there to talk Bisync to.
I wonder if some of the people in the mainframe community would be
interested in running Bisync. But I don't know what sort of hardware
interface would still be usable. :-/
There's work afoot to create a new BITNET. But I think that's using
NJE, likely across TCP.
--
Grant. . . .
unix || die
Hi all,
I recently picked up a ?tabletop? RX01 drive for cheaps. So now I?m in the market for:
- RK11 controller
- cables
- rack ears, rails (how was this done?)
- formatted media
If anybody here might have any of this and like to work out a deal, feel free to let me know off-list!
thanks much,
?FritzM.
I have located the Cray Y-MP EL, in addition to other other interesting
items, including an Intergraph 6400 workstation with tablet, a PDP-11/23,
an IBM System/34 with 5251 terminal and keyboard, a Unisys A-Series
mainframe, and a Symbolics 3640 Lisp machine (includes console, but there
is no keyboard).
Pictures can be found here: https://photos.app.goo.gl/rgkBddeuosjnJ3TC6
I am taking offers on all of the above listed items.
Thomas Raguso
I am just wondering if anyone out there has a source for cheap but reliable
Rechargeable "gum stick" batteries. I am trying to replace some old
batteries and the only source I could find are these:
www.amazon.com/dp/B0047ZW46C/. Not sure on quality of the generic green
batteries, especially since they are going to be in a computer on an ISA
card and not easily visible. TIA!
-Ali
As it happens I wrote a Verilog module last week for serializing and deserializing 3270 coax frames, without realizing someone had already done this with an arduino. What I?ve written is intended for a zynq device but is general enough to be used in other designs.
At the moment I have petalinux installed and can send frames with a small test program and see them on my scope. A loop back configuration also seems to work. I haven?t build the coax driver circuit yet so I can?t be sure of it?s correct operation.
I?d be willing to make this code available tonight. Although I?m not sure how many people have the right hardware lying around.
Chris
I have a query out on VCFed, but I am not gettin gany interest. Neither did my 2015 request on a similar topic - must be the wrong forum.
Advice please: where is the best place to get some troubleshooting tips on debugging a DIGITAL H7202B power supply?
I have 2 supplies that are giving me trouble. I am competent at digital work, much less so on switch-mode and analogue
(555 is an analogue in my books!). I have variacs scopes, logic analysers, voltmeters but no skill ;-(
Any advice?
Its been a long time since last public post about UniBone, time for a
bragging broadcast.
*What it is:*
In case you forgot: UniBone is a plugin board to DEC PDP-11 UNIBUS
systems containing a BeagleBone Black.
See http://retrocmp.com/projects/unibone.
This combo can simulate PDP-11 devices embedded in a physical machine.
So you can operate and repair incomplete UNIBUS PDP-11s and even VAXes,
just by emulating the missing parts.
Disk drive emulators accept SimH image files, which can be ftp'd to the
emulator (no SDcard changing!).
As UniBone can acquire bus mastership, its also UNIBUS diagnostic
console, as well as stimulate individual UNIBUS lines.
Realtime stuff is implemented on BBB's PRU coprocessors.
All programming is done in plain C/C++ under mainstream Debian Linux.
*Whats new in 2019:*
UniBone started with memory and RL11/RL02 emulation.
In 2019 we did a lot of programming and debugging (suppressing endless
techno-babble here).
Thanks to some gifted supporters, we have now these devices:
- DL11 serial port (first concept by David Richards)
- 11/20 CPU (Angelo Papenhoff)
- RK06 and MSCP disk drives (Josh Dersch)
In fact UniBone implements now a complete PDP-11 system... a bit like a
SimH with UNIBUS interface.
UniBone was tested (at least) against PDP-11/05, '34, '44, '84 and VAX
11/750.
Verified OSses include XXDP, Unix V6, 2.11BSD, RT11, RSX11M/M+, VAX
4.3BSD and Ultrixes.
Special thanks to Mark Matlock for endless testing.
*Available?*
Soon. About 25 complete systems were distributed, and the same amount in
kits. Not much complaints.
User group at https://groups.google.com/forum/#!forum/unibone
Just now I'm planing for a 2nd lot.
And it will be shown on http://vcfe.ch/doku.php in Zurich on Nov
30th/Dec 1st, probably plugged into a PDP-11/05.
best regards,
Joerg
The question "FPGA or not?" keeps me still awake at night, so some
rambling here!
> Is the BBB not fast enough to do Qbus? Meaning, for qbus, would a
FPGA be necessary?
> Or was this just the op's choice among many possible options?
I was considering a FPGA solution first, even had a Xilinx ZYNQ training
for that.
But switched to BeagleBone PRU soon for several reasons (many
non-technical ones).
Speed is essential. OK, UniBus/QBus are asynchronuous, so you can delay
bus cycles
when your emulated devices need processing time.
But the emulator has to watch bus activity in realtime for register
accesses to emulated devices.
Problem here is not ARM processing power (1+ GHz is fast enough), but
delays in the GPIO
access and random code delays by Linux task switching and RAM refreshes
and the like.
So you need to have some realtime logic on the bottom of all the C code.
UniBone should be "community friendly", a FPGA would mean:
- code developers need VHDL/Verilog skills and a special tool chain
- kit builders need to program the FPGA and solder these damn fine pitch
parts.
- Technically, a interface between ARM core and FPGA is time-critical,
would not work on RPi FPGA shields. So either you implement EVERYTHING
in FPGA, or you are bound to some FPGA SoC demo boards.
As the BeagleBone has these realtime PRUs:
- all development is done in C/C++, familiar cross platform debugging in
Eclipse.
- the edit-compile-debug cycle is very fast: 10 seconds for a partial
recompile & program start when
developing remote from a modern PC.
- The whole toolchain (gnu gcc and PRU C commpiler) also runs on the BBB
itself, so you can
develop new code immediately.
- BBB is slim enough to fit in a DEC card slot, is cheap (down to $60
now) and will be available for years.
- big Debian/BeagleBone community behind,
Drawbacks of the ARM+PRU approach were:
- the realtime stuff is done with sequential code, so manual
optimization was needed.
- the PRU code&RAM space is limited, design can not be scaled up endlessly.
- limited pin count available, a GPIO multiplier was needed.
UniBone is a success because indeed several contributors accepted it.
Despite choosing BBB, I wasn't sure for long wether that ARM+PRU
approach wouldn't be a dead end technology.
There was not much development on the BeagleBones for 5 years, but with
the new
BBONE-AI, everything has changed.
TI followed the "Linux ARM + coprocessors" road here in a spectacular way.
The mandatory move to "multi core, GHz, RAM, WiFi, GBit Ethernet, USB3"
has been done too.
> It does seem useful to have this thing run linux and ethernet and be
able to pass
> files (data and programs) back and forth very easily.
> the FPGA approach seems more technically challenging but seems less
universal (to my limited mind).
> It would seem a BBB you could load software, test, and reload as
easily as
> copying some executable code (I dont know if that is correct or an
over simplification).
> whereas the FPGA sounds like it needs to be recompiled/re-burned each
time?
All true, see above.
>
> I dont know whether an RPi could work or if the BBB is needed for
speed etc.
RPi's are faster and have more ARM cores than BBB, but thats in fact not
needed.
"Realtime determinism" is the keyword here, as well as GPIO speed.
BBB PRUs can toggle GPIOs with 50+MHz.
regards,
Joerg
We would love tunnel diodes in packaging for our semiconductor? display ay smecc ed#
On Friday, November 15, 2019 charlesmorris800--- via cctalk <charlesmorris800 at centurytel.net; cctalk at classiccmp.org> wrote:
>I've got a bunch of tunnel diodes; never found a practical use for them
for me.
You must not own any older Tektronix scopes then. At one time I had fourteen and there were several tunnel diodes in almost every one (trigger circuits mostly).
And their characteristics do drift with age, sometimes out of the range of adjustment
:)
-Charles
I am the author of tcpser, a UNIX/Windows program that emulates a Hayes
modem.
Some time ago, Chris Osborn (FozzTexx) forked a copy of my project to
fix some bugs and he also added in some parity code, which looks to
strip parity from the incoming serial connection (in the case that the
serial port is set as 8N1 and the computer attached to it sends in 7E1
or similar.
I am working to merge in all of his changes into the mainline codebase,
but I am unclear on prpper Hayes behavior.? His Readme says:
https://github.com/FozzTexx/tcpser/commit/5f0e28bb837463e597a1daf9b3c07e56a…
"I also made the modem routines automatically detect parity and ignore
it in AT commands and print out modem responses in matching
parity. Parity is *not* stripped when sending data over the
connection, which is how a real modem behaves. This may or may not be
what you want. Some servers will expect an 8 bit connection and may
not work."
Did Hayes modem really do that?? I thought most later modems self
detected parity and speed and thus would have switched both the comm on
the serial port and the data sent to the other side in the same parity
(if the terminal was 7E1, the modem would configure as 7E1 and send 7
bit data to the other side.
But, maybe real modems did as Chris notes. Anyone have guidance on
this?? The goal of tcpser is to emulate a Hayes modem as much as
possible, but I never really thought about mismatched parity on the
RS232 line and how to deal with it.
Jim
--
Jim Brain
brain at jbrain.comwww.jbrain.com
>I've got a bunch of tunnel diodes; never found a practical use for them
for me.
You must not own any older Tektronix scopes then. At one time I had fourteen and there were several tunnel diodes in almost every one (trigger circuits mostly).
And their characteristics do drift with age, sometimes out of the range of adjustment
:)
-Charles
I may be stating the obvious here but looking for a little advice and
reassurance from anyone on the list who may have had experience with these
machines.
I have a couple of TI99/4A's that I was given quite a long time ago along
with about 50 software cartridges (if I understand things correctly the
cartridges on their own a quite a bonus). What I am missing are power
supplies. On my research the inputs are 12 and/or 5 volt depending on the
number of power pins on the back (mine have 2).
These voltages appear to neatly align with most PC power supplies so I
should be able to tap into an old AT power supply of which I have quite a
few.
Thank you.
Kevin Parker