drac030 Posted May 10, 2020 Share Posted May 10, 2020 15 hours ago, tschak909 said: @drac030 am assuming that MADS is the de-facto assembler for making SDX binaries? -Thom Basically, yes. There is yet the Fast Assembler which can produce these. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 10, 2020 Author Share Posted May 10, 2020 Would it be possible to patch the E Handler to intercept Graphics calls to call a stub routine in the cassette buffer to relocate my n Handler to the new APPMHI?Sent from my SM-G920F using Tapatalk Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 11, 2020 Share Posted May 11, 2020 22 hours ago, tschak909 said: Does anyone have a compileable version of the RELGEN/RELOCATOR.ACT files? The listings on AtariWiki seem to have encoding errors in them. -Thom My RELGEN compiles fine. The RELOCATE fails with an Error 8 but that's to be expected because I didn't include the relocation table. Are you getting errors other than that, because if so then I can send you my copies. 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 11, 2020 Author Share Posted May 11, 2020 I get an Error 1 when I cut and paste RELGEN into the ACTION! editor in Altirra. ? Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 11, 2020 Share Posted May 11, 2020 Ok then. RELDOC.ACT RELGEN.ACT RELOC.ACT 2 Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted May 11, 2020 Share Posted May 11, 2020 11 hours ago, tschak909 said: Would it be possible to patch the E Handler to intercept Graphics calls to call a stub routine in the cassette buffer to relocate my n Handler to the new APPMHI? The E: (and S:) handler do not touch APPMEMHI. Applications do (thus its name). The free memory region is between APPMEMHI ($0E,$0F) and MEMTOP ($2E5,$2E6).The region between APPMEMHI and MEMTOP is of course also used by other applications, e.g. the DOS++ "COPY" command, as it is "free memory", or as stack for the TurboBasic FILL command. It is therefore MEMTOP you want to adjust, not APPMEMHI. APPMEMHI is under control of the executing program, e.g. Basic. So if you want to relocate, you need to do so before every graphics mode change, to a region below the new MEMTOP which you would need to compute from the target graphics mode, and then adjust MEMTOP to point below your relocated hander after the screen and/or editor open CIOCMD returns. Thus, doable in principle, the question is just "where to place the relocation function itself". 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 12, 2020 Author Share Posted May 12, 2020 Did another pass in MADS, and it initializes correctly, and even survives a reset, but once I do an OPEN, somehow the OPEN routine gets clobbered before it starts executing, what's going on? n-handler.atr ndev.asm Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 12, 2020 Share Posted May 12, 2020 (edited) You’re doing it wrong. Either delete the JMP (DSAV) line and let it fall into RESET or change it to JMP IHTBS. By doing it the way you are, the previous handlers are resetting your MEMLO. Edited May 12, 2020 by Alfred Added reason 2 Quote Link to comment Share on other sites More sharing options...
danwinslow Posted May 12, 2020 Share Posted May 12, 2020 On 5/9/2020 at 8:59 PM, Alfred said: Probably because in the cross-assembler world, it is trivial to assemble/compile 6502 code because the resulting object file in no way is of such a size as to not be able to be handled by a PC program. So why use a linker when you can just generate the full binary in a pass ? Instead of linking, you just include whatever files you need. I'd also imagine linkers are less popular, because they are harder to write. Resolving relocatable virtual operands isn't trivial. Well, having a linker like CL65 adds a kind of abstraction that gives you a lot more control over what's actually happening. You can separate the concerns of the source code itself from the concerns around segments and what's where and what type it is. Is it necessary? No. Is it handy? Yes. 1 Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 13, 2020 Share Posted May 13, 2020 10 hours ago, danwinslow said: Well, having a linker like CL65 adds a kind of abstraction that gives you a lot more control over what's actually happening. You can separate the concerns of the source code itself from the concerns around segments and what's where and what type it is. Is it necessary? No. Is it handy? Yes. I suppose that’s true enough. I’ve been trying to sort out that kind of issue as I work on my DOS. It would be nice to have a single file that contains all of a functions code with directives to say code goes in this section, uninitialized data goes here, etc. All things common on other platforms, but which the Atari does not possess. I’ve tried to make it work with Six Forks, but it’s a very unwieldy mechanism, and not usable in a large project. I think I’m coming around to the point of view that I’m just going to have to clone the WDC assembler/linker to have that ability on the Atari. The Six Forks relocatable format just can’t accommodate that ability no matter how hard I bend it. So I’m thinking of using the S/370 style relocation format as a model. Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 13, 2020 Share Posted May 13, 2020 On 5/10/2020 at 7:28 AM, drac030 said: Basically, yes. There is yet the Fast Assembler which can produce these. Is this Fast Assembler a mode of your ELSA or a different assembler ? I thought MADS was the semi-official cross-assembler people used. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 13, 2020 Share Posted May 13, 2020 Fast Assembler isn't a cross assembler. It's included on the SDX toolkit disk, IIRC. Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 20, 2020 Share Posted May 20, 2020 On 5/13/2020 at 3:19 AM, Alfred said: Is this Fast Assembler a mode of your ELSA or a different assembler As said already, FA is a different assembler. The support for relocatable binaries is planned for ELSA, and there is even some code there, but not yet finished. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 20, 2020 Author Share Posted May 20, 2020 meanwhile, in the crazy pet tricks dept. Copying a file from one N: device to another. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 24, 2020 Author Share Posted May 24, 2020 Am actually kind of curious. In reloc, I see: CHAR FUNC GetD=*(BYTE d)[$7A2] is this actually calling $07A2 ? (This has a JSR SIOV under DOS 2/OS A+2/DOSXL 2) Am trying to figure out why this RELOC.ACT is failing under DOSes other than DOS 2, and my spidey sense is telling me that it's doing direct calls into the DOS 2 FMS... -Thom Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 24, 2020 Share Posted May 24, 2020 No, $A2$07 is LDX #7 so my guess is that GetD is falling into another routine and using iocb 7 which is K: when the cartridge is present. Probably depends on the cart rather than using the runtime package. Runtime uses “device” variable for the default channel. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 24, 2020 Author Share Posted May 24, 2020 ok, so the relocator goes off into the weeds, in anything SpartaDOS. grrr. Here's the most recent build. relwork.atr (I'm also in parallel trying @flashjazzcat's method, trying to both understand what is going on and what to do, while also trying to guarantee that I can get past this.) Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 24, 2020 Share Posted May 24, 2020 5 minutes ago, tschak909 said: ok, so the relocator goes off into the weeds, in anything SpartaDOS. grrr. Here's the most recent build. relwork.atr (I'm also in parallel trying @flashjazzcat's method, trying to both understand what is going on and what to do, while also trying to guarantee that I can get past this.) So if the relocator works in everything but Sparta then it’s not the relocator per se. Things to check: Make sure the finished program from Action! does not use $02E2 address as its run address. The original cart does this, so either use a modified cart image that puts a proper $02E0 run address on the binary or use DiskRX to change the 4 bytes at the end from $E2 $E3 to $E0 $E1 or at the very start of your program put: MODULE BYTE rtsme=[$60] ; This usually works, but not always. Look for Note/Point usage make sure something isn’t getting swapped. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 24, 2020 Author Share Posted May 24, 2020 (edited) Yup, I am using @JAC!'s ACTION 3.7 build, which does not do this, and a quick skim through omnivore does indeed prove this out. I went ahead and put the RTS at the beginning, anyway... still nada. urgh. -Thom Edited May 24, 2020 by tschak909 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 25, 2020 Author Share Posted May 25, 2020 Looks like the trick that causes it to fall through doing command #7 (GETCHR) fails horribly for some reason. I get different behaviors depending on if I use SpartaDOS 2/3 or 1. So it's definitely depending on implicit IOCB behavior that SpartaDOS is doing differently... -Thom Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 25, 2020 Share Posted May 25, 2020 Looking at RELOC, that code, CCIO etc. is pulled from the runtime. It looks like the trick is that the relocater is depending on DOS using channel #1 to read the binary file. So presumably the reason it fails under SpartaDos is that channel #1 is not used. SpartaDOS X at least does not use an active channel. I don't know about 3.2. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 25, 2020 Author Share Posted May 25, 2020 ok so I will have to roll my own with flashjazzcat's method. it's not 100% clear to me yet, but close. -Thom 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.