On Thu, Dec 3, 2015 at 12:15 PM, Kyle Owen <kylevowen at gmail.com> wrote: My understanding is that 6015 does modify the accumulator -- from the manual ( http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/fabritek/402-1001-… ) Function code 5(8) is interpreted as "...if th the addressed device is DONE, the next instruction in sequence is skipped, the contents of the device buffer are inclusive OR'd with the accumulator, and the result is retained in the accumulator..." So 6015 reads the next 8-bit quantity from the paper tape and ORs it onto AC. Yeah, I was actually just looking at that again and the jump to 7755 is rather odd. I think that's what stumped me a couple of years back and since I never got around to building the interface... I think I just assumed a couple of bits had gone south on my PROMs, to be honest. That's interesting -- on my MP-12, the sync interface brings out (IIRC) three lines: clock, data in, and data out. I'd be interested to know what hardware's hooked up to yours to provide all the goodies you have. - Josh

Alright, a lot has happened since 24 hours ago! In summary: 1. 6012 advances the tape one byte but doesn't change the accumulator. 2. 6015 reads the tape buffer and skips when ready. (Josh: you're correct; the manual wasn't lying!) 3. 6052 and 6053 read the buttons and switch on the front panel of the paper tape reader box. 6052 grabs the left four buttons in bits 8 through 11, and 6053 grabs the other five buttons and the switch in bits 4 through 11, with bits 2 and 3 permanently set for whatever reason. 4. With the knowledge of 1. and 2., I was able to get the format for loading arbitrary sequential data into core. I'll explain the format below. 5. By taking DEC's BIN loader and stripping out all unnecessary things (field switching, low speed reader support, etc.), I was able to make a BIN loader for the Fabritek. It works! The RIM format the Fabritek loader expects is something like this: 000 /leader 000 153 /5363 = JMP 7763, stored at 7755. Allows loader to continue running after first deposit 063 1AB /ABCD = Starting address of program to load, minus one, stored at 7756 0CD 1WX /WXYZ = First word of program, stored at starting address specified above 0YZ 1BL /BLAH = more program data 0AH 1BL 0AH 000 /trailer 000 It's important that the starting address specified is one less than the actual starting address, and the starting address can't be zero, as the loader uses ISZ 7756 to increment the address prior to the first store; 7777 will result in zero, causing it to skip, causing it to terminate prematurely. The loader keeps running until it overwrites the JMP 7763 instruction with a halt or something like that. I figure since this was really meant to load a more intelligent loader, like the BIN loader, it should overwrite that instruction with a JMP to the halt prior to the start address of the BIN loader, so that you can just hit the run switch after getting your BIN format tape loaded. So that's what I've done. If you're not loading the BIN loader, but rather something else in lower memory, it'd be a good habit to stop the reader during the trailer, since any other characters (like 377, after the tape has left the reader) will be loaded into core and muddle things up after your program. Might not be a problem for a few words, but eventually, it'll probably do something weird when it starts overwriting 7755...it'd probably take a while though. Best I can tell, there is no way for it to detect the absence of tape in the reader, so it'll happily go on reading 377. Here's the BIN loader with the raw octal dump of the Fabritek RIM format needed for loading it: http://pastebin.com/WiJDU1Bi Doesn't look like these units had the real-time clock option installed. Bummer! I was hoping to get a nice accurate tick for my alarm clock. Guess I'll have to look at adding that myself. Think that's all for now. Kyle