General Category > LisaList2

Cameo/Aphid selector

<< < (6/9) > >>

rayarachelian:

--- Quote from: stepleton on February 07, 2021, 08:44:11 pm ---It miiiiiiight be the case that my firmware is timing out too soon waiting for MacWorks to toggle the ~PSTRB line during reads and writes (e.g. here). If I had to guess, I'd say that MacWorks is more aggressive than some other operating environments about servicing interrupts while it's sending bytes to and from the drive.

--- End quote ---

Certainly possible.


--- Quote from: stepleton on February 07, 2021, 08:44:11 pm ---If this hypothesis is right, then when my code gave up on ~PSTRB, it would stop sending bytes, but MacWorks would keep reading from the parallel port data lines. The nonsense values it would read would then have been what caused such a variety of trouble, especially if the values were code that it would then go on to try to execute.

Bumping up the amount of time my code waits on PSTRB seems to improve the stability of MacWorks Plus 1.1 quite a bit.

I'm not certain it's 100% fixed yet, but I think I've made progress.

--- End quote ---

That's great news, you're at least getting closer to a working solution.

So, I don't use the PSTRB line at all, AFAIK, it's automatically driven via CB1 (or CB2?) as writes are sent through ORA. Or rather, I should say my code doesn't depend on it in any way, but the effect is the same.

If writes are made to ORANH, PSTRB is not pulsed and the value just shows up on PA0-7 (assuming DDR=255 and RRW=write). However, from the point of view of the emulator, while its pulses are ignored, each write is handled like an event, instead, so there's no duplication, etc. Not sure it matters or not. You could disassemble the VIA 2 ISR and see what it does in detail and if there are any writes to ORANH (I think that's register 15 instead of 0 or something like that).

Most likely the VIA 2 ISR is just going to set a flag that the profile driver will pick up and act on instead of being used to transfer data.

But unless they've done some weird things manually - which could be, basically it should be pulsed once with each write to ORA.

Hmmm, I think perhaps one early change in LisaEm post 1.0 was to decouple the CPU clock from the rest of the system, including the VIAs. I wonder if it was working with MacWorks because it was pinned at 5MHz? It doesn't matter at all for LOS, but perhaps there's something in MW that depends on those having the same timings.

I do decouple the MHz rate for the CPU from the T1/T2 timers (as well as the clock in the COPS), perhaps that's an issue. But then how does the XLerator work? Hmm, maybe it does some modifications to that code as well.

You could (should?) use PSTRB as a clock input to drive reading bytes from the Lisa to the Aphid's buffers? But I'm not sure if the rest of handshaking uses it or not, if any of it doesn't that probably wouldn't work well. i.e. the 55 and other handshaking values, i.e. any code reading from IRANH or writing to ORANH.

I do recall the LOS ProFile code doing some writes to ORANH here and there, but not sure if MW does the same or not. I'm pretty sure it's when they're first talking to each other around the 01/02/55 handshaking stuff, but I think it's meant to leave the port with that value and reset the state machine.

It may well be that if MacWorks is busy with something else, while a transfer is in progress that it would stop in the middle of sending bytes out for some time frame while it handles some other devices, such as the floppy or the serial port, etc. and if you time out waiting for PSTRB too early, you'd fall out of sync with it. So maybe increase that time to a lot longer. Maybe something ridiculous like 1s and then do a binary search dropping it lower by 1/2 until you see errors again and then back off a bit.

stepleton:

--- Quote ---You could (should?) use PSTRB as a clock input to drive reading bytes from the Lisa to the Aphid's buffers? But I'm not sure if the rest of handshaking uses it or not, if any of it doesn't that probably wouldn't work well. i.e. the 55 and other handshaking values, i.e. any code reading from IRANH or writing to ORANH.
--- End quote ---

Yes, ~PSTRB is the only clock there is when the Apple wants to read or write more than one byte. It's not really negotiable. But...


--- Quote ---I do recall the LOS ProFile code doing some writes to ORANH here and there
--- End quote ---

It sure does. This was the one bug I had in the first test of the Cameo/Aphid stack. I'm actually pretty proud of this --- when I first made Cameo/Aphid, I thought very hard about the software and hardware, and I checked, and double checked, and triple checked, and... to my delight, when I tried it for the very first time with my UsbWidEx, it just worked! That's my memory anyway; in real life I wouldn't be surprised if there were a few software hiccups that I just hadn't remembered. Nothing complicated though, what joy!

Unfortunately things weren't quite so rosy when I tried it with the Lisa (neither the boot ROM nor the Office System), and my mistaken assumption can be understood when you look at Dr. Schaefer's very handy logic analyser traces. Note all the places where it says "answers with $55" --- you don't see PSTRB there! I think I had missed this (so much for triple-checking!) and my recollection is that UsbWidEx does toggle PSTRB in those settings, which is what allowed it to work.

I'm not sure how dependable my memory really is here, but I do remember being annoyed by not having ~PSTRB on $55 for a silly reason. The TI AM3358 ARM-based SOC that powers the PocketBeagle single-board computer (and therefore Cameo/Aphid) is neat because it has two real-time I/O coprocessors called PRUs --- nifty, simple little RISC chips with very predictable timing. I had it all set up where only PRU0 would touch the data lines (and ~PSTRB and ~PPARITY) and only PRU1 would touch the handshaking lines PR/~W, ~PCMD, and ~PBSY. A handsome plan, but PRU0's code is driven by ~PSTRB, and if you don't ~PSTRB, well... that means PRU0 can't load $55 for you and PRU1 has to snoop the data lines to catch that $55 for itself. Oh well.

Cool story. Anyway, now what?


--- Quote ---It may well be that if MacWorks is busy with something else, while a transfer is in progress that it would stop in the middle of sending bytes out for some time frame while it handles some other devices, such as the floppy or the serial port, etc. and if you time out waiting for PSTRB too early, you'd fall out of sync with it. So maybe increase that time to a lot longer. Maybe something ridiculous like 1s and then do a binary search dropping it lower by 1/2 until you see errors again and then back off a bit.
--- End quote ---

Contemplating the way the original ProFile is designed, and how it basically allows the Lisa to clock data in and out of the on-controller RAM at its own leisure, it seems like the correct timeout is... forever. I think most OSs are a bit more impatient than that, and even with MacWorks I could probably just bump up the timeout and call it a day, although you never know if someone's weird "helper" system modification or extension will grab an interrupt sometime and go to the circus for a few seconds. Maybe this is the kind of mischief that LocalTalk could get up to.

Maybe I will just bump up the timeout at first. But, given that I already have PRU0 set up to clock data in and out independently of most of the handshaking, it doesn't seem impossible to make it support an infinite timeout, so long as I have a way to interrupt it if it's time to move different data or move it in a different direction. I'll have to think about it a bit more.

rayarachelian:

--- Quote from: stepleton on February 08, 2021, 08:58:51 pm ---A handsome plan, but PRU0's code is driven by ~PSTRB, and if you don't ~PSTRB, well... that means PRU0 can't load $55 for you and PRU1 has to snoop the data lines to catch that $55 for itself. Oh well.

Cool story. Anyway, now what?

--- End quote ---

Yeah, exactly, you have to work around it, as you have. Fun times!


--- Quote from: stepleton on February 08, 2021, 08:58:51 pm --- Maybe this is the kind of mischief that LocalTalk could get up to.

--- End quote ---

Indeed as it has the highest IRQ and could be tied up for quite some time depending on what data storm the network has going on.

I'd imagine "reasonable" timeouts would be on an order of 1-5s, but... that's pretty long.

Might be worth looking through these to see what the Widget does with the timeouts if you understand z80 assembly and can figure out the timings: http://bitsavers.org/pdf/apple/disk/widget/firmware/code/

stepleton:

--- Quote ---Indeed as it has the highest IRQ and could be tied up for quite some time depending on what data storm the network has going on.
--- End quote ---

Oh, thanks, that's a good warning. I think I'll go straight ahead then to try and implement "infinite timeouts" (with interruptability, of course). I've actually already begun and it seems to be making some of the code simpler so far --- that's nice of course, but often beautiful code in your mind turns out not to be suitable. We'll see what it's like when I finish.


--- Quote ---Might be worth looking through these to see what the Widget does with the timeouts
--- End quote ---

I've actually been looking at Dr. Schaefer's ProFile ROM disassemblies instead (also on Bitsavers), and you don't really need to speak Z8 very well for that --- he's left excellent comments as usual (thanks!). Thing is, though, this firmware tells you very little about timeouts for moving bytes over the parallel port, since it doesn't do that at all: all that the MCU does is move block data to and from the controller board RAM, and then the other hardware in the controller DMAs it out over the line on its own. I would expect that this hardware doesn't have any timeouts in it at all.

It's actually pretty similar to my design, I think: instead of PRU0, the ProFile has separate hardware for clocking the data in or out. I suspect the Widget is similar, since as the IDEFile webpage notes, it's a rare MCU (for the time) that can keep up with a 1 MHz ~PSTRB signal. There probably aren't many other practical ways to do it, I don't think. But as always I could be wrong.

rayarachelian:

--- Quote from: stepleton on February 09, 2021, 06:38:10 pm ---I've actually been looking at Dr. Schaefer's ProFile ROM disassemblies instead (also on Bitsavers), and you don't really need to speak Z8 very well for that --- he's left excellent comments as usual (thanks!). Thing is, though, this firmware tells you very little about timeouts for moving bytes over the parallel port, since it doesn't do that at all: all that the MCU does is move block data to and from the controller board RAM, and then the other hardware in the controller DMAs it out over the line on its own. I would expect that this hardware doesn't have any timeouts in it at all.

It's actually pretty similar to my design, I think: instead of PRU0, the ProFile has separate hardware for clocking the data in or out. I suspect the Widget is similar, since as the IDEFile webpage notes, it's a rare MCU (for the time) that can keep up with a 1 MHz ~PSTRB signal. There probably aren't many other practical ways to do it, I don't think. But as always I could be wrong.

--- End quote ---

Sure, whatever works, yeah, I was pointing to the disassembly as a way to look at how it handles the state transitions and whether there's a timeout. I wonder if it's just going to use the CRSET line or if it just flips CMD when it loses sync with Profile/Widget. Unfortunately the Boot ROM profile read routine is just a very tight loop reading from IRA2 and nothing else. The only useful clue is that it sets CA2 into pulse mode on the positive edge, but zero timing whatsoever, it just assumes the ProFile will be ready to pulse those bytes once it has them and that nothing will stop it.

The only time outs are during handshaking. UniPlus's profile driver is here: http://bitsavers.org/bits/Unisoft/V.1.5+/sys/pro.c it also doesn't seem to do much in the way of timeouts, though there is a mention of a 1ms timeout at line 595, - this seems to happen only for the BSY response to CMD. So perhaps that's something you might be able to use as a guide as well.

Navigation

[0] Message Index

[#] Next page

[*] Previous page