Print

[rayarachelian]

Found something while looking for the ProFile behavior in the other thread:

From: https://apple3.org/Documents/Manuals/Profile_Level_2_Manual.pdf page 157:

"CRES - generated by the host - this is used to reset the Z8 back to its initial state. This usually begins at the start of communications, but whenever it happens, it depends on the host."

So there's also an output on the VIA outside the RESET signal that can trigger CRES, but CRES isn't used to reset the ProFile, it's to put the communications state machine back to the first listening state.

This implies there's no need for timeouts because the Lisa can pulse CRES any time to push the state machine back to the idle state.

[stepleton]

This implies there's no need for timeouts because the Lisa can pulse CRES any time to push the state machine back to the idle state.

This is true. Unfortunately, I forgot to make any electrical connection at all between the reset line and the PocketBeagle single-board computer, so I can't use this facility. The only workaround for me is absolutely excellent code that will never get stuck anywhere.

I've made a lot of progress on my "infinite timeout" revision, which is a pretty big change, but which I hope can withstand all kinds of interrupts and delays on the Lisa side (especially from MacWorks). I tried it out last night for the first time, and while it works OK for a first run after a major change, it is obviously still not "absolutely excellent" and can get hung up in at least one spot. The work continues.

[rayarachelian]

You're probably never going to get every weird uncommon edge case, so don't worry too much about it. If you get compatibility with the most common cases, i.e. boot blocks loading boot loaders, and most of LOS, MacWorks, UniPlus/Xenix OS's working it should be good enough. The only way to get 100% compatibility is to emulate the z8 ROM on either a real ProFile or Widget, but that will also cause problems: limits on disk size, limits on how fast you can go.

It's better to have a device that runs much faster than the original and doesn't have limits, IMO. Worst case, if it even comes to that, you can provide patches for the drivers of those OSs like James MacPhail did for the X/ProFile.

But yeah, the big issue is that the 8530 doesn't have much buffer space for incoming chars so it could drop data if the IRQ isn't serviced in time. Which isn't that big of a deal really. If you're running on LocalTalk, it will eventually retransmit the packet. If you're in the middle of an X/Y/Zmodem transfer, it will retransmit. If you're just connected to a BBS and miss some incoming text, oh well, pick a lower bps rate, or use another terminal.

Hope I'm not being insensitive here, but between dropping bytes on a serial port or causing file system damage or OS crashes, I'd rather avoid the file system damage and OS crashes.

[stepleton]

I think I've got the fix done now, and the problem was a bit obvious. You can't get rid of all the timeouts --- if you are willing to wait forever with the ~PBSY (meaning "I'm working, don't bother me") line asserted, then if you get stuck there, Lisa software will usually leave you alone, and you'll stay stuck. If you're holding ~PBSY, you need a timeout to let it go, in other words.

The difference this time is that the "control" coprocessor PRU1 used to be able to wait on the "data pump" coprocessor PRU0 to timeout on transactions that expected to transfer a byte when ~PBSY was low. Now, for the benefit of MacWorks, PRU0 is no longer in the timeout business at all. PRU1 has to take care of those timeouts itself.

Works now with MacWorks Plus, LOS 3.0, and Xenix. I'll update GitHub and compile a new drive image soon.

I was thrown off a bit when testing with MacWorks Plus 1.1h --- I was still seeing boot failures with the Cameo/Aphid installed on the lower port of a parallel port card. Ultimately this may be a problem with MacWorks Plus, since it fails in the same way for an IDEfile. I haven't tried a real Profile yet to compare, and probably won't

[stepleton]

A small note for anyone interested that the new code continues to work for me. I don't have my own LocalTalk network set up (though I do have the adaptor for the Lisa end --- and none for any other computer). I haven't tried really any applications, just installation of MW+ 1.1h, which is at least a bit of a workout. LOS 1.0 has now been tried as well.

This is still the biggest low-level firmware update since the initial release in 2018, and it should probably be considered even slightly more beta than usual

GitHub is up to date, and an updated version of the Debian 10.0-based microSD card image is available.

[rayarachelian]

Yeay!

[rayarachelian]

As an aside, incase you want to make your own Phone Net connectors (RJ11) there's a schematic in glorious ASCII here: http://www.nic.funet.fi/index/mac/doc/phone-net-connectors.txt

This is a snippet of that:

Code: [Select]


 
A "O" means a connection
 
PIN NUMBERS ARE FOR MAC DB-9.
NUMBERS IN () ARE FOR MINI DIN 8 (MAC PLUS)
 
          CapNet Connector  (last update 8/21/90)
 
 J1                                                  J2
       9 (5)                               C1 .1 uF
RCV(-) ----------------------------O----------][------O
                                   !
       8 (                       !       C2 .1 uF
RCV(+) --------------------------------O------][------O
                                   !   !            ^
                                   !   !           TO
       5 (3)                10 ohm !   !         "PHONE"
TX(-)  -----------O-----------R3----   !          LINES
                  !                    !
       4 (6)      !         10 ohm     !
TX(+)  -----------------O-----R4--------
                  !     !
             1K   R     R  1K
                  1     2
                  !     !
       3 (4)      !     !
GND    -----------O------
 
 
PARTS LIST:
 
QTY    DES      ITEM
2    R1,2      1K 1/8W RESISTORS
2    R3,4      10 OHM 1/8W RESISTORS
2    C1,2      .1 uF THREE LAYER CERAMIC CAPS
1    J1        DB-9 MALE OR MINI DIN 8 CONNECTOR
1    J2        2 PIN BERG OR RJ-11 PHONE CONNECTOR
5    WIRE      (NOT SHOWN) 22 GAUGE STRANDED WIRE 6"
 
 
NOTES:
 
C1,2 can be disk type but ceramic is more stable.
The entire unit can be mounted on a 1" X 1" .100 ctr
bread board or smaller. No printed circuit is needed.
Connect all componets lead to lead and connect cable
wires to leads on bottom of board.
Use heat shrink tubing over entire board as a cover
or dip in RTV sealer or put in a old 35MM film case.
 

In the case of the Lisa, since the Mac is RS422, you'd tie TX- and RX- together to data ground on the 25 pin side.

There's a bigger discussion here: https://mac68k.info/forums/message.jspa?messageID=1141

[stepleton]

This weekend's Cameo/Aphid improvements 

• The "Selector" program that lets you select and manage hard drive images is itself loaded from a hard drive image, and I found it was too easy to overwrite it with (for example) a fresh install of the Office System. You can copy a fresh Selector hard drive image onto the Cameo/Aphid SD card with a modern computer, of course, but that's a hassle. Well, now you can also type a 20-byte program into Service Mode (note influence of the BLU manual here) and that will restore a Selector drive image for you, too.
• You can now create drive image files in five different sizes in the Selector.
• The Selector now shows you how big drive images are.
• Some minor bugs are fixed.

I hope these updates aren't annoying --- this project has been a lot of fun to work on and I'm excited to share progress. There are just a couple more features to add at this point before I think it's at 1.0. I haven't made a microSD card image with these changes yet, but I will before too long.

[rayarachelian]

The "Selector" program that lets you select and manage hard drive images is itself loaded from a hard drive image, and I found it was too easy to overwrite it with (for example) a fresh install of the Office System.

You could also add a read-only flag to an image to prevent writes. So the on the first write attempt it could switch to a default sized blank image with a specific flag?

And also another flag could be the concept of a stationary image, where it starts off as a read only image, say a golden LOS 3.1 install, and the first time it's written to, it gets cloned to a new image, and then subsequent block writes go to that one (now without the stationary flag). That way you could roll back images, or run various experiments, etc.

Hmm, it sounds like when you boot off a floppy the default is to have the selector image up, which makes sense, but then when it starts to format, perhaps that behavior could be detected and it could switch to a new blank image of a default size instead and then that could be named generically until the user changes its name? Or perhaps its boot sector/loader blocks written to the first blocks could be hashed and the hash used to select a name for the image.

If the Beagleboard has an RTC, perhaps the new image could be named with the date as well.
Don't mind me, just thinking outloud, really neat stuff so far! Many thanks!

[stepleton]

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.)

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...)

Unfortunately there's no RTC on a PocketBeagle --- on those devices, unless you connect them to the internet somehow (or maybe just to another computer), it's always 2019 (or whenever the kernel was built).

[rayarachelian]

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.)

Um, just wait a while.

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...)

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]

Does anyone know how slow a hard drive has to be in order for Xenix to work?

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: [Select]

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)


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