While I wait for my 65C02 GPD project to be fabricated, I'm looking at making my first 65C816 project.

I intend the following:

- Run the MPU in native mode
- Utilise the full memory map of 16MB
- Possibly split the project into two PCBs (due to size)
- Employ 2 VIA chips - 1 for system I/O (keyboard and LCD, settings ROM, RTC) and 1 general I/O
- Employ 1 ACIA for serial I/O

From what I can discover, I need to use a '573 latch which is enabled to transfer the data bus to A16-A23 on PHI2 going low.
Possibly use an inverter on the clock to enable the /LE pin with /OE always held low.
I'll start off using a GAL for glue logic, but this might not have enough pins... not sure. When I can afford it, I'm going to use a CPLD instead.

Assumptions & Unknowns

I believe that the MPU starts off in emulation mode and requires some commands to enable native mode (hence the lack of reset vector in native mode)
Not sure how to set the stack address and how to limit its size, although I do know that it can only reside in bank 0 (000000-00FFFF)


Possible Memory Map

Bank 0
$0000-$00FF [RAM] Direct page (Zero page)
$0100-$03FF [RAM] Stack (this may change)
$0400-$7FFF [RAM] OS working RAM
$8000-$80FF [Air gap] (nothing mapped)
$8100-$81FF [VIA #1, System], 16 bytes used
$8200-$82FF [VIA #2, General I/O], 16 bytes used
$8300-$83FF [ACIA], 4 bytes used
$8400-$8FFF [Air gap]
$9000-$FFFF [ROM/BIOS]

Banks 1 to 14
$0000-$FFFF [User RAM]

Bank 15
$0000-$FFFF [Reserved for possible display RAM]

Congratulations. You will be entering a new realm of 65xx computing, where things actually get easier.


Given that the 65C51 in its present form has a significant hardware bug, perhaps you should consider a non-65xx UART. My recommendation is the NXP 28L92, but there are others whose performance is commensurate with the capabilities of the 65C816. The 28L92 is dual channel, but it never hurts to have some spare I/O capability. Tested, interrupt-driven '816 native mode code exists for driving that UART.

In your "shopping list," you mention using a VIA timer as the RTC. If you elect to use the 28L92 UART you will get with it a precision timer whose rate is not slaved to Ø2, unlike the timers in the VIA. POC V1.1's timekeeping is driven by the 28L92's counter/timer, and has proved to be quite stable. Again, tested '816 native mode code for that exists.


I presume you have referred to the circuit shown on page 46 of the 65C816 data sheet. You can use it as shown, except you can skip the '245 transceiver (there are better ways to prevent data bus contention during Ø2 low), and eliminate the Ø2 inverter to /LE by instead generating a two phase clock, viz:


You would connect /LE on the '573 to the PHI1 output in the above clock generator circuit; PHI2 would drive the MPU and your VIAs.

Speaking of the '573, it has to be fast so as to latch A16-A23 early enough during Ø2 low to produce a comfortable timing margin for RAM selection. This is where a 74ABT573 would be recommended if you plan to take Ø2 up to the maximum (data sheet attached). Slightly slower but still quite fast is the 74AC573. I would not recommend the 74HC573 in this application for anything above 8 MHz.


This looks like a job for a 22V10. Even so, you will have to plan carefully.


Correct. Emulation mode is entered at power-on or when the reset pin is pulled low.


Here is some example code to get you thinking:

Code:

;================================================================================
;
;hrst: HARD SYSTEM RESET
;
hrst     sei                   ;no IRQs during 1st stage POST
         cld                   ;ensure binary mode
         sec                   ;select emulation mode to...
         xce                   ;default DB, DP & PB &...
         clc                   ;register widths
         xce                   ;return to & stay in native mode
...
         rep #%00110000        ;16 bit registers
         lda #hwstack          ;top of hardware stack ($00CDFF)
         tcs                   ;initialize stack pointer
;

The above is from POC V1.1's firmware.

The SEC -- XCE sequence puts the '816 into emulation mode, which defaults the data and program banks, forces the stack pointer to $FF and puts all registers into 8 bit mode. The CLC -- XCE sequence puts the '816 into native mode and makes the stack pointer a 16 bit register, but still loaded with $00FF. Once in native mode, POC stays there. Later on, the stack pointer is set to $CDFF (defined by HWSTACK). Following the setting of the stack pointer you would initialize your I/O and continue system boot.

As for limiting the size of the stack, that is not something that can be programmatically accomplished unless you write code that checks the stack pointer each time a stack operation is to be performed (very slow). Since the stack grows downward until the stack pointer wraps to $FFFF, you simply have to accept the fact that improper stack management could result in a collision with code or data at some point.

In POC's firmware, I placed the top of the stack below the four TIA-232 FIFOs (128 bytes each) so stack growth couldn't impinge on them. All of the bank $00 RAM from $000150 upward is for code and data, which means that unchecked stack growth will eventually step on something. It has not happened due to being careful in writing programs that make heavy use of the stack.

I recommend that you place the top of the stack very high in RAM as I did and leave the address space from $000000 upward as contiguous space for code and data. That way, stack growth is less likely to step on other things in memory. Unlike the 65C02, whose zero and stack pages are fixed, you can relocate direct page and give each function an ephemeral direct page if needed. So you are much less constrained in that regard. I set the "base" direct page location in POC to $000000 and as mentioned above, the top of stack to $00CDFF. The TIA-232 FIFOs extend from $00CE00 to $00CFFF, and the I/O block starts at $00D000. So I have contiguous bank $00 RAM from $000000 to $00CFFF, a total of 52K.


The ROM mapping is awkward, in my opinion, as it isn't an even multiple of the usual ROM sizes. Any ROM you use is likely to be 8K, 16K or 32K. Assuming the top of the BIOS ROM is at $00FFFF, then the start of ROM would be $00E000, $00C000 or $008000, respectively. Starting at $009000 will demand the use of more product terms in the GAL, but without accomplishing much of value.

16K of ROM is more than enough to hold a complete BIOS, plus a copy of Supermon 816. I stuffed all of that into 8K of ROM in POC V1.1.

In general, you should consider bank $00 address space to be valuable real estate, since it has to be occupied by direct page, the MPU stack, enough ROM to hold reset and interrupt routines, and (for programming efficiency) I/O devices and their data structures. Hence a goal in your design should be to efficiently utilize the bank $00 space and make as much of it available for RAM as practicable. Avoiding "air gaps" is one way to accomplish that. Limiting ROM size to what is necessary is another.

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

Congrats! Just a word of warning: Once you start with the 65816, even if only virtually or even just on paper, there is no real way to go back to 8 bit. I second you idea to get to native mode and stick there, because emulation mode has all kinds of weird dark corners about which new instructions do what. And you'll love the stack mode instructions.

Just to make sure you've seen the resources here, Bruce Clark has put together a long document about the opcodes (viewtopic.php?f=1&t=3475), BDD has a Tips and Ticks section going (viewtopic.php?f=2&t=3198), and I'm trying to collect everybody's information on the pins in one spot (viewtopic.php?f=4&t=3404). Also, at the risk of overstepping the limits of polite self-promotion, I've have an emulator in Alpha (https://github.com/scotws/crude65816).

I had briefly thought about making my own 65816 project (still very much in the lists-and-drawings phase) 3V instead of 5V, because that gives you access to all kinds of really neat chips. However, because I came here from the "wait, was red plus or minus again?" crowd, I've decided to breadboard a very simple system first, like Garth's 6502 minimalistic project but with a 65816 to make sure I've understood all the addressing and VPA and other pitfalls, and then make a decision. If you're more of a wire person, you might consider this step; there are all kinds of 3V Flash and SPI chips that are amazing.

The 65816 can be frustrating - some of the design decisions were, ah, interesting - but the added power is worth it IMHO. I'm very curious to see your design.

@BDD Thanks for the details and example code - very useful indeed .

I see what you mean with regard to the memory map. How about this?

Bank 0 - BIOS/OS bank
$0000-$00FF [RAM] Direct page (Zero page), 256 Bytes. Move this to bank 2 perhaps and bring the Stack to $0000??
$0100-$BFFF [RAM] Stack, 47 KB approx. Too big??
$C000-$FFFF [ROM] BIOS/OS, 16 KB

Bank 1 - I/O bank
$0000-$00FF [I/O] VIA #1, System, 16 bytes used
$1000-$1FFF [I/O] VIA #2, General I/O, 16 bytes used
$2000-$2FFF [I/O] ACIA, 4 bytes used

Bank 2 -BIOS/OS RAM bank
$0000-$FFFF [RAM] BIOS/OS Workspace, 64 KB approx.

Banks 3 to 199 - User banks
$0000-$FFFF [RAM] User programs/workspace

Banks 200 to 255 - Video/Experimental/Reserved banks
$0000-$FFFF [Reserved for possible display RAM]

The I/O mapping is as wide as it is to make the decoding simplier.

I'm a bit worried about managing the stack as I'm not sure how beyond just hoping that it doesn't get to $c000 (which would mean something has gone really wrong).
Not entirely sure about how I'm going to get hold of 16MB of SRAM from. The largest I can find on Farnell is Alliance 4Mbit = 512KB each x 32 to get 16MB (minus 1 bank for the I/O bank). LOL. I might have to move to DRAM, buyt as I've never used DRAM before and don't know how to implement RAS and CAS then that might be an issue. Or I could just ratchet back on the amount of RAM as 16MB is probably quite a lot for even a 16bit MPU.

On the subject of the latch, I've ordered some TI 74ABT253 latches from Farnell. Are the ABT devices supposed to be a generation on from AC(T)?

Thanks for the heads up with regard to using PHI2 and the bank bits. For some reason I didn't even think of generating PHI1 which is 100% out of phase with PHI2. Doh. Elminates the prop delay generated by an inverter and saves on an IC.


@scotwas

I'll certianly have a read of those posts. As for breadboarding: This is something that I do myself, but generally only for parts of a project as routing buses to multiple breadboards makes me want to scream after a while. I'd rather make sure sections work then wire wrap the whole thing. Still takes time, but is far easier in my opinion.

Not entirely sure if I want to go with 3V or 5V. I like 5V, but agree that 3V has more in the way of devices available - especially (and importantly) CPLDs when it comes to glue logic.

A nice thing about SPI is that there are very few interface lines, and they're all unidirectional, which makes it easy to put voltage translators in. I've used 3V SPI devices several times with my 5V workbench computer this way, using a quad comparator in a 14-pin DIP for the level conversion. I discuss this in the primer at http://wilsonminesco.com/6502primer/pot ... HI_V_LOGIC (which starts out about interfacing 12V logic, but can be used to go the other way too), with a note at the end of that section of the page (right before "Driving 12V relay coils") about other easy ways to do the voltage conversion.

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

Direct page is always in bank 0. No other bank. If you want to do multitasking, you might want to leave more room than just one page, as you can have for example each task using its own direct page (although they can overlap and there's no need to use a whole page for each direct page).


I can't imagine ever needing more than a few pages for stack space. Each task could have its own stack space too, and the '816 will tend to use more stack space than the '02 anyway as you push 16- and 24-bit values (as opposed to 8- and 16-bit as on the '02) and take advantage of the stack-relative addressing modes for more parameter-passing, local variables and environments, and the biggest stack user of all, recursive programming (all of these are discussed in my 6502 stacks treatise); but even 4K of stack space would probably be overkill, even in a multitasking environment.

As long as you have a large, contiguous portion of bank 0 as RAM, how you divide it up does not need to be decided in the hardware design phase.


A couple of designs done by forum members involved leaving all of bank 0 as RAM, and pre-loading some of it (including the vectors) before letting the processor out of reset, instead of having ROM. A nice thing about that is that then there's no conflict about where to put the ROM/RAM dividing wall when you might not always want that wall in a fixed place. There's more than one way to skin a cat.


Since the biggest RAM ICs are at least 8 banks' worth, it would be better to put I/O up higher if you're not going to have it in bank 0. The 5V 10ns SRAM module I offer is 4 megabytes, with 8 512KB SRAM ICs; and although it has a separate CS\ pin for each IC, it's often best to keep the RAM contiguous.

See the topic, "I/O not in bank 0" at viewtopic.php?f=4&t=1484


A way to divide it that simpler for the decoding would be at C0:0000, meaning between bank 191 and bank 192 in decimal ($BF and $C0 in hex).


I offer 4Mx8 5V 10ns SRAM modules. Although I have to get something for my labor to assemble and test them, the price I buy the ICs themselves at now is probably less than half as much as the best price you can find (since I buy in larger quantities, from non-hobby distributors), and I don't make any money on the parts themselves. SRAM does not have the economy of scale that DRAM does, so it's a lot more expensive per bit, but it is very simple to use, not having any of the complications of DRAM, and it can be battery-backed, and the modules allow write-protecting 2MB at a time if desired. You can see the module on the front page of my website (linked at the bottom of the post), and the data sheet is at http://wilsonminesco.com/WM-1_4Mx8SRAMm ... -15-13.pdf . To give a better idea of the size, here's a picture of the board before I put parts on both sides of it:



Yes. ABT parts are mostly bus-oriented, so most of what you'll find available are the 8-bit-wide parts, not so much the quad gates, dual flip-flops, etc.; and being bus-oriented, they have a lot of drive strength.

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

Garth commented on some of this, but I'll toss in my two cents (or choose your preferred currency)...

Absent special hardware logic, all direct page and stack accesses are forced to bank $00—you cannot make direct page or the stack appear in any other bank. You, of course, can change the DP register to make direct page appear anywhere in bank $00. Just be aware that the performance advantage gained by reading and writing on direct page is lost if it doesn't start on an even page boundary.

Allocating 47K for the stack is, in my opinion, wasteful. I've done some analyzing of stack usage on my POC unit, especially with programs I've written that use stack frames for parameter passing and ephemeral workspace, and have concluded that a 256 byte stack is sufficient and 512 bytes is generous. If you decided to have multiple tasks loaded and running, you can "partition" your stack space and have plenty room for individual stacks—you only have to have a place to store the (16 bit) stack pointers of the tasks that aren't currently running.

Similarly, you can assign private direct page storage and keep a copy of DP on the stack of each idle task.


Programming efficiency "demands" that the FIFOs and buffers associated with your I/O devices be in the same bank as the devices themselves—however, indices and pointers associated with data structures are best kept on direct page. If you do this, you only have to set DB (data bank register) once and then all device and buffer/FIFO accesses can be assembled with 16 bit addresses. If the I/O hardware is in a different bank than the buffers and FIFOs then you either have to constantly fiddle with DB in order to use 16 bit addressing or use 24 bit addresses to access the hardware or the buffers/FIFOs. In addition to being slower than 16 bit addressing, 24 bit addressing greatly narrows the range of instructions that can be used. For example, TRB and TSB are handy for twiddling bits in a device register or in a bit field stored in RAM, but only have direct page and absolute addressing available. Equivalents to TRB and TSB in 24 bit addressing use one more instruction and more clock cycles, nearly twice as many, on average.

You should also consider decoding your I/O into pages rather than entire blocks of address space as you list above. The most complex I/O device you are likely to use won't have more than 32 registers, so why eat up kilobytes for a device with a 32 byte footprint?


You probably don't need 64K of workspace for the environment, unless you plan to have a lot of FIFOs and buffers. However, you should consider this.

Let's suppose an I/O device generates an IRQ. When the 65C816 processes it, it will push PB, PC and SR—in that order, load PB with $00 and load PC with the content at $00FFEE. That sequence implies several things:

1. All MPU hardware vectors must be visible in bank $00.
   
   
2. At a minimum, the front end for each interrupt service handler must be in bank $00.
   
   
3. DB and DP are not automatically pushed, which means that you must preserve them on the stack (with PHB and PHD, respectively) if your your ISR or kernel uses its own direct page and RAM bank for run-time data storage.

See here for more on 65C816 interrupt processing.

If you are running from ROM then it's patent that ROM must be visible at all times from bank $00. On the other hand, if you have loaded a kernel you can run it in some other bank, with just some small code in bank $00 to take care of hardware vectors and ISR front ends. The front ends can start with a JML (24 bit jump) instruction to move execution to the bank in which the kernel is loaded. When the ISR is done and ready to return control to the foreground the RTI instruction will automatically reload PB and PC, thus resuming the next foreground instruction.


If you are doing this in programmable logic decoding I/O into pages is relatively trivial. Basically, what you are doing is synthesizing the effects of a 74xx138 3-8 decoder.


That's mostly a programming concern. There is no reasonably straightforward method of monitoring stack activity in hardware. Your best bet if you are truly paranoid about a stack collision with other code and data is to constantly test SP. A lot of such testing would definitely slow down things, especially since you'd be clobbering either .C or .X at regular intervals.


Perhaps you should consider Garth's 4MB DIMM. It's physically compact and relatively easy to integrate into your system. However, do consider that it has eight SRAMs, which means there are eight chip selects that have to be controlled. You're going to find that a bit of a struggle to work with in a GAL, due to the need for eight dedicated outputs.


74ABT253?


ABT (aka BiCMOS) is a sort of hybrid between AC and F logic, combining the speed and drive of bipolar logic with the noise immunity of CMOS. The outputs are very strong and switching speeds are in the single nanosecond range. The selection in ABT is more limited than AC, but the devices you most likely will need are readily available, for example, the 74ABT74 dual D flip-flop that can be used for clock generation, and the 74ABT573 D-latch for capturing the bank bits.


Atmel CPLDs, such as the ATF150xAS series, operate at 5 volts and are available at speeds down to 7.5ns pin-to-pin. POC V2 is designed around an ATF1504AS, which has all logic functions: address decoding, R/W generation, wait-stating, etc. The only discrete logic device in the design is the 74ABT74 clock generator flip-flop.

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

Speaking of ABT logic, here's NXP's page on these devices.

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

Garth, I had your memory module in mind as a definite possibility (just for space saving alone), although I'll have to have a think on it as I'm still not convinced that I need anywhere near 16MB anyway.
I will still probably contact you in the new year to buy some though.

Sorry BDD - got my numbers wrong . I've now received the some 74ABT573's from Farnell. Unfortunately, they don't stock the 74ABT74 so I'll have to use AC or HC ones.

With regard to Garth's DIMMs and the number of chip selects; A possibility is to use a 3-to-8 decoder such as a 74AC138 although this would introduce a prop delay of 1.5 to 10ns @ 5V. Not so good in faster designs as it would need to be in series with the address decoder GAL.

The module is four megabytes, so it would take four to fill 16MB. I've gotten a couple of orders for four at a time, but people mostly just order a single module. Recently someone ordered a pair with only one megabyte on each, ie, only two 512KByte ICs on each.


I could have put the fastest available '138 on the board, but the idea with the individual selects is that if you're using programmable logic, you can integrate the select logic there and then you would have no additional delays.

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

Use the 74AC74. The '816 is a little fussy about the Ø2 rise and fall time. When I was designing POC V1.0 I was looking at 74HC logic but later found out that the output transition speed of HC is a little lazy.

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

I've got a load of the AC ones anyway, so will do .

Update to my 65C816 project.

For speed purposes I'm going to be using a microcontroller to inject the reset/NMI/IRQ vectors and BIOS code into RAM bank 0. This should speed things up for the entire system as I won’t need to slow it down for the EEPROM (the fastest of which I can find is 45ns). If nothing else, it’s also something that I’ve not tried before.

Here’s how I think I can do it (one of the following options):

Use an Ateml 324P (4x 8 bit ports). Use 3 ports for address bus LSB, MSB and also data bus. Use 4th port for control lines.
Pros: Fastest method, fewer components, can load each port separately.
Cons: Larger AVR (40 pin), possibly more loading on the buses even when tristated(?)

Use an Atmel 328P (3x 8 bit ports). Use 1 port attached to 3 octal latches which feed the address and data buses. Another port is used for the control lines (including the ones for the latches).
Pros: 2nd fastest method, should be able to disable the latches completely so less loading on the buses(?), can load each latch separately.
Cons: 3 extra ICs, have to run AVR bus lines to each, more control lines needed to control the latches

Use an Atmel 328P (3x 8 bit ports)or ATtiny . Use 1 pin of 1 port attached to 3 SIPO shift registers (attached in series)
octal latches which feed the address and data buses. Another port is used for the control lines (including the ones for the latches).
Pros: Can use 1 port SIPO control lines and data, should be able to disable the latches completely so less loading on the buses(?)
Cons: 3 slowest method, extra ICs, small amount of EEPROM if using ATtiny


I’ll probably go with the first one unless there are other cons that I have not thought of.

Algorithm

* AVR starts in sleep mode and maintains an interrupt link to the ‘816 (CPU) reset line (RESB)
* RESB goes low
* AVR interrupt fires and it wakes up
* AVR causes the BE pin on the CPU to go low. This causes the CPU to tristate its bus pins
* AVR causes PHI2 to stay low. PHI2 is generated through a D-type flip flop so this is possible
* AVR causes R/W line to go low (write mode)
* AVR causes RAM /OE to go high to ensure that the RAM knowns not to output. /OE should never be low when R/W is low anyway.
* AVR loops until all data xfered to RAM:
- load address bus
- load data bus
- cause RAM Select to go low (enables RAM)
- wait prescribed time for write completion (RAM datasheet)
- cause RAM Select to go high (disable RAM)
* When all data has been xfered the AVR tristates it’s own pins to: address bus, data bus, R/W, RAM select, RAM /OE.
* CPU BE pin is brought high
* /RESB is pulsed low then the AVR reset pin is tristated and the interrupt is re-enabled.
* AVR enters sleep mode.

What does everyone think? Have I missed anything?

[edit]

Instead of using direct connections to RAM /OE and RAM select, I could simply manually pulse PHI2 high and low as needed.
I'm just a bit concerned with writing rubbish to the RAM or creating bus contention if the timing is off a little.

Not sure I understand. It's not necessary to use latch IC's in addition to the shift register IC's -- is that what you meant? Chips like 74hc595 and 74hc4094 include the shift register, latch and tristate output buffers all in one 16-pin package.

The shift register approach may be slower but is that important? (You can arrange things so you don't have to update the upper address lines for every byte written, BTW.) The nice thing is the compact, 16-pin package, and the reduced amount of wiring due to serial input. Serial input means even a tiny (8-pin?) microcontroller could do the job. Add five shift registers (3 for address, 1 for data, 1 for control) and that covers everything. Four might be sufficient if you don't need all 24 address lines. Also you might prefer to let some/all of the control lines come straight from the uCtlr. You can mix & match the serial & parallel approaches as you see fit. The all-in-one 40-pin AVR is appealing. But shift regs might use less space as long as they're surface-mount.

I expect the capacitive loading will be about the same no matter which option you choose. There may also be some DC loading (eg if you tie to microcontroller port pins which have pullups) but I don't think it's important -- shouldn't affect your decision. Nice to know there's one thing, at least, which you don't have to worry about!

-- Jeff

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

Sorry Jeff. I meant the 3rd option as shift register only (editing went a bit wrong lol).

Another consideration is that I'll obviously need to store the BIOS. I think only XMEGAs have more than 1KB EEPROM I can either:
1) choose to store it in EEPROM and limited myself to 1KB. Not great.
2) choose to store it in Flash, but I'd have to find a way of doing this and space would still be limited
3) choose to store it in an I2C EEPROM. I don't have a programmer that can do I2C though so would be awkward.
4) choose to store it in a conventional EEPROM. Easiest but takes space and the number of pins needed is a little silly.

I2C is probably the best option.