DOS1 bug in handling devices?

Expert (127)

05-06-2007, 15:03

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?

By mohai

Paragon (1031)

05-06-2007, 16:45

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

By Kwik

Expert (127)

05-06-2007, 17:06

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

By flyguille

Prophet (3031)

05-06-2007, 19:19

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.

By zeilemaker54

Champion (355)

06-06-2007, 08:37

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!

By Kwik

Expert (127)

06-06-2007, 10:02

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?

By zeilemaker54

Champion (355)

06-06-2007, 12:15

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 ?

By Kwik

Expert (127)

06-06-2007, 13:58

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.

By Kwik

Expert (127)

07-06-2007, 19:54

In case of the AUX device:

copy bla1.txt aux

By Kwik

Expert (127)

09-06-2007, 21:56

anyone?

By Sonic_aka_T

Enlighted (4130)

09-06-2007, 22:55

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)