@Badwolf , I'm not convinced this is a great idea but here goes :)
There is a build available, for you and anyone else on this forum, that allows you to use direct device access.
http://www.happydaze.se/wp-content/uplo ... 20329.zip
To enable:
"diskdevmode x"
where x can be:
0 = disabled
1 = enable XHDI
2 = enable AHDI
3 = enable XHDI or AHDI (XHDI has priority)
HDDriver and EmuTOS's built-in drivers support both XHDI and AHDI3.0. I haven't had a chance to try out other drivers yet.
XHDI is generally the better choice if the driver supports it and it's able to do at least some basic sanity checks on the settings.
Normally you'd want this setting to be 3 unless wanting a specific mode for testing or debugging purposes.
Speedometer scores seem to hover around x1 for stuff on the 8Mhz bus which makes sense.
In practice it seems to perform better on MacOS's scattered and cache-unfriendly blocks reads so at least to me it feels snappier and faster compared to disk images in MiNT (which actually scores higher in Speedometer due to caching)
Super important:
Your device must have a physical block size of 512 bytes.
I'm assuming they all do, but I recommend you to double check with a tool of your choice. You can verify physical block size with HDDrivers utils:
blocksize.png
Also important:
Maybe test in Hatari first.
Backup or disconnect stuff that contains data that you really don't want to risk being destroyed
Even stuff on devices you are not going to use for BasiliskII.
A bad setting, or bugs, could easily make it trash your real partitions...
Known issue:
The disk becomes unbootable if MacOS is not shut down correctly.
It's fully intact but it seems to loose its blessed status for reasons I am still not sure about.
I don't know if this is specific to my particular setup or if it would happen to everyone, and I haven't been able to reproduce it in Hatari.
Would love to hear if others get the same result on unclean shutdowns.
If it happens, you're going to need to boot from another disk so that you can re-bless it and make it bootable again.
Here's a link to a super tiny System7.5 boot floppy which has the "Startup Disk" control panel.
I usually have this mounted as the second disk so if the real boot disk becomes unblessed it starts into this one instead.
http://www.happydaze.se/wp-content/uplo ... .img_.zip
And with all that out of the way..
There are two ways to create disks, both ends up being the same thing internally but one is a bit higher level in terms of configuration and restricted inside partitions, while the other one simply don't care and allows you to do whatever you want :)
---- raw ----
disk raw:<drive letter>:<start>:<size>
start and size are optional, so at the simplest form it could look just like this:
"disk raw:d"
drive letter = the drive letter for the RAW partition
start = offset in the partition. 0 means Mac disk starts at beginning of the partition.
size = the number of blocks that MacOS will use as a harddrive
You are going to need a driver that recognise and assigns drive letters to RAW partitions.
And some way to create them of course :)
HDDriver is able to create RAW partitions, or even change an existing partition into a RAW one if you want.
If you are using AHDI mode, and it's the last partition on the disk, then you must supply those otherwise optional parameters.
This example partition has 498046 blocks, so you would need to use:
"disk raw:d:0:498046"
rawdisk.png
Those optional parameters are quite useful if you want to make multiple Mac disks inside a single RAW partition.
For example, split in two like this:
"disk raw:d:0:249023"
"disk raw:d:249023:249023"
---- dev ----
dev:<majorID>.<minorID>:<start>:<size>
It'll use <size> number of block, starting at block <start> on the specified device.
It does not care about partitions. It will use that physical block range regardless of how the disk was partitioned. Or not partitioned, that works too, it won't care. So yeah... be careful.
Taking the example screenshot of that raw partition above, the following three settings would do exactly the same thing:
"disk raw:d"
"disk raw:d:0:498046"
"disk dev:16.0:498048:498046"
One case where this is useful is if you want to use unpartitioned "wasted" space on a device, without having to re-partition.
Or if you simply don't want to clutter TOS with unusable RAW partition drive letters..
For example like this, two TOS partitions for Atari stuff followed by 434MB of unpartitioned space where we could "hide" MacOS disks.
The last real partition appears to ends at block (498048 + 498046 - 1) so if I wanted to make a 400MB MacOS disk in the unused space I could do something like this:
"disk dev:16.0:996093:819200
devdisk.png
So, how do I know the device ID?
You can check in HDDriver. If you have partitions on the device then you can check under Drive Details for either of those.
It will say the Major and Minor IDs of the device.
The numbers displayed in the main Device window are shown in a different format.
I don't know if this is by choice or if it's a bug? It's easy enough to figure it out from there as well though:
majorID is 0 for ACSI, 8 for SCSI, 16 for IDE
minorID is the device number on that particular bus.
If HDDRiver says "SCSI 7.0" then that means MajorID=8 (because it's SCSI) and MinorID=7
"IDE 0.0" becomes MajorID=16, MinorID=0
"ACSI 1.0" becomes MajorID=0, MinorID=1
Have fun, please don't wreck your harddrives... :)
Don't forget to backup your existing Atari drives before trying etc etc.
You do not have the required permissions to view the files attached to this post.
