6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 11:23 am

All times are UTC




Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon May 20, 2019 12:21 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
In a moments idleness, I decided to play with some more Mandelbrots and I re-wrote the one I had used a while back - actually, wrote it from 'scratch' by copying one I'd written in C a long time back and subsequently ported to my Linux based RTB Basic. I also decided to do some benchmarks, so made sure it would run un-changed in Applesoft, ehBasic and BBC Basic which are currently the 3 BASICs I can run on my Ruby 6502 SBC.

I wasn't aiming for speed - it's never going to be fast in BASIC, but I wanted to change the ASCII 'palette' and make sure it would run in as many BASICs I had to hand, so 2-character variable names, one statement per line. It won't run un-changed in my RTB, but that's not really important here, although note that RTB doesn't support multiple statements per line as there is no performance overhead to be gained in it from that trick.

There are 3 versions of the 6502 based BBC Basic, all from 1981 to 1983 and a 65C02 version in 1984 which was intended for the 65C02 2nd processor. I can run any of these on Ruby.

The results are not surprising: ehBasic is the slowest, Applesoft marginally faster, BBC Basic 4 (the 65C02 version) almost double the speed of ehBasic. For the parameters I used:

  • ehBasic: 172 seconds
  • Applesoft: 161 seconds
  • BBC Basic 1-3: 124 seconds
  • BBC Basic 4: 96 seconds

This is the code:

Code:
  100 REM A BASIC, ASCII MANDELBROT
  110 REM
  120 REM This implementation copyright (c) 2019, Gordon Henderson
  130 REM
  140 REM Permission to use/abuse anywhere for any purpose granted, but
  150 REM it comes with no warranty whatsoever. Good luck!
  160 REM
  170 C$ = ".,'~=+:;[/<&?oxOX# " : REM 'Pallet' Lightest to darkest...
  180 SO = 1 : REM Set to 0 if your MID$() indexes from 0.
  190 MI = LEN(C$)
  200 MX = 4
  210 LS = -2.0
  220 TP = 1.25
  230 XS = 2.5
  240 YS = -2.5
  250 W = 64
  260 H = 48
  270 SX = XS / W
  280 SY = YS / H
  290 Q = TIME
  300 FOR Y = 0 TO H
  310   CY = Y * SY + TP
  320   FOR X = 0 TO W
  330     CX = X * SX + LS
  340     ZX = 0
  350     ZY = 0
  360     CC = SO
  370     X2 = ZX * ZX
  380     Y2 = ZY * ZY
  390     IF CC > MI THEN GOTO 460
  400     IF (X2 + Y2) > MX THEN GOTO 460
  410     T = X2 - Y2 + CX
  420     ZY = 2 * ZX * ZY + CY
  430     ZX = T
  440     CC = CC + 1
  450     GOTO 370
  460     PRINT MID$(C$, CC - SO, 1);
  470     NEXT
  480   PRINT
  490   NEXT
  500 PRINT
  510 PRINT (TIME - Q) / 100
  520 END


Note that the indentation is produced by the BBC Basic "LISTO 7" option, but otherwise I did use spaces in the code. BBC Basic and ehBasic preserves them, Applesoft strips them.

(And FWIW: While not a fair comparison by any standards, RTB on my Intel i3 desktop produces a 16-colour version in 640x480 graphics in 1.2 seconds...)

You can change the LS (Left Side) and TP (Top) to change the start location if you want to play with zooming in.

Here is the output:

Code:
............,,,,,,,,,,,,,,'''''''''''''''''''''''''',,,,,,,,,,,,,
...........,,,,,,,,,,,''''''''''''''''''''''''''''''''',,,,,,,,,,
..........,,,,,,,,,'''''''''''''''''''''''~~~~===~~~~''''',,,,,,,
.........,,,,,,,,'''''''''''''''''''''~~~~~~=+[&+==~~~~~''''',,,,
........,,,,,,,'''''''''''''''''''''~~~~~~~==+: ;+++~~~~~~''''',,
.......,,,,,,'''''''''''''''''''''~~~~~~~~===+:[ / [+~~~~~~''''''
......,,,,,,''''''''''''''''''''~~~~~~~~~===+:;/?o[:+==~~~~~'''''
......,,,,''''''''''''''''''''~~~~~~~~~====+:O/x  <;:+==~~~~~~'''
.....,,,,''''''''''''''''''''~~~~~~~~~===++:#      X/+====~~~~'''
.....,,,'''''''''''''''''''~~~~~~~~~==++++:;/X      [:++====~~~''
....,,,'''''''''''''''''''~~~~~~~~==+++:::;[/      X/;:+++++==~~'
....,,''''''''''''''''''~~~~~~~===+[<&x[[? <&x     o&//<;:::[[=~~
...,,'''''''''''''''''~~~~~~=====+:;    &O              /[</&/:=~
...,'''''''''''''''''~~~========++:;<                    x    :=~
..,,'''''''''''''''~~=========+++:;/<O                       ;+==
..,'''''''''''''~~~=========++++:< ##                      X<;:+=
..''''''''''~~~~==:/++++++++::::;/x                          [;:=
.,''''''~~~~~~===+:X[;:;; ;;::;;[                             o/=
.,''''~~~~~~~===++;<xXo<<X &<[[[/                             X:+
.'''~~~~~~~=====+::[&         <<&                             /:=
.'~~~~~~~~=====+::;/?          oO                              :=
.'~~~~~~~====++/;[/o                                          [+=
.~~~~~~=++++::;/???X                                         #:+=
.==++:/::+:;;[[o                                             :+==
                                                           &[:+==
.==++:/::+:;;[[o                                             :+==
.~~~~~~=++++::;/???X                                         #:+=
.'~~~~~~~====++/;[/o                                          [+=
.'~~~~~~~~=====+::;/?          oO                              :=
.'''~~~~~~~=====+::[&         <<&                             /:=
.,''''~~~~~~~===++;<xXo<<X &<[[[/                             X:+
.,''''''~~~~~~===+:X[;:;; ;;::;;[                             o/=
..''''''''''~~~~==:/++++++++::::;/x                          [;:=
..,'''''''''''''~~~=========++++:< ##                      X<;:+=
..,,'''''''''''''''~~=========+++:;/<O                       ;+==
...,'''''''''''''''''~~~========++:;<                    x    :=~
...,,'''''''''''''''''~~~~~~=====+:;    &O              /[</&/:=~
....,,''''''''''''''''''~~~~~~~===+[<&x[[? <&x     o&//<;:::[[=~~
....,,,'''''''''''''''''''~~~~~~~~==+++:::;[/      X/;:+++++==~~'
.....,,,'''''''''''''''''''~~~~~~~~~==++++:;/X      [:++====~~~''
.....,,,,''''''''''''''''''''~~~~~~~~~===++:#      X/+====~~~~'''
......,,,,''''''''''''''''''''~~~~~~~~~====+:O/x  <;:+==~~~~~~'''
......,,,,,,''''''''''''''''''''~~~~~~~~~===+:;/?o[:+==~~~~~'''''
.......,,,,,,'''''''''''''''''''''~~~~~~~~===+:[ / [+~~~~~~''''''
........,,,,,,,'''''''''''''''''''''~~~~~~~==+: ;+++~~~~~~''''',,
.........,,,,,,,,'''''''''''''''''''''~~~~~~=+[&+==~~~~~''''',,,,
..........,,,,,,,,,'''''''''''''''''''''''~~~~===~~~~''''',,,,,,,
...........,,,,,,,,,,,''''''''''''''''''''''''''''''''',,,,,,,,,,
............,,,,,,,,,,,,,,'''''''''''''''''''''''''',,,,,,,,,,,,,


(And yes, I checked it was identical for all versions!)

Extracting the BBC Basic floating point routines may be an interesting exercise at some point if I need faster FP routines. It's a 5 byte format though.

Cheers,

-Gordon

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 1:09 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
(Somewhat OT because you're looking at Basic implementations, but perhaps see also this previous thread, which isn't: )


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 1:45 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
BigEd wrote:
(Somewhat OT because you're looking at Basic implementations, but perhaps see also this previous thread, which isn't: )


Yes - that' a great post, I have looked at it with a "what if.." idea, however while Ruby can run some Acorn/BBC Micro code, it lacks the sideways RAM that that uses to store the lookup tables... Maybe in my '816 version though ...

Cheers,

-Gordon

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 2:17 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
There's an idea there, though, if you have sources to a BASIC you like, and if you're prepared to dig in, because (I think) no BASIC uses a fast multiplication method. (After a fast multiplication, the next interesting optimisation might be a fast squaring algorithm which is somehow brought into play.)

(There are fast multiplication methods for the 6502 which use only modest sized tables.)


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 2:26 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
BigEd wrote:
There's an idea there, though, if you have sources to a BASIC you like, and if you're prepared to dig in, because (I think) no BASIC uses a fast multiplication method. (After a fast multiplication, the next interesting optimisation might be a fast squaring algorithm which is somehow brought into play.)

(There are fast multiplication methods for the 6502 which use only modest sized tables.)


I think things like mandelbrots are a good challenge on old hardware though - they are computationally intensive and ways to make that go faster on old system ought to be able to be used on modern systems - if only, in these enlightened days it took more than 5-6 clock cycles to compute a 64-bit double precision multiply, however me moaning about modern brute force methods & "acres" of silicon vs. the elegance of a bygone era won't get us anywhere ...

What I am looking at is a scaled integer version for another project I'm working on - that might work well in a BASIC that handles integers without converting to floating point first. I know most Microsoft/lookalike BASICs (e.g. Applesoft/ehBasic, etc.) do everything in FP, I'm not sure about BBC Basic yet though, however Apple Integer BASIC (which I can also run on Ruby) and other predominantly integer based systems are candidates...

Cheers,

-Gordon

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 2:34 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Yes, BBC Basic has its integer type and AFAIK that does what you'd expect (whereas the MS integer variables on the C64 don't, IIRC)

But BBC Basic can't multiply two integers together without risking overflow or promotion into floating point. For Mandelbrot (and perhaps other applications) a scaled integer might be quite a handy extension. Just possibly a global mode would be enough, if the scaling affects only multiplication and division and therefore won't break for loops and other kinds of iteration.


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 4:13 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Gordon,

Thanks for the mandelbrot program... I've added it to my little BASIC test suite of programs as well. I also tested it on my 65C02 Pocket SBC, which uses my CMOS version of EhBasic. However, as EhBasic on my SBC doesn't handle anything with TIME, I replaced lines 290 and 510 with CALLs to my Monitor/BIOS routines for the built-in benchmark timer. This uses a Jiffy clock via the SCC2691 UART and is handled in the ISR, which increments one page zero byte for hundredths of a second and two page zero bytes for a 16-bit seconds count.

In any case, running on an 8MHz clock speed, the code executed in 154.47 seconds. The benchmark timer does add some clock cycles to the ISR, so technically the code would run slightly (very slightly) quicker without the benchmark timer engaged.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 6:44 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
And for no reason other than because... I changed the code slightly to use graphics and ran it on the graphics terminal - at a resolution of 640x480 with 16 colours.

A shade over 3.5 hours later...

Attachment:
mandel-basic.png
mandel-basic.png [ 42.3 KiB | Viewed 1511 times ]


the gap at the top is because the graphics terminal is emulating the aspect ratio of the BBC Micro which would be 640 wide by 512 high. (the numbers at the top were just some debugging - I'm sure it would have been faster if I'd not been printing them at every point). the other number is the time in seconds...

I really don't think I'll do that again - however, if nothing else it's a very good test of the system and the image matches the same code run on my desktop PC in RTB Basic.

-Gordon

Ps. It would have been done in half the time if I'd been plotting it symmetrically - which I wasn't...

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 7:05 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
floobydust wrote:
Gordon,

Thanks for the mandelbrot program... I've added it to my little BASIC test suite of programs as well. I also tested it on my 65C02 Pocket SBC, which uses my CMOS version of EhBasic. However, as EhBasic on my SBC doesn't handle anything with TIME, I replaced lines 290 and 510 with CALLs to my Monitor/BIOS routines for the built-in benchmark timer. This uses a Jiffy clock via the SCC2691 UART and is handled in the ISR, which increments one page zero byte for hundredths of a second and two page zero bytes for a 16-bit seconds count.

In any case, running on an 8MHz clock speed, the code executed in 154.47 seconds. The benchmark timer does add some clock cycles to the ISR, so technically the code would run slightly (very slightly) quicker without the benchmark timer engaged.


Ah-Ha ... I'm using your 65C02 EHBasic too - with some hacks for my own OS, and I've remembered that the Ctrl-C detect is somewhat slow on my system, so that'll explain why mine appears slower. Just done a quick test now with Ctrl-C disabled (POKE $47F,1) and I get about 152 seconds on my system - which is also running at 8Mhz right now (mostly due to lack of a 16Mhz can) I left the TIME reference in mostly because I forgot to comment it out for the Applesoft and ehBasic runs - I used the same ASCII code for all 3 runs - I can input it in text form directly from my filing system as if it had been typed.

Good to read of someone else running it though :-)

Cheers,

-Gordon

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 8:19 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
drogon wrote:
floobydust wrote:
Gordon,

Thanks for the mandelbrot program... I've added it to my little BASIC test suite of programs as well. I also tested it on my 65C02 Pocket SBC, which uses my CMOS version of EhBasic. However, as EhBasic on my SBC doesn't handle anything with TIME, I replaced lines 290 and 510 with CALLs to my Monitor/BIOS routines for the built-in benchmark timer. This uses a Jiffy clock via the SCC2691 UART and is handled in the ISR, which increments one page zero byte for hundredths of a second and two page zero bytes for a 16-bit seconds count.

In any case, running on an 8MHz clock speed, the code executed in 154.47 seconds. The benchmark timer does add some clock cycles to the ISR, so technically the code would run slightly (very slightly) quicker without the benchmark timer engaged.


Ah-Ha ... I'm using your 65C02 EHBasic too - with some hacks for my own OS, and I've remembered that the Ctrl-C detect is somewhat slow on my system, so that'll explain why mine appears slower. Just done a quick test now with Ctrl-C disabled (POKE $47F,1) and I get about 152 seconds on my system - which is also running at 8Mhz right now (mostly due to lack of a 16Mhz can) I left the TIME reference in mostly because I forgot to comment it out for the Applesoft and ehBasic runs - I used the same ASCII code for all 3 runs - I can input it in text form directly from my filing system as if it had been typed.

Good to read of someone else running it though :-)

Cheers,

-Gordon


Ah, I recall you mentioning the Ctrl-C on your SBC being slower as the implementation is quite different. I think we're quite similar on the execution speed (same EhBasic code). My BIOS ISR does quite a few things... besides being used for transmit, receive, received break and timer... the timer routine alsi handles the RTC update, a core delay routine and the benchmark timer, so that likely accounts for the ~2 seconds time difference. Here's the basic ISR for the timer section:

Code:
;NOTE: Stop timer cmd resets the interrupt flag, counter continues to generate interrupts.
; NOTE: 25 clock cycles to here from INTERUPT0 - 50 clock cycles in total
;
UART_RTC       LDA      #%10010000      ;Get Command mask for stop timer (2)
               STA      UART_COMMAND    ;Send command to 2691 (4)
;
; Check the MATCH flag bit7 to see if a Delay is active. If yes, decrement the MSDELAY
; variable once each pass until it is zero, then clear the MATCH flag bit7
;
               BBR7     MATCH,SKIP_DLY  ;Skip Delay if bit7 is clear (5)
               DEC      MSDELAY         ;Decrement Millisecond delay variable (5)
               BNE      SKIP_DLY        ;If not zero, skip (2/3)
               RMB7     MATCH           ;Else clear MATCH flag (5)
;
; Check the MATCH flag to see if benchmarking is active. If yes, increment the
; variables once each pass until the MATCH flag bit6 is inactive.
;
SKIP_DLY       BBR6     MATCH,SKIP_CNT  ;Skip Count if bit6 bit is clear (5)
               INC      10MS_CNT        ;Increment 10ms count (5)
               LDA      10MS_CNT        ;Load current value (3)
               CMP      #100            ;Compare for 1 second elapsed time (2)
               BCC      SKIP_CNT        ;If not, skip to RTC update (2/3)
               STZ      10MS_CNT        ;Zero 10ms count (3)
               INC      SECL_CNT        ;Increment low byte elapsed seconds (5)
               BNE      SKIP_CNT        ;If no overflow, skip to RTC update (2/3)
               INC      SECH_CNT        ;Else increment high byte elapsed seconds (5)
;
SKIP_CNT       DEC      TICKS           ;Decrement RTC tick count (5)
               BNE      REGEXT0         ;Exit if not zero (2/3)
               LDA      #DF_TICKS       ;Get default tick count (2)
               STA      TICKS           ;Reset tick count (3)
;
; New routine to update RTC variables, saves 15 bytes - from Mike Barry
; ROM based limits are in page $FF (SMHDLIM)
;
               LDX      #251            ; -5 (zp,x wraparound saves us a cpx#) (2)
SMHD           LDA      SECS+5,X        ; Increment SECS counter then propagate (4)
               INC      SECS+5,X        ; it through to the MINS, HOURS and (6)
               CMP      SMHDLIM-251,X   ; DAYS, as needed (4)
               BCC      REGEXT0         ; Exit as early as possible (2/3)
               STZ      SECS+5,X        ; Clear count as increment to next (4)
               INX                      ; Increment index to next (2)
               BNE      SMHD            ; Branch if need to increment next (2/3)
               BRA      REGEXT0         ; Then exit IRQ handler (3)
;


I'm currently using Serial (terminal program for OSX). Loading a BASIC program is trivial... I just did a copy from your post and pasted it into the terminal window and the program is loaded in a couple seconds, 'tis nice 8)

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 8:42 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
floobydust wrote:
Ah, I recall you mentioning the Ctrl-C on your SBC being slower as the implementation is quite different. I think we're quite similar on the execution speed (same EhBasic code). My BIOS ISR does quite a few things... besides being used for transmit, receive, received break and timer... the timer routine alsi handles the RTC update, a core delay routine and the benchmark timer, so that likely accounts for the ~2 seconds time difference. Here's the basic ISR for the timer section:


There are (currently) no interrupts to the 65C02 in my board. The serial IO is done via the host ATmega1284 processor, so there is a bit of latency for the 6502 to call that, ask for character ready, then return - data throughput is fine though, it's just a bit more complex than polling a register for a bit.

floobydust wrote:
I'm currently using Serial (terminal program for OSX). Loading a BASIC program is trivial... I just did a copy from your post and pasted it into the terminal window and the program is loaded in a couple seconds, 'tis nice 8)


I have the "luxury" of an SD card based file system now so I can use the serial line to send files directly into the filesystem for the 6502 to pick-up and one of the features is spool to disk where text output is copied to a disk file, or exec from disk where a text file comes in as if it's been typed. (as well as 'proper' load/save etc. but that's only for BBC Basic right now)

Cheers,

-Gordon

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 20, 2019 10:42 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1950
Location: Sacramento, CA, USA
drogon wrote:
... The results are not surprising: ehBasic is the slowest, Applesoft marginally faster, BBC Basic 4 (the 65C02 version) almost double the speed of ehBasic. For the parameters I used:

  • ehBasic: 172 seconds
  • Applesoft: 161 seconds
  • BBC Basic 1-3: 124 seconds
  • BBC Basic 4: 96 seconds

...

I am slightly surprised that Applesoft was measurably faster than ehBASIC, given that they are not-so-distantly related and given that Applesoft uses 40-bit floats vs. ehBASIC's 32-bit floats. Could the Applesoft-stripped space-indentations inside the loop amount to that much difference, or am I missing something else?

P.S. I'm honored to see that floobydust is exercising my timer code suggestion! 8)

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Tue May 21, 2019 5:50 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
barrym95838 wrote:
drogon wrote:
... The results are not surprising: ehBasic is the slowest, Applesoft marginally faster, BBC Basic 4 (the 65C02 version) almost double the speed of ehBasic. For the parameters I used:

  • ehBasic: 172 seconds
  • Applesoft: 161 seconds
  • BBC Basic 1-3: 124 seconds
  • BBC Basic 4: 96 seconds

...

I am slightly surprised that Applesoft was measurably faster than ehBASIC, given that they are not-so-distantly related and given that Applesoft uses 40-bit floats vs. ehBASIC's 32-bit floats. Could the Applesoft-stripped space-indentations inside the loop amount to that much difference, or am I missing something else?


It's actually slower - once I removed the Ctrl-C test in my implementation of ehBasic. I never patched this in the Applesoft I have, so it still tests $C000....

So that list really ought to be:

  • Applesoft: 161 seconds
  • ehBasic: 152 seconds
  • BBC Basic 1-3: 124 seconds
  • BBC Basic 4: 96 seconds

-Gordon

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


Top
 Profile  
Reply with quote  
PostPosted: Tue May 21, 2019 7:17 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
Another Mandelbrot for the collection - cool.

Runs in 79 seconds on the Jaguar.

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Tue May 21, 2019 8:17 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
BillO wrote:
Another Mandelbrot for the collection - cool.

Runs in 79 seconds on the Jaguar.


Well - that's (presumably) ehBasic at 16Mhz... My Ruby board will run at 16Mhz, but I only have one 16Mhz can xtal right now, but I'm sure I'd get 96/2 = 48 seconds in BBC Basic on it..

Oh, aright then - you've twisted my arm... ;-)

Attachment:
IMG_20190521_211158_DRO.jpg
IMG_20190521_211158_DRO.jpg [ 581.79 KiB | Viewed 1421 times ]


I moved the 16Mhz can over to the 65C02 side and the clip and black wire takes the clock from the GAL over to the ATmega clock input... Must remember to get some more 16Mhz cans!

-Gordon

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 15 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: