I have gotten a basic Ethernet circuit running, using an old ISA-based PC ethernet card connected to one VIA. It has the Realtek RTL8019AS Ethernet controller onboard.

I have a basic TCP/IP protocol working as well and the system is responding to PING requests. however, I do not want to reinvent the wheel so am looking at several TCP/IP stacks out there already. All are written in C which has led me to get CC65 to generate working code for the SBC-3.

This further led me to increasing the bank 0 RAM availability. I did this by relocating the EEPROM data to bank 7 just after reset. This frees up $8000-$FDFF. I also moved the I/O from zeropage to bank 8, above the system RAM. Now, all 256 bytes of the default zeropage are available.

With that configuration, I will work on the CC65 library to support SBC-3 specific I/O.

I hope to eventually try to run Contiki, LNG, or an RTOS that supports TCP/IP.

If any SBC-3 users are intersted in these changes, please contact me via email. I will eventually post everything on my website.

Daryl

You might also look at uIP and see if it's any help.

Yes, Contiki uses that. At least one other I had happened upon also used uIP.

Although I have a TCP/IP stack completely in 6502 assembler, it's a mess and buggy as hell, so for a new version I'll want to look into uIP as well.

(Once I manage to get GeckOS/A65 support cc65 binaries....)

OTOH there used to be a c64 base web server on the internet... those were the days :-)



André

I have created a draft set of target drivers for my modified SBC-3 for CC65 and have been able to compile most of the CC65 sample files.

I have the conio code complete and graphics support for the tgi graphics package is almost done (need to fix the circle-drawing code). Next will be stdio support for my DiskOS file system.

If any of you SBC-3 owners are interested in CC65, please contact me and I can help get you started with target drivers for the stock SBC-3 or get you set up with the upgrades.

Daryl

Last night, I successfully compiled, loaded, and ran the uIP TPC/IP stack along with the HTTPD application with demo web pages using CC65.

It answered repeated ping requests with an average 4-5ms, without any missed pings. It also served up the demo website with the cgi functions all working. I did see a large "dropped packet" count that I want to investigate further.

Next, I want to streamline the code and try to get the pings down to 1ms and correct the dropped packet issue. Also, the web pages are served from RAM that gets loaded from the compiled code. I want to modifiy that to serve them from the CF module (using a RAM cache). That way, the web page can be changed without re-compiling the program.

On a parallel path, I have purchased a PIC ENC28J60 module that uses an SPI port to communicate with the host. I want to build drivers for it and see if it works as well (or hopefully better than) the RTL8019AS. If it works well, them it will be a snap to integrate into the SBC-3.

On the software side, I want to get the SMTP application working along side of the HTTPD. This will allow the host to post an email when triggered. This may be used for remote notification of events, via email to a cell phone.

I may also work on the FTP server app to allow files to be moved to/from the CF module remotely.

If all goes well, I will open up the HTTPD app to my router, allowing you to connect to it. Stay tuned for that announcement.

Daryl

Very good news It strikes me that with ethernet the SBC-3 is hugely useful. Instead of creating from scratch apps such as telnet/ftp/ssh etc how possible would it be for us users to simply port them - especially seeing that cc65 is working well. Does the SBC-3 have the grunt required to support, for instance, an ssh server?

Nick

_________________
Mesham Type Oriented Parallel Programming Language

I'm not sure about simultaneous apps, but surely it should be able to handle any one application. One limitation is the fact that CC65 does not natively support RAM above 64k. It does allow for the use of overlays, as there is a simple overlay demo included with the distribution.

As far as an SSL app specifically, I'm not familiar with the specification or requirements, so cannot answer that.

Daryl

I have finally updated my website to include the many upgrades I have made for the SBC-3. I have added the source files for these upgrades and will happily reprogram any SBC-3 devices for free (I only ask for you to cover the return postage). Plese contact me via email for more information.

The new page is located on the SBC-3 tab here:
http://sbc.rictor.org/sbc31/upgrades.html

Daryl

I made a little progress with the ENC28J60 today. I have it connected to the SBC-3's 65SPI and can read and write to its registers. I will now work on writing the drivers for it. There are several examples written for the AVR's so the conversion should be straight forward.

Daryl

The ENC28J60 drivers are working and loaded on my website. I also made another update to my SPI-IDE interface. It seems the open file for append mode was not correctly setting the file pointer to the end.

As it stands, the SBC-3 platform has a 65816 running at 7.159MHz and 512KB of SRAM. It has a PC keyboard and 320x200 pixel display capable of 256 colors and up to 7 video buffers. There is an RS-232 port for serial communication. It has an IDE interface supporting FAT16 and able to use IDE hard drives or Compact Flash cards for file storage. There is also a Real Time Clock with battery back-up. It now also has Ethernet connectivity. It has a simple Disk Operating System and supports EHBASIC and CC65 C.

SBC-3's planned development is now complete. I have no further plans to build more for it at this point. I will continue to support it and correct any bugs that crop up. This has been a really fun project and its rewarding to see it finally meeting all of the goals that I had set.

Cheers!

Daryl

Except for the video resolution, your SBC-3 has about the same overall processing power as a stock Commodore-Amiga 500.

I read over the Amiga specs briefly a few minutes ago. I'll would not even be able to come close to the video system of the Amiga. It was one well-built design: very flexible and had a lot of features.

The other item of note is the 68000 CPU was 32 bit internal/16 bit external vs. the 65816 being 16 bit internal/8 bit external.

My only regret with the SBC-3 is the cost. It is more expensive than I would have liked it to be. Being able to have others participate in a bulk order helped reduce the cost some, but even with that the basic SBC-3 has about $150 worth of parts. My full SBC-3 with CF and Ethernet has at least $225 worth of parts. To build a single SBC-3, including circuit boards, will run close to $350.

Still, it was a great investment considering the knowledge I have gained and the enjoyment I have received in completing my goal.

Daryl

They benchmarked approximately the same though.

I knew you were going to say these things. Allow me to help clarify.



Yes, I quite agree. However, the blitter is a pure boolean vector processor -- completely incapable of any kind of arithmetic at all. Hence, its power cannot contribute to the processing performance of the CPU except for raw pixel pushing capability.

I mentioned the Amiga 500 because it, too, is clocked at 7.15909MHz.

Here's an interesting experiment for you to try. Find yourself an Apple IIgs running at 2.8MHz. Sit it next to a Macintosh Classic (68000 at 8MHz). Which system wins? I mean, really?

Launch a version of Deluxe Paint II on the IIgs in 16-color 640x200 resolution, draw something, select a brush, and then start drawing with the brush. Watch your jaw drop to the floor at how responsive this 2.8MHz beast is. Remember, the IIgs has no blitter.

Attempt to do the same on the Macintosh. No comparison -- it's slow as hell, and that's on a monochrome screen.

Another example: put the IIgs into 8MHz mode (you'll need either an emulator for this, or a CPU upgrade board), and pit it against that same 8MHz Mac. Watch as you discover just exactly why Apple cancelled the IIgs production run. Why is it so much faster?

(The video circuit for the original Mac stole cycles from the CPU, so the 8MHz CPU really only ran at 4MHz. So, pitting a 2.8MHz 65816 against a 4MHz 68000 was a whole lot more fair than an 8MHz 65816 against a 4MHz 68000!)



This is meaningless. The 65816 is capable of moving four bytes in the same amount of time the 68000 is capable of only moving two. Even though it has a 16-bit external bus, it takes at least four cycles to transfer a word of data over that bus.

Additionally, the 68000 has 32-bit registers, but 32-bit operations require additional cycles. This is because it only has a 16-bit ALU inside.

WDC used to have an interesting article on their site comparing the relative performance of the 68000 to the 65816. Surprisingly, the 65816 was only 20% slower than the 68000 at the same clock speed.



I suspect this is due to the lack of volume production.