Advanced search  


2019.06.07 fixed NChat for the "Curve" theme, will eventually move it to its own page and add it to the default theme as well. Other plugins are next. see post in the Meta board for details

Pages: [1] 2 3 ... 10
 on: January 22, 2021, 11:27:16 pm 
Started by stepleton - Last post by rayarachelian
The upper parallel port boot bug is now fixed!

Congrats and well done! :)

 on: January 22, 2021, 08:55:00 pm 
Started by stepleton - Last post by 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:

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!

 on: January 22, 2021, 12:10:11 am 
Started by stepleton - Last post by rayarachelian
shmem ops are pretty straightforward, it's almost like using malloc but it's mapped to a "file", you could use that with /dev/shm, and once you get a pointer back, the offset is equivalent to the file offset.
However, you mentioned something yesterday that might be a clue, you've noted that the upper and lower ports have slightly different lengths in their traces. This shouldn't matter at all because normally you'd have a ProFile at the end of a 3 foot 25-conductor cable, right?
So are you hanging the Aphid directly on the port itself? Or is there a cable between it and the port?

Perhaps hanging it off the port is the issue because the wire is too short and it's causing some kind of EM/RF interference from some other noisy thing in the Lisa, or just the right condition to cause a resonance?
Or perhaps the wires are indeed too short and the resistor pack terminating the pins is now slightly out of spec enough due to changed capacitance? I recall seeing something similar with 10B2 and early 10BT ethernet where if your cable was too short you'd have issues.

In terms of the direction of the BSY line and the voltage converter, you could always skip going through that chip and instead use a resistor to drop the voltage from ~5v to roughly 3.3v if you think it's the converter chip. And if you want to ensure direction, use a diode too, which would also drop the voltage by ~.7v. Hmm, or instead of a resistor, if you'd use 3 diodes in series it could drop the voltage from 5v to 2.9v which likely should still ok with the rest of the circuitry.

 on: January 21, 2021, 06:18:25 pm 
Started by stepleton - Last post by stepleton
You may be right about that. The main problem facing any theory though is that it has to account for why there's a problem on the upper parallel port but not the lower one.

I got some traces of PR/~W, which is also wiggling in a confusing way, but there wasn't really much difference there between the two ports that way. The signals seem very similar. It's possible that whatever the problem is, it's being provoked by a different control line.

Can't hold back my "software guy" any longer. To narrow down the possibilities for signals that are triggering the problem, it will help to know what state the Cameo/Aphid state machine is in when it gets stuck for so long. This kind of inspection was a big part of my initial debugging process, which is why the state machine implementation has statements like these:

The heart of the PocketBeagle single-board computer is a TI AM335x SOC, which is an ARM core paired with two real-time I/O processors called PRUs --- they're decent little RISC devices. The PRUs talk to the pins and then the ARM talks to the PRUs. It's handy because if Linux on the ARM wants to steal the CPU away from the disk emulator in order to do some other task, it won't interfere with the timing that the parallel port hard drive protocol requires. Dr. Schaefer notes on his IDEfile page that the Apple can send bytes down the cable (or demand that they flow back up the cable) at a megahertz, and the drive just has to deal with it; there's no flow control like on a serial port, so it can't drop the ball.

Anyway, the state machine code linked above is running on one of the PRUs. It's recording the current state to a shared memory region that's accessible to the ARM, so you can write a nice program for the Linux side that probes that shared memory in /dev/mem and reads that useful debug information. Thank goodness I took notes on where to look:

I used to have such a program, but I seem to have lost it forever. Too bad; I can write another one. Time to remember how to mmap again...

 on: January 20, 2021, 08:23:01 pm 
Started by stepleton - Last post by rayarachelian
So then my guess is that the aphid hardware is a lot faster and notices these ups/down where as a real profile and IDE file use a slower processor which would average them out to a nice flat line. So either a switch debounce circuit would solve this, or you could do something similar via software where you don't act on the CMD going back up to 5V immediately, but wait a bit to see if it gets pulled down again, etc. before flipping BSY?

Edit: This is what I was talking about regarding the Schmitt trigger circuit:

 on: January 20, 2021, 08:10:00 pm 
Started by stepleton - Last post by stepleton
Thanks for looking at the ROM! Now I know from my Applenet disassembly that 6008 and 6002 aren't sizes: they're the first words of the status entry and boot routines themselves. Of course there's not much room for code in 16 bits each: you just get one small instruction. So the one instruction in both cases is: jump to the place where the real code is.

Does it work on both ports if you're not booting from it? i.e. just as a data disk?

It does work as a data disk, which was one of the things that was such a mystery. But thanks to the probing I did just now, I have an answer for why booting alone was a problem. I wonder if I would have figured it out from a disassembly.

For some reason the Lisa parallel port card likes to give the ~PCMD (that's the "HEY HARD DRIVE" signal for folks following along) on both of its ports a good shaking prior to talking to either of the ports on boot: both ports get the business no matter which port you're booting from. I don't know the reason for this, but it also seems to happen during the POST, which must mean that it's happening in the status entry routine. (IIRC, in addition to during POST, the boot ROM runs the status entry routine prior to running the boot routine.)

Now, when Cameo/Aphid is on the lower port, it's no problem: see the first attachment.

The blue trace is ~PBSY, the "We are dealing with your request" line that comes back from the hard drive. Basically, the Lisa stabs ~PCMD down very briefly, then gently pulses it down a couple of times more. This three-wiggle manouvre repeats eight times for some reason.

(The reason ~PCMD doesn't drop to 0, I think, is because I've got a series resistor on the line for termination, and there's a pullup on the Lisa end, so the probe is sitting in the middle of a voltage divider.)

Now let's move Cameo/Aphid to the top port: see the second attachment.

You can see here that our poor guy is a little more confused by all this nonsense: while last time ~PBSY goes high very crisply after a wiggle, now it sometimes takes a little longer. The final wiggle keeps ~PBSY low for nearly 11 seconds, which is way too long for the parallel card boot routine: it times out.

Look at how long it takes ~PBSY to return to high after wiggles 1, 2, and 7. It's very suspicious that the delay seems to be an integer multiple of other obvious intervals --- I'd say it's about 88us given the labeled period there.

My hunch now is that we're not seeing the entire story of the wiggles. There are probably other control lines to check out. I bet we're getting treed up at this point:
waiting on PR/~W, the direction signal from the parallel card. Maybe it's doing something weird.

As you've noted, the upper and lower ports seem pretty similar on the schematic, so any difference between the two may be down to the layout?

Those traces for the upper port are longer...

 on: January 20, 2021, 06:22:51 pm 
Started by stepleton - Last post by rayarachelian
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.

Hmm, so this would imply there's something different about the ports. Been looking at and I don't see anything too obvious, both seem to have very similar circuits, I see PB7 and the gate it goes to are above the VIA in one drawing and below in the other, but they're the same circuit. Both have resistor packs. Both have the LS280, 245, 09 on PA lines for the parity checker,  both use the phi2 clock, they do share the DTACK circuitry... so what else could it be?

Does it work on both ports if you're not booting from it? i.e. just as a data disk?

I started a disassembly of the 2x parallel ROM here: I removed the 1st 5 words from the disassembly, but not sure if that's correct or not. The ROM is here:

Not sure what the offsets are supposed to be as it's a bit weird. The 1st 5 words are:  e0 02, 03 fd, 60 08, 60 02,  05 c7
e0 02 - this is the card ID, e0=has icon, has status, is bootable. 02=2x parallel port card id

Code: [Select]
03fd - number of words in the ROM
6008 - this is the offset to the status entry routine
6002 - this is the boot routine
05c7 - icon pointer in packbits format.

But 6002 is outside the size for this card, so it's got to be at 20002 most likely, not sure what the significance of the 60 is.

The first instruction is a branch to 202a2 which checks d0 for the device id and makes decisions from there, likely loading the address of the VIAs and the device to boot from.

 on: January 20, 2021, 05:49:38 pm 
Started by stepleton - Last post by 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 :)

 on: January 20, 2021, 05:11:58 pm 
Started by stepleton - Last post by rayarachelian
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

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?

 on: January 20, 2021, 04:45:21 pm 
Started by blusnowkitty - Last post by stepleton
I'm all for this project :)

The Lisa parallel port is very different to the PC parallel port --- the fact that bits come in a row is where most of the things in common begin and end, I think. I guess they're both 5V, there's that too. Still, you ought to be able to get a Speech Thing to work. I like the idea of whacking together some sound hardware from stuff lying around in drawers. Plus, got a 2-port parallel card? You've got stereo!

Sometimes though I have to admit to wondering what you could do with just the built-in hardware. An IBM PC with a 4.77MHz 8088 can play a MOD file on the speaker if you happen to be a demo wizard, with cycles left over to print the end credits.

I don't know much about this stuff, but the demo I linked seems to take advantage of the fact that the PC has a programmable square wave generator (i.e. a particular way of setting up the 8253 timer). In the Lisa, the speaker is hooked up to a pin on one of the 6522s (CB2) that acts as a shift register, and furthermore it seems like you can get a 6522 to generate somewhat arbitrary square waves too if you want by shifting out the same byte over and over --- the last page of this PDF has the details. Whether this facility has a comparable frequency range to what you can do with an 8253 is beyond me. But, it may be possible --- and, with the Lisa, you have volume control, so you can do dynamics. My bet is that you can play samples on a stock Lisa with no peripherals.

I'd love to try it but I have a hard drive emulator hardware bug to fix :)

Pages: [1] 2 3 ... 10