General Category > LisaList2
Cameo/Aphid selector
rayarachelian:
--- Quote from: stepleton on February 28, 2021, 07:34:56 pm ---That's a bunch of interesting ideas --- the copy-on-write idea sounds practical! One thing I want to be the case though is that people who don't care about the Selector, particularly Apple II and Apple III users, but also Lisa users who just want a plug-and-play ProFile replacement, don't have to take any special steps to deal with it. (It's not like there are more Cameo/Aphids in the world than can be counted on two hands, but I like to pretend.)
--- End quote ---
Um, just wait a while. :)
--- Quote from: stepleton on February 28, 2021, 07:34:56 pm ---Talking of other Apples, I would love to know if my device would work with an Apple that isn't a Lisa. I have high hopes, but there's no substitute for testing. Maybe post-pandemic I can find someone suitably-equipped nearby who would let me try it out. (There isn't much room for more computers here, unfortunately, and they're not exactly handing out Apple IIIs these days...)
--- End quote ---
Yeah, from what I know it was available on the ]['s with a rather expensive, somewhat rare card, and also on ///'s. Perhaps it would be possible to modify an emulator for an Apple /// to get an external DB25 parallel port, not sure how you'd go about that, but, maybe there's a way.
Ofc the real issue is there's no way from the point of view of the Cameo/Aphid to tell what it is you're talking to, so it would have to be setup by the user on the SD card.
And who knows maybe owners of ///'s and ]['s (and possibly IIgs?) with the proper card would also like a selector menu to boot from so they can use multiple hard drives, never know. Perhaps someone will make replicas of those cards again.
Just had a thought, another thing you could do is flag the boot drive as having a full spare table and keep the size tiny - to whatever the size of the selector is. So if something attempts to write it, they'll see an invalid drive or a drive that has all the spare sectors filled and should refuse to install on it - instead of a standard 5MB or 10MB drive that does a replace on write or copy on write. So that might be another alternative strategy.
Though between the two personally I'd prefer the copy on write one. :)
sigma7:
--- Quote from: rayarachelian on February 02, 2021, 11:11:08 pm ---
--- Quote from: stepleton on February 02, 2021, 09:04:05 pm ---Does anyone know how slow a hard drive has to be in order for Xenix to work?
--- End quote ---
I don't, but there's two ways you could find out:
1. look at what change the patch for Xenix does and what the previous code expects.
from: http://sigmasevensystems.com/xpf_xenix.html
--- Code: ---c) To assert CMD after BSY interrupt is enabled and accept fast response
Sectors: $22 (#34), $CF (#207), $183 (#387)
Search: 0200 0002 0C00 0002 6680
Replace: 4E71 08EB 0004 0001 6080 (change 9 bytes)
--- End code ---
--- End quote ---
For posterity:
IIRC, the Xenix "A ProFile can't be so fast" limitation is in how quickly the ProFile asserts BSY once it sees CMD has been asserted.
(ie. all in the controller, not related to how fast the media is)
patrick:
Correct. To quote myself from the IDEfile FAQ:
http://john.ccac.rwth-aachen.de:8000/patrick/IDEfaq.htm#oses
"The ProFile driver of Lisa Xenix 3.0 has a bug that may cause handshake errors when used with a device that is significantly faster than the original ProFile: it asserts -PCMD before enabling the interrupt that should be triggered by the falling edge of -PBSY! If the drive is fast enough and has already set -PBSY in the meantime, this falling edge will never be detected, resulting in a timeout or a hanging Lisa."
stepleton:
Thanks for the background on this --- it makes the problem a lot easier to understand. It looks like it's past time for me to make another pass through all the FAQs and other accumulated wisdom out there.
Adding a delay to my gizmo to account for this problem is possible (well, anything is possible, I guess) but annoying, since it requires modifying the firmware that runs on the single-board computer's I/O coprocessors. But another thing that scared me off for now was the remark on the X/ProFile Xenix modification page talking about some commands being sent as just four bytes. It's another thing I could probably deal with, but these two bugs together certainly made the already-extant patch seem like a great option to use instead :)
Navigation
[0] Message Index
[*] Previous page
Go to full version