Perhaps some additional food for thought... first on a memory map and how much RAM or ROM (EEPROM) you might want to consider.
1- Using a 22V10 for Glue logic gives you flexibility, which is good. Use this to provide chip selects for both RAM and EEPROM.
2- I would suggest using a newer 128KB Static RAM chip. You won't use it all, but by changing the GLUE logic, you can pick where RAM ends and EEPROM begins.
3- I would (also) suggest using a 32KB EEPROM chip. The same applies as above.... changing the GLUE logic allows you to use as much or as little as you need.
NOTE: 32KB EEPROMs are more readily available these days and can be had in 70ns access speeds.
4- PLD speed.... I'm using the slower low power ATF22V10CQZ in my latest C02 Pocket SBC, which is rated at 20ns. 8MHz clock speed is no issue. Faster parts use more current.
Carving out the hardware I/O space. We all have our own view on this.... there's no right or wrong answer either. There are 3 specific memory areas for the 65C02:
1- Page Zero, which is special and has it's set of addressing modes and unique instructions.
2- Page One ($01), which is the processor Stack (read up on this one).
3- The last page ($FF), which contains the address vectors for IRQ, Reset and NMI.
All of the above are not alterable, so you need to fit everything within those constraints. I did my first SBC in the latter 80's and adopted a memory map that I still use. In my simple view, RAM grows from the bottom up and ROM from the top down. I decided to put all I/O on Page $FE. While this can easily result in non-contiguous ROM usage, what does it matter? If I decide to add a bootable device, like an IDE controller, I would be able to fit the boot code into less than 256 bytes and have mostly RAM with the exception of the last 512-bytes (for example). In my view, this memory map gives me the largest possible contiguous "memory". Note that I consider this to be the memory address range starting from $0200 and going as high as $FDFF, which is 63KB. Using a single Glue logic chip allows you to pick the dividing line between RAM and ROM.
Second, some classic code on the 65C02. BDD already showed a classic character out routine. However, it only allows for 255 bytes of a maximum string size, as it uses the Y index register. It is very efficient in both code size and execution time. If you need to output multiple strings in your code, then you might want to look at something with a bit more flexibility. I use an index table in my monitor code, which allows a single value (in the A reg) to define a message. The output routine uses the single index value as a look-up index to a table, then grabs the actual memory address for the respective message and loads that value to a page zero area. It's a bit more code of course, but handles larger messages and the one routine can be used for any and all messages.
Code: Select all
;PROMPT routine: Send indexed text string to terminal. Index is contained in A reg.
; String buffer address is stored in variable PROMPTL/PROMPTH.
PROMPT ASL A ;Multiply by two for msg table index
TAX ;Xfer to X reg - index
LDA MSG_TABLE,X ;Get low byte address
LDY MSG_TABLE+1,X ;Get high byte address
;
;PROMPTR routine: takes message address in Y/A and prints via PROMPT2 routine
PROMPTR STA PROMPTL ;Store low byte
STY PROMPTH ;Store high byte
;
;PROMPT2 routine: prints message at address (PROMPTL) till null character found
PROMPT2 LDA (PROMPTL) ;Get string data
BEQ EXIT ;If null character, exit (borrowed RTS)
JSR B_CHROUT ;Send character to terminal
INC PROMPTL ;Increment low byte index
BNE PROMPT2 ;Loop back for next character
INC PROMPTH ;Increment high byte index
BRA PROMPT2 ;Loop back and continue printing
EXIT RTS ;Exit
;
Needless to say, there's always multiple ways to get something working with the 65C02 assembly language.... and as I like to say, you can't (always) argue with success. You can code for minimum size or you can code for minimum execution speed... and sometimes reach a happy median.
Getting some good references would also be a plus:
1- Programming the 65816 by David Eyes and Ron Lichty (includes the 6502 and 65C02)
2- 6502 Assembly Language Subroutines by Lance Leventhal and Winthrop Saville
Of course, best of luck in getting your first SBC up and running. Do look through other people's code to get ideas and examples on how to get some basic building blocks for the 65C02. They will come in handy as you move forward.
