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