I ported EhBASIC to a CHOCHI board (http://forum.6502.org/viewtopic.php?f=10&t=2644).

I got it working, but it's eating a lot of keystrokes - I have to type very, very slowly. It is not really usable... Is it normal? My board is running at 45MHz, so I can't imagine what it would be like at 1MHz...

Any thoughts?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I haven't tried EhBASIC, but that doesn't seem the least bit normal to me, or someone would have brought it up long ago. I don't have the answer, but perhaps you could clarify for someone who might ...
By very slowly, do you mean < 1 cps?
Are output and computation speed affected as well?
How much bus-snooping are you equipped to do?

Mike

Do you have another app you can test the keyboard with, like a ROM monitor ? Is it just not working in EhBASIC, but works elsewhere ?
I'm running my own system at 20MHz with EhBASIC and it seems to work fine.

Also, the keyboard, if it's a PS2 style keyboard, has specific timing requirements. For my keyboard controller you have to tell it the clock frequency so it can calculate the timing periods.

Is the carry flag being set/cleared properly ? (EhBASIC requires this).

What does your V_INPT routine look like ?

_________________
http://www.finitron.ca

Last year I experimented with EhBasic (with a few mods for 65C816) running at 10mhz and it worked fine. There were no unusual char. I/O delay problems. FYI, there is a subroutine that gets relocated to zero page for speed improvements. Not sure if that could affect your core though.

OK, the problem is solved but points to an issue with EhBASIC that is worth knowing about.

EhBASIC requires a non-blocking input check. The routine is required to set carry flag if there is a key. I was assuming that the carry bit is enough and the contents of the accumulator don't matter. That resulted in long (1S) intermittent delays that made typing nearly impossible.

I updated my routine to clear the accumulator and set the carry flag if no character is available. That cleared up the problem.

Upon cursory examination of the code, it looks like there are many places that check for carry and re-enter the loop. I am not sure why the accumulator must be clear...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Enso,

That is not quite right. It does require a non-blocking (no wait for key press loop) routine. The routine should exit with Carry clear if there was no key pressed. The contents of the Accumulator are not tested and do not need to be cleared. If a key was pressed, then it is loaded into the Accumulator and the routine exits with Carry Set.

If you are setting the carry and clearing the Accumulator, you are essentially telling EhBASIC that you are pressing a lot of "Null" keys. It will do nothing but that is not the desired effect.

Here is my typical input code for a non-blocking routine using a serial interface:



I was able to shift the data ready bit into the C flag directly, making the code efficient.

Here is an example of a 6551 routine:



I hope this helps!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I made an error in my last message. I clear carry and the accumulator. Just clearing carry didn't seem to be enough - I was getting those delays.

My final code is clearing the accumulator

It's possible that your status register is 0 by the time you shift resulting in cleared accumulator as well...
It seems unnecessary, but it made the delay go away. I'll investigate next time I get a chance.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I'm not clearing the accumulator and it seems to work with just clearing C. The accumulator is set to -1 by my charget routine if there is no character.

_________________
http://www.finitron.ca