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 at GitHub to be a more effective means of reporting bugs and tracking progress toward fixes for software. I'd prefer that bugs be reported there rather than being reported by email, and probably will not update this page any longer. For issues with the website, though, please do email me.
||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
||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
||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 this out.)
||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
||The 20040905 Win32 zipfile
download was corrupted, along with the 20040911 attempt to
||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
||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
||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
||In Win32, on slower
computers, using the SimValidation,
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:
||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
||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,
||Some of the changes in the
last couple of days apparently broke the ability to correctly compile the
||Apparently, I forgot to
implement the --port=N command-line switch, and thus it
wasn't possible to run two instances of yaAGC
||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.
||I still don't know what i/o
channel bits are used to control the STBY and RESTART
indicators on the DSKY.
||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
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
||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.
||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
||I don't think I've
correctly implemented + vs. - vs. no-sign correctly, since
I've noticed that the sign display is somewhat
||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
||I think that KEY REL and
OPR ERR are supposed to partake of the VERB/NOUN flashing,
but I haven't implemented it.
||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 message.
||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.
||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,
||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
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.