General Category > LisaList2
MacWorks XL ROM serial drivers
rayarachelian:
Meta: Yeah, I know you guys know, I just wanted to clarify this for future visitors who don't have our background about MacWorks who may mistakenly take away that the Mac toolbox ROM is part of the Lisa's hardware. :) Part of my goals for posts on this forum is to provide a reference guide for future folks who've never seen a Lisa but are interested in it, and another part is to harvest these posts for future LisaFAQ updates. In 20-40 years from now the pool of people who own an actual working Lisa will be very tiny, though perhaps replicas will be possible.
D.Finni:
--- Quote from: sigma7 on May 13, 2020, 06:48:22 pm ---
It would certainly be nice if your software could compensate for the PFG when using a non MW+II environment. I think this would be relatively straightforward in that you would need to directly access the hardware to determine if the PFG is there, and over-ride the baud rate generator time constant accordingly (by writing your own value after the SERD sets it). Let me know if you'd like me to document how to do this. (In the meantime, probably wise to get it working without the PFG first rather than waiting for me.)
--- End quote ---
If you can tell me how to detect the PFG, I think I can work out the rest. I already know how to access the SCC directly.
By the way, I wonder if baud rate is the problem. I'm configuring the Modem port for 57600 baud. Is that too much for the Mac XL to handle?
sigma7:
--- Quote ---57600 baud. Is that too much for the Mac XL to handle?
--- End quote ---
Not inherently, but it depends.
AppleTalk/LocalTalk, for example, is about 230k baud. The stock Mac XL was able to handle this well up to ATP v52 (IIRC, maybe some other version. "ATP " is the AppleTalk Transfer Protocol DRVR), but at ~v57 (or...?), features were added to the packet protocol that made the handler too slow in some cases.
This was quite obvious when attempting to use System 7 file sharing: The stock XL worked fine as a client but could not serve files at all. If an XLerator was added, it could serve files fine.
In some tests, replacing the 8530 SCC with the 85230 ESCC (the difference being that the ESCC has a 5 byte receive buffer, two more than the SCC) seemed to also fix the issue (without the XLerator), but I've heard from Rick that his tests didn't show the same result, so it may be dependent on other machines and software versions, or it might be an outright fallacy that I have unintentionally propagated.
The way ATP works (as far as I can tell/recall/imagine), is to detect the start of a frame and then mask all interrupts while the whole data portion of the frame is collected in a dedicated timing sensitive polling loop.
If you design your software such that it knows when to pay full attention to receiving data, then 57600 is likely to be fine. If you are calculating a CRC or something, it will need to be efficient, or done after the data packet is received. (This was an issue with BLU receiving XModem-CRC at high rates.)
If software were to rely on interrupts to collect all the data at 57600, then I would suspect there could be issues depending on what else was happening on the XL. Perhaps it would work fine if nothing else were happening, but I suppose it depends on what one does with the data when/after receiving it.
Probably not the issue you are having, but note the stock XL's nominal baud rate of 57600 has an error about 0.8% (at an actual baud rate of 57143). The lower baud rates don't have such large errors. For more info, see post 3 of Serial A Baud Rate correction when PFG installed but NOT using MacWorks Plus II.
Edit: (I note that my memory is no longer very reliable, so verify)
D.Finni:
What I'm doing now is to give the serial driver a large buffer on the order of 1,000 bytes using SerSetBuf. I'm also making a call as part of my initialization to disable hardware and software flow control.
Then in my application's main event loop, I just poll the serial driver with a _Control call to SerGetBuf. If SerGetBuf reports any unread bytes in the buffer, I then issue a _Read to copy the data into my application's buffer for processing.
All this works well enough on a conventional Macintosh, though my intent is to refactor the code to be completely interrupt-driven using async IO, a VBL task, and a completion routine.
So I'm scratching my head on why the same working application acts like a deaf-mute on the Mac XL with MacWorks Plus. It doesn't flag any errors, it doesn't crash... It just hears nothing and speaks nothing.
The only variables I can think of to test which may be affecting things are:
- handshaking?
- Modem vs Printer port?
- baud?
But maybe there's something else that's at fault.
stepleton:
Silly question, but do you know your serial ports to be in working condition on your XL? We've had one person here in the past month or so find that their Serial B port did not work, and mine also was inoperative until I replaced one of the ICs on the I/O board.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version