EhBasic memory locations

[Klaus2m5]

ArnoldLayne wrote:

Anyone ever encountered this?

No. You will find, that it is working in the simulator.

I would trap the syntax error message and work my way back through the stack to find what gets trashed in EhBasic. Most probably the problem is in uart_tx. No registers including accumulator and processor status should be changed!

[ArnoldLayne]

Klaus2m5 wrote:

ArnoldLayne wrote:

Anyone ever encountered this?

No. You will find, that it is working in the simulator.

Good point, because it will not simulate my BIOS bugs

Klaus2m5 wrote:

I would trap the syntax error message and work my way back through the stack to find what gets trashed in EhBasic. Most probably the problem is in uart_tx. No registers including accumulator and processor status should be changed!

Here is my uart_tx:

Code: Select all

uart_tx:
			pha

@l:			
			lda uart1lsr
			and #$20
			beq @l

			pla 

			sta uart1rxtx

			rts

I might just throw in php/pla and see if things get better something before I really start digging.

Thanks,
/thomas

[Klaus2m5]

OK, I didn't remember correctly! In your previous version you used chrout to your video adapter.
uart_tx looks OK off course. PLA restores A and NZ, C is never changed.

chrin is also constantly polled for [CTRL-C] and if no character is present should return carry clear (which you do) and A=0 (which you don't do). From the manual:

Quote:

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 would add LDA #0 to chrin_nochar.

[ArnoldLayne]

Klaus2m5 wrote:

OK, I didn't remember correctly! In your previous version you used chrout to your video adapter.
uart_tx looks OK off course. PLA restores A and NZ, C is never changed.

I want to make sure I get everything else right, hence the stripped down version to avoid any bugs in the video routines.

Klaus2m5 wrote:

chrin is also constantly polled for [CTRL-C] and if no character is present should return carry clear (which you do) and A=0 (which you don't do). From the manual:

Quote:

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 would add LDA #0 to chrin_nochar.

Hm, good point. If everything else fails, read the documentation. I added LDA #0. Also added php/plp to uart_tx.
But that doesn't seem to be the problem, I still get the same error. Further digging at the weekend then.

/thomas

[ArnoldLayne]

Something that just crossed my mind. I can't start EhBasic using the reset vector. So in order to be able to start it at the load address, I added a

Code: Select all

	jmp RES_vec

just in front of LAB_COLD, shifting the remaining code by 3 bytes.
Could that be a problem somehow?

https://bitbucket.org/steckschwein/stec ... ic.asm-450

/thomas

[barrym95838]

At first glance, the label RES_vec appears to me to be the address of a vector, not the address of valid machine code. At the risk of sounding foolish for assuming incorrectly or trying to tell you something you already know, you should only jmp indirectly through a vector, as in jmp (RES_vec).

Mike B.

[Edit: oops, RES_vec is the address of valid machine code, found here ... never-mind my foolishness ...]

[Klaus2m5]

ArnoldLayne wrote:

Something that just crossed my mind. I can't start EhBasic using the reset vector. So in order to be able to start it at the load address, I added a

Code: Select all

	jmp RES_vec

just in front of LAB_COLD, shifting the remaining code by 3 bytes.
Could that be a problem somehow?

No, I ran with the same offset. I actually copied ehbasic2 from your repository and only changed IO vectors and the few things Kowalski does not understand and it runs your indefinite "Hello" loop just fine.

Is there any background activity while EhBasic is running (timers, housekeeping, possible spurious interrupts)? Anything that could interfere with ehbasics memory locations?

Could EhBasic interfere with hardware addresses? Maybe you should move ccflag to $300.

What happens, if the UART reports a transmission error?

[ArnoldLayne]

Klaus2m5 wrote:

ArnoldLayne wrote:

Something that just crossed my mind. I can't start EhBasic using the reset vector. So in order to be able to start it at the load address, I added a

Code: Select all

	jmp RES_vec

just in front of LAB_COLD, shifting the remaining code by 3 bytes.
Could that be a problem somehow?

No, I ran with the same offset.

Ok.

Klaus2m5 wrote:

Is there any background activity while EhBasic is running (timers, housekeeping, possible spurious interrupts)? Anything that could interfere with ehbasics memory locations?

That's why I chose this approach to test the basic. Right after BIOS startup, there is nothing running. Interrupts are even disabled.

Klaus2m5 wrote:

Could EhBasic interfere with hardware addresses? Maybe you should move ccflag to $300.

No effect.

Klaus2m5 wrote:

What happens, if the UART reports a transmission error?

Lets put it this way: I didn't ask so far. I ignore any transmission error flags in uart1lsr so there is no transmission error handling. They would be ignored.

[Klaus2m5]

So it is back to plan A. On syntax error you should print the registers, stack, page 0 and the ccflag page.

After the error, does a RUN command work (is the error transient or permanent)?

If not, have you tried a RUN command after a warmstart?

Did you ever run an exhaustive RAM test?

[Klaus2m5]

I have written a little tool to dump important memory locations in EhBasic.

dump.asm

(6.89 KiB) Downloaded 229 times

In order to use the tool, you need to include it in min_mon.asm after the basic.asm include. This will keep EhBasic in the same place.

For the new checksum utility some more changes are required to min_mon.asm. The checksum must be initialized by inserting JMP chksum_init into the reset vector and the labels Code_base (in basic.asm) and Code_top must be defined:

Code: Select all

; . . . . 
      .include "basic.asm"
      .include "dump.asm"     ; *** panic dump utility
; . . . . 
RES_vec
      CLD                     ; clear decimal mode
      LDX   #$FF              ; empty stack
      TXS                     ; set the stack
      JSR   chksum_init       ; *** needed for dump.asm ***
; . . . . 
LAB_mess
      .byte $0D,$0A,"6502 EhBASIC [C]old/[W]arm ?",$00
                              ; sign on string
Code_top                      ; *** label needed for dump.asm checksum
; . . . . 

In basic.asm you need to call the dump on syntax error:

Code: Select all

; syntax error then warm start

LAB_SNER
      JMP   dump              ; *** dump trap ***
      LDX   #$02              ; error code $02 ("Syntax" error)
;      JMP   LAB_XERR          ; do error #X, then warm start

Although it is not necessary, JMP LAB_XERR is commented out to keep the program size the same.

When a syntax error occurs, you will see

The dump waits for a key to allow you to get ready to capture the screen output.

UPDATE: dump.asm now dumps strings & protects code with a checksum, dumps code if checksum fails.

[ArnoldLayne]

Awesome! Thank you very much! This is going to be helpful.

[ArnoldLayne]

Klaus2m5 wrote:

After the error, does a RUN command work (is the error transient or permanent)?

It does.

Klaus2m5 wrote:

Did you ever run an exhaustive RAM test?

Only the one the BIOS does, which is a very simple test that basically just checks if all the RAM is installed.
But I really should write a better one, because the "Syntax Error" problem went away after I installed different RAM-Chips.

[BigDumbDinosaur]

ArnoldLayne wrote:

Klaus2m5 wrote:

Did you ever run an exhaustive RAM test?

Only the one the BIOS does, which is a very simple test that basically just checks if all the RAM is installed.
But I really should write a better one, because the "Syntax Error" problem went away after I installed different RAM-Chips.

A reasonably good RAM test will be non-destructive and successively write two bit test patterns (%10100101 and %01011010 are commonly used) into every location and then do a compare. The Commodore 64 does this at power-on or reset and uses the highest address successfully tested (normally $9FFF) to calculate the RAM available to the BASIC interpreter. That is where the "38911 Bytes Free" message comes from—it's actually 38,912, but location $0401 is where BASIC text is loaded.

A more exhaustive test would also use a series of shift instructions on each location, but that could quickly become too time-consuming.

[Klaus2m5]

I am glad to hear, that you could fix the transient Syntax Error problem.

Yes, an exhaustive RAM test is too time consuming to run it as a power on self test. The BIOS basically only wants to know, wether the RAM is there or not. The typical $5A, $A5 pattern only picks up static cell failures. It does not test for data or address crosstalk or long term cell stability. You easily end up with pseudo random shifted patterns with location offset, that run for minutes just to complete a single pass.

So far I haven't found a 6502 RAM test that I liked but I must also admit, that I didn't look beyond the first few pages on a search engine.

[ArnoldLayne]

Klaus2m5 wrote:

I am glad to hear, that you could fix the transient Syntax Error problem.

I am glad that it turned out to be not an issue with the basic.
EhBasic now runs perfectly stable, even the non-UART-Version using Screen output and everything.
Time to go forward and implement LOAD and SAVE and port some C64 BASIC fun stuff!

One last issue I've got, FRE(0) reports a negative number (-24xxx something) when I give EhBasic more RAM than configured now.
These are my current memory params :

Code: Select all

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

I'd really like to set Ram-top to $e800, but FRE(0) reporting a negative number scares me.

Klaus2m5 wrote:

Yes, an exhaustive RAM test is too time consuming to run it as a power on self test. The BIOS basically only wants to know, wether the RAM is there or not.

Right. We don't even check the RAM underneath the ROM, so there is definetly room for improvement.

Klaus2m5 wrote:

So far I haven't found a 6502 RAM test that I liked but I must also admit, that I didn't look beyond the first few pages on a search engine.

At least a better one is on my list. If you like it or not - we shall see.