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!

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

Good point, because it will not simulate my BIOS bugs



Here is my uart_tx:


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

Thanks,
/thomas

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

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

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


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

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

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

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

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?

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

Ok.


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


No effect.



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.

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?

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

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

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:

In basic.asm you need to call the dump on syntax error: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 seeThe 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.

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

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

It does.


[/quote]
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.

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

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 :


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


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


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