Someone not only spilt water on my implementation but clearly fed it after midnight because the gremlins are out in force.

Be ready to snigger, point and mock, because this blog post is all about bugs, glorious bugs.

Bugs glorious bugs…

With the ROM, RAM and CPU wired up and enough of the ULA implemented to provide the CPU with a clock and RAM access, the stage is set for a first boot up. I guess the post title gives away how well that went.

In theory the CPU should attempt to read the RESET vector address which is the two bytes stored in ROM at 0xFFFC and 0xFFFD.

0xFFFC after removing the 15th bit (rom uses 14..0) is 0x7FFC. Looking in the combined 32kB basic+os rom file at that location shows the CPU should receive a RESET vector address of D2D8.

Circled in green in the simulator image above shows the CPU does indeed receive D2D8 back from ROM however there’s a problem circled in red.

After reading D8D2 the CPU then reads A9 from that location followed by pushing d8d2 to the stack and 0x20. At this point it appears to read the IRQ vector FFFE/FFFF of DAE7 and starts executing from there. Not what I was expecting which was for it to start executing code at the RESET vector address.

It turns out I made a mistake and had set the CPU’s n_irq line using the Master IRQ.

  isr_status(ISR_MASTER_IRQ) <= (isr_status(ISR_FRAME_END) and isr_en(ISR_FRAME_END)) or
                                (isr_status(ISR_RTC) and isr_en(ISR_RTC)) or
                                (isr_status(ISR_TX_EMPTY) and isr_en(ISR_TX_EMPTY)) or
                                (isr_status(ISR_RX_FULL) and isr_en(ISR_RX_FULL)) or
                                (isr_status(ISR_HIGH_TONE) and isr_en(ISR_HIGH_TONE));
  o_n_irq <= isr_status(ISR_MASTER_IRQ);

The Master IRQ is high anytime an IRQ is flagged such as Power on Reset (POR), Cassette High Tone detected…

n_irq however should have been set to not Master IRQ as it is active low.

  o_n_irq <= not isr_status(ISR_MASTER_IRQ);

One bug down, too many to go…

Memory Clear Failure

Having setup the video to output a blue fill by default and a green fill colour if the CPU attempted to put the ULA into mode 6. I was presented with a blue fill colour, yet another bug (or bugs).

Stepping through with the simulator and decoding each instruction the CPU read/executed was needed. For this I made use of several sites including 6502 Instruction Set Decoded and 6502 Opcodes.

With this and the simulator address/data output, I determined the CPU was executing the following sequence of instructions after coming out of reset.

Bolded in the listing above are the three relevant addresses.

A few instructions after the 0xFE00 register read (which also clears the POR, power on reset, flag) there’s a BEQ (branch if equal) at D8F0 that is based on whether the POR flag previously read is set or not.

When it’s set the CPU will jump to a memory clearing routine. However as the listing and sim shows it does not branch and continues on to attempt a read of address 0x0258 which returns UU, isim speak for uninitialised data.

The simulator trace below shows why this is occuring. When reading the 0xFE00 register the ULA clears the POR flag on the next cycle, but since the CPU is operating at 1MHz rather than 16MHz, it’s several more cycles before the CPU actually receives the read data by which point the register has been cleared to 0x0 rather than the expected 0x02 value (POR flag set). You can just about make out the 0x02 transition to 0x0 near the left of the red circled region.

This flag shouldn’t be cleared until the next 1MHz CPU cycle. As it happens I was considering this issue during initial development as the following TODO comment indicated.

-- Register access
if (i_addr(15 downto 8) = x"FE") then

  if (i_n_w = '1') then
    if (i_addr(3 downto 0) = x"0") then
        -- TODO: Will this be read without a one clock reset delay?
        isr_status(ISR_POWER_ON_RESET) <= '0';
    elsif (i_addr(3 downto 0) = x"4") then
        isr_status(ISR_RX_FULL) <= '0';
    end if;
...

I guess the answer to that was, no it will not and just one ULA clock delay would also not be sufficient, it needs to delay the clear until the next CPU clock.

With a delayed clear in place, 0x02 is returned and used in the AND and EOR operations resulting in 00 in the accumulator, Z flag set and 0 being pushed to the stack. The BEQ now branches 9 addresses forward to D8FB which is the memory clearing logic and memory does indeed appear to be clearing in the simulator.

Memory clearing seemed a little odd as not every location in RAM was zero’d out. After stepping through the routine, the following instructions were executed:

It looks like the memory skipping is deliberate. Memory clearing starts 0x0400 bytes in and skips one byte every 256, zeroing out the rest of RAM between 0x0400 and 0x8000. Why, I’m not sure.

A small victory and confirmation some parts are starting to work, but more bugs remain.

Use the source

With more bugs to solve and tired of working out each opcode from the iSim trace I decided to DDG to see if anyone had disassembled the acorn firmware and found a link to this partially commented dissassembly

Between the simulator and the above disassembly I was able to step through and resolve the remaining issues with the implementation. A few conflicts between the CPU and ULA ram during read/writes and assorted other minor issues.

In the end, the screen finally displayed a green fill, signifying that the POR flag had been correctly cleared and the CPU had been able to execute far enough to request the ULA switch to video mode 6.

The first real sign of progress and indication that this just might work.