Virtual AGC Buglist Page

Important Note!

I set up this bug-list with the best of intentions, but haven't really kept up with it very well. You might (or might not) find the issue tracker to be a more effective means of reporting bugs and tracking progress toward fixes. I'd prefer that bugs be reported there rather than being reported by email, and probably will not update this page any longer.

Number	Date	Program	Status	Description	Resolution
30	2005-05-14	yaAGC	Closed	The documented socket interface of the CPU's counters doesn't work. (Thanks to Brad Little and to Peter Joseph for pointing out this problem ... back in March. Sorry, guys, for being so lax about getting to it.)	Fixed in versions 20050515 and later.
29	2005-05-08	yaDSKY	Open	I absolutely can't get this thing to build properly on SuSE 9.1, and to get it to build at all (even incorrectly) involves enormous contortions.	I suspect this is a problem in SuSE 9.1, not in the yaAGC suite, since yaDSKY builds fine not only in SuSE 9.0, but also in Ubuntu 5.04 (which I believe has later versions of everything than SuSE 9.1). Probably, gtk+, glade, and every related program need to be rebuilt from scratch to make it work. Workaround: Even though building yaAGC from source doesn't work on this platform, the pre-build yaAGC binaries do work fine.
28	2005-04-30	Win32	Open	The Win32 build process is broken in a number of ways. (Thanks to Bob Denny for pointing this out.) Apparently, a discrepancy in gtk+ versions can cause yaDSKY not to build. For example, I used gtk+ 2.4.3, but yaDSKY won't build when gtk+ 2.4.1 is used. Building yaLEMAP produces some warning messages. The regression test for yaLEMAP is confusing, in that it is unclear which error messages are supposed to be present, and which are not. There is a confusing warning in compiling agc_utilities.c The binary created for Colossus249 isn't byte-for-byte correct; there is a single byte error which shouldn't actually affect the emulation, but which does stop 'make' and thus prevents an installation. yaLEMAP is installed into a non-existent directory, which also prevents installation.	All of this (except gtk+ discrepancies) has either been fixed or worked around in the 20050430 snapshot. There's also a new Win32 zipfile for 20050430, lessening the need to rebuild on Win32.
27	2004-09-11	Win32 download	Closed	The 20040905 Win32 zipfile download was corrupted, along with the 20040911 attempt to fix it.	Fixed 2004-09-12. The problem related to the method used to create the file rather than to any Internet effect.
26	2004-08-30	yaYUL	Closed	Spurious error messages about things like illegally preceding instructions by EXTEND are displayed.	Fixed 2004-09-05.
25	2004-08-29	yaDSKY	Open	There are rumors (though nobody has actually cared enough about it to contact me directly) that some folks don't like the color-scheme, and specifically that they want the background color for the digit fields to be darker. I think it probably should be darker, to be accurate. (But of course, the widget-based approach I've used in yaDSKY will result in it always being stylized rather than visually accurate.)
24	08/21/2004	yaDSKY	Open	On some platforms, there may still be timing problems with yaDSKY. For example, I've noticed on a 150MHz P1 CPU, with Win 98, that the verb/noun flashing is slow in comparison to faster computers, even though the timing of the simulated CPU seems correct. (For example, SimValidation takes the correct amount of time to run.) Thanks to Stephen for asking the questions that led me to notice this.
23	08/19/2004	yaAGC & yaDSKY	Closed	In Win32, on slower computers, using the SimValidation, SimLuminary131, and SimColussus249 batch files to start the simulation may not work. The symptom is that the DSKY does not work. This is likely due to a race problem in which yaDSKY manages to start talking to yaAGC before yaAGC is ready, though it is also possibly due to some unexpected properties of the Win32 'start' command. Thanks to Paul Fjeld for reporting this.	Worked around 08/21/04 -- maybe! A true fix would be to correct whatever problem it was in my socket-communations stuff that forces us in Win32 to load yaAGC before loading yaDSKY. Failing that, however, I have worked around the problem by adding a start-up delay (in Win32 versions of yaDSKY only), so that communications with yaAGC. no longer begin immediately. Other work-around: If this fix doesn't work for you, I have a report that you can bypass the SimXXXX batchfiles completely, and successfully start the simulation manually. I'll illustrate the technique with the Luminary131 simulation: Get two DOS command-line prompts, and in each of them do "c:" and "cd \mingw\bin". At one of the DOS prompts, do this: "yaAGC --core=Luminary131.bin". At the other DOS prompt, do this: "yaDSKY --cfg=LM.ini" or else "yaDSKY --half-size --cfg=LM.ini". To instead run the validation suite, you'd use "Validation.bin" rather than "Luminary131.bin". Similarly, to run the Colossus249 simulation, you'd use "Colossus249.bin" rather than "Luminary131.bin", and you'd use "CM.ini" rather than "LM.ini".
22	08/19/2004	yaAGC & yaDSKY	Open	In Win XP, putting the computer into hibernation mode can break the simulation in various ways, requiring the programs to be restarted: It can (but does not always) cause the socket connections to be broken, and it can (but does not always) break yaDSKY's connection to the graphical server (or whatever passes for one in Win XP).
21	08/09/2004	yaDSKY	Closed	'configure' no longer works on some systems (SuSE 9.1). It aborts with errors. Thanks to Christian Bucher for pointing this out.	Fixed 08/09/04. This problem is apparently a result of including the yaDSKY/autom4te.cache directory in the development snapshot. That directory won't be included in future snapshots. As a workaround, older snapshots can be fixed by erasing the contents of that directory.
20	08/01/2004	yaYUL	Closed	Win32 only: Crashes before completion, with the helpful message (from Windows) that there is a "problem". (Works great in Linux, though.)	Fixed 08/01/04.
19	07/22/2004	yaYUL	Closed	Some of the changes in the last couple of days apparently broke the ability to correctly compile the validation suite.	Fixed 07/22/04.
18	07/20/2004	yaAGC	Closed	Apparently, I forgot to implement the --port=N command-line switch, and thus it wasn't possible to run two instances of yaAGC simultaneously.	Fixed 07/20/04.
17	07/18/2004	yaAGC	Open	In Win32, in --debug mode, I've devised no way to interrupt execution. In other words, if you haven't set a breakpoint, you're stuck.	This is the same as PR #2.
16	07/17/2004	yaDSKY	Open	I still don't know what i/o channel bits are used to control the STBY and RESTART indicators on the DSKY.
15	07/17/2004	yaAGC	Closed	CM: Goto-pooh crashes the CM sim. It is possible to change major modes (e.g., V91E does go to mode 07), but some other mode-changes I've tried with V37E just crash it. This may have to do with the "uplink too fast" and "downlink too fast" alarms (1105 and 1105). It appears to me that some of the i/o bits are different between the CM and LM, and so the default values I've set up for the i/o channels based on the LM actually cause error conditions in the CM. Unfortunately, I've not yet been able to find any table of CM i/o channel assignments. (It is also possible that there are complementary errors in the core-rope that don't break the checksums.)	07/20/04: Found complementary errors in bank 02 of Colossus249.bin.
14	07/17/2004	yaAGC & yaDSKY	Open	I'm not really handling the second CM DSKY properly. The second DSKY should actually deliver its keystrokes on a second input channel, and this should generate a different interrupt. Instead, if there are two DSKYs attached, they both act identically as the primary DSKY. (Functionally, I'm not sure this makes any difference, but I want it to be right.)
13	07/12/2004	yaAGC	Closed	A flaw with the server/client concept is that peripherals that get started after the AGC don't receive the appropriate signals. The server should dump a list of all current i/o channel settings to any peripheral as soon as it connects.	(This was fixed on 08/12/2004, but I forgot to update this problem report until a few months later. Oops!) Workaround in Linux: Make sure all peripherals get started before the server. Workaround for Win32: Workaround in Linux: Make sure all peripherals get started after the server.
12	07/12/2004	yaDSKY	Closed	The DSKY's behavior on return from test (V35E) is incorrect, I think. Rather than just clearing all of the displays, it should load them up with their pre-test values, or with new values received during the test.	No, I was wrong. The DSKY shouldn't have had an integral all-lights-on signal at all.
11	07/11/2004	yaDSKY	Closed	I don't think I've correctly implemented + vs. - vs. no-sign correctly, since I've noticed that the sign display is somewhat intermittent.	07/13/04: Fixed, I think. At any rate, I fixed some kind of bogus signosity. And (as of 07/20/04) have never observed any more anomalous behavior.
10	07/11/2004	yaDSKY	Closed	I think that KEY REL and OPR ERR are supposed to partake of the VERB/NOUN flashing, but I haven't implemented it.	Fixed.
9	07/09/2004	yaAGC	Went away	Luminary131 stops accepting input from the DSKY about 100 seconds after power-up, and wipes a couple of the DSKY displays.	Hopefuly, it was fixing instructions that fixed this. ... No, it's back. ... No, it went away again.
8	07/02/2004	Luminary131	Closed.	In my supposedly 100%-correct Luminary131 binary listing, there are two complementary errors in bank 1, which cancel out in the checksum (causing it to appear correct). Thanks to Julian Webb for pointing this out!	07/02/2004: Fixed.
7	06/11/2004	yaAGC & yaDSKY	Partial fix.	No longer compiles under Win32. (Works in the sense of displaying the simulated DSKY, but gives "server error 9" and refuses to display or to accept simulated keypresses.)	06/11/04: Compiles again, but the Win32 version of yaAGC doesn't actually work. 07/17/04: Maybe works. I think the problem is that the workaround for PR #13 needs to be different in Win32 than in Linux.
6	05/05/2004	yaAGC	Closed 06/02/2004	In --debug mode, breakpoints don't properly take memory pages into account. In other words, the break occurs whenever the offset into the memory page is correct, but not necessarily the page number.	I think this is fixed.
5	05/01/2004	yaDSKY	Closed 05/01/2004	Christian Bucher has pointed out that the executable for yaDSKY should be called "yaDSKY" rather than "yadsky".	I now provide both. 'yaDSKY' is a link to 'yadsky'. That way, I don't have to rewrite my documentation until I feel like it.
4	05/01/2004	yaDSKY	Closed 05/01/2004	Christian Bucher has pointed that if 'pkg-config' is not installed, then 'configure' returns a very confusing error message.	My 'configure' script now overrides GLADE's autogen.sh script, and substitutes a better error message.
3	05/01/2004	yaAGC	Closed 05/01/2004	Christian Bucher has pointed out that yaDSKY is no longer able to connect to yaAGC when the latter is started in --debug-dsky mode.	Apparently I broke this in adding the --debug mode to yaAGC, and never tested it aftward. Now fixed.
2	11/30/2003	yaAGC	Open	There is no interactive means of halting execution for debug mode in Win32, and the method which has been created for Linux may or may not work in *BSD or MacOS X.
1	10/28/2003	Colossus249	Closed 12/25/2003	Due to inadequacies in the available program listing, the binary image is incomplete: The "bugger word" of bank 35 and the values at two locations (2634 and 2734) of bank 36 are unknown. Therefore, bank 36 contains known errors (within the P37 and P70 programs). Furthermore, while the remainders of banks 35 and 36 could be correct, they are nevertheless suspect because of the impossibility of generating checksums for them. Note: The only complete remedy for this problem requires an improved scan of Colossus249. A different (but similar) version of Colossus may also be adequate for solving the problem of bank 36, and would obviously be desirable for other reasons as well. Help, anyone!	I have developed improved proofing techniques for banks 35 and 36, and I have reconstructed the missing code in bank 36. (Description here.) While the only fix in which we could have 100% confidence requires better page images, I'm pretty confident (in the absence of better images) that my reconstruction/proofing is correct. Later (12/01/03) ... Mr. Gary Neff has provided replacement scans for the problematic pages of bank 36, verifying the reconstructed code. Potential problems within bank 35 persist.