z80 Development Kit
You are not logged in.
I'm trying to retarget z88dk for the Sega Master System. Almost everything
so far went smoothly, but I still have some doubts/problems:
- Although I had copied sms.lib (support routines for the Sega Master
System) to the ./lib/clibs/ directory, the compiler is unable to find it,
unless I copy it to the same folder as the program I'm trying to compile. I
don't think it could be a problem with the environment variables, othewise
the compiler wouldn't be finding sms_crt0.asm, either.
- How do I configure the compiler to put code/constants in one address (SMS
ROM) and the variables in another (SMS RAM)?
- How do I define in which memory bank a certain function/constant will be
placed?
- Sega Master System's ROM header is placed at the end of a bank instead of
at the start. How do I reserve a specific fixed address of the bank so that
nothing else will be put in that location?
Thanks in advance.
- How do I configure the compiler to put code/constants in one address (SMS
ROM) and the variables in another (SMS RAM)?
- How do I define in which memory bank a certain function/constant will be
placed?
- Sega Master System's ROM header is placed at the end of a bank instead of
at the start. How do I reserve a specific fixed address of the bank so that
nothing else will be put in that location?
Unfortunately the assembler used by z88dk is not capable of these things.
It isn't >64k aware nor does it have any concept of multiple or even
separate code and data segments.
An even bigger problem is that some library subroutines mix static data
with the code, which means unless they are rewritten, you won't have
any way to separate the ROMable code from the RAM data.
Here are some things I've been doing to work around this:
You can define the location of C variables anywhere in the 64k memory
space with the appropriate declaration.
In the libraries I am writing now I am making a conscious effort to separate
data from code by allowing the user to declare certain variables that are
accessed from the library. Ie- a global static variable of reserved name
is declared by the user and accessed by the library code.
A sprite library being written now has a rather large data segment
associated with it (data structures, variables, constants) and in
this case I've elected to have a separate file containing defines that
describe the location of those data structures. The user is supposed to
customize it prior to compiling the library.
The IM2 library needs to know where the vector table is placed in
memory -- the user declares that in his main.c file with a short
embedded assembler code fragment copied out of the header file.
The IM2 library also supplies a generic interrupt service routine that
is written to be relocatable. The user gets the library to copy that
routine into known RAM locations at program runtime, allowing
multiple copies of the routine to be installed on different vectors.
But this falls well short of what you want (and what I want :-)
When it comes to a >64k memory space, you can't get away
without some manual linking :-(
z88dk might not be ready for the SMS if this is too big a problem.
I really think it is time to look for a better assembler for z88dk...
Maybe we should start by listing some requirements? I know
I have in mind a list of features that we would need to support
larger memory spaces and ROMable code.
_________________________________________________________________
Take advantage of powerful junk e-mail filters built on patented Microsoft®
SmartScreen Technology.
http://join.msn.com/?pgmarket=en-ca& … S_Taglines
Start enjoying all the benefits of MSN® Premium right now and get the
first two months FREE*.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk … dat=121642
Offline
On Wed, 15 Mar 2006, alvin albrecht wrote:
Unfortunately the assembler used by z88dk is not capable of these things.
It isn't >64k aware nor does it have any concept of multiple or even
separate code and data segments.
You can just about separate code and data - the original z88 target
supports ROMable applications, so it can be done.
An even bigger problem is that some library subroutines mix static data
with the code, which means unless they are rewritten, you won't have
any way to separate the ROMable code from the RAM data.
I think there's only a couple in the string library that mix ROM and RAM,
most of the standard library should work from ROM (see z88 above)
But this falls well short of what you want (and what I want :-)
When it comes to a >64k memory space, you can't get away
without some manual linking :-(
Generally all the fixing up for a platform takes place in the appmake
stage - this is where it prettifies up the binary image for use on the
actual hardware. The z88 for example requires structures at the end of a
page which link into the DORs which define the application entry points.
I really think it is time to look for a better assembler for z88dk...
Maybe we should start by listing some requirements? I know
I have in mind a list of features that we would need to support
larger memory spaces and ROMable code.
Yes! There's quite a few places where bugs in z80asm have to be worked
around (take a look at the z88 crt stuff for example), which are
irritating. I was looking at the venerable asz80 stuff a few years ago,
but it came down to a point where I'd have to rewrite an awful lot of code
for it to work for it to work.
Perhaps it's time to have the assembler discussion.
cheers,
d.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk … dat=121642
Offline