In this video series, I'll build a basic 6502 computer with an LCD display and a few buttons, explain how to program it in assembly, and write a game or two.
Videos
This series is in progress and more videos are on the way soon!
If these videos turn out as well as the SAP-1 and video card, we will have a new "newbie" link to go with Garth's primer (which enabled my own sbc design/build)
I'm hoping he pairs it with worlds worst video card in the future.
Not sure why he called it the world's worst video card. It was actually pretty nice.
Years ago I created a PIC based B/W video "card" that literally had two pixels for the entire screen. One black and one gray. The entire NTSC screen was 2x1 pixels.
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)
It's a valid strategy if you want to simplify the address decoding as much as possible, want to use as much of the address space as possible, and if you also think code will be larger than data. If the reverse is true, you would want to put the I/O overlapping the ROM area instead.
For my 6502 Fake Finder, which has fairly low memory requirements, I'm using 8Kx8 RAM and ROM parts which are about as cheap as they come. The address/control logic is literally two chips - a 74HCT00 and a 74HCT138. This still leaves big 8KB gaps in the memory map where there simply aren't enough I/O devices to fill it, but who cares? For a more ambitious machine I would of course take more care.
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.
