fujinet DOS 2.0 DUP overwrites my CIO handler :(

[drac030]

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.

[tschak909]

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

[Alfred]

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.

[tschak909]

I get an Error 1 when I cut and paste RELGEN into the ACTION! editor in Altirra. ?

 

[Alfred]

Ok then.

RELDOC.ACT RELGEN.ACT RELOC.ACT

[thorfdbg]

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

[tschak909]

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

[Alfred]

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

[danwinslow]

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.

[Alfred]

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.

[Alfred]

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.

[flashjazzcat]

Fast Assembler isn't a cross assembler. It's included on the SDX toolkit disk, IIRC.

[drac030]

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.

[tschak909]

meanwhile, in the crazy pet tricks dept. Copying a file from one N: device to another.

 

 

 

[tschak909]

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

[Alfred]

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.

[tschak909]

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

 

 

[Alfred]

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.

[tschak909]

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

[tschak909]

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

[Alfred]

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.

[tschak909]

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

 

-Thom