Came across this during some random search - http://homepage.mac.com/jorgechamorro/a ... /65xxx.txt

I've never heard of the 6516 mentioned before (as a development pursuit or otherwise). The 6516 sounds pretty impressive from what's mentioned in that article. Out of the handful of processors I've worked with (65x/816, z80, x86, 68k) and looked/traced through (SH2,v810), the 65x has always been my favorite to code on. It sad to see how the 65x could matured but didn't.

Thanks for the link. The 6516 seemed to have a lot in common with the 65CE02. I would sure like to see the 65032 be put on the market.

I'd like to see a 32-bit upgrade to the architecture as well. However, I have a hard time believing that Terbium 32-bit CPU will hit the market (WDC considers the 6502 and 65816 as Terbium family parts), and even if it does, it will fall so far behind the performance curve that it wouldn't sell in any appreciable numbers to recoup development expenses.

At least where power isn't a concern, folks are finding an FPGA programmed with a homebrew CPU (or one from opencores.org) to provide superior cost/benefit ratios.

If performance is not an issue, you can implement a soft-CPU using a high-speed microcontroller chip, like the SX-series.

The cost of developing ICs seems to have dropped precipitously, but it sure sounds like WDC still won't come out with any more (judging from how long ago the Terbium was announced and there's still no hardware). The FPGA is probably the only way to get it. The fastest microcontrollers I know of, including a 75MIPS SX, would probably not even be fast enough to emulate a 1MHz 65032 though when you consider the many, many instructions the µC would have to carry out to emulate each half cycle.

Generally, in most emulators, you have a 10:1 performance ratio. This means, you can within reason expect a 75MIPS SX microcontroller to emulate your desired virtual processor at 7.5MIPS, give or take some noise figure. You'll notice that there are often a factor of 10 performance ratios of raw assembly language to Forth colon definition performance too, for the same reasons.

While not exactly great, it's also not entirely too shabby either.

Also, the cost of fabbing a piece of silicon is, so I'm told, relatively cheap. The cost of packaging it, however, remains exorbitantly expensive, with costs going up geometrically with pin count. It costs Intel pennies to fabricate a Pentium IV chip, but significantly more to package it. Combined with relatively low yields (compared with, say, a simpler chip like the 6502), this is why Pentiums are so dang expensive compared to the 6502.

If committed demand levels cannot match the development and packaging costs for a chip, then there is no financial incentive for doing so. Particularly if you're a smaller, fabless semiconductor house like Intellasys or WDC.

That may be true for this case if the microcontroller had 32-bit ports and registers, but trying some senarios with the PIC instruction set (which is what the SX has) and 8-bit ports, I find it is far, far below that 10% efficiency. Just incrementing the 32-bit address (taking four 8-bit ports) to output on the bus takes 7 instruction cycles, already taking almost 70% of the budget, and you have to double that for any instruction that has an operand after the op code. If you have to store it and put another address out there like you have to for ADC ABS and then put the program address back, that's an additional 24 instruction cycles, and we haven't even begun to do the addition which, with the PIC's instruction set that does not have an add-with-carry, will take a few dozen more for the 32 bits by the time you store the result in the accumulator variables. It will take even more if the decimal-mode flag is set. Add some more for checking or modifying the NMI\, IRQ\, RST\, VDA, VPA, VP\, ML\, BE, ABORT\, SYNC, RDY, R/W\, and clock I/O bits, and more for updating the N, C, Z, and V flags. To get to the PIC or SX code to emulate the particular 65032 instruction, you still have to add the address table look-up, which is very inefficient with the PIC & SX instruction set. The 6502 does the whole thing in four clocks. To get the needed I/O bits, the µC would have to come in an 84-pin package, otherwise use additional outboard latches and more instructions to feed or read them one at a time. It's not lookin' good.

OK, I agree. But, several points here:

1. Why use 4 8-bit ports? Back in their day, lots of micrprocessors relied on external up-counter registers which could be loaded. It wasn't uncommon to have a program counter and an index register external to the CPU, loaded with special strobes as data came in over their buses. True, it's not single-chip, but it worked quite well. In fact, the Saturn architecture CPU in your HP calculators uses this precise architecture.

This can save time, because, instead of reloading all four bytes, you only have to strobe a "count up" signal to the register.

This is a separation of concerns -- you have the surrounding register-transfer logic for address manipulation and other goodies, while the microcontroller serves as the "PLA" of the system -- executing instructions and, as a result, directing the external resources accordingly.

2. Microcontrollers with far more efficient instruction sets exist. A 65265 comes to mind. I think we're discussing concepts at this point, and not specifics. I could be wrong. In either event, the distinction between 20:1 and 10:1 is about 10dB less observable than the distinction between 2:1 and 1:1. A 3.5 or even 1 MIPS execution rate for a _microcontroller_ to achieve is nothing less than phenomenal.

3. Execution rates will be amortized. Not ALL instructions will involve reloading the address bus registers.

4. You don't need to reload all 32-bits of an address bus. What are the odds that you will even use half of that address space? Remember, the original 68000 was limited to 16MB, and the 68008 to 1MB. Lots of useful systems were built with both, each with significantly less than their complete memory capacity installed.

5. This *might* be a case where parallel processing can come in to help out too -- one microcontroller serving as the bus interface unit (BIU) while the other microcontroller serving as the execution unit (EU). This sets up, essentially, a two-stage pipeline, so one microcontroller can be fetching the next instruction or performing other activity while the EU is busy working on the last fetched instruction.



OK, this is a clear-cut case where you come into a doctor's office complaining of a headache. The doctor asks you what you've been doing in the near past, and you answer that you ram your head into the wall repeatedly.

What do you think the doctor's response will be?

The term "microcontroller" doesn't imply an automatic restriction to 8-bit bus widths. Other widths do exist, and with instruction sets far in excess of anything the SX or PIC architecture has. I believe ATmel makes a 32-bit line of microcontrollers. ARM-based microcontrollers exist. I know for a fact that 68K-based microcontrollers exist (aka "ColdFire" processors, which have proper 1-cycle-per-instruction throughputs for most instructions). They exist, are reasonably priced, and inevitably a whole lot cheaper than fabbing your own custom CPU design.




If you make NMI and IRQ bits 8 and 9 of a 10-bit pseudo-opcode, then this becomes trivially easy to check; use a 1024-entry jump table. Entries 0-255 refer to normal opcode behavior. Entries 256-511 *all* point to the NMI emulator. Entries 512-767 point to the IRQ emulator. Entries 768-1023 all point to the NMI emulator (since NMI has priority over IRQ).

Theoretically, RES\ can be checked the same way, but the jump table is growing large at this point. But, if you've the ROM space, why not?



Actually, you need only 5 8-bit ports to implement a complete 32-bit bus with a two E-cycle (since Phi doesn't make sense any more, we're not looking at a 6800-like E-based bus) overhead, where the first E-cycle sets the 32-bit address for the second E-cycle. Note also that you can amortize the cost of this 50% drop in bus throughput by "bursting" multiple 32-bit words into the microcontroller. This is how caches work, it's how SDRAMs work, and it's amazingly effective. As for the rest of the control signals, well, odds are likely you really don't need them.

In fact, this kind of interface might be preferable, particularly since you can implement the SDRAM controller software directly in the microcontroller and eliminate a huge amount of outboard logic (or an external CPLD or FPGA).

Overall, if you're looking for anything resembling performance, you'll want either a discrete component CPU (using actual TTL parts) or an FPGA solution. In either case, using a 65xx-style PLA combined with a register-transfer architecture and multiple internal buses should yield quite a bit of performance (few cycles per instruction, and hundreds of MHz for the FPGA solution).

However, you might want to consider building a stack-architecture CPU if you go this route. I think you'll find Phil Koopman's text on the subject, "Stack Computers: The New Wave" (http://www.ece.cmu.edu/~koopman/stack_c ... index.html) most interesting.

I was digging around in a binder the other day, and I found my old 65832 docs from March 1990. It's a straightforward 32-bit extension of the 65816, and has an E16 bit (behind the V bit) for 65816 emulation.

I'm rather glad it wasn't built, because it wasn't well-suited for compiler code generation.

Toshi

Neither is a PIC or Atmel microcontroller instruction set (especially the PIC; the Atmel makes token efforts to be easier to compile for though). That hasn't stopped anybody from writing C compilers for them though.

Do not forget though that the largest marketplace for the 6500 series is embedded applications.

Going for an FPGA as a processor would not make sense in industries seeking to lower costs all the way. since you have th load the buggers each time.

WDC does some good licensing, such as a Winbond all in one videogame chip utilizing an 816, graphics and sound generators.
http://www.winbond-usa.com/products/win ... 91a1.7.pdf

We discussed that before, But for application, you know the handheld games that plug into your TV set that sell for maybe 10 bucks? You figure out the cost of this main controller chip, possibly less than a dollar in quantities. Plus you tap into people with experience in writing NES or SNES home games to easily migrate for using this. Would an FPGA processor make sense in this application? don't think so.


I did have some neat fun in terms of one of the companies mentioned as their head support can desperately use some anger management. (it ain;t WDC, as they have the world's greatest support team which is why I still have future projects involving the 6500 series This one company, I ALMOST considered one of their chips for an audio application. All it took was a 10 minute blast on the phone of him yelling at me to decide that I wouldn't be too happy with their support. And at a new job, I found out one guy also got blasted by the exact same guy, and this is someoen I never met. Add in a whole group of people who told me that I had hit a sore spot and they also mentoned anger management.

sorry, wierd tangent there.


But overall, the primary business for WDC is the core ip for companies building in huge quanties with a low price point and wanting heavy reliability and low development time.

_________________
"My biggest dream in life? Building black plywood Habitrails"

I just found this languishing on the internet

http://www.obelisk.demon.co.uk/files/W65C832.pdf

_________________
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

Further, don't forget that a 32-bit processor in WDC's current market space isn't going to yield all that many benefits either. For starters, there's no less than four times as many traces to place and route. That means increased board-related expenses, and really, THAT ultimately is what determines product price. Then there is the additional expense from extra memory chips, etc.

The point is, WDC promised a 32-bit processor as part of their Terbium lineup. The 65832 and 65T32 processors have both, heretofore, been vapor.

When Hifn announced but failed to deliver its 65000 (a completely unrelated product; this is a 1024-bit modular math coprocessor intended for hard real-time encryption applications), I thought that a dirty, underhanded tactic. I mean, I was in post-silicon verification -- why hadn't I heard of the 65000 before the public announcement? Shouldn't I have, especially since it was my job to test all the chips coming down the pike? It turned out that it was a deliberately planted fake, in an effort to influence (in this case, successfully) our competition into not making a competing product.

The idea was simple: if I'm the competitor, and it's taken me several years of effort to compete against Hifn's 6500 chip (the predecessor to the 65000), requiring several more, and at the same time, I see that a 65000 is coming out, with better instruction timings, wider integer paths (2048-bit in this case), and multiple cores on a die, then I've basically just wasted two years of effort. It'd have to be scrapped, everything retooled, and we'd end up going through another development cycle at the absolute minimum. Or, we'd realize that we can't compete in the space, and not even bother.

I consider this a dirty, underhanded, dishonest, unethical practice. In fact, everyone I've spoken to, both inside and outside the industry, considers such "anti-competition vapor" to be the epitome of dishonesty. If you announce, then you release. I accept that things can take upwards of five years of effort -- maybe more. But it has to come out *sometime*. Having regular progress reports would be awefully nice too.

The 65T32 is total vapor from an outsider's point of view. All indications seems to be that it was an anti-competitive posturing. Who was the competitor though? I can't think of anyone. Both PIC and Atmel have released 32-bit microcontrollers anyway. PowerPC and ColdFire have both taken off in the embedded space, some of which are actually 64-bit CPUs from what I hear. I understand that the Prius was Toyota's first non-65xx car computer system, because the 65xx series just wasn't up to the task of computing the fuzzy logic involved with its CVT. With automotive being the 65xx's current forte, you'd think that a 32-bit CPU would be high on their priority to fend off competition from PowerPC.

So, knowing that WDC didn't really have any competition to fend off (for all its competition already had 32-bit products on the market), and knowing that the announcement of the 65T32 had a sizable number of people waiting for the product's release (judging by the number of Internet websites at the time which latched onto it), I consider the failure to deliver real silicon with a 32-bit 65xx core a major let-down to their customer base and, if I'm allowed to say it, their fans.



That isn't the problem. That takes maybe two to five seconds at best. My handheld GPS unit takes upwards of 45 seconds just to get to the boot-up progress screen!

The real problem is that a 32-bit architecture takes up real-estate, and the price of the product is directly proportional to the cost of the real-estate.



So, you're defending a company whose survival is essentially tied to a single industry? It seems that they're losing out in the automotive sector due to the math involved with CVT calculations, so instead of competing in that space, they've decided to focus on cheap, Chinese game units that nobody else wants?

That's hardly a strategy for long-term business success. In fact, if you read any business management book, regardless of how famous the author, dependency is a real killer! A business needs to have more than one significant customer -- it has to diversify its portfolio, so that fluctuations in one market do not affect availability or prices substantially.

When I acquired my collection of 65816 chips, they cost $6.00 or so each across the board. Today, they're almost $10! Why the price increase? It certainly isn't demand! It can only be one thing: their supplies are running low, and fabbing expenses are increasing due to lower sales volume. Their microcontroller offerings have also increased in cost substantially -- almost $28 for a single chip microcontroller? That's insane. Considering the capabilities you get in an FPGA of equal price, you're far better off with the FPGA. Considering that pinning a semiconductor is the dominant cost of the chip, and that FPGAs have far greater pins than WDC's microcontrollers, I can't imagine any technical reason why WDC's microcontrollers are so astronomical in cost. The only remaining reason is, again, low sales volume.

OK, fine, WDC makes its dough on IP licensing. Now the question remains, does the 65T32 exist as an IP core? No indications exist that it does; if it did, you'd expect them to plaster their site with developer details on it.

So far as this outsider can see, WDC is supported, at any given time, by one major industry segment. When I purchased my chips, it was the automotive sector. Today, it appears to be uber-cheap Chinese game cores. If WDC came out with even a discrete $5.00 competitor to the ATmega-8 40-pin DIP package, complete with flash programmability, they'd have a throng of customers beating at their door so large that the building would threaten collapse. If they fixed that damn VIA serial-port bug, they'd have real solution to parallel computing in the embedded space right now (I'm not sure if the VIA's serial port appears in their $25+ microcontrollers; too lazy to look right now. But, IIRC, they didn't have anything which compared except a UART). What an embarrassment -- 30+ years, and the VIA's serial port bug still isn't fixed. Commodore's only reason for coming out with the 6526 was to fix that serial port bug (and then they didn't even use it in the Commodore 64! Oohh, for shame!).

If Mensch wants to retire, fine; I simply ask that he don't lie about it. But if he's interested in keeping the 65xx lineup not only alive but competitive as well, then he must look into offering a competitive 32-bit offering as well. (And fix that damn serial port bug!)



Well, you get heavy reliability from other architectures too. As far as development time is concerned, I'm overwhelmingly more productive on a 68000 than I am on a 65816, simply because I don't have to deal with pointer issues (do I use a 16-bit or 32-bit pointer? Do I allocate this in bank-0? Will there be any possibility of structures crossing a page- or bank-boundary? Oh crap, I need to widen the pointer from 16- to 24-bits; how will this affect critical timing? How will this change affect every other call-site to this procedure? How the hell do I use object-oriented or functional-style programming with the 65816 without incurring a huge performance overhead? And on, and on).

I appreciate your sticking with the 65xx architecture, and it holds a large nostalgia value with me as well. That, and its affordable price, were the reasons I persued its application in the Kestrel. However, without a clear upgrade path to wider bus widths, combined with the increasing costs for discrete hardware, there exists no clear future for the processor lineup.

I found it interesting in you mentioning it being used in Toyotas, except for the Prius (got an 88 Toyota Hilux myself).

I would dearly love to see an AVR competitor single chip solution in the 6500 series as well. Built in flash and ram and rom. I was under the assumption back in 93 that it was when I drew up a ticket dispenser system using the 134. Still glad I gave it a whirl for the ATE system all around. Made me appreciate the bugger for an upcoming project all its own out here.


Don't underestimate the Chinese market for low cost computing solutions. The game gigs are but one product Was just poking round the WDC website and came across a testimonial I had never read before.

Customer Testimonial

Judy Kuo‚ Director of Consumer Industry Marketing Division, Winbond Electronics Corp.

"By using the matured 65C02S core, Winbond is able to develop application specific chips for speech and MIDI synthesis in a timely manner. The unified user interface in code development ensures the successful deployment to customers while lowering the development system cost. As highly-flexible solutions roll out constantly‚ Winbond is leading the way to help customers innovate their products easily. "



The Winbond game chip is evidently just a single product they make using the 65XX core. Couple more products evidently, and their reasons are interesting, a mature stable product line that decreases their R&D time instead of using whatever is the flavor of the minute.

A robotics company in Florida also has a similar reasoning, using Apple 2Es as their core control systems instead of going to PCs or micro controllers. I had asked about that one time and the answer was the 2E was stable as heck and gave consistent production results.



One interesting place I had seen Winbond was in reverse engineering an automobile TV LVD display system. It used an all in one graphics controller from Winbond (the non RAM foundry spun off now called Nuvoton). Their line has the previously mentioned speech and midi synthesizers, and quoting other things:

ViewTalk™ Family
ViewTalk™ Family Series are specially designed for LCD-based consumer product applications such as musical watches, musical
calculators, musical PDAs, hand-held games, toy PCs, pre-school kid education toys, virtual pets, and security systems.

USB Device

The W55U02 is an USB V1.1 controller for W55Fxx, SPI serial flash or NAND type flash memory. It has an 8-bit microprocessor that
provides flexible API functions to support general applications. It is compatible with any PC via USB.


MFID & RF Family
In recent years, contactless identification devices have been increasingly used in the toy market. MFID (Magnetic Field Identification) is
used in all areas of automatic data capture allowing contactless identification of objects using magnetic coupling.

(their advanced toy systems utilize the ARM, a chip descended from the 65xx series)


Game
The “TV Edutainment/ Game Family” is the highly integrated chip for TV-toy/game application. In W55V9x, many functions are embedded;
including 65C816 µC, CRT controller (CRTC), TV encoder, Programmable Sound Generator (PSG) and other miscellaneous peripherals.
Additionally, the Direct Memory Access (DMA) mechanism can make W55V9x more powerful in image processing.



While they do offer the 8051 seperately and use the ARM and 8051 in pc related applications, the 65xx seems to be a workhorse for them.


and this is but one company out there. More to the line than simply toys....

_________________
"My biggest dream in life? Building black plywood Habitrails"

You missed my point completely. The Chinese market, regardless of how large it is, is still only a single market.



I'm really not liking it when people say, "It's a stable product line." This is a bad word to use, because, . . .



. . ., given exactly the same level of documentation for the PC that the Apple II has, the PC would deliver precisely the same level of consistency and stability. There is nothing in the 6502 that inherently increases software stability over, say, an 80286.

The reason the Apple IIe won over the PC, then, must come down to other factors, such as having readily available hardware programming documentation (something the PC industry strongly discourages).



More precisely, the ARM was inspired by the 6502, but is otherwise a fresh design.



Again, that is positively wonderful . . . for Winbond. However, this says nothing about WDC. By all accounts, WDC has only one significant customer, Winbond. And, by significant, I mean, if Winbond stopped using the 65xx lineup tomorrow, WDC would find themselves desperately seeking new clientele to keep cash flow, or risk burning cash reserves.