Now here's why:

AUX does not use the ToolBox as much as Mac OS does. AUX is a direct hardware implementation of UNIX on the Mac OS hardware, meaning that it will access devices directly, bypassing any usual work that the ToolBox does. Basilisk II does not emulate any real hardware, it just messes around with the ToolBox and emulates the CPU that is required to run. (ToolBox Patching) Hence, Basilisk II does not provide a hardware emulation, but rather a sloppy patch job to the ToolBox to trick Mac OS into running, which is why many applications won't run because hardware components are missing.

Even if you got MMU to work, there is another problem ahead: Hard Disks. Basilisk II uses Disk Images to represent hard disks. These disk images are treated by Mac OS as large external floppy drives. If you drag a hard disk in Basilisk II to the trash, you won't be presented the dialogue that you normally get on a real Macintosh if you eject a SCSI device.."Are you sure you want to eject the disk? It will re-appear on the Finder Desktop when you restart." Thus, it isn't a true SCSI Disk System. You would have to write a complex sequence of programming to allow Basilisk II to treat disk images as true SCSI Devices and allow the Partition tools to be able to make partitions. (AUX requires UNIX Partitions, it does not use HFS that much)

The next hurdle of course would be to make sure it works correctly. See, AUX only works on specific models because it is custom designed for them. So when using Basilisk II, you would need to have the correct ROM type in for a supported model.

Hence, it's not worth the time or money if money ever was an issue. Not happening anytime soon.

quote:

---

I honestly don't see what the point would be...Quadras are cheap and relatively easy to find.

"**** em" - Jobs in regards to customers
Warrior maclover5
68kMLA
Official 68kMLA Detective
Number of 68ks Liberated: 7
Number of Contraband (PPC) Liberated from the Dumpster: 1

---

What I was looking for was a system that had a good machine-level debugger and could run NetBSD.

This was before I found the bug that was keeping the NetBSD native-boot code from working, which is one of the two reasons I wanted such an emulator.

The other reason was to try and figure out the (almost completely undocumented) SWIM chip in the hopes of being able to write a NetBSD driver for it. There's nothing quite like watching a trace of I/O register accesses and lining it up to a disassembly of the driver for figuring out how hardware works. There still isn't a SWIM driver for NetBSD yet.

Unfortunately, the UAE CPU core was a bit more complex than I wanted to try and figure out at the time, and I knew that writing a working 68000 core was beyond me, let alone a 68030 core. So I dropped the project in favor of a Lisp Machine emulator.

There's another fun problem with doing hardware-level emulation of a Mac system. Collecting all the NuBus declaration ROM images and emulating the video cards, network cards, MacIvory cards, TI MicroExplorer cards, etc. Sure, you could just do one of each, but where's the fun in that?

And then hardware documentation! Space Aliens Ate My Mouse is about as good as you're going to get on how ADB works short of understanding the NetBSD HWDIRECT ADB drivers. And those are still a little finicky. You can find documentation on the IWM chip, but the SWIM chip is a lot harder to figure out. And the SWIM II chip is a complete unknown. What are the memory maps for the different systems? In 24-bit mode? In 32-bit mode? Plus you have to collect ROM images for each system -and- keep them all straight. Oh, and most of the NuBus cards are completely undocumented, hardware wise.

I may take this challenge up at some point. Just not soon.

Hunh. I should try and get a machine with a SWIM II chip. I might at least be able to get that to read 800k disks, which would be an improvment over the current situation in NetBSD, and might lead to getting the floppy driver into better shape for when the SWIM ISM mode is figured out...

Oh well, I've ranted for long enough now.

--Jamethiel

Look at the linux/m68k project they had to do ADB and SCSI drivers for the mac and they have support for most a/ux machines.
I think they did swim chip drivers too.

i don't know much about coding but those drivers might be useful.

http://www.eetasia.com/ARTICLES/2000JUN/2000JUN02_CT_AN8.PDF

I'm both saddened and relieved. Saddened to think that Linux doesn't even support the well known IWM chip (well known enough that NetBSD and OpenBSD support it) or the original SWIM chips in IWM mode, and relieved that nobody else figured the SWIM chips out yet either (petty of me, I know).

Maybe I'll play with the SWIM chip in my LC II this weekend. I still have my notes and the Pocket Forth source for my original experiments... Or Pocket is small enough, I could make a boot disk with it for the SE/30... And now I have a couple experiments in mind to try.

What also needs to be done is a complete Apple Sound Chip driver.

Then all the Aiff Wave and even mp3 stuff could be played.

Also any music editing stuff could be ported over from other 68k unix OS's.

Heres a SWIM thing I found.

Notes on the SWIM controller chip.
Alastair Bridgewater, Febuary 2, 2001.

The SWIM drive controller chips used in such Macs as the Classic and the
IIcx are descended from the original Disk ][ drive controller card for
the Apple ][ series of computers. Unlike the previous generation drive
controller (the IWM controller), they support both GCR and MFM format
disks. They also support two sets of registers, although only one set
may be used at a time (see Switching between IWM and SWIM modes below).

SWIM mode register layout:

.equ writeData, 0x0000 /* Data (write) */
.equ writeMark, 0x0200 /* Mark (write) */
.equ writeCrc, 0x0400 /* CRC (write) */
.equ writeParameter, 0x0600 /* Parameter data (write) */
.equ writePhase, 0x0800 /* Phase (write) */
.equ writeSetup, 0x0a00 /* Setup (write) */
.equ modeZeros, 0x0c00 /* mode register zeros (write) */
.equ modeOnes, 0x0e00 /* mode register ones (write) */

.equ ??? 0x1000 /* ??? (read?) */ /* data read? */
.equ readData, 0x1200 /* Data (read) */ /* mark read? */
.equ ??? 0x1400 /* ??? (read) (error?) (mark?) */
.equ readParameter, 0x1600 /* Parameter data (read) */
.equ readPhase, 0x1800 /* Phase (read) */
.equ readSetup, 0x1a00 /* Setup (read) */
.equ readMode, 0x1c00 /* mode register (read) */
.equ handshake, 0x1e00 /* Handshake (read) */

According to the patent (US4916556), the SWIM chip has 16 registers as
follows: data (r/w), mark (r/w), error (r), write CRC (w), parameter data
(r/w), phase (r/w), setup (r/w), handshake (r), mode zeros (w), mode ones
(w), and status (r).

Switching between IWM and SWIM modes:

To switch from SWIM mode to IWM mode, clear bit 6 of the mode register by
writing 0x40 (or any other value with that bit set) to modeZeros. Typically,
this value will be 0xf8, to clear the action, writemode, HEDSEL, and MOTORON
bits at the same time.

To switch from IWM mode to SWIM mode, use the following code fragment:

tstb a0@(q7L)
tstb a0@(mtrOff)
tstb a0@(q6H)
moveb #0x57,d2
moveb d2,a0@(q7H)
moveb #0x17,a0@(q7H)
moveb d2,a0@(q7H)
moveb d2,a0@(q7H)

To determine which mode the chip is in, store data in writePhase, and see
if it shows up in readPhase (it will if the chip is in SWIM mode). The
sequence of values used for this in the Classic's .Sony driver is 0xf5,
0xf6, 0xf7.

Selecting a drive:

Bits one and two of the mode register select the internal and external
drives, respectively, and bit 7 controls the motoron signal.

Manipulating the disk Phase and SEL lines, and reading the SENSE line:

Disk phase lines are controlled by means of the phase register. The bottom
four bits control the state of their respective phase lines. The top four
bits are usually all set to 1 to indicate that the phase lines are all
outputs.

While the patent appears to indicate that the disk SEL line can be
controlled by the SWIM chip (and the SWIM III driver in MkLinux concurs),
the SEL line is still controlled by the VIA in both the IIcx and Classic
.Sony drivers.

The sense line can be read by way of bit three of the handshake register.

Parameter memory:

The SWIM chip has 16 bytes of parameter memory. This memory is accessed by
successive accesses to the parameter register (either read or write). The
offset into parameter memory for the next access can be reset by writing to
the modeZeros register.

Some odd characters were in the last post here it is again.

Notes on the SWIM controller chip.
Alastair Bridgewater, Febuary 2, 2001.

The SWIM drive controller chips used in such Macs as the Classic and the
IIcx are descended from the original Disk ][ drive controller card for
the Apple ][ series of computers. Unlike the previous generation drive
controller (the IWM controller), they support both GCR and MFM format
disks. They also support two sets of registers, although only one set
may be used at a time (see Switching between IWM and SWIM modes below).

SWIM mode register layout:

.equ writeData, 0x0000 /* Data (write) */
.equ writeMark, 0x0200 /* Mark (write) */
.equ writeCrc, 0x0400 /* CRC (write) */
.equ writeParameter, 0x0600 /* Parameter data (write) */
.equ writePhase, 0x0800 /* Phase (write) */
.equ writeSetup, 0x0a00 /* Setup (write) */
.equ modeZeros, 0x0c00 /* mode register zeros (write) */
.equ modeOnes, 0x0e00 /* mode register ones (write) */

.equ ??? 0x1000 /* ??? (read?) */ /* data read? */
.equ readData, 0x1200 /* Data (read) */ /* mark read? */
.equ ??? 0x1400 /* ??? (read) (error?) (mark?) */
.equ readParameter, 0x1600 /* Parameter data (read) */
.equ readPhase, 0x1800 /* Phase (read) */
.equ readSetup, 0x1a00 /* Setup (read) */
.equ readMode, 0x1c00 /* mode register (read) */
.equ handshake, 0x1e00 /* Handshake (read) */

According to the patent (US4916556), the SWIM chip has 16 registers as
follows: data (r/w), mark (r/w), error (r), write CRC (w), parameter data
(r/w), phase (r/w), setup (r/w), handshake (r), mode zeros (w), mode ones
(w), and status (r).

Switching between IWM and SWIM modes:

To switch from SWIM mode to IWM mode, clear bit 6 of the mode register by
writing 0x40 (or any other value with that bit set) to modeZeros. Typically,
this value will be 0xf8, to clear the action, writemode, HEDSEL, and MOTORON
bits at the same time.

To switch from IWM mode to SWIM mode, use the following code fragment:

tstb a0@(q7L)
tstb a0@(mtrOff)
tstb a0@(q6H)
moveb #0x57,d2
moveb d2,a0@(q7H)
moveb #0x17,a0@(q7H)
moveb d2,a0@(q7H)
moveb d2,a0@(q7H)

To determine which mode the chip is in, store data in writePhase, and see
if it shows up in readPhase (it will if the chip is in SWIM mode). The
sequence of values used for this in the Classic's .Sony driver is 0xf5,
0xf6, 0xf7.

Selecting a drive:

Bits one and two of the mode register select the internal and external
drives, respectively, and bit 7 controls the motoron signal.

Manipulating the disk Phase and SEL lines, and reading the SENSE line:

Disk phase lines are controlled by means of the phase register. The bottom
four bits control the state of their respective phase lines. The top four
bits are usually all set to 1 to indicate that the phase lines are all
outputs.

While the patent appears to indicate that the disk SEL line can be
controlled by the SWIM chip (and the SWIM III driver in MkLinux concurs),
the SEL line is still controlled by the VIA in both the IIcx and Classic
.Sony drivers.

The sense line can be read by way of bit three of the handshake register.

Parameter memory:

The SWIM chip has 16 bytes of parameter memory. This memory is accessed by
successive accesses to the parameter register (either read or write). The
offset into parameter memory for the next access can be reset by writing to
the modeZeros register.

quote:

---

The point would be... Really fast A/UX.

---

It's like people's obsession with Emulating PPC on Intel to run OS X. (Which by the way has been done, the developers have booted 8.5 with extensions off)

It's just easier to grab a machine to do anything natively.

quote:

---

I still don't see the point, not when you can get free machines that run AUX like the SE/30 that people are literally dumping out.

It's like people's obsession with Emulating PPC on Intel to run OS X. (Which by the way has been done, the developers have booted 8.5 with extensions off)

It's just easier to grab a machine to do anything natively.

---

I'm sure that it'd be better to make a more 'maclike' box, but still completely possible

That would be a VERY interesting upgrade for some older macs IMHO... If Apple or someoen was to make a cdromsized G3 with a NuBus card and software so's you could use G3 on your 68k or older PowerPCs I'd get one for the 7300

quote:

---

Heres a SWIM thing I found.

Notes on the SWIM controller chip.
Alastair Bridgewater, Febuary 2, 2001.

---

So you already knew that. LOL.

I don't know why apple just doesn't release the hardware info for the old chips.

It's like CyberDog..Apple promised to open up the source but later refused.

Logan

68k Macintosh Liberation Army Forums

© 2001-2003 68kMLA