LisaList2

The boards arrived today, a day earlier than expected, and so far they seem to be working great!

I haven't tested all of the new board's features and fixes yet, but here's what I've done so far.
- Validated that the external ProFile port works now, unlike on the original board thanks to those weird bidirectional level shifter ICs. This means that my new MOSFET-based level shifter solution seems to work!
- Confirmed that the new +12V supply is good and that the speaker doesn't literally melt anymore (which it would do on the v1 board when you supplied -12V to the board but no +12V).
- Tested all of the stuff that worked on the previous board, and confirmed that it all still works as well as it did on that board, with the exception of the floppy drive port. But this is probably just because I was doing some weird experiments with the floppy drive on the old board and had remapped the pins so that they weren't even pointing to the port anymore!

I haven't been sitting idle while waiting for these boards to arrive; in fact, I've gotten lots of minor (and several major) problems solved over the past couple weeks. These include:
- Getting 60FPS HDMI video working. I've discovered that, while most devices will happily accept the 60FPS video stream, there are a select few (like my HDMI capture device) that don't like it and glitch out, so I've got it set up so that you can switch between 1080p30 and 1080p60 on the fly. Right now it's done with a wire shoved into the GPIO header, but I'll add a proper jumper on the v3 boards.
- Fixing some really annoying reliability issues with a variety of different parts of the Lisa that have been bothering me for months, mainly with the floppy controller, video circuitry, and RAM. The problem manifested as one or more of these systems (most often the floppy controller) randomly breaking when I would change some tiny thing about the design, even something completely unrelated to that part of the system. And I couldn't attach virtual logic analyzer probes to troubleshoot the problem because the very act of attaching the probes would fix it! This issue took me over a month to figure out, but I finally discovered that it was because I was clocking some things off signals that weren't proper clocks running on clock nets. Doing this is really bad because clock nets are special paths inside the FPGA that minimize clock skew, essentially ensuring that the clock arrives everywhere inside the chip at nearly the same time. But if you clock a bunch of stuff off a non-clock net and that signal propagates all across the chip, significant skew can be introduced and one thing will be clocked before another, leading to certain elements latching data too early or too late. And making tiny changes to the design would cause everything to be placed and routed on the chip differently, changing the skew on these non-clock nets that I was using to clock stuff. It seems so obvious in hindsight!
- Getting UniPlus to boot properly. It turns out that this was a problem with my handling of the PRES signal as it comes out of the 6522.
- Fixing the issue where my USB-to-Lisa keyboard logic couldn't detect a modifier key press (like the Alt/Apple key) unless it was accompanied by the press of a non-modifier key. This would mean that, if you wanted to have LOS shut down into the Environments Window, you'd have to hit Alt+Some Key and then let go, which would latch Alt's (Apple's) status as "on" internally, and then you would hit the power button. And to un-latch Alt, you'd have to do it again. This was just a dumb logic bug, but now all the modifier keys can be pressed and registered on their own.
- Implementing a solution to the parity problem. In case you don't remember, the FPGA-based Lisa doesn't have any parity RAM, so it would always fail the "write wrong parity" test in the boot ROM and LisaTest where the CPU board would intentionally force bad parity and try to read it back. I had patched this test out of the ROM for a while, but I went back and added a real solution now where, whenever the RAM board detects that the CPU is trying to do one of these tests, it latches the write address. Then, the next time it sees a read from that address, it sends the parity error (HDER) signal. It'll un-latch the write address whenever the CPU writes to that address again but with the write wrong parity test disabled. Granted, this only lets it remember the address of one parity test operation at a time, but it's good enough for the boot ROM. We'll find out if it's good enough for LisaTest when I get the floppy drive working again...
- Fixing an annoyance with the HDMI video output where my Lisa-to-HDMI framebuffer would start sampling 2 pixels too late on each line. This would cause 2 columns to be cut off on the left side of the image, and two black columns to be inserted on the right side of the image. The fix was as simple as adjusting my delay counters, which figure out how many DOTCKs to wait before reading pixels after the end of HSYNC at the start of a line, and how many DOTCKs to continue reading pixels for after the start of HSYNC at the end of a line. I had them both set to 11 before, but 9 is the correct value. Not sure if anybody had noticed this in any of my pictures, and it's honestly pretty minor, but it sure annoyed me a lot!

My next goal with the v2 boards is to get the floppy port working, and I've also thrown some code into the HDMI interface that should get the new "simulated scanline" jumper working at the same time. Then I need to fix whatever's preventing communications with the SCC, and that's really the last major thing left to do. But the SCC thing could prove to be a big task (I haven't looked into it yet whatsoever), so who knows how long that will take.

I've attached a picture of the new board, and here's a video showing it in action:
https://youtu.be/sAVDWAXoQMQ

Hey, that's awesome! Congrats!

Not sure if you know, but a rarely-used (or at least it seems rarely-used to me because very few people mention it) feature of ESProFile is its diagnostic mode, which might be pretty helpful in getting your Widget running. I spent far more time developing the diag mode than I did the emulation mode, so it's pretty full-featured, and supports nearly every command in the Widget's rather large command set other than the block read and block write commands. So you might be able to use your ESProFile not only as an emulator, but also as an aid to get your Widget running again!

Congratulations! Welcome to the party 

More good news! I dug out a crystal in my parts bins and did a swap and the Lisa came to life and passed all its test besides the widget drive which is expected. I may start a new thread troubleshooting that. I will install the proper crystal when the part arrives tomorrow but really happy with this progress. Now to recap the power supply and wait for my ESProfile board to come in for a boot drive! I'll update once we I have Lisa OS booting but I think we are looking good. Again appreciate all the help here it has been indispensable for this more advanced repair for a beginner!

The transistors looked ok but the Hfe values on my tester were very low on Q1 compared to the Q2. Since I had some that would work I replaced the Q1 & Q2 transistors and had no change in my probe measurements or behavior of the machine. I also confirmed 12v+ at the R4 resistor, Im not sure I have a crystal on hand, but going to look and I ordered a new 16Mhz one which will be here in a couple days.

QuoteThanks for the tip, I probed U68-LS132 Pin 3 and see basically the same thing.

Sounds like you've narrowed it down a lot!

Suggestions:

Check for physical damage to the transistors as they can be bent/broken by rough handling.

Check for +12V at R4.

Swap in another crystal (even a different frequency) to see if the rest of the oscillator circuit works.

Thanks for the tip, I probed U68-LS132 Pin 3 and see basically the same thing. I lowered the voltage to 1.0/div for more detail but basically a flat line as before.

QuoteGreat suggestion. I think I may have found the issue. The 16Mhz FDC clock Y1 appears to be dead if im reading my scope correctly. Compared to the others there is zero activity.

If you are probing the portion of the circuit connected to the crystal itself, its behaviour may be altered/stopped by the loading of the scope probe. Double-check the signal after it is buffered, eg. at U6A-3

Great suggestion. I think I may have found the issue. The 16Mhz FDC clock Y1 appears to be dead if im reading my scope correctly. Compared to the others there is zero activity.

Yeah, soldering a wire and probing it is probably your best bet unless you have right-angle risers that let you probe the CPU board directly.

But given your symptoms, I'd be willing to bet that the problem is on the I/O board and not the CPU board. If something were wrong with the 556 that was causing it to assert BERR too quickly (or constantly), the Lisa almost certainly wouldn't be making it this far through diagnostics. So I'd suggest looking at the floppy controller on the I/O board instead, which is luckily a lot easier to probe!

Page 4 of the I/O board schematics should show you everything you need to see when troubleshooting the FDC. I've seen this exact same problem several times (including on my FPGA-based Lisa) and it's always been because of DTACK never getting asserted by the floppy disk controller at the end of the 68K read/write cycle. This could be caused by a variety of different things, from the 16MHz FDC clock being completely dead to a bad 8T97 that buffers the FDC's DTACK onto the main systemwide DTACK line, but something in there is likely to be your issue.