6502.org

Posted: **Wed Nov 16, 2016 9:24 am**

Hi there,

I am just starting to really dive into EhBasic by porting it to my homebrew 65c02 computer (Steckschwein).
Right now, I am wondering if Ram_base can be above the address where EhBasic resides in memory.

Our rudimentary OS (SteckOS) always loads binaries to $1000. Below that are os specific locations, sd card block buffer and such.
So I assembled EhBasic with $1000 as start address, Ram_base happened to be $0300. In this case, Basic worked fine.
Then I tried $4000 as ram base, to use the memory behind EhBasic but EhBasic crashed right at the start. I traced the crash to somewhere in the neighbourhood of LAB_20DC before I gave up.

So maybe anyone with more experience can point me in the right direction? It it at all possible to use EhBasic that way without turning everything inside out?

Thanks,
ArnoldLayne

Posted: **Wed Nov 16, 2016 3:30 pm**

Just tried your memory layout in Kowalski and it worked!

When I give it too little RAM I end up with the same problem. What is the value of the Ram_top constant in basic.asm and what do you enter in response to "Memory size ?"

Posted: **Wed Nov 16, 2016 7:19 pm**

Klaus2m5 wrote:

Just tried your memory layout in Kowalski and it worked!

Ok, so there is hope. Thanks for that.

Klaus2m5 wrote:

When I give it too little RAM I end up with the same problem. What is the value of the Ram_top constant in basic.asm and what do you enter in response to "Memory size ?"

Ram_top is $b000.
I do not get far enough to be able to enter a memory size. The crash happens before.

I think further testing with Kowalski might be a good idea.

Posted: **Thu Nov 17, 2016 1:05 am**

Just to ensure we are on the same page, are you using version 2.22?

Here are my notes for when I used EhBASIC on my SBC's:

ccflag changed from $0200 to $0300
Ibuffs changed to = VEC_SV+8 ; start of input buffer
Ram_base changed from $0300 to $0400

You may want to check ccflag and Ibuffs to see if they may be causing your trouble.

If all else fails, post your source file so we can take a look.

Daryl

Posted: **Thu Nov 17, 2016 8:10 am**

8BIT wrote:

Just to ensure we are on the same page, are you using version 2.22?

Yup, it's 2.22. I could have made that clear from the beginning, of course.

8BIT wrote:

ccflag changed from $0200 to $0300
Ibuffs changed to = VEC_SV+8 ; start of input buffer
Ram_base changed from $0300 to $0400

You may want to check ccflag and Ibuffs to see if they may be causing your trouble.

Good point. I changed ccflag from $0200 to $0290 because my IO-area is from $0200-028f.
I did not to anything with Ibuffs AFAIR. Will check.

8BIT wrote:

If all else fails, post your source file so we can take a look.

Will do. Thanks!

/thomas

Posted: **Thu Nov 17, 2016 10:57 am**

I changed my source according to your layout (IO_AREA=$200, ccflag=$290, Ram_top=$B000). The simulator is still happy with it.

Do you see "6502 EhBASIC [C]old/[W]arm ?"?

Could you please post your min_mon.asm.

There is only little code before "Memory size ?" is displayed, so it should not be too difficult to debug.

Posted: **Thu Nov 17, 2016 11:08 am**

Klaus2m5 wrote:

I changed my source according to your layout (IO_AREA=$200, ccflag=$290, Ram_top=$B000). The simulator is still happy with it.

Ok, still hope then. I can't be too far from the solution. Maybe it's a SteckOS-thing after all.

Klaus2m5 wrote:

Do you see "6502 EhBASIC [C]old/[W]arm ?"?

Yup. As soon as I enter c oder w EhBasic crashes. Looks like it's outputting spaces.

Klaus2m5 wrote:

Could you please post your min_mon.asm.
There is only little code before "Memory size ?" is displayed, so it should not be too difficult to debug.

https://bitbucket.org/steckschwein/stec ... ck_mon.asm

Posted: **Thu Nov 17, 2016 2:55 pm**

Oh well, I can confirm now that it is a bug in EhBasic. I stepped my way through the cold start routine until the message "Memory size" is setup. It is copied to $FFF2! Sure enough if I turn on write protect for $b000-$ffff the simulator stops with "Protected area write attempt detected" So it worked for me, because there is RAM at $fff2. For you there is ROM and you won't see the message.

The problem seems to be here:

Code: Select all

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

                              ; string in utility area, move to string memory
      TYA                     ; copy length to A
      JSR   LAB_209C          ; copy des_pl/h to des_2l/h and make string space A bytes
                              ; long
      LDX   ssptr_l           ; get string start low byte
      LDY   ssptr_h           ; get string start high byte
      JSR   LAB_2298          ; store string A bytes long from XY to (Sutill)

; check for space on descriptor stack then ..
; put string address and length on descriptor stack and update stack pointers

LAB_RTST
      LDX   next_s            ; get string stack pointer
      CPX   #des_sk+$09       ; compare with max+1
      BNE   LAB_20F8          ; branch if space on string stack

                              ; else do string too complex error
      LDX   #$1C              ; error code $1C ("String too complex" error)
LAB_20F5
      JMP   LAB_XERR          ; do error #X, then warm start

It works when Ram_base is lower than the message in memory. When it is higher, it doesn't work in systems with ROM because the proper end of RAM has not yet been set (strings grow from top down).

I have to wrap my head arround this and see, if I can come up with a fix.

Posted: **Thu Nov 17, 2016 3:12 pm**

Interesting.

Actually, I do have RAM there (ROM at boot, but its disabled after kernel load to enable read access to the underlying RAM, much like $01 on the C64). So my kernel jumptable/interrupt vectors get overwritten. That explains a lot.

I might work around this by omitting the "memory size"-question completely and go with a fixed memory size. Which I am planning to do anyway.

Thank you very much.

/thomas

Posted: **Thu Nov 17, 2016 3:48 pm**

A quick fix:

Code: Select all

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

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

Code_base         = $1000     ; *** RAM above code Patch ***
Ram_base          = $4000     ; start of user RAM (set as needed, should be page aligned)
Ram_top           = $B000     ; end of user RAM+1 (set as needed, should be page aligned)

; This start can be changed to suit your system

      *=    Code_base         ; *** RAM above code Patch ***

; BASIC cold start entry point

;..............................................................................

LAB_20DC
      STX   Sendh             ; save string end high byte
      LDA   ssptr_h           ; get string start high byte
; begin *** RAM above code Patch ***
      .if   Ram_base < Code_base
        CMP #>Ram_base        ; compare with start of program memory
      .else
        CMP #>Code_base       ; compare with start of program memory
      .endif
; end   *** RAM above code Patch ***
      BCS   LAB_RTST          ; branch if not in utility area

Posted: **Thu Nov 17, 2016 4:31 pm**

Klaus2m5 wrote:

Oh well, I can confirm now that it is a bug in EhBasic.

Good catch Klaus!

If Lee were here, he'd call it an "undocumented feature." I always got a kick out of that!

RIP Lee!

Posted: **Thu Nov 17, 2016 5:51 pm**

That worked!

Thank you!

Posted: **Thu Nov 17, 2016 6:19 pm**

Hm, I shouldn't get "Out of memory Error" when entering $4000 as Memory size, right?
Entering $8000 gives me "16383 Bytes free"

Still quite a bit to do.

Posted: **Thu Nov 17, 2016 6:21 pm**

EhBasic counts memory size from 0 - even if it can't use it.

Posted: **Mon Nov 21, 2016 8:59 am**

Hi, I am still getting weird problems even with

Code: Select all

Code_base       = $b000     
Ram_base	= $0400	
Ram_top		= $b000

Running the well known BASIC killer app
10 PRINT "HELLO"
20 GOTO 10
for a few minutes provokes a sudden "Syntax error in 10", which is weird.

Code: Select all

Hello 
Hello 
Hello 
Hello  0
Syntax Error in line 10
Ready
LIST

10 PRINT "Hello "
20 GOTO 10 

Ready

Anyone ever encountered this?
Here is the exact code I am testing: https://bitbucket.org/steckschwein/stec ... /ehbasic2/

I am also going to test this in the simulator later today to determine if my hardware is acting up.

/thomas

6502.org

EhBasic memory locations

EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations

Re: EhBasic memory locations