Date   : Tue, 26 Feb 2008 08:28:18 +1100
From   : msmcdoug@... (Mark McDougall)
Subject: BBC FPGA Boots to BASIC... almost...

Peter Coghlan wrote:

> If this works ok, perhaps the execution of BRK
> is setting something up for a later failure.

I suspect you may be on the right track, as REPORT prints the copyright 
message and returns to the BASIC prompt.

> Alternatively it might be useful to type in a short program with an ON ERROR
> directive which does not involve REPORT to see if the problem stems from
> processing a BRK or from processing REPORT.

Using ON ERROR inside a program results in the freeze again...

> Unfortunately, there is also a lot of fiddling about to decide whether a
> character should go to the screen, printer and/or serial port.

I'm pretty sure it's not a device redirection problem, as it starts to print 
to the screen and then freezes.

> 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. :(

This type of debugging support is sorely lacking in this environment and 
would be a *huge* assistance in tracking down these types of problems. But 
what you generally have at your disposal is a built-in "logic analyser" that 
is capable of inspecting a handful of signals for short periods of time - 
say 1us. You can trigger on specific values, like CPU address bus values, 
but it doesn't get much better than that. :(

I've thought of adding such a debug mode to some of the CPU cores, including 
single-step mode, but it's a lot of work, especially when you're hacking 
someone else's core. You need an intimate understanding of each machine 
cycle of the core - so you can for example, differentiate between opcode and 
operand fetches, and halt after a *full* instruction has been executed - you 
need to expose the registers to an external interface etc. And the machine 
cycles in the core won't necessarily match those of a real CPU! Then on top 
of that you have to develop the interface to display the I/O - for example 
the entire mechanism to display characters on VGA.

Anyway, thanks for your suggestions!

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"