"the expression, 'atonal music,' is most unfortunate--it is on a par with calling flying 'the art of not falling,' or swimming 'the art of not drowning.'. A. Schoenberg
only weird m68k MorphOS binaries which can't work on AmigaOS (not only OS4, they can't work on AmigaOS 2.x and 3.x either - except for HDs smaller than 4 GB, or on larger HDs if the partition you want to access is completely inside the 1st 4 GB of the HD).
That's not true. These m68k binaries are standard AmigaOS binaries. These simply use TD64 system to access >4GB, instead of NSD64. Phase5, individual computers and other manofacturers choosed the TD64 standard.
It works perfectly. Just because OS4 does not support TD64 it doesn't mean that NTFS filesystem doesn't work on AmigaOS3.x.
Quote:
NTFS isn't supported by CrossDOSFileSystem, and AFAIK there is no NTFS implementation at all for AmigaOS, if the partitions are NTFS you could try to read them with Linux.
You are wrong, current ext2/NTFS filesystems work without problems on real amigas with their standard hardware (including the standard IDE port) and also with 3rd party hardware manofactured by individual computers or phase5. Software like Idefix also uses TD64 system to access >4GB with standard ide port or idefix express, buddha, catweasel, etc...
Would it be difficult to add TD64 support to OS4 so we could have access to other filesystems? It's not a matter of which system is better or worse, it's a problem of accessing more filesystems. AFAIK there's no one working on a NTFS or ext2 filesystem for OS4
I revived my A4000T last sunday with OS3.9, I hope I can reinstall OS4 soon to finish some projects that have been frozen since my equipment started to fail.
What is strange OTOH is that people (Haymiga) told us that he made it work via usb whereas he's unable to do it via ide !?! Would be interesting to know why... Is USB device implementation TD64 compatible ?
Would it be difficult to add TD64 support to OS4 so we could have access to other filesystems? It's not a matter of which system is better or worse
You can easily wrap the TD64 functions to native NSD64, by setting up a fake device, you can easily do that on a one to one bases.
For example having a device called a1ide_td64.device that forwards the SCSI command to a1ide.device.
Having tow different standards to deal whit for block device developer is going to make thing complicated, and more testing might be need for every device added to the system, so it make no sense to add TD64 code there, but to change the filesystem to support the OS provided the code comes from a Linux GPL source, it should be obtainable, if not we can always port it over again if we really need it?
Quote:
it's a problem of accessing more filesystems. AFAIK there's no one working on a NTFS or ext2 filesystem for OS4
For most it not problem not having access to this file-systems, but I guess there some cases where you have removable devices that are formatted whit NTFS or some other kind of file system.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
I very much doubt that. If a partition is less than 4GB and all of it is in the lower 4GB of the disk then most filesystems will use the normal CMD_READ/CMD_WRITE instead of the TD64/NSD64 commands as they are not necessary and also slower. Probably this is what happened in this case.
You can easily wrap the TD64 functions to native NSD64, by setting up a fake device, you can easily do that on a one to one bases.
Couldn't it be generic ? Let's say we have this generic handler named TD64CompatibilityHandler then you instanciate this handler by giving it : - the device to make compatible ex a1ide.device, - the fake compatible device ex: a1ideTD64.device,
Then this generic handler will add to the system the new device (here a1ideTD64.device) and will redirect (after some wrapping) to a1ide.device. Just an idea...
TD64 is an unofficial extension that adds 64-bit support to the trackdisk-like device commandset. It is not the only one. NSD (New Style Devices), which was introduced in OS3.5/3.9, has its own 64-bit extension and this is the one that is used/supported by OS4.
Having tow different standards to deal whit for block device developer is going to make thing complicated, and more testing might be need for every device added to the system, so it make no sense to add TD64 code there, but to change the filesystem to support the OS provided the code comes from a Linux GPL source, it should be obtainable, if not we can always port it over again if we really need it?
AFAIK Marek code does not come from any Linux GPL source and it's designed from scratch to suit AmigaOS. He's a MorphOS user and I guess that he supported TD64 instead of NSD because he owns a Pegasos and it's easier for him to test (MOS also uses TD64). I don't know if he still has access to any classic amiga running OS3.9 to test NSD code. I don't want to go offtopic but maybe if an OS4 crosscompiler for MOS was available more software could be ported.
Maybe a small bounty could be set up to make native OS4 versions of his filesystems(now we have another good idea for amigans.net... bounties!).
I don't want to go offtopic but maybe if an OS4 crosscompiler for MOS was available more software could be ported.
So it can be ported ... VBCC allows right now to compile from any supported platform to any other supported platform... (and MOS as OS4 are supported platforms)
You can easily wrap the TD64 functions to native NSD64, by setting up a fake device, you can easily do that on a one to one bases.
Couldn't it be generic ? Let's say we have this generic handler named TD64CompatibilityHandler then you instanciate this handler by giving it : - the device to make compatible ex a1ide.device, - the fake compatible device ex: a1ideTD64.device,
Then this generic handler will add to the system the new device (here a1ideTD64.device) and will redirect (after some wrapping) to a1ide.device. Just an idea...
I do not really know any thing about handlers, all I know is the device side of it.
I think it?s possible to have program that generates fake devices.
TD64 is quite simple; io_Actual is used to store the high 32 bit value io_HighOffset.
I've made a simple program "td64patch" that patches the BeginIO method in a .device with a routine that maps the TD64 commands (read, write, seek & format) to their NSD equivalents. If anyone wants to try they can download it from my website: http://a500.org/index.php?s=downloads&f=td64patch.lha
I make no guarantees as to whether it will work or not. At least it didn't crash for me but I haven't had time to test with any TD64 filesystems yet either...
Assuming the commands are compatible it should work though...
Command line syntax is: Run <>NIL: td64patch devicename [unit]
devicename = a1ide.device or other device [unit] = optional, any unit number that can be opened (default = 0)
F.e. Run <>NIL: td64patch a1ide.device
To disable patch send a break signal to the td64patch command (C:Status can be used to obtain the process number to use with C:Break).
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
