Hello
I am wondering if the 65816 and the 6502 has support for ports in a similar way to how the z80 has?

Also is the 65816 address space 24-bit direct access or is it paged? The data/address multiplexing is confusing me.

No. I/O is provided through memory mapped hardware on 65xx designs.

Others here can speak more knowledgably about the 65816 architecture, but yes it is banked (see the PBR and DDR registers).

The CPU outputs the high 8 bits of the target address on the data bus when PHI2 is low so it can be latched. When PHI2 is high the it can be combined with the low 16 bits of the address to form the target memory address for read or write access.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

The I/O is memory-mapped, and as far as the processor is concerned, it all just looks like memory. For example, if your program has an instruction LDA $480C and that area is RAM in your system, you will read the RAM (memory) byte there which could be some kind of variable you have assigned in your program for example; but if you have a 65c22 VIA (Versatile Interface Adapter I/O IC) with its base address at $4800, the same instruction will read the VIA's Peripheral Control Register. The exact complete instruction with op code would be AD 0C 48 (AD being LDA absolute, the non-indirect, non-indexed long form), and the whole thing will take four clocks, or "T states" in Z80 lingo if I'm not mistaken, one to fetch the op code, two to fectch the two bytes of the operand, and one to carry out the instruction. (And, BTW, the instruction has an implied compare-to-zero built in, so for example you can immediately follow it with a conditional branch on whether or not the fetched number is zero or negative.)


Many of the instructions have addressing modes that allow specifying the complete 24-bit address do it doesn't matter what the bank bytes are. IOW, you can have direct access. But if you had to specify all 24 bits (three bytes) of the address every time, your program would take more memory and run more slowly; so the idea is to make the banks work for you, not against you. You may have different tasks loaded into different banks, and each one can more-or-less think that it's in bank 0 and not have to use long-form addressing to access anything in its own bank. Even in bank 0 (ie, addresses 00:0000 to 00:FFFF), it is divided into 256-byte pages. The page boundaries are more transparent than the bank boundaries are; but having zero-page addressing on the 6502, and direct-page addressing on the '816 (same thing but it can be moved around instead of being stuck at 0000-00FF), allows you to have faster access to those prime locations through instructions that are only two bytes total, one for the the op code and one for the operand. It's kind of like having 256 processor registers, all usable for variables and and indirect pointers and so on, and all accessible in three clocks ("T states"). Many 8-bit processors can't do anything at all in three clocks. This addressing is why the low byte of longer instructions comes first. In the LDA 480C example in the paragraph above, the 0C comes before the 48 because when the processor is fetching it, it is still figuring out from the op code whether it will even need a high byte or not. If it does not, then having started with the low byte, it already has what it needs, so it can get the job done faster than it would if the order were AD 48 0C. And for addressing modes that have to add to it for indexing, the addition has to start with the low byte anyway, and it can get started on that while the high byte is being fetched.

The address multiplexing is often confusing to newcomers to the '816. It works simply though, and furthermore, if you don't need more than 64K address space, you can completely ignore it and still get tons of benefits from the '816. In this case you won't have to latch, decode, or use the high 8 bits of the address (ie, the multiplexed part), and you can ignore that the bank registers even exitst. Or, I suppose, you could use them as some kind of extra registers to store something in. It won't hurt anything.

All members of the 65xx family use memory-mapped I/O. A few versions, such as the 6510 and 8502 (both NMOS parts used in Commodore computers), also have an I/O port, although not all bits are wired. However, it is unlikely you would want to use one of those for a new design. There are no special instructions for I/O, such as the Z80's IN and OUT.


The multiplexing of A16-A23 on the data bus was primarily a cost-savings measure mandated by the original target system for the 65C816. It's a bit strange, but understandable once you've worked with it.

During Ø2 low, the '816 will place the lower 16 bits of the effective address on A0-A15, just as the other 65xx processors do. The data bus, D0-D7, will hold the A16-A23 address component, which has to be latched by external circuitry on the rise of Ø2. The presence of a valid address will be indicated by the VDA and/or VPA signals going high. When Ø2 goes high D0-D7 will revert to being the data bus.

As for addressing, the way in which the MPU accesses memory depends on what is happening at any given instant. Opcode and operand fetching is confined to a 64K segment, the exact segment being determined by the value in the MPU's PBR (program bank) register. For example, if the effective address is $00FFFE and a three byte instruction is executed, the PC will wrap around to $0001 but the PBR value will remain unchanged, resulting in an effective address of $000001, not $010001 as one might expect.

Access to data is linear within the entire 16 MB address space and can be controlled by either setting the data bank register (DBR) to any value between $00-$FF inclusive (assuming the RAM is actually there) or by coding a 24 bit address operand, e.g., LDA $1A2B3C. Also, indexed addressing will automatically extend into the next memory segment. That is, if .X=$01, the instruction LDA $01FFFF,X will effectively be LDA $020000. Extending that principle a little further:


also results in .A being loaded from $020000 in RAM. Hence it is possible to extend data structures across segment boundaries and not have to engage in any special tricks to do so.

The '816 has a number of stack-oriented instructions for managing memory access, a description of which can be read in the W65C816S data sheet.

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

Processing new information....
If I would want to make, say, a TRS-80 model 100 styled laptop based on a 65816 and using contiki as a operating system, Do I have to think of something special in my design? (512KByte of ram) or can I just map it directly?

Map what directly?

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

That's my question as well. GhstWlf, 512KB takes 19 address bits. The easiest and normal way to accommodate what you want is to have 512KB RAM minus a little bit in the first 64K for I/O and ROM. That means that not all of the RAM will be usable, but most of it will be. You would use the first 8 banks of the 816's memory map.

For the LCD for your TRS-80 model 100 copy, you can easily get intelligent character LCDs up to 4 lines of 40 characters each. Finding bigger ones can be difficult. You could go to a graphics LCD, but they are not as easy to interface to. If you find a keyboard source, I would like to know about it. That would be one very neat project if you can pull it off!

I was thinking if I should do something like this:

OR

Go with the second choice. It will work much better and more easily, both hardwarewise and softwarewise, than paging the rest of RAM into the 8000-BFFF window.

Sounds like a software question: how are you going to write and load programs, and will they be small programs with large datasets? Something like a dedicated photo viewer could keep all the code in bank 0 and page in data in a small window. Or a 16-bit OS could use other banks as a RAM disk. But a general OS might be better off presenting an almost-flat memory space.

I think the '816 is usually used(*) with the banks being visible - which is to say, mostly 16-bit addressing, and a program or data structure being contained within a single bank. As soon as you have code in more than one bank, you need to use 24-bit calls between them - which is to say, routines need to use 24-bit returns. So you either use 24-bit calls everywhere, or you have some routines callable only within a bank and others only callable with 24-bit addresses. There'll be many ways to do it, but simplest and smallest is to have all your code in bank0, and next simplest might be OS code in bank0 callable from application code in another bank.

(Maybe even simpler would be to use 24bit addresses everywhere, but it won't be pretty, because you can't simply use 16-bit pointers in direct page.)

(*) would be interested to hear of other cases

I am going to use ContikiOS and cc65 and hopefully a battery backup ramdisk as well. secondary memory would be SD/MMC cards. Turning of the computer would mean to either slow it to a crawl or make it static. A reset would mean to load the boot code from SD/MMC or RS-232. A simple block diagram will follow shortly.

edit:
Blockdiagram v1

It's worth bearing in mind that there's no easy C compiler story for the '816 - cc65 has an assembler which will target '816 but the compiler is pure 6502. That's fine for programs and data which fit within a bank. You'd need to write some kind of library to access data or code across banks. No reason why that wouldn't be straightforward.

I don't know about ContikiOS... a quick search draws a blank for '816 but again it needn't be an obstacle. You can target 6502 so you only need to figure out a multi-bank story.

Somewhat different, but John Kortink patched 6502 BBC HiBASIC so that on the 816 a program (which is loaded into bank 0) can access data structures over several other banks, using 3-byte pointers. So this kind of thing can be done!

I don't know what qualifies as an "easy C compiler story for the '816," but WDC lists on their page http://www.westerndesigncenter.com/wdc/tools.cfm , in the last big box called "EduDSK/ProDSK Tool User Guides":

Might that be what you're looking for?

GhstWlf, your method of representing things with a big "glue" box in the middle tying everything together is very unusual. There's nothing wrong with that, but early in the process, you will need to consider what you will use for I/O. The 6522 is the major I/O chip used with the 65-family processors, but definitely not the only one. And for direct SPI, ie, without bit-banging which works well but is much more limited in speed, you can use Daryl's 65SPI chip. Don't confuse his 65SPI with 65SIB which is the serial interface bus. They are related but not the same thing. I can't volunteer his services but I suspect he will also be offering a PC keyboard interface to make that job easier too. For RS-232 the common solution has been the 6551 because it is so easy of course to put directly on the 6502/816's bus; but WDC is only sampling their new fast version of it and it cannot really be considered to be in production (they had a minor bug in it and I don't know if they got it taken care of-- it seems like it had to do with a feature that few people use anyway), and note also that the 6551 has some quirks that don't make it ideal-- although I have used it a lot. The next time I set up an RS-232 port, I will probably use the 14-pin-DIP MAX3100 which is interfaced through SPI and has 8-byte buffers. The MAX3110 is the same thing with the line drivers and receivers built in.

If you're going to put the computer into a sleep mode instead of real power-down, you may not need the battery-backed RAM. Battery-backed ones are never very fast. The processor does have a SToP instruction which will be worth looking into as part of the sleep mode. My Hewlett-Packard hand-held computers are never really powered down, so when they are supposedly off, if an alarm comes due, they can wake themselves up to do a scheduled job and then put themselves back to sleep. One thing I have used one for is taking battery voltage data on a battery life test on a product where I had eight of them going at once. If power consumption is an issue, it's nice to be able to do that.

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

Oops - I could tell while I was composing that "easy" wasn't the word I wanted! I was thinking of free solutions, and I think there have been some, but I don't think they are finished and available. Of course you're right to point out that WDC sell a toolchain and IDE.

Yes it is, it is there because I have to find out what I should use in terms of parts before I go any further. GLUE should be replaced with a CLPD later on in the process. I am intentionally keeping away from FPGAs.