I have compiled the ehBASIC 2.22 source code and I want to run it on the Kowalski simulator.
If I set the processor to 6502 or 65c02, everything works, but when the simulated processor is 65816, the code does not execute correctly. What could be the reason?
I am attaching a recording of the simulator's behavior and the EhBASIC image file
I/O base $F000

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

I think the problem is in the simulator.
In the register window I have the following information:
A=$00,X=$FD,Y=$03,PC=$0001 S=$FF ,P=$33 Stat Program Finished.
If I run the Simulator in Animated mode, it does not respond to the RETURN key in the I/O window and loops between $C058 and $C06F.

What's interesting is that the Stack looks like it's running in native mode

It looks like E = 1, and the 65816 datasheet claims that zero-page indexing behaves the same as the NMOS 6502 in that case. And while Microsoft BASIC (which EhBASIC is derived from) does rely on the index-wrapping, that's only in the floating point division routine. So it's probably not that.

I notice that when it dies, S = $00ff, although the 65816 datasheet claims that it's always 8 bit when E = 1. There's definitely something wrong going on there. Having a look at the simulator source, I see something that might not be a bug, but does make me nervous:

If it was ctx.s-- instead of --ctx.s, that would definitely be wrong: the order of post-decrement and assignment is undefined. But pre-decrement has to happen before the evalation of ctx.s, and that has to happen before the assignment. It's probably not the cause of what you're seeing, but there are enough dark and dusty corners of this language that I wouldn't trust it.

I have never used this simulator. But I imagine it has a tracing mode of some sort. The way I got Microsoft BASIC running on the simulator for my 6502-derivative was to enable tracing, let it run until it failed, and search from the end until I found code that stopped looking obviously wrong. Whatever happened just before that was probably the culprit. In this case it's easier: search forwards from the start until S goes below $0100. That should never happen with E = 1.

It is on begining

After TXS S=$00ff
it looks like the simulation is starting in native mode but just for S .
The same efect:

I'll look at the code later today or tomorrow, BUT, I have a faint memory of the same issue when I ported EhBASIC to my SBC-3 and the stack or zero page wrapping was the issue. Again, a long time ago, but I should have it documented somewhere.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

OK, found the info on the EhBASIC forum. The issue revolves around the TSX $FF commands that are being run in native mode are setting the SP to $00FF instead of $01FF. In this thread, I posted a modified source file: viewtopic.php?p=7936#p7936 but that file is not there anymore. I'll dig around for it as soon as I can. I basically had to replace all TSX $FF with proper opcodes.

Daryl

PS link fixed

_________________
Please visit my website -> https://sbc.rictor.org/

Gregorio,

Attached is a copy of my EhBASIC v2.2 source with a change log file showing my modifications. There are mods for using LOAD and SAVE and adding SYS that returns to the host OS that you can ignore. This should be easy to port to the latest version of EhBASIC. Note that this source was assembles with TASS, not the Kowalski Simulator so I had macros for the 65816 opcodes. However, the macros are can be easily interpreted and replaced with actual 65816 opcodes.

Let me know if you have any questions.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Hi all,

I had some more time today to review the actually 65816 simulator and did find that the register display windows does wrongly show $00FF when the LDX #$FF - TXS combination is encountered in emulation mode.

A pull afterward will pull data from $00ff and increment the stack pointer to $0100.

However, a subsequent push after the stack reset will actually push the value to the right address of $01FF and decrement to SP to $01FE.

I'll bounce this all off of my 65816 SBC and then update the simulator to work accordingly.

thanks for pointing out the error!
Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

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

There are corner cases that quite possibly aren't documented. They're not useful for programmers - mostly you'd pick emulation or native and stay there - but they matter to writers of simulators who want to get things perfect.

The physical S register is 16 bits wide. When E=1 only 8 of them are visible to the programmer. Nothing is said about what happens to the others, but it is testable.

Start with E=0, X=0. LDX #$1234, TXS. S will now contain $1234.
Now set E=1, and PHA. Where does that byte get written? I would expect it goes to $0134, but $1234 is plausible.
The low 8 bits of S are now $33, and the high 8 bits are unknown. They're unknowable as long as E=1, so set E back to, make sure X=0, and TSX. What is now in X? I would believe either $1233 or $0133.

If instead we'd switched to E=1 then straight back to E=0 without using the stack, what would be in S? $1234 or $0134?

Another test: set E=1, LDX #0, TXS, PHA. The write will be to $0100, and the low 8 bits of S will now be $ff. Set E=0,X=0, TSX, and what is now in X? I would believe either $01ff or $00ff.

The question is where "the stack is always in page 1" gets applied: when S is written to (both TXS and the update part of pushes and pulls), or when it is read (the address generation part of pushes and pulls)? Or maybe both.

(There's another question: if you start with E=0,X=0, then switch to E=1, the datasheet says that X=1. Does that apply only to the value read from it, or to the value stored in the flip-flop? When we return to E=0, does X remain 1? I'm thinking with my CPU implementer hat on - it feels easier to force X=1 when E=1 by ORing those signals on the output, and leaving the value in the flip-flop as it is)

I tested a lot of those cases on my 65816 but darned if I can recall the results. Looks like I'll be testing again this weekend.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

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

Daryl,
Thanks for the EhBasic2.2 source code.
For now I have added the Monitor function in my simulator and I can get the register view after each instruction.
Unfortunately I had to add an additional serial port for this function and I only have one serial2USB, and now I am waiting for the shipment of an additional Ser2USB converter.

I would like to check why EhBasic2.22 does not work in the 65816 simulation. As soon as the shipment with ser2USB reaches me, I will take care of it.
And this is what the logs from my simulator look like, the first item is ADDRES, next opcode + 3 next bytes, Status FLAG slightly changed order, rej BA , X,Y,SP,DIR,B

I made a screenshot where the error occurs.
$C398 TXS
On the left side the processor is 65c02, on the right 65816.