Looking for information on low level disk i/o calls

Página 2/3
1 | | 3

Por NYYRIKKI

Enlighted (6016)

Imagen del NYYRIKKI

14-11-2011, 14:56

I think you need to take the hard way then and create standard MSX-DOS1 driver in to 16K... MSX-DOS2 needs at least 64K mapped ROM and Nextor needs at least 128K mapped ROM. All the requirements, creation process and how to embed driver to Nextor is explained in Nextor Driver Development Guide I suggest you take a look even if you are planning to make DOS1 driver. There is good basic information of MSX disk system other ways as well.

Por Eugeny_Brychkov

Paragon (1232)

Imagen del Eugeny_Brychkov

14-11-2011, 15:03

Thank you. It seems I figured out how to create driver - my code should start at offset 07405h. The only question is how to make main part of the ROM support 0F0h descriptor (as I clearly saw that if descriptor is <=0F8h driver returns error) and figure out if it's flexible enough to use disk properties if I will put such 0F0h medium onto the list of supported media (at the beginning of driver code).

Por RetroTechie

Paragon (1563)

Imagen del RetroTechie

14-11-2011, 15:13

Thank you. There're some things which are immediately not clear for me:
DISKIO: why it needs disk descriptor? Check if disk was changed? Or to properly calculate physical sector number from logical one? I also assume that this sub is performing all the needed seeking, reading id ops as well as reading data itself.
DSKCHG: why it needs media id two times? Is there any rationale? It says "read the boot sector or the FAT sector" - well, where to read it? Is there any temp location for it?
GETDPB: why media id two times again?
DSKFMT: not clear what work ares is about - is it sector format array (filler byte, sector number on the track etc)? As I see it formats whole disk, thus "read track" need not to be implemented as is, right?

It may be helpful to check some driver sources, and see how above routines are implemented. That should clarify many of the why/how's...

It seems I will need mapper to use nextor? I do not have one, and expect code to be <=16K in bank 1 or <=32K in banks 1 and 2.
You mean banks 1 and 2 inside 4000-7FFFh area, or 4000-BFFFh area (usually called pages 1 and 2) ? If the latter: how would you do transfer to/from 8000-BFFFh RAM, when your ROM is paged in there? (yes you can read/write to page 3 buffer & then use XFER to copy data, but that would make disk I/O dog sloooowww).

Por NYYRIKKI

Enlighted (6016)

Imagen del NYYRIKKI

14-11-2011, 15:19

Yes compile should be easy: Fill template and save it as DRIVER.MAC then compile disk100\DISK.MAC (There is INCLUDE DRIVER.MAC at end of source)

The main part of ROM does not check media descriptor at all, so it is a task of your driver to handle it. Check out for example Sunrise driver sources (diskdrvs\sunrise)... It handles 0F0h descriptor.

Por zeilemaker54

Champion (345)

Imagen del zeilemaker54

15-11-2011, 05:21

If you need detailed information about the diskdriver routines, please check the MSX technical databook <url>http://www.msxarchive.nl/pub/msx/docs/manuals/msxtech.pdf</url>, pdf pages 259-270

Por Eugeny_Brychkov

Paragon (1232)

Imagen del Eugeny_Brychkov

27-11-2011, 11:00

Hi guys, update.

I used disk.mac. disk101.mac and diskupd.mac disk code.

Diskupd.mac does not compile at all - m80 abnotmally aborts.

With disk.mac and disk101.mac there's an issue:
In DOS mode it sets SP somewhere to C3xx, however in BASIC mode it also has it set to C3xx.
I checked ith PANASONICDISK.ROM - in BASIC mode it has SP set somewhere to Dxxx.

This behavior of .mac code gives problems when trying to load 16K .bin files in BASIC mode. .bin file usually loads at 8800, and ends at C800, but as you see stack is at C300, thus PC fails.

Please help obtaning proper disk rom code, or advise me if I forgot something in disk driver.

Por zeilemaker54

Champion (345)

Imagen del zeilemaker54

27-11-2011, 11:40

It is just as simple as putting disk.mac and your own driver.mac in the same directory and executing make.bat (provided that you also have m80,l80 and hex2bin. The result is disk.rom which is a rom file located at 04000H.
I am not sure how your driver code looks like, but diskbasic 1.0 allocates always the complete FAT size. So if you use a huge harddisk, a lot of memory is allocated for the FAT. If you are using a harddisk, you better use diskbasic 2.0.
If you like, i can take a look at your drivercode to see what is wrong.

Por zeilemaker54

Champion (345)

Imagen del zeilemaker54

27-11-2011, 11:44

by the way, disk101.mac is just an old version of the kernel. The disk.mac in diskupd is update version of kernel by myself, but the same as in my previous mail does apply.

Por Eugeny_Brychkov

Paragon (1232)

Imagen del Eugeny_Brychkov

27-11-2011, 15:01

My complete FAT is 9 sectors (1200h). One boot sector. 14 sectors for directory.
What is expected stack location in
(a) DOS mode
(b) BASIC mode?
As they seem to differ?

This is 1.44MB diskette


		db	0f0h		; MEDIA		0F8h
		dw	512		; SECSIZ
		db	0Fh		; DIRMSK = (SECSIZ/32)-1
		db	04h		; DIRSHFT
		db	0		; CLUSMSK	01h
		db	01h		; CLUSSHFT	02h
		dw	1		; FIRFAT
		db	2		; FATCNT
		db	224		; MAXENT	112
		dw	33		; FIRREC	12
		dw	2848
		db	9		; FATSIZ	2
		dw	19		; FIRDIR	5

Por zeilemaker54

Champion (345)

Imagen del zeilemaker54

27-11-2011, 16:16

STKTOP is at 0DB82H if using a two drive 720KB 3.5" system, so for FAT 2*3*512 = 3072 bytes for FAT
If you where to use 1.44" this would be 2*9*512 = 9216 bytes, STKTOP should be arond 0C382H.

If you are using a big sized FAT, always use disk kernel 2.0.
Kernel 2.0 is not allocating the FAT buffer in page 3, but in memorymapper, which leaves you with more stackspace.

Página 2/3
1 | | 3