6502.org

That's a good bit of detective work!

Good catch, Daryl! I will eventually (when I return home in about 6 weeks) add this to my EHBasic bugs and quirks text. I sure hope this is the last Ibuff bug.

I traced the code that happens after the RTS of that routine and the first access to the Accumulator was to load it with a new value in both cases, so its safe to use LDA without the PHA/PLA wrapper.

Daryl

It was actually pretty easy using the Kowalski Simulator. After seeing that the line input was processing right, I figured I could trace a LIST command to see why it was not working.

I got it to the point that I typed LIST after entering Line 10 and then went into debug mode. I injected the CR and then just single stepped the code until I got to a point where I saw the Bpntr get INC'ed to $0500. That jumped out as obviously wrong, so testing that code with different values of Ibuffs was very quick. It took longer to write up the post that it did to find the problem.

I have attempted other bug hunts with much less successful results. It did feel good to find this one. Lee did a great job of commenting the code, which also helped.

Daryl

Thanks Klaus for maintaining these. It will hopefully help others not stumble on the same things.

Daryl

Thank you for your further investigation!

Thanks for figuring this out.

Here's another one

Write a simple FOR I=0 TO 1000, PRINT I, NEXT I loop.

Run it and while it's running (and printing out the values of I), press a key. The program will stop and freeze.

Is that expected?

No, and trying both with line number 10 and RUN and also in Direct mode, it did not stop for me except by doing Ctrl-C, as designed. Can you post your VEC_IN routine and your current memory configuration?

thanks

Daryl

Okay. I figured it out. It was an error on my part (aka false alarm).

I'd left interrupts on the UART enabled. Left over code from the Z80 BIOS (that has a 255-char buffer etc).

I'm really sorry for that.

No worries! I'm glad you found it.

Daryl

Just curious, but why did you want to change Ibuffs from it's default anyway?

Because the comment in the source code is "Ibuffs can now be anywhere in RAM". So I took it to be a porting requirement. Also irq_vec wasn't defined in basic.asm. So you'd hit a build error if you're building a stand-alone BASIC binary.

Anyway, I've "checked in" the forked code at GitHub (https://github.com/ancientcomputing/rc2 ... 02/ehbasic). This is based on the source hosted by Klaus.

Other than the "port" itself plus Daryl's patch, I've added the following:
1. Cold and warm start entry points. This is to make the behavior similar to the old Nascom/MS BASIC that is used in the RC2014 kit.
2. Hardcoded BIOS calls for console i/o
3. Added SYS keyword to exit back to the monitor. I think Daryl is using SYS for his port, so I wanted to stick to that. Otherwise the RC2014 BASIC uses the "monitor" keyword (which actually jumps to reset...).
4. Some clarity (in comments) on what variables need to be on what page in memory

Oh and I'm thinking about removing the IRQ/NMI code. Are there any side effects e.g. core BASIC functionality that is dependent on the IRQ/NMI code?

@Daryl, I've used your monitor "lite" codebase to build a simple monitor for the RC2014 6502 board. While I've reused a number of the subroutines, I've changed the user interface a fair bit to produce that same/similar behavior as my Z80 monitor for the RC2014. I've also added a (C) continue command to the BRK handler so that you can actually continue program execution after examining the registers. This is a little simpler than what I implemented for the Z80; primarily because there's essentially only one stack on the 6502. Whereas the Z80 can have a Monitor stack and an application one. So you can hit a breakpoint, go out to the full Monitor, and look at/change memory contents... (Note: not intending to start a CPU religious war here. We know who won: it starts with A ).

I ran Robert Sharp's prime number program to benchmark the 6502+EhBASIC vs the Z80 with Nascom/MS BASIC on the RC2014.

The latter runs at 14.7456MHz on a custom Z80 board. The 6502 runs on the same RC2014 system but at 4MHz using a CMD part.

To find all prime numbers to 199, the Z80 gave 10.62 seconds (iPhone stopwatch), whereas the 6502 gave 10.82 seconds.

Barring differences in BASIC implementation, this is actually quite consistent from a MIPS perspective: with a 6502 being capable of 4MIPS and the Z80 at 14.7456MHz doing ~3.7 MIPS (4 clocks per instruction) along with somewhat more efficiency etc.

This sort of comparison highlights what we knuckle-draggers have known for years: the 6502 is very efficient at what it does. The Z80: not so much. I won't even go into the interrupt latency angle...

The way to look at this is to compare the number of memory accesses. The clock speeds of the two CPUs are different because of the different microarchitectures.

I remember when the T9000 was struggling to reach even 15MHz, one of the senior management wondered if we could market it as being 60MHz on the grounds that it ran on a four-phase clock. For sure the emphasis on clock speed in marketing favoured architectures like the Z80 and x86.

Running an application benchmark is a very good way to compare performance - just have to be careful that both versions are coded with roughly equal levels of expertise.