ehBasic on 65816

[tokafondo]

tokafondo wrote:

I'm having a problem that is, that the XMODEM transfer is VERY slow.

UPDATE:

I was using the original "dual UART" '256SXB hacker option, and then went back to the "single UART" as provided in the download.

Now the XMODEM transfer does work, but stops just before reaching 70%.

[BitWise]

You have to load a binary file into the ROM with XMODEM not an S28.

[tokafondo]

BitWise wrote:

You have to load a binary file into the ROM with XMODEM not an S28.

Ouch! It's true!! The second test I made it by uploading the .s28 instead of the .bin.

I wonder why the XMODEM didn't work in the second UART but does it (and nothing to do with my wrong upload) with the first.

Well... Anyway, I'm reworking the board because I want it to be selfpowered instead of USB powered.

Thanks again for your help and patience.

[tokafondo]

BitWise wrote:

You have to load a binary file into the ROM with XMODEM not an S28.

Now it works!! Thanks!! I have a question for you about the "hacker", but won't go off-topic and will open a different thread.

[tokafondo]

Well... I went high with all of this, and took the "Change Log.txt" of the file that Daryl/8BIT posted earlier, and applied the changes to the basic.asm file that Andrew/Bitwise posted today.

Deleted the .65C02 directive, replaced some opcodes (#XBA -> XBA and #TCS -> TCS) and compiled it with the Dev65.jar file and uploaded it to the board.

And it works. But I don't go too high, so... How can I tell if the compiled code is working in native or emulated mode?

[BitWise]

My version does a SEC/XCE at the start to force the emulation mode.

When I browsed the 65C02 source I found a few TXS instructions which will execute differently in the two modes. In emulation mode the high byte of the stack pointer is always $01 but in native mode it gets set from the high byte of the X register which is $00 if X&Y are set to 8-bits. This would leave the stack pointer on zero page and could overwrite the interpreters variables if the code recursed a lot (like in a complex math expression).

So I opted to put the processor in emulation mode for safety.

[tokafondo]

BitWise wrote:

My version does a SEC/XCE at the start to force the emulation mode.

Thanks. I also removed that, compiled again, and it boots. Now.... Is there any test to be done that would force the error you say?

Only asking as a sort of beta tester or something... anyway. Not something that I would actually need.

[floobydust]

BitWise wrote:

My version does a SEC/XCE at the start to force the emulation mode.

When I browsed the 65C02 source I found a few TXS instructions which will execute differently in the two modes. In emulation mode the high byte of the stack pointer is always $01 but in native mode it gets set from the high byte of the X register which is $00 if X&Y are set to 8-bits. This would leave the stack pointer on zero page and could overwrite the interpreters variables if the code recursed a lot (like in a complex math expression).

So I opted to put the processor in emulation mode for safety.

I just recently noticed that you were kind enough to use my CMOS version of EhBasic for porting to the 65C816 SXB. Just an FYI, I did another update to the CMOS code after Klaus released a p5 patched version. My updated CMOS version 2.22p5C has those updates, plus 100% of the Cold/Warm start code and additional code to implement LOAD and SAVE which links to my C02Monitor for Xmodem-CRC upload and download functions. The only problem porting to the 65C816 related chips would be some usage of the page zero bit manipulation instructions... all are related to the Xmodem LOAD/SAVE... 3 in total. There's also a few more performance enhancements as well... one to the CHRGET/CHRGOT equivalent routine by Mike Barry.

I'm adding the updated source code here for convenience, hope you (and others) find it useful.

basic.asm

(334.38 KiB) Downloaded 238 times