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:




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 .


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.


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


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?

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

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

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


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

but if I write

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.




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.

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?

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.

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 ... quirks.txtSo I recommend to put the input buffer to a fixed safe location like $380 or apply the patch.

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

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.

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.

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!

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

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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

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.

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:



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


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.