Memory Moves vs resetting ORG

[tschak909]

I'm just contemplating in my head... Is it better to assemble everything as one big lump image at one single point in memory, and then move things to other parts of memory as needed? A lot of the different code i've seen basically is one large single segment image, that just moves what it needs to other parts of memory (for things like character set or screen memory...) ... is this a better approach than re-setting the assembler origin to different segments and having your assembler make a multi-segmented binary file?

 

(i'm also curious, because I will be burning my game to cartridge formats, eventually.)

 

-Thom

[Bryan]

I often place data that needs to be aligned a certain way (chset, dlist) at the beginning of a file where I know it will be locked in place by the ORG, then put my code after it.

 

-Bry

[Rybags]

Normal practice isn't to include everything in one source file.

A good idea is to have modules, each containing specific routines or sections of code.

Once you're up for a final ASM, have a main file which just .INCLUDEs everything (each Assembler has different means to do so).

 

In any case, graphics and other data are often generated by external programs besides the assembler anyway.

 

Once a module is nicely working, it's best to tuck it away anyhow, plus it's fairly pointless assembling 10,000 lines of source if the routine you're working on is only a couple of hundred lines.

[analmux]

moving blocks of data is mainly needed when you copy to the RAM area under the O.S.

 

f.e. you cannot do such a thing as:

 

org $f000

 

because the OS (in that area) is needed for disk access routines.

 

you need to copy afterwards.

 

...

 

but in other cases the programmer is free to copy or redefine 'org' multiple times...

 

...though it's recommended to do no 'org's for (different) code parts

f.e. a characterset has a well defined size

the actual size of a piece of code is harder to estimate

Edited July 5, 2006 by analmux

[tschak909]

so let's say i have a final assembly, and I have a good idea how much everything takes up (ATASM does a good job of showing the segments and how much they take up, after the assembly...), and I want to crunch it into a cartridge form, I would define the ORGs as equates, and in the main file with all the includes, just shift the addresses around for the game logic, character sets, display list, screen memory, etc?

 

-Thom

 

p.s. as for copying RAM under the OS, I understand this is needed to gain full access of the 64K in the XL's... how does that work? I mean, I understand the process of flipping the PIA control bits, but.. if you're overwriting address space normally used by the operating system, what then? do you have to take over all of the functions the OS would normally do, or???

 

 

moving blocks of data is mainly needed when you copy to the RAM area under the O.S.

 

f.e. you cannot do such a thing as:

 

org $f000

 

because the OS (in that area) is needed for disk access routines.

 

you need to copy afterwards.

 

...

 

but in other cases the programmer is free to copy or redefine 'org' multiple times...

 

...though it's recommended to do no 'org's for (different) code parts

f.e. a characterset has a well defined size

the actual size of a piece of code is harder to estimate

[kenfused]

Reasons for copying ROM to RAM when using a cartridge.

Self modifying code

A character set or other block of data you might want to dynamically modify (for animation, etc).

Something that you can compress or packdown in ROM to save space, you could decompress to RAM.

 

Try to keep RAM usage to 16K if you want to make a 5200 version.

Edited July 5, 2006 by kenfused

[Rybags]

If you're using RAM under the OS for just data that's referenced infrequently (like level maps that are decompressed or something), then you just need to disable interrupts and don't do any OS calls while you reference that RAM.

 

So, SEI, LDA #0, STA $D40E is sufficient. Always use AND / OR to change bits in PORTB to ensure you remain compatible with the different RAM expansion schemes around. If you're just dealing with a 64K type program then you'll only be needing to play with bits 1 and 0 anyway.

 

If you chose to use the extra RAM for actual program code (or just want to have complete control over the machine), then you (as a minimum) have to set the NMI and IRQ vectors at $FFFA/B and $FFFE/F to point to your own code which has to handle NMIs and IRQs. You don't need to worry about the RESET vector since reset always switches the machine to it's default state (OS enabled).

 

NMIs are easy to deal with yourself since there's only VBlank and DLIs - IRQs are a bit of a different matter since there's so many different types.

 

But within the confines of a game, the only IRQs you really want to enable and deal with are related to the keyboard/Break key (and possibly POKEY timers), and the BRK instruction.

 

Back to the ORG thing - decent Assemblers have options to assemble code to load in different locations to what they execute in. Very handy for using RAM down around $400-$2000 where buffers and DOS usually reside.

 

As for putting your final program together. A compound binary file with all the parts is often quite sufficient - then you either load from DOS or a file menu. Or you can create an bootable disk, either single or multi stage loading.