Hi All,

I have difficulty visualizing hex addresses especially coupled with the address decoding as set up by Ben Eater in his 6502 project. I set up an Excel spreadsheet which shows any address in the 6502 range, the pins addressed, and which device it is pointing to. I found it quite useful in getting a better understanding of the address logic. I hope these attachments work as I haven't tried this before.

I'm not familiar with Ben Eater's 6502 memory map but I must say the interactive spreadsheet is pretty sweet

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

Ah yes, thanks.

His memory map is from Garth Wilson's single IC address decoder circuit: https://wilsonminesco.com/6502primer/addr_decoding.html

See below for the image from: https://wilsonminesco.com/6502primer/32 ... Mlogic.jpg

It inverts A15 with one NAND gate, and that is fed into /ROM_CS and /ROM_OE (using leading "/" to mean active low), so /ROM_CS and /ROM_OE are active low from $8000-$FFFF.
/ROM_CS := /ROM_OE := NAND(A15,A15)

It selects a 32K SRAM when A15 is low and Phi2 is high by taking that inverted A15 and combining it with Phi2 so that SRAM is only selected in the second half of the clock phase:

/RAM_CS := NAND(Phi2,NAND(A15,A15))

It feeds A14 into the /RAM_OE, so RAM only outputs in $0000-$3FFF, using 16KB of the 32KB RAM. Note that /RAM_OE is also active low in $8000-$BFFF, but in that range RAM is not selected.
/RAM_OE := A14

It derives the /IO_SELECT by taking the NAND of A14 and the inverted 15 line, so /IO_SELECT is active low in $4000-$7FFF:
/IO_SELECT := NAND(A14,NAND(A15,A15)

Then it can take advantage of 6502 bus I/O chips like the VIA that have two selects, one active low and one active high, by tying one of the address lines from A8-A13 to the active high select and /IO_SELECT to the active low select.

You are free to extend that down to up to 10 "slots" with A0-A3 for register addressing, but with such a massive I/O memory mapped space available, using A8-A13 means that the device is the first two digits of a hexadecimal address and the register address in the device is the second two digits.

You avoid the problem that an address like $7F04 (%01.111111.00000100) would select all of the I/O device by "don't do that" ... you only use addresses with one of the address lines A8-A13 high:
%01.000001 = $41 ... Device0 = $40+2^0
%01.000010 = $42 ... Device1 = $40+2^1
%01.000100 = $44 ... Device2 = $40+2^2
%01.001000 = $48 ... Device3 = $40+2^3
%01.010000 = $50 ... Device4 = $40+2^4
%01.100000 = $60 ... Device5 = $40+2^5

If you want to put an active low shift register or a latch in that I/O address you can use a couple of NAND gates for active low:
/IO5 := NAND(A13,NAND(/IOSELECT,VCC))

A single quad NAND could put three single active low select parts on Device3-Device5 that way. Or you can also fit a single active low select part as Device5 and a single active high part as Device4:
/IO4 := NAND(A12,NAND(/IOSELECT,VCC))
IO4 := NAND(/IO4,VCC)

Garth also has a version of a single chip Address Decode for 32KB of RAM from $0000-$7FFF, IO in $8000-$BFFF, and 16KB of ROM in $C000-$FFFF. With that one, if you have a 32KB ROM, you can put the ROM A14 line on a jumper between VCC and GND and have two different ROM banks ... you could even dedicate a VIA GPIO to ROM A14 and have software selectable ROM banks. IMHO, that one is more interesting for a Forth system, since I would like to have a Kernel jump table to load and save RAM images and common I/O routines and core primitives I am not going to monkey around with in the ROM and a (separated header) Forth dictionary in RAM, so I would have more code in RAM than is common with Ben Eater's "reprogram the ROM and see what happens" approach.

Thanks for that. I know I've skimmed through Garth's primer several times but unless I'm in the right context I don't really remember what I'm reading.

I did wonder how Garth managed to decode six 65xx support ICs given both the ACIA and the VIA only have two chip selects. And, of course, I was questioning that before I read the rest of your message .
I'd started drawing how it worked before I read or thought about your answer. It's very clever! Just use restraint when programming to make sure that two support ICs aren't selected at the same time.

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

And, after all, when you have an assembly language source, you define the device address in the definitions section at the top. So while it might "feel like" tightrope walking when looking at the holes in the I/O address space, it's not really an issue ... as Garth says on the back of far more experience than I.

Indeed, if for some reason I was using the trick that you can access parallel registers at the same time, I expect I would let the assembler do the logic for me, and do it with an OR: "STA (VIA1 | VIA2)+DDRA"

I would be inclined to reserve A0-A4 for register addresses, so if I was selecting individual IC's (shift register or latches), I would be inclined to use the A5, A6 and A7 selects for individual IC selects, making those $4020, $4040, and $4080 (or $8020, $8040 and $8080 in the $32KB usable RAM version).

I was also vaguely wondering about malicious code. But not likely I suppose. The chance of someone getting to sneakily run code on someone else's board without access to the board (and a hammer) seems ... small.

Looks like you're not the first to struggle to visualise the address layout. Adrian and Michael have both drawn up aids too.

Same. Would be so much easier if only humans had 8 fingers...

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

Here is the memory map file I use.

I have various areas colored like Zero Page, the Stack, VIA, ACIA, visible and offscreen areas of the Display as well as the mapping of the ROM in my version of EhBasic.

Since I'm spending so much time working with the display and images I find it better to visualize the memory mapped out like the screen is at 128 byte alignment.

I like being able to scroll around and see what fits where. It was helpful when EhBasic started to grow because of the functions I was adding and I was also storing sprite data.

https://github.com/Fifty1Ford/BeEhBasic
(Edit.. Removed PNG... Too big. Slow to load.)

Last time I looked I *did* have eight fingers... different in the big city, I guess

Neil

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

no idea what kind of software you tried, but Libre Office (or really any modern Excel compatible software) works fine with .xlsx files.
Now i'm interested in what format would you suggest considering that Libre Office is already a very common piece of software (IIRC it comes bundled with Ubuntu).
i guess .ods would've been an alternative

Here is that PNG I removed.

I think this is a logical way to view the memory layout of the 6502 in this system.