MODELB DEBUG

	This version of the EXE is compiled without optimisations and has
    some simple debugging features. I've put these features in as I've
    had a need for them, and they're often rough and ready and they
    might interact in strange ways! Still, you might find them useful.
    
    You'll need DirectX8. It's pretty much like the normal version,
    except for the following.
    
DEBUG MENU

	Start Disassembly
    Stop Disassembly

		produces a running disassembly of each instruction executed. The
        format is like this:

20644193  (@20644224 )E3D : BIT   &FE60      2C 60 FE -> A:00 X:00 Y:13 S:E8 P:------Z-

		It should be pretty clear. The first value is the current cycle
        count. The second is the 'next-stop' value, which you can
        ignore. (In case you're wondering: it is the soonest point, in
        cycles, when the CPU will definitely have to stop because an IRQ
        is coming or some hardware needs polling.)

		Then is program counter, instruction, dump of instruction bytes,
        and finally the registers after the instruction has run.

		IRQs are also indicated:

38932222  (@38932223 )802B: BPL   &8068      10 3B    -> A:00 X:03 Y:1F S:EB P:N-----ZC
38932224  (@38932224 )IRQ: flags 0x1, SysVIA: IER=&73 IFR=&C0 ACR=&60, UsrVIA: IER=&00 IFR=&00 ACR=&00
38932231  (@38932352 )IRQ: flags 0x1, SysVIA: IER=&73 IFR=&C0 ACR=&60, UsrVIA: IER=&00 IFR=&00 ACR=&00
38932231  (@38932352 )DC1C: STA   &FC        85 FC    -> A:00 X:03 Y:1F S:E8 P:N----IZC

		'flags' is a bitmask of the RQing devices. Bit 0 is system VIA,
        bit 1 is user VIA and bit 31 is the NMI (i.e., disc system).
        IFR, IER and ACR are provided to show what's going on.

		Note that there is a real overhead to saving this data (the
        emulator will be about half as fast again), saving it can take a
        very long time, and the resultant files can be very large.

	Disassemble RAM
    
    	disassembles all of RAM and saves it to './ram_disassembly.txt'.

	Save Challenger RAM
    
    	saves the 256K or 512K RAM in the challenger to a file.
        
    System VIA debug panel
    User VIA debug panel
    Video debug panel
    
    	debug panels for particular aspects of the beeb. COnstantly
        updated. Video one not done yet!
        
    Show all
    
    	Forces a very strange palette (and a few other things) so you
        can see what's _really_ on the screen! Strangely entertaining,
        this is!
        
    Log a few frames
    Log a few frames (w/ disasm)
    
    	Logs records for a few frames about the contents of each
        scanline, and various other events useful when debugging the
        video system (VIA T1 timeouts mainly).
        
        The "w/ disasm" one also switches on running disassembly, if it
        isn't already.
        
        Regardless, when logging is done, if running disassembly
        was active (be it through "Start disassembly" or "w/disasm"
        option) the output is appended to the specified file. No progres
        indicator will appear for this, so the emulator might appear to
        hang if there's a lot to be saved.
        
Show sys (R)/usr (G) T1 timeouts
    
    	Show system and user VIA T1 timeouts on the screen. The red bar
        indicates sytsem VIA. The green bar indicates user VIA. The line
        will be yellow should they coincide.
        
        If you have this enabled, the scanline log will show T1 timeout
        messages from the video system as well as from the VIA itself.
        
NO OPTIMISATIONS

	It's compiled without optimisations and with internal checks and
    extra logging facilities blah blah. Basically, it runs a lot slower
    (about half the speed of the real version it seems) and the EXE is
    shockingly massive.

MULTITASKING

	It plays nicer with Windows so it's not a pain to debug. You'll find
    Windows has use of F10, Alt, windows keys, etc., and the keyboard
    response might not be so immediate.

BBC1770.TXT

	If I forgot to undefine it, you'll get a file called 'bbc1770.txt'
    listing what the 1770 has been doing. (Note read/write cycle times
    are 'out' compared to the running disassembly; this is actually
    correct, there are a couple of CPU cycles of internal processing
    before the read/write actually takes place.)

