Re: DIGI-COMP 1 enhanced

[Jörg Hoppe via cctalk]

Hi,
It it possible to get parts for a Digicomp? Mine needs some springs and 
 the thing that connects the clock to the whatever.

I used rubber bands instead of springs.

The article about 3D print DIY
https://www.thingiverse.com/thing:1477209
contains instructions how to bend the wire crank.

regards,
Joerg

 > >/I added a motor drive to my DIGI-COMP I, and wrote 4 web pages about /> >/that device. /> >//> 
>/See http://www.retrocmp.com/articles/digi-comp-1/ /> >//> >/or just the video 
https://youtu.be/D6GgxXRJXnw /> >//

Re: DIGI-COMP 1 enhanced (Joerg Hoppe)

[Jörg Hoppe via cctalk]

/Hi Michael, />>/I added a motor drive to my DIGI-COMP I, and wrote 4 web pages about />>/that 
device. />>//>>/See http://www.retrocmp.com/articles/digi-comp-1/ />>/or just the video 
https://youtu.be/D6GgxXRJXnw /

That is very cool!
The RICM has a DIGI-COMP, but we have not done much with it other than put
it on display.

--
Michael Thompson


I attached the Arduino firmware and the "Bill Of Materials" with all 3D print 
files to
http://www.retrocmp.com/articles/digi-comp-1/305-digi-comp-1-show-case-project

So if you like ...

kind regards,
Joerg

DIGI-COMP 1 enhanced

[Jörg Hoppe via cctalk]

Guys,

I added a motor drive to my DIGI-COMP I, and wrote 4 web pages about 
that device.


See http://www.retrocmp.com/articles/digi-comp-1/

or just the video https://youtu.be/D6GgxXRJXnw

best regards,

Joerg

UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

UniBone emulates now the M9312 bootstrap ROM card.
Each of the 5 ROMs can be loaded with MACRO11 listings files from
http://www.ak6dn.com/PDP-11/M9312/
The tricky bootvector redirection logic is also implemented.
The address to execute after power-on is given as symbolic MACRO11 label.

For demonstration the script "m9312+xxdp_dl0.sh" is given,
which boots into 11/34 console emulator, or auto-boots XXDP from RL02.

kind regards,
Joerg

UniBone (Linux-to-UNIBUS bridge) available

[Jörg Hoppe via cctalk]

Hi,

After half a year I can dump out UniBones again.

Seems I lost contact to several interested guys, hope this broadcast helps.

Info: http://www.retrocmp.com/projects/unibone
Conditions: http://www.retrocmp.com/projects/unibone/283-unibone-getting-one


best regards,
Joerg

Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

Hi,


I'll add that I started working on RH11 emulation on the Unibone last week,
i'm making steady progress (as of yesterday it's able to boot the 2.11BSD
kernel before falling over).  16-bit only at the moment, 18-bit will
require some infrastructure work but I'll leave that to Joerg :).



I just ordered a UniBone from Joerg, and my KS10 seems to work ok to the
extent that I can test it.

Is your code available somewhere? You will probably run circles around
me while I get up to speed on what is what, but I would still like to
set up a development environment.


The repository is
https://github.com/j-hoppe/UniBone

UniBone is its own development platform.
The first thing you'd do after unpacking is to run script
./github-sync.sh
which updates all sources and starts a big recompile.

There's also a ./compile.sh for selective build.

Personally I prefer cross-compiling from a X64 Linux Kubuntu under 
Eclipse. There the compile is 30 seconds instead of 4 minutes, I have a 
rich programming environment and can remote-cross-debug UniBone code via 
networked gdb/gdbserver setup.


Btw, UniBone needs about 2 amps of 5V power over the screw terminals, if 
not run in a PDP-11 (or 10!). Do not try USB power.


For controlling the 18bit DATA path inside the software, I think best is 
a global

#define DATAWIDTH18 (or similar)
to indicate the special KS10 compile. We don't need to switch 
dynamically between 16 and 18 data bits, a special binary is all we 
need, right?


kind regards,
Joerg

UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

Hi Pontus,

This thread makes me very happy.

I have a KS10 that I'm working on (quite slowly). The PSU is checked out 
and working. Then console seems to work, I can deposit/examine to CRAM 
and RAM.


Next step will be to load micro code and I've been mentally preparing to 
tackle an RH11 emulator for the Unibone.


I'll buy one from Joerg as soon as the second batch is ready and me and 
my KS10 will happily be guinea pigs.


And if I can, I'll help with development.


I now have UniBones ready to ship.

More on PM,

kind regards,
Joerg

UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

2. When doing 18bit on UNIBUS-A we put all kind of signal levels
on parity lines PA,PB = DATA<16:17>.
Won't the KS10 CPU interpret these as real BUS parity errors generated
by some UNIBUS-A device?


I asked nonsense here: if UNIBUS-A is 18bit too, no parity will be evaluted of 
course.

Joerg

UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

 * *Messages sorted by:* [ date ]
   
   [ thread ]
   
   [ subject ]
   
   [ author ]
   





Although, with the 3 SPC slots - although they are on UNIBUS A, and only
UNIBUS B has the 18-bit capability


It is of course perfectly possible to run UNIBUS _A_ (where the SPC slots are)
in 18-bit mode too - although the _RH11_ can't use it that way. But you won't
be using the RH11 anyway, so who cares?

Also, I took another look at the KS10 tech manual, and they do in fact use use
an M9200 'thin' jumper (although it's mis-labelled "M9300" in the diagram -
that diagram has a number of errors, including the "M8014" in the UNIBUS 'A'
In slot - they must mean an M9014 [UNIBUS to 3 flat cables] instead) to link
the two UNIBI together. Which answers the question of how the KS10 CPU gained
access to UNIBUS A (where the device registers, interrupts, etc are) when it
also had to be connected to UNIBUS B (for 18-bit data transfers).

So I think all our questions are answerered (except for the -AB/-C difference
issue).

So I understand right:
UniBone can be used in UNIBUS-A SPC slots in 18 bit mode without any extra 
adapters?
And can emulate an RH11-C there, even if the RH11 is supposed to run in UNIBUS 
B?
Thats good news.

Two more things to check:
1. We've seen early SPC slots (PDP-11/40, '45) without NPG wired,
'cause SPC was apparently originally meant for "Small" peripherals without DMA.
Is KS10 UNIBUS-A wired to be DMA capable?

2. When doing 18bit on UNIBUS-A we put all kind of signal levels
on parity lines PA,PB = DATA<16:17>.
Won't the KS10 CPU interpret these as real BUS parity errors generated
by some UNIBUS-A device?

best regards
Joerg


 

UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

>> Well, I was expecting to have to do all of the work myself. There’s 
still the problem of the disk Unibus itself to solve

> -the disk UBA doesn’t terminate into a normal Unibus.
> It goes into the disk RH11 directly, and the bus is terminated on the 
far end of the RH11. I’d either have to buy another Unibus backplane to 
plug the Unibone into, or find a way to plug the cables from the UBA 
directly into the Unibone.

>This still leaves the issue of terminating the bus.
> The ideal scenario would be if the first slot of a RH11 (where the 
bus jumper comes in) can accommodate the (quad card)
> Unibone without issues, the rest of the RH11 boards can simply be 
pulled without breaking bus continuity,
> and the normal terminator in the far slot can be used. I haven’t 
looked at any prints or anything yet.
I gave UniBone a set of pinheaders for all UNIBUS signals in parallel to 
the gold fingers.
So an adapter board can be designed, which plugs onto the pinheaders, 
contains some provision for the UBA connection and contains the 
terminator array.
The UBA-UniBone adapter may consist of two parts coupled via flat cable, 
with flipchip plugs on one end if necessary.
All this is only mildly annoying, did similar before, for example 
http://www.retrocmp.com/tools/uniprobe


> Right, there were two unibus ports on a 2020: The first one went to the
> RH11-C and was very odd in that "Hog Mode DMA" was enabled to allow the
> device to just stream data as much as it wanted to the controller. This
> would mean that other devices on the bus would time out and not have
> their interrupts serviced, but since the RH11 was the only thing it
> didn't matter (and I think this is why you could use RM03's instead of
> RM02's: The whole track could be read and buffered to the 2020's UBA
> controller in one shot.
> That would have to be programmed into the BBB software to ignore the 
16 word

> DMA limits and go as fast as the drive can go).

As the disk drives are also emulated, they are not putting any 
constraints on the DMA logic: give them the speed and DMA length you prefer.


Joerg

UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

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

UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

*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.


Is it possible to get it as a "kit+" where the SMD components only are already 
soldered onto
the bare board, but all the rest left for those who are ok with a normal 
soldering iron but
not confident on doing the SMD?


Yes, can do that.
Joerg

UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

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 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

Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

Stefan,

*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!).


Ethernet or FC connection ??
If so it would be possible to build an PDP-11 who is datacenter-
compatible today year 2019 ...

One requirement for todays datacenter (for some owners at least) is the
ability to directly connect the system to the storage system (ie
FC/SCSI or IP/iSCSI.)

Hint: with that requirement as far as i know it an ARM device in the
form of a Samsung S9 can't be data center compatible

Mot clear to me what "data center compatibility" for a PDP-11 means.

Anyhow, the BeagleBone runs Debian Linux, has an Ethernet port and the 
emulation software is a plain Linux application.
So all emulator binaries and all PDP-11 disk images or other data can 
reside anwhere in the world and are not bound to the UniBone SDcard.


Joerg

UniBone: Linux-to-DEC-UNIBUS-bridge, year #1

[Jörg Hoppe via cctalk]

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

Re: Another DEC UNIBUS signal adapter: UniProbe

[Jörg Hoppe via cctalk]

Hi,



Did you happen to take a look at my UA11?  It’s different in that it goes into 
an SPC slot.
Yes, I was pointed to it after UniProbe was out. Good I saw it not 
earlier, would have killed my project ;-)


best regards,
Joerg



TTFN - Guy


On Feb 26, 2019, at 11:07 PM, Jörg Hoppe via cctech  
wrote:

Hi,

most people dealing seriously with older PDP-11s have found means to monitor 
the UNIBUS traffic.
My latest approach is www.retrocmp.com/tools/uniprobe
UniProbe is a M9302 terminator, a LED display, a probe for logic analyzer.
It can be mounted in Standard or Modified UNIBUS sockets.

I'm ordering a batch of PCBs in a few days and will show this and other stuff 
(UniBone, BlinkenBone) at VCFPNW in Seattle.
https://vcfed.org/wp/festivals/vintage-computer-festival-pacific-northwest/

best regards,
Joerg

Another DEC UNIBUS signal adapter: UniProbe

[Jörg Hoppe via cctalk]

Hi,

most people dealing seriously with older PDP-11s have found means to 
monitor the UNIBUS traffic.

My latest approach is www.retrocmp.com/tools/uniprobe
UniProbe is a M9302 terminator, a LED display, a probe for logic analyzer.
It can be mounted in Standard or Modified UNIBUS sockets.

I'm ordering a batch of PCBs in a few days and will show this and other 
stuff (UniBone, BlinkenBone) at VCFPNW in Seattle.

https://vcfed.org/wp/festivals/vintage-computer-festival-pacific-northwest/

best regards,
Joerg

Plug+Play for PDP-11/40 panels - BlinkenBone update

[Jörg Hoppe via cctalk]

Hi guys,

There is now a special 11/40 adapter board for the BlinkenBone system.
With that you can plug a physical 11/40 panel to the extended SimH 
running on a BeagleBone.


Surprisingly there was some demand for the 11/70 panel adapter, so 
adding the '40 panel may be worth mentioning.


There is no own '40 documentation, see again the 11/70:
http://www.retrocmp.com/projects/blinkenbone/physical-pdp-11-70-panels/288-pdp-11-70-console-panel-on-blinkenbone-plug-and-play-adapter
If you want it: I made the '40 €10 cheaper then the '70.

Entry to far-too-many web pages here: 
http://retrocmp.com/projects/blinkenbone


All in all there are now at least 6 different (but compatible) ways to 
get a blinking PDP-11's with SimH.


- Connect a real 11/40 or 11/70 panel.
http://retrocmp.com/projects/blinkenbone/physical-pdp-11-70-panels

- Run the virtual Java panels for 11/20, 11/40 or 11/70, also with play 
isntruction for the physical ones:

http://retrocmp.com/projects/blinkenbone/simulated-panels/253-blinkenbone-simulated-pdp-11-20-panel
http://retrocmp.com/projects/blinkenbone/simulated-panels/254-blinkenbone-pdp-11-20-running-papertape-basic
http://retrocmp.com/projects/blinkenbone/simulated-panels/252-blinkenbone-playing-with-the-pdp11-40
http://retrocmp.com/projects/blinkenbone/simulated-panels/247-blinkenbone-simulated-pdp11-40-panel
http://retrocmp.com/projects/blinkenbone/simulated-panels/243-blinkenbone-panelsim-pdp11-70
Download & run from github https://github.com/j-hoppe/BlinkenBone/releases

- get Oscars Vermeulens PiDP11
http://obsolescence.wixsite.com/obsolescence/pidp-11

I will be at VCFPNW in Seattle with that stuff.

kind regards,
Joerg

UniBone - access DEC PDP-11 UNIBUS under Linux

[Jörg Hoppe via cctalk]

Guys,

I'm about to finish another project:
"UniBone" - a Linux-to-UNIBUS bridge, based on the BeagleBone Black.

It is supposed to be a development platform for device emulation.
At the moment it can emulate memory, emulate an RL11 controller with 4 
RL drives attached, and act as UNIBUS hardware test adapter.


There are some web pages at http://retrocmp.com/projects/unibone
And I'll show it on VCFE.CH in Zurich on Nov 24/25,  plugged into a 
PDP-11/05.


Enjoy,
Joerg

Re: Photorealistic frontpanels for DEC PDP simulations under SimH

[Jörg Hoppe via cctalk]

Hi Rob,


See here
http://retrocmp.com/projects/blinkenbone/169-blinkenbone-architecture-overview
and adjactent pages.

I use photos of each button and each lamp, in every state.
So first operation is taking picture of a real panel.
Then I use Photoshop, to cut out all the lamps & switches into separate 
layers
- a photoshop script scales them to different screen reloutions, and 
names the resulting images with __
- Photoshop generates also a text file with coordinates of each control, 
so they can be painted at right position later.


I tried other approaches, but this has best quality. Even scaling the 
images at run time was not as perfect as scaling with Photoshop.


To get a clickable image of the panel I use a Java program.
It paints the current control states onto screen, and decodes 
mouse-click positions into activated switches.


I choose Java with the old AWT framework, because graphic is relatively 
easy there, and it is platform independent. The graphic should follow 
SimH onto as much different platforms as possible.


So I have a simulator written in C (SimH) and a Java display.

Both communicate over an network interface, written with RPC 
(https://de.wikipedia.org/wiki/Remote_Procedure_Call)

RPC is a 1990's technic, so very fast on today machines.

if you look at https://github.com/j-hoppe/BlinkenBone
you find the Java sources at
projects/09_javapanelsim,
and the image directories (example for the PDP-11/70) at
projects/09_javapanelsim/resources/blinkenbone/panelsim/panelsim1170/images

The extensions on SimH-side reside in
projects/02.3_simh/4.x+realcons/src/REALCONS/
and as small extensions in scp.c and the *_cpu.c sources of the 
simulated machines. Every change is marked with "#if USE_REALCONS",

so I know what to merge into new SimHs.

I do not use the "frontpanel" interface of SimH, as my project was ready 
before this was introduced.



I confess my approach is maximal over-engineered, but I want to be as 
good as possible, and I'm enhancing it since years.




best regards,
Joerg




Am 28.03.2018 um 14:19 schrieb Rob Jarratt:

Hello Joerg,

I am looking to do a graphical front panel simulation of a machine I am in the 
process of building an emulator for. I am not very good on the graphical side 
and would love to understand how this was done. Can you point me at the area of 
the code that does this simulation, and can you offer any tips? For instance do 
you use photos of each button/switch etc or do you draw them in code?

Thanks

Rob


-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Jörg Hoppe
via cctalk
Sent: 28 March 2018 12:06
To: General Discussion: On-Topic Posts <cct...@classiccmp.org>
Subject: Photorealistic frontpanels for DEC PDP simulations under SimH

Guys,

there are updates to the photorealistic PDP-8/10/11/15 panel simulations for
SimH, code name "BlinkenBone".

* Added bigger images for 3000 pixel width screens.

* made PDP-11/70 panel behaviour compatible with the real machine
(after tests performed at the PDP-11/70 "Miss Piggy" at LCM in Seattle,
thanks to Rich Alderson & Josh Dersch).
Oscar Vermeulen's upcoming PiDP1170 replica will also benefit.

* Added Mike Hill's BLINKY animation as PDP-11/70 application.

* Optically enhanced the PDP-10KI10 panel:
Added rack background of the real KI10 at LCM.

* Merged with SimH code base from march 2018

* Some people want to reanimate a physical panel with "BlinkenBone" too, or
did already.
http://retrocmp.com/projects/blinkenbone/setting-up-a-blinkenbone-project
Finally I can supply the hardware, a tested set of BeagleBone Black,
BlinkenCape and BlinkenBoard.
I can't get the price below 200€, there's this penalty for manual small 
batch
production (including some self-exploit).



Doc root page: http://www.retrocmp.com/projects/blinkenbone

Download: https://github.com/j-hoppe/BlinkenBone/releases
As usual, there are precompiled distributions for Win32, Ubuntu x86 & x64,
Raspberry Pi and Beaglebone.
Just unzip and start some of the shell scripts.




Enjoy,

Joerg

Photorealistic frontpanels for DEC PDP simulations under SimH

[Jörg Hoppe via cctalk]

Guys,

there are updates to the photorealistic PDP-8/10/11/15 panel simulations 
for SimH, code name "BlinkenBone".


* Added bigger images for 3000 pixel width screens.

* made PDP-11/70 panel behaviour compatible with the real machine
  (after tests performed at the PDP-11/70 "Miss Piggy" at LCM in Seattle,
  thanks to Rich Alderson & Josh Dersch).
  Oscar Vermeulen's upcoming PiDP1170 replica will also benefit.

* Added Mike Hill's BLINKY animation as PDP-11/70 application.

* Optically enhanced the PDP-10KI10 panel:
  Added rack background of the real KI10 at LCM.

* Merged with SimH code base from march 2018

* Some people want to reanimate a physical panel with "BlinkenBone" too, 
or did already.

http://retrocmp.com/projects/blinkenbone/setting-up-a-blinkenbone-project
  Finally I can supply the hardware, a tested set of BeagleBone Black, 
BlinkenCape and BlinkenBoard.
  I can't get the price below 200€, there's this penalty for manual 
small batch production (including some self-exploit).




Doc root page: http://www.retrocmp.com/projects/blinkenbone

Download: https://github.com/j-hoppe/BlinkenBone/releases
As usual, there are precompiled distributions for Win32, Ubuntu x86 & 
x64, Raspberry Pi and Beaglebone.

Just unzip and start some of the shell scripts.




Enjoy,

Joerg

set help

[Jörg Hoppe via cctalk]

DEC MINC in center Germany

[Jörg Hoppe via cctalk]

I like to point you to this DEC MINC-11:

http://www.ebay.de/itm/112435553232

Its a non-profit offer, we just need the space.

best,
Joerg

Re: RT-11 5.x install tapes?

[Jörg Hoppe via cctalk]

Alan,
thanks!

- I saw that neither 5.5 nor 5.6 has no DD, but 5.0 -5.4G and 5.7 has.
Didn't understand the reason.

- Also DD.MAC in the 5.0 - 5.4 and 5.7 changes often.
I tested tu58fs with oversized TU58 tape for 5.3 and 5.7, the number of 
blocks is always patched into into offset 0x2c, 0x2d in DD.SYS


- I made a working DD.SYS  with
 .macro DD,
 .link DD,
.rename DD.SAV DD.SYS

Do you know how to make DDX.SYS? Must be a conditional MACRO symbol.

Joerg




for work on TU58 emulator "tu58fs" I'd like to experiment with
oversized  tape images under RT-11 5.5, 5.6 and 5.7. The images I
know about are the classiccmp collections, Earl Evans  pointed me
to the RT11DV50.ISO archive.
However, in these images the TU58 driver files
DD.MAC/DD.SYS/DDX.SYS are  mostly missing. Strange, because they
claim to be pristine.
Somebody knows about original RT-11 V5 installation tape images?

Here is the DD.MAC file you are looking for.   It was part of
the RT-11 v5.6 sources that Mentec supplied to the Y2K update
team to make v5.7.   Since the last modification was in 1979,
it is safe to assume that it applies to all recent versions.

Have fun!

Alan

--
.MCALL  .MODULE
.MODULE DD,VERSION=21,COMMENT=,AUDIT=YES

;   COPYRIGHT (c) 1989 BY
;   DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS.
;ALL RIGHTS RESERVED
;
;THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
;ONLY  IN  ACCORDANCE  WITH  THE TERMS  OF  SUCH  LICENSE AND WITH THE
;INCLUSION OF THE ABOVE COPYRIGHT NOTICE.  THIS SOFTWARE OR  ANY OTHER
;COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
;OTHER PERSON.  NO TITLE TO AND OWNERSHIP OF  THE  SOFTWARE  IS HEREBY
;TRANSFERRED.
;
;THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE  WITHOUT NOTICE
;AND  SHOULD  NOT  BE  CONSTRUED AS  A COMMITMENT BY DIGITAL EQUIPMENT
;CORPORATION.
;
;DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR  RELIABILITY  OF ITS
;SOFTWARE ON EQUIPMENT THAT IS NOT SUPPLIED BY DIGITAL.

.SBTTL  CONDITIONAL ASSEMBLY SUMMARY
;+
;COND
;   DD$PRI  (4) Interrupt Priority
;   4-7 possible interrupt priorities
;
;   DDT$O   (0) two controller support
;0  1 controller
;1  2 controllers
;
;   DD$CSR  (176500)1st controller CSR
;   DD$VEC  (300)   1st controller VECTOR
;
;   DD$CS2  (176510)2nd controller CSR
;   DD$VC2  (310)   2nd controller VECTOR
;
;   EIS$I   (MMG$T) Use SOB instruction (no code effects!)
;   0   simulate SOB
;   1   use SOB
;
;   MMG$T   std conditional
;   TIM$IT  std conditional (no code effects)
;   ERL$G   std conditional
;-

.SBTTL  GENERAL COMMENTS

.ENABL  LC

;+
; ABSTRACT FOR CODE FROM WHICH THIS WAS TAKEN:
;
; THIS MODULE MAY BE ASSEMBLED TO YIELD EITHER THE RAM PORTION OF A PDT
; DRIVER WITH PRIMITIVES IN ROM OR A MODULE TO BE LINKED WITH ANOTHER
; MODULE TO MAKE AN RT11 DRIVER FROM THE ROM PRIMITIVES.
;
; AUTHOR:
;
;   BILL CLOGHERVERSION 1
;   DARRELL DUFFY   VERSION 2 27-APR-78
;
; MODIFIED BY:
;   BARBARA DOERRE
;   23-AUG-78   SINGLE MODULE RT11 DRIVER
;   DENISE LANGLAIS
;   29-JUN-79   REMOVE 'DEVICE DRIVER LIST' (R5) AND IMPURE AREA (R4)
;   1-AUG-79ADD DUAL CONTROLLER CODE AND SET OPTIONS
;-

.SBTTL  MACROS AND DEFINITIONS

.MCALL  .DRDEF, .MTPS,  .ASSUME .ADDR

; DD IS CONTROLLED VIA A SERIAL LINE OF DL TYPE
; CONTROL REGISTERS ARE THEREFORE A DL

.IIF NDF DD$PRI DD$PRI  = 4 ;STANDARD PRIORITY FOR DL

.IIF NDF DDT$O  DDT$O   = 0 ;DEFAULT TO SINGLE CONTROLLER

.IIF NDF DD$CS2 DD$CS2  = 176510 ;DEFAULT CSR FOR SECOND CONTROLLER
.IIF NDF DD$VC2 DD$VC2  = 310   ;DEFAULT VECTOR

.DRDEF  DD,34,FILST$,512.,176500,300
.IIF EQ MMG$T   .DRPTR
.IIF NE MMG$T   .DRPTR  FETCH=*NO*
.DREST  CLASS=DVC.DK

.IIF NDF EIS$I  EIS$I = MMG$T
.IIF EQ EIS$I   .MCALL  SOB ; USE SOB INSTRUCTION UNDER XM

;THE FOLLOWING LIST OF SYMBOLICS WERE DELETED SINCE ACCESS TO THE CSR'S
;IS THROUGH A LIST OF THEIR ADDRESSES (@TICSRA AS OPPOSED TO @#TI$CSR)
;TI$CSR =: DD$CSR   ;INPUT CONTROL AND STATUS
;TI$BFR =: TI$CSR+2 ;INPUT BUFFER
;TO$CSR =: TI$CSR+4 ;OUTPUT CONTROL
;TO$BFR =: TI$CSR+6 ;OUTPUT BUFFER
;TI$VEC =: DD$VEC   ;INPUT VECTOR
;TO$VEC =: TI$VEC+4 ;OUTPUT VECTOR

CS$INT  =: 100  ;CONTROL INTERRUPT ENABLE
CS$BRK  =: 1;CONTROL BREAK ENABLE

; ERROR LOG VALUES

DDCNT   =: 8.   ;RETRY COUNT
DDNREG  =: 10.  ;COUNT OF REGISTERS REPORT TO EL

; RADIAL SERIAL 

RT-11 5.x install tapes?

[Jörg Hoppe via cctalk]

Hi all,

for work on TU58 emulator "tu58fs" I'd like to experiment with oversized 
tape images under RT-11 5.5, 5.6 and 5.7.
The images I know about are the classiccmp collections, Earl Evans 
pointed me to the RT11DV50.ISO archive.


However, in these images the TU58 driver files DD.MAC/DD.SYS/DDX.SYS are 
mostly missing.

Strange, because they claim to be pristine.

Somebody knows about original RT-11 V5 installation tape images?

Thanks,
Joerg