Cannot get past "Memory Size ?"

[floobydust]

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.

[cbmeeks]

floobydust wrote:

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.

Where did you remove that code?

I have other uses for IRQ and NMI too.

[floobydust]

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...

basic.asm

(322.45 KiB) Downloaded 270 times

[BillO]

Quote:

Why/how would EhBASIC know the keyboard input is blocking?

The routine gets called...and it waits for valid input to be pressed. Wouldn't EhBASIC be halted during that time?

Either way...not sure why this wouldn't work. Once a key is pressed, A contains the ASCII code and it should be setting the carry flag correctly. Or, am I missing something?

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.

Quote:

Code: Select all

KEYBin:
        ;; GET KEYBOARD CHAR
        JSR     kbinput                 ; Waits for ASCII key press.
                                        ; A should now have ASCII character
                                        ; (waits for a non-zero ASCII code)
        BEQ	LAB_nobyw		; branch if no byte waiting
	SEC				; flag byte received
	RTS

LAB_nobyw:
	CLC				; flag no byte received
        RTS

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.

[floobydust]

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.

Code: Select all

;Character Input routines
;CHRIN_NW uses CHRIN, returns if a character is not available from the buffer with carry flag clear
; else returns with character in A reg and carry flag set. CHRIN waits for a character to be in the
; buffer, then returns with carry flag set. Receive is IRQ driven/buffered with a size of 128 bytes
CHRIN_NW	CLC	:Clear Carry flag for no character
					LDA	ICNT	;Get character count
					BNE	GET_CH	;Branch if buffer is not empty
					RTS	;and return to caller
;
CHRIN			LDA	ICNT	;Get character count
					BEQ	CHRIN	;If zero (no character, loop back)
;
GET_CH		PHY	;Save Y reg
					LDY	IHEAD	;Get the buffer head pointer
					LDA	IBUF,Y	;Get the character from the buffer
					INC	IHEAD	;Increment head pointer
					RMB7	IHEAD	;Strip off bit 7, 128 bytes only
;
					DEC	ICNT	;Decrement the buffer count
					PLY	;Restore Y Reg
					SEC	;Set Carry flag for character available
					RTS	;Return to caller with character in A reg
;

[barrym95838]

cbmeeks wrote:

Code: Select all

KEYBin:
        ;; GET KEYBOARD CHAR
        JSR     kbinput                 ; Waits for ASCII key press.
                                        ; A should now have ASCII character
                                        ; (waits for a non-zero ASCII code)
        BEQ	LAB_nobyw		; branch if no byte waiting
	SEC				; flag byte received
	RTS

LAB_nobyw:
	CLC				; flag no byte received
        RTS

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

Code: Select all

KEYBin:                 ; GET KEYBOARD CHAR
      jsr   kbinput
      cmp   #1          ; CC means no key yet
      rts

[floobydust]

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:

Code: Select all

Input vector points here:
    JSR KBSCAN ; Check to see if a key was pressed
    BEQ NO_KEY ; If no key pressed, exit
    JSR KBINPUT ; Get key pressed and process to ASCII
    SEC ; Set carry flag to show a character is in A reg
    RTS ; return to caller
NO_KEY
    CLC ; ensure carry flag is clear showing no character
    RTS ; return to caller

[BillO]

Quote:

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

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!

[barrym95838]

floobydust wrote:

; KBSCAN - Scan the keyboard for 105uS, returns 0 in A if no key pressed.
; Return ambiguous data in A if key is pressed.

Code: Select all

    JSR KBSCAN ; Check to see if a key was pressed
    BEQ NO_KEY ; If no key pressed, exit

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.

[floobydust]

barrym95838 wrote:

floobydust wrote:

; KBSCAN - Scan the keyboard for 105uS, returns 0 in A if no key pressed.
; Return ambiguous data in A if key is pressed.

Code: Select all

    JSR KBSCAN ; Check to see if a key was pressed
    BEQ NO_KEY ; If no key pressed, exit

Your code makes two assumptions which may or may not be safe (but probably are):
1) The Z flag is directly related to the contents of A.
2) The "ambiguous data" always includes a cleared Z flag.

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

Code: Select all

KBSCAN         ldx   #$05              ; timer: x = (cycles - 40)/13   (105-40)/13=5
               lda   kbportddr         ; 
               and   #$CF              ; set clk to input (change if port bits change)
               sta   kbportddr         ; 
kbscan1        lda   #clk              ; 
               bit   kbportreg         ; 
               beq   kbscan2           ; if clk goes low, data ready
               dex                     ; reduce timer
               bne   kbscan1           ; wait while clk is high
               jsr   kbdis             ; timed out, no data, disable receiver
               lda   #$00              ; set data not ready flag
               rts                     ; return 
kbscan2        jsr   kbdis             ; disable the receiver so other routines get it
; Three alternative exits if data is ready to be received: Either return or jmp to handler
               rts                     ; return (A<>0, A=clk bit mask value from kbdis)
;               jmp   KBINPUT           ; if key pressed, decode it with KBINPUT
;               jmp   KBGET             ; if key pressed, decode it with KBGET
;
;

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.

[whartung]

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.

[8BIT]

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

[Klaus2m5]

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.

Quote:

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

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