Hi!



Yes, was a little typo.

But note that in the standard text mode, the available cycles for the CPU are only 63.8% of the total cycles, given an equivalent 1.14MHz.

I told Arne that I would do a Forth version of the 'Prim' function version of the benchmark which does not use the sqrt function. Before doing that I did do a sqrt function for Forth in assembly which is based on 'Mr. Woo's Abacus Algorithm' (the sqrt2 word I did in Forth previously). I've copied the results of all tests below. The Foth code is at the bottom. The sqrt in assembly was of course the fastest but it you compare the sqrt2 and Prime versions it gives you an idea of the speed difference between the sqrt done in Forth and the Prime version.

I am quite certain my Forth code is not great, but it works and I'm getting quicker at producing code that actually works!

@Jeff_Birt: thank you again, very interesting results. Never thought about an integer sqrt

@dmsc: an impressive type of Basic interpreter - reminds me to BASIC09. Did you ever thought about a stripped version, that does not require the Atari platform to run? Could be a strong competitor to EhBasic I suppose. Performance rivels with Plasma V2.

I updated the table to include all your results - thank you!


Regards,
Arne

Hi!



In fact, I would like to do a stripped version, but I need to find the minimum set of requirements. At least, for the integer IDE, you need:
- Screen output at given position,
- Cursor positioning,
- File loading / saving,
- Keyboard input without echo.

For the floating-point IDE you also need the math-pack, currently FastBasic uses the Atari-OS math routines (6 bytes per float, in BCD, uses 2KB), for a portable version I think it would be better to use simple binary arithmetic.

Arne pointed out that a few of my results (32000,50 32000,70) had odd looking times and he was quite correct. I tracked this down to the 32bit subtraction word I did in assembly. Although I looked at it 3-4 times and did not see the error I redid it to make use of the address calculation syntax of the built in assembler in DurexForth (instead of lots of inx, dex to shift the stack index around) and it worked. (Bugs me I could not see my error though.) Anyhow new table below. I ran each test at least twice to verify the results.

Thank you Jeff for verification! I have edited the main table accordingly.
I'm glad to see that the "Prime" (aka modulo) version is - as assumed - still the fastest one.

I know I am slightly late to this thread, but I thought I would try this out using the custom BASIC I created for my machine which I call dflat

It is 16 bit integer only (which helps a lot with performance), and running on a 5.36Mhz 65c02. The results are:
A : 3.95s
B : 6.51s
C : 81.61s

It's similar in speed to VTL02 as far as I can see (when adjusted for clock speeds), but I am pleased as dflat is a fairly full implementation of BASIC with loads of string, file, sound and graphics commands.

The benchmark code is as follows:

Thank you, dolomiah

I have pasted your results into the main table.


Regards,
Arne

Well, I'm quite late to the party on this one, but I've been working on a CMOS only version of EhBasic and I've pretty much finished it up. It's based on Version 2.22p4 (Klaus' patched version) and with the changes, I just refer to it as Version 2.22p4C. It's a bit smaller, slightly quicker and uses less page zero space as well. I've removed all of the IRQ and NMI code and added an EXIT command. I've also changed the startup a bit that tests and sets the memory amount without prompting the user. The current size is 9884 bytes and requires only the I/O vectors set in the single source file.

I've done numerous timings which are accurate to 0.01 seconds using the counter/timer in the NXP SCC2691 UART, which is configured for 10ms as a Jiffy clock. Using the initial Basic Bench program, plus a few changes, my results are below. The changes I've made do a few extra bits, to reset the Jiffy clock before the test starts, then print the elapsed time after it completes. I've run the tests multiple times and the results are extremely consistent. The worst change is a 0.01 seconds once in a while as this is the resolution of the timer itself as part of the ISR.

The board is a W65C02 running at 8MHz with 32KB RAM and 32KB ROM using a single 22v10 glue chip and SCC2691 UART. Details on the hardware can be found here:

viewtopic.php?f=4&t=5005

For reference, the actual basic program used is listed below. Line 15 resets the Jiffy clock, line 100 prints the basic elapsed time accurate to 1 second, lines 110 and 120 calculate and print the remaining hundredths of a second.



The benchmark timings are here:

1000,20 = 2.78 seconds
2000,30 = 4.68 seconds
9999,35 = 61.92 seconds
32000,50 = 162.51 seconds
32000,70 = 308.33 seconds

_________________
Regards, KM
https://github.com/floobydust

Sounds good!

Have you a link for the source yet?

I was just about to embark on something similar myself though for my little system.

I presume you just iterate up memory until you find something that doesn't test - which may be an issue for me as I have an all-ram system with my monitor currently in high memory, although I can relocate that anywhere.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Hi Gordon,

I'll just paste the source here. Note that the source has been changed to assemble/link with WDC tools.



The memory test goes up to the declared Ram_top, so just set that to your max, it also zeros out RAM during the test. Also, you'll need to change the vector defaults for your monitor which are listed at lines: 7428 - 7432. The Page Zero usage is contiguous from $00 - $85. Page $04 is used for the input buffer, Ctrl-C bits and system vectors.

There's only the single source file... one other note, I print the intro message from my Monitor code and then JMP to the start of EhBasic, which is $B000 on my system. You can easily change any of the locations for your monitor. Have fun.... and let me know how it works out for you.

_________________
Regards, KM
https://github.com/floobydust

Great, thanks!

I only have ca65 under Linux right now, so it might take a a bit to massage it for that - then work out how to get it into my system, but I'll let you know how it goes.

thanks,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Just to follow-up, it's working fine.

Assembling with ca65 was easy - add the flag to enable colon-less labels and change .equ into =.


Had to do some digging to work out exactly what ehbasic expected for the character in/out routines - as my ones in my monitor weren't quite compatible. Also worked out that it checks for Ctrl-C very often and that's a slow operation in my system right now, so even though I'm running at 16Mhz, the results of that little benchmark above are slower, however this is exactly why I've built the little 6502 test rig before I dive into 65816 land - to make sure I get the little stuff like this sorted first.

Anyway, disabling Ctrl-C and I get almost exactly half the times you get - I have no hardware timers, but using minicom in timestamp mode works fine and times are half above. My 65c02 is running at 16Mhz so that's very encouraging. Running a "real" program is always better than just doing simple memory tests, etc. too (I used to write test & diagnostics once upon a time - our users would often find some code that broke the boards that passed all our tests!)


This run:


is just under 180 seconds, but it included the time I took to type the numbers in. Quick tests with a stopwatch were closer to 150 seconds. Actually making it print a blank line gives:



So 153 seconds. Neat.

Anyway, thanks again,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Hi Gordon,

Thanks for the feedback. Glad it's working for you. Not sure why checking Ctrl-C would be sluggish on your system. My C02 Pocket SBC is using a NXP SCC2691 with interrupt-driven code for receive, transmit, timer/counter and received break. Perhaps your routine that checks for a key without waiting is the culprit.

The BIOS on my board simply checks the input buffer count. If the count is zero, it returns with the carry flag clear. As the ISR updates the input buffer count, it's a very fast check. If a character is in the buffer, meaning the count isn't zero, it just drops down to the routine to get the character from the buffer.

_________________
Regards, KM
https://github.com/floobydust

Oh, I know exactly why - was just surprised at just how slow. (or how often ehbasic checks)

Other than a latch & 8 LEDs, the 6502 side doesn't have any directly connected peripherals. All it has is the top 256 bytes of RAM which is shared with the ATmega host. So to check for a key (or to print, etc.), the 6502 puts a command in the shared memory area and executes WAI. The ATmega sees the Rdy line going low then /BE's the 6502 and un-tri-states it's own bus control lines (A0-7, D0-7, R/W), reads the command from RAM, does what's needed - e.g. check to see if a key is ready to be read on it's serial line, updated the shared RAM with the result, then releases control, hands it back to the 6502 and blips the IRQ line. The 6502 wakes up and carrys on.

One niggle is that it can take the ATmega up to 64µS to recognise the Rdy line going low from the 6502 - this is due to the video generation being done by the ATmega, and even if a video scan-line isn't being output, if you hit the scan-line interrupt then that's another 64µS gone.. It's not ideal, and somewhat cumbersome, but it's workable for now. Video generation (320x240) takes up some 60-70% of the ATmega execution time )-:

Plan B is to use a spare output pin from the ATmega via the GAL (I have spare in & out pins on it) and into D7, then the 6502 can poll the IO address and if N then it knows the ATmega has "something" for it, so it can then initiate the lengthy exchange process. I'll do that today then I think it might be PCB time (with space for a 6522)

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/