Whatever happend to 65T32(Terbium)?

[Velociraptor]

Hi!

A long time 6502 fan here...

I'm interested in knowing whether WDC is still working on the 65T32? Is there any info on the CPU itself, even if the project has been abandoned?

[Nightmaretony]

Still running, not dead, far as I know...

[BigEd]

Really? I thought it had been abandoned, at the point that 'Terbium' was adopted as the name for the development kit (or for the 65xx architecture generally) - Jan 2007 I think. Prior to that, there was a public call for joining a special interest group back in 2004 - I would suppose that there was not sufficient interest to continue development.

Cheers
Ed

[BigEd]

Bitwise previously found a document describing the 65832 (W65C832) and explains it a bit here

Cheers, Ed

Edit: fixed up linkrot

[GARTHWILSON]

The word on the 65832 was that the design was completed (this was many years ago) but that they weren't going to produce any hardware until/unless they got an order big enough to justify it. (I'm sure you could still buy a license to use the IP though.) The Terbium processor was to be a higher-powered 32-bit processor, but they never gave any details, like whether the data bus itself would be 32-bit (unlike the 65832's which was still only 8-bit) and the address bus would be non-multiplexed like the 6502's.

I think the best hope for a real 32-bit 65-family processor at this point is the HDL enthusiasts. We have at least three on this forum (ElEctric_EyE, Arlet, and BigEd) who are actively working in that direction and apparently making good progress, first widening an NMOS 6502 design to double width and adding some features and calling it the 65Org16, and eventually (my hope) getting to the 65Org32 which we have discussed extensively in this forum topic to be similar to the 65816 but with all registers being 32-bit, including the bank registers which will be used as offsets instead so it's like everything is in a 4gigaword continuous zero page but the offsets make it all the more efficient at relocatable code, multitasking, multithreading, etc.. Some things would have to be added like a barrel shifter since shifts otherwise can get ridiculously long, and we would like a fast MULtiply instruction on it if not also a fast DIVide. For ease of programming and hardware design, the 6502 flavor is to be retained, otherwise there's no point and we might as well use something else that's already on the market. 32 bits of data bus and 32 (or close to it) of non-multiplexed address bus, plus the other control lines and a bunch of ground and Vcc connections would require at least 84 pins, but the internal resources needed probably only come in packages with a lot more pins than that.

When these enthusiasts work on it, a disadvantage may be that they only do it on the side when they're not working and they don't have to mow the lawn or something; but an advantage is that the result will be open-source instead of a closely guarded secret, and they don't have to see big orders to justify working on it like a for-profit business would.

[ElEctric_EyE]

I'm curious. What would anyone do with a CPU that has a 32bit databus?
Besides the obvious 24bit RGB video with 8bits leftover, and working 2 16bit stereo channels?

[GARTHWILSON]

ElEctric_EyE wrote:

I'm curious. What would anyone do with a CPU that has a 32bit databus?

In a higher-level language, you're always transferring addresses, and it would be a lot more efficient to be able to do that all in one gulp. If we limit ourselves to 64K addresses, 16 bits is enough; but for large data arrays, it definitely is not.

Next, any kind of math on bigger numbers, or even comparing a value to determine if it's time to stop looping, gets cumbersome if you cannot handle the whole thing at once. For testing memories of more than 64KB (even before my 4Mx8 module), I wrote Forth words in 6502 assembly for controlling loops with 32-bit index, limit, and incrementers so i wouldn't have to nest 16-bit ones, and it got ridiculously long. It works, but the program would be trivial (and very fast by comparison) if I had 32-bit everything to work with. Just having 32-bit registers would still be an improvement over 8 or 16, but it would be even better to not have to take the words apart to get them to fit through the the door every time.

In my control work on the workbench with my workbench computer, 16-bit arithmetic is usually enough but sometimes not, especially with something like a large fast Fourier transform where values add up over thousands of iterations, so you have to limit the input range to avoid overflows. 32-bit would take care of this, and again, being able to handle entire values at once instead of take them in installments would make it far more efficient. In this case, 32-bit is way more than twice the performance of 16.

[ElEctric_EyE]

GARTHWILSON wrote:

...In a higher-level language, you're always transferring addresses, and it would be a lot more efficient to be able to do that all in one gulp. If we limit ourselves to 64K addresses, 16 bits is enough; but for large data arrays, it definitely is not...

This "higher-level" language you speak of, is it based on a 6502 8bit(NMOS/65C02/65CE02 immaterial) machine opcodes? Or is there a total redifinition planned?
I've not looked deeply into the Terbium intentionally, because I don't want my 16bit ideas influenced by other ideas. Currently, all my 16bit opcodes are based on the original 6502 with the opcode matrix being 16x16x256=$FFFF...

[GARTHWILSON]

"Higher level" just means something above assembly language, whether it's Forth or C or BASIC or any of the gob of languages kc5tja was talking about. The processor itself still runs assembly language (or actually machine language), even if it is unknowingly carrying out something originally written in a higher-level language that makes the programmer more productive for bigger jobs. Assembly is fine for small jobs, including optimizing small, performance-critical portions of bigger projects, but it becomes harder to manage if you try to do a whole big project in it.

[Arlet]

Even without the use of higher level language, having a 32 bit address space makes it useful to have 32 bit registers and operations. On the 65Org16 dev board, if you want to access the SDRAM, you still need to load 2 ZP locations, and the Y register. And incrementing to the next address takes several instructions. Imagine you had a 32 bit Y register, and an LDA (Y) instruction, without having to use ZP. It would be a lot simpler and faster. And incrementing the address would be a single instruction.

[BigEd]

Yes - the main change I'd make to call a core 65Org32 would be the support of one-word addresses. As that's removing states rather than adding them, it should be relatively straightforward.

(To test such a core in the large, I'd also need a gadget to interface with 16-bit external memory.)

(Garth: other HDL practitioners here are Ruud and André, at least. Oh, and BitWise. But you're right to note that we three are closest to the 65Org16 and therefore the 65Org32.)

Cheers
Ed

[GARTHWILSON]

BigEd wrote:

Yes - the main change I'd make to call a core 65Org32 would be the support of one-word addresses. As that's removing states rather than adding them, it should be relatively straightforward.

There would no longer be ZP, Abs, and Long, like the '816 has (since everything is now in ZP), but there would be with and without the 32-bit bank-register offset added, with no bank boundaries like the '816 has.

Quote:

(To test such a core in the large, I'd also need a gadget to interface with 16-bit external memory.)

I see it as just putting two 16-bit memory arrangements together, putting their address and control lines in parallel and putting the data lines of one at D0-D15 and the other at D16-D31.

Quote:

(Garth: other HDL practitioners here are Ruud and André, at least. Oh, and BitWise. But you're right to note that we three are closest to the 65Org16 and therefore the 65Org32.)

Yes, thankyou, I knew there were others and it's good you point them out (and there are probably still more), but I wanted to especially give credit to the ones working on 65Org16 and toward 65Org32.

BTW, my avatar is a small portion of one of my cartoons in my 6502 interrupts primer.  Mike pulled it out and put it there a day or two ago when he was working on taking the forum to the new version of phpBB. I got a huge laugh out of it!

[ElEctric_EyE]

OT: Ah I like the new layout of the forum! Now we have avatars, heh.

Hmmm, all this talk makes me wonder why I spend so much time on the 65Org16.b. It is good excercise for learning though...

Getting rid of addressing modes might make it faster too. It's good we're all agreed? the core opcodes will be mostly NMOS6502, so a 16x16 base matrix would have 24bit= $FFFFFF=16.7million pages!

So looking at the current opcode matrix (which I happen to be doing alot lately!) , we would only be using imm, a, ax, ay addressing modes. So all zp, zpx, zpy, (zpx), (zp)y opcodes would just translate over to the right half of the matrix.

[Velociraptor]

Nightmaretony wrote:

Still running, not dead, far as I know...

really? That's nice news!

So, considering that Terbium has been announced years ago, what's the reason for this long birthing? What's the market they're aiming for? Any estimate on performance? Will it be a SoC design?

[BigEd]

Sorry Velociraptor, this might seem to be a thread hijack, hopefully it's just a little diversion...

GARTHWILSON wrote:

BigEd wrote:

(To test such a core in the large, I'd also need a gadget to interface with 16-bit external memory.)

I see it as just putting two 16-bit memory arrangements together, putting their address and control lines in parallel and putting the data lines of one at D0-D15 and the other at D16-D31.

Sorry, just to hop back and reply to this point: I was speaking personally, in that I have an FPGA dev board with a 16-bit wide memory on it (and another with an 8-bit wide memory.) In fact we've done all that we have with 65Org16 without yet connecting it to off-chip memory, because the on-chip memory of FPGA has been enough for testing, but we will want to hook up to a larger external memory soon, and we can.

In the case of 65Org32, existing dev boards (including EEye's board) generally offer only 16-bit wide memory. We'd be able to proceed by working through a buffer or cache, but of course we'd expect better performance from a full-width memory interface. Right now, I don't have that buffer or cache, so my starting point would be limited to on-chip memory - that's 16k words. That's all I was saying - it's not the biggest obstacle, which is time.

Cheers
Ed