I'm implementing an AUX device for Nowind and noticed something strange. When i tried to send a file greater than 16kB to AUX, not all bytes were sent and there was rubbish at the end. Dos1 first loads as much of the file in ram as is possible and then sends it from there. While sending, the routine does not take into account that the diskrom itself is in page 1. So when the transfer address reaches 0x4000, the contents of the diskrom is sent, in stead of the ram contents.

PRN suffers from the same problem. Try copying a 16kB file to PRN in dos1 and capture the printer output (blueMSX can do this). The problem seems to be fixed in dos2. Is this a known bug?

When using DISKROM (DOS 1), it is not allowed to transfer data to page 1 (4000h-7fffh) or load files to it. It is not a bug, but a rule. Keep in mind that DISKROM is allocated at this page. I know it is a little annoying , but this is the way this ROM works...
Try to use MSX-DOS environment instead

Quote:

When using DISKROM (DOS 1), it is not allowed to transfer data to page 1 (4000h-7fffh) or load files to it.

That's not true. The driver part of the diskrom can transfer to page 1. There is even the XFER routine that is meant especially for transfers to page 1. It can be used by the driver part when it cannot write to page 1 direct. The upper 8 kB of Nowind is mirror in page 2. It therefore does not need to use XFER but can transfer direct (much faster).

And i do consider it a bug when copying a file greater than 16kB to (e.g.) the PRN device fails, because it copies part of the diskrom itself...

I remember trying to use BDOS (DOS1) functions of the DISKROM 1.0 at BOOT SECTOR to load a secuence of disk-sectors. It wasn's able to copy exactly 16k (16384) bytes, but it was able to copy only up to 16382 or something. And it on a MSX2 loading to page 2 but using the mapper. Simply it hungs or corrupts something, after that I trashed the loader and move to BLOAD type loader for MNBIOS disks.

There is a huge difference between using the DiskBasic and MSX-DOS environment (in DOS1). In the DiskBasic enviroment, transfers to page 2 and 3 are supported, not to page 0 and 1! MSX-DOS supports all pages. DOS2 works differently, because it is using the memorymapper. Transfers are always mapped to page 2, only the block in the mapperregister is changed. But remind you, DOS2 has some contrains too! It can only transfer to or from the system memorymapper. It means that if you have a second memorymapper, you can not transfer to or from it with the BDOS calls!

Thanks all for you contributions, but the question remains. Is it or is it not a bug? I'm only considering MSXDOS, not BASIC.

When copying data to a device, the diskrom first transfers the data to memory. This transfer has no problem writing data to RAM in page 1. The next step is to read all data from memory and send it to the device. The routine responsible for this does not take into account that RAM is not accessible in page 1, because the diskrom itself is in page 1. Consequently it sends the first ~16kB to the device, and then part of the content of the diskrom until it reads EOF (0x1a) and then quits.

Perhaps it is not allowed to send "big" files to a device?

May be you can supply an example of how you are sending the data to the AUX device. I mean, which BDOS function are you using ?

In MSXDOS on the command line do this:

copy bla.txt prn

Make sure the file is bigger than 16kB. When you capture the printer output (blueMSX can do this), you'll notice the file will not completly be sent. You can also copy to AUX and capture the routine at 0xf32c. Register A will contain the character.

In case of the AUX device:

copy bla1.txt aux

anyone?

dunno, but if you say simply copying the file in MSX-DOS doesn't even work then you've probably found a bit of a bug indeed. Does the same happen on hardware? If I understand your post correctly it means that COPY TEXTFILE.TXT PRN woulnd't work if the textfile is larger than 16kB? I should think there are still a few people who have the hardware to test this... (sorry, but I don't)

Off course i cannot be 100% certain about what happens on real hardware, but studying sources of diskroms it is just something the diskrom does not take into account... I'm amazed that it seems nobody encountered this before?

B.t.w. i read something about addaux.com? Does anyone know what it does? Is it a kind of redirection of AUX to COM? This is interesting, as it might suffer from the same problem.

nono, I see that about the year 2001....

with bdos functions, just opens a 32k file, and try to load it in two parts (16k + 16k) both mapping to page 2 using different mapper pages offcourse that doen's work.

now, with the same code just try to load 16k-4bytes or something, and it will works! for both pages. But then comes the problem of HOW HELL to fill that 4 last bytes....

I tried solutions like setting the I/O file pointer and just to transfer 4 bytes, or something..... doesn't works.

Then, I just tested the direct DSKI$ function of BDOS but thinking that the file needs to be allways at the same sectors, it is not an option.

Tired of that crap, lefted the BOOT SECTOR's loader and swap to a .BAS loader... more dirty... but enought as for to load the 32KB of the MNBIOS KERNEL.

Kwik is right, DOS1 has a bug in handling transfers to/from page 1 when it comes to devices!

Thanks for checking it, zeilemaker54! The problem has indeed nothing to do with disk transfers to/from page 1. It is specific for devices. So i guess for Nowind i can't simply use the hooks at F371/F374. I'll have to patch the routines that call these hooks.