What is wrong with HALT instruction ?!

norecess · Post by **norecess** » Sat Apr 26, 2008 3:58 am

Hi,

When I insert a HALT instruction as 1st instruction of my main() function, the application freezes. Why ?

Thank you,
Arnaud (still targeting +cpc)

norecess · Post by **norecess** » Sat Apr 26, 2008 4:05 am

Hum, just found this on your forum..

http://www.z88dk.org/forum/viewtopic.php?id=205

It looked similar to my problem. I added a EI before my HALT instruction, and.. it worked !

Does it means there are some impredictable DI executed somewhere ?

Thank you,
Arnaud

Post by **alvin** » Sat Apr 26, 2008 7:20 am

norecess wrote:Does it means there are some impredictable DI executed somewhere ?

I can see in the cpc_crt0 (the start up code which calls the program's main) that interrupts are disabled. This was probably done because the cpc's interrupt service routine causes trouble with z88dk's library functions (does it save all registers? does it expect certain registers to contain fixed values?).

I think any fiddling with interrupts should be removed from all z88dk library code and leave the decision to enable/disable interrupts to the programmer. The spectrum crt0 does not disable interrupts, eg, even though the spectrum interrupt routine expects a fixed value in the IY register pair. That's why it isn't uncommon to see a "di" in main() in C programs targetted at the spectrum and/or the installation of a user-supplied interrupt routine to field interrupts.

z88dk's libraries assume all registers are fair game -- this makes the library code as optimal as possible -- however most libraries don't make use of IX/IY/EXX/AF' which cause trouble on some platforms. I think this is the correct approach, along with the provision of alternative code for platforms (like the zx81) that absolutely must reserve some registers for the system.

Aside from possibly the crt0s, the only library code in z88dk at the moment that contains di/ei is in the 1-bit sound generation, which should be fixed up to remove the di/ei.

Back to the point, yes the di is there as mentioned above, and I think all instances of it should be removed from z88dk in the next release.

Post by **stefano** » Mon Apr 28, 2008 12:52 pm

I'm not sure it is so easy to keep interrupts enabled; one of the latest stability fixes I put in was an added di at the end of the firmware interposer: it happened that sometimes the interrupts were enabled back by the ROM routines and the CPC crashed.
I agree it is quick'n'dirty but it did the job, see line 156:

http://z88dk.cvs.sourceforge.net/z88dk/ ... iew=markup

Anybody is encouraged to experiment and remove instructions at line 47, 94 and 156. Since still there is no support for 1 bit sound on the CPC, all the interrupt related instructions (but the ones used in firmware) should be in that file.

The 1-bit sound plays gracefully only when interrupts are disabled, the only exception is the bit-tick function, thought to create a buzzing effect for car engines, etc..
It has the side effect to halt the timers for a while and to force the interrupt to be enabled on exit; suggestions ? The "bit_close_ei" function might be adapted to avoid re-inabling IRQ on some conditions.

Another interesting point is about custom interrupts: should we provide a generic wrapper and bind the programmers to it ?
Multi-target developement could take benefit, but probably skilled guys would prefer not to have it. On the other side it might be necessary to transparently support memory paging and to save critical registers keeping the interrupt running..

Post by **alvin** » Tue Apr 29, 2008 9:59 pm

stefano wrote:I agree it is quick'n'dirty but it did the job, see line 156:

http://z88dk.cvs.sourceforge.net/z88dk/ ... iew=markup

Anybody is encouraged to experiment and remove instructions at line 47, 94 and 156. Since still there is no support for 1 bit sound on the CPC, all the interrupt related instructions (but the ones used in firmware) should be in that file.

I'm thinking there must be a better way to do this. What I don't like about it is that it locks cpc programs into one way of doing things and that is run your C program with interrupts disabled or constantly insert EIs whenever a firmware call is made. I much prefer having the programmer completely aware that firmware calls have special requirements and having the program do necessary setup prior to making the firmware call. This is more natural rather than having things hidden away.

The 1-bit sound plays gracefully only when interrupts are disabled, the only exception is the bit-tick function, thought to create a buzzing effect for car engines, etc..
It has the side effect to halt the timers for a while and to force the interrupt to be enabled on exit; suggestions ? The "bit_close_ei" function might be adapted to avoid re-inabling IRQ on some conditions.

Yeah, again I think the 1-bit sound shouldn't touch the interrupts at all. In the CPC case the sound routines will re-enable interrupts and cause a crash. However, programmers may also want to run their programs with interrupts disabled in which case disabling interrupts is not necessary and enabling them at the end of the sound output could be harmful. People may also want to run a sound routine from within an interrupt service routine and not have interrupts reenabled from inside that routine, especially in true im2 environments.

So I think it should be the program's responsibility to disable interrupts if necessary to get clean sound output.

Another interesting point is about custom interrupts: should we provide a generic wrapper and bind the programmers to it ?
Multi-target developement could take benefit, but probably skilled guys would prefer not to have it. On the other side it might be necessary to transparently support memory paging and to save critical registers keeping the interrupt running..

I don't think it's necessary to bind anyone to one way of doing things. Maybe the best way to handle the CPC is to provide by default an interrupt that will jump into the CPC's regular interrupt routine after saving registers and restoring them properly. A compile time flag could specify that this code is not inserted which leaves the responsibility of dealing with the CPC firmware up to the program.

norecess · Post by **norecess** » Wed Apr 30, 2008 11:43 am

Hi there,

I don't know about other platforms, but on CPC interrupts are enabled by default.

To me, I think a DI before developer's main() implementation is evil

Have a good day,
Bye

Arnaud

Post by **stefano** » Wed Apr 30, 2008 3:14 pm

Here's a first feedback on my own experiences enabling/disabling the interrupt.

I first disabled all the interrupts, and run the "chessboard" demo.
It crashed after about 1 second.

Then I tried to fix the firmware interposer with a couple of DI/EI, and the demo went on with no errors.
So I tried with ansitest.c, and it crashed on the half way.

Same happens with other programs, so there must be some register we're forgetting to save, or perhaps a safer interrupt routine is necessary. I'll keep you updated on progresses.

About the sound lib (and others): the interrupt stuff is in a common place, so it isn't difficult to add the required flexibility; what about a customization flag ?

It could be:
-startup=1 (default) safer interrupt handler in place and automatic DI/EI for sound, Sprite Pack, and whatever; generic hook for interrupt driven code.
-startup=2 no DI/EI handling, minimal safe interrupt handler, (preserve registers before BIOS CALLS ?)
-startup=3 rough mode, no nothing, probably default firmware dependent funtions won't work

Opinions ?

norecess · Post by **norecess** » Wed Apr 30, 2008 3:26 pm

Actually, is the problem platform specific ?

Post by **dom** » Wed Apr 30, 2008 4:08 pm

I suspect that this is a platform specific issue, but there are a few things we can do to mitigate it, for example any ei/di that are required can restore the state of interrupts correctly afterwards, see the end of http://z88.svn.sourceforge.net/viewvc/z ... iew=markup for some code that does it.

This way, we can keep our nice sounding 1 bit sound when run outside of the interrupt, and it will also allow it to run inside the interrupt as well (not that it would sound very nice if it was run from there).

Post by **stefano** » Sat May 03, 2008 12:48 pm

I'm amazed it is possible to detect whether the interrupt is enabled or not !
If it works we solved the sound related part of the discussion (it will be useful for custom load/save routines too).

The main CPC related problem still isn't solved, anyway. But hopefully it shouldn't be so difficult (we did it with the ZX81 which had serious limits involving the NMI, almost every special register and other hardware related tricks, so I'm sure we'll fing a way).

So far I got stable programs with interrupts enabled by making the interrupt subroutine do nothing (ei/reti).
The current z88dk libraries still seem to work without problems (keyboard, i/o/, graphics..), and it seems not to be longer necessary to save IY. If a programmer would need to make the interrupts to point to his own custom code he can do it; I could provide a flag to exclude such patch.
Could it be enough ?

Post by **stefano** » Sat May 03, 2008 4:49 pm

Updating what I said just above, this new trick permits to avoid to preserve AF' too, and the generic math functions work fine, too as well as the 6128 specific ones; I had problem with the 464 version, but it could be because of the emulator I'm using (WinCPC) which has a weird platform configurator.

Post by **stefano** » Mon May 05, 2008 2:18 pm

All, I just updated the CVS with various fixes for the CPC platform.
Hopefully it solves the HALT issue too.

norecess · Post by **norecess** » Mon May 05, 2008 2:25 pm

OK. I would like to check this.. unfortunately, I'm more a SVN user, hehe. Is there a night-build released somewhere ? Thank you.

Post by **stefano** » Mon May 05, 2008 6:04 pm

To make it easy you could just overwrite your copy of the {z88dk}/lib/cpc_crt0.asm file with this one:
http://z88dk.cvs.sourceforge.net/*check ... c_crt0.asm