Amithlon/FAQ

Amithlon

“Amithlon is a low-level Amiga emulator for current x86 PCs. It provides very high performance CPU emulation, as well as a translation layer that lets AmigaOS use common PC hardware without the usual drawbacks of emulators. The philosophy behind the development of Amithlon was not to create an Amiga emulator that runs on top of some PC OS, but to turn a current PC into an Amiga. With Amithlon, AmigaOS is in the driver’s seat, and directly controls all the hardware.”

Amithlon is no longer available and all development and support has disappeared.  This blog is for those who enjoy tinkering with out-dated software/hardware and who loved the Amiga operating system above the custom chipset (no support in Amithlon, audio/video based on AHI (sound) and RTG (video)).

————————

FAQ

Unofficial and incomplete Amithlon FAQ

© Bernd Meyer 2001

What is this FAQ?

  • This FAQ is not about using Amithlon, it is about what Amithlonis. In other words, it tells you what you will get if you decide to buy Amithlon; It won’t tell you the answers to any questions you have once you have bought Amithlon. That’s a different FAQ (included below)
  • This is really just an FAQ — a collection of questions I have been asked frequently, or have seen being discussed frequently on the newsgroup or discussion forums. Its main intent is to clarify things before the rumours and speculations get out of hand.
  • Please note that this is not an official Amiga document. Heck, it isn’t even an unofficial Amiga document. It’s just me writing down a few answers. Things are written from my point of view, so you shouldn’t even think about taking these as anyone else’s opinion, or position, or world view, OK?

 

Does this FAQ get updated

  • Sometimes. However, as what Amithlon is doesn’t really change much, neither should this FAQ.

 

Who is “I”? Who is “we”?

  • “I” am Bernd Meyer, often called “Bernie”, living in Australia, and being the author of the JIT compiler for UAE.
  • “We” refers to Harald Frank, of VMC in Germany, and myself. Together, we have been working on the Amithlon project.

 

So what is it? Emulation, or native AmigaOS

  • It is “just” an emulator. It boots up (from a CD, although other boot methods are possible), then starts an m68k emulator task, sets up the hardware for it, loads the rom images into memory, and then pretty much hands control over to the emulated 68k, which just runs like it would in any “real” Amiga.
  • Now, there is a bit more happening. Notice how I talked about rom images, plural? That’s because in addition to the kickstart rom, we are also loading some Amithlon-specific roms that contain special drivers. These drivers tend to not actually do their work in 68k code (because, quite frankly, I suck at writing 68k code:), but instead simply call into the x86 side of things. So in actual use, control is jumping back and forth.

 

Is this the stuff Amigactive talked about in issue 23?

  • No, it isn’t. I know that it sure sounded like it (so much so, in fact, that I called up Amigactive to find out whether someone had sent them a copy of Amithlon), but no, they were talking about someone else’s stuff. Haage and Partner’s, to be precise, and they have now released it under the label “AmigaXL”.

 

Yeah, so what about native x86 AmigaOS

  • Short answer: There isn’t one.
  • Long answer: One of my design choices was to make this thing in such a way that a gradual migration towards an x86 native AmigaOS is possible. The API for switching modes is insanely fast, and as far as programs are concerned, there is absolutely no difference between pointers to 68k functions and pointers to x86 functions. So if one were to rewrite, for example, the AddTail() function in x86 code, it could easily replace the 68k version.

 

Yeah, but so what about native x86 AmigaOS??????

  • OK, to be honest — nobody knows. Amiga Inc might do this, they might not. Only time will tell. And they are the only ones who really *could* do this (unless the AROS people get in on the act…).

 

What about native x86 routines for application software?

  • No problem. Right now, you need a linux/x86 machine to compile your x86 code, but then there are really nice APIs. You just call one function in your 68k program to load the x86 stuff, then call another to find the address of the x86 routines — and then you treat that address just like any old function pointer. That way, it should be easy to write software that runs on 68k, but also supports calling native PPC or x86 routines, depending on what sort of hardware it runs on.

 

Isn’t this just UAE-JIT with a custom bootloader?

  • No. This is something much much closer to the hardware, giving many more (and some less) features than UAE.

 

Can you name those features?

  • Bill McEwen named quite a few in his speech at AmiWest. Let’s see — you don’t need to install a host OS, everything comes on a bootable CD. This means you can just take your existing Amiga harddisk, hook it up to the PC, and boot into your normal setup. Also, most of the hardware is directly under AmigaOS’s control, or at least directly under the control of the emulator process. No going through layers upon layers of abstractions. This allows for AmigaOS drivers to get direct access to all that cool hardware (and yes, we are currently developing a nice and comfy API for finding stuff on the PCI bus). You can also jump back and forth between 68k and x86 to your heart’s content. It supports CD-Roms, including detecting changes. It also supports getting access to all your other SCSI or ATAPI hardware; For example, I am currently burning my CD-R’s with MakeCD on a SCSI CD burner. What’s missing is custom chip emulation. There is barely enough to do the early startup menu, and that’s it.

 

What about sound?

  • Sound is handled through Amiga AHI drivers that directly access the sound hardware. Currently available (and included) drivers are for SB128 PCI cards, and for the AC97 codec built into most VIA chipset equipped motherboards.
  • There is also a version of Martin Blom’s “NallePUH” program included that will transparently redirect many games and other Paula-only programs to use AHI.

 

So you mean I can just use my FFS hard disk with this thing?

  • FFS, SFS, PFS — anything you like. As long as the filesystem is stored on the disks RDB structure, it will work.

 

Bill said something about using linux for drivers….

  • Indeed. PCs are extremely varied pieces of hardware these days. A lot of the stuff has some minimal compatibility mode (VGA for gfx cards, PIO0 mode for IDE controllers).
  • It wouldn’t be fun to be limited to just using all that fancy hardware in compatibility mode. On the other hand, it also is unrealistic to write AmigaOS drivers for all this stuff.
  • So what we do for gfx card access is to use the linux framebuffer devices. That lets us use just about any gfx card to some degree, and a number of directly supported cards in very nice ways. That’s only possible because some nice people already wrote really good drivers for the linux kernel, and all we have to do is to make some calls to those drivers.
  • The same goes for IDE/SCSI access. The linux kernel is full of drivers for an incredible range of IDE/SCSI controllers. So instead of hitting the hardware directly, we simply leave the low level detail to someone else….:)
  • We are currently thinking about doing the same thing to network devices — you would then have a single SANA2 device that gives you access to whatever networking hardware the linux kernel found. It’s not quite clear whether this is feasible, but it appears to be

 

Hang on, did you just say SCSI?

  • Yep. I like SCSI. My test machine has 2 SCSI controllers. All attached hardware shows up under AmigaOS. It just works.
  • (To be honest, you cannot possibly imagine how much work thatone was, but it’s the end result that counts, and that is that it works).

 

But didn’t you say not going through the OS was an advantage? Now you say you are going through the OS?

  • It’s a tradeoff. You trade on-the-metal programming against device support. And we only ever consider doing this sort of thing if the time needed for the extra layer is insignificant compared to how long the operations themselves take. Of course, it helps that linux is so nice and fast to start with.
  • An earlier version of Amithlon supported IDE disks by presenting the PC’s IDE port as the Gayle IDE interface. It worked, and in some ways it even worked better than the current setup. But in many many ways, it was much worse — PIO0 is really an insult to modern disks. And there couldn’t be more than 4 IDE devices. Not to mention the total lack of SCSI support. And every now and again, things locked up, because Gayle just isn’t the same as a PC’s IDE port, really. So things are much much better now.

 

I got to play with Bill’s laptop at AmiWest, and there was only a single 640×480 screenmode. Is that all?

  • It’s all you get if you have an unsupported gfx card. Well, strictly speaking, you can get any VESA mode you want, but only one single mode.
  • Fun starts when you get a supported gfx chipset. That’s when you suddenly have loads of modes in 8, 16 and 24 bit depth available. The best supported ones are currently nVidia cards, up to and including all the variants of GeForce2. You will get all modes, and also accellerated 2D on these (no prices for guessing what cards I have in my machines). Next best supported are Matrox cards, with most modes available (some the hardware can’t do the way P96 needs them), and most of the 2D accelleration. Then there are a few chipsets (e.g. some ATI stuff) which will give a wide range of resolutions/depths, but no accelleration.

 

I want it!

  • Right now, you can’t buy it. That’s due to licensing issues (see the statement regarding the situation). I hope that a new and improved version will be available fully licensed soon.

 

How come Bill Hogget and Lasse Bodilsen have had it for so long?

  • They are two people who alpha-tested this stuff. They have provided great feedback, on many aspects of the emulator. They have also provided some great suggestions, have tried out things I would never have thought of, or plain didn’t have available, and are just a couple of all-round great guys. They are also much appreciated for sometimes being a relieve valve when I really needed to tell someone about this stuff I was working on (or some other, related happenings) and could not tell anyone else, due to the hush-hush nature of it all.

 

Sounds great — can I see it working somewhere?

  • Check out the official AmigaOS XL site for dates and locations of the road tour. Also, you might want to contact your local Amiga user group and check whether some member already has it, and would be willing to show it off.

 

I am about to buy a PC. Any recommendations?

  • If you intend to run Amithlon on that PC, there are two things you can do to make things work better once it is available. The first is to buy an nVidia gfx card (and stay away from the GeForce3 for now). They are good value for money, and the 2D part is really good, and also well supported under Amithlon.
  • The other, less obvious thing is to buy a “real” processor, not the budget version. I.e. get a PIII rather than a Celeron, or an Athlon rather than a Duron. The extra L2 cache in those really is important for emulation performance.
  • Other than that, just grab a whole bunch of memory (easy to do at the current prices), and leave a few gigs free on the hard disk to eventually put your Amiga stuff on.

 

So when is it gonna be available?

  • Unfortunately, not right now. It was on sale for about 5 months, until the license issues described in here came up. Hopefully, something will be worked out soon, and a new and improved version will be available

 

Wasn’t Amiga Inc going to release this?

  • Yes, they were. Things have changed. Nobody is happy about that, least of all me.
  • However, this thing was always meant to come with fully licensed copies of the Kickstart ROM and AmigaOS 3.9. While it appears as if Haage and Partner have not quite shared that vision (see here for details), I am still committed to that.

 

I am not worried about licensing terms…

  • Great! Then the rest of this FAQ is of no real interest to you. I hope I managed to answer some of your questions. Now go outside and enjoy the summer (or winter, down here, in the Southern hemisphere) while it lasts. Or go and check out the JPEG cleanup page, or the Glicbawls page. That’s cool stuff, too…. The link at the bottom of this page will get you to my homepage on byron, from which this other stuff is linked.

 

This stuff is under the GPL! I want source!

  • No, it is not. At least not the part that you probably want source to.
  • This whole thing sits on top of a modified linux kernel. Of course, that linux kernel is under the GPL, and of course full sources are included on the AmigaOS XL CD. No discussion about that.
  • There are also a bunch of example programs and little helper utilities that I have written over the months to demonstrate and test the Amithlon features. I have also put those under the GPL, to give people as much info as possible.
  • All the clever stuff, however, is in the emulator. That one is proprietary, and no, you won’t get sources.

 

The emulator is based on UAE, that’s GPL’ed code. It’s GPL!

  • Yes, the emulator was derived from UAE sources.
  • Think of UAE as a grand mansion, with many rooms and corridors. There are a couple of rooms that between them make up the Amiga gfx emulation. There is one room for Paula, one room for the CIAs, one room that has the CPU emulation, one room for the FPU emulation, one room for the floppy emulation, one room for the P96 emulation, and so on. The corridors are things like the config file parsing, the GUI modules, the various I/O modules, and that sort of stuff. Lots and lots of people have contributed to this great building.
  • What I did was to take a great big wrecking ball to this mansion. Piece by piece, I got rid of just about everything. Native chipset emulation — gone. Floppy emulation — gone. P96 emulation — gone. Config file parsing — gone. GUI — gone. All that was left standing was the innermost core of the place, the CPU emulation. Everything else I got rid of.
  • Quite a few of those things I then had to rewrite from scratch, looking only at the available hardware documentation. But most of them needed a rewrite, anyway, because Amithlon is very, very different from UAE….

 

Hang on — what about the CPU emulation?

  • Yes, we are using UAE’s CPU emulation. We are also using UAE’s FPU emulation. Before we started work on this thing, Harald contacted the respective authors, and they agreed to grant us a non-GPL licence to these pieces of code. So while we are using code that also was released under the GPL, we are not using the GPL’ed version. OK?

 

But your UAE-JIT code is GPL, how can you use it for this?

  • Once again — releasing some code under the GPL does not mean the author is giving up ownership of the code. What it does is to grant an irrevocable license to everyone to use and do certain other things with the code. This license is non-exclusive. The author may choose to grant additional licenses with other conditions.
  • If the author produces derivative code, based on code he released under the GPL earlier, there is absolutely no need to release that new stuff under the GPL as well. In contrast, if someone else,who acquired the code under the GPL, creates a derivative work and distributes it, then she is bound by the conditions placed on her by the GPL.
  • Please check the further explanations on the FSF site if you are still not convinced.

 

OK, so maybe legally it’s OK — but how can you sleep at night?

  • Hey, look — I really like the GPL. If I had a choice, I would make the source available to everyone today.
  • Unfortunately, reality is that I have to pay rent. I have to eat. I have to buy nifty new hardware to work on, and nifty old hardware to test this stuff with. Maybe I should even buy a special girl flowers every now and again. All of that costs money.
  • To get Amithlon to the point where it is right now took a lot of work. A LOT of work. Maybe you remember Bill McEwen’s comment about having saved his team 18 months of development time? Well, I don’t know how many people he has on his team, but over here, it’s basically just me. And it hasn’t been 18 months. Which might give you an idea of the kind of daily hours that went into it.
  • To put it bluntly — I could not afford to invest that much time without getting some money out of it. If this thing wasn’t proprietary and commercial, it wouldn’t exist. Period.
  • If you object to the idea of a commercial derivative of the UAE-JIT work, then by all means, use UAE-JIT. Hey, I like UAE-JIT. I spent waaaaaay too much time on it, of course, but it was fun making it. And I released it under the GPL, which is the only reason you can use it. Which is exactly why, most days, I can sleep quite well. This way, everyone is better off.

 

But… but…

  • Sorry. That’s the way it is. You want to change it? Easy! Got some serious spare cash lying around? Wanna sponsor the project?

—————————————————————————————————————————-

FAQ 2

BOOTING

When I am booting Amithlon, . the boing ball is a bit jerky, every few seconds it sticks for a moment.

That’s OK. The bouncing ball is shown while in the background, the linux kernel boots up. For it to bounce (and move and turn), it relies on the timer interrupt — and during bootup, some drivers disable interrupts for a short while.

 

I have a SCSI CD-ROM, and the Amithlon CD won’t boot from it

  • That’s a problem of your SCSI controller’s BIOS. You may try upgrading that BIOS, if it is flashable. If that doesn’t help, you will need to find an alternative method of booting.
  • An ATAPI (aka IDE) CD-ROM might be a simple solution; You can often pick them up for pocket change from swap meets.
  • Alternatively, you can look through the hard disk install guide, install Amithlon to boot from your HD, and thus avoid using the CD at all.

Last but not least, if you have a way to boot into DOS mode with a CD-ROM driver for your SCSI CD-ROM, try going into the isolinux directory on the CD and then typing loadlin @amithlon

 

I have a serial mouse attached, and it doesn’t seem to work!

At this point in time, Amithlon requires a PS/2 mouse, at least until you set up a mouse driver for a serial mouse (which is much much easier if you have a PS/2 mouse to do it with)

 

I have a USB mouse/keyboard, and it doesn’t seem to work!

USB is not currently supported in Amithlon. You might, however, be able to activate the BIOS setting “USB Legacy Support” or “USB support for DOS” or similar, to have your PC automatically translate the USB signals into PS/2 signals. It works at least for some people….

 

I have a PS/2 mouse, and it doesn’t seem to work!

This seems to happen sometimes when you have USB legacy support (see previous answer) switched on, although you have actual PS/2 devices attached. Apparently, the USB translation blocks the signals from the real PS/2 devices. So try switching Legacy Support off.

AMITHLON BUGFIXES

I have heard something about a bunch of updates/bugfixes for Amithlon?!? Is my version faulty?

  • Yep, there are two extremely minor bugs in the CPU emulation, and there should also be built-in support for mounting FAT partitions, but there isn’t (I screwed up!)

I have prepared fixes for these problems; However, they are currently applied in a way that is not nice, and will be changed once a better way has been devised. If you want them, anyway, have a look at the original announcement I sent to the mailing lists. The download includes a detailed README, describing how to install these fixes.

DISPLAY DRIVERS

I have a GeForce3, why isn’t it supported as well as the GeForce2?

Amithlon uses the linux framebuffer drivers for graphics access. There currently isn’t a framebuffer driver for the GeForce3, so we can only use that card through the generic VESA mode.

 

I know where to find linux drivers for the GeForce3!

  • So do I. However, those are drivers for XFree86. What Amithlon uses are the low-level kernel framebuffer drivers.

If you know where to find a framebuffer driver for the GeForce3, let me know as quickly as you can. But unfortunately, drivers for Xfree86 are no use at all.

 

I got a Voodoo3. Why isn’t it supported better? Any chances of better support?

  • There are a few things one needs to know about the Voodoo3:
    • There is a kernel framebuffer driver for it. Unfortunately, that driver doesn’t play by the rules, and thus causes problems when coexisting with other drivers. That’s why it isn’t included in the Amithlon kernel.
    • There is also an 68k native P96 driver for it, written by the Picasso96 team themselves. This driver works quite well under Amithlon, but there is a problem — once the VESA frame buffer has claimed the card, the P96 driver is unable to claim it. As the VESA driver kicks in long before P96….
    • Most importantly — I don’t have one. Yet. Which means I can’t really do much about the previous two points, because I can’t test.
  • So, what to do? There are several possibilities:
    • If you have Amithlon installed on the hard disk, you could compile a kernel with Voodoo3 framebuffer support, butwithout support for any other framebuffer devices. The complete kernel sources, as used for Amithlon, are on your AmigaOS XL CD.
    • If compiling linux kernels is too scary, you can try to hassle me to do that for you; But then, you’d become an alpha tester for this sort of Voodoo3 support, seeing as I don’t have one.
    • Once you have a V3-enabled kernel, try putting it next to the emubox,gz kernel on your HD, and changing the boot line in your boot manager to use the new kernel. Good luck!
    • If you have any other video card, even an old S3 Virge (as long as it can do VESA 2.0), you could make that card your boot card, and thus the one that Amithlon will grab for its VESA driver. Which leaves the Vodoo3 unclaimed, and the native P96 driver can get to it.
    • To get a copy of the driver, contact harald@amithlon.net for a copy, and instructions on what to do with it.
    • Or you could just wait until I get a Voodoo3, which will hopefully happen the Sunday after the first license payment for Amithlon hits my bank account. Then I can do all sorts of clever things to make it work well without any of those contortions, and can test them myself. No promises, but…

 

I heard somewhere that Warp3D actually runs on Amithlon?

  • I used to not mention this, but seeing as the Frieden brothers have recently posted this to ANN.LU themselves….
  • Yes, the Warp3D drivers for the Voodoo3 do indeed run on Amithlon, if using the official P96 Voodoo3 driver.

Please note that to run the W3D drivers, one needs to do one small hack to the P96 drivers. And we won’t tell you what that hack is. The reason for this is that Warp3D is commercially licensed software, and nobody has yet paid for a W3D license for Amithlon. So while we are more than happy to demonstrate this stuff and to show that it does indeed work from a technical point of view, using W3D under Amithlon is completely unsupported from a business point of view.

ACCESS TO WINDOWS/LINUX FILESYSTEMS

I want to access FAT partitions on my hard drive from within Amithlon!

  • This was meant to be a feature of the release version, but unfortunately I screwed it up (and due to lack of FAT partitions on my hard drives, didn’t notice). See the section on Amithlon fixes for a fix to the screwup…. that file also contains a description on how to set up easy access to FAT partitions, relying on Amithlon doing the actual mounting.
  • Alternatively, you can download FAT95 from Aminet, and use it with amithlon.device. However, leaving the whole mountlist thing to Amithlon is much easier…

 

What about accessing NTFS partitions?

No, sorry, no can do. There simply isn’t an NTFS filesystem for AmigaOS, and as in Amithlon, AmigaOS is in the driver’s seat, that’s what would be needed.

 

How about linux ext2fs filesystems?

  • There is a GPL-ed implementation of ext2fs for AmigaOS. When I looked for it, it seemed to have vanished from the face of the Earth, but some friendly soul (who I would like to thank here, but whose name I cannot look up at my current location….) found an archive when cleaning up his hard drive, and sent it to me.
  • The README for that stuff is really scary. It sounds like using this stuff might be risking some serious data damage unless one is very careful. And it also needs to be compiled, all I got is source.
  • When I next find time, I will have a look at whether I can somehow make a safe, read-only version (probably with read-write an untested, use-at-your-own-risk option). So here the answer is currently “soon”.

If you want to play around with the source yourself (or maybe even take that work off me:), mail me at bernie@amithlon.net, and I will be more than happy to send you the source archive.

PREFERENCES

What keymap should I use?

  • PC keyboards, especially national ones, have slightly different layouts than Amiga keyboards. This means that standard AmigaOS keymaps might not work completely.

Instead, Amithlon comes with ready-made keymaps for US and German PC keybaords, called “us_pc” and “d_pc”. Unfortunately, at this point, we do not have ready-made keymaps for other national keyboard variations available, as we do not have any keyboards other than US or German ones.

 

I have an Italian/Croation/French/xxxxx keyboard. What now?

  • First of all, check out the keymap repository to see whether there already is one available for download. If yes, great. If no, you will need to create one.
  • If there is a Win95 keymap for your country on Aminet, it is probably a good starting point. Otherwise, start with either the normal AmigaOS keymap for your country, or with one of the existing Amithlon keymaps.
  • Then, use a keymap editor to change things around. I’d recommend KeyMapEd or EditKey off Aminet. Note that these programs, for some reason, expect you to type in the symbols keys should produce…. which seems kinda silly, seeing as you are trying to get the keyboard right. You might need to do this with some foreign keyboard map active to be able to actually produce the symbols

Once you have a working keymap for your country’s PC keyboard, it would be nice if you made it available to other Amithlon users, by sending it to me so I can put it up in the repository. Thanks!

 

My copy of the d_pc keymap gives the wrong symbol when pressing the ‘#’ key!

You are a beta tester, aren’t you? The last beta H&P sent out (version 2c) still had a slightly wrong keymap on it; The release version has the correct one on it. So go and get your real copy (or fix the keymap as describd above).

AMIGAOS DEVICES

How can I access my EIDE and SCSI devices under Amithlon?

  • You can access all of them through the amithlon.device . The IDE devices will show up as units 0 to 7 (0 for primary master, 1 for primary slave, 2 for secondary master, 3 for secondary slave, 4 and 5 for tertiary, and 6 and 7 for the fourth IDE port)
  • Unit 100 is the disk image amithlon_hd.

Units 200 and up are SCSI devices attached to actual SCSI controllers in your PC.

 

When I start HDToolBox, everything shows up twice! Is this a bug?

  • No, that is a feature. There are (at least) two different standards for mapping multiple SCSI adaptors and buses that are handled by a single AmigaOS device. The first standard encodes the adaptor number in the “hundreds” column of the unit number (see previous question — IDE is adaptor 0, disk images adaptor 1, actual SCSI adaptors are on 2 and up).
  • The other standard involves creating extra entries in the device list, called (in our case) 2nd_amithlon.device, 3rd_amithlon.device and so on.

Some software relies on one scheme, some software relies on the other. So Amithlon actually supports both. However, HDToolBox in OS3.9 will alsosupport both methods, and thus most devices show up twice. That’s OK, it’s no problem.

 

In some software, I have a weird device showing up on amithlon.device, unit 8. Why?

  • It’s a similar issue as in the previous question. The original scheme as standardized by Commodore would only allow SCSI IDs up to 9. When Phase5 introduced Wide SCSI to the Amiga on the Cyberstorm cards, they had to come up with a way to kludge around that, because on Wide SCSI, IDs up to 15 are possible.
  • They decided to make a unit with SCSI ID 8 a special “switch unit”; Any unit with such an ID would have the rest of the unit number interpreted in a different way. Unfortunately, they didn’t include an extra sanity check.
  • In order to support Wide SCSI adaptors in the most compatble way, Amithlon also supports this special remapping or reinterpreting of unit numbers. Unfortunately, not all software is aware of Phase5’s extensions, and unaware software tends to look at unit 8 — which, in the special reinterpretation, translates to SCSI adaptor 0, bus 0, ID 0, LUN 0…. which happens to be the primary IDE master. So a mirror image of unit 0 will show up at unit 8.

Ain’t standards wonderful?

 

So what about my CD-ROMs?

  • They will also show up on amithlon.device, together with all other IDE or SCSI devices.
  • However, PCs are very very varied, and it would be almost impossible to provide a way to provide a mountlist entry for CD-ROMs that works on the majority of users’ machines — there is no way of knowing the unit number of the CD-ROM.
  • To overcome this, Amithlon also provides a cdrom.device . On that device, only CD-ROMs are supported, and they are enumerated. Thus, cdrom.device, unit 0 always refers to your first CD-ROM, unit 1 refers to the second, and so on.

Using the cdrom.device, it is possible for the minimal OS3.9 install to automatically mount the first CD-ROM, which in 95% of PCs should be the boot CD-ROM.

 

How about floppies

  • There is also a floppy.device, which will provide access to yourPC-formatted floppies. Unit 0 is floppy drive A:, unit 1 is floppy drive B:.

amithlon_hd:Storage/DosDevices/PC0 has been setup to access the A: drive through CrossDos; PC1 does the same for B: drive.

 

I used PC0:, and then changed the disk. AmigaOS doesn’t seem to notice?

  • Theoretically, floppy drives can signal disk changes to the disk controller, and an OS should be able to detect them. However, on the PC, this feature is rarely if ever used; As a consequence, there are a lot of dodgy floppy drives out there that don’t implement this correctly or at all. Thus, disk change detection on a PC is very much hit-and-miss.
  • In order to avoid this gamble, we don’t even try to detect disk changes in Amithlon.

So if you want AmigaOS to notice a floppy change, you need to issue the command diskchange PC0: (or diskchange PC1:) in a shell. This might be clunky, but it has the advantage of always working.

 

What about Amiga-formatted floppies?

  • Short answer: You can’t use them!
  • Long answer: There is a small different in the MFM coding between Amiga format and PC format. That small difference makes it impossible for the PC floppy controller to read Amiga formatted floppies; The PC controller is actually more intelligent and independent than the Amiga one and looks for a certain sector header all by itself. Amiga floppies don’t have this header, so the controller never starts reading. Doh!
  • A bunch f people who have worked out a truly clever hack how to fool the PC floppy controller and have written a tool calleddisk2fdi. With this tool, you can read Amiga floppies IF you have two floppy drives in your PC (and have a lot of time).

Disk2fdi can produce ADF files, which you can then use under AmigaOS with the FMSDisk virtual floppy.

 

How about serial, parallel ports?

They can be used through the powercom.device and powerpar.device, respectively. These devices are derived from the device drivers for the HyperCom card by VMC; So anything that works with a HyperCom should also work with these devices.

 

I tried using powercom.device for my modem, but the terminal program says it couldn’t open the device. Huh?

You might be missing the vmc.resource from your libs: folder. Just copy it from amithlon_hd:libs, and it should work.

 

What about networking?

  • For networking, we currently support NE2000 compatible PCI cards (also known as “RTL-8029 cards”, which covers just about any cheap 10MBit/s only PCI card you can buy today). For those, a SANAII driver can be found in amithlon_hd:devs/networks/powerne2k.device . You can use this driver with any network stack you like, including Genesis that comes with OS3.9.
  • This driver currently doesn’t support more than one network card. We are working on fixing this limitation.

If the powerne2k device does not load properly, please check that you have powerpci.library installed in libs:. If it is missing, you can copy it from amithlon_hd:libs.