Hello! I'm a long-time electronics hobbyist (started out as a child, built my first single-board computer during junior high school around Robert Grossblatt's "The 8088 Project Book" with my father trying to help me debug it using his two-channel oscilloscope) who's been wanting to build a 6502-family system for many years. Having started on the C64 as a little kid at home and using an Apple II at school, the 6502 still has a special place in my heart even in today's world of AVRs and Propellers. I finally have some time where I might be able to start and finish such a project, and I'm about ready to send an order off to Mouser.

The main reason I'm posting, other than as a general introduction after lurking for many years, is that I'm wondering if there's a particular reason there's such a dearth of homebrew systems around the W65C265S relative to its 65C816 counterpart (both of which are of course overshadowed by the always-popular 6502). I'm particularly curious since WDC seems to be using it on the front lines with their hobbyist and educational development boards, so I would assume that chip might be the first point of contact that a lot of newer community members might have with the 6502/65816 family.

So, are there any hobbyist-specific pitfalls I should be aware of before I get started? Are there technical reasons that make this a particularly poor choice for hobbyist-grade projects, or are there issues routinely sourcing these chips in small-run hobbyist quantities over the years? If so, I could hold up for a bit and look at the 65C816 itself, or just fall back to a regular 65C02.

(What I have found out so far: I'm aware that the internal ROM isn't end-user programmable, but it still seems like a nice enough chip and the built-in monitor seems like a great starting point for more interactive development as a hobbyist, and eventually use a secondary processor like a PIC or Propeller to download your own "ROM" via the serial link after startup. The PLCC pinout also seems more than amenable to relatively straightforward PCB design, and the system-on-chip nature of it simplifies a lot of the I/O and address decoding that I'd otherwise have to deal with for an initial system. I know you end up losing some of the IO ports when you hook it up to external RAM and so on, but at first glance it still seems like you'd get a pretty clean result with your board. I also know that I'm looking at a PLCC adapter for breadboarding, but I'm not sure that's necessarily any worse than using several individual ICs with wires running to and fro in terms of build complexity, particularly for prototyping purposes. So I feel like I'm missing something big because of my own ignorance on the subject, or perhaps it's just not a popular choice for historical reasons.)

Thanks in advance for any advice, and many thanks to everyone for such a useful learning resource in these forums.

Can't help with your question- I'm sure someone can- but welcome anyway! And thanks for your background story.

Welcome. You covered some of it already (lack of user programmability, forfeiting a lot of I/O in order to use the pins for external memory, etc.). When I was talking to Bill Mensch nine months ago, he, too, asked why people are shying away from it. One reason I gave was that the maximum operating speed was only half of that of the others. His response is that it might go faster but they just never tried it any faster. I don't know why they wouldn't push it and see what it could do, but that does seem to be what we have to do with the 65xx stuff, since the data sheets are often missing information we need, or they're overly conservative in terms of specifying performance, or there's something that actually just plain incorrect. It does look like a very nice unit otherwise. I could wish for flash programmability, A/D converters, PWM, etc., but so far we've been having to do those things externally anyway, so what it does have should still be a big benefit to some users.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Welcome!

I like the W65C265 but it requires several readings through the datasheet to get familiar with it. Perhaps this and the slow specs are the cause of the lack of interest. Then there is the fixed memory map that might collide with some software you would like to import. To get rid of the internal ROM you have to place that "WDM" string at a certain place, again something that might collide with someones interests.

On the other hand you can pretty easy setup a system with a fall back guarantee due to the ROM. You only need to add an external EEPROM or Flash at $00:8000 using CS4B and RAM of course and then start develop your software. If you figure out a solution how to switch your desired FCLK back to 3.6864 MHz (the speed the ROM set up UART 3 to 9600 Bd) if you need to fall back to ROM, then you can drive FCLK much higher. My SXB seamlessly works with 14MHz http://forum.6502.org/viewtopic.php?f=4&t=4448&p=52362#p51954 and more should be possible (if you need it). There isn't much I/O left when attaching external memory, but some of the CS-signals can be used to add one or more 65C22 easily.

I wish you good luck and much fun.


Arne

We have a couple of good thread about the 265S.

There's this one, viewtopic.php?f=1&t=3552 , which while more specifically about the board WDC sells, it's fair to argue that the board is little more than a 265S "breakout board", so most of it is germane to the 265S.

It is a nice chip.

As a pure, general purpose CPU, you get "Free" address decoding -- the 265S does not multiplex the Address and Data bus like the 816 does.

You also get some free memory decoding logic, which is kind of nice.

The price for that is an exotic startup sequence, and a different set of interrupt vector registers. At that level, the 265S is not 1:1 compatible with the 816.

Also, the 256S can only go up to 8MHz, whereas the 816 can go to 14MHz.

As a 7 port MicroController SoC, it's pretty limited to a layman. Since WDC is in the Core/IP business, not the chip business, it's not really motivated to do much more with it. Because it certainly has potential.

But you can get a pretty good general purpose CPU out of it, with a free UART or two and at least one 8 bit I/O port, and another few bits on the other one.

If you compare the W65C816SXB board with the W65C265SXB board, even after gimping the SoC to get it to address your RAM and such, you have an ALMOST as capable board (the 816 board has 2 more 8 bit ports), but at a far, far less chip count.

Plus you get a bunch more chip selects on the 256S board than the 816 board, as it exposes the entire memory space. If you're willing to forgo large swaths of memory, you can easily add an other PIA or something (for example, give up the top 4MB of RAM and use the chip select for your device instead).

So you could easily have several MB of RAM and some more IO ports with a low chip count.

You could turn the 256S in to a greenfield project, bypass much of the extras built in to it (both software and hardware), but still have a "better" chip than the 816, just not as fast. It's just a bunch of it is "wasted".

With minimal extra hardware I think you could easily take that 265SXB board, add 1MB of RAM to it, add that USB w/FAT32 chip (the CH376), and have a free parallel port and 2 Serial ports. Populate the Flash with your own loader and on your way. That's a pretty capable system. Being on the 265SXB, it would run at, what, 3.68Mhz.

If you look at the 265SXB board, it has 5 chips: MCU, RAM, Flash socket, a USB<-> Serial chip, and a NAND gate package to help qualify Write Enable.

All that said, the 40 Pin 65816 chip is a very hobbyist friendly chip, up to 64K, and works as a nice "fast" 6502+, given the 816 instruction set. I don't want to say "nobody", but "nobody" (save for BDD) seems really interested in the 816 for its larger memory size. It seems more popular for its programming model as a better 6502.

I think the 65c265 is an excellent chip. In someways I prefer it to the full 65c816.

Much easier to connect extra SRAM and peripherals to. Four serial UARTs that have working interrupts. The monitor can easily be usurped by an external ROM.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I was actually just looking at what I'd need to build a couple of particular projects I had in mind. Basically my choices for the CPU come down to:

- 65C816
- 65C265
- 6309
- implementing a "super 6309" with 24-bit addressing, in an FPGA or CPLD.

Obviously, implementing a complete CPU in reprogrammable logic would be a major undertaking, and I'm not yet sure whether that would meet the idle power consumption target I'd like. I'm filing that one under "awesome but impractical" for now. Nevertheless, I've written a draft design brief as part of teasing out how to go about it, if anyone's interested; the next stage would be to write an emulator.

The '265 is problematic for several reasons already mentioned. Yes, it has lots of built-in peripherals which, therefore, I don't need to attach externally - including equivalents to the 6551 which presumably actually work properly, timers and I/O ports to mostly replace a grab handful of 6522s, and an interrupt controller which can automatically vector the CPU directly to the appropriate handler. All of these are theoretically very useful in a greenfield project. Even so, the *way* it does all this simply rubs me the wrong way, including the way I would have to fudge the bytes appearing at particular addresses during startup in order to transfer control to my own code, and the way that the vectors trample all over high 64K memory with no way to relocate them (the VP signal is not brought out to a pin). The latter makes it a complete non-starter for running Acorn MOS in any form. On top of all that, it's a high-pin-count device, not available at all in through-hole format, which would be significantly more difficult to hand-solder than even the QFP version of the '816.

So by far the easiest options, in terms of building the hardware, appear to be the 65C816 or the 6309 - I consider the latter to have a far better programming model, aside from the limited address space, such that I could tolerate the lower clock speeds available. Interfacing these CPUs to some SRAM, a boot ROM and some basic I/O peripherals should be a doddle, with a GAL chip to latch the high-order address bits of the '816 and generate some chip select signals, or a small page register bank to expand the 6309's address space. I would get complete control over what the memory map looks like, up to and including redirecting the interrupt vector fetches to be MOS API compatible if I wanted, and using idle Phi2 cycles for background DMA without halting the CPU. The '816 is even available in through-hole format, though the QFP version also looks reasonable for hand-soldering.

In short, given the choice between only the 65C816 and the 65C265, I'd choose the '816 almost every time.

Thanks so much for all the replies, not to mention the warm welcome!

I'm going to take the weekend and digest a lot of this information to try and decide if I want to go with a full W65C265S-based system for my first foray into this realm or stick with a more traditional 6502 circuit since it's my first build. Either way, I think it's going to be a lot of fun, and it's nice to be part of a community that has so much knowledge already available on these forums and elsewhere.

Assuming I actually make any progress on any of this, I'll definitely post back when I have something interesting to share.

I can't speak to the VP thing (I assume you mean the VPB pin?). Maybe you could explain that a bit more. I honestly don't quite grok precisely what that does. I guess the idea is that it's used to tell external circuitry that it's "looking for an interrupt vector", and you can then use logic to provide it with one, rather than having a common routine in software do an analysis of the system and then route the interrupt. That's pretty clever, a hardware solution to interrupt routing. Or, I'm completely wrong and have no idea what I'm talking about.

I think having all of those vectors "trampling" high memory is to make the chip easier to use. I mean, it has, like, 28(!!) interrupts it's managing.

But as for the startup, the "bytes appearing at particular addresses during startup" part, that's simply an artifact of the monitor that comes in the stock chip.

If you drive BE high after RESB, the system basically turns in to a 65816. The internal ROM is disabled, and the chip lights up the address and data buses looking for data. There's no magic codes anywhere, you just need something out there at 00FFFC,D for the reset vector. And then, away it goes. At that point, you get to configure all the internal gizmos and what not to your liking.

So, that requires a little clever reset circuit to pull that off, but I don't think it's that big of a challenge.

On their development board, that WDC signature trick lets you slap in a programmed Flash and have it "automagically" boot the Flash code, rather than the internal ROM. Yank the Flash out, and you get a monitor prompt. But you certainly don't need that for a greenfield design.

In the end, save for the package type, it's Hobbyist Friendly in that it lets you, the hobbyist, scale your design out. It's easy to get started because the chip is a stand alone SoC. Out of the box you have a monitor prompt. Plug in power and a serial cable, and 5 minutes later you can have lights blinking. As you get more sophisticated, more skilled, you can move farther and farther away from the on chip facilities and capabilities, expand it out, take on more responsibility. In the end, you have an "almost" 65816. Close enough for most things, but, sure, there's differences.

As a core for a clean slate design, maybe it's a little less attractive if the on board peripherals aren't as interesting to you.

What I mean here is that the '816 has a relatively sophisticated bus interface, with signals indicating when it's performing a data access, an instruction fetch, a vector fetch, and whether it's in the middle of an atomic memory transaction. Idle cycles, when it's doing none of those things, can be used by a DMA bus master without pausing the CPU, by telling the '816 to tristate the bus instead of driving an invalid address onto it.

This means you can theoretically put instructions, data and vectors in three separate address spaces if you really want to, like a Harvard architecture machine - or simply use the distinction between instruction and data references to optimise cache allocation, if you think it's worth implementing one of those. More likely, you could relocate the vectors to a more convenient part of memory (perhaps a section of ROM normally hidden under an I/O window) by replacing the most-significant bits, or satisfy interrupt vectors from a dedicated memory within an interrupt controller instead of from the fixed vector in ROM or RAM. Those are the sensible ways to go about it, anyway; the '265 simply steals a block of address space and effectively hardwires it to the internal interrupt controller.

The ability to relocate the vector table is essential for supporting Acorn MOS on the '816, because the "new" vectors (for ABORT, COP, and the separate native-mode vector table) overlap the entry points of the MOS API. In particular OSCLI is called using JSR $FFF7, which traditionally consists of a JMP through an indirection vector in RAM; this requires 3 bytes which butt up precisely against the 3-entry vector table of the original 6502. I imagine this situation is mirrored in many other 8-bit micro ROMs. By not exposing the VPB signal, the '265 denies me the opportunity to do that.

I don't suppose you get a SYNC to help?

Yes - the equivalent of the SYNC condition is indicated by asserting both the "program" and "data" lines simultaneously.

Aha - so perhaps it wouldn't be too hard (!) to detect SYNC in page FF00 and fetch Acorn MOS program bytes instead of vector bytes?

It's undoubtedly possible - but that still means you've got to insert a non-trivial state machine into the external bus, which undermines the advantages of using a more integrated chip in the first place. At that point you might as well use an '816 and implement your own peripherals.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!