Hello, anyone has descriptions of input argument and output values of the following system calls
DSKIO
INIHRD
MTOFF
DRIVES
INIENV
DSKCHG
GETDPB
CHOICE
DSKFMT
OEMSTAT
and maybe others related to storage media i/o.
ログイン/登録して投稿
Hello, anyone has descriptions of input argument and output values of the following system calls
DSKIO
INIHRD
MTOFF
DRIVES
INIENV
DSKCHG
GETDPB
CHOICE
DSKFMT
OEMSTAT
and maybe others related to storage media i/o.
; A template driver section ; (C) 1992-2005 by Ultrasoft ; ; By: Arjen Zeilemaker ; ; Version: 0.90 ; symbols which can be used from the kernel ; GETSLT get my slotid ; DIV16 divide ; GETWRK get my workarea ; SETINT install my interrupt handler ; PRVINT call orginal interrupt handler ; PROMPT prompt for phantom drive ; RAWFLG verify flag ; $SECBUF temporary sectorbuffer ; XFER transfer to TPA ; DISINT inform interrupts are being disabled ; ENAINT inform interrupts are being enabled ; PROCNM CALL statement name ; symbols which must be defined by the driver ; INIHRD initialize diskdriver hardware ; DRIVES how many drives are connected ; INIENV initialize diskdriver workarea ; DSKIO diskdriver sector i/o ; DSKCHG diskdriver diskchange status ; GETDPB build Drive Parameter Block ; CHOICE get format choice string ; DSKFMT format disk ; DSKSTP stop diskmotor ; OEMSTA diskdriver special call statements ; MYSIZE size of diskdriver workarea ; SECLEN size of biggest sector supported by the diskdriver ; DEFDPB pointer to a default Drive Parameter Block ; errorcodes used by DSKIO, DSKCHG and GETDPB ; ; 0 write protect error ; 2 not ready error ; 4 data (crc) error ; 6 seek error ; 8 record not found error ; 10 write fault error ; 12 other error ; errorcodes used by DSKFMT ; ; 0 write protect error ; 2 not ready error ; 4 data (crc) error ; 6 seek error ; 8 record not found error ; 10 write fault error ; 12 bad parameter ; 14 insufficient memory ; 16 other error MYSIZE equ 1 ; Size of environment SECLEN equ 512 ; Size of biggest sector ; INIHRD ; ; Input: None ; Output: None ; Changed: AF,BC,DE,HL,IX,IY may be affected INIHRD: ret ; DRIVES ; ; Input: F Zx set if to return physical drives ; Zx reset if to return at least 2 drives, if only one ; physical drive it becomes a phantom drive ; Output: L number of drives ; Changed: F,HL,IX,IY may be affected ; ; Remark: DOS1 does not handle L=0 correctly DRIVES: ld l,1 ret ; INIENV ; ; Input: None ; Output: None ; Changed: AF,BC,DE,HL,IX,IY may be affected ; ; Remark: examples installs own interrupt handler, but this is NOT required. ; depends on the hardware if this is needed. INIENV: call GETWRK ld (hl),1 ld hl,INTHAND jp SETINT INTHAND: push af push bc push de push hl push ix push iy call GETWRK inc (hl) pop iy pop ix pop hl pop de pop bc pop af jp PRVINT ; ; DSKIO ; ; Input: A Drivenumber ; F Cx reset for read ; Cx set for write ; B number of sectors ; C Media descriptor ; DE logical sectornumber ; HL transferaddress ; Output: F Cx set for error ; Cx reset for ok ; A if error, errorcode ; B if error, remaining sectors ; Changed: AF,BC,DE,HL,IX,IY may be affected DSKIO: ld a,12 scf ret ; DSKCHG ; ; Input: A Drivenumber ; B 0 ; C Media descriptor ; HL pointer to DPB ; Output: F Cx set for error ; Cx reset for ok ; A if error, errorcode ; B if no error, disk change status ; 01 disk unchanged ; 00 unknown ; FF disk changed ; Changed: AF,BC,DE,HL,IX,IY may be affected ; Remark: DOS1 kernel expects the DPB updated when disk change status is unknown or changed ; DOS2 kernel does not care if the DPB is updated or not DSKCHG: or a ld b,1 ret ; GETDPB ; ; Input: A Drivenumber ; B first byte of FAT ; C Media descriptor ; HL pointer to DPB ; Output: [HL+1] ; .. ; [HL+18] updated ; Changed: AF,BC,DE,HL,IX,IY may be affected GETDPB: or a ex de,hl inc de ld hl,DpbTable ld bc,18 ldir ret DpbTable: db 0F8h dw 512 db 0Fh db 04h db 01h db 02h dw 1 db 2 db 112 dw 12 dw 355 db 2 dw 5 DEFDPB equ DpbTable-1 ; CHOICE ; ; Input: None ; Output: HL pointer to choice string, 0 if no choice ; Changed: AF,BC,DE,HL,IX,IY may be affected CHOICE: ld hl,ChoiceStr ret ChoiceStr: db 13,10 db "1 - Choice A",13,10 db "2 - Choice B",13,10 db 13,10 db 0 ; DSKFMT ; ; Input: A choicecode (1-9) ; D drivenumber ; HL begin of workarea ; BC length of workarea ; Output: F Cx set for error ; Cx reset for ok ; A if error, errorcode ; Changed: AF,BC,DE,HL,IX,IY may be affected DSKFMT: ld a,16 scf ret ; OEMSTATEMENT ; ; Input: HL basicpointer ; Output: F Cx set if statement not recognized ; Cx reset if statement is recognized ; HL basicpointer, updated if recognized ; unchanged if not recognized ; Changed: AF,BC,DE,HL,IX,IY may be affected OEMSTA: scf ret ; DSKSTP (Not the offical name) ; ; Input: None ; Output: None ; Changed: AF,BC,DE,HL,IX,IY may be affected DSKSTP: ret
Oh thank you so much!
Second question - descriptions of the
INIHRD Init hardware
INIENV Initialize environment
OEMSTATEMENT New statements
are these available through hooks in disk basic? What do they do?
Oh thank you so much!
Second question - descriptions of the
INIHRD Init hardware
INIENV Initialize environment
OEMSTATEMENT New statements
are these available through hooks in disk basic? What do they do?
Edit
Thank you again!
Q: you list names of the procedures, but how to hook them if I want to replace them with my custom procedures?
Edit
Oh sorry again - just found out that these are the jumps at the beginning of the disk rom! Does it mean I can not hook them - and need to modify ROM with addresses of custom procedures? (I do not see calls to hooks from standard disk ROM procedures thus it seems not possible to "hack" the process of execution)
Q: you list names of the procedures, but how to hook them if I want to replace them with my custom procedures?
Eugeny, "VG8245.GEN" has what you ask - look at end of that file... (DSKSTP = MTOFF)
are these available through hooks in disk basic?
INIHRD - no
INIENV - no
OEMSTATEMENT - this IS a hook itself
What do they do?
INIHRD - 'reset' the hardware (as far as that's necessary). For example move drive head back to track 0, de-activate drive motors, initialize FDC registers, that kind of thing. Depending on hardware, may no not need to do anything.
INIENV - each diskROM has a very small work area (8 bytes for most 2793-based FDC's) where some variables are kept (eg. head positions, interrupt counter, etc). INIENV is for initializing that work area. Depending on use, may not need to do anything.
OEMSTATEMENT - called when a BASIC CALL statement is issued, and it's not one that main diskROM recognizes (like _FORMAT, _SYSTEM). This allows you to 'insert' / implement your own CALL commands easily. Again: need not do anything.
I do not see calls to hooks from standard disk ROM procedures thus it seems not possible to "hack" the process of execution
No, you have to hack the driver code in ROM instead... Under normal operation things are fixed.
Btw(1): IIRC a few more error codes can be returned if the driver is called from MSX-DOS2 (but those defined for DOS1 should do)
Btw(2): in DOS2, driver will not be asked to transfer data from/to page 1 (or page 0?). This must however be supported if driver is to work in DOS1 as well (see XFER helper routine, and various page 3 sector-buffers one might use for doing this).
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?
Oh sorry again - just found out that these are the jumps at the beginning of the disk rom! Does it mean I can not hook them - and need to modify ROM with addresses of custom procedures? (I do not see calls to hooks from standard disk ROM procedures thus it seems not possible to "hack" the process of execution)
Yes, this is true... I think best solution would be to make own disk ROM to replace the original ROM. I understand that this is not how ever always possible. May I ask what you are planning? It might be more easy to suggest possible solutions/workarounds if we would know exactly what you are trying to achieve...
I am finalizing development of the microcode of the microcontroller, which is expected to control FDC (1.44MB floppies).
First, I need to figure out which functionality MSX will need from this mictocontroller in order to define set of commands for microcontroller and their format, and next I need to have MSX having ROM controlling this microcontroller.
What I currently see:
1. We have several standard routines:
DRIVES Return number of connected drives
DSKIO Sector(s) read/write
DSKCHG Check disk change status
GETDPB Get Drive Parameter Block
CHOICE Get FORMAT choice string
DSKFMT (low level) Format a disk: physically and logically
and these can be ones to be implemented within microcontroller.
2. I take the latest available disk ROM (I need help on it to figure out which one is latest) and ideally which supports 1.44MB drives (descriptor 0F0h - for example, PANASONICDISK does not support 0F0h returning 0Ch ("other error" )). If such support is not available, I will have to modify existing ROM to support it. Then I will replace procedures listed in item (1) with pointers to my procedures which communicate with microcontroller, but these procedures will accept and return data in standard MSX format.
I think most easy way would be to do driver for Nextor and burn it as ROM. This should be very easy because needed routines are very simple and well documented. Problem might be that Nextor is bigger than normal 16K disk ROM and therefore needs some sort of mapper.
Other possibility is to make traditional disk driver and compile it. Practically this means that you need to fill the template that I posted and compile it as complete ROM with all the other stuff. (Source of the rest of the ROM together with some example disk drivers can be downloaded from here)
I think most easy way would be to do driver for Nextor and burn it as ROM. This should be very easy because needed routines are very simple and well documented. Problem might be that Nextor is bigger than normal 16K disk ROM and therefore needs some sort of mapper.
GR8BIT has 32K visible ROM for storage subsystem code. Thus it's ok if it's enough.
It's not clear how to handle nextor. Should I have nextor code installed into the system, and another ROM with driver? Plus, is this nextor proven to work with 1.44Mb diskettes? 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.
Don't you have an account yet? Become an MSX-friend and register an account!
