Dan Pollock
Reged: Dec 21 2004
Posts: 5
|
|
I am working on a Z80 project with bank switched ROM from 0000 to 7FFF. I am compiling individual C files to OBJ and I want to link them into 4 individual Hex files.
I am looking for more information regarding bank switching with HT-Z80. The documentation I've seen says that HPDZ takes care of everything, but doesn't give any details. There are some assembly code samples, but I don't understand how to incorporate that functionality into my application.
Any information regarding bank switching and linking individual OBJ files is appreciated.
|
John Payson
Reged: Oct 16 2003
Posts: 794
|
|
I've used HT-Z80 but haven't done any bank switching with it. Generally, though, what I've seen embedded compilers do is have you declare various banked and unbanked memory areas, and give the compiler a routine to use to switch banks. What sort of hardware are you using?
|
Dan Pollock
Reged: Dec 21 2004
Posts: 5
|
|
It's a proprietary design. Basically you output a value to a certain port and the hardware switches memory banks. The function in the new bank is called and then it switches back.
In the original assembly code they use "stubs". Each memory bank has a stub for access to functions in other banks. I'm just not sure how to incorporate this in C.
|
John Payson
Reged: Oct 16 2003
Posts: 794
|
|
Quote:
In the original assembly code they use "stubs". Each memory bank has a stub for access to functions in other banks. I'm just not sure how to incorporate this in C.
One approach would be to divide your code into several 'projects', one for each memory bank, and have each project divided into two segments: the jump table and the main code.
For simplicity, make the following assumptions:
-1- The area of memory above $8000 is divided into four banks; bank switching is performed by outputting any value to port address $F0, $F1, $F2, or $F3.
-2- Each bank has up to 50 routines that need to be callable from other banks, named FUNC[x]_[y] for bank x function y. The functions are invoked by VECT[x]_[y].
Code all of the C functions for each bank in normal fashion, linking at addresses $8800 and up.
Each project should have a special assembly file and a special header. The header should #define all the functions in the project to either FUNC[x]_[y] [if it's #included from a file in the project] or VECT[x]_[y] [if it's not].
The ASM file, which may be sharable among projects using defines/includes (but producing separate object files for each) will link at address $8000, $8200, $8400, or $8600, and will read (substitute the bank number for [x])
Code:
; 500 bytes: Loop for [y] equal 0 to 49
PUSH HL
LD HL,(087FEh)
EX (SP),HL
OUT 0F0h+[x],0
CALL FUNC[x]_[y]
; Final twelve bytes: cleaup/return
; Address == 0x81FA+256*[x]
OUT 0F0h+[x],0
RET
DB 0,0,0,0,0, 0,0,0,0,0
; Label defines: run [z] from 0 to 3 and [y] 0 to 49
VECT[z]_[y] equ 8000h+[y]*32+[z]*512
All of the necessary labels should be imported and exported of course.
Once the ASM files are produced, they will generate the necessary code for addresses $8000 to $87FF; this code should be copied among all banks except that address $87FE-$87FF of each bank should hold ($81FA+bank*512). The C files will call the lower address routines, and they in turn will call the C files in the right bank.
Note that this approach will allow for arbitrarily-reentrant code and interrupt handlers (save/restore the current bank by a sequence similar to that shown). Simpler approaches may be used for projects that require only two banks (since calling a project in the 'other' bank requires going through a springboard but calling projects in the 'current' bank does not, the fact that a springboard was used would automatically indicate the necessity of switching banks after the call).
|
lucky
HI-TECH team member
Reged: Oct 06 2003
Posts: 1054
Loc: Brisbane, Australia
|
|
Quote:
I am looking for more information regarding bank switching with HT-Z80. The documentation I've seen says that HPDZ takes care of everything, but doesn't give any details. There are some assembly code samples, but I don't understand how to incorporate that functionality into my application.
Have a look at the file "lcall.as" in the compiler's sources directory. The
compiler will call on the routines in this file to do the switching. You can change this as needed...
--------------------
Matt Luckman
HI-TECH Software
|
Dan Pollock
Reged: Dec 21 2004
Posts: 5
|
|
I understand the concept, but still do not understand how to actually implement it.
Am I *required* to create a separate project for each memory bank? If I don't, will the compiler break my code into separate 32K OBJ files for me?
I've seen some posts that say "The compiler handles bank switching automatically". What does that mean exactly?
How do I tell the compiler that a particular function resides in another bank. Do I declare the function differently?
I've read all the documentation I can find, but I need some information in laymans terms.
Any info is appreciated.
|
lucky
HI-TECH team member
Reged: Oct 06 2003
Posts: 1054
Loc: Brisbane, Australia
|
|
Hi Dan,
Quote:
Am I *required* to create a separate project for each memory bank?
No.
Quote:
If I don't, will the compiler break my code into separate 32K OBJ files for me?
Yes.
Quote:
I've seen some posts that say "The compiler handles bank switching automatically". What does that mean exactly?
It means that you tell the compiler where the bank window is, how big it is and give it some routines to switch banks, and it will organize your code into banks and use your routines to access your functions as required.
Quote:
How do I tell the compiler that a particular function resides in another bank. Do I declare the function differently?
You can leave it up to the compiler to position your code, however there are some additional keywords provided to control how functions are positioned in memory if for some reason you need to: Functions qualified near will keep a function in the same bank as other near qualified functions within a module. Functions qualified as basenear will be positioned into non-banked (common) memory.
The Features and Runtime Environment chapter of the user manual has further details about this.
--------------------
Matt Luckman
HI-TECH Software
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
