6502.org

Thank you for the reply. You gave me alot to think about and to read up on more.

Dimitri

I defiantly need to learn to be more efficient at tracing circuit boards. I've been putting in the last minute touch ups to the board and it really did not look good.

I'll post a picture of the board once I am done, or maybe even the PCB123 program's file for you guys to criticize once I am happy with it.

Dimitri

The way Daryl is moving along, he might be a big factor in eventually getting us this. He writes, "Last night, I successfully compiled, loaded, and ran the uIP TPC/IP stack along with the HTTPD application with demo web pages"

That is pretty cool. Its just about making my project seem useless.

None the less still working on the project, slightly slower pace, I had some side jobs to do for my college so I spent most of my time learning how to run and running a wire EDM the last week.

I had stopped re-tracing all the paths for a bit to work on my "OS" of sorts. Decided a RTOS is not required (I think), so it simplifies things. I am thinking a few C include files can take care of the BIOS system so the software will not need to point to the OS to run. But we will see how that mess goes once I am debugging it on the system.

Dimitri

No 65xx project is ever useless. At the very least, it becomes a teaching tool. So don't let what others have accomplished discourage you. After all, Daryl has been working on his SBC series for some seven years, if memory correctly serves me.

Actually I am simulating the computer environment, using Atmel AVR microcontrollers. I'm not using a 65** model CPU for my project.

I don't know microprocessors per say, as I went from resistors and transistors so to speak right to microcontrollers when I "upgraded" from electrical to electronics skipping the processor based electronics that many of you are quite good at.

Dimitri

And there you go, my project became a 65** series project ...



Not done as you can see, going to add the ROM, other unit of RAM, Flash, and glue logic for memory selection in the next couple of days. I hope to fit it all on a 3.8x2.5" double sided 4 layer board.

If you notice that I borrowed one of your designs, thank you cause I did borrow some stuff.

Like what you see so far?

PS. All 74 series logic "LS" etc is representative, the I'll be using the fastest version of each IC I can find in a SMD package to cut down on space.

Dimitri

If you're thinking about performance, there's a "Test Drive" video game on a Commodore 128 (in C64 mode) with the 65816 SuperCPU here as a bit of a demonstration. (The first actual drive starts at about 3:00.) I have little interest in graphics for my 6502 projects, let alone fast video, but the performance here seems to be pretty good, and I'm not sure the program was even optimized to take advantage of the 816's extra capabilities and yet it has to do some computing of the picture in real time, not just play a pre-recorded movie. For all I know about the SuperCPU, it appears to just plug onto the board-edge connector at the back of the computer; and although it can have more memory and computing speed, its output still has to go over the C128's 1MHz bus to get into the C64 or C128. Maybe Samuel can tell us more.

The '816 was never intended to compete performancwise with the 32- and 64-bit mulit-GHz processors; but add to the above some updated video hardware, and a surprising amount could still be done with the '816 in a desktop environment.

Let me start by admitting I don't have any Commodore 8-bit hardware in my possession (no place to put them and no power to supply them), and if I did, I never had the SuperCPU. Everything I know about it, I learned from reading other sources.

With that being said . . .
This is correct. The SuperCPU is not just a processor upgrade. It is, in fact, a completely headless, whole new computer consisting of a 65C816 at 20MHz, an FPGA, static asynchronous RAM (128K IIRC), and some SDRAM (I believe it's SDRAM, at least). It comes with a single expansion slot, which just so happens to be a perfect fit for the C64's expansion slot.
Correct. The SuperCPU performs a number of tricks to keep the CPU running at high-speed, but sometimes it simply has to inject wait states to re-synchronize against the VIC-II's timing.

One of the tricks the SuperCPU employs is a write-buffer. If I write data to a location in bank 0, it's queued by the FPGA for convenient delivery. In essence, writes to bank 0 are scheduled for the next phase-2 sub-cycle on the Commodore bus.

To handle the scheduling, IIRC, the SuperCPU has a one- or two-byte queue, which means you can only write one or two bytes to bank 0 every 20 cycles without incurring wait-states. This lets the SuperCPU compute something else while the data being written is synchronizing against the VIC-II's bus.

Note: reads must always block, due to the 65816's unrelenting synchronicity in its bus cycle. Unlike 32-/64-bit RISC processors, the 65816 does not support split address/data bus transactions, and therefore, no means of prefetching exists. So if you read from bank 0, you're just gonna hafta wait for it to finish.

Another trick it employs involves a custom memory management unit, allowing you to map significant chunks of bank 0 into SDRAM (1 or 2 wait-states) or static RAM (0 wait-states). That is, zero-page, stack, ROM, and most of RAM can be mapped to S(D)RAM, thus preventing the CPU from wait-states where they're not needed (this includes for reading). Proper placement of frequently used resources in SRAM plus the hardware-managed write-buffers effectively means your program will not incur nearly as many wait-states unless it touches I/O registers, color RAM, or the VIC-II-related memory regions.

Note: The Turbo-CPU upgrade to the Apple IIgs treats its SRAM as cache RAM, and translates DRAM accesses in hardware. The SuperCPU relies on software to place its resources appropriately; hence, you might say that the SuperCPU uses a software-managed cache.
Remember that the world once thought EGA on an 8MHz 80286 was jaw-dropping graphics and break-neck processor performance. A 20MHz 65816 will compete rather favorably against a 20MHz 68000. Indeed, it's strange to think about, but a 65816 at 16MHz or faster, equipped with a MMU (actually making use of the ABORT# pin) would probably make a nice Unix workstation, giving an early Sun workstation a run for its money, and it'll undoubtedly draw less power.

I should point out my interest in a 65816-based PC has historically been derived from the following: silence and openness. I've not yet found a PC-platform computer that was completely silent (even fanless motherboards require power from ATX power supplies), and where those that exist come close, absolutely none are truly open. And even the lowest power PCs seem to suck power (well, except the ARM-based units; they're pretty low-power -- but then you have to worry about recompiling everything for the ARM, and that means manual dependency management, and that means spending hours downloading, cross-compiling, ... no thanks!!).

Reading the spaghetti that is the Linux source tree does not count as "openness" to me.

Openness, in my world-view, encompasses everything from the host OS to the expansion slots and all I/O connectors. I miss the days of the Commodore 64, where you can purchase a single book (namely, the Commodore 64 Programmers' Reference Guide) and have everything you need to write new software (even OSes if you were so inclined) as well as develop new expansion hardware. While the book was quite thick, note that more than half of it was dedicated to beginner's learning advanced BASIC. So, really, the entirety of the C64 could be described in as little as around 300 to 400 pages (you figure 35 pages per chip or significant ROM feature). The Commodore 128's PRG was even bigger and more involved, but it was still a single book.

This demonstrates why I contributed to 65SIB. I wanted a low pin count (as few as possible!), yet high throughput, expansion infrastructure that could be profitably implemented by anyone, for any hardware platform, at very little cost, and yet still be understood in as few pages of documentation as possible. Remember, we're not the PCI or USB SIG here; we have day-jobs, hack in Java, fix car engines, go camping with the kids, whatever. We don't have time, and certainly lack the financial resources, to develop the more advanced interfacing technologies we see today. Though the 65SIB still has more pins than I'd like, I think it's an adequate compromise considering our constraints.

OT: I have an ARM-powered NAS which is running debian. I did have a little trouble finding a kernel and userspace which would install but since then it's been plain sailing: debian has a full and easy to use repository of every package I've wanted. I've compiled run6502, of course! The machine is fanless and silent apart from the disk drive.

The nice thing is, that gives me an ARM box with a native toolchain, so I could get into ARM coding someday. I maintain that ARM is a natural step up for 6502 fans (that's what it was invented as, in a sense) and it was handy a few weeks back to be able to use 'objdump' to disassemble the Archimedes 6502 emulators.