Information about the Java-based Sigma emulator.</HEAD> <BODY><PRE> See also the companion page http://www.andrews.edu/~calkins/sigma/sigma7.htm about the fully functional DOS-GCC based Sigma emulator. This emulator, which only does limited CPU functions but has a nice user interface with instruction decoding, was created in November and December 2002 by Madhu Siddalingaiah with assistance from Keith G. Calkins. A minimal configuration consists of the files sigma6.jar, sigma6.cfg, and sighcp. Under DOS/UNIX: java -jar sigma6.jar sigma6.cfg should bring up the front panel like object. Press reset, load, and run and it should run through the Sigma Hard Core Diagnostic deck and give you an "End of Deck!" message. Below are exerpts from e-mails produced during debugging which indicate the various known failures. MEDIC The RD,11 .10 at .268 does not zero out R11. In fact, R11 remains a link address so it goes looking for an error. (R0 is clobbered, in retrospect!) } else if (addr == 0x0010) { if (regR != 0) { // read/reset mem fault currentRegisters[regR] = 0; Note change in above line---was only changing R0!!! That was all it needed: SIGMA 5/7 MEMORY DIAGNOSTIC (MEDIC) 960-0401-G02 MEMORY SIZE: 0128K SUCCESS TEST 01 SUCCESS TEST 02 SUCCESS TEST 03 SUCCESS TEST 04 SUCCESS TEST 05 SUCCESS TEST 06 SUCCESS TEST 07 SUCCESS TEST 08 SUCCESS TEST 09 SUCCESS TEST 10 SUCCESS TEST 11 SUCCESS TEST 12 SUCCESS TEST 13 SUCCESS TEST 14 RTC I realized the data chaining was overkill and changed the first write to write all 47 bytes by changing .32d from .8000000b to .2f. I thus obtained the following output: SIGMA 5/7 REAL-TIME CLOCK TEST 704017-F00 MANUAL 901136 F CP4 INTERRUPT MAP FEATURE INSTALLED. IND. ADDRS MAPPING OPERATIONAL IN CPI4. CPI4 MAP REPETITIVE TEST COMPLETE, SUCCESS. LEVEL WD -TRIGGER- CLK/=0 FREQUENCY CPI1 YES NO 0 * ERROR CPI2 YES NO 0 * ERROR CPI3 YES NO 189 * ERROR CPI4 YES NO 189 * ERROR CEZ1 YES NO * ERROR CEZ2 YES NO * ERROR CEZ3 YES YES CEZ4 YES YES 500 CPS IS SLOW. CALCULATED BY AN INSTRUCTION LOOP The error indication is because the WD vs Clock are different (and these come in pairs so errors can appear because the pair is different). With the error? I saw in 7INTRAP I won't pursue this further now. I looked over the code for LPSD and XPSD. I noted a lack of CALL support in XPSD---see page 77, column 1, #2 where the R field get or'ed in, etc. Backing up, I don't see support for trap .40 specialties (page 76, column 2, #1, etc.) Maybe I'm just not seeing it because I thought you handled things like nonexistant/privileged already. I looked over the code for checkwaitinginterrupts and getinterruptlocation and was troubled by the omissions of 57, 5E, 5F. I know they are "reserved", but they still need to act like interrupts, .57 with no inhibit and .5E/.5F as II (based on T-85 manual I have). This can explain some (but not all) the problems. I noted with interest, however the lack of 011FFFF near the bottom of the list. for (int i=0x52; i<=0x57; i+=1) for (int i=0x5C; i<=0x5F; i+=1) (don't do this one---see below) (two places each) These changes didn't change the error output, much. It changed the last line from .0017BF0 to .0017FF0 which I assume is the bit for .57 since things are misaligned. I was hoping for 7FFE or better .FFFE. That missing leading 8 bit might be key as well (location 52, counter 1). This is where I would really groove on having a table output of the current status of the interrupts--armed/enabled/triggered! I'll have to reboot this beast (PC) soon--something (the usual) got clobbered and it won't paint the screen. It occurred to me to check bit alignment between the WD and interrupt routines---oops another fix in WD: for (int i=0; i<14; i+=1) (maybe 7 places) This may not have been a problem, since there was a symmetry between being able to trigger/arm/enable/etc. but should explain the missing E above. Actually, this caused another problem, although the problem is back in the interrupt chassis, not the CPU. I think the CPU is right now, but I need to pull that board for the .5E/.5F interrupt---interesting. The software leaves 0's in .50/.51/.5E/.5F and now your emulator is complaining about there being a zero. .50/.51 aren't a problem since you can't trigger power on/off. I also meant to say that debugging might be easier if you don't act like all 14 external interrupt chassis are installed. One "bucket" of 16 should be enough for debugging/CP-V/etc. Note that you could cable these in different orders (external above clock/etc.)---that would be a simple move and keep or two I'm thinking. I'm running out of time, but I see two approaches: 1) figure out what M6 is trying to print, if that really is all (where is 02?). My stop at .31A seemed ineffective. 2) figure out what M2 is doing/what the deal is with the missing line (011FFFF) and bit (8000). It doesn't seem to be returning from that counter 1 interrupt quite correctly is my gut level reaction. 1) A stop at .318 worked---maybe I forgot to hit enter yet again. Note: others will tire quickly of converting doubleword address and byte address to word address for lookup---perhaps a button near the memory display would allow you to look up by dw/byte---the command double word extractions can be time consuming. At .32C it prints the stuff---I failed to note that it was command chained. What would be special about F4?---group 15, level 4. Location .134? for (int i=0x60; i<=0x6F; i+=1) (was 13F) Two places (I don't like to make things more complicated than I have to---too many cables, power supplies, and LT16's and other logic to fight). Well that was interesting! It explained the missing line---there is no group 1 (dah). .F4 is still there---that's bad---there seems no (good) reason for you to be triggering that interrupt, especially now that I powered off those 13 chassis of external interrupts. I'll leave it there and let you figure those three items out (no 01 02 ... in M6, no 8 bit on M2 group 0, why F4). I'd say that F4 is the biggest problem. Oh, that interrupt table above may only need to do a group at a time (or format compactly 16 lines, 50 AEA or blank if not armed/enabled/active---more than one could be active, but that would mean an interrupt got interrupted). > machine on page 20, fig. 7. Instead, I was doing something that I Yes, that diagram is a good one and we've used it many times (written signal names in some manuals) and I remember going over it with George. I didn't look at the code (past or present) too closely so didn't note the deviation. I realized late this afternoon (Wed---I got interrupted in my reply) while laying some floor that 01 being present and that 8 bit being absent were consistent with each other and a good thing---you're way past that now! > > Here's the complete output with all interrupts (except 0x5E, 0x5F) wired in: That little 5E/5F bugaboo was totally unexpected. I wondered if the program caught it on a TRAP40, but the code is not the easiest to read---a data breakpoint (when location 40 changes) would do the trick, but I don't think your breakpoint works quite that way (or does it?). (It does not---see description on page 95, however). I guess .5F was so entrenced as JITLOC (contained .8C00) that you couldn't put an LT16 board in there (and pass the diagnostic)---I will have to file that one for future reference, maybe have George try it if/when he powers his up (and see what 9INTRAP does). Also, we didn't run 7INTRAP much because A) it rarely broke, and B) once we had interprocessor communication cabled up it would kill the other system. > > F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF That's a lot of interrupts! Although the "CPU" (WD) needs to allow these, I don't think the "interrupt chassis" needs to scan past .6F, thus allowing one set of 16, for now anyway. Some of the real-time Sigmas running power stations may have used more, but often that was hidden from Sigma. > > For some reason, nothing appears after "RESPOND,". Not sure why or if > > this is an error. If SS is set, run enters M7, which is correct. What should appear after RESPOND is M6, but it is not only data chained to the next CDW, but the next CDW is a transfer in control (an I/O branch, see page 90). This should be simple to implement/debug?. The set up is at lines 1778 with the LI,0 CDW at .4F5. This is followed by a B to a common routine which soon does a BAL to a short routine to kill interrupts before the actual I/O takes place. I retested the break point and you seem to be right, no CR is required---my prior problem remains unexplained (and unexplainable now). > > I have some questions on WD. On the bottom of page 81, there's a note > > that says "These code clear the current interrupt...". Take a look at > > what I did for codes 1, 2, 3 and see if I did that right. I think I did, > > but I'm confused between "current interrupt" and "remove from active > > state or waiting state all levels...". I assume it means these interrupts have to be retriggered to occur--they may have triggered once and have not been serviced, but to get service they will have to be triggered again. > > XPSD handling is a little convoluted. Part of the work is done in XPSD > > and part of it is done in processInterrupt(), CALx etc. I did it based > > on the Sig6 ref, rather than the logic equations. I think it would have > > been cleaner if I had looked at the logic equations first. Anyway, I've > > poured over it many times and it passes 7AUTO, so I think the > > instructions are correct. I looked again for code to handle page 76, col 2 and pg 77, col 1 of the XPSD and am just not finding it. I am remembering now it was something we had to add for CP-V but no diagnostics complained. However, if CP-V is happy, I'm happy (7AUTO and SIGHCP just are good enough on this one). > > I started thinking of that -- I'll do it today. It will be useful during > > CP-V debug also. With it passing 7INTRAP it becomes more academic, but as a memory centered, event driven machine, it has always been something I've wanted so you know what the hell is going on. There are deadlock situations which seemed to occur so that it would not service the PCP/KSR=TTY interrupt and figuring out why was not easy. In other words, there are some software bugs in CP-V which a scope would help figure out. Generally, we didn't have the luxury of time and knew the problem would go away with a reboot, but looking at the dump generally didn't answer what got us into the mess we were in. Eventually we figured out a COC line sending breaks continually could kill it, but someone somewhere wasn't interruptable/reentrant. It seems that generated a 7E-40, one of the most common software checks which only meant the monitor has trap 40'ed. We would often choose this to an operator recovery (don't remember right off the advantages), but it was easy to put the machine in idle---see that it was monitor code (address <.8BFF or unmapped=UMOV) clear the lights, step, run. > > If I do that, do I just ignore WD arm/enable/trig for groups higher than > > group 2?? As above, I think the WD does it, but the interrupt scanner ignores it. This will be closer to the way a real Sigma works and make subsequent changes easier. I.e. put it in the CPU,but don't cable up the interrupt chassis. > > I'll add a hex calculator window. Addresses would be fine---enter an addresss, say it is B/D not W (rarely H) and dump the locations. A "hex calculator" might be overkill. > > I'll also add command chaining to TTY. I think it's critical now. See TIC above. > Win98 is really bogus. I avoided it altogether and used only Win95, NT, > 2000 and XP. You might want to think about upgrading. I snagged an > eMachines 2.4GHz Celeron for $299 with XP after rebate. I've had this repainting problem since the original Windows 95 release---it actually has been much rarer with '98. It seems exacerbated by using DOS full-screen mode, so I suspect it won't get fixed anytime soon, but I also suspect it is a more fundamental problem. Under '95 I could actually reproduce it and sent them info thereto---might as well piss in a black hole--pardon the French. I added another diagnostic---those not using GUIDE or MTL are getting rare (PORT, SWAP, FAULT), so I will have to jump that hurdle (or wait until you can boot the diagnostic tape) soon. The diagnostic is called SEX (maybe your e-mail filter will SPAM this!) for System EXerciser. Our CE (Customer Engineer) George Snyder always said you needed to run it once a week to keep the computer happy. I thought it was time to let the emulator "get lucky", it has almost come of age (2 months?)! I put it in the "standard drop", but chose to zip it this time. I expect I will have to zip the compressed listings soon, but it has been useful at times browsing/searching them in this form (but I use my local not www copy). If you have an editor which will handle >1Mbyte files, please change all occurances of "TELEFILE" to "SDS/XDS " and return a copy. I will change the binary accordingly as well. I've been doing that before releasing any of these---Telefile claims copyright/proprietary information, but that claim is rather bogus (except, perhaps on their very minor changes). (Since we had a "single" CPU at a very conservative University, we didn't run this diagnostic much.) This diagnostic was good at putting the system under some stress---giving it a workout on multiple channels/levels at once--like mental, not just physical... You may want to remove your nonexistant I/O address exception/wait since it wants to determine what addresses are valid and scans most of .000-.7FF (skipping .20-.7F on each IOP, I think). After you get through that it gives a prompt. I will have to keep digging for what is expected there, but it hosed when I gave it a ?. I seem to have gotten further than George's emulator does---he complains about unimplemented orders (.FF) and hangs before giving the prompt. Anyway, before the prompt it lists configured I/O addresses---I don't know why it doesn't seem to find "any"/but 1 at 0. This may have to do with TIO/TDV status information. I will keep digging. I found the manual. It recommends HARDCOR (how appropriate! =SIGHCP) and AUTO be run fiist. I see it exercises various boundaries (page, word, byte, doubleword), the map, ext. int., additional reg blocks (with all those ext ints and reg blocks this could be very entertaining). It should also read/write tape/disk and maybe give some useful error messages. (George's also gives me some cannot configure errors as well as duplicate channel which seem to be bogus--he has floating, we don't.) It seems to not check for counter 1/2/=0/.57/.5E/.5F TELEFILE SYSTEM EXERCISER 960-0050-H03 01FFFF MEMORY LAST WORD ADDRESS SIGMA 7 CPU DECIMAL 0020 REGISTER BLOCKS MAP WRITE LOCK 0000 GROUP INT. LEVELS 38F0 0002 GROUP INT. LEVELS FFFF 0003 GROUP INT. LEVELS FFFF 0004 GROUP INT. LEVELS FFFF 0005 GROUP INT. LEVELS FFFF 0006 GROUP INT. LEVELS FFFF 0007 GROUP INT. LEVELS FFFF 0008 GROUP INT. LEVELS FFFF 0009 GROUP INT. LEVELS FFFF 000A GROUP INT. LEVELS FFFF 000B GROUP INT. LEVELS FFFF 000C GROUP INT. LEVELS FFFF 000D GROUP INT. LEVELS FFFF 000E GROUP INT. LEVELS FFFF 000F GROUP INT. LEVELS FFFF ... Thanks for the patches, but right now I'm using the exception as a convenient place to stop and check out the code.... .356B (.3573, .357B) is where SEX does a TIO,12 *8 to the different IOP's. It preloads location .20 with 0. If it remains 0, then it concludes there is no such IOP. It is using address 0, .100, .200, .300, ... for this and has logic to apparently differentiate between an IIOP (Sigma 5, shared memory port with CPU) and Sigma 9 MIOP (but perhaps uses Sigma 9 flag, so a Sigma 9/Telefile MIOP on a Sigma 6/7 may not be detected here) . Anyway, this location .20 stuff is not documented in the Ref manual, but see the Tech manual. It seems George and I had to fix this before CP-V ran (but we probably caught it on the tape/disk diags). Also, TIO has to return status to 12 for this logic to work since it compares R12 with .20 (earlier copy). However, since the TIO is not accepted (CC1=1), R12 isn't changed (I'm rambling). Somehow it is trying to differentiate between an IOP that isn't there and one that is. Note: for address 0, George returned a current command address of .FF01---location R13/.21 had .10800348, apparently status and byte count of a prior I/O---don't know what device right off. THUS the branch at .356D is where we diverge. NOTE, also, the TIO to 0 is accepted not rejected. I think this is a special address. .35A3/4 is where it does the device checking with an HIO/TIO. I don't understand why address 2 is not being recognized---apparently your I/O subsystem isn't implemented to that extent??? George hangs at .3646/7 doing a TIO after issuing a seek to a tape drive. Apparently the tape drive has gone busy (CC2=1) and doesn't ever quit. NOPping out .3647 isn't enough since it checks status bits as well as CC. NOPping out the branch at .3649 means it hangs at the SIO. So, what should it do with an invalid order---certainly not go busy? Wait, it isn't invalid. SEEK=.03, set correction=.03. This bears more investigate time than I have right now. We may need to figure out how we want to procede with the I/O subsystem, since the CPU and interrupt systems seem good to go. Right now I'm kind of taking a scatter shot approach and not clear which bullet hits something vital and/or what you might be stuck on (other than perhaps the holiday season was too short). I put PORT and the excuse for a listing "out there". I used PSEDIT to change TELEFILE---it doesn't have a global change, but handles files bigger than QEDIT (an older version) does. I should try SPRINT on these large files sometime. PORT halts with a WD .44 exception at .7ED. My research into what a .44 might be has so far turned up nothing. This comes directly after a pair of .42 to toggle the music flip-flop. It seems the "lamp" may have been addressable separate from the alarm and sound, but I'm not sure now. The T-85 manual didn't say. I will nop it out/ignore it for now, but it seems stuck in that code. Then it does not have a line printer (address 2). I see I don't have such in my configuration file. I will put something in (like a TTY), but wonder where we are at on that score. It has output: TCP/PORT-H02 MAX MEM= but not the memory size yet (1FFFF), number of register blocks (4---it ignores the extra), and a prompt. Must run More on PORT. I verified that George does nothing for either the WD which sets clock margins or this WD .44. My Sigma 9 ref manual also shed no light. I expect to at least peak in the Sigma 6 tech manual sometime. For now I think we should ignore it, but document that we are on the lookout for what it does and that PORT issues it at .7ED. After looking harder I thought I had discovered a real listing! However, upon close examination it appears to be more related to SWAP/SUPER SWAP which were programs I don't ever remember using. PORT, however, was kind of nice to run every once in a while. I also found instructions at home, but there should be another copy here at work in the Honeywell DPM stuff. I did find a 13 page document---two copies---both very poor, as well. If/when there is another mailing I will try to include it. PORT actually starts with a WAIT at .69 after enabling interrupts and arming/enabling Clock 3/4 and clock4=0. The wait it followed by a B $-1, so the WAIT exception/step/run aspect doesn't allow the interrupts to take over and get us out of there. I think I mentioned before that I NOPped this WAIT out and then we proceeded. After putting address 1 in .5E and .5F the program loops with a constant chime, but still doesn't output the memory size, nor prompt. In stepping through it I came to location .80 (via a PLW,7 B 0,7) which could be an XPSD but really is TEXTC. Will have to get back with you on this, must run now, but something is broken! The XPSD sends us to R0 which has EBCDIC "0" in byte 3, hence trap 40 sends us to .761 and the nasties continue (I think). It seems the IA window isn't circular (it starts over when full?), the newest entries are at the bottom, and it doesn't track LPSD/XPSD activity??? It was useful earlier, but seems garbaged now. It's not clear if I ran into a logic bug based on broken I/O or if something is wrong with the PSW/PLW/interrupt/? aspect. Without a descent listing it isn't clear if this is a good avenue to pursue. It may be trap 40 related in find the memory size so I will likely investigate a little more. The WD of .44 I finally found in a Sigma 5 Ref. manual. It resets an IIOP. I also want to document here WD .47---on 9/T85/560's it turns on the MA flag (46 turns it off). Don't know right off if implemented on a Big 6. Could well be it isn't. George ignores all 4x but 40,41,42. George and I only needed it to allow big MAPs, not use more than 128K, so we didn't go that far. I note this partly because PORT does this at .7FB. The last entry in my copy of progress.txt (in sigma subdirectory) is dated 12/16/02, so I hesitate to use it as current. Lots of nice ideas there at the end. Some would be nice features, but may distract from the critical path. There were nice acknowledgements for my contributions (except on DL, DST)--thanks. CPU failures seem limited to implementing remaining instructions which I expect to get to over the next month or two. (I remain unclear as to some special trap 40/cal XPSD stuff I haven't seen.) MAP/access/locks all seem to work. The interrupt system passes the diagnostic. Hence this list, based on various diagnostic test cases, primarily relates to I/O: RTC data-chained output to TY (column 1 but no YES/NO/ERROR) also must be faking a NL 7INTRAP command-chained output + TIC to TY (RESPOND, but no M6) 7INTRAP Reset should restart (not clear memory) 7PFS no way to activate PON/POFF interrupts (or save memory to disk :) SEX IOP address recognition on address 0, .100, .200 SEX IO instructions changing locations .20/.21 on TIO (status returned there before R/Ru1) SEX needs to output fairly valid "attached" devices and associated model numbers. PORT wait at 69 doesn't wait allowing the triggered interrupts. PORT PSM/PLM broken--see below. CPCU.MT no data transfer (but no error reported either) AUDIAG has an extraneous prompt ">"; TY input not forced to upper case; lots of potential for device testing here! TDIAG order 03 unsupported---SIO accepts, TIO returns CC1, loopus. MTLU00 same as above. Commentary generated during debugging: PORT starting at .A7A does a CAL1,0 L547 to output "MAX MEM=" .48 (CAL1 loc) has XPSD,6 .9E. .9E should send it to .668 which sends it to .693 which pushes three words onto the empty stack (SPD=.12F4, stack at .16E0). From here we go through .69D to .6A4 (address not equal 0 so so LF appended) where we BAL,7 to .67A and push 3 more. At .67A we check for TIO to 1 and branch to .74F where we pull three regs and return. We BAL to an SIO and a TIO routine at .6A6/7, pull three regs, increment the CALled PSD and return. So far so good. We save this max mem address at .A7C/D, and do a CAL1,1 which goes to .669 ok (So the register ORing is occurring). The stack is now empty. At .6BA we BAL to .6F2 apparently to convert the hex value in R9 to a text value in R8/9. His happens, but I didn't come back to .6BB without chiming (clock 4? and stopping on that WD,0 .44 at .7ED which I will now NOP and see if I am dead yet). I may be dead because I'm at .7F0 with an HIO to 0 where I have been (but not this time). After NOPping these I am hosed here. We will go reload and stop at .6BA and try again Ah ha. In this routine we PSW,7; PSM,10 (2) and end with a PLM, 10 (2), PLW,7. I'll swear we pushed our link address (.6BB), but we pulled what had been in R9 (.1FFFF000). Thus our B 0,7 at .703 sends us to .1F000 which has .761 so we trap 40. Stay tuned (but I'm expecting a call home anytime). Back at .6BA and the BAL,7.6F2. The stack (.12F4/.16E3/) has three words from a few instructions earlier. They are .11/.11/.EF/.11, but I seem somewhat misaligned already (I guess not empty=0 I pointed at .16E0, so the last nibble agrees). R7 was pushed to .16E4 (.6BB). (The phone call came.) When we pushed two registers starting at R10, R9 clobbered .16E4, R10 may have gone in .16E5 and R11 may have gone into .16E6. R10 and 11 were both zero so I could not tell for sure, but R12 was not pushed. Hence PSM is broken (and SUFFIX didn't complain---why am I not surprised). Note, in generating the above summary, I did a fairly complete regression test, but after repairing PSM (and PLM) we will have to do it again. Let's see, I wrote PSM/PLM so I suppose I should look into it. It will be hours before I get back to this, however. Glad to find this now and not in the operating system, even if this listing is virtually trash. > I added ack for DL/DST -- I like to give people credit where it's due. Thanks. This month we have to do our faculty annual reports, so such things are on my mind, colleagueality, national/international collaboration, etc. > This looks like real time commentary! :-) :-) :-) Yup! Sure is hard to backtrack with you don't keep good notes. > I think i<=count should be i<count. If you start from zero, you should > go to count-1, not count. That's what PLM does. I could understand how The problem is a bit more subtle. Indeed R-1 clobbers the prior entry, but R gets put in the right place. Thus the problem is one of not incrementing the storage location first. Thus in addition to the two items cited above, value0++ in the memory access goes to ++value0 and the value0--; line with comment gets deleted. With those changes it passed SUFFIX (still/again). By the way/for the record, a stop at .145 and inspection of R3 hw 0 gives you a pass count for a success indicator, in addition to: CNT PULSE INTERRUPTS ARMED ON NEXT PASS. -- INTERRUPT AND CLEAR R5 TO DISARM. In adding 7FLOAT to my list of diagnostics (but then commenting it out since I didn't create the file and it complains if the file does not exist, this check shouldn't happen on output devices like LP/CP) I discovered a limit of 24 "IOP's". It ignored iop.24! PORT now gives the time prompt, accepts the time, and gives the H> prompt. However, basically any input yields <NO>. I don't know why. GO should ask for DATA MODE? WA for waterfall was one of my favorites. I also am not hearing the tune to "Here I am to save the day!" which I should (no big surprise and add that to the list?). This will also float that PCP/TY interrupt high on the stack. Good news---while looking for instructions here on running PORT, hoping to find more information on that <NO> above, I found a listing from Nov. 11, 1971 and Carleton University Computing Centre, an early Sigma 9 site in Ottawa Canada. It seems to be only 2997 locations of 4906 locations or 2600 lines vs. 4700 lines, but it is better than the nothing we had! There is no cross-reference. (There are a lot of differences, BAL,7 to do SIO/TIO, R6 instead of R1 used, etc.) Back to PORT. Having found the input routine I thought to stop and compare listings. (I'm suspecting it isn't liking our activation character, but I can't seem to send a LF (CNTRL J) and haven't figured out how to EOM (.15?), so I'm stuck with a CR=.0D or CNTRL M). Curiously, I am at .75C B 0,7 which doesn't seem to want to step---the computer goes into RUN mode and won't come out. Maybe this is because of the TY read pending? When I satisfy the read it will come out of the RUN the single step put it into. Back to PORT at .6C6. G but not anything else is at the location it does a LB on. Not clear yet if this is a TY read problem or something else. By running GSP's emulator I discovered these are 1 byte reads and it keeps issuing reads until that .15 character is typed. Your emulator doesn't activate until the activation is sent, thus it only gets that first byte, but knows we were activated. I hope that makes sense and I have to run again. I'll need to stop loosing hours figuring these out probably for the rest of the week anyway. Good luck. In Progress.txt I don't see adding boxes for DW, HW, Byte address conversion for address given. Also, the two entries below overlap substantially. > 7INTRAP Reset should restart (not clear mem I'm not finding my reply to this e-mail of last August although I thought I had sent you to George Plue. However, late October Madhu Siddalingaiah <madhu@madhu.com> started hacking together a Sigma 6 emulator in JAVA. Since then we have about a dozen diagnonostics, including SIGHCP, PATTERN, VERIFY, 7AUTO, 7SUFX, MAP, PROTECT, and 7INTRAP running. We are moving on to the I/O subsystem. It is not as fast as the one I helped George Plue with, but it is still many time faster than a Sigma 9 on this old 600Mhz system. The user interface is much better and I am hoping we can have more easily integrate networking, which is where George bogged down. We haven't clarified distribution, but I made it clear in my involvement that I wanted something the Computer History Museum could use. You might drop Madhu a line of encouragement. He is doing it as a hobby and reviving memories of the short time he programmed at NASA. ---.-.----.-.-----...24+ years at AU and counting, ...(down to retirement?) That tune PORT tries to play I mentioned earlier as "Here I am to save the day" comes from the theme to the 1950's cartoon Mighty Mouse. I was not able to find a sound clip on the internet although I tried. George's emulator plays it---it isn't all that fast but sounds rather "tinny". Thus I was surprised/not to find any apparent corrections for processor speed. The WD is at .A88 and is followed by a BDR,4 $ for frequency timing and embedded with BDR,3 for duration and BIR,2 for note sequencing. Thus, as I see it, the short notes (2nd, 4th, 5th, 6th) get 105 (.69) repeats, the long notes (1st, 3rd) 210 (.D2), and the ending note (7th) 630. The frequencies are .2A9 (681 for 1st, 7th), .32B (811 for 2nd, 6th), .3FC (1020 for 3rd, 5th), .553 (1363 for 4th). Perhaps I can get my wife to sound it out music wise, but using Sigma 6 timing, BDR $=1.4/WD=2.5 so maybe 4 microseconds per, so 681 would give 2.7ms or 367Hz or maybe F4#; 811 would be 308Hz, 1020 would be 245 Hz, and 1363 would be 183Hz. Thus, maybe F4# (.5), D4# (.25), B3 (.5), F3# (.25), B3 (.25), D4# (.25), and F4# (1.5), where # is sharp, () is timing, 3/4 is octive. There is also LPSD/XPSD in here to confuse things further, but I think we've about hit what they are attempting. This code may not appear in my real listing. Also, later versions of PORT handled MOS memory and MPC (microprocessor controlled=Honeywell) tapes/disks. This explains much of the ballooning of code. Not sure why I don't hear anything with your emulator, since somethings do emit sound. I've done a fair bit of reading JAVAwise to discover that some </PRE></BODY></HTML>