Here it is: https://github.com/DavidBuchanan314/6502-emu

Nothing special, but it's completely free of macros which I personally find hard to read.

I started this project so I could debug programs for my SBC more easily, so it has the same hardware (so far only the 6850 UART is actually implemented).

I also plan to implement the GDB protocol, for debugging purposes.

I haven't implemented Decimal mode yet, but ehBasic apparently runs fine without that.

Edit: Adjusted README wording to avoid sounding over-confident

Well done! I see you describe it as bug-free(!) - does that mean you've passed Klaus' test suite? Or maybe a different test suite?

It looks like memory doesn't wrap around.

Perhaps my wording was too ambiguous, the "relatively" part was also meant to refer to the bugs

But yes, I have tested it with Klaus's tests, up to the part where it tries (and fails) to run the decimal mode tests.

Could you point to where? I tried to always access withthe index as a uint16_t (which inherently wraps), or with "& 0xFFFF" when addition is involved.

ehBasic's HEX$() will malfunction without a proper decimal mode, but that's a very minor issue.

Mike B.

P.S. You are certainly welcome to use my BCD patches, with my blessing.

viewtopic.php?f=2&t=2052&p=37758&hilit=chambers#p37758

>relatively
Ah! But glad to hear you've passed Klaus' tests - the decimal tests are last, so you can only fail those by passing all the previous ones.

Ah, you were right. Some of my address-mode decoding functions didn't wrap. I think I've fixed them now.

Thanks for pointing that out.

That's interesting - some cases not yet covered by Klaus' tests. Could you raise an issue perhaps?
https://github.com/Klaus2m5/6502_65C02_ ... sts/issues
(If not, perhaps I can)

The bugs I just fixed were fairly harmless, and would only have any effect if the program counter was in the interrupt vectors (so can't really be tested against).

However, my relative adressing also failed to wrap, but it didn't actually matter because the program counter is a uint16_t (so in practice the value is wrapped) - If it wasn't that could have caused some nasty issues, so perhaps it could be added to the tests.

No harm in wrapping by using 16 bit types, I think.

There's something about stepping through the CPU in your IDE that certainly can make debugging your code a lot easier.

The problem I had later on, though, when debugging the Forth I was porting, was simply the bugs were higher level, and debugging at the instruction level, much less even small within the CPU, simply became far too much detail. I had to do stuff at a higher level. Not quite debugging Forth in Forth, but closer to that. It's times like that when you want NEXT to be primitive.