Quote:
I'm puzzled by the memory map in his design.
He appears to be throwing away half of the 62256 32kB RAM to make space for the I/O, still leaving 32kB left over for ROM.
(strictly speaking, writes to the top half of the RAM chip's address space will still reach it, but you can't read them back because ~OE is tied to A14)
Ben pretty clearly got it from the
address-decoding page of the
6502 primer and the top of the
circuit potpourri page. I published it over seven years ago, and have been using the scheme for another 20 years prior to that, in my primary
workbench computer. I'm glad it's getting used; but it would be nice if he would give credit.
Beginning computer builders tend to make the address-decoding logic very complex, forgetting that each level of discrete logic has substantial delay (and that something like the '138 has a lot more delay than a simple NAND gate), and greatly reducing the maximum operating speed of the computer. Speaking only of program space, 64K is an absolutely
huge amount of memory for a single person to fill up in assembly language or any of a lot of other languages likely to be used with such a computer. OTOH, if you need a lot of
data space, then yes, 64K can be very quick to fill up, if for example you're getting the data from an A/D converter and getting tens of thousands of points per second (which I've done). But if that's the case, the 65816 is a much better way to go, or store the samples in a many-megabyte SPI flash memory that's interfaced through the I/O.