16 bit values are AFAIK stored as two consecutive 8 bit values...

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

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

Please do help me understand this.




The CPU will work logically as 16 bit, but phisically as 8 bit, with those two consecutive 8 bit accesses. The high byte and low byte. Those two bytes should be stored somewhere. They are usually stored in memory chips with an 8 bit data bus.

So a 64K memory chip filled with 8 bit values could be understood as a 'virtual' 32K memory chip filled with 16 bit (high 8 bits + low 8 bits) values.

Am I right up to this point?

8 Mega_Words (16 Bit) = 16 Mega_Bytes (8 Bit).

For instance, MC68000 has a 24 Bit address bus, a 16 Bit data bus, and a 16 Mega_Bytes (= 8 Mega_Words) address space.
A0 isn't available outside the chip, instead of this there are the /UDS and /LDS signals which enable read/write of the upper and the lower Byte on the data bus.

If you would have a 65816 with a 16 Bit data bus, I think it also would have something similar like MC68000 /UDS and /LDS.

So, with no MMU and by directly using the full 24 lines of address bus, the '816 will handle 8 Mega_words of address space.

But there are no opcodes stored as words but only as bytes, the 8 Mega_words address space is only useful for data.

I'm wondering about how forcing (by hardware) the '816 to always doing 16bit reads and writes would be more a problem than anything else.

I mean... the '816 do always reads bytes. LDA #$02 is always assembled as A9 02 00 if the compiler detects that the code is to be run in native mode.

When the '816 reads A9 and the M register = 0 then it will read two bytes more. So those are three bytes.

But what would happen if the '816 would have one of the proposed circuits in another thread, set between memory chips and feeding always 2 bytes? There would be a time that the order of the bytes would be reversed...

What do you think?

If you always do 16-bit fetches, you can still fetch them from odd or even addresses and with 24 bits have 16M addresses. If you're talking about only allowing fetches from even addresses, then you no longer need the least significant bit A0 and the 24 address bits let you address 32M addresses. In that case, you'll need to devise some scheme to access bytes at odd addresses. You might accomplish that by having the user load 16 bits then providing an instruction like swap to extract the high byte of the fetched 16 bits that was at the odd address. You could also do it in hardware and let it be transparent to the user - when they ask for a byte at an odd address, the hardware fetches 16 bits from the corresponding even address then uses circuitry to extract the high byte and routes it to the right register. It doesn't really matter how you do it.

Most microprocessors address memory by byte index: memory is always logically an array of bytes. Those microprocessors which allow for access of multibyte values can be built in one of two ways: one way is only to allow aligned accesses, and the other is also to allow misaligned accesses.

A machine which only allows aligned accesses does in some sense have a view of memory as an array of words - but every address is still a byte address, so it's not a strong sense.

Both kinds of machines start a multibyte value at some byte address and include bytes at higher consecutive addresses.

In all cases, the programmer view is a simple one of what to load or store, and the memory controller's job is to make the right series of accesses to the memory and join the pieces together.

There are also machines, less often seen these days, which access memory as words at consecutive word addresses. If they offer any finer grain of access, and they needn't, they have to invent a means of accessing something at a fractional address.

The '816 is a byte-addressed machine, with some means of accessing 16 bit quantities. (The 6502 also accesses 16 bit quantities, in limited ways: JSR; RTS; JMP (indirect); LDA (indirect),X and so on.)

tokafondo, I'm not out to discourage you, but:
I think, that you are out to jump into a rabbit hole that could be really deep.

In general, I would say that the design effort which is necessary to build a 65816 which _really_
makes efficient use of a 16 Bit data bus (16 Bit instruction prefetch mechanism etc.)
is not justified by the resulting _netto_ speed gain.

You would end up with a wider data bus, that yes, but with a lower maximum CPU clock speed,
because more complexity in the CPU means more circuity (resulting in bigger capacitances and propagation delays).

Unless you would be going for a deeper pipeline inside the CPU,
but then it would be difficult to make the CPU cycle compatible to the original 65816,
what could cause compatibility problems with some of the 65816 software (games etc).

Designing a fast CPU means making a compromise between speed, complexity and compatibility (and price).

To put it this way: it's difficult to design a car which can be bought for $20, able to run at 300km/h, burning 6 liters of fuel per 100km while doing so.

For implementation, it's worth considering a memory controller between the CPU and the external bus. It's the job of the memory controller to fire off the right accesses, to deal with byte enables and misaligned words. The memory controller is then also a good place to put a cache - either a single unified cache or possibly separate instruction and data cache. And the interface between the memory controller and the CPU need not be a single bytewide bus, or wordwide bus - it could separate out instruction fetches, direct page reads (from early in the pipeline), general reads and writes (from later in the pipeline.)

Yes, you can think of it as 8 megawords or 16 megabytes -- same thing.

And if an '816 were created with a 16-bit data bus, it would have 23 lines of address bus, plus the /UDS and /LDS signals which Dieter mentioned (above).

IOW, the chip would always output a 23-bit address specifying one of 8 megawords.
- if only /LDS is active then that's an access to one half (one byte) of the selected word.
- if only /UDS is active then that's an access to the other half (byte) of the selected word.
- if both /LDS and /UDS are active then the entire word (both bytes) are accessed at once.

That's why A0 would not need to be available outside the chip.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

It seems then that the 16 bit data bus style should be used then with other chips instead of memory.

The memory would be always read as the '816 is designed to, and the 16 bit data bus created from using the circuits proposed in other threads would be used, as already said, to drive chips that would need it as the IDE adapters as an example.

Thanks all for your reponses.

Maybe I'm over-thinking or over-simplifying, but ISTM that it could work, but the only way it could be consistently faster than the byte-aligned original would be to break software compatibility and allow only word-aligned addresses ... unless you put a lot of effort and complexity into the memory interface (x86, anyone? ). The 68k doesn't suffer from a deeply-ingrained 8-bit bias like the 65xx.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)