Skip to content
Assembly and Fortran

Test 4b: the counter without DAA

This is the program of test 4a without the word DAA. The 8086 then adds in binary, and nothing makes the byte decimal again. The counter shows 0000 to 0009 correctly. Then it shows 000A, 000B … 000F, and only then 0010. The letters come from the digit table: the program shows each nibble as it is.

A cassette tape with a handwritten label: "A Side. Assembly - the first language of the machine."

A The missing word

In src/bcd.inc, the switch -dWRONG_DECIMAL removes the two DAA words.

  • add al, 1 then daa right
  • add al, 1 only wrong: the byte stays binary

The assembler cannot see this error. Without DAA, the program is still a correct binary counter. It is only wrong for a person who reads the digits.

    Waiting for the copy of the PC to start…

    Speed:

    Compare with the correct program in test 4a. Watch the step after 0009. Jump to 9990 goes to the value that 9990 steps give here: 2706, because the counter counts in binary. After 9999 steps it shows 270F, not 9999, and the carry cell stays gray.

    A cassette tape with a handwritten label: "B Side. Fortran, the language that speaks maths."

    B What the check sees

    The value that the check expects after the same number of steps.

      The check report

      The test program runs the wrong routine 10,000 times and writes each value to BCDW.BIN. The checker (lab/check_bcd.f90) compares them with its own answers:

      File: BCDW.BIN
A side and B side agree on 10 of 10000 values
After 9999: 2710, carry 0 (must be 0000, carry 1): wrong
First wrong value: step 10: A side 000A, B side 0010
ERROR STOP The A side and the B side disagree.

      The wrong values in each group of 1,000 steps:

      How one missing word breaks the game

      1. The first ten values are right. 0 to 9 look the same in binary and in packed decimal. A person who tests the counter for a few seconds sees nothing wrong.
      2. Then the digits show letters. After 0009, the binary sum 0Ah stays 0Ah. The digit table turns it into the letter A. In the lander game, the fuel would show 00A0.
      3. The end of the count is wrong. After 9999 steps, the wrong counter is 270Fh, the binary form of 9999. It never shows 9999, and it gives no carry at the end. A game that waits for 9999 never sees it.
      4. The check guards the site. Only 10 of 10,000 values agree, and the step after 9999 is wrong. The build requires this check to fail. If the check accepts the wrong program, the check itself is broken, and the build stops.

      Where this twin comes from

      Test 4a lists the full path from the video to the test (where this test comes from). The wrong twin has two more sources:

      • The rule of PLAN.md, Phase 4d: each new routine gets a wrong twin, and the build requires its check to fail. Phase 4d names this twin: the switch -dWRONG_DECIMAL removes DAA, and the check must find 9,990 wrong values. The check found 9990.
      • The Doing arithmetic page of the A side: "If you forget it, 09 + 1 becomes 0A, not 10". This page shows that sentence in a running program.
      • The same pattern as test 2b (one wrong word) andtest 3b (one wrong value), decisions D23 and D24.

      The wrong program comes from the same files as test 4a. NASM builds it with the switch -dWRONG_DECIMAL(see src/bcd.inc). The panels of this page calculate the steps in the browser. The check report comes from the real test in DOSBox.