<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Sun, 25 Jul 2010 04:33:02 +0200
From   : rick@... (Rick Murray)
Subject: Spitting expletives

On 23/07/2010 08:55, Michael Firth wrote:

> As the SBC operation is effectively A = A - operand, a borrow occurs if
> the operand is larger than A.

Mmmm, sounds like CMP's logic for the N flag. As I'm coding this, I'm 
starting to get a 'feel' for the internal building blocks of the 
processor. With this angle, there code be heavy code optimisations, but 
that would kill the KISS principle. When it is OSS, somebody else can 
hack it to death. I prefer to trade speed for painfully obvious. [*]


* - at least in VB it is impossible to do fancy tricks with pointers
     that would leave others scratching their heads for ages... :-)


> Or is the theory that you pull the value into A and then do a CMP to
> find out whether the B position would have been set? That would seem
> rather messy to me though

But... That's EXACTLY what you're supposed to do. It is probably a 
"mysterious topic" as, really, there isn't a lot of use for BRK. Maybe, 
with the largely undocumented two-byte behaviour (note the datasheets 
call it a 1 byte op, but the PC returns to the byte AFTER the following 
byte), I would imagine some designer somewhere considered it might have 
been like a "BRK <code>", like a rudimentary SWI mechanism, or x86 INT call.


> which seems a lot of instructions.

All, it would seem to me, down to a bug where PHP pushes the B flag set. 
Why? BRK isn't PHP... There must be a reason as the CMOS variant didn't 
fix this, it would have made interrupt routines that much quicker [*].

* - assuming, of course, your system and IRQ handler even bothers to
     support the BRK mechanism.


> I'm guessing the idea of the B flag is that when you do a PLP,

...which clears the B flag. Actually I read somewhere it is best to 
think of 'B' as a level sensitive signal from someplace inside the 
processor to the bit of hardware responsible for pushing the status 
register to memory; and as such it MUST be read from the stack into a 
register (A, usually) because it doesn't really 'exist' in the CPU 
otherwise. Like that bit that is always one. There's probably no such 
bit, it is just a signal pulled high that 'looks' like a bit.


> It also seems from the other descriptions that I've seen that B is
> effectively an "active low" signal to indicate an IRQ/NMI has happened,

Most IRQs are active low.


> which potentially makes "true" and "false" slightly confusing terms to
> use for it.

Depends if you are looking at it from the hardware side (line goes low, 
IRQ happened) or the logical side (variable = true if IRQ...).


This, actually, is a point raised in the FDC emulation:

--8<--------
   Latch.RTCOkay = ((Value And 8) = 8)              ' \/\/\/\/
   Latch.FDCDiscDensity = Not ((Value And 16) = 16) ' INVERTED
   Latch.FDCMasteReset = Not ((Value And 32) = 32)  ' INVERTED
   Latch.FDCTest = Not ((Value And 64) = 64)        ' INVERTED
   Latch.RedLED = ((Value And 128) = 128)           ' /\/\/\/\
--8<--------

The three FDC signals are active low, but from a logical point of view 
it would be annoying to have "FDCTest = False ' test mode on". I, 
neither, wished to complicate with "Not" prefixes (NotFDCTest...).
As far as I'm concerned, if we're resetting the FDC, then the 
FDCMasterReset flag is TRUE is the most *logical* approach.


Best wishes,

Rick.

-- 
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>