Unless the time-critical ISR involves the particular I/O residing on the external bus, it will have no impact at all. If it does reside on the external bus, only a MOVX instruction will affect the timing. Keep in mind, that if you have multiple devices on the external bus, you need only ensure that the bus cycle is long enough to accomodate the slowest. If you have a requirement for LOTS of I/O to one set of peripheral hardware, you can consider making a timing adjustment dedicated to that set of hardware to the exclusion of others. You have to consider the consequences of that, however. Remember, though, that an SFR write can change the bus cycle length. If you have two bus speeds, and know which routines affect which hardware (which you should, as you're the guy writing the code) then there's no need to determine what the current SFR setting is. You simply set it, once, as needed when entering the code block and restore the default when you exit. When you subsequently enter a code block that requires a cycle length change, you can make the necessary change, so long as you do it prior to the MOVX instruction(s) that access the external bus region that requires it.


No, I don't think that's necessary at all. First of all, the ISR will only be affected in its timing during cycles to the external bus. IF you use the external bus-located hardware, then you must, of course, allow for the required time. However, if your time critical ISR doesn't involve the external bus, it will not be affected at all. Secondly, IF you DO need to operate I/O on the external bus as part of your ISR, and IF those external resources require a different bus speed, which is a rare condition, indeed, then a SFR writes are all that's needed to set the bus speed for that ISR. Naturally, you have to consider the effect of how you've designed your system. I imagine what youd have to do given the circumstance you propose, is

fetch the current SFR content to a register
set the appropriate SFR content (1 byte)
do the isr
restore the prior SFR content (1 byte)

However, it would be an unusual situation, indeed, to have to have two different bus-cycle lengths, possible and practical though it might be. I think this is among the rarest of situations. I think you're "reaching." Unless you actually do have devices requiring a choice of cycle length on the external bus, which would be extremely unusual, you'd simply have to know how long a MOVX instruction takes when you use it and allow for it in your time budget. In that case, your ISR would probably be more like


set the appropriate SFR content for the ISR (1 byte constant)
do the isr
set the appropriate SFR content for the main code body (1 byte constant)


No, you certainly wouldn't want to disable interrupts. What you would want to do is to take into consideration that every access to the external bus, which, of which you as the programmer will be acutely aware, will have a duration different from access to internal resources. However, you'll know that, so you can make adjustments in your code.


Well, if you have a 1 ms interrupt, you have to take it into consideration in the ISR if it uses the external memory bus. In the case we were considering, the external hardware was limited to the external 8255's, though the same restrictions apply to any external LSI (FDC, HDC, USART, CRTC, etc.) hardware with access time restrictions that exceed the full-speed specified performance of the external bus.


This all ties back to the basic architecture of the 805x. The only instructions that would be impacted by the firmware-controlled cycle stretch are MOVX instructions. If you don't use 'em you won't be affected. If you do, you'll know it, since you're the one doing the typing, and you simply have to allow the appropriate amount of time in your time budget.


Well, I never learned to like the 8255, or its Motorola equivalents because of their low output current. COnsequently, my primary use for the thing was on COTS boards where they'd been designed in.

RE