Programming two ROMs for the same 6502 Computer

[vespacla]

Hello dear forum members

I am currently building an Apple 1 -like computer and now want to add a second ROM. Therefore, I'd like to split my already existing code into two parts for two ROMs and add more code later.

How can I use assembler labels meant for one ROM in the code of the other ROM ? An example: The code for the screen output is implemented in the first ROM, but I also need to output information from the code of the other ROM.

I have never used a cross-compiler, but if I understand it correctly it would not help much in this case ? Or is there no alternative to using absolute addressing ?

Any help would be greatly appreciated.

[barnacle]

Are the roms intended to share the same memory space? i.e. only one is visible to the processor at a given time? Or are you putting (say) two roms at different addresses so they are both visible at all times?

Neil

[GARTHWILSON]

Do you have the source code for the first EPROM, and will you be assembling it along with the new code for the second EPROM?  If so, the assembler doesn't need to know they're in two ROMs.  That's a matter for the EPROM programmer's driver software to handle.  Otherwise, the labels you'll use that are in the first ROM can be made to be EQUates (constants) that you put at the beginning of the source code for the material that will go into the second ROM.  There may be exceptions that are outside my experience, like if you use a linker.  Neil posted a good question above while I was writing.

[BigDumbDinosaur]

Like the others, I could use a little more info on exactly what you are attempting to achieve.

That said, if code for both ROMs is expected to share symbols, you should define them in a separate INCLUDE file that you would refer to in the source code for both ROMs.  That is pretty basic stuff when it comes to using an assembler.

You need to clarify what you are trying to accomplish so we can better help you.

[John West]

You say that you want to split your existing code into two ROMs, and I'm guessing that every part of it is referring to symbols defined throughout - if it was practical to separate out a common set of definitions, you wouldn't have a problem.

If the two ROMs are mapped to adjacent locations (say $E000-$EFFF and $F000 to $FFFF), the easiest is to put all your code into the same file and split the binary before it goes into the ROMs. Like Garth suggests.

If they're not adjacent you can still do this. It's just a little tricker. You'd have to find a point in your source code just before the end of the first ROM and stick a JMP and .org in there. The version of BASIC in the Commodore 64 does this - BASIC is slightly bigger than the 8K ROM at $A000-$BFFF, so there's a JMP $E000 in the middle of the floating point EXP routine. It's ugly, and a hassle to maintain if you keep adding code to the first half. But it works.

The alternative is to use an assembler that produces relocatable object files like a C compiler does, and get the linker to fix up all the references between the two. I don't use such an assembler, so I can't help you with the details.

[vespacla]

Thank you all very much.
Yes, there are two ROMS that will work in the same system at the same time. The existing ROM has the addresses $E000 - $FFFF and the other ROM has the new addresses $A000-$BFFF .
I get the impression it will be easiest if I write the code in one, with the corresponding instructions where to put what in memory. Then I have to split the file manually into two halves before I load it onto the ROM.
Let's see if it works...

[GARTHWILSON]

You could write a macro that considers the current assembly address, and if it's getting close to the end of the $A000-$BFFF range, uses the ORG $E000 assembler directive to skip over the $C000-$DFFF gap and pick up in the other ROM.  Then you'll invoke that macro every so often, between routines, obviously not in a place that you would have to skip over with a relative branch which of course won't branch far enough to get over that large gap.  I'm at work now and can't take much time on this; so I might come back later to refine the explanation if I see I made something as clear as mud.

[barnacle]

If you use an intel hex file as your output carrier, splitting it manually is a piece of cake: you'll just need to break it into two files based on the address, and add a new 'end of file' line to the lower half. Any text editor will do.

As Garth suggests, I'd make this as a single file (or, if you have multiple assembly files, include them into a single file) and probably consult the output listing to see where to insert an .org $e000. I'm lazy when macros come along to do something a bit unusual

Neil

[GARTHWILSON]

barnacle wrote:

As Garth suggests, I'd make this as a single file (or, if you have multiple assembly files, include them into a single file) and probably consult the output listing to see where to insert an .org $e000. I'm lazy when macros come along to do something a bit unusual

Depending on your assembler's macro language, such a macro might look something like this:

Code: Select all

WatchForEPROMboundary: MACRO
    IF  $C000-*<$80  ; If $C000 minus the current address is less than $80,
        ORG   $E000  ; bump the assembly address up to $E000.
    ENDI
    ENDM
 ;-------------

The macro won't lay down any code, only affect the address where subsequent assembly starts.

[jgharston]

Another thing to consider is if your code can be split into two completely seperate functional modules. For instance, application in A000-BFFF and I/O in E000-FFFF. Then have a general purpose jump block in the I/O ROM, and your application code just needs to EQUate the entry points and call them. For instance, something like:
IOINIT EQU FF00
IOCTRL EQU FF03
IORDCH EQU FF06
IOWRCH EQU FF09
etc.

This has the additional advantage of making each ROM completely independent of the other and swappable and replaceable with something else.