|Re: [hatari-devel] Problem with changes in drive ID handling|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Problem with changes in drive ID handling
- From: Uwe Seimet <Uwe.Seimet@xxxxxxxxx>
- Date: Fri, 10 Oct 2014 08:39:39 +0200
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1412923180; l=3514; s=domk; d=seimet.de; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Subject:To:From:Date; bh=XBEESfCVBB95jK2J8ObEvNE5tS4=; b=tA+G2mDGn79EO3tWV3WtkaJGSz0I8QU+JI2PbodmKJ3EcVsnzrM77/r6Kiwbqw4ikuA Ag5R/kDqUrqdlLNxokEwaxdkUOSbP0fRsFVUNEMoNcgcQcz9clWMQIz88qNVliXv6dQ8l WX5IGSdDwqMpWZaGCtqdsYIUN1mcFYkIJsw=
> Is there any documentation on the primary partition table
> with 8 partitions?
I don't know, the CBHD archive might include something. The four
additional partitions start at offset $186. But they are only valid if a
hard disk driver is used (booted or started later from a GEMDOS drive)
that supports this kind of extended partitioning.
But that's just one of the problems I see with your approach: The actual
ID assignment depends on the hard disk driver being used, and when the
hard disk driver is booted (or started from a GEMDOS drive) Hatari has
already been initialized.
> Last HDDRIVER version I tested (I think it was demo version),
> didn't have skipping enabled by default.
Yes, this is not enabled by default. Just enable "Preserve Existing
Partitions". Why don't you use the full version? In case you forgot your
serial number, which you need for the download, just tell me.
> > > However, I noticed that at older TOS versions don't handle "holes"
> > > in drive bitmap very well...
> > Can you please elaborate? I don't remember any TOS versions that had
> > problems with this.
> I'm not completely sure which version of TOS had this issue.
> Maybe v1.04?
Actually, I'm quite sure that this has never been any issue. Where did
you get this information from? It's probably as wrong as fairy tales
like the boot partition must be less than 32 MB, or that drives > 1 GB
are not supported etc. Unfortunately as time goes by more and more
users, in particular those who are using a hard disk (or memory card
adapter) for the first time do not realize that its their fault that
something does not appear to be working. They assume that something is wrong
with TOS, or that there is some kind of limitation that does not really
exist. And yes, there definitely are users that nowadays connect a hard
disk drive to their Atari the first time.
By the way, with METADOS it's normal that not all drvbits are used. In such
case usually IDs Q-Y are usually unused, but Z: is used for the CD-ROM drive.
> I guess the new config option needs to default to assigning
> GEMDOS HD to C:...
I think this should indeed be the default, because there is much less
potential for problems than when not making it the default.
But in any case, if there is such an option I'd recommend that the
Hatari documentation goes into detail about the consequences this option
> > By the way, before your change I noticed that when changing settings in
> > HDDRUTIL, HDDRUTIL now reports that the write operation failed. This
> > worked fine with Hatari 1.8.0 and earlier.
> Does this happen both with ACSI & IDE or just one of them?
This happens when writing the settings to a GEMDOS drive. Just start
HDDRUTIL from a GEMDOS drive and, for instance, open the "Devices and
Partitions" dialog. Then just click OK. HDDRUTIL now tries to
re-configure the HDDRIVER binary, and this operation fails. With Hatari
1.8.0 and earlier it works fine.
In my development setup all relevant files are on GEMDOS drives. Hard disk
images I just use for testing partitioning etc., but
> Are you sure this was because of my change and not some other change?
> I don't think I changed anything that would affect the actual disk
I guess it has to do with GEMDOS-related changes since Hatari 1.8.0.
When I use 1.8.0 with my setup it works fine, but with exactly the same
setup the development version fails.