Nearby, enso offers an FPGA dev board suitable for a wide-byte 6502, with 1MByte of fast SRAM. I'd like to hear in this thread from everyone who has an interest in making, experimenting with or using one of the wide-byte 6502 variants.

(The major point of a wide-byte machine is to offer a 32 bit address space on a CPU which is reminiscent of a 6502. See footnote for more.)

It's been a few years since we've had an implementation of 65Org16 (which sprang from Arlet's 6502 core), complete with emulators, assemblers, a minimal boot loader, and ports of TinyBasic and eForth. (ElEctric_EyE took the idea and ran with it, making a series of graphics processors using a further variant of 65Org16 with a larger register file and some register-register operations. Making a further variant of a simple existing core is a good way to make incremental progress and test out ideas.)

On the other hand, the 65Org24 and 65Org32 are just sketches of ideas, with no implementation or emulation yet. In fact the 65Org32 has two variant sketches: let's say my 65Org32e is a super-simple variant of 65Org16 whereas Garth's 65Org32g has base registers for program and direct page relocation, and something more like a 65C02 instruction set, perhaps also with a barrel shifter and multiply.

Did anyone other than EEye and myself run 65Org16 in hardware?

Who's interested in pushing on to write HDL for 65Org24, the simple 65Org32e or the complex 65Org32g?

In the absence of concrete progress, 65Org16 remains the only practical extended core to target for tools and applications. Even an OS... So, who's interested in writing software to run on 65Org16?

Footnote: wide-byte machines offer a 32 bit address space by making all accesses to memory wordwide - 16 bits for 65Org16 and 32 bits for the wider variants. It might seem that this would make it difficult to work on 8-bit I/O devices or to work with strings, but that's not so. There's a tradeoff of simplicity for memory density. This approach also forestalls spec creep and shortens development by keeping the machine's structure close to an existing HDL core. Almost all discussions of 6502 extensions, enjoyable as they are, end up with loads of ideas and no implementation.

Postscript: I can't find a description of 65Org24(*)... what I mean by that is a 65Org32 with the operand truncated to 24 bits and merged with the opcode. All instructions now fit in one word so program memory usage is nearly halved. Some operands are too big to express, so they see something like a 24bit window on the 32bit address space. Some immediates will need to be constructed indirectly. This variation has somewhat less room for opcode expansion, as a consequence of denser encoding.

(*) Edit: I found it here viewtopic.php?f=10&t=2825

Edit: I realise there must be space here too to include other wide CPUs, such as Rob's RTF65002 and Mike's 65m32 (need a better link). If I've forgotten other current wide designs, my apologies - please correct me.

Edit: better link for 65m32

I've studied the 65Org16 some and have some interest in wide byte-6502 variants. But I think the wide-byte paradigm may be too simple an approach. There are a lot of byte-code oriented stuff out there so the cpu should be able to read and write bytes even if it's a native 32 bitter. The 65Org16 might be acceptable for some solutions, but I don't think extending the idea to 32 bits would be very popular.

I've been thinking about making another 32 -bit accumulator oriented cpu having worked with the RTF6809 recently. The 6809 with extended addressing is almost like the 65Org16. It's almost the same processor but with a different object code. The RTF6809 has the 6809 registers (D,X,Y,U,S) which are 16 bits equivalent to the 65Org16's 16 bit registers (A,X,Y,S). It supports indirect addressing to gain the 32 bit address space.

I think that using oddball instructions lengths may not be that big of an issue, so it should be possible to stick with a byte code like the 6502's even for a 32 bit machine.
For example, LDA #12345678 would take five bytes to perform. Other instructions like INY or INX would remain a single byte. The trick may be to use a wide window into an instruction cache for the processor. With an eight byte (64 bit) cache window one can read any number of bytes (up to eight) in a single clock cycle that one desires for an instruction. So there's no performance loss compared to the eight bitter.

Any machine which supports a varying size of data is going to be somewhat more complex than a machine supporting only bytes.

_________________
http://www.finitron.ca

It has to be said, once a person has written a core of their own, they are in a good position to innovate with the instruction set and architecture! 65Org16 was conceived from a position of never writing a core, just modifying one.

One way to look at the wide-byte choice is that it makes the machine only source code compatible at best - like 8008 to 8080, or 6800 to 6809, very approximately. You reuse the same mental models, slightly expanded, but you do have to assemble from source and do some tweaking. I think Bruce has said that porting to 65Org16 wasn't too different from porting to '816.

It's clear that a machine with both byte and word accesses, and with more addressing modes and more registers, is going to be more convenient for the programmer, provided the model isn't too difficult to grasp. And, as you say, more complex for the implementer (and more difficult to verify.)

Someone - might have been you! - recently pointed out that large symmetric register files were a useful and necessary development to support C compilers, but if we're not planning to support C especially well, that becomes moot. It's a useful insight.

Before I was done reading above, I was thinking Mike's 65m32 is already well on its way and has a chance of becoming reality. He has other things on his plate and might need help, but I know he'd probably have to let go of his baby just a little bit (since helpers will have slightly different ideas); and it's up to him whether or not he wants to do that. The 65m32 bears a lot of resemblance to the 6502, but also diverges quite a bit in some areas. His design lends itself to a very 65-flavored assembly language which I would recommend implementing even if some of the more advanced functions mix in the assembly language of his own creation. A lot of operations could be specified in more than one way and still yield the same machine language; but preserving the 65 approach will gain it a lot more acceptance, since people already think in that language.

I have not been watching Rob's RTF6809 closely, but he has a point in that even with an 8-bit data bus, huge performance benefits can come from having wider registers. The '816, in spite of its 8-bit data bus, handles 16-bit quantities far more efficiently than the '02, in ease of program writing, and in code compactness, and in execution speed. But rather than just extending the 6502 to greater widths, the new processor needs to address the needs that will become more and more glaring as the door is opened to multitasking, relocatable code, and other things that the '02 was poorly suited to. The '816 does some of this, but I would like to see it taken further.

This is why my idea of the 65Org32 was basically an '816 with everything except the status register extended to 32 bits. The bank registers become merely offsets in the 4-giga-long-word address space; and having these to be 32 bits gets rid of the bank boundaries and makes it so programs stacked on top of each other in a multitasking environment can each think they they start at whatever address they want, and they can be any length without dealing with 64K bank boundaries. The same is true for their data. Want to index in a huge array (like for music files or hi-res photos) with X or Y? No problem. I suppose it's like having an MMU onboard, although I'm not qualified to make a real comparison.

I remember earlier efforts, particularly the 65832 design which was finished by WDC but never put into production, and Gideon Schweitzer (sp?) and friends' 65GZ032 which was actually running but still needed various things worked out. These had design goals of still being able to run already-assembled 6502 code, a requirement I hope we can drop because of the complexities and limitations that come with it. The 65GZ032 in native mode was hardly a 65-family processor, but rather a RISC.

I personally don't have any interest in compiling C, but there will always be those who do. Does being a good C target almost automatically exclude a real 65-family processor? I would however like to be regularly handling 32-bit quantities in Forth (not just 24-bit for addresses) as nimbly as the '816 handles 16-bit quantities. I have little interest in a wide 6502 without at least the CMOS instructions and addressing modes, although I don't need the decimal mode.

_________________
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?

I am interested, but I don't really count (biologist; not physicist or engineer ). What is it? Is it new hardware? New way of wiring and coding 65816? Or an IC made specially for the 6502-nut, seeking bigger and wider buses/data widths?

(P.S. though I claim to be a just a mere biologist, I am a bit of a ringer. I once ran the Rapid Thermal Anneal machine in a semiconductor manufacturing plant, but that didn't mean I understood what it did. "I just let the robot (boat) do all the work, that was my secret"~Bill Murray, in "What About Bob". Apparently the tortured, extra-crystalline, atoms were happier--less stressed--when I was done.

My 5 robots were the best wafer cookers in the whole factory!

The idea of these variant cores is that we run them in an FPGA - either on an FPGA dev board, which can be had for $50 or more, or on a custom board. An FPGA is a species of programmable chip: at powerup it reads a block of configuration data from a memory and configures its hundreds of thousands of logic gates according to that. At some point someone designed the circuit which the FPGA should be, and created the necessary configuration, which is called a bitstream. A subsequent user of the circuit just needs the bitstream and needs only understand the system-level behaviour of the chip, not the internals of it. It's quite possible and relatively common to put a 6502 or Z80 design on an FPGA, possibly also with designs for various peripherals. Many 8-bit micros were simple enough for their entire design to fit on a cheap FPGA today. But for the present discussion, we're considering our own CPU designs, which often bear a family resemblance to 6502 but with some interesting variations.

Having made a variant design, one realises that one also needs software to run on it, which means needing at least an assembler. The end-user who might want to play a game or run a spreadsheet is still a long way off.

Probably we need another thread if we're to cover the basics: please have a look around for existing threads which answer your questions, and if you don't find one, feel free to start one!

I have been tinkering with the final design, and have floundered for about a year. Garth, Jeff, and Dieter were very helpful and encouraging (especially Dieter), but it wasn't enough to push me to the finish line. Dieter stopped helping for unrelated personal reasons, and that was a huge loss for me. I haven't given up ... just took a couple of detours and potty breaks. The finish line is still out there in the distance, and I'll keep plugging away until it's done or I suffer a fatal stroke or something.

Here's a sample of what Garth means:

Mike B.

Mike
do you have any summary or diagram anywhere which describes what the 65m32 is? I couldn't find anything.

Edit: I found something! See here
viewtopic.php?p=27613#p27613

AIUI, it's a highly symmetric machine, with 8 registers and 32 bits for all operations (including memory.) All instructions have the same encoding: 6 bits of operation, 2 of addressing mode, 4 for predication, 3 to specify the indexing register, then 17 bits of operand which is sign-extended before use. As PC is one of the available indexing registers, it's possible to pick up a 32 bit word from the instruction stream and skip over it by using an auto-incrementing mode.

Certainly interesting!

Sadly, I'm not ready to post the full specification, although I shared some woefully unfinished versions with Garth, Jeff, and Dieter. My unique feature is the concept of "indexed immediates" ... the rest have been done before in various other designs, like 6809, pdp-11, and ARM. I'll shoot you a copy if you want, but be fore-warned that it's VERY rough around the edges.

Mike B.

Mike: no problem, and no rush. I'm glad now to have found a basic reference, and look forward to further updates as they happen. A simulation looked like it was nearly ready to run last time we heard, I think?

In other news, it seems I need to update my ideas a bit: I've been stuck with the idea that there is no open source 816 core and therefore the full-on 65Org32 which Garth has had in mind had no basis for implementation. That was true at the time 65Org16 got its start, but in the meantime (and some time ago now) Rob has made his bc65816 and now FT816 cores which might well be amenable to same simpleminded upgrade to wide bytes - if indeed they don't get some other upgrade to a 32bit memory space. It looks like FT832 is presently a 32bit machine addressing byte-wide memory up to 24bits of memory space. Here's the relevant thread.

Thanks BigEd; I'm vaguely familiar with FPGAs (Wakerly, digital design textbook). I'll stick to the newbie pages, but I stray sometimes and get curious. Your thread will make more sense now. (for some reason I thought the 65816 WAS a 16 bit processor...maybe because I was a kid and played super nintendo, and later read that the 65816 was the processor? SNES was a 16 bit wasn't it? Maybe not?

If I think about the data sheets I've been reading these past weeks, I think 65816 has 16 address pins, 8 data pins, and during first half (or quarter? I forget?) of clock cycle, the data bus acts as address high ("block") bus. I think I have that right? I am working on my memory map tonight; Is 16 MB--roughly-- what the 65816 can address?. *I suppose some fancy decoding might be in order, with such plentiful memory? Wakerly mentions a 74319s and 2 (or 3?) 74318s to make a 5 to 32 decoder. But I am not a "fancy-PCB" kind of guy, and 32 RAM chips sounds cumbersome. Perhaps I needed a bigger-Byte RAM chip? I hope I can find a compatible one.

Also, just bumped into some new-ish vocabulary; MebiBytes and KibiBytes? Spelt wrong? Oh well. Wide data sounds neat. Have fun!

@randallmeyer: Yeah, it's open to a bit of interpretation, but the wide-byte concept doesn't really apply to the 65816, because it still treats memory as an array of "normal-sized" bytes of 8-bits each, and an address points to an individual byte (or possibly the first of a small group of bytes) in that array.

Several of the processors that Ed mentioned pretty-much abandon the concept of 8-bit bytes. The instruction sets of these processors can still deal with groupings of 8-bits, but not without some effort, since they treat memory as an array of "wide" bytes, usually of 16 or 32-bits each. So, using my 65m32 as an example: if I want to load 8-bits from memory, I have to find the address of the cell containing those 8-bits, load the 32-bit cell containing those 8-bits and mask-shift to get those 8-bits in the least-significant end of my register, assuming that's where I want them. To do a general-purpose store of 8-bits to memory, I would have to do a load-mask-shift-merge-store. Although it's possible for these processors to deal with 8-bit quantities, it's a lot more work to do so, making it usually worthwhile to avoid them and simply deal with native-width quantities.

Mike B.

@BigEd: "nearly ready to run" could be said, but only for an EXTREMELY generous definition of "nearly".

I'll go back to my newbie pages after one more brief comment. You made something very clear to me, which had been fuzzy before; Perhaps now that I think clearly, I will write clearly about memory/bit-width in the future.

"It looks like FT832 is presently a 32bit machine addressing byte-wide memory up to 24bits of memory space"~BE

I hadn't really thought of RAMs/ROMs clearly before. I was wondering why they were named "256s" when they were 32KB; but I didn't wonder too much because 8 X 32 = 256; so it made sense. But I never really thought about the 8 bit data bus and the size of the accumulator. It didn't occur to me that they could mismatch; that you could have byte-wide data in the memory, and a byte-wide data bus, but a 2-byte-wide accumulator (and/or other working registers) in the processor. Seems potentially troublesome, but also more efficient for more bits being processed at a time.

(I suppose, when looking for RAM and ROM one must pay attention to their 256-chips? To make sure that they are 8 X 32 Kilo"places" (kilo-words). and not 16 X 16 Kilo"places" (kilo-double-words)? Are there double-word RAMS and ROMS (rhetorical question; don't answer it; I will look it up!)?)

I guess the opposite situation is almost standard; one of the first things learned about a 65xx system is that there is 16 bits address and 8 bits of data; necessitating at least two reads to load an address (absolute addressing mode). The situation with wide data might conceivably be reversed (converse? obverse? perverse?); op-code (like, say, ADC) must "know" to make two fetches of data before it can execute? is that correct? or fanciful?

Ahhh, well... I dunno.... probably made fool of myself. Back to the newbie pages I go !!!! (and Garth's primer; still barely cracked it open, but I carried the ones and zeros home on my back--like a digital sherpa--and I have them on my "air-gap computer" now. Now I can read it at my leisure and not worry about my internet connectivity, and specifically, the lack thereof.).

P.S. Back when I was first learning about electronics (2002-2004-2006 or so) I studied ASICs a bit, because I wanted chips to do things that weren't being done yet, but not at the prices--or volumes--that the "big boys" were interested in. I think this is the other reason I had heard of FPGAs; suitable alternatives to ASICs and/or fabless semiconductor companies, etc.

@barry ; Thanks. So data bus is generally the width of the accum. and/or working registers. That makes the most sense anyway; otherwise bottlenecks. I can see, for historical reasons, 16-bit address and 8-bit data bus, but now there is less reason for this to be the case. And lucky for you there is an FPGA for you to play around with, instead of hiring a 50 billion dollar semi-fab company to "get 'er done".