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.
||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
||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.
||The Win32 build process is
broken in a number of ways. (Thanks to Bob Denny for pointing
||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.
||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.
||Spurious error messages about
things like illegally preceding instructions by EXTEND are displayed.
||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.)
||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.
||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
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:
||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).
||'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.
||Win32 only: Crashes before
completion, with the helpful message (from Windows) that there is a
"problem". (Works great in Linux, though.)
||Some of the changes in the last
couple of days apparently broke the ability to correctly compile the validation
||Apparently, I forgot to
implement the --port=N command-line switch, and thus it wasn't possible
to run two instances of yaAGC simultaneously.
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.
||I still don't know what i/o
channel bits are used to control the STBY and RESTART indicators on the
||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.)
complementary errors in bank 02 of Colossus249.bin.
||yaAGC & yaDSKY
||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.)
||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
||(This was fixed on 08/12/2004,
but I forgot to update this problem report until a few months
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.
||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.
||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.
||I think that KEY REL and OPR ERR
are supposed to partake of the VERB/NOUN flashing, but I haven't
||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.
||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!
||yaAGC & yaDSKY
||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.
||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.|
||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.
||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
||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.
||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.
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!
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.