flashjazzcat Posted June 15, 2016 Share Posted June 15, 2016 (edited) .DS work with .RELOC but .DS must be a last .reloc lda temp sta buf temp .ds 10 buf .ds 100 .DS create EMPTY BLOCK (BLK EMPTY) your loader must support BLK EMPTY This worked for a while but is broken is recent MADS releases which happened to fix other stuff I depend on, so I'm now stuck. .DS now produces no empty block but a block of zero padding instead. Got no response to a PM so reporting the bug here instead. Edited June 15, 2016 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 15, 2016 Share Posted June 15, 2016 So for an empty block it'd have to just end the current load segment and start another one a bit further on? What about in the case of raw binaries as if you were doing a cart though? Can you get around the whole thing by something like ORG *+10 ? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 15, 2016 Author Share Posted June 15, 2016 (edited) Sincere thanks to Tebe for producing a fix. So for an empty block it'd have to just end the current load segment and start another one a bit further on? The relocatable file format allows only a single code segment per binary (unlike the SDX format which can have a mix of absolute, MAIN and EXTENDED), and .DS isn't even allowed in the RELOC segment - unless it's the very last thing in the file. In that case, all the .DS directives following the last line of code are totalled up and appended as an "EMPTY" block (type identifier "E"). Any labels inside "E" produce fixups with offsets relative to the start of the code segment. In the case of the GOS, this is useful when you want some uninitialised memory straight after the code segment (there being no guarantee that dynamically allocated RAM will be taken from the same extended bank). The relocating loader makes two passes, first looking for an "E" block and adding its size to that of the code segment, yielding the amount of RAM which needs allocating to house the code and data segment contiguously. We then copy the code segment into the allocated block and iterate through the fixup segments. After any "E" block come the fixup segments, external references, symbol definitions, etc. It works pretty well, especially since MADS proprietary relocatable format can deal with lo/hi addressing without any kind of indirection. I only noticed an issue last week when compiling the profiler app, which has a few large blocks of uninitialised storage at the end. The binary (including all fixups) was coming in at something crazily big like 8KB, when it should be less than 5K. Then I noticed there was no "E" block, but instead a lot of zero padding. What about in the case of raw binaries as if you were doing a cart though? All this applies only when the source begins with the ".RELOC" directive. Contiguous assembly, header omission, etc, can otherwise be set up easily enough (with OPT F+ and OPT H- respectively) when not dealing with relocatable files. The single segment limit on the relocatable format poses a slight issue with drivers which load into extended RAM, since the code may want to copy data from (for instance) an IDE register into a sector buffer in some other extended bank. Fortunately we can easily get around this by having some helper code at a fixed address outside of the banking window (for instance, a function which reads the register n times and places the result at a specified buffer address in a specified bank). In any case, MADS' relocatable format is also used by the assembler's linker, so drastic changes to the file format would probably have unwelcome side-effects elsewhere. Edited June 15, 2016 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.