Re: Round 16... FAT! (help wanted!!)
What you could do, instead of setting the disk change flag, is to either update or mark as invalidated any data that can change if a disk is changed. Here is the problem: I have not enough internal info about DOS so I don't know where is this "any data". So I prefer to leave all unchanged, so DOS will do all the dirty work. What info does DOS keep of a disk? Is it only the disk buffers, or is there more? There is more: current directory, volume label, etc... but how many info? And where? 15th MSX users meeting in Barcelona: May 1th, 1999 Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user New address!!http://konamiman.msx.tni.nl [EMAIL PROTECTED] ICQ#: 18281450 Metal Gear for MSX - (C) Konami 1987 (Nothing new under the sun...) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Round 16... FAT! (help wanted!!)
You could figure out how to set this disk change flag for other interfaces, but it's disk hardware-specific, so better leave it alone... But my driver will be anyway hardware-specific... By the way, why everybody worry so much about this? I said that hardware dependant routines are separated from the main code, so anyone can change it for other interfaces. I suppose that someone has information about internal working of IDE and other SCSIs, as well as enough programming knowledge for doing the changes, right? Or are you saying that I'm the best programmer around the world?? No way! 8-) -Avoid making a "disk changed?" call. If you do need it: maybe you can use the result of a "disk changed?" call made by DOS earlier? But what if my driver must handle the first function call performed after a disk change? And where does DOS store this information? -Maybe you can use another interception point for your routine, at a point where DOS already determined this disk change status? I can't patch anywhere other than the #F252 hook... except if I had the source codes of DOS... aaah nice dream... -DOS does this call again, after your code? Maybe you can use a different exit point from your code, skipping this next DOS call, and pass on the result of the "disk changed?" call you made? I can only do all or nothing: if I patch a function call, I must do it completely (till the exit of the #F252 call). -Or: intercept somehow this next "disk changed?" call made by DOS (difficult, tricky) Yes, difficult. Because of this and because similar problems, one year ago I asked for internal DOS info. But nobody seems to have this information... (O! !O) Dos HAS code for handling "Abort", right? You can do the same, but instead, you could also jump back to that DOS code handling "abort" (and don't care what happens from there). That was the idea. Well, the goal is the to find this "abort" code. It is not so easy. When a function call is executed, a REALLY BIG LOT of code is executed! You can't imagine!! (^^!) 15th MSX users meeting in Barcelona: May 1th, 1999 Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user New address!!http://konamiman.msx.tni.nl [EMAIL PROTECTED] ICQ#: 18281450 Metal Gear for MSX - (C) Konami 1987 (Nothing new under the sun...) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Round 16... FAT! (help wanted!!)
Nestor Soriano [EMAIL PROTECTED] wrote: SET the disk change flag? Why do you need to do that? The behavior of my driver when a function call is made is the following: - Check if the disk has been changed via CALL #4013. - If not, read an internal table which contains the type of the drive. If FAT16, process function call. Else (FAT12) do not process and let DOS to do it. - If yes, read boot sector in order to determine the type of drive. If FAT16, build new DPB and process function call. Else, let DOS to do it. Update the drive type table in both cases. Well, suppose that disk was changed and it is FAT12 type. My driver must do nothing and let DOS to execute funtion call. But what will do DOS at first? To check if the disk was changed. But my driver did it already!! So DOS will obtain a "disk not changed" status, even if the disk was changed, and will not update the drive's work area. This is very dangerous... How to solve it: if the disk was changed and it is FAT12, set again the disk change flag, so next call to #4013 (check disk change), performed by DOS, will return "disk was changed" status. I know how to do it but only on MegaSCSI. You could figure out how to set this disk change flag for other interfaces, but it's disk hardware-specific, so better leave it alone... Possible solutions for the above: -Avoid making a "disk changed?" call. If you do need it: maybe you can use the result of a "disk changed?" call made by DOS earlier? -Maybe you can use another interception point for your routine, at a point where DOS already determined this disk change status? -DOS does this call again, after your code? Maybe you can use a different exit point from your code, skipping this next DOS call, and pass on the result of the "disk changed?" call you made? -Or: intercept somehow this next "disk changed?" call made by DOS (difficult, tricky) If it only works with MegaSCSI, then it's really a MegaSCSI modification, not some kind of 'driver'. If so, I think you'd better re-do it. No. It is NOT a MegaSCSI modification, because I don't change anything of MegaSCSI SRAM. My driver resides in a RAM segment. Besides when a FAT12 drive is accessed, my driver does nothing, and normal DOS code is executed: no modification at all then. MegaSCSI modification = adding something, that only works with megaSCSI, not other interfaces. What it does with the megaSCSI itself, or where that added code stays: I don't care! b) If possible, simply return/jump back to the original end of a routine? What? Sorry I don't understand what you mean. Anyway I think you are maybe speaking about "ignore" option, not "abort"... Dos HAS code for handling "Abort", right? You can do the same, but instead, you could also jump back to that DOS code handling "abort" (and don't care what happens from there). That was the idea. I also don't know how sector buffers works, as well as "fork a child process" (what the hell is this???) X-) See MSX-DOS 2 function call documentation, functions 60 61h. Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msx MSX Tech Doc page MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Round 16... FAT! (help wanted!!)
At 07:01 PM 3/18/01 +0100, you wrote: SET the disk change flag? Why do you need to do that? The behavior of my driver when a function call is made is the following: - Check if the disk has been changed via CALL #4013. - If not, read an internal table which contains the type of the drive. If FAT16, process function call. Else (FAT12) do not process and let DOS to do it. - If yes, read boot sector in order to determine the type of drive. If FAT16, build new DPB and process function call. Else, let DOS to do it. Update the drive type table in both cases. Well, suppose that disk was changed and it is FAT12 type. My driver must do nothing and let DOS to execute funtion call. But what will do DOS at first? To check if the disk was changed. But my driver did it already!! So DOS will obtain a "disk not changed" status, even if the disk was changed, and will not update the drive's work area. This is very dangerous... What you could do, instead of setting the disk change flag, is to either update or mark as invalidated any data that can change if a disk is changed. What info does DOS keep of a disk? Is it only the disk buffers, or is there more? If it's only the disk buffers, the solution is simple: perform "invalidate disk buffers" (standard DOS2 call) whenever disk change status is "changed". If a FAT12 disk is accessed, DOS will read a "disk not changed" status, but this doesn't matter as there is no info left about the disk that was changed. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Round 16... FAT! (help wanted!!)
At 05:53 PM 3/17/99 +0100, you wrote: If so, a FAT16 driver should not in any way depend on a certain type of hardware/ROM, only change things that are the same with any disk interface. Or any DOS2-using interface, if you like. Yes, the standard way for accessing physical sectors is through routine #4010 of diskROM. But the standard input parameters specification for this routine allows only the use of 16 bit sector numbers. So, for accessing 24 bits sector numbers a controller specific routine is needed. So you are actually doing 2 upgrades at once? Upgrades being: 1. 16bit sector numbers - 24bit sector numbers (allows partitions 32MB) 2. FAT12 - FAT16 (keeps cluster size reasonable when partitions go beyond 32MB) Besides I need to set the "disk change" flag under certain circumstances, and (AFAIK) there is not standard diskROM routine for this. SET the disk change flag? Why do you need to do that? Reading the flag is perfectly possible using diskROM, but you probably already knew that. I also don't know how sector buffers works, Sector buffers are a kind of cache. They are located in the 32K of memory that DOS2 claims. If a sector is requested and it is located in a sector buffer, the content of the buffer is returned instead of reading the sector from disk. This is the mechanism that allows a turbo R to display "files" in BASIC a second time without accessing the drive. Disk buffers are invalidated whenever disk change status is "changed" or "unsure". If your MSX has hardware disk change checking (like turbo R), the hardware signal is used. Otherwise, the status will be "not changed" for a certain number of interrupts. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Round 16... FAT! (help wanted!!)
So you are actually doing 2 upgrades at once? 1. 16bit sector numbers - 24bit sector numbers (allows partitions 32MB) 2. FAT12 - FAT16 (keeps cluster size reasonable when partitions go beyond 32MB) Yes. It has no sense to do one of these upgrades without doing the other, I think! ;-) SET the disk change flag? Why do you need to do that? The behavior of my driver when a function call is made is the following: - Check if the disk has been changed via CALL #4013. - If not, read an internal table which contains the type of the drive. If FAT16, process function call. Else (FAT12) do not process and let DOS to do it. - If yes, read boot sector in order to determine the type of drive. If FAT16, build new DPB and process function call. Else, let DOS to do it. Update the drive type table in both cases. Well, suppose that disk was changed and it is FAT12 type. My driver must do nothing and let DOS to execute funtion call. But what will do DOS at first? To check if the disk was changed. But my driver did it already!! So DOS will obtain a "disk not changed" status, even if the disk was changed, and will not update the drive's work area. This is very dangerous... How to solve it: if the disk was changed and it is FAT12, set again the disk change flag, so next call to #4013 (check disk change), performed by DOS, will return "disk was changed" status. I know how to do it but only on MegaSCSI. Reading the flag is perfectly possible using diskROM, but you probably already knew that. Yes but... setting?? I also don't know how sector buffers works, Sector buffers are a kind of cache. They are located in the 32K of memory that DOS2 claims. [...] Yeah, I know the general working procedures of sector buffers, but I don't know all the exact parameter: I know where they are placed, and the meaning of some bytes of the headers... but not all. And there is a flags byte whose description I don't know... And add other problem: sector buffer's header use only two bytes for sector number! So I think it is better if I use my own buffers, placed into another own RAM segment. And I can ever add an option for customize number of sector buffers, using more RAM segments if necessary. Disk buffers are invalidated whenever disk change status is "changed" or "unsure". Thanx! I had not tough in this detail!! ;-) But my "abort" routine continues crashing... someone, help!! (O! !O) 15th MSX users meeting in Barcelona: May 1th, 1999 Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user http://www.geocities.com/SiliconValley/Bay/9797/msx.htm [EMAIL PROTECTED] ICQ#: 18281450 Metal Gear for MSX - (C) Konami 1987 (Nothing new under the sun...) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Round 16... FAT! (help wanted!!)
Nestor Soriano [EMAIL PROTECTED] wrote: Yep, tired of searching technical info, and since nobody does anything (eh Pazos! Esto no va por ti; yo ya me entiendo) I started my FAT16 driver. Unlike PazosOkei one, it is not a patch for diskROM, but a completely self-made driver which will be placed into a RAM segment. I'm making it for MegaSCSI, but the controller dependant routines (just three routines) are clearly separated from the rest of the code, so anybody can modify it for any other controller. I am really sorry to have to write this, but: Doesn't a FAT16 driver modify the disk system, and not the disk-I/O itself? For clarity: with 'disk system' I mean here: the non-hardware dependant software, that for instance resides in an ordinary DOS2-cartridge. With 'disk-I/O' I mean: the low-level, hardware-dependant part of diskROMs. If so, a FAT16 driver should not in any way depend on a certain type of hardware/ROM, only change things that are the same with any disk interface. Or any DOS2-using interface, if you like. A FAT16 driver changes the FILE system, and thus should work with any type of disk that supports that file system, in this case: any disk hardware that could support FAT16 formatted disks, not just MegaSCSI. If it only works with MegaSCSI, then it's really a MegaSCSI modification, not some kind of 'driver'. If so, I think you'd better re-do it. I almost finished the "basic engine" but I have problems with the error handling part, so I ask for help. Here is the problem: [HI-TECH MODE ON] X-) Imagine that a function call is being executed. Page 2 contins the DOS data segment. Page 0 should contain the DOS code segment... ... (...more tech speak...) ... - Restore TPA segments in pages 1 and 2 - Load C=#62 (program terminate) and B=Error code - Jump to #0005 in TPA segment of page 3, via inter-segment call It works and COMMAND.COM takes control, but next execution of a program causes the computer to hang. [HI-TECH MODE OFF] SOS... help... maidai... dios mio, esto es un infierno... X-) I just need to solve this problem for having a "releasable" version of the driver (I hope!!). Also, any suggestion beta-testing offers will be welcome of course! On error handling: Why not - a) Start end your routines as much as possible the same way as is done in the original routines (do some disassembling code copying, only squeezing your own version of the interesting parts in between), or b) If possible, simply return/jump back to the original end of a routine? Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msx MSX Tech Doc page MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Round 16... FAT! (help wanted!!)
If so, a FAT16 driver should not in any way depend on a certain type of hardware/ROM, only change things that are the same with any disk interface. Or any DOS2-using interface, if you like. Yes, the standard way for accessing physical sectors is through routine #4010 of diskROM. But the standard input parameters specification for this routine allows only the use of 16 bit sector numbers. So, for accessing 24 bits sector numbers a controller specific routine is needed. Besides I need to set the "disk change" flag under certain circumstances, and (AFAIK) there is not standard diskROM routine for this. BTW, routine #4010 of MegaSCSI was modified for accessing 24 bit (actually 23) sector numbers, so actually I use this routine in my driver. But I don't know if other interfaces have also this modification, so I separated this part from the main code. The modification is as follows: Standard #4010 routine definition: Input: C = Media ID MegaSCSI #4010 routine definition: Input: C = Media ID if bit 7 = 1 C = Starting sector number (bits 22-16) if bit 7 = 0 All other input parameters are identical in both cases. A FAT16 driver changes the FILE system, and thus should work with any type of disk that supports that file system, in this case: any disk hardware that could support FAT16 formatted disks, not just MegaSCSI. For this reason the controller dependant routines are separated from the main code, so anyone knowing how other interfaces work (designers? manufacturers?) can change it; sorry, I have only MegaSCSI and information for MegaSCSI, so I can program only for MegaSCSI. BTW it is just three routines: physical sector access, disk change flag setting, and checking if a slot contains the controller. If it only works with MegaSCSI, then it's really a MegaSCSI modification, not some kind of 'driver'. If so, I think you'd better re-do it. No. It is NOT a MegaSCSI modification, because I don't change anything of MegaSCSI SRAM. My driver resides in a RAM segment. Besides when a FAT12 drive is accessed, my driver does nothing, and normal DOS code is executed: no modification at all then. - Jump to #0005 in TPA segment of page 3, via inter-segment call By the way I commited mistake when typing this... it is "page 0" of course! a) Start end your routines as much as possible the same way as is done in the original routines (do some disassembling code copying, only squeezing your own version of the interesting parts in between), MSXDOS.SYS uses a lot of memory addresses which depends on the TPA end address, so I can't make a "fixed" code emulating this. My driver takes control via hook #F252, when DOS code and data segement are already set, and stack is already placed in page 3, so I must not use these variable addresses. b) If possible, simply return/jump back to the original end of a routine? What? Sorry I don't understand what you mean. Anyway I think you are maybe speaking about "ignore" option, not "abort"... BTW my driver will never show "ignore" option. Sometimes DOS shows it, sometimes doesn't, and since I don't know how to decide if ignore should be allowed or not, I'll never allow. If someone knows, please... I also don't know how sector buffers works, as well as "fork a child process" (what the hell is this???) X-) Hasta incluso! - Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user http://www.geocities.com/SiliconValley/Bay/9797/msx.htm [EMAIL PROTECTED] ICQ#: 18281450 Please don't send me messages with HTML code "New Pentium 34. Obsolete in 2 months. Guaranteed!" - MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
