Jump to content
tschak909

DOS 2.0 DUP overwrites my CIO handler :(

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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".

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by Alfred
Added reason
  • Like 2

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.)

 

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by tschak909

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

ok so I will have to roll my own with flashjazzcat's method. it's not 100% clear to me yet, but close.

 

-Thom

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...