Small update here:
Still working on the tools for the next DPS stages. The Assembler will be closer to the System/370 Assembler version, since this contains a few assembler features that the HAL/S FC Compiler specification uses.
The PC (program controlled I/O) instruction seems to be a bit more powerful than I initially thought, containing many capabilities that also the MDM command interface has (eg Set/reset discrete). Still it seems possible to use the same SI/RS instruction format for it, as the normal System/360 channel I/O instructions have (that are now partially part of the MSC instruction set), which means we do know in which block of 64 opcodes the PC instruction must lay (and there is not that much room, I would say either 0x9B or 0xA0 are the most likely candidates, that is still in the block of the S/360 I/O instructions, but the instruction also makes use of a different logic, so it could also be anywhere else in this block). My current understanding is, that the instruction uses the following format:
With R1 being a 32 bit GPR register, OP a 4 bit operation code and HR a 16 bit hardware register location. (Modified RS-Format). Having the proper AP-101S assembler handbook would be the final truth there, but I don't feel like I will see it in my lifetime.
The AP-101 does not know any channel I/O features as the System/360 (and its successors until today) do, no channel command words, no channel status words. The IOP does a similar function, but operates in a different way, the Channel command words are there finding their equivalent in the BCE programs that are stored in BCE PROM memory.
For making things a bit easier for the HAL/S compiler development, I think about making the assembler a number of classes in the libUltra, that can be embedded in another applications. So, instead of the need to write assembler source files from HAL/S sources, the HAL/S compiler could produce directly object code files. The same could be done with the MDM assembler language and the related BCE assembler language tool (All would use the same front-end for parsing the assembler lines, but a different back-end for producing the output). Standalone command line applications will still exist for them of course. Also a disassembler should exist for every back-end, for debugging purposes.
Another tool that is needed then,would be something to work with tape images. Every tape is made of 512 half-word (16-bits) blocks, that are read and written block-wise. We need at least a way to compile multiple input files of any type into a single tape image. This way, we can for example merge the system and application software, that doesn't change that often, with the I-Load data, that is changed for every mission.
(Since every tape image is 30 MB large, I think we should be able to do some data reduction. Maybe have a read-only tape image for both MMUs and a diff data file that contains only changed blocks for simulation purposes)
My short term goal is having assembler, disassembler and AP-101S emulation run properly with only a small number of bugs left, the mid-term goal is then using this foundation for implementing all software specified in Part 1 of the ALT software specifications as "Revision 0" of a homegrown flight software. This means the whole FCOS operating system of PASS + the IOP software. That is then also the whole part needed to compile and execute HAL/S programs - essentially the equivalent to stdlib + stdio for C.
(Part 2 is the user interface, like DEU, Keyboard, LDB and ICC; Part 3 is the system software of OPS 0)
I am not sure about the legal side there - if we use the flow charts of a software, instead of the source code, taken from a NASA server, can we still include it under our own license for making it open-source, or do we have to exclude it or use a different license there?
