Denial

wimoos wrote:Just like the Zp $03-$06 and $FB-FE are never used in CBM Basic or the Kernal, there is no instance of a SED. So a CLD would not be needed....

I know that.

Don't you think that doesn't preclude that user programs might use decimal mode?

That consideration is especially important, as the free memory display is supposed to run with essentially arbitrary user programs in the foreground.

Actually, we both face another slight problem: $03 .. $06 and $FB .. $FE are now effectively unusable for all foreground processes. Their contents ought to be put on stack during the ISR like this:

I'd agree with including CLD in the code, as an ISR doing arithmetic should ensure the CPU decimal mode is set as it expects, rather than assuming the rest of the system (and any other user code running in it) always uses the same setting.

However, pushing those ZP bytes to the stack seems a little OTT; the VIC system isn't a multithreaded re-entrant environment, so there's no requirement to guarantee 'stack frames' in the sense that memory should retain consistency between different user-mode applications. Arguably, since BASIC isn't using them, the likelihood is that any other application making use of them is machine code - in which case, this ISR has probably already been usurped (either by another ISR blowing it away, or by something that doesn't want any ISR running anyway, like a game).

Plus the speed benefit gained by using these ZP bytes is entirely neutralised by the stack operations, and the space savings from using ZP addressing are also rather undone by the stacking code.

The purpose of the routine is to display *BASIC* free RAM, while e.g. the screen format stays the same.

So the foreground program will most probably be a BASIC program, with the odd ML-routine here and there to speed things up. In these ML routines some decimal arithmetic will maybe happen and the ISR will then display bogus information. When the ML routine has finished, the ISR will display correct information again.

I know that CLD is only a single byte instruction, and I hadn't thought about it, but risc*impact in my opinion is very, very low. And if you really want to speed things up, you maybe start your ML routine with a SEI.

Regards,

Wim.

SEI is really only necessary when you're either doing something that alters the IRQ vector, or running a process that is highly time-critical and must not be interrupted by an ISR.

For a background process like this, you'd want an SEI in the initialisation step because you're twiddling the vector; you then don't need it in the injected ISR, because the CPU has already done it for you as part of the hardware IRQ logic.

However, you do want a CLD in your ISR if you're doing arithmetic because some other program may have legitimately executed a SED and you've interrupted it before it got a chance to do a CLD of its' own. The CPU will of course put the Decimal flag back the way it was when the IRQ process completes and it pops the PSW off the stack - so this mythical other program carries-on in Decimal mode quite happily, and your ISR arithmetic behaves as you expect.

I agree with FD22 entirely. And I thank the rest of the thread for uncovering the use of zp 3..6, too.

For those concerned, here's an updated data loader for the streamlined version at 673, *including* the CLD, but leaving out save/restore for the ZP bytes. I could strip off another few bytes: bit 8 of $9003 does not contain bit 9 of the screen start address in the VIC bank, but bit 0 of the raster counter ... my mistake. A simple 'LDA #$30:STA $9003' suffices:

Great job guys. Thanks for picking this idea up and running with it. Lots of good info here.