Hi all,
Around 1981, Intel made a 8086 companion chip named _operating system
processor_ (i80130, and i80150, resp.) which comprised a ROM and some
interrupt logic. The 80130 contained sort of a BIOS for iRMX86, the
80150 supported CP/M-86. Few info can be found at
https://en.wikipedia.org/wiki/Intel_80130, and a datasheet exists at
alldatasheet.com.
Some lore is also found in some history pages, but not much more than
the datasheet contains.
Was the ROM content of both chips dumped and is available on the
Internet somewhere, or does someone have such a system (supposedly some
iAPX86/30) and is willing to make this public, e.g. upload to bitsavers?
THX to any pointers
Kind Regards
Holger
I've been reinventing the wheel quite a bit lately and a couple of new
things as well, so I'm glad I was not well-versed in the issues
surrounding this machine in the BSD sphere and elsewhere.
Some new ideas to help those with this machine:
cycle a known-good elsa or permedia with rom disabled through each slot
of an empty card-cage. On each swap, unplug the machine from the wall
and leave the power switch on for a minute or two, then issue an init
at srm. When you run out of slots:
This should pattern the entire bus with a calm elsa stamp.
There are three digital levels to this coherence problem (at least),
and there's the analog one no one seems to have considered as a member
of the whole picture.
I searched for this above and it was no where. I don't think anyone
thought of it.
The system trains. I saw it do this recently with the si3114udc card.
As the card drifts, the system drifts with it, in sympathy. This drift
can become ingrained in the system beyond the digital realm.
I think it is totally worthwhile to consider making a card for this
purpose using a cheap cpld or mcu. There are already pci projects out
there, it could be a snap. I'll look into it, but what it could DO is
repeatedly and visciously assert aligned and properly timed data in the
same way the 3114 and other misbehaved cards assert mis-skewed data and
timing. This, in theory would re-train the entire io subsystem to
compliance with the cards whole and healthy stride, normalizing the
machine for expansion and deployment.
I could really use some feedback. This list has the best there is.
Weaponizing init and prefetch and a crash, exploiting the system is
good, because it can work, but it isn't the whole fix, just a peek at
the mechanisms which can unlock the problem entirely.
So today I added an analog or dumb aspect to what has been seen as a
monolithic problem. It really is a DUAL problem insofar as BSD is
concerned, but for Alpha architecture it is a four-layered problem, as
I see it.
I lack the targam at this depth, so please forgive my terms:
PCI cage physical state (why is this such a stepchild in the process?
And red-headed!)
PCHIP executing saved bitsieve which was generated by init probe before
prefetch is re-asserted (one-boot process).
PCI to EV6 bridge, logic and code the training is here, I believe, and
incredibly active and intrusive. The SRM is a computer inside the
computer.
EV6 bus and its side of the divide.
The way I see it is shooting through three sets of overlapping chain-
link fences. If you are sqare to them and a good shot, you will put
your shot through the same hole of the 'grid' and it will land in the
appropriate target zone. If you are at an angle, you will land your
shot, but it will be dislocated from your planned landing spot. The
system is really tolerant to this!, it trains itself..... If I keep
hitting the fences, the fences move to accommodate my shot, as though
the strikes were physically enough to do that.
I think the dec hardware guys wanted to puke when they were told to
hang pci off ev6 AND as the only available bus. They hated it with
their whole souls. So, the implemented the most rigorous and perfect
implementation of the 'standard' they could. It was so good and so
rigorous the software guys had to eat the puke they'd made the hardware
guys egest. We are dealing with the aftermath of that battle, is my
take. I'm just looking at the machine.
So if it can fail for bad training, why not try GOOD training?
Some of you may remember me. I've been here since 1997 or so?
I have no formal education at all. I have 40 years of computing
experience and have gotten this far in the project through logic and
theory and the output of the framebuffer in various failure modes.
One, for example would just look corrupted to a LOT of people, but it
looks like a loader for a demo on an 80's 8-bit decompressing its
payload. That is informative. I realized that the framebuffer had
overflown into main memory and I was seeing the contents of that in
this familiar way. That is science, even if it is using in-situ
diagnostic tools. Using this as a primary window into the system I've
built the theory as expressed here. A smarter person would use
expensive tools I don't have, and those have been applied already I'm
sure.
I'ts been awhile is all. I've been lurking.
Please holler!
Best,
Technoid Mutant
Jeffrey S. Worley
Greetings,
Over the past several months I've been privileged to experience RSRE Flex,
an operating environment for PERQ workstations (and a few other bespoke
machines before that). Flex is interesting for being a networked
capability-based system with a hypertext-ish user interface, and everything
is implemented in Algol 68. Closures (in the programming language sense;
called "procedures" in Flex) are a fundamental abstraction similar in
importance to how files are fundamental to Unix*.*
Flex was developed in the late '70s and the '80s by the Royal Signals and
Radar Establishment, a research lab of the UK Ministry of Defence. Its
influence on computing has been limited as far as I can tell: the same
researchers went on to develop the Ten15 abstract machine which begat the
TenDRA compiler, and that might be most of the story. Nevertheless, the
system remains fascinating (I think) if you get the chance to learn about
it. I've collected some Flex materials here: https://mg-1.uk/flex/flex.html
In a few weeks I'll be giving a talk and demonstration of Flex to a
technically well-informed but otherwise unfamiliar audience. I can
certainly fill the time with rich technical details and descriptions of
things like Algol 68 and the PERQ, but I'd like also to have more to say
about the circumstances that brought Flex about and the ways people
encountered it at the time. I'm also hoping to gather information that
might lead to a public release of Flex someday (another thing I've been
working on behind the scenes).
So this message is a general request for information and connections:
- Did you or did someone you know work in computing at RSRE in the '70s and
'80s?
- Flex was shared with people outside of RSRE in the '80s, mainly
universities and colleges from what I can tell. Did you encounter Flex
running on a PERQ in one of these settings?
- Did you ever use Flex under any circumstances? What for?
Also:
- Flex contains numerical routines in both Algol 68 and PERQ microcode that
bear copyright assertions by Numerical Algorithms Group Ltd (now nAG,
nag.com). Does anyone know someone at nAG who would be a sympathetic person
to approach about the disposition of this very old IP?
Many thanks, --T
As a matter of fact, I had already sent Scott an email, but did not get a reply.
> Date: Fri, 26 Jun 2026 08:57:24 -0400
> From: Ken Seefried <seefriek(a)gmail.com <mailto:seefriek@gmail.com>>
> Subject: [cctalk] Re: Looking for a paper in COMPCON '83
>
> You might reach out to the authors. I'm pretty sure S.B. Baden is Scott
> Baden @ UCSD.
>
> https://cseweb.ucsd.edu/~baden/
>
> KJ
I’m trying to get a copy of this paper:
S. B. Baden and D. R. Patel. “Berkeley FP — Experiences with a Functional Programming Language.
Conference Record of COMPCON ’83, San Francisco, California, pp. 274–277, March 1983.
and wonder if anyone on this list has a copy of the proceedings?
The source code is available in the tuhs.org archives and the manual is available in the supplementary documentation for BSD 4.2, but I am interested in what the author wrote about their experiences. (I’m working on a history of John Backus’s functional programming project; Berkeley FP is based on Backus’s work.)
Paul McJones
This is irregular, and I beg your indulgence, as it at least in light
of the recent Alpha EV6 discovery.
I have a story to tell you Mr. Stone, that you will be very glad,
amazed and fulfilled to hear and to know.
This is not the forum for such things, but I am a very little person
and could not hope to reach you in any other way.
Thank you gentlemen for your forbearance. I ask further of you even,
if you know Harold S. Stone, the author of High-Performance Computer
Architecture, please ask him to message me on facebook or call me. I'm
not hard to find, I'm @Technoid_Mutant on Youtube...
Again, my thanks.
Jeff
We've been working on restoring and powering up a fairly rare bird of IBM Midrange machine, the IBM System/38.
We had some good success this past weekend that I'd like to share.
https://crusty.computer/?p=89
June Work Recap: Edith – The Crusty Computer Club
crusty.computer
tl;dr: she powered up and no smoke came out and no sparks came out! There are several repairs needed but they are known and fixable.
Intel's x86 technology as in the 8086 came into existence for the
microcomputer-user at this time back in June 1978. It was a response to
Motorola's and Zilog's move to 16-bit processing. Still in use today...the
basic tech so to speak. Can it be unseated by RISC(Apple and such) and
Nvidia?
Happy computing.
Murray 🙂
