Hello all,
I've got Unz (FM Towns emulator) running under wine but its not capable of reading the original FM Towns CDROM images on my Mac.
I have it working under Windows XP using Daemon Tools to mount the ISO but under OSX it does not work. I have the ISO mounted under finder and have pointed my wine configuration to the mount point. No luck.
Has anyone successfully got this running under Wine?
UNZ FM TOWNS Emulator not reading discs
-
SpawnHappyJake
- Level 5
- Posts: 272
- Joined: Sun Feb 06, 2011 5:57 am
Robbo007, you have summoned me! Hardware emulation, particularly optical drive emulation, is far too commonly misunderstood.
I don't hold anything against you personally, but it's one of my pet peeves that all across the Internet, people think that simply mounting an ISO = hardware emulation.
If you're in Mac OS X or Linux, and you "mount" an iso, all you are doing is having the files in that image displayed in a folder somewhere. You don't magically make hardware appear. The "sudo mount -o loop [path to iso] [path to folder you want to mount it in]" command that you can do from terminal in either Linux or Mac OS X also simply displays the files in the ISO file in the folder you specify.
I also want to point out that PowerISO _does_not_ emulate an optical drive and AcetoneISO _does_not_ emulate an optical drive. They just make the files of an ISO show up in a directory.
WINE sees that the path you associated with a drive letter is not where a CD is mounted. And no, specifying that it is a CD won't magically give it a hardware name, obey the SCSI command set, have a firmware revision, look like it is plugged into a controller, and everything else that real optical drives do.
It needs to look like a CD drive, i.e., hardware.
The heart of the operating system, the kernel, is what sees hardware. All programs ran by the kernel, including WINE, only know about hardware because the kernel tells them about it. All hardware info is passed onto a program by the kernel.
The kernel can lie and say that there is hardware present that is not. This is one method of emulating hardware. To do so in an ideal fashion, you'd write a whole kernel (operating system) specifically for the purpose of hardware emulation where the kernel itself can do hardware emulation (lying).
But that isn't really an option for most people. Fortunately, the Mac OS X and Linux kernels are modular, meaning they have a way of extending kernel functionality by loading some kind of kernel module. Once a kernel module is loaded, it is pretty much a part of that kernel.
CDEmu is a CD emulator for Linux and has a kernel module that inserts into the Linux kernel, giving the Linux kernel the functionality of lying about extra optical drives being present.
Kernel modules for Linux are called "kernel modules". Kernel modules for Mac OS X are called "kernel extensions" abbreviated as "kexts".
Windows can run a driver in kernel mode. Daemon Tools and Virtual CloneDrive install such a driver into Windows that lies (from the kernel level) and says there is extra hardware present.
You cannot install a driver into WINE, so Daemon Tools and Virtual CloneDrive or any other Windows kernel-level hardware emulator _will_not_ work in WINE.
Unfortunately, after hours of Googleing, there is yet to be an open source or even free (as in "free beer") optical drive emulator for Mac OS X. There are some for sale, but no freebies. I know that they must work by inserting a kext.
It is possible for someone to make an open source optical drive emulator for Mac OS X via use of a kext, but no one has taken up the task yet.
So your only practical and free option is to dual boot your Mac with Linux (preferably Ubuntu or a variant thereof) and install CDemu and WINE.
Do not attempt to compile CDEmu from source. It's actually impossible. The compiled binaries just appeared on someone's hard drive one day, and that person uploaded them.
Just mount the optical image with CDEmu, find where it is mounted to, go to the drives tab in winecfg, and associate a drive letter with where the emulated optical drive is mounted. WINE sees that the path you associated with a drive letter is indeed where a CD is mounted.
I actually wrote a big thing about this to have on stand-by: http://dl.dropbox.com/u/20170669/Hardwa ... difier.rtf. If you want the full scoop, go there.
Cheers,
Jake
I don't hold anything against you personally, but it's one of my pet peeves that all across the Internet, people think that simply mounting an ISO = hardware emulation.
If you're in Mac OS X or Linux, and you "mount" an iso, all you are doing is having the files in that image displayed in a folder somewhere. You don't magically make hardware appear. The "sudo mount -o loop [path to iso] [path to folder you want to mount it in]" command that you can do from terminal in either Linux or Mac OS X also simply displays the files in the ISO file in the folder you specify.
I also want to point out that PowerISO _does_not_ emulate an optical drive and AcetoneISO _does_not_ emulate an optical drive. They just make the files of an ISO show up in a directory.
WINE sees that the path you associated with a drive letter is not where a CD is mounted. And no, specifying that it is a CD won't magically give it a hardware name, obey the SCSI command set, have a firmware revision, look like it is plugged into a controller, and everything else that real optical drives do.
It needs to look like a CD drive, i.e., hardware.
The heart of the operating system, the kernel, is what sees hardware. All programs ran by the kernel, including WINE, only know about hardware because the kernel tells them about it. All hardware info is passed onto a program by the kernel.
The kernel can lie and say that there is hardware present that is not. This is one method of emulating hardware. To do so in an ideal fashion, you'd write a whole kernel (operating system) specifically for the purpose of hardware emulation where the kernel itself can do hardware emulation (lying).
But that isn't really an option for most people. Fortunately, the Mac OS X and Linux kernels are modular, meaning they have a way of extending kernel functionality by loading some kind of kernel module. Once a kernel module is loaded, it is pretty much a part of that kernel.
CDEmu is a CD emulator for Linux and has a kernel module that inserts into the Linux kernel, giving the Linux kernel the functionality of lying about extra optical drives being present.
Kernel modules for Linux are called "kernel modules". Kernel modules for Mac OS X are called "kernel extensions" abbreviated as "kexts".
Windows can run a driver in kernel mode. Daemon Tools and Virtual CloneDrive install such a driver into Windows that lies (from the kernel level) and says there is extra hardware present.
You cannot install a driver into WINE, so Daemon Tools and Virtual CloneDrive or any other Windows kernel-level hardware emulator _will_not_ work in WINE.
Unfortunately, after hours of Googleing, there is yet to be an open source or even free (as in "free beer") optical drive emulator for Mac OS X. There are some for sale, but no freebies. I know that they must work by inserting a kext.
It is possible for someone to make an open source optical drive emulator for Mac OS X via use of a kext, but no one has taken up the task yet.
So your only practical and free option is to dual boot your Mac with Linux (preferably Ubuntu or a variant thereof) and install CDemu and WINE.
Do not attempt to compile CDEmu from source. It's actually impossible. The compiled binaries just appeared on someone's hard drive one day, and that person uploaded them.
Just mount the optical image with CDEmu, find where it is mounted to, go to the drives tab in winecfg, and associate a drive letter with where the emulated optical drive is mounted. WINE sees that the path you associated with a drive letter is indeed where a CD is mounted.
I actually wrote a big thing about this to have on stand-by: http://dl.dropbox.com/u/20170669/Hardwa ... difier.rtf. If you want the full scoop, go there.
Cheers,
Jake
-
SpawnHappyJake
- Level 5
- Posts: 272
- Joined: Sun Feb 06, 2011 5:57 am
That's another misconception I've found out there! Glad you pointed it out. I confront it in my shpeel. People think that they need some fancy CD emulator to get past copy protection because "plain CD emulation" wasn't enough, when in fact, the problem is that they weren't even emulating an optical drive to begin with!I thought the problem was more along the line of copy protection but what your saying makes sense.
However, if a rootkit is installed, something running near the kernel level in this case, and I'm talking about Windows, the rootkit can bypass the hardware reported by the kernel-level driver and get hardware info right from the kernel and see that the cd drive is fake and communicate to the game saying that the cd is a fake. SecuROM is such a rootkit. Obviously if the kernel itself was doing the emulation, and not a kernel-level driver or a kernel module or a kext, we wouldn't have this problem.
So Virtual CloneDrive and Daemon Tools actually install _their_own_ rootkit to combat SecuROM. That IS an example of a "special" CD emulator getting past "copy protection", but I want to stress the point that if you are simply showing the files in an iso in a folder without emulating an optical drive, your issue is not that you aren't "getting past copy protection" but that you aren't even emulating an optical drive. Besides, it might simply look for CD hardware __without__ a rootkit, in which case you not emulating an optical drive _at_all_ is the problem _not_that_you__aren't_"getting_past_copy_protection".
Cheers,
Jake
Very true.. I'm not sure what exactly FMTOWNS UNZ is looking for. The only options you have are to specify ASPI CDROM, which then gives you a pulldown menu of the detected drives or select a drive letter where your CDROM or image is mounted.
Don't think these games had very advanced copy protection as the hardware is from the early 1990's. I guess it would have been more manual or code wheel copy protection.
Guess there is no way to use the ASPI option either right?
Rob
Don't think these games had very advanced copy protection as the hardware is from the early 1990's. I guess it would have been more manual or code wheel copy protection.
Guess there is no way to use the ASPI option either right?
Rob
-
SpawnHappyJake
- Level 5
- Posts: 272
- Joined: Sun Feb 06, 2011 5:57 am
ASPI stands for Advanced Scsi Programming Interface. In other words, it is a method (instilled in a driver) to use the SCSI command set to communicate with hardware. Simply displaying the files in an ISO to a folder gives you no way to talk to this mounted thing via the SCSI command set. You can talk to an emulated optical drive with the SCSI command set.
I found this site: http://snesorama.us/board/showthread.php?p=471397. Do you seriously need a floppy to save you game saves? Why can't you just tell it to store save files to some directory? Does the emulated system expect a floppy drive, and the emulator doesn't emulate that for you?
This emulator seriously needs to do more emulation. You should be able to supply it with a CD image and it emulate a CD drive for you (inside the emulator) and it should be able to emulate a floppy drive and save floppy images on your computer that it can use.
If you're stuck with having to use a physical floppy drive, and you're going over to Windows, let me liberate you. There's a free floppy drive emulator called Virtual Floppy. It worked great for me in WinXP 32-bit, but haven't figured out how to get it to work in Windows 7 64-bit.
Unfortunately, I don't know of any floppy drive emulators for Linux or Mac OS. I'm rather disappointed that there's not a vast array of hardware emulators for Linux. You'd think there'd by hard drive emulators, CD drive emulators, floppy emulators, etc. Nope.
However, you can make a virtual machine via VirtualBox (yes, even in Mac OS X!), which is free, put Linux in that, and use VirtualBox to get sub-kernel-level emulation of both floppy drives and optical drives. You could put WINE and the emulator into Linux and see if that works.
I'd recommend a slimmed down version of Ubuntu or something like that without any Compiz or special graphics drivers. All you are using it for is to run WINE to run the emulator. Maybe Lubuntu (Lightweight Ubuntu) or Crunchbang. It needs to be light because the load will be high because you will be running both Mac OS X and Linux at the same time on your hardware.
I found this site: http://snesorama.us/board/showthread.php?p=471397. Do you seriously need a floppy to save you game saves? Why can't you just tell it to store save files to some directory? Does the emulated system expect a floppy drive, and the emulator doesn't emulate that for you?
This emulator seriously needs to do more emulation. You should be able to supply it with a CD image and it emulate a CD drive for you (inside the emulator) and it should be able to emulate a floppy drive and save floppy images on your computer that it can use.
If you're stuck with having to use a physical floppy drive, and you're going over to Windows, let me liberate you. There's a free floppy drive emulator called Virtual Floppy. It worked great for me in WinXP 32-bit, but haven't figured out how to get it to work in Windows 7 64-bit.
Unfortunately, I don't know of any floppy drive emulators for Linux or Mac OS. I'm rather disappointed that there's not a vast array of hardware emulators for Linux. You'd think there'd by hard drive emulators, CD drive emulators, floppy emulators, etc. Nope.
However, you can make a virtual machine via VirtualBox (yes, even in Mac OS X!), which is free, put Linux in that, and use VirtualBox to get sub-kernel-level emulation of both floppy drives and optical drives. You could put WINE and the emulator into Linux and see if that works.
I'd recommend a slimmed down version of Ubuntu or something like that without any Compiz or special graphics drivers. All you are using it for is to run WINE to run the emulator. Maybe Lubuntu (Lightweight Ubuntu) or Crunchbang. It needs to be light because the load will be high because you will be running both Mac OS X and Linux at the same time on your hardware.
-
SpawnHappyJake
- Level 5
- Posts: 272
- Joined: Sun Feb 06, 2011 5:57 am
Thanks for the reply. Basically UNZ needs to read the "FM Towns" CD via a CDROM. The floppy emulation works fine as its normally the character or save game disk that needs to be inserted. The program is cleaver and has built in a way to create an old 720kb floppy disk and mount it so that the games can use it. Just like the original FM Towns computer did with a real floppy drive.
Did you manage to download UNZ and try it to see what I'm talking about? Maybe you will see something that I've missed? You never know. I think what you've said before is probably the problem. OSX is lacking a CDROM emulator for wine. Let me know.
Cheers,
Rob
Did you manage to download UNZ and try it to see what I'm talking about? Maybe you will see something that I've missed? You never know. I think what you've said before is probably the problem. OSX is lacking a CDROM emulator for wine. Let me know.
Cheers,
Rob
-
SpawnHappyJake
- Level 5
- Posts: 272
- Joined: Sun Feb 06, 2011 5:57 am
Glad to hear you don't need a physical floppy drive.
Remember, it's not that you need a CD-ROM emulator for WINE. You need a CD-ROM emulator. An illusionary optical drive generated by the kernel will be seen by all programs the kernel runs. WINE is just one of many programs that will see it.
And there's no way to install a CD-ROM emulator into just WINE. Windows hardware emulators work by a kernel-level driver conjuring up the illusionary hardware from the kernel level. You can't install drivers into WINE.
However, you can install Linux into VirtualBox and have VirtualBox emulate an optical drive with a provided CD image. Also, you can duel boot your Mac with Linux and install CDemu and WINE (the better option).
Cheers,
Jake
Remember, it's not that you need a CD-ROM emulator for WINE. You need a CD-ROM emulator. An illusionary optical drive generated by the kernel will be seen by all programs the kernel runs. WINE is just one of many programs that will see it.
And there's no way to install a CD-ROM emulator into just WINE. Windows hardware emulators work by a kernel-level driver conjuring up the illusionary hardware from the kernel level. You can't install drivers into WINE.
However, you can install Linux into VirtualBox and have VirtualBox emulate an optical drive with a provided CD image. Also, you can duel boot your Mac with Linux and install CDemu and WINE (the better option).
Cheers,
Jake
SpawnHappyJake PowerISO Virtual Drive under windows does answer some drive hardware requests. Does not under Linux or OS X at all.
"I also want to point out that PowerISO _does_not_ emulate an optical drive and AcetoneISO _does_not_ emulate an optical drive. They just make the files of an ISO show up in a directory."
Partly correct. It is what gets people into trouble. It worked under PowerISO for Windows but it don't work under PowerISO for Linux and OS X. Yep the difference one does a bit of drive emulation the other two does not.
SpawnHappyJake. Under Linux we have very little need for full drive emulators. Also wine does not have the means to talk directly to an hard drive in the first place. So network block device with qemu is more than suitable for hard drive emulation. In fact in most cases is over kill. Yes qemu on a ndb emulates all harddrive instructions.
I also remembered something. http://illusioncity.net/Towns/ Yes the main project site died this is a backup site. This is based off boch a cross platform emulator open source.
Really if people want to keep on using fm towns it would pay to get a group of developers/people and update the fm-boch project with the new boch code http://bochs.sourceforge.net. It has the cdrom emulator, harddrive and floppy emulator built in.
Basically why run a emulator in wine when with a little work you can run the emulator native. So removing one level of problem.
Yes most of Linux hardware emulators are inside virtual machines or linked to virtual machines somewhere. Since that is where we need hardware emulators.
"I also want to point out that PowerISO _does_not_ emulate an optical drive and AcetoneISO _does_not_ emulate an optical drive. They just make the files of an ISO show up in a directory."
Partly correct. It is what gets people into trouble. It worked under PowerISO for Windows but it don't work under PowerISO for Linux and OS X. Yep the difference one does a bit of drive emulation the other two does not.
SpawnHappyJake. Under Linux we have very little need for full drive emulators. Also wine does not have the means to talk directly to an hard drive in the first place. So network block device with qemu is more than suitable for hard drive emulation. In fact in most cases is over kill. Yes qemu on a ndb emulates all harddrive instructions.
I also remembered something. http://illusioncity.net/Towns/ Yes the main project site died this is a backup site. This is based off boch a cross platform emulator open source.
Really if people want to keep on using fm towns it would pay to get a group of developers/people and update the fm-boch project with the new boch code http://bochs.sourceforge.net. It has the cdrom emulator, harddrive and floppy emulator built in.
Basically why run a emulator in wine when with a little work you can run the emulator native. So removing one level of problem.
Yes most of Linux hardware emulators are inside virtual machines or linked to virtual machines somewhere. Since that is where we need hardware emulators.
http://illusioncity.net/fujitsu-fm-town ... ors-lists/
I forgot about http://www.xe-emulator.com/ for Linux. Fairly much nukes the need for UNZ under Linux. But its closed source and not in a large storage system that does not make me particularly happy about what the future might hold.
I forgot about http://www.xe-emulator.com/ for Linux. Fairly much nukes the need for UNZ under Linux. But its closed source and not in a large storage system that does not make me particularly happy about what the future might hold.
-
SpawnHappyJake
- Level 5
- Posts: 272
- Joined: Sun Feb 06, 2011 5:57 am
That's interesting that PowerISO answers some hardware requests.
However, it still doesn't emulate hardware. What I mean by this is that if you open Device Manager, WMIC, or anything that shows a list of hardware, PowerISO's drive does not show up, so hardware isn't emulated, even if some hardware requests are satisfied.
That CDEmu can't be compiled from source was a joke backed up by some truth. If you want to know what I mean, make a virtual machine, install Linux in the virtual machine, and try to install CDEmu from source in the virtual machine. I tried on my real machine and it wouldn't boot into Linux the next boot. You have to compile dependencies for dependencies. I think you might even have to compile dependencies for dependencies for dependencies. It's a branching effect, not a simple chain, because each dependency that has to be compiled has more than one dependency (at least some do)
How the ppa for CDemu for Ubuntu was made, I don't know. I almost wonder if they had to edit the source code. It _seems_ as if it just magically appeared on someone's hard drive one day.
My other joke is that CDEmu is not compiled from source, it's compiled from sourcery.
Cheers,
Jake
However, it still doesn't emulate hardware. What I mean by this is that if you open Device Manager, WMIC, or anything that shows a list of hardware, PowerISO's drive does not show up, so hardware isn't emulated, even if some hardware requests are satisfied.
That CDEmu can't be compiled from source was a joke backed up by some truth. If you want to know what I mean, make a virtual machine, install Linux in the virtual machine, and try to install CDEmu from source in the virtual machine. I tried on my real machine and it wouldn't boot into Linux the next boot. You have to compile dependencies for dependencies. I think you might even have to compile dependencies for dependencies for dependencies. It's a branching effect, not a simple chain, because each dependency that has to be compiled has more than one dependency (at least some do)
How the ppa for CDemu for Ubuntu was made, I don't know. I almost wonder if they had to edit the source code. It _seems_ as if it just magically appeared on someone's hard drive one day.
My other joke is that CDEmu is not compiled from source, it's compiled from sourcery.
Cheers,
Jake
-
parazythum
- Newbie
- Posts: 2
- Joined: Sat Sep 14, 2013 10:46 pm
Re: UNZ FM TOWNS Emulator not reading discs
I'm using Ubuntu 12.04 LTS right now.
Installing CDemu was a pain in the a$$, since 12.04 is not listed any more in the CDemu PPA. So I had to compile it myself.
You have to install all the packages in the right order, because the dependencies are numerous : first the VHBA module, then libmirage, cdemu-daemon, cdemu-client, and finally gcdemu.
Finally, the cdemu-daemon would not work
Investigating more, I could understand this :
- the VHBA module must be loaded at ubuntu startup
- the cdemu-daemon must be run by the current user
- unfortunately the vhba_ctl device created in /dev doesn't have the permissions set to allow the cdemu-daemon to access it, so you must set before a udev rule to create the device with the cdrom group (your user must be in that group of course)
This is how I got it to run :
**** Loading the VHBA module at startup :
Edit /etc/modules, add "vhba" at the end, save.
Create/edit /etc/udev/rules.d/99-cdemu.rules with this line :
KERNEL=="vhba_ctl", NAME="%k", MODE="0660", OWNER="root", GROUP="cdrom"
**** Load the gCDemu applet in gnome :
Launch gnome-session-properties
Add a launcher called "cdemu", use "gcdemu --indicator" as the command line
Reboot. It should work now
After a kernel update, if gCDemu doesn't work anymore (cdemu-daemon error), you may have to compile again VHBA for the current kernel version.
UNZ works nice now with wine, with full CD-ROM access
Installing CDemu was a pain in the a$$, since 12.04 is not listed any more in the CDemu PPA. So I had to compile it myself.
You have to install all the packages in the right order, because the dependencies are numerous : first the VHBA module, then libmirage, cdemu-daemon, cdemu-client, and finally gcdemu.
Finally, the cdemu-daemon would not work
Investigating more, I could understand this :
- the VHBA module must be loaded at ubuntu startup
- the cdemu-daemon must be run by the current user
- unfortunately the vhba_ctl device created in /dev doesn't have the permissions set to allow the cdemu-daemon to access it, so you must set before a udev rule to create the device with the cdrom group (your user must be in that group of course)
This is how I got it to run :
**** Loading the VHBA module at startup :
Edit /etc/modules, add "vhba" at the end, save.
Create/edit /etc/udev/rules.d/99-cdemu.rules with this line :
KERNEL=="vhba_ctl", NAME="%k", MODE="0660", OWNER="root", GROUP="cdrom"
**** Load the gCDemu applet in gnome :
Launch gnome-session-properties
Add a launcher called "cdemu", use "gcdemu --indicator" as the command line
Reboot. It should work now
After a kernel update, if gCDemu doesn't work anymore (cdemu-daemon error), you may have to compile again VHBA for the current kernel version.
UNZ works nice now with wine, with full CD-ROM access
-
Bladeforce
- Level 3
- Posts: 63
- Joined: Fri Nov 09, 2012 8:01 am
Re: UNZ FM TOWNS Emulator not reading discs
May i just pop and say you WILL need to remove gcdemu and re-install it after a kernel upgrade. I was pulling my hair out as to why it wouldnt work about a month ago and it was, just as parazythum said, had to compile vhba for the current kernel you are using
-
parazythum
- Newbie
- Posts: 2
- Joined: Sat Sep 14, 2013 10:46 pm
Re: UNZ FM TOWNS Emulator not reading discs
Ah ! CDemu is not stable.
These last days I've tried many ISO / cue-bin / MDF images, and the daemon crashed many times in the middle of a game. I suspect it happens most when audio tracks are played through UNZ...
Quitting and launching again the gnome client will launch again the daemon, but it's annoying.
These last days I've tried many ISO / cue-bin / MDF images, and the daemon crashed many times in the middle of a game. I suspect it happens most when audio tracks are played through UNZ...
Quitting and launching again the gnome client will launch again the daemon, but it's annoying.
