6502.org

The C command is a great idea. I built the BRK handler with the intention of using it for debugging. I would overwrite an opcode with BRK to verify expected vs. actual register & flag contents. But I usually just replaced the BRK with the original code, moved the BRK to another test location, and reran from the start. Having the ability to continue is an added feature, but best used with BRK's included into the source.

Daryl

A?

.. followed by 'RM', I guess.

...or followed with MD.

@Daryl, we tend to build tools that fit our individual SOPs. I tended to populate my code with printfs (back in the day), so populating it with BRK is just an extension of that

The 6502 implementation here is a little less flexible than the Z80 one. With the latter, you can jump back to the monitor, use the memory examine command to modify the stored register values, then hit C to continue execution i.e. do some what-ifs.

So who won the CPU architecture wars? Yes, it's ARM

Any well-designed 6502 monitor will implement similar functionality. For example, in Supermon64, if a program was interrupted with BRK it can be resumed with the G (run program) command, which will reload the context that existed when BRK was encountered. It has nothing to do with the MPU and everything to do with the programmer.
I didn't know MPUs were at war with each other.

Unfortunately, as you've seen, there are some topics here which it is impossible to mention, even in jest, without getting a "discussion" about them which detracts from the conversation.

It would be interesting to see a couple of stock FIG Forths going head to head on the Z80 and 6502. Out of the box, they should both be "reasonable" implementations (in terms of efficiency), the architecture should be pretty much identical, and the benchmark can be written in high level Forth and ported, much like the BASIC.

Wouldn't be perfect, by no means, as a Forth probably tests only a specific subset of the CPUs capability, but at least in terms of "cycle to cycle" performance for "similar tasks", I think a FIG Forth would have less margin for disparity.

But then, you're probably, in the end, just testing NEXT, FETCH, STORE, stack handling, and some basic math primitives.

Still, might be enlightening.

I can tell you from personal experience with MS BASIC (on the TRS-80 M1 L2 and the early PET and Apple ][) that the perceived difference was quite noticeably in favor of the 65xxers, even with 32-bit floats on the former (by default) vs. 40-bit floats on the latter two.

Mike B.

So back to my question: I'd like to strip out the NMI/IRQ code.

Are there dependencies (beyond the CTRL-C handler) that will result in a less stable EhBASIC?

As far as I can tell from my experience in modifying the interrupt system in EHBasic there are no "deep roots" of the interrupt handler in EHBasic. Just keep in mind that if you remove or change EHBasic keywords, a binary SAVE / LOAD will not be compatible across EHBasic versions.

I took advantage of the long July 4th weekend over here to check out things and improve the overall EhBASIC experience using the 6502 CPU Board for the RC2014.

The first thing I realized was that I'd failed to check into GitHub the latest code. Done: https://github.com/ancientcomputing/rc2 ... 02/ehbasic

The second thing I did was to enable the UART receive interrupt (on the 16C550) with characters dumping into a 63-byte buffer and then implement manual RTS handling according to pre-defined low and high water marks.

While doing this I realized that EhBASIC is really crappy with zero page usage. It was basically clobbering my buffer pointers. I didn't want to cannibalize the zero page locations that the Monitor/Debugger was using since the UART buffer will be used by the Monitor (monitor commands and Intel Hex uploads). So I ended up moving the buffer pointers to Page 3. The code ends up being relatively inefficient (absolute addressing etc) and longer but it seems to work...

The resulting Monitor/Debugger + EhBASIC is in GitHub here: https://github.com/ancientcomputing/rc2 ... 50_irq.rom

The upside of the use of the interrupt driven and buffer-backed serial input is the following:
I now can run a 1MHz 6502 at 115200 baud with no errors with Intel Hex uploads with the Monitor or BASIC source code uploads with both EhBASIC and MS BASIC.

Previously, I had to configure my terminal emulator to use character delays.

"Crappy" might be a bit harsh ... maybe "greedy"? Who was there first, anyway?

A clash over 65xx zero-page real-estate is certainly not without ample precedent. When you try make two or more non-trivial applications play well with each other in 65xx land, you have to keep a very close eye on their zero-page usage or you will wind up with some nasty bugs (some of which may be very intermittent). Of course, you already knew that, or at least you do now!

Mike B.

It all depends on how you define "crappy." The Commodore 64 used virtually all of zero page for BASIC and the kernel, leading only five or six zero page locations that were guaranteed to not be disturbed.

What? You are using a 1 MHz CPU with 115200 baud?

Let me do the math for you. 115200 baud means a character every 10 bits, so 11520 chars/s. The CPU has one million cycles per second. So there is 86.8 cycles per character.

In this 86.8 cycles you want to interrupt for each character and stuff it into a buffer. Then Ehbasic comes along and fetches the character from the buffer and needs to do something usefull with it while there are more characters coming in.

I hope you see, what is going wrong here. Of course EhBASIC was never meant to deal with massive program uploads like that. It is fast enough to catch what you type on a terminal though, even at 115200 baud. LOAD & SAVE was meant to be binary just stuffing memory sequentially and not having to tokenize every line and stuffing it into the middle of an existing frame (NEW helps in that case).