Hi Mark (& all),

Just wanted to know how you're doing with that conversion of the Javascript Burroughs B5500 emulator that you said you were looking at...

Wonder if you have interesting stories about performance to tell us ;)

Regards,
Reinier

Noting obviously that I'm not the prime mover of this, and that I'm mainly transcribing code from Javascript to Pascal to run on unix.

As background: the B5x00 was an early-60s design using transistors and diodes rather than valves, assembled as modules and plugged into a wire-wrapped backplane (which, incidentally, is why I was digging for info on the Lawrence Livermore S-1 computer a couple of weeks ago, hence the Stallman comment I posted elsewhere). The B5000 was drum based, the B5500 used discs (/big/ discs), and the B5700 could cluster up to 4x systems around shared disc. Later machines had 2x CPUs, with one mainly handling the operating system and the other devoted to user code. These three machines were not code-compatible with the later B6xxx or B7xxx range, or with the B5900.

The operating system was written in an ALGOL derivative, with fairly heavy use of embedded assembler. The frequently-repeated statement that these machines were programmed entirely in ALGOL and that there was no assembler is a simplification. Dijkstra liked them, Knuth and Wirth used them on occasion; Gary Kildall was involved in writing an APL interpreter at IIRC Washington.

I'm starting off with a command-line driven variant, i.e. there's no GUI and controls are simulated by typed-in commands using a parser I wrote for something else. I've transcribed the CPU, central control and IOPs, and am currently working on I/O devices starting off with the SPO (Supervisory Printer Output) and card readers/punch. Importantly, as I go I'm adding a fairly extensive set of test/debug commands.

I'm hoping to later put together a GUI using Lazarus, and to allow symbolic debugging of the operating system etc. by transferring compiler output listings from the emulated environment to the host. But I'm a long way from that stage.

I've got to the point where I can enter a 48-bit I/O descriptor at which point the first free IOP's thread spins once to e.g. read a card into memory. I'm currently tidying up the code but at this time of year I've got a lot of other demands on my time which are causing problems.

I'm not sure whether to tackle more I/O devices next (tape or disc), or to start debugging the CPUs mow that I can read a loader deck into memory.

I'm hoping to be able eventually to get a cluster running, i.e. 4x twin-CPU systems sharing common disc. Good old mid-60s technology ;-)

I'm also hoping to be able to support e.g. non-standard tape formats by loading shared libraries, rather than hardcoding them. There's a number of projects that emulate mainframes from the 7-track tape era, but like the original systems they're very poor at reading each others media.

In the longer term, it would be nice to get a Pascal compiler running (there's a listing on Bitsavers). However that would probably need a lot of typing, which takes me back to a large-scale collaborative project that's something else I'm trying to work on. And which is, as they say, yet another story.

Mark Morgan Lloyd wrote

Reinier Olislagers wrote:

<snip>

Interesting - sounds like a huge job you're tackling there & thanks a lot!

I keep wanting to give the javascript emulator a go but each time manage to tell myself that I already have more than enough projects that I can work on rather than messing with an entirely new (ehm for me) environment ;)

I'm hoping to be able to make it a bit more friendly. I've got a terminal I wrote to drive an APL interpreter, which I've extended to support emulated card readers etc.

One of the interesting things from the POV of a Pascal user is the extent to which, when submitting a job via a card reader, control cards to specify things like attached files and supplementary chunks of source are interleaved.

I'd add that the 5x00 series predated EBCDIC, they use a 6-bit code for characters which adds to the challenge when e.g. drag-and-dropping a file to the reader. Later machines had both EBCDIC and two, incompatible, 6-bit codes... the IBM emulation people don't know how lucky they are :-)

I'd also add that in most cases the customary base is octal, and I'm using the Smalltalk-style radix indicator at the command line, i.e. 8r20 is 16 decimal.