New build, getting a variety of errors - 84 & 75

[mg-man]

Hiya, I've just built a couple of these - awesome project btw! - and seem to be running into various issues. I've re-formatted my uSD card a few times, using both Windoze and also the SD Formatter tool. Unfortunately, when initially trying it with the SDTemplate files, I get an 84 error - which I believe is boot blocks corruption? When I put the uSD in my computer and overwrite the profile.image with the selector.image, the Lisa tries to boot, but then throws a "75" error - which I believe is OS files corruption?

I'm going to try some other uSD cards and also a different power setup today, but logging this here to see if it rings any bells. I'll add more observations along the way.

[i-to-z]

I can't comprehend the discussion linked above about why "Port F is faster than Port L", but my estensive tests show that using port F is indeed faster (based only on observations of what works where, I don't have any tangible numbers to support that). Perhaps we should put that to bed, and we (you, Alex?) should create another PCB version "1.2" (or whatever), and tag the current main branch as "v1.1", which will be described as obsolete, not recommended to use.

---

About getting rid of the interrupt-related code: I did that, things work as fast as previously (I timed it with a stop watch). Somehow Serial.print() worked fine without all that sei() and cli() around it.

---

I bear good news about booting from an external parallel card: It works, with caveats. Read below.

All tests were done on a Lisa 2/20, with the ArduiboFile hardware mod that uses port F for data (as aledgedly it is faster), with the code in the "2/10 Testing" branch (with a bug fix in the "Resetting drive..." code, but that doesn't seem to matter), with the parallel card inserted in the middle of the 3 slots (it fails to boot if paced into any other slot ;):

Booting MacWorksXL3.0         with 3A ROMs from internal IDC26 connector: YES
Booting MacWorksXL3.0         with 3A ROMs from external parallel card, lower DB25 port: hangs with a blank black screen on the very first command 000000000A03. This may be an unsupported combination, see my comments below.
Booting MacWorksXL3.0         with 3A ROMs from external parallel card, upper DB25 port: hangs with a blank black screen on the very first command 000000000A03. This may be an unsupported combination, see my comments below.
Booting MacWorksXL3.0         with H  ROMs from external parallel card, lower DB25 port: hangs with a blank black screen on the very first command 000000000A03. This may be an unsupported combination, see my comments below.
Booting MacWorksXL3.0         with H  ROMs from external parallel card, upper DB25 port: hangs with a blank black screen on the very first command 000000000A03. This may be an unsupported combination, see my comments below.
Booting Stapleton'sSelector   with H  ROMs from external parallel card, lower DB25 port: YES 
Booting Stapleton'sSelector   with H  ROMs from external parallel card, upper DB25 port: YES
Booting Stapleton'sSelector   with 3A ROMs from here-and-there: not tested, the roms and the image software are incompattible.
Booting LisaOS                with H  ROMs from internal IDC26 connector: YES (as previously reported)
Booting LisaOS                with H  ROMs from external parallel card, lower DB25 port: YES
Booting LisaOS                with H  ROMs from external parallel card, upper DB25 port: hangs with Lisa error "10741" at command 0000041B0A03, after reading hundreds of sectors. Tried many times, it consistentlly fails in this exact way. Do not bother googling the lisa error code 10741, it's not important, but anyhow: the closest you will find is : https://lisafaq.sunder.net/lisafaq-sw-los_error_codes.html
Booting LisaOS                with 3A ROMs from here-and-there: not tested, the roms and the image software are incompattible.

... then I repeated just the failing tests on another mlachine, Lisa 5, with an external parallel card. I got the same results. Good!

About the problems with booting MacWorksXL from the external parallel card: I am pretty sure this is an unsupported configuration because: If you boot MacWorks XL from the (two) installation floppies and run the "Install Hard Disk" program, it says "No Hard disk is attached to the builtin parallel connector!", and then it exits. This means that MacWorksXL3.0 is not designed to work with the external parallel card.

About the problems with booting LisaOS from the Upper DB25 port on the external parallel card: It fails consistently as described above, which makes me think that we are also hitting some bug in the Lisa software. But I don't have a real, working ProFile hard drive to confirm that. Anyhow, users can always choose to boot from the lower DB25 port, so I guess this is not a big deal (and most likely Apple classified their bug in the same way).

[busterswt]

Nice work on finding the compile flag!

For what it's worth, the Lisa has proven to be a bit particular about booting a parallel drive from a port other than the one it was installed to. It might be worth trying to mount a blank hard drive and perform a clean install off the upper port to see if the behavior is different.

I would also be interested in seeing how Xenix and Uniplus work in this scenario. I have a few ArduinoFile in my kit, without the mod, and could give it a go.

James

[alexthecat123]

For what it's worth, the Lisa has proven to be a bit particular about booting a parallel drive from a port other than the one it was installed to. It might be worth trying to mount a blank hard drive and perform a clean install off the upper port to see if the behavior is different.

Yep, I was about to say the same thing! I've gotten that exact same error code before and doing a fresh install of the OS while connected to your desired port should fix everything.

Perhaps we should put that to bed, and we (you, Alex?) should create another PCB version "1.2" (or whatever), and tag the current main branch as "v1.1", which will be described as obsolete, not recommended to use.

Good idea! I'll get to work on that now. It should be pretty easy to make those changes, so I'm sure I'll have it done at some point tomorrow! And yeah, switching to Port F clearly seems to help because I was also using my parallel card in the middle slot with my Port L ArduinoFile, but I'm still not getting the good-ish results that you are! I wonder what's so special about the parallel card being in slot 2? The slots should all be identical other than a couple of selection and interrupt signals (/SLn, /SHn, /INTn, and /IAKn), so that's pretty weird!

About getting rid of the interrupt-related code: I did that, things work as fast as previously (I timed it with a stop watch). Somehow Serial.print() worked fine without all that sei() and cli() around it.

If you got rid of the interrupt-related code entirely, then that would explain why Serial.print() is working fine for you! If there isn't a cli() anywhere in the program, interrupts will be enabled at all times and thus serial stuff should always work as expected. And if it doesn't hurt performance or reliability at all, then that's absolutely awesome!

I think you're right about the MacWorks XL 3.0 thing, so let's not worry about that too much right now! And by the way, I've tested pretty much every OS the Lisa can run (LOS 2 and 3, MacWorks XL 3.0, MacWorks Plus, MacWorks Plus II, Workshop, Xenix, and Uniplus) with the ArduinoFile plugged into the 2/10's internal parallel connector, so at least we know that everything works fine there with the 2/10. It's just a matter of getting things working with the darn parallel card at this point!

[i-to-z]

For what it's worth, the Lisa has proven to be a bit particular about booting a parallel drive from a port other than the one it was installed to. It might be worth trying to mount a blank hard drive and perform a clean install off the upper port to see if the behavior is different.

I did exactly this just now, before reading these comments, and now I have a LisaOS 3.1 image file that boots equally well from the internal connector and from the lower and upper ports on the external parallel card on a Lisa 2/10 ! I can't explain why my other image was hanging midway boot. Will try to do some bunary diffs of the image files to see how different are they.

About booting MacWorksXL3.0 from an external parallel card: It seems that the functionality was added in MacWorks4.5, see https://ia902206.us.archive.org/12/items/Macintosh_Garden_Manuals_2021_M/MacWorks_4.5_text.pdf , page 13. And a golden nugget on the last page: A warning window that says "What you are about to do may ruin that day!" I want this software!

---

If you got rid of the interrupt-related code entirely, then that would explain why Serial.print() is working fine for you! If there isn't a cli() anywhere in the program, interrupts will be enabled at all times and thus serial stuff should always work as expected. And if it doesn't hurt performance or reliability at all, then that's absolutely awesome!

I wasn't fully honest above. I left one single call to cli() in setup(). I think things were not working without it, but now I am not so sure... I need to read more on this stuffffffff.

---

busterswt , could you share your Xenix and Uniplus images? Perhaps email me at tor.zidan at gmail.com, this is an email address that I have and I feel ok to share publicly here :)

Ivan

[i-to-z]

Going on a tangent: I like using MacWorksXL3.0 for this project, because it allows me to push software changes to the Arduino Mega without shutting down / staring up the Lisa; this reduces the strain on the machine and increases its longivity. Here how it's done:

Let's say you have booted into MacWorksXL3.0 and you want to update the ArduionFile software and boot again.

1. Hold the "Option" key on the keyword and press and relese the Lisa power button. The lisa goes in a mode where it wants to boot from a floppy (but there is no such in the floppy drive). Note: any unsaved work is lost; I am ok with that.
2. Upload the ArduionFile software to the Arduino Mega in the usual way, via USB cable.
3. Hold the "Apple" key on the keyword and press and relese the Lisa power button. The Lisa will start booting without going through the startup tests.
4. In a few seconds you are booted into MacWorksXL3.0.

A shorter version for the brave among us: skip step 1.

This is it, I hope people find this useful. Note: this does not work in LisaOS.

Ivan

[alexthecat123]

Well, I finished with the new PCB design and you can now find it in the PCB folder of the 2/10 branch! Other than the Port F change, I also changed the board's font to the Lisa's silkscreen font and updated some of the footprints to better match the footprints that are used on actual Lisa boards. Obviously, these are just cosmetic changes, but I think they make the board look a lot more Lisa-like!

[RolandJuno]

Forgive me for adding to this thread but many of the issues described here sound like the issue I'm also having.

Background: I have a Lisa 2/5 system that consists of a original CPU and SunRem 2MB cards as well as reproduction motherboard and I/O cards. I'm also using EPROMs as emulated PROMs on the CPU and I/O cards as well as a COP emulator on the I/O card.

Reads from the ArduinoFile seem solid. I've not encountered issues there. The issue seems to be with writes to the device. The symptoms while using the ArduinoFile are:

• MacWorks will report "The file "name" couldn't be written and was skipped (disk error)." while copying a large-ish file (one that typically takes multiple read/write cycles in the Finder).
• When I try to boot into the LisaOS, I get an error 10707.

First I tried the following:

• Monitored the serial port for debug messages. When the error in MacWorks appeared, the debug statement "Phase 1: Host didn't respond with a 55! Maybe the drive was reset?" appeared.
• Set the timeout value from 10000 to 20000. MacWorks still produced the error but there was no error messages on serial this time.
• Changed the version of SDfat to an earlier version (2.0.5 is pictured in the docs but that wouldn't compile. 2.1.0 was the oldest that would compile).
• Removing the Serial.println statements in an attempt to speed things up

I then found this issue thread which seemed to offer some hope! I tried the following:

• Set the compiler flag to -Ofast.
• Bodged the board to use PORTF instead of PORTL.

None of these so far has resolved the issue in MacWorks. I'm hoping that someone has some ideas of what might be the issue?

Update: I enabled many of the serial debug statements in the code and watched the stream. It seems the Mac will write data and then read it back to verify. I got a new error this time.

• Timeout: Read Command Confirmation
• Phase 1: Host didn't respond with a 55! Maybe the drive was reset?

PS Alex, I know you're very busy so reply only if time allows! Your university studies should be your top priority! =-)

[alexthecat123]

That's so weird! I just tested it for myself and my ArduinoFile never gets those write errors in MacWorks Plus or MacWorks Plus II. I wonder what's going on here? Are you running the new 2/10 version of the code or the older 2/5 version?

[i-to-z]

I also have not experienced a single write error. I would assume something is wrong with your DIY Lisa.

Try borrowing original (not reproduction) CPU and I/O cards and do a mix-and-match tests to see which one is faulty? Note: the I/O card from a lisa 2/10 won't work on a Lisa 2/5; the CPU card works on both, but you may want to change the ROMs to Lisa 2/5 ROMS. Are the quartz clocks on your Lisa same speed as on the Lisa 2/5? Also, the page at https://en.wikipedia.org/wiki/MOS_Technology_6522 describes a "bug" in some of the VIA chips out there (they are used on the Lisa to communicate with the ArduinoFile). May be yours have the bug? This is just a speculation, I don't know if it affects ArduinoFile. Also, try a different SD card? Mine is SanDisk Ultra 16GB microSDHC.

[RolandJuno]

Thanks for the responses!

I'm using the fork located at https://github.com/alexthecat123/ArduinoFile/tree/2/10-Testing

The CPU card is an original. Unfortunately, I don't have access to a 2/10 I/O card. I'm using H ROMs on the CPU card.

The quartz clock on the CPU card are original. The ones on the I/O board are to spec.

I have been curious about the 6522 as being suspect. I have some extras I can try plus the modern WDC W65C22N6TPG (which I couldn't get to work originally but are supposedly drop-in replacements for the original 6522). Will give this a try.

I've tried three different class 10 SD cards (SanDisk, Samsung and PNY).

Also, as before, I increased the timeout value to 15000 this time and both errors in the serial debug stream went away but the error on MW II+ still persist (but definitely seem to be related to reading back what was just written).

Is there a way to write to the debug stream the actual data in HEX that is being read and written? That could help me pinpoint if it's an actual verify error or a timing error.

I have an 8 channel logic analyzer. Should I measure all 8 data lines?

[RolandJuno]

I just tried three different 6522 chips in U5C. A SY6522A, MOS6522, and a new W65C22N6TPG. All three produce errors from the ArduinoFile.

`Timeout: Write Command Second Handshake Part 2 Phase 1: Host didn't respond with a 55! Maybe the drive was reset?

Timeout: Read Command Confirmation Phase 1: Host didn't respond with a 55! Maybe the drive was reset?

Timeout: Write Command Confirmation Phase 1: Host didn't respond with a 55! Maybe the drive was reset? `

Does this seem to show that we're missing a signal (or never get one)?

[RolandJuno]

I connected my logic analyzer to the pins pictured in the screenshot (6 control lines and 2 data lines). I attempted to copy a large application in MW II+. It produced a write error on the Mac side. The last few lines of the debug from the ArduinoFile are:

.. 010034F7030A 010034FC030A 010034F1030A 010034F6030A 010034FB030A 01003500030A 01003505030A 0100350A030A 0100350F030A 01003504030A 01003509030A Timeout: Write Command Confirmation Phase 1: Host didn't respond with a 55! Maybe the drive was reset?

The logic analyzer was stopped shortly thereafter with this near the end of the capture.

Zooming in:

Hopefully this helps? Let me know if you want the raw data or more screenshots or measurements.

[i-to-z]

RolandJuno, since we can't reproduce the errors that you experience, I would recommend opening a new issue. The issue in this thread has been solved.