Well, perhaps you have some conflicts with zero page usage between your code and EhBasic. As for the startup, I removed the prompt for memory size, I just use the base and end pointers... test the memory from start to end and set the values accordingly if the RAM test is successful. The option to declare a smaller memory size for certain scenarios can be useful, but for my SBC setup, I have 30KB RAM free from 32KB, so I prefer to let all of it be available to basic.

In any case, you'll still need a non-waiting character input routine for EhBasic to work properly.

On another note, the interrupt handling sections in EhBasic is broken (according to Klaus) so I removed all of that code as well, as my BIOS uses both IRQ and NMI for interrupt-driven UART transmit/receive/timer and the NMI for a panic routine. I didn't see any need to attempt to integrate it for my purposes, so I removed it from the source.

_________________
Regards, KM
https://github.com/floobydust

Where did you remove that code?

I have other uses for IRQ and NMI too.

_________________
Cat; the other white meat.

Well, I've made numerous changes to the code... it's a single source file now. It also uses many of the newer CMOS instructions/addressing modes and requires a CMOS processor to execute. I also consolidated all of the page zero space and moved the chrget/chrgot routine to ROM which saves some space. To use it, all you need to do is add the character in and out vectors in the source, re-assemble and your done... no additional monitor section. I also added an EXIT comand which points to an exit vector... I just jump to my Monitor warm entry point. Source is also modified to assemble and link with WDC Tools... attached it here if you would like to try it. Have fun...

_________________
Regards, KM
https://github.com/floobydust

EhBASIC is always checking for a break sequence even when code is running. If the input routine halts, then execution will halt the first time it goes looking to see if there has been a break request.


That bit of code looks good as long as your kbinput routine is guaranteed to return with the right values in the accumulator. I did read through it yesterday, but was unable to make that determination.

_________________
Bill

The KBINPUT routine is part of Daryl's code to use a PS/2 style keyboard with a 6522 VIA. Per his code, that routine will wait until a character is received from the keyboard. Daryl's code has another routine (KBSCAN) which spends 105 usec scanning the port for input... and then returns with "0" in the A reg if nothing was pressed.

Technically, (CBMEEKS) should be able to use the KBSCAN routine as part of the EhBasic input routine along with the KBINPUT routine to have a no-waiting keyboard input routine.... but alas, he noted that it's not working as described. I haven't looked at enough of Daryl's code on that one... but there's also the possibility that there's some page zero conflicts that might be tripping things up.

The BIOS I wrote for my SBC uses interrupt-driven code for a UART console/timer. As a result, I only need to check in the input buffer count value to see if an unread character is in the buffer and set/clear the carry flag as needed. This is really quick in code.

_________________
Regards, KM
https://github.com/floobydust

I know that it's completely psychotic to optimize non-working code, but my mental illness refuses to let me leave this itch unscratched:

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Well, below is a snippet from Daryl's code explaining the routines that are available for external calls:

;********************************************************************************************
; Software communicates to/from the keyboard and converts the received scan-codes
; into usable ASCII code. ASCII codes 01-7F are decoded as well as extra
; pseudo-codes in order to acess all the extra keys including cursor, num pad, function,
; and 3 windows 98 keys. It was tested on two inexpensive keyboards with no errors.
; Just in case, though, I've coded the <Ctrl>-<Print Screen> key combination to perform
; a keyboard re-initialization just in case it goes south during data entry.
;
; Recommended Routines callable from external programs
;
; KBINPUT - wait for a key press and return with its assigned ASCII code in A.
; KBGET - wait for a key press and return with its unprocessed scancode in A.
; KBSCAN - Scan the keyboard for 105uS, returns 0 in A if no key pressed.
; Return ambiguous data in A if key is pressed. Use KBINPUT OR KBGET
; to get the key information. You can modify the code to automatically
; jump to either routine if your application needs it.
; KBINIT - Initialize the keyboard and associated variables and set the LEDs
;*******************************************************************************************

Based on the above, the routine that EhBasic should call could be something like this:

_________________
Regards, KM
https://github.com/floobydust

That bit of code actually works. I use the same code myself (different input routine though), and now I can save some bytes. Thanks Mike!

_________________
Bill

Your code makes two assumptions which may or may not be safe (but probably are):
1) "No key pressed" always sets the Z flag.
2) The "ambiguous data" always includes a cleared Z flag.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Good point... but here's the KBSCAN routine from Daryl's code... exit specifically loads the A reg with #$00 and then returns.



In any case, it needs to be tested before it's declared as working... it was just a quickie code example.... worst case one can always do an explicit CMP #$00 before the branch. I still prefer my own approach using an ISR to manage the console I/O buffers and simply check to see if a character is in the buffer... I know it works, as I've been running EhBasic on my SBC for several months now.

_________________
Regards, KM
https://github.com/floobydust

I don't know about EhBASIC, but MS BASICs had an "INKEY$" routine that scanned the keyboard from BASIC.

You would call that in a loop to read keys, and you would use it for things like games and what not.

I just noticed you are using my VIA keyboard reader. That code needs to be modified to work with EhBASIC. EhBASIC's input routine uses the X register as an index. My KBscan code also uses the X register without preserving it. You'll need to save and restore the X register in my code. May need to do the same with the Y register... I did not dig into the EhBASIC code far enough to see if it also uses Y.

Daryl

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

By the way: $DF is used both as IrqBase (EhBASIC) and LCDPh (PrintString in mon.asm). This should not cause a problem however as IrqBase gets initialized by EhBASIC after its use by PrintString.

That is GET <var[$]> in EhBASIC.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5