Warner asks: "Why was microcode support required to make APL work? What did it enable that couldn't be done in other ways?" [On an HP 3000 Series III, for example] Back in the mid-1970s, on the HP 3000 Series III, the team implementing APL\3000 apparently decided they would need to implement some form of virtual memory (beyond the multiple 64KB spaces the HP 3000 Classic architecture provided). They chose to add 11 new instructions: LDV, STV, MWFV, MWTV, MBFV, MBTV, LDVB, STVB, MVW, and EGOTO (unnamed by HP), LDWX (unnamed by HP) The first 9 are "virtual memory" related instructions. The last two are not. These instructions were added shortly after the original Series III instruction set had previously been expanded by the addition of the new extended COBOL instructions. (So, the Series III had two sets of firmware expansions.) Subsequent HP 3000 models had the COBOL instructions from day 1. I presume that the APL instructions weren't ready when the Series 30/33 design was locked down. I *think* they might have been available later as an add-on. I know that a few years later, the instructions were ported to the Series 40/44 microcode by Leon Leong, but they were never released for it (APL\3000 was in limbo, about to be cancelled at the time.) But, to answer your question, yes...there are other ways. Gavin Scott managed to patch the unimplemented instruction handler in MPE V/R (the release the SIMH HP3000 simulator is running), and got APL\3000 running. In the meantime, I'm slowing trying to add the instructions to the SIMH code. The nice thing about Gavin's approach is that if I get an instruction implemented, his code *for that instruction* simply never gets called ... so we can coexist peacefully. In theory, implementing the APL instructions in SIMH will lead to better performance (because calling one won't cause a missing instruction interrupt, followed by hundreds or thousands of simulated HP 3000 instructions to emulate the instruction). I believe Gavin is preparing a talk about APL\3000 for an APL Users Group. Another alternative would have been for the APL\3000 people to implement references to their virtual memory via "cover functions". However, I suspect that the grasp of SPL programming, the lack of "macros" with parameters in SPL, and concerns about the performance penalty of a procedure call per memory access all would have conspired to argue against this approach. (Having been reading thousands of lines of SPL written in the 1970s, I conclude that perhaps a handful of people at HP understood how to write readable, maintainable SPL code ... and that's probably the same percentage as SPL programmers outside HP :) Stan