diff --git a/_posts/2016-08-19-connecting-an-ibm-pc-to-a-dec-vt100-terminal.md b/_posts/2016-08-19-connecting-an-ibm-pc-to-a-dec-vt100-terminal.md index a804fdf7f..8d1f7c7e2 100644 --- a/_posts/2016-08-19-connecting-an-ibm-pc-to-a-dec-vt100-terminal.md +++ b/_posts/2016-08-19-connecting-an-ibm-pc-to-a-dec-vt100-terminal.md @@ -64,10 +64,10 @@ was add the following Front Matter to the top of the Markdown file: and then embed the machines in the post, each with a single line: - {% raw %} +{% raw %} {% include machine.html id="ibm5170" %} {% include machine.html id="vt100" %} - {% endraw %} +{% endraw %} For people rolling their own web pages, [the basics](/docs/pcx86/) haven't changed, and adding a serial connection merely requires adding a *connection* property (eg, `connection:"com2->vt100.serialPort"`) to the *parms* parameter passed to the diff --git a/_posts/2016-10-06-introducing-pdpjs-a-pdp-11-emulator.md b/_posts/2016-10-06-introducing-pdpjs-a-pdp-11-emulator.md index 7581e1506..9ae85d022 100644 --- a/_posts/2016-10-06-introducing-pdpjs-a-pdp-11-emulator.md +++ b/_posts/2016-10-06-introducing-pdpjs-a-pdp-11-emulator.md @@ -24,9 +24,9 @@ beginning of the PDP-11 line: the PDP-11/20. I'm starting with the top-of-the-line PDP-11/70 largely because the core of the emulator is being adapted from the JavaScript [PDP-11/70 Emulator (v1.3)](http://skn.noip.me/pdp11/pdp11.html) written by Paul Nankervis, who has generously given permission to use his code in PCjs. Since his emulator is a fully functional -11/70, it made sense to start there and work backwards, factoring out features as needed. +11/70, it made sense to start there and work backwards, disabling features according to the model. -The code has already undergone a lot of refactoring. Opcodes are now decoded by function tables rather than a single +The code has already undergone a lot of refactoring. Opcodes are now decoded by function tables rather than a single switch statement, and every opcode is implemented with a discrete function. Other refactoring includes flag management, interrupt management, and device management. @@ -37,9 +37,9 @@ component, [device.js](/modules/pdp11/lib/device.js), which has now been convert The first new device component is [serial.js](/modules/pdp11/lib/serial.js), which is currently the only means PDPjs has of communicating with the outside world. So you can try -[PDPjs connected to a VT100 Terminal](/devices/pdp11/machine/1170/vt100/), by clicking the **Run** button on the test machine. -The test machine is running [custom boot code](/apps/pdp11/boot/test/), adapted from boot code written by Paul, but due to the -lack of other device support, nothing can be booted yet. +[PDPjs connected to a VT100 Terminal](/devices/pdp11/machine/1170/vt100/), by clicking the **Run** button on the +test machine. The test machine is running a custom [Boot Monitor](/apps/pdp11/boot/monitor/) included with +[Paul's emulator](http://skn.noip.me/pdp11/), but due to the lack of other device support, nothing can be booted yet. Obviously PDPjs is very much a work-in-progress. Before I proceed much farther, I really want to put the CPU through some rigorous testing, so I'll be on the lookout for some comprehensive PDP-11 instruction tests. Or I'll write my own, diff --git a/_posts/2017-01-03-pdp-11-tutorials.md b/_posts/2017-01-03-pdp-11-tutorials.md index b33803e06..b2a5097e5 100644 --- a/_posts/2017-01-03-pdp-11-tutorials.md +++ b/_posts/2017-01-03-pdp-11-tutorials.md @@ -16,39 +16,44 @@ machines: sticky: top --- -Introducing PDP-11 tutorials! +Introducing PDP-11 tutorials. For more information, keep scrolling. {% include machine.html id="vt100" %} -[PDPjs](/devices/pdp11/machine/) is the newest addition to the PCjs family of emulators, joining PCx86, PC8080, and C1Pjs. +[PDPjs](/devices/pdp11/machine/) is able to run a variety of old DEC operating systems, such as RT-11 and RSTS/E, +and while there are manuals available online, thanks to the efforts of those who operate and contribute to websites +like [bitsavers.org](http://bitsavers.org), I suspect most people don't have a lot of interest or time to spend +reading old manuals. -While PDPjs may eventually support a range of DEC PDP machines, my current focus is on the PDP-11, starting with the -PDP-11/70. From there, I'll work backwards to support other PDP-11 models, such as the PDP-11/45, until I reach the -beginning of the PDP-11 line: the PDP-11/20. +In an effort to remedy that situation, I'm adding some new features to PCjs. The first feature is what I call +"Sticky Machines", and it's more a website feature than a machine feature. At the top of any PCjs webpage, in the +*machines* section, a machine can now have a *sticky* property. For now, the only supported value is "top"; e.g.: -I'm starting with the top-of-the-line PDP-11/70 largely because the core of the emulator is being adapted from the -JavaScript [PDP-11/70 Emulator (v1.3)](http://skn.noip.me/pdp11/pdp11.html) written by -Paul Nankervis, who has generously given permission to use his code in PCjs. Since his emulator is a fully functional -11/70, it made sense to start there and work backwards, factoring out features as needed. + machines: + - id: vt100 + type: pc8080 + config: /devices/pc8080/machine/vt100/machine.xml + connection: serialPort->test1170.dl11 + sticky: top -The code has already undergone a lot of refactoring. Opcodes are now decoded by function tables rather than a single -switch statement, and every opcode is implemented with a discrete function. Other refactoring includes flag management, -interrupt management, and device management. +A sticky machine makes it easier to construct a tutorial page for a single machine, by preventing that machine from +scrolling off the top of the page; it "sticks" to the top instead. The rest of the page scrolls normally, allowing the +user to progress at their own pace through the text and/or images of an accompanying tutorial. -Most of the work remaining is in device management. Like other PCjs emulators, PDPjs has a Bus component, -[bus.js](/modules/pdp11/lib/bus.js), that allows separate device components to register I/O handlers for specific -UNIBUS addresses. During the initial port, I moved all of Paul's original device management code into one "catch-all" -component, [device.js](/modules/pdp11/lib/device.js), which has now been converted to the new I/O registration model. +The second feature is a generalized method for sending commands to components within a machine. For example, if we +want to send some keyboard commands to machine: -The first new device component is [serial.js](/modules/pdp11/lib/serial.js), which is currently the -only means PDPjs has of communicating with the outside world. So you can try -[PDPjs connected to a VT100 Terminal](/devices/pdp11/machine/1170/vt100/), by clicking the **Run** button on the test machine. -The test machine is running [custom boot code](/apps/pdp11/boot/test/), adapted from boot code written by Paul, but due to the -lack of other device support, nothing can be booted yet. +{% raw %} + {% include machine-command.html type='button' label='Try It!' machine='vt100' component='Keyboard' command='sendString' value='Hello World' %} +{% endraw %} -Obviously PDPjs is very much a work-in-progress. Before I proceed much farther, I really want to put the CPU through -some rigorous testing, so I'll be on the lookout for some comprehensive PDP-11 instruction tests. Or I'll write my own, -and compare results across 1 or 2 other PDP-11 emulators. +which should translate into a control that looks like: + + + +In fact, let's try it now. {% include machine-command.html type='button' label='Try It!' machine='vt100' component='Keyboard' command='sendString' value='Hello World' %} + +Obviously, every component we want to control will need to be updated to export the necessary functions. {% include machine.html id="test1170" %} diff --git a/modules/markout/lib/markout.js b/modules/markout/lib/markout.js index 027cbeced..998e9c794 100644 --- a/modules/markout/lib/markout.js +++ b/modules/markout/lib/markout.js @@ -942,10 +942,12 @@ MarkOut.prototype.convertMDLinks = function(sBlock) * Before we start replacing Markdown links, see if there are any Liquid-style replacements * (in case this Markdown file is part of a Jekyll installation) and remove them. * - * TODO: These replacements should use appropriate values from _config.yml; however, unless/until - * we start using Node again to host the public site, that's low priority. + * TODO: Any double-brace replacements should use appropriate values from _config.yml or the + * page's Front Matter; however, unless/until we start using Node again to host the public site, + * that's low priority. */ - sBlock = sBlock.replace(/\{([\{%]).*?\1}/g, ""); + sBlock = sBlock.replace(/([^\t])\{([\{%]).*?\2}/g, "$1"); + sBlock = sBlock.replace(/(\{)([\{%])(.*?\2})/g, "
$1$2$3
"); var aMatch; var re = /\[([^\[\]]*)]\((.*?)(?:\s*"(.*?)"\)|\))/g; @@ -1150,21 +1152,21 @@ MarkOut.prototype.convertMDImageLinks = function(sBlock, sIndent) */ MarkOut.prototype.convertMDMachineLinks = function(sBlock) { - var aMatch, sReplacement; + var aMatch, sReplacement, machine; var sMachineType, sMachineID, sMachineXMLFile, sMachineXSLFile, sMachineVersion, sMachineOptions, sMachineParms; /* * Before we start looking for Markdown-style machine links, see if there are any Liquid-style machines, * (in case this Markdown file is part of a Jekyll installation) and convert them to Markdown-style links. */ - - var reIncludes = /\{%\s*include\s+machine\.html\s+id=(["'])(.*?)\1\s*%}/g; + var reIncludes = /(.){%\s*include\s+machine\.html\s+id=(["'])(.*?)\2\s*%}/g; while ((aMatch = reIncludes.exec(sBlock))) { + if (aMatch[1] == '\t') continue; sReplacement = ""; - sMachineID = aMatch[2]; + sMachineID = aMatch[3]; if (this.aMachineDefs[sMachineID]) { - var machine = this.aMachineDefs[sMachineID]; + machine = this.aMachineDefs[sMachineID]; sMachineType = machine['type'] || "PCx86"; sMachineOptions = ((sMachineType.indexOf("-dbg") > 0 || machine['debugger'] == "true")? "debugger" : ""); if (machine['sticky']) sMachineOptions += (sMachineOptions? "," : "") + "sticky"; @@ -1176,11 +1178,14 @@ MarkOut.prototype.convertMDMachineLinks = function(sBlock) sReplacement = machine['name'] || "Embedded PC"; sReplacement = "[" + sReplacement + "](" + sMachineXMLFile + ' "' + sMachineType + '!' + sMachineID + '!' + sMachineXSLFile + '!!' + sMachineOptions + '!' + sMachineParms + '")'; } - sBlock = sBlock.replace(aMatch[0], sReplacement); + sBlock = sBlock.replace(aMatch[0].substr(1), sReplacement); reIncludes.lastIndex = 0; // reset lastIndex, since we just modified the string that reIncludes is iterating over } - sBlock = sBlock.replace(/\{%\s*include\s+build\.html\s+id=(["'])(.*?)\1\s*%}/g, '
'); + /* + * Ditto for any Liquid-style machine build links. + */ + sBlock = sBlock.replace(/\{%\s*include\s+machine-build\.html\s+id=(["'])(.*?)\1\s*%}/g, '
'); /* * Start looking for Markdown-style machine links now... @@ -1254,6 +1259,43 @@ MarkOut.prototype.convertMDMachineLinks = function(sBlock) ); } + /* + * Last but not least, see if there are any Liquid-style machine command links that need to be converted. + */ + reIncludes = /([ \t]*)\{%\s*include\s+machine-command\.html\s+(.*?)\s*%}/g; + + var findParm = function(aParms, sParm) { + sParm += '='; + for (var i = 0; i < aParms.length; i++) { + if (aParms[i].indexOf(sParm) == 0) { + return aParms[i].slice(sParm.length+1, -1); + } + } + return ""; + }; + + while ((aMatch = reIncludes.exec(sBlock))) { + if (aMatch[1] == '\t') continue; + var aParms = aMatch[2].match(/[a-z]+=(["']).*?\1/g); + if (!aParms) continue; + sReplacement = ""; + sMachineID = findParm(aParms, 'machine'); + var sControl = findParm(aParms, 'type') || 'button'; + var sControlType = sControl == 'button'? ' type="button"' : ''; + if (this.aMachineDefs[sMachineID]) { + sReplacement = '<' + sControl + sControlType + ' onclick="commandMachine('; + sReplacement += "'" + sMachineID + "',"; + sReplacement += "'" + findParm(aParms, 'component') + "',"; + sReplacement += "'" + findParm(aParms, 'command') + "',"; + sReplacement += "'" + findParm(aParms, 'value') + "')"; + sReplacement += '">' + (findParm(aParms, 'label') || 'Try It!') + ''; + } else { + sReplacement = ""; + } + sBlock = sBlock.replace(aMatch[0], sReplacement); + reIncludes.lastIndex = 0; // reset lastIndex, since we just modified the string that reIncludes is iterating over + } + if (cMatches) { sBlock = sBlock.replace(/^

([\s\S]*)<\/p>$/g, "$1"); } diff --git a/modules/shared/lib/sticky.js b/modules/shared/lib/sticky.js index 2b5c39ecb..270523448 100644 --- a/modules/shared/lib/sticky.js +++ b/modules/shared/lib/sticky.js @@ -29,7 +29,7 @@ "use strict"; /** - * addStickYMachine(idMachine) + * addStickyMachine(idMachine) * * @param {string} idMachine */ @@ -41,7 +41,10 @@ function addStickyMachine(idMachine) /* * TODO: Determine if/when we can cache the machine and machineSibling elements; we already * know we can't cache them when addStickyMachine() is first called, because that currently - * happens *before* embed.js replaces the placeholder machine DIV with the *real* machine DIV. + * happens before embed.js replaces the placeholder machine

with the real machine
. + * + * Placement of the addStickyMachine() call is irrelevant, because embed.js asynchronously + * reads all the XML files that define the machine *before* replacing the
. */ var machine = document.getElementById(idMachine); if (machine) { @@ -70,6 +73,19 @@ function addStickyMachine(idMachine) }; } +/** + * commandMachine(idMachine, typeComponent, sCommand, sValue) + * + * @param {string} idMachine + * @param {string} typeComponent + * @param {string} sCommand + * @param {string} [sValue] + */ +function commandMachine(idMachine, typeComponent, sCommand, sValue) +{ + +} + /** * findTop(obj) *