CRC65, A frugal 6502 SBC

[plasmo]

An user reported write problems with certain brand of CF disk, so I delved into the timing of the CF disk and came up with a interim solution that should fix the write problem. The updated CPLD equation is here: https://www.retrobrewcomputers.org/lib/ ... _12_21.zip

As I did more testing, I discovered an unexpected result: I can now run CRC65 at 29.5MHz! It is just a matter of replacing the 14.7MHz oscillator with 29.5MHz oscillator and change the serial baud to 230400. That's all. CRC65 retains all the original functions but will now run twice as fast. It turns out the previous overclocking limitations were also CF disk related and I didn't realize it was not a CF access time problem, but a hold time problem.

ASCII mandelbrot in 38 seconds, wow!

I think I'll get up now and go toot my horn and pound on my chest a bit...
Bill

[Sean]

Congratulations!

[drogon]

plasmo wrote:

ASCII mandelbrot in 38 seconds, wow!

I think I'll get up now and go toot my horn and pound on my chest a bit...
Bill

That's great!

I'm curious about your algorithm/code. My BBC Basic version (which I used as a crude BASIC benchmark) runs in 48 seconds on my 16Mhz 65C02 board

https://unicorn.drogon.net/mandel.txt

code:

https://unicorn.drogon.net/mandel.bas

If you're running a Basic, give that version a go - it should run under most Microsoft style BASICs unchanged.


And this:

Code: Select all

!!!!!!!!!!!!!!"""""""""""""####################################""""""""""""""""
!!!!!!!!!!!!!""""""""""#######################$$$$$$%'&%%$$$$$######"""""""""""
!!!!!!!!!!!""""""""#######################$$$$$$$%%%&(@(&&'%$$$$$######""""""""
!!!!!!!!!!""""""######################$$$$$$$$$$%%%&'(),7*'&%%$$$$$$######"""""
!!!!!!!!!"""""######################$$$$$$$$$$%%%&&(,+/@@?)(&%%%$$$$$$######"""
!!!!!!!!""""#####################$$$$$$$$$$%%%&&&'(*@@@@@@@,(&&%%%%%$$$########
!!!!!!!"""####################$$$$$$$$$%%&&''''''()+@@@@@@:+)('&&&&&&%$$$######
!!!!!!""####################$$$$$$%%%%%&'(.</1+-@@@>@@@@@@@@@/@3)(()1*'%$$#####
!!!!!!"##################$$$$%%%%%%%%&&&'),@@@@@@@@@@@@@@@@@@@@@@@@@@,(%%$$####
!!!!!"###############$$$%%%%%%%%%%&&&&'+/.2@@@@@@@@@@@@@@@@@@@@@@@@@+('&%%$$###
!!!!"##########$$$$$%%&**''''''''''''((+0@@@@@@@@@@@@@@@@@@@@@@@@@@@@+)-&%$$###
!!!!"####$$$$$$$$%%%%&'(=0-+*+32*-)))*+2@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@3+&%$$$##
!!!!##$$$$$$$$$%%%%%&''(*2@@@@@@@@8.,,@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@-+&%$$$##
!!!"$$$$$$$$%%%%%%&)()),@@@@@@@@@@@@@2@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@96'%%$$$$#
!!!#$%%$$$%&&&&''')*1341@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@*'&%%$$$$#
!!!((*++,@0--5//15<@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@6,)'&&%%$$$$#
!!!#$%%%$%&&&&&''')*<:@3@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@)'&%%$$$$#
!!!"$$$$$$$$%%%%%&&*()),@@@@@@@@@@@@@3@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@0'%%$$$$#
!!!!##$$$$$$$$%%%%%%&'')*@@@@@@@@@>0,,@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@1.&%$$$##
!!!!#####$$$$$$$$%%%%&'(:<-+*,1@+@)))*+2@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@5*&%$$$##
!!!!"#########$$$$$$%&&)*'''''(''''''()+/@@@@@@@@@@@@@@@@@@@@@@@@@@@6+)-&%$$###
!!!!!"##############$$$%%%%%%%%%%%&&&&'82/1@@@@@@@@@@@@@@@@@@@@@@@@2+('&%%$$###
!!!!!""#################$$$$%%%%%%%%%&&&'),@@@@@@@@@@@@@@@@@@@@@@8@@@+(%%$$####
!!!!!!""####################$$$$$$%%%%%&')/@0@+-@@@@@@@@@@@@@0@@)))),*'%$$#####
!!!!!!!"""####################$$$$$$$$$%%&''''''()*+@@@@@@>+)(''&&&&&%$$$######
!!!!!!!!""""#####################$$$$$$$$$$%%&&&&'(*8@@@@@@,('&%%%%%$$$########
!!!!!!!!!"""""#####################$$$$$$$$$$%%%%&')-+/@@2))&%%%$$$$$$#######""
!!!!!!!!!!""""""######################$$$$$$$$$%%%%&'(),0*'&%%$$$$$$######"""""
!!!!!!!!!!!""""""""#######################$$$$$$$%%%&(@)'')%$$$$$$#####""""""""
!!!!!!!!!!!!!"""""""""########################$$$$$%&('%%%$$$$######"""""""""""
!!!!!!!!!!!!!!"""""""""""""####################################""""""""""""""""
Time taken: 10952

is just under 11 seconds, but it's a scaled integer algorithm (the BASIC one is floating point) and written in BCPL to run on my Ruby 816 system and I do "cheat" in that I used shifts instead of division at 2 places in it - still division, but somewhat hand-crafted!)

Cheers,

-Gordon

[plasmo]

I'm using EhBASIC, 2.22p4 running the program below. I've not tried porting BBC BASIC to my hardware. I did run your benchmark on EhBASIC and it took 43 seconds with 29.5MHz CPU clock. So either BBC BASIC is significantly better than EhBASIC or my CRC65 running at 29.5MHz is actually not that fast. I should find out which...
Bill

10 MAXITER=20
20 LET C$=" .,'~!^:;[/<&?oxOX# "
30 FOR Y=-39 TO 39
40 FOR X=-39 TO 39
50 CREAL=X/20
70 CIMAG=Y/20
80 ZREAL = CREAL
90 ZIMAG = CIMAG
95 COUNT = 1
100 ZM = ZREAL*ZREAL
105 ZN = ZIMAG*ZIMAG
107 ZL = ZM+ZN
110 IF ZL>4 THEN GOTO 170
120 Z2=ZM-ZN+CREAL
130 ZIMAG=ZREAL*ZIMAG*2+CIMAG
140 ZREAL=Z2
150 COUNT=COUNT+1
160 IF COUNT<MAXITER THEN GOTO 100
170 PRINT MID$(C$,1+COUNT,1);
180 NEXT X
185 PRINT ""
190 NEXT Y
200 END

[rwiker]

BBC Basic is significantly better (and faster!) than EhBasic; I think it is commonly held to be about twice as fast as MSBasic and similar Basics. Soooo, your 29.5MHz CRC65 is definitely no slouch

[drogon]

plasmo wrote:

I'm using EhBASIC, 2.22p4 running the program below. I've not tried porting BBC BASIC to my hardware. I did run your benchmark on EhBASIC and it took 43 seconds with 29.5MHz CPU clock. So either BBC BASIC is significantly better than EhBASIC or my CRC65 running at 29.5MHz is actually not that fast. I should find out which...

It's BBC Basic that's significantly faster and better in the opinion of many. I benchmarked them together some time back.

https://projects.drogon.net/comparing-old-basics/

However that does not detract from your near 30Mhz system - which is pretty good!

Cheers,

-Gordon

[BigEd]

Thanks for sharing that benchmark video, Gordon - interesting that over in this thread on stardot we more or less concluded that BBC Basic's main advantage came from the BBC Micro's 2MHz CPU speed. (Perhaps you were running Basic 4? That's certainly faster in some ways, as it uses 'C02 opcodes and was a revisiting of Basic 2.)

[drogon]

BigEd wrote:

Thanks for sharing that benchmark video, Gordon - interesting that over in this thread on stardot we more or less concluded that BBC Basic's main advantage came from the BBC Micro's 2MHz CPU speed. (Perhaps you were running Basic 4? That's certainly faster in some ways, as it uses 'C02 opcodes and was a revisiting of Basic 2.)

Yes, Basic 4 which, AIUI had a bit of a re-write in the floating point code as well as using a few 'C02 instructions.

-Gordon

[Sheep64]

plasmo on Wed 6 Jan 2021 wrote:

* 64-byte ROM, dual boot either from serial port or CF disk

That's impressive. BigEd's serial boot requires 27 bytes. Conditional branch also has overhead.

From my calculations, booting from opto-resistors has a soft limit of 64 bytes. That is less restrictive than I first imagined.

plasmo on Wed 6 Jan 2021 wrote:

* PC board size goal of 100mm X 50mm, so 2 pc boards per 100mm X 100mm panel.

That's clever.

BigEd on Sat 16 Jan 2021 wrote:

An application! Excellent. It's but a small step to make this an alarm clock and a stopwatch... or egg timer.

I have a semi-useful feature request. I'd like an alarm clock which outputs a gpsd compatible signal on UART. That would allow time on a home server to be set from the alarm clock. I'd also like an alarm clock with mains relay. That could be used to switch a kettle, music and/or lighting. (I'm a programmer. I'm not a morning person.)

plasmo on Thu 21 Jan 2021 wrote:

My pc board shipment is taking a walkabout all over USA. It came through Los Angeles gateway early last Friday morning, then went to San Diego, then to Phoenix, to Tucson, back to Phoenix, and now is on hold in Cincinnati.

Does your parcel have a GPS receiver and e-ink label? Some people do this as a sport to see how long they can keep a parcel in transit and how many exotic destinations it can reach. The advanced ones have SMS and can be recalled at any time.

plasmo on Sun 24 Jan 2021 wrote:

Given the murky supply chain for the retro hobbyist electronics, it really is a good idea to build multiple boards to prove out a design and then periodically build a couple boards during the life of the product.

This isn't restricted to hobbyists or retro. There was a survey, possibly by NASA, possibly mis-quoted, in which an estimated 15% of electronic components are fake. Good luck launching anything with that level of fakery. You won't see me on board. 0.85^N is a disappointingly small value for moderate values of N.

I was shocked by the level of excess packaging from electronic distributors. Honestly, do my 14 pin DIP sockets have to placed in a tube, wrapped in anti-static packaging and sealed with tamper-proof stickers? After reading the terms and conditions of sale, it is apparent that some fraudsters purchase genuine components and then "return" fakes. This leaves the fraudster with higher quality components while the distributor unwittingly conveys counterfeit electronics. Apparently, this either extends to DIP sockets or the warehouse staff have been trained to package everything to this standard. I would prefer that the components weren't packaged, packaged again, sealed, bar-coded, bagged, bubble-wrapped and boxed. However, that is the minimum to counter deceitful customers.

plasmo on Mon 25 Jan 2021 wrote:

Anyone in USA interested in trying out CRC65, I'm giving away 3 blank pc boards.

Your giveaway has inspired my own. I am also inspired by the budget of your project. The offer of pre-programmed components is especially helpful to reduce cost and scope for error. The table of baud rates is also very helpful.

[GARTHWILSON]

Sheep64 wrote:

I was shocked by the level of excess packaging from electronic distributors. [...]

Recently I bought some things from Mouser, including a 4-foot-long piece of 3/16" heat-shrink tubing. They sent the tubing in a separate package, a 3"-diameter cardboard mailing tube long enough to not have to bend the shink tubing, and there was bubble wrap to pad the heat shrink!

[BigEd]

Most things about electronics, these days, make sense at scale. Even a thousand units isn't appropriate scale for everything to work out - and yet, in the hobbyist world, we seldom get up to even a hundred units. So we see odd things...

[plasmo]

drogon wrote:

It's BBC Basic that's significantly faster and better in the opinion of many. I benchmarked them together some time back.

https://projects.drogon.net/comparing-old-basics/

I was search around and found your discussion regarding BBC BASIC vs EhBASIC. BBC is about 2x better than EhBASIC, so the benchmark difference is due to BASIC software. Good, I like that answer.

I also upgraded all 7 CRC65 boards I have to 29.5MHz. All except one were able to run at 29.5MHz, so W26C02's 14MHz max rating is quite conservative. Ironically, the one that failed was the one I built specifically for overclocking experiment; it has fast (10nS) RAM and fast CPLD (5nS) whereas other 6 boards have 25nS RAM and 10nS CPLD. The failed board actually works better at lower voltage, lower than 4.9V, so my suspicion is system noise is causing the failure. CRC65 is 2-layer board with no design consideration for signal integrity, so I'm asking for troubles with 10nS RAM and 5nS CPLD and it shows.
Bill

[plasmo]

Sheep64 wrote:

I was shocked by the level of excess packaging from electronic distributors. Honestly, do my 14 pin DIP sockets have to placed in a tube, wrapped in anti-static packaging and sealed with tamper-proof stickers? After reading the terms and conditions of sale, it is apparent that some fraudsters purchase genuine components and then "return" fakes. This leaves the fraudster with higher quality components while the distributor unwittingly conveys counterfeit electronics. Apparently, this either extends to DIP sockets or the warehouse staff have been trained to package everything to this standard. I would prefer that the components weren't packaged, packaged again, sealed, bar-coded, bagged, bubble-wrapped and boxed. However, that is the minimum to counter deceitful customers.

As a hobbyist I occasionally sell kits and assembled boards to support my addiction and I've found it is frequently easier (and cheaper) to ship assembled boards than kits, especially boards with surface mount components. I have a recent example where an assembled board is lesser than 8oz but a kit is more than 8 oz due to the extra packing materials. 8 oz is the threshold for international shipping rate to jump from $14 to $25. So the price differential between kit and assembled/tested board is not that much.

Blank pc board is easy & cheap to ship. 50mm X 100mm board is lesser than 1oz, so I just put it in regular domestic 1st class letter mail or even International 1st class letter mail. It is important to keep the pc board away from the postmarking machine at the top edge of the envelop.
Bill

[floobydust]

plasmo wrote:

An user reported write problems with certain brand of CF disk, so I delved into the timing of the CF disk and came up with a interim solution that should fix the write problem. The updated CPLD equation is here: https://www.retrobrewcomputers.org/lib/ ... _12_21.zip

As I did more testing, I discovered an unexpected result: I can now run CRC65 at 29.5MHz! It is just a matter of replacing the 14.7MHz oscillator with 29.5MHz oscillator and change the serial baud to 230400. That's all. CRC65 retains all the original functions but will now run twice as fast. It turns out the previous overclocking limitations were also CF disk related and I didn't realize it was not a CF access time problem, but a hold time problem.

ASCII mandelbrot in 38 seconds, wow!

I think I'll get up now and go toot my horn and pound on my chest a bit...
Bill

Nice to see the speed increase! I'm running my CRC65 at 1/4 that... 7.3728MHz, as that's what I had kicking around, which also has the baud rate at 57.6K. Running the EhBasic from the supplied CF Card and your Mandelbrot program, it takes about 153 seconds to complete. That certainly is inline with the 38 seconds you're showing at 4X the clock rate.

I also took one of my C02 Pocket SBC boards and put a 7.3728MHz oscillator in it. Using the same Basic program, it completes the Mandelbrot in 148.01 seconds. Note that this is using my CMOS version of EhBasic. I would also note that the Pocket SBC has a 10ms jiffy timer via the SCC2691 UART which sequences a software RTC along with the Benchmark timer (which measures the 148.01 seconds) and also has interrupt-driven send and receive for the UART. I also matched the 57.6K baud rate for the test.

Granted, it's not a massive speed increase, but it is certainly faster... perhaps as much as 4%, depending on the test. I've uploaded the latest 2.22p5C02 version, which is both easier to integrate to an existing system and everything is contained in a single source file. All you need to change is the character in and out routines to your monitor's equiavalents at a minimum.

basic.asm

(335.25 KiB) Downloaded 86 times

[plasmo]

Bought few I2C 128x128 OLED with 16 grey levels to experiment with.
https://www.ebay.com/itm/3pcs-1-5inch-I ... 3696175425

It is a nice looking display that's 1.3 inch wide instead of 1" wide of the 128x64 OLED display. Unfortunately the pin assignments are different than the 128x64 OLED, so I have to build an adapter board to swap VCC and GND pins.

The display initialization routines are different than 128x64 OLED; after plowing through the SSD1327 datasheet and becoming frustrated with the large list of options, half of which I don't understand, I skipped all that and used the reset default values. It worked fine just with a command to turn on the display.

The display data format is also different; instead of 8 pixels per data byte, it is now 2 pixels per byte with 16 grey levels per pixel. The amount of data to fill a screen goes up by a factor of 8 (twice the screen resolution, and 4 times the data per pixel), so instead of 50mS to fill a 128x64 screen it now takes about 400mS to fill the screen. The screen fill is noticeable now.

The biggest hurdle I encountered was the interleaving of the screen; no where in the data sheet mentioned that. Once I've figured out that it fills every other lines when writing to the screen, everything works just fine.
Bill