BASIC with character LCD

[NickH93]

Hello everyone

I was going to use EHBasic on my finished board, but it seems like everyone who is using it uses it with an ACIA and a terminal.

Is there a ported version with supports a character LCD? Or is porting this interpreter for an LCD possible?

Thanks!
-Nick

[8BIT]

EhBASIC uses two calls for IO
- A non-halting input call to check for input, Carry clear if no character and Carry set with character in A if there is.
- A character out call for sending characters.

All you would need is to write the LCD driver code and point EhBASIC to it for output (and take care of data input).

Daryl

[NickH93]

Awesome. Thanks. I'll get working on it ASAP.

[GARTHWILSON]

I have code in various forms for driving the common intelligent character LCDs at http://wilsonminesco.com/6502primer/LCDcode.asm in the 6502 primer. Be particularly careful to follow the reset method there, to get a reset that always works. It came from when we were trying to get an LCD going at work in the late 1980's and finally got this info in an ap. note from the manufacturer. (I know 1987 was a long time ago for many people here, but it has been nice that the same controllers have been used for 30+ years now, giving stability.) The "Displays" page of the primer is at http://wilsonminesco.com/6502primer/displays.html .

[NickH93]

Well, I have it running...sorta. When I do a command, it freezes. I can write programs, but the second I execute them it freezes.

I don't know if anyone has ever run into this? Otherwise I think it may just be an issue with the way I handle keyboard input.

[8BIT]

Does Ctrl-C work? Can you post your IO routines?

Daryl

[NickH93]

At

Code: Select all

V_INPT

KEYSCAN: 
         LDA VIAORB ; LOAD THE VALUE OF VIA PORT B. KBD DATA READY LINE IS HERE
         CMP #@00000111 ; IS DATA READY LOW? 
         BEQ LOADKEY ; YES, LOAD KEY DATA
         JMP KEYSCAN ; NO, KEEP SCANNING DATA READY
LOADKEY: LDA VI2ORA ; LOAD ACC WITH ASCII DATA FROM KEYBOARD
         RTS ; GO BACK TO WHERE SUB WAS CALLED FROM              	 

So this places the key data in A and returns to where it was called from. The CMP is kind of convoluted, but basically all bits are output expect the Data Ready input, bit 3. 0 and 1 are for the LCD, kept high beforehand, and then bit 2 is irrelevant, but kept high for the soundchip I have.

Below is my output routine

Code: Select all

V_OUTP

         JSR ECHO ; PLACE ACC ON LCD
         RTS ; RETURN TO WHERE OUTPUT WAS CALLED FROM

...................................

ECHO: 
      
      STA VIAORA ; STORES ACCUMULATOR ON LCD DATA LINES
      LDA #@00000111 ; LCD CHARACTER MODE, ENABLE HIGH. VIAORB SHOULD ALREADY HAVE THIS DATA BEFOREHAND, BUT JUST FOR SAFETY'S SAKE I ADDED IT 
      STA VIAORB
      LDA #@00000101 ; LCD CHARACTER MODE, ENABLE LOW, READING DATA
      STA VIAORB
      JSR DELAYS ; DELAY, ALLOWING LCD TO PROCESS COMMAND
      LDA #@0000111 ; LCD CHARACTER MODE, ENABLE HIGH AGAIN. ALSO SETS VIA READY FOR KEYBOARD USE AGAIN
      STA VIAORB
      RTS
      
DELAYS: NOP ; GENERAL PURPOSE DELAY. ONLY USES NOP TO GIVE A DELAY WITHOUT DISRUPTING ANY REGISTERS. 
        NOP
        NOP
        NOP
        NOP
        NOP
        NOP
        NOP
        RTS

NOP delay....yeah I know. I just wanted to see if my original delay with the X register made a difference, but it didn't.

Sorry if my code looks....lacking or bad or anything. Only been doing this for a month or 2. Haha.

[GaBuZoMeu]

These LC displays are sometimes beasts. They claim to be compatible, but they aren't. Slightly different timing requirements and fine working code doesn't work anymore.

You should read very carefully the datasheet (that one what is exactly for your display) to dig out the information of how long the delays should be for the various commands. IIRC 'clear display' and 'home' (place cursor to first pos in first line), take longer than others.

Use long delays (start with something around 50ms). Once it works you can shorten them.

Next you should try output only. This way you can circumvent problems with char input (if any). Just try to print a sequence of characters. If it works sometimes, then you can try to figure out why only sometimes (perhaps only after power_off_on ?). This could be because something within the initialization is wrong or missing or done still too fast.

Some of these displays have controllers that can work with larger displays. Frequently 16x2 displays have a controller that is designed to work with 20x2 or even 20x4 lc-glasses. Then it is no error, if the first characters appear and then it seems to get freezed - you are writing into a display region that simply cannot be displayed.

I'm sure you will be successful

[leepivonka]

I think V_INPT should not wait for a char, just return the C flag to indicate Acc contains a char.

For example:

Code: Select all

V_INPT
         LDA VIAORB ; LOAD THE VALUE OF VIA PORT B. KBD DATA READY LINE IS HERE
         AND #@00001000   (Is this the correct mask for kbd ready?) ; IS DATA READY LOW?
         CLC
         BNE V_INPT9
         LDA VI2ORA ; LOAD ACC WITH ASCII DATA FROM KEYBOARD
         SEC
V_INPT9
         RTS ; GO BACK TO WHERE SUB WAS CALLED FROM

I think your code is looking quite good for 2 months!

[GARTHWILSON]

Regarding the LCD: If you do what I show in my sample code linked above, you won't have problems. I have lots of sizes and brands of intelligent character LCDs here, and they all work with the same code. Since we got that first one going in about 1987, I have never had a problem with any of them. Not a one. But you do need that extra stuff in the reset routine that looks unnecessary.

[NickH93]

leepivonka wrote:

I think V_INPT should not wait for a char, just return the C flag to indicate Acc contains a char.

For example:

Code: Select all

V_INPT
         LDA VIAORB ; LOAD THE VALUE OF VIA PORT B. KBD DATA READY LINE IS HERE
         AND #@00001000   (Is this the correct mask for kbd ready?) ; IS DATA READY LOW?
         CLC
         BNE V_INPT9
         LDA VI2ORA ; LOAD ACC WITH ASCII DATA FROM KEYBOARD
         SEC
V_INPT9
         RTS ; GO BACK TO WHERE SUB WAS CALLED FROM

I think your code is looking quite good for 2 months!

Thanks so much!

This code works as intended, but it is lagging a little bit as expected.

At any rate, it is more of the same. If I do a "PRINT" without anything after, it prints a CR, just like you'd expect. Is when I give it a value to print, or a string, etc. Then it freezes and I cannot control-C out of it. It doesn't like to process values or strings, it seems.

I run BASIC from my monitor, but I don't think my monitor would affect it. BASIC should just overwrite any of MY zero page usage from the monitor, right?

I don't know if it has to do with the way the buffers and everything are set up in ram. It needed me to set RAM base and buffer location before assembling. Perhaps I am setting these wrong?

I am only using a 16x2 LCD, so I know that I will be printing some data in a region of the screen controller that I can't see. I am hitting enter until the screen loops back around before confirming that BASIC is in act freezing. I ordered a 40x2 LCD which should be here soon. That will allow me to see everything, though I know BASIC is crashing.

I will use that LCD code, thank you Garth. That will rule out the LCD as any source of an issue. Thanks!

[leepivonka]

Have you changed V_INPT to not wait for a character from the keyboard?

From the EhBasic source:
;Input: This is a non halting scan of the input device. If a character is ready it should be placed in A
; and the carry flag set, if there is no character then A, and the carry flag, should be cleared.

I think the getting stuck problem is because your earlier V_INPT routine will not return until a keyboard character is available.
EhBasic calls V_INPT periodically while it's running a program to check for ctrl-c. If V_INPT waits for keyboard character instead of returning "no character available" when there is no keyboard character available, the running BASIC program will run part of a statement, wait for a keyboard character, run part of a statement, wait for a keyboard character, etc.
With enough keyboard characters entered the program should eventually run.

[NickH93]

So I currently do have it set where if no character is present, it clears carry and returns. It doesn't keep scanning the keyboard. If a key is pressed, it's loaded into the acc, carry set, and return. So it doesn't loop waiting for just a key press like before.

Still though, no luck. A few times it printed a ? on crash. Also, when I run it from monitor, I'm not asked cold or warm start. Does this matter?

[8BIT]

Does it ask you for memory Size before in starts? That's the cold boot route.

Daryl

[NickH93]

8BIT wrote:

Does it ask you for memory Size before in starts? That's the cold boot route.

Daryl

It does, yes. Also, another weird bug. PRINT "TEST" gives me a mismatch error. I should wait until I have 40 column screen to see everything. Or just port this for my ACIA in the mean time.