Hi again!
Maarten ter Huurne <[EMAIL PROTECTED]> wrote:
> >> But you still haven't convinced me (and some others) why 4010 should
> >> be updated instead of creating a new routine at a new address.
> (...)
> By changing parameters of an existing call, like you suggested,
> programmers have to learn the changes as well. This is unavoidable.
>
> >make every single
> >piece of software that PERHAPS might still have some use, useless 'by
> >definition',
>
> I can't think of any software, written for 16 bit sector numbers,
> that will function well on a partition requiring 32 bit sector
> numbers.
Sure you can!
-Debuggers with built-in sector-I/O function
-Sector-editors
-Disk TYPE checking utilities (=displaying bootsector-info)
etc. etc.
I WOULD agree, that for most of such utilities, their usefullness
would be LIMITED for drives using big sector numbers. The only point
I made here earlier: if you use an access method which remains
compatible, you can still USE these. For a sector-editor, this would
be limited to using it within a 16-bit sector number 'window', or the
first 32 MB. of a bigger partition. But you can still USE that, to
edit bootsector, FAT etc.
If you use a new entry, the only thing you CAN be sure of, is that
every existing software CANNOT be used for accessing those bigger
partitions.
Although some of you seem to like that, I think the problems that
might occur when older programs are used for bigger partitions, could
probably be overcome, or lived with. Like with the introduction of
DOS2; many programs had to be 'hacked'/patched, things like
MAP.COM/MAP.BIN were cooked up, but eventually, just about every
existing program could be made to work under DOS2.
When you use the existing entries, you can try and find such
solutions, and use that software that still has some use somehow, but
when you use new entries, you will simply have to rewrite every
single piece of software to use the big partitions, and you will
have as good as nothing to work on these in the mean while. That
simply seems like a waste to me, and avoidable too.
> >My view on this is simple: define new methods/entries etc., when
> >there is a CLEAR ADVANTAGE to be had from this. If no such clear
> >advantage exists, use existing entries/methods if possible, this will
> >simply minimize the overall impact, and make acceptance easier.
>
> Advantages:
> - HD BIOS implementation doesn't have to check whether old (16-bit)
> or new (32-bit) calling convention is used. - Complete freedom in
> specifying parameters.
I agree with these, however:
-as shown earlier, the impact on performance is minimal
for the total SIZE of code in a HD interface, it won't matter much
either (checking 16/32 bit number, or using 2 entries instead)
-freedom in specifying parameters? Nice, but as a
'programmer-minded-guy', I read that as: different sets of parameters
to remember/look up, and 2 different addresses to call, depending on
what disk/drive is accessed, for essentially the same action. You
call that an advantage?
I didn't hear anyone either, with ideas for extra/other parameters to
use (other than a bigger sector number), so what would be left, is
simply re-arranging the position of parameters in memory or Z80
registers.
I don't see the use for that either; you might have done it
differently when you had to define the original DISKIO now, but it
is, and for me, this is okay as it is. Changing the behaviour of the
DISKIO-routine (cache control, for instance) can easily be done using
other ways, no need to re-define DISKIO itself for that.
> But there was a different suggestion that will work well to protect
> partitions: direct sector I/O must be enabled explicitly by the
> user. For example, by specifying a certain environment variable.
You can do that, or disable partitions, or use environment settings
to control this, but the one thing to note here, is that this is free
(up) to the HDD-interface, to implement this somehow.
This whole discussion was not about this. If you can hook up drives
with bigger partitions to a HDD interface, and the interface would
recognise it, it's free for the interface to give the user choices to
disable/enable options on how to access these. The only thing this
discussion really is about, is:
IF a user would set the HD interface so, that programs would be
allowed access to these bigger partitions, HOW to let these programs
call this then? Wheter a particular HD interface will allow it, or
what options the user has to control this, is simply up to the makers
of such an interface.
I think the pro's and con's on this issue should be clear to anyone
by now. Can we please end the discussion on this part of the topic?
> >> It's not easy for the programmers of the HD BIOS. To fetch the
> >> sector number, the memory it is in must be selected. But by the time
> >> the HD BIOS looks up the sector number, a lot of slot switches have
> >> occured. Reading the correct values would take an inter-slot-read,
> >> which is slow.
> > (..)
> >If the BIOS routine is called, the system can copy the value to a
> >save location in page 3 or elsewhere in case it was in page 1, or
> >leave it alone otherwise.
>
> But where is "a safe location in page 3"? If you can find one, you
> might as well let the user store the sector number there.
You mean, you can't just use any location from a user program? Agree,
but what I meant is: for the SYSTEM (like for MSXDOS.SYS), ANY
memory location that is a) reserved by setting the right system
variables to reflect the memory space used, and b) not defined as
'external', that is, to be called or used by 'outside' programs, IS
'safe'.
Once for example MSXDOS.SYS is loaded, there is some memory space
used, which is normally not touched by user programs. Some parts of
this memory have a defined contents, but other parts are unknown, or
might have different uses in different versions of MSXDOS.SYS. For
MSXDOS.SYS itself, any memory location in such undefined parts,
could be used (by this MSXDOS SYS, not user programs!) for what I
called 'a safe address'.
> >Calling driver entry 4010h directly from an application program
> >would be illegal (as it is now, strictly speaking), with the
> >parameters in any other than page 1, no problem anyway.
>
> Loading sectors to page 1 is perfectly possible in DOS1 and DOS2, as
> far as I know.
Not quite:
For DOS1, the driver can use help routines, to make the access to the
whole 64K of memory possible, and works transparant for user
programs.
If you read some sectors in page 1 for example, the driver (diskROM)
might go about it like this:
Until all sectors are read:
read sector in page-3 buffer
(several buffers reserved/available for this purpose)
call system help-routine, to copy each sector to its actual
destination
This help-routine used here (called XFER or something like that), is
setup during the boot-process, and works like a LDIR, but with
slot-switching in between, like:
switch DOS RAMslot (F342h) in page 1
LDIR (=copy sector from page-3 buffer to page-1 destination)
switch diskROM-slot back into page 1
Doing this for every single sector one by one, works kind of slow.
Most later diskROMs will therefore use something like:
Switch diskROM-slot in page 2
(=no diskROM, but diskcontroller-registers in there)
copy essential parts of disk-I/O routine to page-3 buffer
call this to read those sectors, that were going to page 1
switch back original slot (or DOS RAM-slot) in page 2
continue reading, if still more sectors
(on page 1/2 boundary, or in page 2 and further)
These copied sector-I/O routines might work like:
read sector
sectors left? If no, done
next sector on page 1/2 boundary, or in page 2?
still in page 1 -> read next sector
further -> pass control back to diskROM
All these page-boundary checks, and use of help-routines,
slot-switching etc. makes live easy for programmers, but can make
drivers highly complex.
In order to simplify this, for DOS2 this was changed. In essence, a
DOS2-only driver can do sector-I/O always to page 2 or 3 directly
(and only), and need not be able to transfer sectors to page 1 (or
0).
DOS2 does this essentially as follows:
For every disk-I/O call transferring data to memory below 8000h:
check what memory mapper block is used in that page
switch that mapper block in page 2
call the driver (diskROM), with the transfer address adjusted
to point to page 2
switch the original mapper block back in page 2
This can greatly simplify drivers, if they don't need to stay
compatible with DOS1 (like with HD interfaces; usually no need for
DOS1-compatibility, because a harddisk will most likely not be
usefull if no subdirectories could be used).
For application programs, this is mostly transparant as well, as it
was for DOS1. But it does introduce 2 conditions:
-You must have a memory mapper for this trick to work
-This (and only this) memory mapper must be used for all disk-I/O,
and selected as the DOS RAMslot for all 4 pages (F341-F344h).
It could in principle work with multiple memory mappers, but in this
case, you would have to find out the (mapper) slot switched in page
0/1 first, switch this slot in page 2, then set the right mapper
block in there, call the driver, and restore both mapper block & slot
settings.
Apparantly, this was too much work for the makers of DOS2, so the
slotswitching was dropped, and only mapper-block switches are needed
(apart from slot-switching involved in calling the driver).
Because of this, you will see that under DOS2, memory locations
F341-F344h always contain the same slot, this will always be a mapper
RAM slot, and all disk-I/O will go to this slot, even if other slots
are selected when a disk-I/O call is made (try it, and you will see
that this is true).
This is the reason for many programmer's headaches, when trying to
write software that does disk-I/O using multiple RAM/mapper slots,
and under DOS2 (like for sampling programs, using MemMan to use 2 or
more memory mappers). No problem doing disk-I/O to the 'primary'
(DOS-) mapper, no problem accessing the other mappers, but disk-I/O
to these other mappers under DOS2 simply doesn't work right, the data
always lands in the primairy mapper.
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/)
****
