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.

[mg-man]

So... switched to another PSU, another uSD card, still getting the "84" error on power-on. Here's what's happening in the log :

`Switching to the 5MB ProFile spare table.
ArduinoFile is ready!
Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
FFFFFF0A0000
Bad Command!
FFFFFF0A0000
4

FFFFFF0A0000
Bad Command!
FFFFFF0A0000
4

Switching to the 5MB ProFile spare table.
ArduinoFile is ready!
Resetting drive...`

The FFFF sections were spat out when booted from the Lisa OS diskette 1 and choosing [Install]. They were spat out during the 'Looking for HD' phase - which ultimately failed with 'No HD found'.

The last "Switching to" was after hitting RESET while everything powered up. Attempt to boot gave me "84". I then powered the Lisa off - which gave the 'Resetting drive...'

Lastly, mine is a Lisa 2/10 and works perfectly with a IDEfile on the internal connector, which I'm attempting to connect the ArduinoFile to. It also works with a real ProFile on the parallel card.

[alexthecat123]

So it looks like the issue here is that the Arduino just isn't fast enough to keep up with the VIAs on the 2/10 since they're clocked faster than those on the 2/5. I'm already pushing the Arduino to its limit on the 2/5 and I guess this is just too much for it to handle. I've known about this problem for a few months now and I thought that I updated the readme to let people know before they build one, but it looks like I never updated it. I'm really sorry about this and I've updated the readme now! And of course, feel free to mess around with the sections of the code that deal with reading /STRB pulses and reading or writing the corresponding data on the bus to see if you can optimise it any more than I could. I'm not a professional software developer or anything, so there's almost certainly some more optimizations that can be done!

[mg-man]

Thanks for getting back... but that is a real bummer! I suppose the upside is it saves me wasting too much time trying to make it work. I was kind of surprised to be the first to open an issue, so I guess there aren't too many of these out in the wild?

Please don't feel too bad, all is not lost... I'm actually working with a friend on restoring about 6 Lisas. Only one is a 2/10 like mine, the rest are 2/5s. Question on the 2/10, is it only when using the internal "Widget" connector that we run into this? I do have a Parallel Card I can try and given the time difference between us, I might have the answer before you get this - will see.

As for tweaking the code.... while I have s/w engineering skills, they're pretty dated - ASM86, Fortran [77!], Pascal, etc... I have dabbled in some PHP and Python, but only enough to be dangerous! Do you think it'd be worth mentioning on LisaList to see if anyone out there wants to have a crack at it?

Lastly, I have poked around the 'web to see if there's a "faster" Mega 2560. I've found the Arduino Due, but that seems limited to 3.3V output - which probably won't work? I've also seen mention of the Hitex ShieldBuddyTC275, but that looks pricey and appears to use a different tool chain? And, then there's the Adafruit Grand Central M4 Express... but that too is 3.3V logic. Any thoughts?

[mg-man]

Another thought... I found mention of changing the clock crystal to 20Mhz, along with MCUdude's https://github.com/MCUdude/MegaCore... Question, assuming I manage to do this, is it likely to work or do you have timing loops that assume the standard 16Mhz clock?

[alexthecat123]

Yeah, I don't think very many people have made one of these out in the wild; there's only one other person that I know of besides you who's actually built one.

Good luck with your Lisa restoration project; six Lisas is a lot to work with! Unfortunately, I just tested the device with a parallel card and it doesn't work there either because the parallel card VIAs are clocked faster than those 2/5 I/O board as well.

I thought about using the Due or another 3.3V Arduino-compatible board, but the 3.3V logic issue makes that a little bit complicated. My goal with this project was to make everything as cheap and simple as possible and the addition of an expensive Due and the complexity of level shifters (many of which are SMD components, which I would prefer to avoid) make the project stray away from this goal. If worst comes to worst, I might try to switch to a Due or something, but it would definitely be less than optimal.

The 20MHz overclock sounds like a really good idea! I'm not sure if it'll be enough to fix things, but it's definitely worth a try! There aren't any timing loops in the code that are tied to a particular clock frequency, so things should work without any modifications after switching to the new crystal.

I'm about to go back to college for the spring semester, so I probably won't have much time to work on any of this for a little while, but feel free to give it a try yourself and see what happens!

[mg-man]

I just tested the device with a parallel card and it doesn't work there either

Darn it!

I thought about using the Due ... but the 3.3V logic issue makes that a little bit complicated.

Yeah... I suspected that.

The 20MHz overclock sounds like a really good idea! ... There aren't any timing loops in the code that are tied to a particular clock frequency

Good to know. I might try this. I have 3 x Megas, so I can use one as a "test subject".

Good luck with College. I'll let you know how I get on.

[mg-man]

SO... an update. After a few failed attempts at using a faster ceramic resonator, I've managed to over-clock my Mega using a discrete crystal + 22pF caps...

Used CoreMark https://github.com/PaulStoffregen/CoreMark to confirm the 25% bump. :-)

Unfortunately... I still haven't gotten it working. Here's the log (I added the "/*" remarks) from a couple of tries :

`First attempt

/* power on ArduinoFILE
Switching to the 10MB ProFile spare table.
ArduinoFile is ready!
/* power on Lisa
Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
/* Lisa tries to boot
Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
00000A000000
/* press Opt-3, Opt-1 to boot from internal drive
Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
00000A000000
/* power off Lisa
Resetting drive...

Second attempt

/* Lisa powered-on, hit reset on ArduinoFILE
Switching to the 10MB ProFile spare table.
ArduinoFile is ready!
/* hit Opt-3 to get to Lisa boot menu
Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
/* hit reset on ArduinoFILE
Switching to the 10MB ProFile spare table.
ArduinoFile is ready!
/* hit Opt-1 to boot from internal drive
Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
00000A000000
`
As you can see, I'm still getting the "55" error, but what's spat out after is different. I'm now getting a "00000A000000" whereas before I was getting "FFFFFF0A0000".

Any thoughts?

[mg-man]

So it looks like the issue here is that the Arduino just isn't fast enough to keep up with the VIAs on the 2/10 since they're clocked faster

Out of curiosity... how much faster are they clocked?

[alexthecat123]

Sorry to hear that things still aren't working! The "host didn't repsond with a 55" error isn't really an error in this situation, so we can pretty much just ignore it. The Lisa checks for a ProFile's presence when you enter the boot menu by starting (but not finishing) the handshake and it does the same thing again when you actually tell it to boot from the drive, hence these errors saying that the Lisa never responded with a 55 to complete the handshake. Those errors would be problematic if you were getting them all the time after successfully starting the boot process, but they're to be expected here.

Unfortunately, I don't think that the change from FFFFFF to 000000 really means too much. It seems to show that the ArduinoFile is running a little faster and reading different incorrect data now, but it's definitely still reading an incorrect command. The "0A" byte should be the second to last byte in the command, but it's third to last instead, so the ArduinoFile is definitely still missing some stobe pulses. As far as I know, we can't overclock the ATmega2560 any more than this, so we're kind of stuck. The only options are switching to a faster (and preferably still 5V-tolerant so that we don't have to add level shifters) MCU or optimizing the code to make sure that we read all of the strobe pulses. I spent hours and hours on that section of the code when first creating this thing, so I'm not sure how much more optimized we could make it. I think I also configured the ATmega at some point to send us an interrupt on each strobe pulse so that we don't have to keep polling the strobe, but this was slower than the current solution from what I remember. Maybe I could try rewriting it in assembly or something? I think that's the only thing I haven't tried yet!

The VIAs in the 2/5 are clocked at around 500kHz, while the VIAs in the 2/10 are clocked at 1.25MHz. So it's a pretty significant difference!

[mg-man]

The VIAs in the 2/5 are clocked at around 500kHz, while the VIAs in the 2/10 are clocked at 1.25MHz. So it's a pretty significant difference!

Yah, it is! More than a 25% speed bump is gonna compensate for. :-(

This may be a complete red herring... but when Googl'ing how the PINL command works, I found this reference to the way it behaves on the Mega ...
https://forum.arduino.cc/t/arduino-coding-without-delays-using-program-ticks/196693/17

[alexthecat123]

That's really interesting! I had no idea that some of the I/O registers required more CPU time to access than others! I wonder if it's a big enough difference to solve our problem? I'm super busy with college right now (this semester has been the busiest one so far), so I'm not sure when I'll get around to switching to different ports and trying things again, but I'll definitely let you know if/when I get around to it! And of course, feel free to give it a shot yourself if you're in a hurry to get things working!

[mg-man]

I'm glad that wasn't a total herring!! Unfortunately, I'm not sure I have the knowledge / skill to investigate a change. :-( Will switching to a different port be purely software, or would hardware mods be needed? If software, I'm willing to have a crack if you'll point me in the right direction. ;-)

There's no massive rush, it'd just be nice to have a solid-state alternative to my failed Widget. Get back to me when you can and good luck with college!

[alexthecat123]

Sadly, it's a little more than just software. The ports are implemented in hardware, so a certain set of 8 Arduino pins connect to each port. Changing the port would require rewiring the data bus to a different set of pins that correspond to another port. The software side is really easy, though. Let's say that we're going to change the bus from port L to port A. All we would have to do is replace all instances of PORTL with PORTA, PINL with PINA, and DDRL with DDRA. The port for the control signals is already one of the "fast" ports (port C), so we can just leave that one alone! Looking at the ATmega2560 datasheet, it seems that all ports under address 0x60 (meaning ports A-G) can be accessed quickly, so changing to any of these (other than C since it's already used) would be fine.

[mg-man]

Sadly, it's a little more than just software.

Darn it!! ...but I kinda figured.

Changing the port would require rewiring the data bus to a different set of pins that correspond to another port.

So that's 8 x "cuts" and 8 x "bodge wires"? Won't be pretty, but doesn't seem impossible. I had 5 x 'boards made up, and have so far only built up 2, so I'm happy to hack at one of them if you can point me in the right direction? Do you want to create a Lisa 2/10 branch and we'll get started?

[alexthecat123]

I just created a 2/10 branch and added you as a contributer so that you can update things with any changes that you might make. And yep, it's 8 cuts and 8 bodges. Not super fun, but it could definitely be way worse (flashbacks to the 70 or so bodges that I had to do on my VERY damaged 2/5 I/O board)! Thanks for offering to give these mods a shot; I've been really stressed with school and this defintely relieves some of that stress!

There's an image showing you the different ports on the Arduino Mega. You can probably see why I went with ports C and L; all of the pins for the port are clustered together instead of being scattered all over the place! I'm not sure why I went with C and L instead of C and A, but we can't use A anymore because that's where I hooked up the status LED and it would be easier if we didn't have to mess with that. Looking at the image, it seems like port B or F would be the way to go; the other ports are either in that extended I/O space that slows down access or not all of their pins are exposed on the Arduino. B would probably be the best choice since keeping F free would be nice in case we ever decide to use analog inputs or outputs in the future, but it's totally up to you! Let me know which port you choose and I'll go through and change the code accordingly so that you can focus more on the hardware.

Rewiring everything should be pretty simple; tedious but simple. Just connect PD0 to pin 0 of the port, PD1 to pin 1 of the port, and so on up to PD7.

When cutting the traces, make sure to cut them between the Arduino and LS280 parity generator, not between the parity generator and the 26-pin ProFile connector! We need to keep the LS280 connected to the data bus, and cutting it out of the circuit would screw things up. From what I remember when I first made this thing a year ago, MacWorks would still work since it doesn't care about parity, but LOS would not be happy!

[mg-man]

I just created a 2/10 branch and added you as a contributer so that you can update things with any changes that you might make.

Cool, thanks!

Thanks for offering to give these mods a shot; I've been really stressed with school and this defintely relieves some of that stress!

Well don't stress about this!!! I have a pretty demanding job, so I have to dip in and out of this as well. If I sound a little annoyed at times, it's a) probably work-related ;-) or b) just really wanting to figure out how to make this to work. I could not have possibly done what you've done myself, so I'm grateful you did and eager to see if we can created a 2/10 compatible implementation! :-)

There's an image showing you the different ports on the Arduino Mega.

Thanks for that! I did a bit of Googl'ing, but always landed on much more complicated diagrams - this one is much clearer for what we need (find another - hopefully faster - port).

we can't use A anymore because that's where I hooked up the status LED

Glad you said that. On the 'complicated' ones I did find, I compared them to my boards and it did look like Port A was in use (and connected to the LEDs), so I was a little confused given your initial comment about Port A vs L above. This clears it up and also confirms I'm looking at the right things on my board. :-) If we DO get this working, maybe you can move the LED control to Port D for example - which appears to be in proximity to the LED placement, meaning A could be re-purposed. Maybe that will make the routing simpler like it was for Port L? Let's see if I can get it working first tho. :-)

Let me know which port you choose

Will do. I'll work out where the connections to Port L come and go and then which alternate Port to aim for. Tell me something, though... looking at the image above, I can only see 5 pins for Ports D & E, 4 pins for Port G? Am I reading this correctly? If so (and assuming we need 8 pins = byte-wide), that means our choices are B or F only. I'll go for B as you suggested, but let me know if I have this right.

When cutting the traces, make sure to cut them between the Arduino and LS280 parity generator

Hee, hee... I did spot some were going to the LS280, so wondered about that - thanks for the clarity!

It might be a day or three before I get stuck into this, so focus on your studies and enjoy the weekend!

[mg-man]

Just connect PD0 to pin 0 of the port, PD1 to pin 1 of the port, and so on

SO... re-reading this. Am I correct that all I need to do is locate the traces that go from PDx to Port L and sever / replace those? If so, I didn't solder in a Debug Header, so this might end up being a relatively tidy bodge! LMK

[mg-man]

B would probably be the best choice since keeping F free would be nice in case we ever decide to use analog inputs or outputs in the future

Well... I sat down to have a look at this and discovered an issue with using Port B. From looking at the board (and schematic) it looks like a few of the pins on Port B are used for the uSD card adapter. :-/ Can you confirm?

As for Port F, it's marked as "ANALOG IN" but you mention it above, so it can be used for 'digital' (logic) as well?

Lastly... I've realised I can modify one of my boards without making ANY cuts. All I need to do is omit pins 42 - 49 of the header, and then wire PD0 - PD7 to the Port F pins - right?

[alexthecat123]

To answer your question about certain ports only having a couple pins, it's because they didn't wire every pin on the ATmega2560 to a pin on the Arduino. I'm not sure why they did this (maybe they didn't have enough space to do all of them), but this is why some of the ports only have a few of their pins exposed.

Darn, you're totally correct about the SD card! Clearly I didn't look at the schematic very closely, lol. So I guess port F is our only option. And yeah, the analog pins can be used as both analog and digital pins, so we should be good to go there!

And that's a really clever way of rewiring things! I didn't even think of that as a possibility, but it's definitely the smartest way to do this! Just make sure that PD0 goes to pin 0 of the port, PD1 goes to pin 1 of the port, and so on. Otherwise, we would have to do some painful modifications to the code that would probably slow things down to the point that it wouldn't even work on the 2/5!

I changed the code in the 2/10 branch to reflect the change to port F, so you can just upload that to the Arduino whenever you're ready to test things!

Good luck and let me know how it goes!

[mg-man]

Thanks for getting back on all that. Glad I'm able to make some sense of this. 😀 I'd already decided to embark on using PORTF.

After a false start which ended up being a bad microSD adapter, I managed to get the modded one built. Here are some pics:

Moment of truth... attached it to a standard Mega, got the 84... drat!! So... tried it with my go-faster Mega... and...

Woo woo!!! But... I'm not sure why it isn't seeing any of the images I have on the SD card - there are two, and I know they work on my IDEFile and one of ArcaneByte's BeagleBoard-based ProFile emulators. Any ideas?

[alexthecat123]

WHAT? It actually worked? I honestly wasn't expecting that, but that's so awesome! Great work! As for the error message that you're seeing there, I get that occasionally too, even when using a real Cameo/Aphid. I have no idea what causes it, but you should be able to get past it by choosing the B(oot option. If that doesn't work, try the S(tart over option, and if that still doesn't work, try Q(uitting to ROM and then booting from the ArduinoFile again.

It's definitely able to read the contents of the SD card because the emulator would halt itself and turn the LED red if it didn't detect an SD card. Also, you wouldn't be seeing that message if it wasn't able to boot from the Selector image, so I'm pretty confident that there isn't anything seriously wrong and that following the instructions above will fix things!

It kind of sucks that the overclock is still necessary to get things working, but at least it isn't a particularly difficult mod or anything. And the mod only needs to be done if you're using a 2/10, which seems to be a minority compared to 2/5 users, so I guess it's not too bad!

By the way, those are some really nice and clean bodge wires! And I love the black color of your board too; I'll definitely be ordering my next batch of boards in black!

[mg-man]

WHAT? It actually worked?

Well.... not quite it seems. I did try S)tart and B)oot but it kept coming back to the same screen. I then decided to just rename one of my LOS images to be profile.image - and it started to boot... then emitted a medium tone and threw be back to the Startup From... screen (with the tone still on). I tried another boot and this time it cleared the tone, but crapped out with a 10707 error.

I then decided to try and Repair the HD... no joy. So I then tried to just Install LOS. It 'sees' the HD and asked if I wanted to Erase, so I did. After a L O N G wait (with the Status LED flickering away) it barfed with the following :

I didn't have my laptop connected to the serial output, so tried another Erase - here's the top and tail of the log :

/* Lisa powered-on, hit reset on ArduinoFILE

Switching to the 10MB ProFile spare table.
ArduinoFile is ready!

/* Booted from LOS Install Disk 1 and chose "Install"

Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
Phase 1: Host didn't respond with a 55! Maybe the drive was reset?
000000000A03
00FFFFFF0A03
0000000D0A03
000000020A03
000000070A03
0000000C0A03
000000010A03
000000060A03
0000000B0A03

---

0100002D0A03
010000220A03
010000270A03
00FFFFFF0A00
0000002E0A03
0000002E0A03
0000002E0A03
0000002E0A03
0000002E0A03

So, as they say, "close, but no cigar"

Been a long day... I might try with a 5Mb ProFile image tomorrow. Also... I have some 74HCT280s on order - just to try.

Let me know if there's anything else you can think of.

[alexthecat123]

Well darn. Never celebrate too early I guess. That output is identical to what I get when I do an install on a 2/5, so it looks like it's receiving all of the command bytes properly now. I remember LOS being very picky about timings when I was first designing this thing; believe it or not, MacWorks worked fine on the very first test I ever did, but the Office System took a couple weeks of work to figure out. I wish I remembered exactly what timings it was unhappy with....

To go any further, we probably need to look at a logic analyzer trace. I'm not sure if you have a logic analyzer, so this might be the point where I need to just build the updated version and mess around with it myself. I'll try to design an updated PCB (and clean up that monstrosity of a schematic that I drew when I was still new to PCB design) as soon as I can and then I'll see if I can figure things out. Unless, of course, you have a logic analyzer and want to try it yourself. I wish I wasn't so darn busy with school right now!

I doubt that the HCT280s will fix things since the original ProFiles themselves used LS280s, but it's definitely worth a shot! I also didn't think that switching to port F would make this much of a difference though, so what do I know?

Maybe give it a shot with MacWorks and see what happens there. If it works okay, then that sort of confirms our theory that it's a LOS-specific issue.

[mg-man]

Well darn. Never celebrate too early I guess.

Yeah... but I consider a step forward. Small victory, but the war is still to be won. 😀

That output is identical to what I get when I do an install on a 2/5

Interesting... including the Stop Sign fail? Maybe you're on the edge with timing on the 2/5, and I'm now getting to the same point with the 2/10? 🤔 In addition to the HCT280s, I'm debating on boosting another of my 2560s to 22.1184 MHz - which is a better match for serial port speed conversion. It will mean I need to build my own bootloader - or use a USBasp (which I'd need to get), hence the debating...

Something else I found that may be worth a go is this - https://forum.arduino.cc/t/digitalwritefast-digitalreadfast-pinmodefast-etc/47037 - any thoughts?

To go any further, we probably need to look at a logic analyzer trace

Yeah... I figured we might be on that path. Sadly, I don't have one. It's also a shame we're on opposite sides of the ocean - making sending you one of my boards cost-prohibitive. 😞

Thanks for sharing your experiences, it sounds like we're heading in the right direction and maybe some of the above will get us there. I'll start with the HCT280s, then attempt another clock boost, and will give MacWorks a spin. LMK what you think about those DigitalFast routines.

[alexthecat123]

Yeah... but I consider a step forward. Small victory, but the war is still to be won. 😀

I guess you're right! It's definitely working better than it was, so we're taking some steps in the right direction!

When I said that I got the same output on the 2/5, I was referring to the ArduinoFile debug stuff over serial, not the error message. It would've been really bad if I got that error message on the 2/5 as well! What I was trying to say is that it's clear that we're properly receiving the command bytes now because they perfectly match the command bytes from a successful install on my 2/5.

I had no idea that you could overclock the Mega past 20 MHz, so it'll be really neat to see what happens if you bump the clock speed up a little bit higher! Assuming it's not too much of a pain for you, I'd say go for it! We're clearly pretty close to getting it to work and that additional 2 MHz might be enough to do it!

I just took a look at that forum post and unfortunately that won't really help us here. That library is basically providing a wrapper over direct port manipulation that's way faster than the default digitalRead and digitalWrite, but still slower than direct port manipulation. But unfortunately we're already manipulating the ports directly. That's what all of the weird code like "PORTF = 00001111" is for; we're directly writing values to the port registers to maximize speed instead of using more programmer-friendly functions like digitalWrite or the digitalWriteFast that you linked to. Plus, writing an entire byte to the parallel bus is much quicker and easier with direct port manipulation since you can set all 8 bits with one line of code instead of having to do a bunch of digitalWrites in a row. So good idea, but unfortunately it would slow things down.

Since you don't have a logic analyzer, I'll just design some new boards and get them ordered as soon as I have time. I would just modify one of my existing ones, but it's probably better to go ahead and order some with the new design. I'll have to do a redesign eventually, so might as well go ahead and do it now!

Good luck with the HCT280, clock speed, and MacWorks experimentation!

[mg-man]

When I said that I got the same output on the 2/5, I was referring to the ArduinoFile debug stuff

Thanks for clarifying. So you have been able to Erase/Install LOS, good to know it should work.

So good idea, but unfortunately it would slow things down.

No worries... I'm pretty sure I spotted at least one DigitalWrite in the code, but no DigitalReads. On further inspection, looks like you're only using it in the setup section and for the LED.

I had no idea that you could overclock the Mega past 20 MHz

😀 When researching this... I saw mention of ppl claiming 30Mhz works! I'll try 22.1184 since I do want to be able to see the debug info, but might also look into fitting a socket of some kind to enable further experimentation. BTW, speaking of debug, are there any commands you can enter from the serial interface?

I'll update you once the new parts arrive.

[alexthecat123]

Yeah, all of the digitalWrites in the code are in parts that aren't very time critical. I decided against direct port manipulation for those parts because it makes things a little easier to understand.

And wow! 30 MHz?? That's insane and I bet it's really pushing that ATmega2560 to its absolute limits! And as for the serial interface, unfortunately there aren't any commands that you can enter, at least in the emulator mode. There's plenty of stuff that you can enter when it's in tester mode, but not when it's being used as an emulator. Are there any debug commands that you think I should add in the emulator mode?

[mg-man]

Yeah, all of the digitalWrites in the code are in parts that aren't very time critical.

But you're also using DigitalWrite to manipulate the LED color, so, that code is getting hit pretty often. As a test, I decided to cut out the LED interaction by commenting out the lines in setLEDColor :

void setLEDColor(bool r, bool g, bool b){
// digitalWrite(red, r);
// digitalWrite(green, g);
// digitalWrite(blue, b);
}

Doing so still didn't allow me to get any further with the Selector, but it seemed to increase the speed of the Erase. I was able to successfully Erase a 5Mb Profile image, but when trying to install LOS, it failed saying there was not enough room on the HD. I was trying LOS 7/7 a.k.a. 3.1, I don't have diskettes made up of anything older (smaller?). I next tried booting my LOS 3.1 image (a 10Mb ProFile image). That started, gave the rectangle with the hourglass, did the brightness change, then crashed with a 10707 error. (which was what I was getting before commenting out setLEDColor). The 10707 seems to be to do with writing to the ProFile - which is similar to the error above. Trying to Erase the 10Mb image also failed like before, so I guess I conclude that the setLEDcolor - even though it's using DigitalWrite - is not adding excessive overhead.

A couple of other questions... can you confirm you're using Dedicated SPI to interact with the SD card? There's a comment in the SDFat library readme about Dedicated SPI being WAY faster than the default(?) Shared SPI :

Here is write performance for an old, 2011, card on a Due board.

Shared SPI:
write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
294.45,24944,1398,1737

Dedicated SPI:
write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
3965.11,16733,110,127

...and lastly, have you tried exFAT for the SD card? I'm going to try it, but just wondering if you tried and found issues?

[mg-man]

I'll just design some new boards and get them ordered as soon as I have time.

Coming back to this... since (I think?) you only need a few pins for the LEDs, maybe you can use Port D or E for the LED and then use Port B instead of F - saving F for future use as you mentioned above.

And wow! 30 MHz?? That's insane and I bet it's really pushing that ATmega2560

I've ordered both 22.1184Mhz and 27.648Mhz - we'll see what happens!! :-)

[alexthecat123]

Disabling the LED stuff shouldn't make much of a difference in terms of performance. The standard digitalWrite is slow compared to direct port manipulation, but it's still quite fast in the grand scheme of things (it takes less than a millisecond), so leaving that in should be fine. I think I even measured boot times with and without the LED (as well as with and without the serial output after each command) and they were pretty much identical.

Also, I am indeed using dedicated SPI. Interestingly enough though, any speed penalties incurred by the LED, serial output, or SD card shouldn't have any effect on the issues that we're having. This is because the ProFile (or ArduinoFile in this case) is capable of setting the pace at every point in the communications sequence except for the actual sending/receiving of data. Whenever the host changes the state of /CMD to tell us to do something, it has to wait for us to correspondingly change the state of /BSY before it can move on to the next step. The actual data transfer itself is where the host sends the super fast /STRB pulses and just assumes that we'll be ready when the next one comes along. Since all of the SD card accesses, LED toggling, and serial printing occur in the parts where the drive can regulate the speed by controlling /BSY, they don't really play a role in the issues that we're having.

I don't think I've ever tried exFAT, but that's a pretty good idea! It's probably not going to fix the problems we're having, but it very well may speed up disk operations in general!

I'm working on redesigning the board right now and I've moved the bus from port F to port B, just as you suggested. And the LED is now hooked into port D. I'm not quite done yet and the next couple days are going to be pretty busy school-wise, but hopefully I'll get it done soon!

Good luck with the crystal experimentation; let me know how it goes!

[busterswt]

Nice work, fellas!

Past experience testing with a 2/10 demonstrated that commenting out DEBUG messages throughout the code (the printData functions) resulted in some minor speedups. Now that you're using a faster port, maybe it would be enough to push you over the edge?

https://github.com/alexthecat123/ArduinoFile/blob/main/proFileEmulator.ino#L1153-L1205

[mg-man]

commenting out DEBUG messages throughout the code (the printData functions) resulted in some minor speedups

Interesting... I'll try that. Did you spot I have my Mega running at 20Mhz? 😀 Going to try 22 or 27Mhz this w/e if I can find time. 🙂 Wish me luck!

[mg-man]

So... I'll let the pictures go first :

That's the 34Mb MW+ image booting on my 2/10. I did comment out the calls to printDataNoSpace that weren't associated with an error message, and this is running on my 20Mhz Mega. I opened ZTerm, MacWrite and Zork I with no apparent issues.

So... I guess this points to something quirky on the "LOS" side? Thoughts anyone?

I do have a non-o/c'd (16Mhz) Mega, so I might try MW+ with that. FWIW, I also tried some LOS 5Mb images, but those give me the 10707 error on my o/c'd Mega. Last of all, I am working out how to o/c another of my Megas, but want to do this in a way I can swap crystals... stay tuned.

[mg-man]

Going to try 22 or 27Mhz this w/e if I can find time.

So... spent way too long hacking another of my Mega's... including lots of swearing when frustratingly small pads were lifted... but... perseverance paid off and I now have a socketed variant :

...and, yep, that's 22.1184Mhz! :-)

To recap...

CoreMark Performance Benchmark - Standard Mega - 16Mhz
2K performance run parameters for coremark.
Total ticks : 14657
Total time (secs): 14.66
Iterations/Sec : 7.50
Iterations : 110

CoreMark Performance Benchmark - 20Mhz
Total ticks : 12485
Total time (secs): 12.48
Iterations/Sec : 8.81
Iterations : 110

CoreMark Performance Benchmark - 22.1184Mhz
Total ticks : 11290
Total time (secs): 11.29
Iterations/Sec : 9.74
Iterations : 110

Unfortunately... still no joy with LOS. Grr.... but MW+ loads just fine.

It turns out going to 27Mhz is going to be a significant effort, but it looks like 24Mhz is a pretty easy option - so going to order some crystals and give that a spin. I can't help but wonder if there is something more than just raw speed that we're running into... I'm now running almost 40% faster than stock. :-|

[alexthecat123]

I did comment out the calls to printDataNoSpace that weren't associated with an error message, and this is running on my 20Mhz Mega.

Interesting! Have you tried MW+ without commenting those calls out? If you left those calls in and it didn't work, then that would be pretty weird!

Unfortunately... still no joy with LOS.

Darn! At this point, I think it's got to be something to do with timing as opposed to raw speed. It's looking like the 20MHz upgrade was helpful, but anything above that hasn't seemed to make much of a difference. We're definitely at the point where we need to take a look with a logic analyzer, but I have no idea when I'll get the chance to do that. I had a bit of a reprieve from schoolwork near the end of this past week, but now things are back in full force again.

[mg-man]

Have you tried MW+ without commenting those calls out?

Just did. Worked fine with the 20Mhz Mega.

Darn! At this point, I think it's got to be something to do with timing as opposed to raw speed.

It does seem that way. I'm currently hacking with optiboot to see if I can configure it for my 27Mhz crystal so I can give that a spin. We'll see how much luck I have - will report back.

I had a bit of a reprieve from schoolwork near the end of this past week, but now things are back in full force again.

No worries... that trumps these shenanigans... ;-)

[mg-man]

I think it's got to be something to do with timing as opposed to raw speed.

Just making sure you caught it... When booting LOS, the initial phase with the rectangle / hour glass displays (lots of LED activity on the ArduinoFile), then there's a brightness change, then it drops back to the "start from" panel with a 10707 error. Looking at one of the online resources, it shows :

10707 | Cannot initialize the File System volume

Could it be there are there two 'phases' to LOS startup (the second phase causes the brightness change) and it's something in the second phase that's catching us out?

[alexthecat123]

When booting LOS, the initial phase with the rectangle / hour glass displays (lots of LED activity on the ArduinoFile), then there's a brightness change, then it drops back to the "start from" panel with a 10707 error.

Are you booting LOS 2 or LOS 3? I always get that exact error when I boot LOS 2 (even on a real ProFile or a Cameo/Aphid) and I just have to retry the boot a couple times to get it to work. LOS 3 doesn't have this problem and always boots just fine. If you're getting that error with LOS 3, then clearly there's something wrong. I don't really know anything about the LOS boot process, but it could very well be that there are two separate phases. I know that there's an externally-callable ProFile read/write routine built into the Lisa ROM and maybe the OS uses that in the first phase, but switches over to some custom routine that causes problems in the second phase? That's just a total guess though.

[mg-man]

LOS 3. I've tried several "3" images... my own 3.1 (10Mb image built on this Lisa) as well as the 5Mb "3" you have in your G.drive. I've not tried over and over... will do that.

I don't think I've tried LOS 2.... will do that as well.

Lastly, I think I've managed to build a bootloader for 27Mhz... will let you know how that goes.

[mg-man]

OK, so... more testing, but, unfortunately, still no victory.

I tried LOS 2 and this resulted in a repeating boot-loop - the Lisa would start to load LOS, the brightness change would happen, then after a longer pause than I'd seen with LOS 3, the Lisa hard-reset back to the Power-on Diagnostics. It would then try again, with the same result. Hitting the space bar during the Diagnostics was the only escape. I was trying this with detail messages & LED off -- so should have been running with minimal overhead.

I then tried LOS 3, same behaviour as before, except the crash to Error 10707 seemed to happen sooner after the brightness change. Looking at the log, however, there seems to be a similar period of activity (about 10 seconds) before the crashes. I turned on print messages for a couple more attempts to see if there was anything meaningful captured. Curiously, it appears the initial failure in a session happens right after the "magic" block read, whereas subsequent attempts seem to make it past this, and even past a successful(?) WRITE?

Here's a concatenated / commented log of these attempts :
ArduinoFILE log - 29Jan22.txt

I then decided to move onto MW+ and see what was being spat out with the print messages enabled. Well... it crashed!! Huh? So... I went back and disabled the print messages and copied over a fresh MW+ image since the crash corrupted the one on the uSD card. :-| This time I was able to boot - yea! Feeling brave, I decided to purposefully "write" something to the HD by opening up the "test" document and doing a "Save As"... Well... that led to a System Error. :-|

Here's a concatenated / commented log of these MW+ attempts :
ArduinoFILE log - 29Jan22 - MW.txt

I'm not sure what to conclude from this... there does seem to be a lot of "Resetting drive..." going on - especially with MW+, but you'd now better than me whether or not that's to be expected.

I haven't yet been able to get my Mega running at 27Mhz, so that's still on my list if I can make that work.

[i-to-z]

8 months later .... I bear great news!
I got the ArduinoFile to work on a Lisa 2/10. It works relaiably and stable, and NO overclocking of the Arduino Mega is necessary.
TLDR: Just change the compilation level from the default "-Os" to "-Ofast" and recompile the file proFileEmulator.ino in the branch 2/10-Testing; no code changes are needed.

Hello Everyone, my name is Ivan.
I've been observing this project with great interest, and the stars aligned just right for me to play with this awesome board.

Here is my setup:

• ELEGOO MEGA R3 Board ATmega 2560 board for $20 from Amazon. I put the quartz on a socket so that I can overclockit, but it turns out this is not needed.
• HiLetgo 5pcs Micro SD TF Card Adater from Amazon.
• The SD card is SanDisk Ultra 16GB microSDHC, speed rating 10, says "speed up to 80MB/s, 533x" on the packaging, from ebay, costs just a few bucks.
• Hitachi HD74S280P parity chip salvaged from an old Apple 2 board.
• PCB board from JLPCB (come with a min qty of 5), with the jumper wires soldered to use PORTF instead of PORTL for the data bus.
• Apple lisa 2/10 (has the faster VIA chip on the I/O board).
• I am connecting the ArduinoFile to the internal IDC26 parallel connector (where the 10Mb widget drive goes).
• I am powering the ArduinoFile from 5V on the power supply for the widget drive, but any power supply should work.
• My Lisa has the "rominator" switch that allows me to switch between a List 5 "H" rom and a Mac "3A" rom. Why is this needed: Lisa OS 7/7 works well only with the "H" rom, shows a garbled screen on the "3A" rom because the screen resolution is different from what the software expects.

All of the following works on Lisa 2/10:

• Booting Stapleton's cameo aphid "selector" image (using Lisa H roms) and from there booting Lisa OS 7/7.
• Booting Lisa OS 7/7 (using Lisa H roms) , launching the few available apps, changing few folder names to confirm that "write" functionality also works.
• Booting MacWorks XL 3.0 (using Lisa 3A roms), launching the few available apps, changing few folder names to confirm that "write" functionality also works.

How to change the compilation level :

• First, find the location of your file "platform.txt": In the Arduino IDE: In File->Preferences I checked the "show verbose output during compile and upload" checkboxes to output the location of the platform.txt file . My file is (on Ubuntu linux) is at /home/yada/.arduino15/packages/arduino/hardware/avr/1.8.6/platform.txt
• Edit file platform.txt and replace the 3 occurrences of "-Os" to "-Ofast".
• Recompile and upload.
• This is it.

I want to say that I am quite familiar with the code now. I made extensive code changes (with limited success) before arriving at the solution above. I would like to clean it up if you, Alex, are ok with that. Obviously, I have many more ideas, e.g. to remove the parity chip and to calculate the parity signal usign software.

Awesome project, I am really impressed.

Note: I also have built Stapleton's Cameo aphid board, but it's software stack is way too much more complex for me; the Cameo board often hangs for me on this Lisa during boot or after boot, and I wasn't able to make any progress on that.

[alexthecat123]

Wow, that's absolutely awesome! I have a really busy schedule with school this week, so I'll try to respond in more detail in a couple days. But I just wanted to let you know that I did indeed see your comment and I'm not ignoring you or anything!

[mg-man]

8 months later .... I bear great news! I got the ArduinoFile to work on a Lisa 2/10.

WOW!! Awesome! I'm also pretty time-poor atm (work - boo!), but I will ABSOLUTELY be checking this out as soon as I can find the time. Thanks so much for the update!

[alexthecat123]

So I just tested things with the Ofast flag and sure enough, the ArduinoFile now works perfectly with the 2/10! Great work with figuring things out; it's awesome that it ended up being such a straightforward (but obscure) fix!

From my testing, your fix even works with ArduinoFiles that use Port L for the data bus instead of Port F. So people who haven't done the Port F modification can get their ArduinoFiles working with the 2/10 without any hardware mods at all!

Aside from the Port F versus Port L thing, there seems to be some other difference between the code in the 2/10 branch and the code in the main branch because the main branch code won't work with the 2/10, even with the Ofast optimization. It's been so long since I've played with the 2/10 branch that I'm not sure where the difference between the two files occurs, but definitely use the 2/10 branch for now if you want to try this yourself. Once I get the chance, I'll update the code in the main branch to the version that's currently in the 2/10 branch and maybe delete the 2/10 branch entirely as well.

In the process of messing around with the 2/10 stuff, I found a bug in the code. I'm not sure when it was introduced, but the if statement that encompasses the Serial.println(F("Resetting drive...")); line should have PINL replaced with PINC. This is supposed to check to see if /PRES is asserted, but at some point I accidentally changed it so that it checks to see if bit 4 of the data bus is asserted instead. Which leads to some serious slowdown during operation. I'll be fixing that and pushing the changes to Github as soon as I get the chance!

And yeah, I'm absolutely okay with you going through and cleaning up the code! I'm not a programming expert or anything (heck, I don't even have any formal CS education), so I'm sure there are plenty of things that you could do to make it cleaner and more optimized! Now that we know about the whole Ofast thing, maybe the Arduino will actually be fast enough to handle parity calculations without the external parity chip, so absolutely give that a try as well!

Thanks again for your efforts here; I'm so excited to finally have 2/10 compatibility! If you'd like, I can credit you in the readme and the source code itself because your work here has made the ArduinoFile way more useful for way more people!

Alex

[i-to-z]

Alex, could you post the link that suggests that Port F is faster than L? And is there a simple test that can prove/disprove that it's faster?

About the "Resetting drive" bug:
I was seeing the "Resetting drive" message ONLY if I remove all interrupts-related code (setting up the interrupts 4 and 5 pins, calls to sei(), cli()). Then, If I comment out this section of the code, it works great, and is as-fast as before. My point is that the interrupts-related code is unnecessary and should be removed. WDYT?

Also: I will email you directly, as I want to hear your vision and plans for this project; I want to help, but don't want to overstep.

Cheers!
Ivan

[alexthecat123]

So I wasn't actually the person who discovered the "Port F is faster than Port L" thing; mg-man was the one who found that piece of information. Here's the link to it!

Yeah, we might be able to get rid of the interrupt-related code. I'm pretty sure that setting up the interrupts to pins 4 and 5 of that port isn't even needed anymore; that was left over from an earlier revision. The sei() and cli() calls are in there to (presumably) speed things up by disabling interrupts during time-sensitive portions of the code (but we have to enable them again before a Serial.print() because it supposedly uses interrupts), but they might not be needed either!

And a little bit of unfortunate news: even with the Ofast optimization, the ArduinoFile doesn't seem to work with the parallel card. I'm not sure if this is because I'm using Port L instead of Port F or if it's something else, so would you mind trying your ArduinoFile with the parallel card? I don't have any ArduinoFiles that have been rewired to use Port F, so I would really appreciate it if you could test with a parallel card for me!

[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.