BASIC with character LCD

[leepivonka]

Quote:

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.

Quote:

Also, when I run it from monitor, I'm not asked cold or warm start. Does this matter?

Cold start is jumping to LAB_COLD (at the beginning of the EhBasic ROM code).
Warm start is jumping to LAB_WARM (at $0000 after EhBasic initializes).

Here is a sample session of a minimally modified EhBasic I ran in a 6502 (really 65816) simulator:

Code: Select all

E:\65816>\65816s\release\65816s ehbas.lst
65816S Mar  6 2017 22:39:02
65c265 mode on
A=0000 X=0000 Y=0000 S=0180 EnvMXdIzc D=0000 B=00 A004B9F2 00c000 ldy #04
.g   (starts 6502 execution)


Memory size ?

48383 Bytes free

Enhanced BASIC 2.22

Ready
PRINT


Ready
PRINT 2*3
 6

Ready
PRINT "abcd"
abcd

Ready
A$="abCD"

Ready
PRINT A$
abCD

Ready
10 FOR I=1 TO 10
20 PRINT I
30 NEXT
RUN
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10

Ready



A=0002 X=0000 Y=0002 S=01FB EnvMXdIzc D=0000 B=00 4A900302 000210 lsr a
.d300,37f
000300: 00 10 03 0A 00 81 20 49 C1 31 20 AD 20 31 30 00
000310: 18 03 14 00 9F 20 49 00 1E 03 1E 00 82 00 00 00
000320: 49 00 84 30 00 00 AA AA AA AA AA AA AA AA AA AA
000330: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
000340: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
000350: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
000360: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
000370: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
.dbf80,c00f
00BF80: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
00BF90: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
00BFA0: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
00BFB0: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
00BFC0: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
00BFD0: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
00BFE0: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
00BFF0: AA AA AA AA AA AA AA AA AA AA AA 34 61 20 31 30
00C000: A0 04 B9 F2 E0 99 00 02 88 10 F7 A2 FF 86 88 9A
.
g

Quote:

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?

EhBasic uses RAM at:

• most of $0000..$00ff; EhBasic will overwrite anything previously there (hopefully your monitor doesn't need these values & doesn't overwrite EhBasic values while EhBasic is running)
• most of $0100..$01ff; hardware stack; you can use some stack space, just don't overwrite deeper stack entries.
• $0200..approx $0270;
• Ram_base..Ram_top-1;

Ram_base thru Ram_top should be entirely in RAM & shouldn't overlap any other use.
Try entering 1000 at the "Memory size" prompt; this tells EhBasic to use only Ram_base thru approx 1000 .

Quote:

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'm worried that a lot is scrolling off before you see it. EhBasic tends to finish it's replys with a blank line then "Ready" line then another line to collect the next command.

Quote:

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.

Ok, good! I wasn't sure you had fixed that.

Quote:

Still though, no luck. A few times it printed a ? on crash

If nothing seems to help yet, we can look for ways to divide the problem into smaller pieces & conquer them. Some ideas are:

• Is the EhBasic code getting into the ROM without error? Is ROM working, properly selected & addressed? Try reading some randomly chosen bytes from the ROM & compare them to the build listings.
• Is RAM working, properly selected & addressed? Try writing some bytes at addresses scattered throughout the range, then reading all of them back & verifying they didn't change. Maybe add a "memory test" function to your monitor that fills a memory block with a pseudo-random sequence of values, then verifies all the bytes are still the pseudo-random sequence.
• Write a routine to send more characters fast to the LCD. Does it have any unexpected behavior with fast sequences, writing off the end, multiple lines, etc. ?
• When EhBasic crashes: Look at the 6502 address lines - resistors & LEDs or a logic probe or a voltmeter will do. Are they pretty constant, like the program is in a tight loop? What code is around that address?
  If you can single-step the 6502, step it through several instructions - what is it doing?

[Klaus2m5]

NickH93 wrote:

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.

You must restore the original content of the accumulator on RTS of your output driver.

[NickH93]

Unfortunately I cannot single step. I will check with my voltmeter when I can to see what it is doing.

I have now set my RAM within in these parameters, but still no luck.

As far as I can tell, my RAM is good. I haven't implemented a test in my monitor, but I have manually keyed in programs into RAM with my monitor and ran them from RAM with success. (LED Blinks, etc). I've also written random values throughout and checked them to be OK. The programs remain in memory through resets.

The ROM checks out okay when checking with the monitor. Matches the assembled code 100%

The monitor runs programs by doing a JMP to specified address through indirect addressing. This should disable the monitor completely, correct?

So here's where I am now. I have the accumulator restored after my echo routine before returning from sub, just as mentioned, but still get type mismatch errors.

It seems that it just cannot process values or variables.

For example. Writing this

Code: Select all

10 PRINT
20 GOTO 10

will infinitely write carriage returns to the screen, like it should.

but if I write

Code: Select all

10 PRINT 25
20 GOTO 10

this will cause a crash.

Also trying to manually add memory size will cause a crash. Is there a way I can force a memory size before running?

So in review:

RAM is good, as far as I can tell. ROM is 100% okay. LCD screen is properly driven, works just fine with my monitor and BASIC. ECHO restores acc before RTS. This is accomplished by first storing the ACC at a location outside of user RAM, and then LDA with that address before doing an RTS. PLA/PHA instructions cause it not to work properly. (Nothing gets displayed)

Input routines are as follows: Check to see if there is a key press, if not, CLC and RTS. If so, load key data, SEC, RTS.

RAM is located from $0000-$3FFF, ROM is at $8000-$FFFF. Basic is located at $9000

Here is my configuration.

Code: Select all

LAB_STAK		= $0100	; stack bottom, no offset

LAB_SKFE		= LAB_STAK+$FE
					; flushed stack address
LAB_SKFF		= LAB_STAK+$FF
					; flushed stack address

ccflag		= $0300	; BASIC CTRL-C flag, 00 = enabled, 01 = dis
ccbyte		= ccflag+1	; BASIC CTRL-C byte
ccnull		= ccbyte+1	; BASIC CTRL-C byte timeout

VEC_CC		= ccnull+1	; ctrl c check vector

VEC_IN		= VEC_CC+2	; input vector
VEC_OUT		= VEC_IN+2	; output vector
VEC_LD		= VEC_OUT+2	; load vector
VEC_SV		= VEC_LD+2	; save vector

; Ibuffs can now be anywhere in RAM, ensure that the max length is < $80

Ibuffs		= $3500+$14
					; start of input buffer after IRQ/NMI code
Ibuffe		= Ibuffs+$47; end of input buffer

Ram_base		= $1000	; start of user RAM (set as needed, should be page aligned)
Ram_top		= $3000	; end of user RAM+1 (set as needed, should be page aligned)

; This start can be changed to suit your system

	*=	$9000

Thanks everyone for all the help. I've just run out of ideas at this point.

I may have set Ibuffs wrong, as it wouldn't assemble with the value "IRQ_vec+$14" so I just chose an arbitrary spot to place this.

Again, I should also wait until I have my 40-character LCD, but that may be awhile.

Sorry for all of the questions.

[GaBuZoMeu]

Try

10 A = 10
20 PRINT A
30 A = A - 1
40 IF A > 0 GOTO 20
50 END

Perhaps (I have no EhBasic) you need to write

40 IF A > 0 THEN 20

Ah, by the way, what happens when you key in 2 or more lines and then key in (at the beginning of a new line)

LIST

Does it list the program you keyed in so far?

[barrym95838]

NickH93 wrote:

... ECHO restores acc before RTS. This is accomplished by first storing the ACC at a location outside of user RAM, and then LDA with that address before doing an RTS. PLA/PHA instructions cause it not to work properly. (Nothing gets displayed)

That's worrisome (assuming that you were doing the PHA and PLA in the correct order and locations). Are you actually saying that replacing the STA TEMP with a PHA and the LDA TEMP with a PLA results in an immediate failure? If you can't trust your system stack, not much else should be assumed to be trustworthy.

Mike B.

[NickH93]

barrym95838 wrote:

NickH93 wrote:

... ECHO restores acc before RTS. This is accomplished by first storing the ACC at a location outside of user RAM, and then LDA with that address before doing an RTS. PLA/PHA instructions cause it not to work properly. (Nothing gets displayed)

That's worrisome (assuming that you were doing the PHA and PLA in the correct order and locations). Are you actually saying that replacing the STA TEMP with a PHA and the LDA TEMP with a PLA results in an immediate failure? If you can't trust your system stack, not much else should be assumed to be trustworthy.

Mike B.

You know, it would probably help if I reset the stack before running basic...dumb DUMB mistake.

Now that I added a stack reset at the start of BASIC (My monitor was leaving things in the stack before running new code), I can successfully use PHA and PLA now. Just added your typical LDX #$FF, TXS

I'm going to retry my past configurations that would run commands with no values after them, but with this stack reset in place. I'll see what happens.

It's always some little thing I missed.

[Klaus2m5]

NickH93 wrote:

I may have set Ibuffs wrong, as it wouldn't assemble with the value "IRQ_vec+$14" so I just chose an arbitrary spot to place this.

You should be aware that there is a bug in EHBasic if you place the input buffer above Ram_base. From https://github.com/Klaus2m5/6502_EhBASI ... txtps://github.com/Klaus2m5/6502_EhBASIC_V2.22/blob/master/bugsnquirks.txt[code]2. String handling when the string is in the input buffer.

When a string is entered via the input buffer (Ibuffs - Ibuffe) in Ehbasic it
is transient because it gets overwritten by the next input. In this case it
needs to be copied to the string area. In all other cases the string remains in
place and only a pointer needs to be set to the string location.

There is a bug in EhBASIC to determine where the string is.

LAB_20DC
STX Sendh ; save string end high byte
LDA ssptr_h ; get string start high byte
CMP #>Ram_base ; compare with start of program memory
BCS LAB_RTST ; branch if not in utility area
This does not work, if RAM_base is below the input buffer or EhBASIC itself is
below RAM_base. The fix requires the input buffer not to cross a page boundary.

LAB_20DC
STX Sendh ; save string end high byte
LDA ssptr_h ; get string start high byte
; *** begin RAM above code / Ibuff above EhBASIC patch ***
; *** replace
; CMP #>Ram_base ; compare with start of program memory
; BCS LAB_RTST ; branch if not in utility area
; *** with
CMP #>Ibuffs ; compare with location of input buffer page
BNE LAB_RTST ; branch if not in utility area
; *** end RAM above code / Ibuff above EhBASIC patch ***
So I recommend to put the input buffer to a fixed safe location like $380 or apply the patch.

[NickH93]

So, I've set Ibuffs in the appropriate place and still nothing. If I do PRINT "A", the whole system crashes and reboots. Even to the point where I can see the LCD dim, which suggests its ground it being affected. I don't know how normal this is, or isn't.

The only thing I'm starting to suspect now is either an issue with the way I'm trying to port it (very likely), as my monitor runs just fine, and according to it, my memory map shows everything I expect it to, so I think my decoding is working (First example in the 6502 primer

The other issue would be my RAM. I noticed I have 70ns RAM, but at 1mhz clock speed, would this be an issue? There is a 50ns version which would be a direct replacement and need no change in the wiring. Is this something I should look into?

I'm also going to build a single step circuit so I can find out exactly what's happening.

[GaBuZoMeu]

The speed of your RAM is no issue - you don't need to change that! (If it were an issue - why should your monitor work then?)

If you key in a line starting with a number - does BASIC crash?
If you then type LIST - does a listing appear or does it crash?

Did you try to use BASICs POKE function?

POKE(ADDRESS, VALUE) places VALUE (8 bit) into memory location ADDRESS.

As you know how to display a character out of your monitor you could mimic the necessary steps by a sequence of POKEs.

You only have to figure out what the decimal addresses of your display are and whether EhBasic accepts addresses above 32767 (decimal) (only if your display is mapped somewhere above $8000).

A few BASICs don't accept values bigger than 32767 as addresses, some accept &"ABCD" as a legal notation in hex.

Sure there will be some documentation about that - or someone here could clarify this.

[NickH93]

GaBuZoMeu wrote:

The speed of your RAM is no issue - you don't need to change that! (If it were an issue - why should your monitor work then?)

If you key in a line starting with a number - does BASIC crash?
If you then type LIST - does a listing appear or does it crash?

Did you try to use BASICs POKE function?

POKE(ADDRESS, VALUE) places VALUE (8 bit) into memory location ADDRESS.

As you know how to display a character out of your monitor you could mimic the necessary steps by a sequence of POKEs.

You only have to figure out what the decimal addresses of your display are and whether EhBasic accepts addresses above 32767 (decimal) (only if your display is mapped somewhere above $8000).

A few BASICs don't accept values bigger than 32767 as addresses, some accept &"ABCD" as a legal notation in hex.

Sure there will be some documentation about that - or someone here could clarify this.

I thought so about the RAM. Just wanted to make sure.

If I key in a line number, BASIC will accept it, even if it contains a command which otherwise would make it crash. If I list, it will show the program in memory. So far I've only done this with programs that are 3 or 4 lines long. When I get back home (still have to work on the holiday ), I will give the POKE statement a shot. My LCD is at $6000, so it shouldn't be an issue. I'll see how that goes.

I'm waiting on a UART to USB, so my plan is to use the ACIA output/input routines which are widely available from many builds and successful. I'll use those and use a terminal. If it works, I'll know the problem is in my IO routines. If not, I'll look elsewhere. I'm going to get all the parts for single stepping, so I'll be able to see that as well.

Thanks everyone for all the help.

[GaBuZoMeu]

NickH93 wrote:

I thought so about the RAM. Just wanted to make sure.

If I key in a line number, BASIC will accept it, even if it contains a command which otherwise would make it crash. If I list, it will show the program in memory. So far I've only done this with programs that are 3 or 4 lines long. When I get back home (still have to work on the holiday ), I will give the POKE statement a shot. My LCD is at $6000, so it shouldn't be an issue. I'll see how that goes.

I'm waiting on a UART to USB, so my plan is to use the ACIA output/input routines which are widely available from many builds and successful. I'll use those and use a terminal. If it works, I'll know the problem is in my IO routines. If not, I'll look elsewhere. I'm going to get all the parts for single stepping, so I'll be able to see that as well.

Thanks everyone for all the help.

Wow you can do a LIST!! That means parts of Basic are working as they should. I can hardly imagine why Basic should work different when do a listing or printing variables or strings during runtime. But perhaps some of our specialists know more about these details?

If you use
10 POKE(24576,65)
20 END
RUN
as example and if at $6000 you can store a character so it will become visible then this should give you an 'A' on your display.

Don't use something like
10 DI = 24576
20 A = 65
30 POKE(DI,A)
40 END
because if you have trouble with variable storage this way would crash as well. Once you can POKE characters into your display you may try the same using variables instead.

Multiple POKEs in series may not work - just because the display requires some delay between two characters.

Good Luck!

[GARTHWILSON]

NickH93 wrote:

So, I've set Ibuffs in the appropriate place and still nothing. If I do PRINT "A", the whole system crashes and reboots. Even to the point where I can see the LCD dim, which suggests its ground it being affected.

That sounds like the power supply voltage is dipping because of a heavy load presented by bus contention.

[GaBuZoMeu]

GARTHWILSON wrote:

NickH93 wrote:

So, I've set Ibuffs in the appropriate place and still nothing. If I do PRINT "A", the whole system crashes and reboots. Even to the point where I can see the LCD dim, which suggests its ground it being affected.

That sounds like the power supply voltage is dipping because of a heavy load presented by bus contention.

This could be possible. I think NickH93 said he is using example 1 of your primers. If he has more than one I/O device reading from a 'wrong' address might cause bus contention.

How does Basic knows where MEMEND is? Is it part of the setup or is it trying to detect non RAM by itself? Then such 'odd' address may be used causing trouble..

[whartung]

But it seems clear that he's able to display text, from BASIC, on the LCD, as evidenced by being able to LIST the program.

So, reading the keyboard, and printing out text appears to be solved at a primitive level, there just seems to be some issue with PRINT or string handling, which sounds like a corrupted EhBASIC listing in some way.

[NickH93]

It's also possible I have the decoding wrong to begin with.

Because come to think of it, I remember reading at the bottom of the first example in Garth's primer, I see that each device would have a unique range where an address ISN'T mirrored anywhere else. If I'm understanding this right, then my devices should be able to be addressed at these locations:

Code: Select all

  62256	SRAM:  $0000-3FFF  (binary 00xxxxxxxxxxxxxx)  (There are no 16Kx8 SRAMs, so here we use half of a 32Kx8.)
  6522	VIA1:  $4010-401F  (binary 010000000001xxxx)
  6522	VIA2:  $4020-402F  (binary 010000000010xxxx)
  6522	VIA3:  $4040-404F  (binary 010000000100xxxx)
  6551	ACIA1: $4080-4083  (binary 010000001000xxxx)
  6551	ACIA2: $4100-4103  (binary 010000010000xxxx)
  6551  ACIA3: $4200-4203  (binary 010000100000xxxx)
  27256 ROM:   $8000-FFFF  (binary 1xxxxxxxxxxxxxxx)

This scheme doesn't work. Just this one does.

Code: Select all

  IC:   address: (the "$" means "hexadecimal," or base-16)
  RAM   $0000-3FFF (only 1/2 of 32KB available.  Writing to I/O also writes to the upper half of RAM, but
                                                 you can't read it back since it would interfere with I/O.)
  ROM   $8000-FFFF (all 32KB available)
  VIA1  $6000-600F
  VIA2  $5000-500F
  VIA3  $4800-480F
  ACIA1 $4400-4403
  ACIA2 $4200, 4204, 4208, 420C
  ACIA3 $4100, 4104, 4108, 410C
  (and up to four more I/O ICs could be added) 

So if I'm reading it correctly, they're placed in both locations, it's just that the first set are unique, and would not output to anywhere else. The second list would, but runs the risk of writing to multiple locations, etc.

I wouldn't be surprised. I had to redo this decoding stuff a lot.

I'm using a 74HCT132, is there an issue with this chip for decoding? Or based on this, is my decoding just wired up wrong. Entirely possible. Reading 4000, for example, the memory there just reads "40" from $4000 to $40FF, 41 at $41FF, and so on.