Date : Tue, 26 Feb 2008 14:24:10 +0000 (WET)
From : PCOGHLAN@... (Peter Coghlan)
Subject: BBC FPGA Boots to BASIC... almost...
>> If it is possible to include a debug mode which outputs (maybe to a serial
>> port or possibly even to the same place as the BBC output) a one-line
dissasembly
>> of the each 6502 instruction being executed and the contents of the 6502
registers
>> and flags, this can be very useful in tracking down the source of failure.
>
>To implement what you suggest inside an FPGA would probably take more
>development effort and on-chip resources than the BBC itself (not counting
>the 6502)!!! :O Not to mention reasonably extensive modifications to the
>6502 core to support the debugging output. :(
>
I guess we won't go down that road then!
After re-reading the thread and giving it further thought, it strikes me
that this
kind of debugging might not be so useful after all in this particular case.
Some other snippits from earlier in the thread:
>
>I notice that each time I run it, I see various numbers of characters in
>"Mistake" printed before it freezes - and sometimes half a character. So
>perhaps it's dependent on timers or interrupts???
>
If it freezes in the middle of printing a character in a two colour mode,
it appears to me that this would have to be in the short loop between CFD0
and CFD9 (maybe someone could check if have this right?). There is nothing
complicated there and nothing that does i/o, just basic everyday opcodes to
copy bytes to the screen memory.
The fact that the problem happens at different locations means that knowing
exactly where it happens probably isn't all that useful, unless for example
it always happens when processing a STA (zp),Y type instruction.
>
>I can switch in and out of MODE 7 using the MODE command, even though I
>can't see anything in MODE 7. So I switched to MODE 7, then typed a syntax
>error, then tried to switch back to MODE 6. It was frozen.
>
>That suggests to me that the problem is not caused by the MODE 0-6 character
>rendering routines?!? Agreed?
>
Agreed! It looks more like either a lower level fault in the CPU emulation or
something involving timers and interrupts as you suggested above.
Getting back to BRK, it has always been clear when the B flag is set but it
I don't think I have ever found out when exactly it is cleared. I assume it
gets cleared when there is an IRQ? If this is not happening correctly, the
IRQ service routine would never get called and perhaps IRQs might pile up
causing interesting effects?
>
>Actually this isn't quite true. The reset works correctly unless the machine
>is in the afore-mentioned freeze state, from which it cannot recover without
>re-programming the FPGA. That is weird... :(
>
This might be an important clue.
In order to determine whether a reset was caused by pressing the break key or
by the machine powering up, the MOS checks the system VIA, which is not attached
to the systemwide reset line. If the system VIA has been reset then the reset
was caused by a power up and the MOS sets everything up from scratch.
One check that is made at reset is for diagnostic hardware plugged into the
1MHz bus asserting IRQ. Interrupts are disabled from all on-board sources and
if there is an early IRQ the MOS assumes the diagnostic hardware is present
and IIRC a JMP (&FDFE) is executed. Jumping there with no suitable hardware
emulated might have interesting results...
Other than that, if resetting everything including the system VIA does not
cause the normal banner to be displayed, it suggests that something of the
emulation has been somehow damaged when the freeze happened or an unexpected
state has somehow been reached.
Is it possible to verify the FPGA programming after the freeze has happened?
(I don't know the first thing about FPGAs so I don't know if it is possible
for some bug to damage the programming!)
Finally, is it possible that something suddenly causes NMI to be asserted and
sends the emulated CPU into a loop trying to service it? Putting some code at
&D00 to catch it might allow this to be tested.
Regards,
Peter.