can I divide my code into multiple source files?

how will code in 1 file reference things in another source file?

on 68k assemblers you tend to use xref and xdef,

yes
you reference them directly, use
this includes them directly. for example:

MAIN.ASM


NOTMAIN.ASM

This assembles correctly (if you assemble MAIN.ASM, that is.)

that is what I've been doing so far, unfortunately I've globbed so
much code that the binaries no longer run,

if I comment out some of the includes which arent referenced they
run,

my code right at the start calls a subroutine right at the end
and the code fails.

I tried expanding out all the includes and the binary still fails:

the globbed source is 71295 bytes including a lot of comments
and the resulting binary which doesnt run is 18700 bytes,

are there any limits on the size of a source file for fasm?

maybe I will experiment and find the size at which the file fails,

I tried the -m option also and it makes no difference,

it all depends how much source code is present:

with 61356 bytes of source the binary was fine
and with 64079 bytes of source there was partial malfunction,
with the full version 71295 bytes there is a lot of malfunction,

I'm going to try and insert say 10K of fake comments to
the 61356 byte file and see if it functions,

UPDATE:

there appears to be a bug in fasm as regards source file size:

with the 61356 source file I inserted a huge amount of
fake comments which produced an IDENTICAL correct binary,

however I then created an extra include file with 4689 nop instructions
and the machine not only malfunctioned but it reset,

so there is a bug in fasm if there are too many source instructions,
and at the start you call a subroutine right at the end:

try inserting a huge number of nop instructions,

[editted out an apparent further problem which wasnt a problem]

this code is loaded to 10000h, and the stack is from 20000h to 2fff0h
so it cannot be trashing its own stack,


is there a reliable 16 bit real disassembler that I can use,
because the problem happens right at the start,

unfortunately XP's "debug prog.bin" disassembly is useless,

FURTHER UPDATE (some hours later!)

I've been comparing disassemblies, the fasm output
looks correct, maybe the bug is in the program I wrote
to copy the binary to disk, I'll study that.

Use OllyDbg as a visual debugger. Much better than the debug program.

after much study the bug appears to be
that int 13h ah=2 to read sectors from a floppy
to ram will not copy beyond the cylinder boundary:

with my boot code the first sector
loads the next 32K of sectors to 10000h and
then jmp's to 10000h,

as I dont have any echo facilities in the first sector
I wasnt checking the error status of this copy to ram,

by hacking an error message I've found that

if I copy 35 sectors from sector 2 there is no error
but if I copy 36 sectors there is error,

recall I was getting malfunction with an 18k binary
which will require 36 sectors as 35 sectors is 17920 bytes,

IIRC a floppy's geometry is 80 x 2 x 18

so the first cylinder is 1,2,3,....,36

so it is failing when I try to copy beyond the cylinder!

(next cylinder is 37 onwards, 37-2+1==36)

I need to get around the problem without making
any disk geometry assumptions, so either a
3 phase boot or see if there is some way to do it
in the first sector,

are there unconstrained ways to copy sectors from a floppy
better than int 13h ah==02h ?

http://board.flatassembler.net/topic.php?t=4757

looks like the ultimate way to do it!