General Category > LisaList2
Cameo/Aphid selector
stepleton:
Now that my fun software project is basically complete, I have to return to the cold reality that Cameo/Aphid is a piece of hardware that wasn't designed by an EE --- and so there is one hardware bug! I thought it might be good to describe the bug here in case anyone has any thoughts about what might be going on. I have a feeling that the fix will involve adding a component to some empty pads on the Cameo PCB, so hopefully not a bad one as these things go.
Here's the problem: you just can't boot a Cameo/Aphid from the upper port of a parallel interface card.
It is the strangest issue, since it appears only to affect booting and nothing else. BLU will detect and work just fine with a Cameo/Aphid installed on that port. The Office System will format a Cameo/Aphid there and will read and write files on that drive all day long. Also, there is no problem with booting from any other port: the built-in port on a Lisa 1 or 2/5, the Widget parallel cable on a 2/10, the lower port on the 2-port card. Those all work without any issues.
This problem reproduces identically across two parallel interface cards that I own. It's possible that this is a signal quality issue relating to bus termination. I assume this is so because the 100 ohm series resistors that I've put on the signal lines in the current SMD layout, which you can see here:
https://github.com/stepleton/cameo/blob/master/aphid/pics/smd_layout.png
actually make the problem worse. You see, it used to be that I used only 0-ohm jumpers everywhere. In this older configuration, the upper parallel port would sometimes boot successfully, but the Widget parallel cable would not work under any circumstances. Some termination was clearly required, and with the 100-ohm resistors, the Widget cable became reliable for all accesses, while booting (and only booting!) on the second parallel port was broken forever.
Now that the Selector is done, perhaps it's time to get to the bottom of this issue. I have to admit feeling a bit daunted! One bit of good news though is that the "plugboard" that you use on the Cameo (1, 2) to hook up individual signal lines will likely make it really easy to introduce the components that make up a fix, whatever the fix winds up being. It's almost like I expected to have to deal with a problem like this :)
Some observations that may be important:
- When the boot fails, the error message complains of an error 81. On the boot ROM, this means "DISK NOT READY", which suggests that something may be amiss with the BSY line. But then again, when you boot from the parallel card, it's the parallel card who's complaining, not the boot ROM. So who knows if 81 means the same thing.
- Cameo is built out of fancy-pants TXS0108 bidirectional level adaptor chips to convert between 5V signalling and 3.3V signalling. These things are pretty funky---they detect which side of the connection (the 5V side or the 3.3V side) is driving the signal automatically and then drive the other side with the voltage it expects. There's no way to force a fixed direction, which would be appropriate for the BSY line, which is always driven by the emulator. Maybe there's some noise or voltage on BSY from the parallel card upper port that fools the TXS into thinking the parallel card is in charge on that pin.
(Why fancy TXS0108 adaptors instead of something much simpler? I wanted Cameo to be useful for more than just ProFiles---basically general purpose 5V I/O for the PocketBeagle computer. Maybe you could also do IEEE-488/GPIB/HPIB with it...)
rayarachelian:
--- Quote from: stepleton on January 19, 2021, 04:57:55 pm ---- When the boot fails, the error message complains of an error 81. On the boot ROM, this means "DISK NOT READY", which suggests that something may be amiss with the BSY line. But then again, when you boot from the parallel card, it's the parallel card who's complaining, not the boot ROM. So who knows if 81 means the same thing.
--- End quote ---
Indeed:
--- Code: ---0000| 0000 0051 DSKBSY .EQU 81 ;DISK NOT READY
...
1F70| 48E7 3F7E PROREAD MOVEM.L D2-D7/A1-A6,-(SP) ; save regs
1F74| DISABLE ; ensure interrupts off
1F74| 40E7 # MOVE SR,-(SP)
1F76| 007C 0700 # ORI #$0700,SR
1F7A| 6174 BSR.S PROINIT ; init for Profile access and check
1F7C| ; if attached
1F7C| 6704 BEQ.S CHKBSY ; go on if OK
1F7E| 7050 MOVEQ #NODSK,D0 ; else set error code and
1F80| 605C BRA.S PROERR ; skip if error - no disk attached
1F82|
1F82| ; Now check if Profile ready - wait time presently set for about 100 seconds
1F82| ; to allow enough time for normal Profile startup time of about 80 seconds
1F82|
1F82| 0810 0001 CHKBSY BTST #BSY,IRB2(A0) ; check if Profile ready (not busy)
1F86| 6608 BNE.S TRYRD ; skip if yes
1F88| 5382 SUBQ.L #1,D2 ; else loop until timeout
1F8A| 66F6 BNE.S CHKBSY
1F8C|
1F8C| 7051 MOVEQ #DSKBSY,D0 ; set disk busy error code
1F8E| 604E BRA.S PROERR ; and go to error exit
1F90|
--- End code ---
So this is what PROINIT does, the Boot ROM expects BSY to be in the ready state right after this, perhaps your timing is a little off:
--- Code: ---1FF0| ;----------------------------------------------------------------------------
1FF0| ; Subroutine to init parallel port for Profile access.
1FF0| ; Inputs:
1FF0| ; None
1FF0| ; Outputs:
1FF0| ; D0 cleared for error use
1FF0| ; A0 = VIA base address for parallel port
1FF0| ; CCR zero bit set if cable connected
1FF0| ; Side Effects:
1FF0| ; None
1FF0| ;----------------------------------------------------------------------------
1FF0|
1FF0| PROINIT
1FF0| 4280 CLR.L D0 ; clear for result use
1FF2| 267C 00FC DD81 MOVE.L #VIA1BASE,A3 ; get kybd VIA base address CHG036
1FF8| 0013 00A0 ORI.B #$A0,ORB1(A3) ; initialize profile-reset and parity-reset CHG036
1FFC| 002B 00A0 0004 ORI.B #$A0,DDRB1(A3) ; and set lines as outputs CHG036
2002| 207C 00FC D901 MOVE.L #VIA2BASE,A0 ; get paraport VIA base address
2008| 0228 007B 0060 ANDI.B #$7B,PCR2(A0) ; set ctrl CA2 pulse mode/positive edge
200E| 0028 006B 0060 ORI.B #$6B,PCR2(A0)
2014| 4228 0018 MOVE.B #$00,DDRA2(A0) ; set port A bits to input
2018| 0010 0018 ORI.B #$18,ORB2(A0) ; then set direction=in, cmd=false, CHG036
201C| 0210 00FB ANDI.B #$FB,ORB2(A0) ; enable=true CHG036
2020| 0228 00FC 0010 ANDI.B #$FC,DDRB2(A0) ; set port B bits 0,1=in,
2026| 0028 001C 0010 ORI.B #$1C,DDRB2(A0) ; 2,3,4=out
202C| 0810 0000 BTST #OCD,IRB2(A0) ; check OCD line
2030| 4E75 RTS ; and exit
2032|
--- End code ---
So maybe play around with that. Perhaps the LOS driver or whatever else you're testing is not as sensitive to the timing.
stepleton:
Thanks Ray! I think this is a hardware problem, though. The fact that it works on the lower port but not the upper port is just too suspicious, since both ports must use the exact same code from the parallel card ROM --- and while PROINIT is relevant, I haven't checked to see if that code in the Lisa boot ROM (which is only for the built-in parallel port, I think) is the same as the parallel card ROM's ProFile I/O code.
I'm really tempted to disassemble the parallel ROM and see what it does, since after all I am a Software Guy and I would love to try and tackle this problem with software. But I think I gotta do it the hardware way, it just seems too much like a hardware issue. I've got the tools (oscilloscope, breakouts); I should get better at using them.
Last night I hung the scope off of the ~PBSY and observed that as the computer tried to talk to the ProFile, ~PBSY wiggled around a bit and then just stayed low for too long --- definitely the reason for the DISK NOT READY error. Time now to put channel 2 on ~PCMD and see what it's doing. Noise there could throw my emulator's state machine out of whack, causing those funny wiggles. Or maybe the only problem is on ~PBSY after all.
The TXS0108 level translator is a delicate device, and in all likelihood this application (pushing bits down a bus of any length) is probably pushing it to its limits. It's almost too tempting for a newbie like me: just throw it between the 3.3V and 5V devices and don't worry about all of that messy electronics stuff, the magic chip will handle everything on its own. As an older and wiser hobbyist now, I know better: the real solution is TI's even more magical LSF0108 device. Or wait, no, maybe it's the SN74GTL2003.
Just kidding. In the worst case, if I can't get the current device to work, there is definitely a solution that is ProFile-specific and that uses a few more conventional unidirectional parts similar to what you find behind the parallel port in a real ProFile. It's a new board to design, but it'll still be pretty cheap.
rayarachelian:
--- Quote from: stepleton on January 20, 2021, 04:05:08 pm ---I think this is a hardware problem, though. The fact that it works on the lower port but not the upper port is just too suspicious
--- End quote ---
Or it might be that specific port on that specific 2x parallel card went bad or marginal, or it's VIA is failing, etc. If it's working on 2/3 ports, maybe the problem is unlikely to be with your device, but that specific port failing? Maybe swap the two VIA 6522s on the card if they're socketted? Maybe a cap on that board is marginal?
If you think it's because of noise and debouncing/cleaning it, it would help, maybe add a Schmit trigger on those lines? Or go all out and add a pair of octal tristate Schmitt trigger to cover all the lines?
stepleton:
That's what I'd hoped at first too. Unfortunately the problem shows up on both of the parallel cards that I own, and both cards' upper ports work fine with a real ProFile or with an IDEfile.
Got the 'scope out now, having a look :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version