fujinet DOS 2.0 DUP overwrites my CIO handler :(

[tschak909]

For anyone who can answer.

 

I have a CIO handler, that I've ported entirely to assembler (using AMAC), and it works. It loads just above the memlo that is imposed by DOS XL 2.30 with two double density disks ($2300), and with this, I am able to test and work through the rest of the CIO handler actions and debug without the weird side effects imposed by the C prototype version.

 

In addition to the attached files here, I've uploaded my current work to the #FujiNet repo:

https://github.com/FujiNetWIFI/atariwifi/tree/master/n-handler/production

 

However, I've noticed a bit of an issue, What about DOS 2.0/2.5?

 

Specifically,

 

If I load at MEMLO (e.g. $1CFC or similar), then DUP will clobber my code. Normally, for devices like R: this is fine, because they're not being used by the DUP potentially for file operations (like copying or loading binary files), so DUP can swap back in via MEM.SAV, and things don't go awry. However...if I try to binary load using NDEV.COM in DOS 2.0, the DUP has overwritten my handler, and it doesn't know to swap the overwritten memory back in. whoops.

 

The solution I had done, to continue debugging on DOS 2.0, was to make a version that assembled roughly at MEMHI, which puts it out of reach of the DUP, and then things work. But this isn't ideal. 

 

Is there a better solution? or am I going to have to patch a version of DOS 2.0/2.5 to add the N: handler for those who want to use it? (roughly 975 bytes + 2K of buffers.)

 

What's the right decision, here?

 

-Thom

n-handler-asm-alpha-listing.pdf amac.atr n-asm.atr

[phaeron]

From what I can tell, DUP + MEM.SAV would handle this but the issue is that NDEV.COM contains a bogus second run segment with an address of $0000. Seems to work fine if that is removed.

 

[tschak909]

1 minute ago, phaeron said:

From what I can tell, DUP + MEM.SAV would handle this but the issue is that NDEV.COM contains a bogus second run segment with an address of $0000. Seems to work fine if that is removed.

 

wait what? so there's a bug in AMAC? ? ok.

-Thom

[tschak909]

I will try to build, with an O=$2300 in the cmdline instead of putting it in the source file, and see if that fixes it.

-Thom

[phaeron]

Just now, tschak909 said:

wait what? so there's a bug in AMAC? ? ok.

Looking at some docs online, it seems that you're supposed to specify the run address in the END statement instead of manually putting a segment at RUNAD.

 

[tschak909]

*blush*....yeah. there it is in the manual.

That'll teach me to read closer.

 

Thanks, Avery.

-Thom

[tschak909]

@phaeron

 

Yup, adjusted, bogus run address is gone, still same problem.

I can use in Atari BASIC just fine, but once DUP is loaded, trying to do:

 

'L'

N:BURIEDBU.COM

 

causes a freeze. The program memory isn't swapped back in.

 

(the N: device is set using NPREFIX.COM before doing the load)

 

Here's a build.

 

 

n-dos2.atr

[thorfdbg]

7 minutes ago, tschak909 said:

Yup, adjusted, bogus run address is gone, still same problem.

I can use in Atari BASIC just fine, but once DUP is loaded, trying to do:

 

'L'

N:BURIEDBU.COM

 

causes a freeze. The program memory isn't swapped back in.

There is nothing you can do. The 2.0S DUP uses the address space of the handler, and there is no way to learn within the handler or the DUP that the address HATABS points to is now overwritten by the DUP. The  handler becomes operational again once  MEM.SAV restores its code. You could place the code somewhere else, e.g. behind the Os or behind the basic cart, with a minimal jump table somewhere in the low memory area.

[tschak909]

This is what I was afraid of, and ultimately why I am making N* wrapper utilities that talk over SIO, for those OSes like DOS 2.0 that can't properly handle this. Being able to specify where the code relocates may also be an interesting idea.

 

so, basically, because I can configure the fujinet beforehand, maybe once I get relocation working, I could make it place itself behind MEMHI?

 

-Thom

 

[phaeron]

Not sure about BURIEDBU.COM as I don't have it, but I'm not seeing an issue with BASIC at least with your latest handler disk. The handler will be temporarily overwritten while DUP is loaded, but that won't be an issue as long as the N: device is not actually in use and MEM.SAV is set up. HATABS contains the device letter needed for handler matching and the handler table it points to is only needed if the handler is matched against the path.

 

You do need to ensure that loaded programs have a segment within $1D00-33FF as that is the signal for DUP to swap in MEM.SAV. Without that, DUP assumes that it can coexist with the loaded program.

 

[tschak909]

@phaeron yes, BASIC works fine, it's when you try to do any file operations inside DUP, because the handler's gone.

 

That's okay I guess. The solutions are:

 

(1) make a handler that loads into high mem

(2) make utilities that call the SIO directly for networked operations for DOS 2 and MyDOS, as SpartaDOS, OS/A+, DOS XL, XDOS, etc. do not have these issues.

 

I will tackle those once I get the handler into a relocatable state, I will also look at your type 3/4 poll handler, as I want to see if it is possible in addition to type 1 to implement type 3 and 4 relocatable poll handling.

 

-Thom

[dmsc]

Hi!

26 minutes ago, tschak909 said:

@phaeron yes, BASIC works fine, it's when you try to do any file operations inside DUP, because the handler's gone.

As phaeron says:

33 minutes ago, phaeron said:

You do need to ensure that loaded programs have a segment within $1D00-33FF as that is the signal for DUP to swap in MEM.SAV. Without that, DUP assumes that it can coexist with the loaded program.

 

That is the key.

 

Have Fun!

 

[tschak909]

4 minutes ago, dmsc said:

Hi!

As phaeron says:

That is the key.

 

Have Fun!

 

Yes, my handler loads at $2300 by default (this is the memlo for DOS 2.0), again, you guys are missing a subtle point:

 

DUP attempts the CIO open before it swaps back in the affected memory area. Understandable. There doesn't seem to be a way to make DOS 2.0's DUP play nicely with the N: handler for things like a COPY or a BINARY LOAD while staying loaded in the DUP memory area.

 

It works just fine with BASIC, though.

 

Mayyybe there could be a patched DOS 2.5 DUP with the N: handler folded in...

 

So the solution is the two point solution above, try to make utilities to work around it, and make a version of the N: that can load into high or hidden mem area, so that things can work. I was just trying to see if I was missing something, but it's pretty clear that I am in very much off the map territory here.

 

-thom

 

 

Edited May 3, 2020 by tschak909

[dmsc]

Hi!

22 minutes ago, tschak909 said:

Yes, my handler loads at $2300 by default (this is the memlo for DOS 2.0), again, you guys are missing a subtle point:

No, it is not your loader what has to include a segment within $1D00-33FF - it is the *loaded program*, in your example the N:BURIEDBU.COM file. But...

 

22 minutes ago, tschak909 said:

DUP attempts the CIO open before it swaps back in the affected memory area. Understandable. There doesn't seem to be a way to make DOS 2.0's DUP play nicely with the N: handler for things like a COPY or a BINARY LOAD while staying loaded in the DUP memory area.

You are right, DOS (it is not DUP who does this) first OPEN the file to be able to check if it will be loaded over the MEM.SAV area, at this point you are doomed.

 

My recommendation: try to build a *minimal* driver, moving your logic outside the Atari and into the Fujinet device, you can hide a device like this in the cassette buffer. Using any memory beyond $2000 will make your handler incompatible with many (most?) programs - including TurboBasicXL and FastBasic.

 

22 minutes ago, tschak909 said:

Mayyybe there could be a patched DOS 2.5 DUP with the N: handler folded in...

Don't bother - just use BW-DOS then, as it allows you to place your handler in low memory without conflicts.

 

Have Fun!

[tschak909]

8 minutes ago, dmsc said:

Hi!

No, it is not your loader what has to include a segment within $1D00-33FF - it is the *loaded program*, in your example the N:BURIEDBU.COM file. But...

 

You are right, DOS (it is not DUP who does this) first OPEN the file to be able to check if it will be loaded over the MEM.SAV area, at this point you are doomed.

 

My recommendation: try to build a *minimal* driver, moving your logic outside the Atari and into the Fujinet device, you can hide a device like this in the cassette buffer. Using any memory beyond $2000 will make your handler incompatible with many (most?) programs - including TurboBasicXL and FastBasic.

 

Don't bother - just use BW-DOS then, as it allows you to place your handler in low memory without conflicts.

 

Have Fun!

Again, you're missing the point. sigh.

 

I am trying to maximize compatibility for an end-user device.

 

My driver IS a minimal driver, all the logic is done on the ESP, the CIO is a pass-through. look at the listing!

-Thom

[+CharlieChaplin]

You could try a DOS that does not require a DUP, i.e. is DOS.SYS only - like DOS XL, XDOS, DOS II+D and many other DOS 2.x versions. Or one of the SDFS versions, including Sparta, Bewe and Real DOS...

 

Alternatively you could try DOS 2.0 or DOS 2.5 with a DUP replacement (much shorter DUP) aka a command processor, like e.g. BBK CP, DOS 2.5 CP and several others...

 

[dmsc]

Hi!

2 minutes ago, tschak909 said:

Again, you're missing the point. sigh.

 

I am trying to maximize compatibility for an end-user device.

 

My driver IS a minimal driver, all the logic is done on the ESP, the CIO is a pass-through. look at the listing!

-Thom

No, your driver is too big: almost 1kB of code and 2kB of buffers - this is bigger than a full DOS like LiteDOS (2kB total). It is not possible to have a handler that big in the Atari and be compatible with most programs.

 

So, you have to make it smaller, my suggestions:

- Don't use buffers - a single 16 byte buffer for preparing/receiving SIO frames located at $3C0 should be enough.

- Don't write error messages, just pass those to CIO - those are not needed and use a lot of space.

- Don't translate commands - send over SIO the full IOCB to the remote device, then send or receive the application buffer at ICBAL/ICBAH directly.

- Add a little logic to detect bulk transfers if you have enough space.

- Move your initialization logic (the driver installation) outside the driver memory, as it is not needed after install. This section can be long and verbose, with error messages if the driver is not detected and even an optional uninstall option. After driver installation, this area is not used anymore so it is available to other applications.

 

Have Fun!

 

[tschak909]

1 minute ago, dmsc said:

Hi!

No, your driver is too big: almost 1kB of code and 2kB of buffers - this is bigger than a full DOS like LiteDOS (2kB total). It is not possible to have a handler that big in the Atari and be compatible with most programs.

 

So, you have to make it smaller, my suggestions:

- Don't use buffers - a single 16 byte buffer for preparing/receiving SIO frames located at $3C0 should be enough.

- Don't write error messages, just pass those to CIO - those are not needed and use a lot of space.

- Don't translate commands - send over SIO the full IOCB to the remote device, then send or receive the application buffer at ICBAL/ICBAH directly.

- Add a little logic to detect bulk transfers if you have enough space.

- Move your initialization logic (the driver installation) outside the driver memory, as it is not needed after install. This section can be long and verbose, with error messages if the driver is not detected and even an optional uninstall option. After driver installation, this area is not used anymore so it is available to other applications.

 

Have Fun!

 

Did you even bother to read my listing? Also, this driver is smaller than the 850 R: handler that actually sits in memory. so. wtf?

-Thom

Edited May 3, 2020 by tschak909

[dmsc]

Hi!

1 minute ago, tschak909 said:

Did you even bother to read my listing? Also, this driver is smaller than the 850 R: handler that actually sits in memory. so. wtf?

-Thom

Yes, I did read it. Did you read my response?

 

Have Fun!

 

[tschak909]

7 minutes ago, CharlieChaplin said:

You could try a DOS that does not require a DUP, i.e. is DOS.SYS only - like DOS XL, XDOS, DOS II+D and many other DOS 2.x versions. Or one of the SDFS versions, including Sparta, Bewe and Real DOS...

 

Alternatively you could try DOS 2.0 or DOS 2.5 with a DUP replacement (much shorter DUP) aka a command processor, like e.g. BBK CP, DOS 2.5 CP and several others...

 

I am testing with _many_ DOSes, including the ones you mention. DOS 2.x is the odd one out here, because of the memory map issues, which can be dealt with.

 

To anyone commenting, please don't bother to respond until you've actually read my listings and understand what I am trying to do. I need buffers in exactly the same way that the disk system needs buffers, for almost the same damned reasons!

 

-Thom

[dmsc]

Hi!

2 minutes ago, tschak909 said:

I am testing with _many_ DOSes, including the ones you mention. DOS 2.x is the odd one out here, because of the memory map issues, which can be dealt with.

 

To anyone commenting, please don't bother to respond until you've actually read my listings and understand what I am trying to do. I need buffers in exactly the same way that the disk system needs buffers, for almost the same damned reasons!

 

No you are wrong. You don't need big buffers, at most a 128 byte buffer is enough for a CIO device, look at all the available DOS.

 

Old devices used fixed size sectors, so most modern DOS have 256 byte buffer (or even 512) to support big sectors. But in your case, you are defining the protocol, so you could do with 64 byte "sectors" if you wanted.

 

And as I explained above, you can transfer directly to/from application memory wuthout need for buffers - an example of this is the "autoboot" protocol implemented in AspeQT (RespeQT now) by Fatih Aygun.

 

Have Fun!

[tschak909]

If anyone can help make this driver better, please help. I have a _LOT_ of firmware to write.

 

(also, I just loaded a file over HTTP into AtariWriter through the N: device)...

 

-Thom

Edited May 3, 2020 by tschak909

[tschak909]

#Atari8bit #FujiNet - Have spent the last week porting the CIO handler to assembler. A lot more to do, but wanted to put it through its paces through a few different DOSes, and programs to show its transparency. I just loaded a document into AtariWriter from HTTP

 

 

[Rybags]

High mem just below the DList is an option but then the danger is being overwritten when a graphics mode is opened.

Another option is under Basic or the OS with some stub code down lower but then it's restricting you to 64K and possibly non cartridge environment.

Another if it's small enough is to spread out among areas such as low part of the stack, printer buffer, page 6 and the few spare byte areas below page 4 (Page 4 another option but easily overwritten by tape activity).

[Alfred]

4 hours ago, tschak909 said:

I am testing with _many_ DOSes, including the ones you mention. DOS 2.x is the odd one out here, because of the memory map issues, which can be dealt with.

 

To anyone commenting, please don't bother to respond until you've actually read my listings and understand what I am trying to do. I need buffers in exactly the same way that the disk system needs buffers, for almost the same damned reasons!

 

-Thom

 

I don't think you can go that high at MEMLO. I've always used $2800 as the max as a rule of thumb. For DOS 2.0 you'll probably just have to limit it to one N: device. If people want something better, then they'll just have to switch to a different DOS.