General Category > LisaList2

Cameo/Aphid selector

<< < (4/9) > >>

stepleton:
The upper parallel port boot bug is now fixed!

I was halfway through writing my shared memory prober when a friend who is much better at mental boolean arithmetic pinged me for a video call. I told him the story of my woes and showed him some traces, and he cleverly determined that my code was too picky!

There's a part of the Cameo/Aphid state machine that was waiting for the ~PCMD signal line to be high and the PR/~W signal line to be low. It turns out that valid ProFile transactions usually lower PR/~W before raising ~PCMD, so this change here:

https://github.com/stepleton/cameo/commit/b6bed36619bc3c256e727477c11d96acbedbc3a7

abandons the transaction if it sees ~PCMD go high when PR/~W is already high. Previously the software was just waiting for PR/~W to go low eventually, and in those random wiggles observed during the parallel card's initialisation routine, that can't be relied on to happen, so it was a long wait ending in a timeout (during which the emulator was unusable). The fact that the bug didn't affect the lower port is probably down to minor differences in signal propagation --- in other words, we got lucky there.

There's a chance that some Lisa OSs are sloppy about the order in which they change ~PCMD and PR/~W, which would mean this change makes Cameo/Aphid newly incompatible. Fortunately, the workaround is pretty simple: rather than give up immediately if PR/~W is high, just delay for a little bit to give it a chance to come down. I'll try some more testing tomorrow, but I have a good feeling. If things look good, I'll prepare a new microSD card image to replace what's found on the current release.

Ultimately, it was a software bug all along. I'm very glad that no revisions to the hardware are necessary!

rayarachelian:

--- Quote from: stepleton on January 22, 2021, 08:55:00 pm ---The upper parallel port boot bug is now fixed!

--- End quote ---

Congrats and well done! :)

stepleton:
Hi again. I'm happy to find that the latest system software for Cameo/Aphid (available now) has shortened boot time to under 27 seconds. This is a long time for a hard drive emulator (IDEfile and X/ProFile are both ready in only a couple seconds), but the critical thing is that it's short enough that if the Lisa and the emulator turn on at the same time, Cameo/Aphid is ready soon enough that the boot ROM can boot from it instead of timing out.

What this means is that if you make a little adaptor that converts from the Widget power supply connector to an ordinary USB Micro-B plug, you can throw a Cameo/Aphid into a Lisa 2/10 drive bay and it should just work.

Now, I still have to make this adaptor for myself (it's easy if you have the connector for the Widget power plug---just hack up an ordinary USB "charging cable"), but I have simulated the setup by turning the Lisa and the emulator on together. To keep myself honest, I gave the Lisa a 3-second head start, and it still worked. I'll probably try to make the cable tomorrow, and if it makes a monkey out of me, I'll let you know. Otherwise, please assume it worked :)


"Fast-enough" startup was the last of the big features I wanted to add in order to make Cameo/Aphid useful to me. There are a few more items to add before I actually stop this round of developing Cameo/Aphid and just start using it:

* ProFile-10 emulation. This should be pretty easy to do and only requires changes on the Python side. Now, I don't think I'm likely to try emulating the Widget anytime soon: the much larger Widget command set would take a lot of time to implement, and the multi-block Widget reads and writes in particular would require expanding the state machine in my low-level firmware. I hope that the Lisa OSs don't care that I've somehow managed to fit a ProFile-10 into the drive cage of my 2/10.


* Slow mode. I'd like to make the emulator add a delay to reads and writes whenever it detects that it's working with a drive image file whose name ends in ".slow.image". This is for Xenix (and maybe also UniPlus?), which expects reads and writes to take at least a certain amount of time. Patches exist to make these OSs more tolerant of fast drives, but you know authenticity is very important for me when I'm using a hard drive emulator with 500x the memory, 200x the clock speed, and 6400x the durable storage of the Lisa. Anyway, this is an easy Python change, too.Does anyone know how slow a hard drive has to be in order for Xenix to work?

rayarachelian:

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

2. time an actual ProFile or Widget drive by reading from it. You could attach a scope to the ProFile while you use BLU to do a dump, or boot an OS and run tar to /dev/null or dd to /dev/null, and see how fast the data streams through between sectors.

3. estimate. Likely the rotational speed between two consecutive sectors is what they're after, and not track seek time. I think they're 3600 or so RPM, likely the Widget ERD has that info also.

a. Maybe divide the RPMs (3600) by number of sectors per track, this gives 57, so you're looking at reading 57 sectors/minute, so somewhat less than 1 sector/second.
I don't know if this applies to the ProFile, but the ST506 when MFM formatted used 63 sectors per track.
Now it's possible to not read sequentially, but instead read in parallel across the heads (I think the ST506 might have had 8 heads, but not sure), so perhaps start with a multiple of 1sector/sec upto maybe 8 or 16 and then slow down from that until it starts to work.

b. Another way to measure: off the top of my head it takes about 30mins or so to transfer a whole ProFile over BLU, I may be off here, but that could be used to divide the number of sectors by that time, however, the question is, is 57.6kbps the limit or the parallel interface? Likely the serial port is the bottle neck, so that's not going to be a great estimate, but it could be a starting point, and then ratchet up from there.

This would be 9728 sectors / ( 30mins*60s)=5.4 sectors/sec?

So that's quite the range from ~1sector/second to 5.4, so the math here is off here somewhere, but yeah, it's a start.

One thought, perhaps it might be best to not have to force the user to rename the hard drive ahead of time - you could detect their presence of UniPlus or Xenix it by reading the boot block, and then, if it's Xenix, figure out where the speed patch gets carried to onto the ProFile hard drive, and detect if it's been patched or not, and adjust the speed accordingly - likely it's in a fixed place after it's installed (possibly the boot loader, and certainly the "xenix" kernel file) and use that value to decide whether or not you should slow down the interface.

X/ProFile doesn't requires patching UniPlus for speed, only Xenix, so likely that's the more sensitive of the two, so you could go at least as fast as the X/ProFile for UniPlus and only slow down if unpatched needed for Xenix, unless your device is significantly faster than the X/ProFile, if in which case: Woo Hoo!

compu_85:
This is just anecdotal, but both Xenix and UniPlus work fine from a 200mb conner IDE drive I use with an IDEFile. I don't know how much faster this is than a Widget - but it is a noticeable improvement.

Navigation

[0] Message Index

[#] Next page

[*] Previous page