A small plea for assistance after a couple of days calling my computer some rather naughty names.
After adding j/s support to 'AtticBug' I was hoping that it would be a quick 5 minute job to slot the same into MazezaM.
How wrong could I be ?
During gameplay there is an ever-so-slight drop off in the speed due to reading the j/s but then I tried adding it to the title page in a 'press any key or fire to start' fashion.
I managed a small work-around which runs as follows:(pseudo-code alert!)

.inputloop
OSBYTE &F ;flush keyboard buffer
OSBYTE &78 ;check for key and
LDA &EC :STA ... ;store for safe-keeping
OSBYTE &80 ;check for joystick input
IF j/s input=TRUE THEN
replace stored k/board value (probably 0) with equivalent key value
ELSE
IF no input detected, GOTO inputloop

The trouble with this is that quite often the k/b input is not detected even though the j/s works perfectly.
If I loop back missing out the k/b flush then the program acts as if a key has been pressed on the second pass.
Any enlightened guidance would be greatly appreciated.

Kian

I don't think OSBYTE &78 is the way to go. The AUG says that this call is "Write current keys pressed information", and that it takes the X and Y registers as inputs which will be written to memory locations &ED and &EC, i.e. no keyboard scanning is done at all.

I think an appropriate call would be OSBYTE &7A (keyboard scan from 16 decimal), which returns the internal number of the key pressed in X. No need to look at location &EC or anything.

Also, you don't need to clear the keyboard buffer (with OSBYTE &0F) every time you read the keyboard in this way - but you should do it before you read anything from the keyboard buffer, e.g. OSWORD 0 or OSBYTE &81.

Thanks, Rich.
It now works like a charm.
One odd side-effect though. I had to shorten the 'slide' sound effect as it now mysteriously lasted about twice as long as it used to.
Probably a result of having been using OSBYTE &78 before.

Cheers,
Kian