Are there any datasheets on the W65T32 version of the 65xx series? I just recently saw, this on WDC's site, but I dont see any data sheets on it.

OOooohhh....so the Terbium has a part number now? And, at risk of judging a book by its cover, it is almost as if it will be a 32-bit processor too... (Please don't take this as a rumor; this is just conjecture -- I have no idea if the 65T32 even is referring to the upcoming processor)

Well 32bit addressing at least. The data is 16bit, so I guess you can call this a 16 bit processor then. It would have been nice if it had 32bit data tho.

Umm...no? Just because it has a 16-bit data bus does not mean it is a 16-bit processor. According to the website, it has a 32-bit core. It just means that it takes two bus cycles to transfer a full 32-bit quantity.

(Yes, this means that the Z-80 is a hybrid 8/16-bit CPU.)

Here are my predictions, based on my research to date (which admittedly isn't all that much, hence all the heresay):


PREDICTION 1: 64-pin DIP or 68-pin PLCC

I'm not sure that they want to multiplex the bus after the near disaster that the 65816 has had in DIP form-factor getting the bank address byte off the data bus. I think they would want to use a fully demultiplexed bus for this new chip. Therefore, with 48 pins dedicated to just addressing, I suspect the next "standard chip size" for this family of CPUs will be at least 64 pins.

The PLCC form factor will suck a bit for us home-brewers, because the sockets are much more expensive, and dealing with PLCCs aren't fun (at least for me). But, even so, I'm willing to invest in order to get my grubby little hands on that chip.

PREDICTION 2: 8GB RAM capacity

The documentation on the site states that it'll address 4.2 giga-WORDS, not gigabytes, of memory. If true, and if the CPU now considers 16-bits to be the smallest addressible unit of memory (see further predictions below), then the total address space will now be 8GB.

PREDICTION 3: Strong influence from the 65032 and 65000 projects

I believe that the choice of architecture will closely reflect these designs. They state that it will be software compatible with the 6502 and 65816 processors, but when operating in these modes, I believe that the data bus will use only D0-D7, leaving D8-D15 unused. However, when operating in native 32-bit mode, that's when the full bus will become available for use.

Therefore, executing something like "LDA $ABCD", it can be interpreted in one of several ways (assume E8 bit is emulate-6502 bit, and E16 is emulate-65816 bit, assuming one exists):

M=0, E8=0, E16=0: load 32-bit word from ea+0--ea+3 into A[31:0]
M=0, E8=0, E16=1: load 16-bit word from ea+0 and ea+2 into A[15:0]
M=0, E8=1, E16=x: load 8-bit byte from ea+0 into A[7:0]

M=1, E8=0, E16=0: load 16-bit word from ea+0--ea+1 into A[15:0]
M=1, E8=0, E16=1: load 8-bit word from ea+0 into A[7:0]
M=1, E8=1, E16=x: load 8-bit word from ea+0 into A[7:0]

where ea is the effective address of an instruction, and n is the byte offset from that.

Of course, this is all assuming that the 65T32 even inherits the operational implementation of the 65816, which of course there is no guarantee. For all we know, they could use the WDM instruction as the prefix byte of a 2-byte opcode, that shoves the CPU into native 32-bit instruction set mode, where additional registers and addressing modes may become available, that are independent of any M, X, or E flag bits. But to do that, they'd basically need to implement two instruction decoders, which takes up space, power, and design time. I strongly doubt this will happen.

Additional evidence is that they say it will address 4.2 giga-words of memory, instead of giga-bytes, which suggests that, in 32-bit native mode, the idea of a "byte" changes fundamentally somehow.

PREDICTION 4: Performance Galore

The 65816 is well known to compete favorably with the 68000 and 68010 processors, despite its 8-bit wide data bus. It easily owns the 68008. The Terbium will have a 16-bit wide data bus according to the website, therefore letting the chip easily out-perform the 68000/68010 CPUs. This will place the Terbium squarely in the 68020 to 68030 performance arena, especially when dealing primarily with 16-bit arithmetic.

PREDICTION 5: Relatively Low Cost, but Not Necessarily Hobbiest Friendly

I predict the final chip will be less than or equal to $20, should individual chips be purchasable. For the level of performance that we've seen from the 65816, I think this is just a tad high, and as a result, I suspect most will still choose to utilize the 65816 as it's cheaper and, "Good Enough." Nonetheless, should the Terbium become available, you can bet your bottom's dollar that I will find a way to design a Kestrel around it. >:)

PREDICTION 6: Goodbye ABORT pin!

As far as I'm aware, nobody made use of the ABORT input on the 65816 at all, let alone for its intended use, either in an IP-core application or in an external circuit. Therefore, I fully expect that facility to be removed from the Terbium. This is a pity, because I, for one, WAS planning on designing an FPGA-based Kestrel that DID make use of a home-made memory management unit. I hope this prediction falls flat on its face. I really do.

PREDICTION 7: Overall, The Same Bus Architecture

I do not see the external bus architecture changing all that much. If the chip permits byte addressing, then there will be two new signals, to control which byte lane of the data bus has valid data on it. Otherwise, they can just make the smallest addressible quantity a true 16-bit word (of which, only bits 7-0 are used for 6502/65816 software). Indeed, I can readily see how this can be expanded to support the native 65T32 instruction set: if the opcode bits 7-0 are the WDM opcode, then bits 15-8 contains the expanded instruction. Or, alternatively, bits 15-8 *always* are valid, but configured so that if its $00, it happens to mimic the 6502/65816 instructions. This can then do away with the hypothetical E16 bit discussed above entirely. This is another trick from the 65032 project, if I recall.

Well, those are my predictions as of now. We'll see how things play out and how close I am in this.

The problem is that most of the other chips in the range that the Terbium is competing in have far more than a 68 pin PLCC package, which may result in a package that's even less hobyist friendly than a 68 pin PLCC.

Remember, we've moved to an era where people don't always feel the need to wire-wrap prototypes. :/

It may also be that the Terbium parts are all aimed at the faster-than-a-PIC-but-slower-than-a-full-PC market that the ARM has been doing quite well in. So there might be something that has a form factor like a PIC or AVR, with everything, including flash and RAM, built in.

To me, giga-words means that whatever the machine word size is, it's 4*1024*1024 that. If the machine word is 16 bits, it's a 8 gigs. If the machine word is 32, it's 16 gigs. If the machine word is 8 bits, it's 4 gigs.

There's a lot of different directions they could go with things, IMHO. Remember, the ARM's Thumb abbreviated instruction set is quite popular for things, which may mean that they just add a few flags here and there and use the WDM instruction for all of the extra stuff. I always thought it would be interesting to have a flag that turns the zero page into 256 real registers.

That is true only for microcontrollers. The raw processors themselves typically have relatively few pins. Architecture-wise, the Terbium has "caught up" with the 68010 as far as its bus interface is concerned. That CPU had only a 64-pin DIP form factor, and worked out quite well.

Also, remember too that WDC doesn't have infinite cash reserves -- they're going to want to go with the cheapest packaging possible, since the external parts have never been considered their flagship products. At best, they treat them (rightly so) as product demos. Their real bread and butter is in licensing the processor cores. Spending googols of dollars on chip packaging (individual pins on a chip's package is *rediculously* expensive) may not be cost effective for WDC. Thus minimizing their pin count is very much in their best interest.

We'll see though. This is what makes predicting these things so fun. It's not whether you're right or wrong -- it's about exercising your brain, reading the writing on the wall, and challenging yourself to see how well you really know what's going on in the industry.



I have never considered a PLCC package hacker friendly, I don't now, and I never will in the future. While there are wirewrap sockets for PLCC chips, it's also true that you get raped, beaten, hung upside down in bamboo cages in some steamy jungle, dipped in dung, and flung out to sea if you purchase them. Compared to DIP sockets, a PLCC socket can easily dominate the cost of a homebrew project. It's rediculous.



They would be insane and inept to challenge the market that ARM has utterly dominated for the last 10 years. I mean, it can be done, but the resources you'd need to throw at it to succeed are immense. This is why you never truely see independent automotive manufacturers these days. The established "Big Three" are so well entrenched that you're spending 80% of your revenue to compete with only 5% of investment by the big-boys. With a mere 6%, they'd put the independent out of business in less than a year. In fact, a brilliant example of this is how the big telcos put a HHUUGGEE amount of local ISPs out of business by dropping DSL prices below profitable margins, relying on their massive cash reserves to absorb the hit until the locals fell out of the market. Illegal? You bet!! But it didn't stop them.

WDC needs to stay in business, and that means finding and exploiting a niche. While I suspect that they can compete admirably in the PIC/AVR market place, I strongly doubt that Terbium is well positioned for that. That is where the W65C02-based microcontrollers can really shine. W65C816-based systems make good automotive-grade computer processors, and as I recall, the 6502 and 65816 do have their largest application in the automotive sector. Where will Terbium be placed? It's hard to say -- I really don't know.



Possible. But unlikely. I think the first generation Terbium chips will be a raw processor, allowing people to get used to the architecture, just as the 6502 and 65816 processors are used in things like trainers and such.



Well, we know already it's not gigabytes, because they claim the external bus width is 16-bits. So, a word is either 16-bits, or 32-bits. I suspect it is 16-bits because it is the most convenient size.

They can use all the same logic for controlling the bus as what is in the 6502 processor, almost verbatim. The bus transceivers will have 16 bits instead of 8-bits. Thus, the smallest addressible unit of memory becomes the "word" (really, by the definition of 'byte', it is a true byte, but since 99% of all people aren't aware of the history of the 'byte', they say 'word' instead).



Remember that with the introduction of a new processor comes a new line of support peripherals. Garth indicated that Bill Mensche had full intentions on replacing the current 65C22 with a bug-fixed design. Will this new peripheral retain the 16-bits of parallel I/O, or will it be a 32-bit I/O device?



I was distinctly under the impression that the Thumb instruction set is the single most revolted against innovation of the ARM architecture. While it's true that it cuts memory space requirements by 50%, it's also true that it *apparently* (I don't know for sure, not having programmed an ARM) also cuts out half the registers, and about 80% of the architecture's most salient features out of the equation too. I've read a lot of online discussion posts that indicates that using the 32-bit instruction set often results in code that is the same size, or bigger by no more than 20%, than the Thumb code if coded properly (e.g., by hand), while retaining the full capabilities of the architecture.



As I posted above, they don't need to use the WDM instruction if they redefine the platform's concept of a byte to be 16-bits instead of 8 bits, because you now have all those extra bits to use. Old code will still run with a 16-bit byte, provided the processor is aware that it's running old code. And, the only thing That means adding one more emulation bit (keeping the 65816's E bit and calling it E8, and adding the new E16 bit for emulating the 65816 itself).



Actually, that's not even necessary. Zero-page can be cached inside the CPU, using 16-byte cache lines, with ordinary caching techniques. The only distinction between that and a normal cache would be the ability to directly feed a cache hit into the other ALU input concurrently as the A register is fed into the primary input.

But, yeah, I agree. Zero page and RISC registers have an awful lot in common.

I think it depends on how sophisticated of a bus they want to have and if they consider a microprocessor viable. I was thinking under the assumption that people would either want an embedded PC or a microcontroller and forgot about an embedded-ish microprocessor.



See, I consider PLCC packages hacker friendly in that you can actually get sockets for not totally absurd amounts of money that adapt to DIP. Compare to the various QFP and BGA packages, where your best option is to just get a tiny PCB header made.



Yeah.

See, I'm thinking under the assumption that the people who are currently buying the AVR and PIC processors are going to want a little more processing power and stuff. So, for somebody, there's a certain appeal to not competing with the ARM head-on, but instead to handle this new more-power-on-a-single-chip area of the market that various folks have been putting their processors into.

And also, personally, I'd LOVE to have a Terbium microcontroller with a reasonable amount of internal RAM and ROM and IO ports. Remember, if you want more than a few k of memory on an AVR or a PIC, it usually needs to be external.



The only problem with the 16-bit-byte is that it can lead you to odd contortions to handle 8-bit-byte access in certain languages *cough*C*cough*

If they don't do the 16-bit-byte, the WDM instruction would help them retain a good amount of code-density.

I may have been wrong about the Thumb instruction set being something people were fond of.. hee hee... but the desire to have the ability to offer a more compact executable is there.



Actually, that's not even necessary. Zero-page can be cached inside the CPU, using 16-byte cache lines, with ordinary caching techniques. The only distinction between that and a normal cache would be the ability to directly feed a cache hit into the other ALU input concurrently as the A register is fed into the primary input.

But, yeah, I agree. Zero page and RISC registers have an awful lot in common.[/quote]

I guess it depends on how much modifications they are going to require software to have to work on the Teribum. They do have the option of skipping out on a cache... or at least making it possible to skip out on a cache... but still retain that 256 word direct page store.