After looking into some 16 bit computers (for educational and entertainment reasons), I started wondering how expensive 16 bit SRAM is.

According to Mouser, it's substantially more expensive! And, a bit slower.

How much more complicated do you think using two 512K x 8 chips would be compared to one 512K x 16?

Or, is that even practical with a 65C816?

_________________
Cat; the other white meat.

The '816 has an 8-bit data bus. How were you envisioning using a 16-bit SRAM? (There are a lot of new posts this morning, and maybe you told elsewhere and I just haven't gotten to it yet.)

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

Actually, I'm not actually sure. My only knowledge and assumption is that I *thought* the IIgs used 16-bit RAM with the '816. But now that I think about it...maybe it didn't? Especially since it had IIe compatibility.

Truth is, I just don't know that much about the '816.

But, if that's the case, how is it truly a 16-bit MPU?

_________________
Cat; the other white meat.

256K x 16 is no more expensive than 512K x 8...

http://www.digikey.com/product-search/e ... ageSize=25

All parts currently active, and available as fast as 10ns.

If I knew my current revision would be using a 16 bit data bus, I would have purchased these instead.
For now, I am just paralleling the address busses together and a pair of 512k x 8 SRAMs. Same end result.

There is no difference in operation, except that the 16 bit SRAM offers the ability to mask the Hi and Lo bytes for RW.

Brad

The problem is that the '816 generates two consecutive bus accesses to read or write a word. The first access does the least significant byte and the second one does the most significant byte. So you'd have to somehow figure out how to cycle between the LSB and MSB data lines of the SRAM according to what the '816 is doing. As the '816 doesn't have an output to tell you which byte is being written I don't think what you are envisioning with a 16 bit RAM is doable.

Using a pair of 512KB × 8 SRAMs is not at all difficult. You wire A0-15 of both RAMs to A0-15 of the '816. A16-18 of both RAMs are wired to bits 0-3 of your bank address latch. /CE of the first RAM (RAM0) is asserted if bit 4 of the bank address is zero, which corresponds to $000000-$07FFFF. /CE of RAM1 is asserted if bit 4 of the bank address is one, which corresponds to $080000-$0FFFFF. The result is 1 MB of addressable RAM.


It has a 16 bit ALU and the accumulator and index registers can handle 16 bit values. Arithmetic, logic and load/store instructions can process words or bytes as required. In this respect the '816 is similar to the Intel 8088.

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

The problem is the '816 does not tell the outside world which part of a 16 bit memory cycle is occurring. How would you tell the 16 bit SRAM which data lines to use?

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

Not knowing the 816, I cannot offer much there.

If one had a fast enough SRAM, it would certainly be possible to use the AB line on a set of 74HC157s to select the bits.
Drive this from a master clock, but then drive the 816 from CLK/2 perhaps?

... just thinking out loud.

Brad

Thanks everyone for clearing this up. I had some wildly false assumption on how the '816 worked.

_________________
Cat; the other white meat.

It's not that simple. The logic would have to know if a 16 bit read or write is being executed. The only clue the '816 offers comes from the M/X output, which tells external logic the current register widths (M is memory/accumulator and X is the index registers). However, M/X doesn't tell external logic which register is being loaded or stored. So you still wouldn't know if the current memory access cycle is eight or 16 bits.

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

BDD is right. Internally they have 16-bit registers and are perfectly fluent with 16-bit operations, yet they have only an 8-bit data bus for loading and storing data from the outside world. Compared with a 16-bit data bus, the 8-bit bus saves space and reduces cost, but it transfers only 8 bits per bus cycle. It's necessary that a 16-bit load or store be done in two halves, requiring two bus cycles rather than one.

Whether an '816 or 8088 can be considered a "true" 16-bit MPU depends on whose definition you use.


We want to connect a 16-bit RAM to the '816, is that what we're talking about? (Of course an '816 won't get any extra benefit from a 16-bit RAM, so the proposition seems unlikely. But it is easily possible to do this.)

16-bit RAM's like the ones Brad linked to are organized almost exactly as if they had a pair of ordinary 8-bit RAM's inside. And from an external POV you can treat them accordingly. IOW you can take the RAM's two 8-bit data buses and tie them together, just as you would with a pair of individual 8-bit RAM's.

There's a minor wrinkle in regard to the glue logic. One of the CPU address lines (one not otherwise attached to the RAM) would be used to feed the RAM's BHE\ input. The same address line, but inverted, would feed the RAM's BLE\ input. (Or BHE\ and BLE\ can be interchanged; it doesn't matter.)

It's true the RAM won't know why the '816 is accessing a given byte, or whether that access represents half of a 16-bit access, but these details aren't essential for getting the job done, and "mushroom management" will suffice. Each cycle has, at most, one simple, 8-bit operation: ie, read the byte from this address. Or write to it.

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