Mac OS X's AppleSCCSerial kernel extension requires the slot-names property in order to use any serial ports. This patch adds the property.
After this patch is applied, the next thing that stops Mac OS X from using the serial port is something having to do with DMA.
http://www.opensource.apple.com/source/AppleSCCSerial/AppleSCCSerial-126.4.0... In this file the setPortName() function is what does the searching for slot-names.
Index: drivers/escc.c =================================================================== --- drivers/escc.c (revision 1378) +++ drivers/escc.c (working copy) @@ -456,6 +456,11 @@ NEWWORLD(set_property(dnode, "interrupts", (char *)&props, 3 * sizeof(cell)));
+ /* The four numbers in front of Modem are needed for AppleSCCSerial + kernel extension compatibility. */ + char *names = "0001Modem"; + NEWWORLD(set_property(dnode, "slot-names", names, strlen(names) + 1)); + device_end();
if (legacy) {
Le 09/02/2016 04:45, Programmingkid a écrit :
After this patch is applied, the next thing that stops Mac OS X from using the serial port is something having to do with DMA.
http://www.opensource.apple.com/source/AppleSCCSerial/AppleSCCSerial-126.4.0... In this file the setPortName() function is what does the searching for slot-names.
Index: drivers/escc.c
--- drivers/escc.c (revision 1378) +++ drivers/escc.c (working copy) @@ -456,6 +456,11 @@ NEWWORLD(set_property(dnode, "interrupts", (char *)&props, 3 * sizeof(cell)));
/* The four numbers in front of Modem are needed for AppleSCCSerial
kernel extension compatibility. */char *names = "0001Modem";
NEWWORLD(set_property(dnode, "slot-names", names, strlen(names) + 1));
device_end(); if (legacy) {
I get a compilation error. drivers/escc.c: In function 'escc_add_channel': drivers/escc.c:463:19: error: initialization discards 'const' qualifier from pointer target type [-Werror] char *names = "0001Modem";
It works by changing the line to const char *names = "0001Modem";
I didn't test MacOS X, but this changes MacOS 9 error from "illegal instruction" to "address error".
Hervé
On Mon, Feb 08, 2016 at 10:45:42PM -0500, Programmingkid wrote:
Mac OS X's AppleSCCSerial kernel extension requires the slot-names property in order to use any serial ports. This patch adds the property.
After this patch is applied, the next thing that stops Mac OS X from using the serial port is something having to do with DMA.
Great!
You can assign addresses for serial DMA and even OS 9 will try poking at the dbdma controller, so this is just a question of hooking up the qemu side. I can try doing this later today if it's useful..
Which version of OS X are you using for testing this?
http://www.opensource.apple.com/source/AppleSCCSerial/AppleSCCSerial-126.4.0... In this file the setPortName() function is what does the searching for slot-names.
Index: drivers/escc.c
--- drivers/escc.c (revision 1378) +++ drivers/escc.c (working copy) @@ -456,6 +456,11 @@ NEWWORLD(set_property(dnode, "interrupts", (char *)&props, 3 * sizeof(cell)));
- /* The four numbers in front of Modem are needed for AppleSCCSerial
kernel extension compatibility. */- char *names = "0001Modem";
Weird. Is this meant to be \x00\x00\x00\x01Modem? (I see that the OS X code you linked is just skipping the first four bytes. And it hardcodes the PowerMac1,1 case I switched to for my own testing, heh..!)
- NEWWORLD(set_property(dnode, "slot-names", names, strlen(names) + 1));
If so, I guess you have to replace the strlen with a hard-coded length.
(Shouldn't the slot-name only be set to a string for one channel? Maybe it doesn't matter?)
device_end();
if (legacy) {
- Alyssa
On Feb 9, 2016, at 1:25 AM, Hervé Poussineau wrote:
Le 09/02/2016 04:45, Programmingkid a écrit :
After this patch is applied, the next thing that stops Mac OS X from using the serial port is something having to do with DMA.
http://www.opensource.apple.com/source/AppleSCCSerial/AppleSCCSerial-126.4.0... In this file the setPortName() function is what does the searching for slot-names.
Index: drivers/escc.c
--- drivers/escc.c (revision 1378) +++ drivers/escc.c (working copy) @@ -456,6 +456,11 @@ NEWWORLD(set_property(dnode, "interrupts", (char *)&props, 3 * sizeof(cell)));
/* The four numbers in front of Modem are needed for AppleSCCSerial
kernel extension compatibility. */char *names = "0001Modem";
NEWWORLD(set_property(dnode, "slot-names", names, strlen(names) + 1));
device_end();
if (legacy) {
I get a compilation error. drivers/escc.c: In function 'escc_add_channel': drivers/escc.c:463:19: error: initialization discards 'const' qualifier from pointer target type [-Werror] char *names = "0001Modem";
It works by changing the line to const char *names = "0001Modem";
I didn't test MacOS X, but this changes MacOS 9 error from "illegal instruction" to "address error".
Hervé
Thanks for testing out my patch. I think this change in Mac OS 9 errors definitely indicates we are on the right patch. Now all that's left is attaching DMA channels to the ESCC (I think).
On Feb 9, 2016, at 3:24 AM, Alyssa Milburn wrote:
On Mon, Feb 08, 2016 at 10:45:42PM -0500, Programmingkid wrote:
Mac OS X's AppleSCCSerial kernel extension requires the slot-names property in order to use any serial ports. This patch adds the property.
After this patch is applied, the next thing that stops Mac OS X from using the serial port is something having to do with DMA.
Great!
You can assign addresses for serial DMA and even OS 9 will try poking at the dbdma controller, so this is just a question of hooking up the qemu side. I can try doing this later today if it's useful..
It is definitely useful. The ability to run Mac OS 9 in QEMU depends on it.
Which version of OS X are you using for testing this?
Mac OS 10.2.8 is running as the guest.
http://www.opensource.apple.com/source/AppleSCCSerial/AppleSCCSerial-126.4.0... In this file the setPortName() function is what does the searching for slot-names.
Index: drivers/escc.c
--- drivers/escc.c (revision 1378) +++ drivers/escc.c (working copy) @@ -456,6 +456,11 @@ NEWWORLD(set_property(dnode, "interrupts", (char *)&props, 3 * sizeof(cell)));
- /* The four numbers in front of Modem are needed for AppleSCCSerial
kernel extension compatibility. */- char *names = "0001Modem";
Weird. Is this meant to be \x00\x00\x00\x01Modem? (I see that the OS X code you linked is just skipping the first four bytes. And it hardcodes the PowerMac1,1 case I switched to for my own testing, heh..!)
I don't know if your string would work, but you are right that the first four bytes are just skipped. So it doesn't really matter what they are.
- NEWWORLD(set_property(dnode, "slot-names", names, strlen(names) + 1));
If so, I guess you have to replace the strlen with a hard-coded length.
Is there an issue with strlen()? I thought it was a good idea because it makes the code more self-documenting, meaning you understand what the last argument expects.
(Shouldn't the slot-name only be set to a string for one channel? Maybe it doesn't matter?)
I don't know. But I do know my G3 iMac's value for this property is this:
00000001 Modem
The PowerMac3,1 probably has the same value.
- Alyssa
Thank you very much for reviewing my patch.
On Tue, Feb 09, 2016 at 09:47:57AM -0500, Programmingkid wrote:
You can assign addresses for serial DMA and even OS 9 will try poking at the dbdma controller, so this is just a question of hooking up the qemu side. I can try doing this later today if it's useful..
It is definitely useful. The ability to run Mac OS 9 in QEMU depends on it.
After a few days spent poking through the startup process in MacsBug, I'm not sure this is true. But I'll hook it up later (if someone else doesn't do it first).
Which version of OS X are you using for testing this?
Mac OS 10.2.8 is running as the guest.
Thanks, I'll see if I can go install 10.2 myself later too..
I don't know if your string would work, but you are right that the first four bytes are just skipped. So it doesn't really matter what they are.
The first four bytes are the slot bitmask (as a 32-bit BE integer), followed by one string per slot (so, one string for each set bit). I don't know whether any OS cares about this or not, another thing to look into..
Is there an issue with strlen()? I thought it was a good idea because it makes the code more self-documenting, meaning you understand what the last argument expects.
It fails if you have null bytes in your string (as you would if you encoded the integer in it). Otherwise, yes, it's much clearer than using a constant.
I don't know. But I do know my G3 iMac's value for this property is this:
00000001 Modem
The PowerMac3,1 probably has the same value.
In any case, it makes sense as a value. (Does anyone have an OF dump from a PowerMac3,1?)
Thank you very much for reviewing my patch.
Thank you for the work!
- Alyssa
On Feb 9, 2016, at 10:05 AM, Alyssa Milburn wrote:
On Tue, Feb 09, 2016 at 09:47:57AM -0500, Programmingkid wrote:
You can assign addresses for serial DMA and even OS 9 will try poking at the dbdma controller, so this is just a question of hooking up the qemu side. I can try doing this later today if it's useful..
It is definitely useful. The ability to run Mac OS 9 in QEMU depends on it.
After a few days spent poking through the startup process in MacsBug, I'm not sure this is true. But I'll hook it up later (if someone else doesn't do it first).
You may be right. This code on Mac OS X does not allow the driver to work because of DMA issues. It is from the PPCSerialPort.cpp file.
// Calls the DMA function that knows how to // handle all the different hardware: SccSetDMARegisters(&Port, provider); if ((Port.TxDBDMAChannel.dmaChannelAddress == NULL) || (Port.TxDBDMAChannel.dmaBase == NULL) || (Port.RxDBDMAChannel.dmaChannelAddress == NULL) || (Port.RxDBDMAChannel.dmaBase == NULL)) return false;
Which version of OS X are you using for testing this?
Mac OS 10.2.8 is running as the guest.
Thanks, I'll see if I can go install 10.2 myself later too..
No probably. If you want I could send you a custom AppleSCCSerial kernel extension with a lot of debugging statements added to it. It will tell you what expectations are being missed.
I don't know if your string would work, but you are right that the first four bytes are just skipped. So it doesn't really matter what they are.
The first four bytes are the slot bitmask (as a 32-bit BE integer), followed by one string per slot (so, one string for each set bit). I don't know whether any OS cares about this or not, another thing to look into..
For the ch-a node, setting the 32-bit number to 1 would be right since it is only one port.
Is there an issue with strlen()? I thought it was a good idea because it makes the code more self-documenting, meaning you understand what the last argument expects.
It fails if you have null bytes in your string (as you would if you encoded the integer in it). Otherwise, yes, it's much clearer than using a constant.
Ok. When I remake the patch constants will be used.
I don't know. But I do know my G3 iMac's value for this property is this:
00000001 Modem
The PowerMac3,1 probably has the same value.
In any case, it makes sense as a value. (Does anyone have an OF dump from a PowerMac3,1?)
I was thinking about this and what Mark told me should definitely be applied. We are building a emulator as opposed to a simulator. A simulator will have almost all variables as close as possible to the real thing. With an emulator we are allowed to make changes as long as these changes work. So we may not need to know what the PowerMac3,1 has in its escc/ch-a node.
On Tue, Feb 09, 2016 at 10:28:48AM -0500, Programmingkid wrote:
You may be right. This code on Mac OS X does not allow the driver to work because of DMA issues. It is from the PPCSerialPort.cpp file.
You can add debug statements in qemu to the dbdma code (print reads or writes if channel isn't 0x16 nor 0x1a, they're the ATA channels); if I add DMA addresses and do this, the first attempted write I see is when I crash into MacsBug (and only if MacsBug is running). But that might just be because I'm crashing too early in my test runs, who knows..
For the ch-a node, setting the 32-bit number to 1 would be right since it is only one port.
I have honestly no idea what a slot is! I have the documentation for it open .. somewhere. So I'm just assuming/hoping that 1 makes sense.
- Alyssa
On Tue, 9 Feb 2016, Alyssa Milburn wrote:
On Tue, Feb 09, 2016 at 09:47:57AM -0500, Programmingkid wrote:
You can assign addresses for serial DMA and even OS 9 will try poking at the dbdma controller, so this is just a question of hooking up the qemu side. I can try doing this later today if it's useful..
It is definitely useful. The ability to run Mac OS 9 in QEMU depends on it.
After a few days spent poking through the startup process in MacsBug, I'm not sure this is true. But I'll hook it up later (if someone else doesn't do
Without knowing anything about the details I had the same feeling, considering that on real hardware there was a modem connected to that port so it may be looking for that modem. But I think we want to emulate a functional serial port but without the modem instead so we don't need to emulate the modem as well. Not sure what should it say for just a serial port. Maybe none or serial instead of modem.
I've mentioned this before here:
http://lists.nongnu.org/archive/html/qemu-ppc/2016-01/msg00467.html
In any case, it makes sense as a value. (Does anyone have an OF dump from a PowerMac3,1?)
I've sent this in the message above:
http://web.archive.org/web/20090107145016/http://penguinppc.org/historical/d....
I've also found these (from NetBSD and Linux appearently):
http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604134
Hope this helps.
Regards, BALATON Zoltan
On Tue, 9 Feb 2016, Programmingkid wrote:
I was thinking about this and what Mark told me should definitely be applied. We are building a emulator as opposed to a simulator. A simulator will have almost all variables as close as possible to the real thing. With an emulator we are allowed to make changes as long as these changes work. So we may not need to know what the PowerMac3,1 has in its escc/ch-a node.
Considering that you are trying to run Mac OS versions written by the same company that produced the hardware with only their hardware in mind, I would not be surprised if the code has some assumptions as it knows what to expect. So to run it you may need to make the emulation sufficiently close to real hardware. You might be able to get away with differences but it may be easier to just follow what's on the real hardware instead which is known to work with the software instead of finding out how Mac OS works without access to source and trying to make it run on some fictious hardware it was never intended to be running on. So I think knowing how the real hardware looks is definitely helpful in this case even if we don't want to make a one to one simulation of it.
In this case we should probably emulate the serial port close enough with DMA support as the OS seems to exepct that to work but we can probably get away by not emulating the modem connected to that port in the real hardware. But we'll see if the OS is happy if it can't find the modem.
Regards, BALATON Zoltan
On Tue, 9 Feb 2016, BALATON Zoltan wrote:
modem as well. Not sure what should it say for just a serial port. Maybe none or serial instead of modem.
What if you just put four zero bytes in slot-names? But you may still need working DMA added.
Regards, BALATON Zoltan
On 2016-Feb-9 11:45 , BALATON Zoltan wrote:
On Tue, 9 Feb 2016, BALATON Zoltan wrote:
modem as well. Not sure what should it say for just a serial port. Maybe none or serial instead of modem.
What if you just put four zero bytes in slot-names? But you may still need working DMA added.
I don't know if that works for Apple, but it shouldn't. From the PCI binding:
"slot-names" S prop-name, describes external labeling of add-in slots.
prop-encoded-array: An integer, encoded as with encode-int, followed by a list of strings, each encoded as with encode-string.
The integer portion of the property value is a bitmask of available slots; for each add-in slot on the bus, the bit corresponding to that slot's Device Number is set. The least-significant bit corresponds to Device Number 0, the next bit corresponds to Device Number 1, etc. The number of following strings is the same as the number of slots; the first string gives the label that is printed on the chassis for the slot with the smallest Device Number, and so on.
That is, the first four bytes are supposed to be an integer (in binary) indicating how many names follow, each name null-terminated. The usual case for this properly is that you see 0x00, 0x00, 0x00, 0x01, <string>, 0x00.
On Feb 9, 2016, at 11:52 AM, Tarl Neustaedter wrote:
On 2016-Feb-9 11:45 , BALATON Zoltan wrote:
On Tue, 9 Feb 2016, BALATON Zoltan wrote:
modem as well. Not sure what should it say for just a serial port. Maybe none or serial instead of modem.
What if you just put four zero bytes in slot-names? But you may still need working DMA added.
I don't know if that works for Apple, but it shouldn't. From the PCI binding:
"slot-names" S prop-name, describes external labeling of add-in slots.
prop-encoded-array: An integer, encoded as with encode-int, followed by a list of strings, each encoded as with encode-string.
The integer portion of the property value is a bitmask of available slots; for each add-in slot on the bus, the bit corresponding to that slot's Device Number is set. The least-significant bit corresponds to Device Number 0, the next bit corresponds to Device Number 1, etc. The number of following strings is the same as the number of slots; the first string gives the label that is printed on the chassis for the slot with the smallest Device Number, and so on.
That is, the first four bytes are supposed to be an integer (in binary) indicating how many names follow, each name null-terminated. The usual case for this properly is that you see 0x00, 0x00, 0x00, 0x01, <string>, 0x00.
So is this how it is suppose to be added to OpenBIOS:
1 encode-int " Modem" encode-string encode+ " slot-names" property
I tried my best to make it look like this:
00000001 Modem
but I just couldn't figure out how. The above code makes the value for slot-names into a bunch of unsightly hexadecimal values.
On 2016-Feb-9 13:56 , Programmingkid wrote:
That is, the first four bytes are supposed to be an integer (in binary) indicating how many names follow, each name null-terminated. The usual case for this properly is that you see 0x00, 0x00, 0x00, 0x01, <string>, 0x00.
So is this how it is suppose to be added to OpenBIOS:
1 encode-int " Modem" encode-string encode+ " slot-names" property
I tried my best to make it look like this:
00000001 Modem
but I just couldn't figure out how. The above code makes the value for slot-names into a bunch of unsightly hexadecimal values.
Since it's a mixed-type property (integer, followed by an array of strings), unsightly hexadecimal values are inevitable. Assuming Apple implements the property per the PCI binding, that is.
Under OpenBoot (Sun/Oracle's version of IEEE 1275), the slot-names properties would generally dump out into a hexadecimal array unless it was something which knew the specific format of slot-names. The general ".properties" didn't.
On Feb 9, 2016, at 2:06 PM, Tarl Neustaedter wrote:
On 2016-Feb-9 13:56 , Programmingkid wrote:
That is, the first four bytes are supposed to be an integer (in binary) indicating how many names follow, each name null-terminated. The usual case for this properly is that you see 0x00, 0x00, 0x00, 0x01, <string>, 0x00.
So is this how it is suppose to be added to OpenBIOS:
1 encode-int " Modem" encode-string encode+ " slot-names" property
I tried my best to make it look like this:
00000001 Modem
but I just couldn't figure out how. The above code makes the value for slot-names into a bunch of unsightly hexadecimal values.
Since it's a mixed-type property (integer, followed by an array of strings), unsightly hexadecimal values are inevitable. Assuming Apple implements the property per the PCI binding, that is.
Under OpenBoot (Sun/Oracle's version of IEEE 1275), the slot-names properties would generally dump out into a hexadecimal array unless it was something which knew the specific format of slot-names. The general ".properties" didn't.
I see now. You are saying the problem is with the .properties word. That makes sense. A version 2 of my patch will be made soon.
On 09/02/16 15:05, Alyssa Milburn wrote:
On Tue, Feb 09, 2016 at 09:47:57AM -0500, Programmingkid wrote:
You can assign addresses for serial DMA and even OS 9 will try poking at the dbdma controller, so this is just a question of hooking up the qemu side. I can try doing this later today if it's useful..
It is definitely useful. The ability to run Mac OS 9 in QEMU depends on it.
After a few days spent poking through the startup process in MacsBug, I'm not sure this is true. But I'll hook it up later (if someone else doesn't do it first).
Which version of OS X are you using for testing this?
Mac OS 10.2.8 is running as the guest.
Thanks, I'll see if I can go install 10.2 myself later too..
I don't know if your string would work, but you are right that the first four bytes are just skipped. So it doesn't really matter what they are.
The first four bytes are the slot bitmask (as a 32-bit BE integer), followed by one string per slot (so, one string for each set bit). I don't know whether any OS cares about this or not, another thing to look into..
Is the bitmask used to indicate the port presence? If so, could we get away with just setting it to zero, i.e. there are no ports here so don't try and access them? Other than that, do OSs check for specific values of the name string?
Is there an issue with strlen()? I thought it was a good idea because it makes the code more self-documenting, meaning you understand what the last argument expects.
It fails if you have null bytes in your string (as you would if you encoded the integer in it). Otherwise, yes, it's much clearer than using a constant.
I don't know. But I do know my G3 iMac's value for this property is this:
00000001 Modem
The PowerMac3,1 probably has the same value.
In any case, it makes sense as a value. (Does anyone have an OF dump from a PowerMac3,1?)
Thank you very much for reviewing my patch.
Thank you for the work!
- Alyssa
ATB,
Mark.
On 09/02/16 15:28, Programmingkid wrote:
On Feb 9, 2016, at 10:05 AM, Alyssa Milburn wrote:
On Tue, Feb 09, 2016 at 09:47:57AM -0500, Programmingkid wrote:
You can assign addresses for serial DMA and even OS 9 will try poking at the dbdma controller, so this is just a question of hooking up the qemu side. I can try doing this later today if it's useful..
It is definitely useful. The ability to run Mac OS 9 in QEMU depends on it.
After a few days spent poking through the startup process in MacsBug, I'm not sure this is true. But I'll hook it up later (if someone else doesn't do it first).
You may be right. This code on Mac OS X does not allow the driver to work because of DMA issues. It is from the PPCSerialPort.cpp file.
// Calls the DMA function that knows how to // handle all the different hardware: SccSetDMARegisters(&Port, provider); if ((Port.TxDBDMAChannel.dmaChannelAddress == NULL) || (Port.TxDBDMAChannel.dmaBase == NULL) || (Port.RxDBDMAChannel.dmaChannelAddress == NULL) || (Port.RxDBDMAChannel.dmaBase == NULL)) return false;
From memory, we got away with just not having the DBDMA properties
present in the reg property when booting OS X for this reason: if they are empty then they are simply ignored. Obviously OS 9 has slightly different ideas here ;)
ATB,
Mark.
On Thu, 11 Feb 2016, Mark Cave-Ayland wrote:
On 09/02/16 15:05, Alyssa Milburn wrote:
The first four bytes are the slot bitmask (as a 32-bit BE integer), followed by one string per slot (so, one string for each set bit). I don't know whether any OS cares about this or not, another thing to look into..
Is the bitmask used to indicate the port presence? If so, could we get away with just setting it to zero, i.e. there are no ports here so don't try and access them? Other than that, do OSs check for specific values of the name string?
That's what I was suggesting too and this device tree seems to support this (it has slot-names property with just 00000000 for both channels):
http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt
Setting the property to indicate we have a modem connected which we don't emulate may be looking for trouble if the OS is trying to access that but I'm not sure if Mac OS looks at the property or just assumes what's on the real machine. It may still look for external modems and use DMA to do serial transfers though.
Regards, BALATON Zoltan
On Feb 11, 2016, at 3:22 AM, Mark Cave-Ayland wrote:
On 09/02/16 15:05, Alyssa Milburn wrote:
On Tue, Feb 09, 2016 at 09:47:57AM -0500, Programmingkid wrote:
You can assign addresses for serial DMA and even OS 9 will try poking at the dbdma controller, so this is just a question of hooking up the qemu side. I can try doing this later today if it's useful..
It is definitely useful. The ability to run Mac OS 9 in QEMU depends on it.
After a few days spent poking through the startup process in MacsBug, I'm not sure this is true. But I'll hook it up later (if someone else doesn't do it first).
Which version of OS X are you using for testing this?
Mac OS 10.2.8 is running as the guest.
Thanks, I'll see if I can go install 10.2 myself later too..
I don't know if your string would work, but you are right that the first four bytes are just skipped. So it doesn't really matter what they are.
The first four bytes are the slot bitmask (as a 32-bit BE integer), followed by one string per slot (so, one string for each set bit). I don't know whether any OS cares about this or not, another thing to look into..
Is the bitmask used to indicate the port presence? If so, could we get away with just setting it to zero, i.e. there are no ports here so don't try and access them? Other than that, do OSs check for specific values of the name string?
It would appear not. At least not for Mac OS X. I don't know about Linux, *BSD, or Mac OS 9.
On Feb 11, 2016, at 3:24 AM, Mark Cave-Ayland wrote:
On 09/02/16 15:28, Programmingkid wrote:
On Feb 9, 2016, at 10:05 AM, Alyssa Milburn wrote:
On Tue, Feb 09, 2016 at 09:47:57AM -0500, Programmingkid wrote:
You can assign addresses for serial DMA and even OS 9 will try poking at the dbdma controller, so this is just a question of hooking up the qemu side. I can try doing this later today if it's useful..
It is definitely useful. The ability to run Mac OS 9 in QEMU depends on it.
After a few days spent poking through the startup process in MacsBug, I'm not sure this is true. But I'll hook it up later (if someone else doesn't do it first).
You may be right. This code on Mac OS X does not allow the driver to work because of DMA issues. It is from the PPCSerialPort.cpp file.
// Calls the DMA function that knows how to // handle all the different hardware: SccSetDMARegisters(&Port, provider); if ((Port.TxDBDMAChannel.dmaChannelAddress == NULL) || (Port.TxDBDMAChannel.dmaBase == NULL) || (Port.RxDBDMAChannel.dmaChannelAddress == NULL) || (Port.RxDBDMAChannel.dmaBase == NULL)) return false;
From memory, we got away with just not having the DBDMA properties present in the reg property when booting OS X for this reason: if they are empty then they are simply ignored. Obviously OS 9 has slightly different ideas here ;)
Definitely. I'm hoping we can fix this problem and hope it helps Mac OS 9 as well.
On Feb 9, 2016, at 11:16 AM, BALATON Zoltan wrote:
On Tue, 9 Feb 2016, Programmingkid wrote:
I was thinking about this and what Mark told me should definitely be applied. We are building a emulator as opposed to a simulator. A simulator will have almost all variables as close as possible to the real thing. With an emulator we are allowed to make changes as long as these changes work. So we may not need to know what the PowerMac3,1 has in its escc/ch-a node.
Considering that you are trying to run Mac OS versions written by the same company that produced the hardware with only their hardware in mind, I would not be surprised if the code has some assumptions as it knows what to expect. So to run it you may need to make the emulation sufficiently close to real hardware. You might be able to get away with differences but it may be easier to just follow what's on the real hardware instead which is known to work with the software instead of finding out how Mac OS works without access to source and trying to make it run on some fictious hardware it was never intended to be running on. So I think knowing how the real hardware looks is definitely helpful in this case even if we don't want to make a one to one simulation of it.
In this case we should probably emulate the serial port close enough with DMA support as the OS seems to exepct that to work but we can probably get away by not emulating the modem connected to that port in the real hardware. But we'll see if the OS is happy if it can't find the modem.
If it does turn out we need modem support in QEMU, emulating enough of a hayes compatible modem to fool Mac OS 9 into thinking it is real might not be too hard to do.
-
Alyssa Milburn -
BALATON Zoltan -
Hervé Poussineau -
Mark Cave-Ayland -
Programmingkid -
Tarl Neustaedter