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!

[mg-man]

Hiya, thanks for all the info.

I hope you're not taking my queries as being critical - as mentioned, I'm more comfortable with h/w vs. s/w, so not so easy to tell which path you took. It does sound like we're out of "s/w" options for speeding things up - but I will try exFAT to see if that makes any difference (but I think we both doubt it). FWIW, the HCT280s arrived, but as you expected, no difference. I haven't had a chance to test with MacWorks or XENIX, etc., so I'll give those a spin when I get a chance.

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.

Thinking about this... won't we get in this situation when Erase'ing? The reason I ask is that when Erase'ing a 5Mb proFile image, it seemed to complete, but when doing the same on a 10Mb image, it runs longer and then throws the "STOP" error screen. Does the Erase function just do things 'blind'?

Back on the h/w side... crystals arrived, so I have those to try and will report back (need to decide whether or not I want to hack another of my Mega's - or just re-hack the one I'm already using). ;-)

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!

Cool! ...glad my suggestions made sense. Is your redesign using the Teensy? Not sure if you're aware of the BlueSCSI, but Eric and Co. who did the original design (using a STM32?) have just released a v2 version https://bluescsi.com/v2 that uses the Pi Pico - which, unlike the rest of the "Pi" family, still seems to be in abundant supply and cheap - about $4 ea? I don't know if that's an option, but it does have a tiny (Pico) footprint, so might be worth a thought?

[alexthecat123]

Don't worry; I'm not taking anything you say as critical! I actually really enjoy all of the feedback and suggestions that you're giving! Sorry if I ever sound that way; if so, it's probably just my stress with school coming through in my replies!

So the "erase" function that LOS does to the drive isn't actually a special function or anything. The only commands that the ProFile accepts are read, write, and write-verify (the ArduinoFile treats write-verify as a standard write since we trust the SD card to save stuff reliably and I don't think any OSs even use write-verify in the first place). So an "erase" is simply a write command where all the bytes in a block are written with zeros (or whatever other value we choose; I think LOS might erase it by writing 2E to each byte for some reason). Since it's just a standard write, it should behave identically to any other write that we may experience.

As a fun little side note, you can determine what kind of command is being sent to the drive by looking at the serial debug output from the ArduinoFile. The command itself is represented by the first (leftmost) byte in the command string that is printed over serial. 00 means read, 01 means write, and 02 means write-verify.

And you said that an erase seems to complete okay when you're using a 5Mb image, but not with 10Mb. Does this mean that you're able to successfully install and boot LOS on a 2/10 if you're using a 5Mb image instead of a 10Mb image? Or does it fail somewhere else after the erase?

Good luck with the crystals! I have a feeling that they might just fix all of our problems, assuming the Arduino doesn't become too unstable!

As for the redesign, I was just planning on keeping the Arduino Mega for now, but cleaning up that awful-looking schematic, changing the bus to port B, and moving the LED to port D. It would be cool to use a Teensy, but the issue is that all of the 5V-tolerant ones have been out of stock for a while now. They come back in stock occasionally, but then they're gone again in a few days and I don't want to design around something that ends up being unobtanium most of the time! The Pi Pico would also be really cool (and SUPER cheap), but unfortunately it requires level shifters since it's not 5V-tolerant. Someone actually tried making a ProFile emulator with a Pico a couple years ago, but it's a work in progress and they haven't updated anything in over a year, so I'm thinking that the project might be dead. If we try the faster crystals and things still don't work, then I'll probably bite the bullet and switch to the Pico or a non-5V tolerant Teensy with some level shifters, but I would prefer to stick with the simplicity of the current solution if possible!

[mg-man]

Don't worry; I'm not taking anything you say as critical! ... Sorry if I ever sound that way

Good - and no, you don't, I just know some ppl don't like kibitzers... ;-)

and 02 means write-verify.

hmm... interesting. I don't think I've seen any 02's, but I'll keep watch. So... that "00FFFFFF0A00" that gets spat out just before the "STOP" or error is a READ, but what's with the FFFFFFs?

And you said that an erase seems to complete okay when you're using a 5Mb image... Does this mean that you're able to successfully install and boot LOS on a 2/10 if you're using a 5Mb image

I haven't tried. I think I mentioned that when I tried with my disks (LOS 7/7 aka 3.1) I got an error saying there wasn't enough space on the HD. I may have to bite the bullet and create a set of LOS 1.0 or 2.0 disks and see if that might load. I might also have a LOS 5Mb image, need to check... a couple things to try. :-)

As for the redesign ... the Pi Pico would also be really cool (and SUPER cheap), but unfortunately it requires level shifters

Ah, yeah... rats!

Good luck with the crystals! I have a feeling that they might just fix all of our problems,

You'll be the first to hear! :-)

[alexthecat123]

So... that "00FFFFFF0A00" that gets spat out just before the "STOP" or error is a READ, but what's with the FFFFFFs?

Whoops! I guess I should've explained all of the command bytes instead of just the first one! The last two bytes (the ones that are usually 0A03 or 0A00) are the retry count and spare threshold. The retry count is how many times the ProFile should internally retry a failed read from the hard disk before giving up. The spare threshold is the percentage of failed reads above which the ProFile should mark that particular block as bad and allocate one of the empty "spare" blocks to replace the bad one. The ArduinoFile doesn't pay any attention to these bytes since SD cards are really reliable and perform bad block management internally.

The three bytes in the middle (the ones that are FFFFFF in your example) represent the block number that we want to read. This number can range from 000000 to 0025FF for a 5Mb ProFile or 000000 to 004BFF for a 10Mb ProFile or Widget. So now you're probably wondering why LOS is reading from FFFFFF then. The reason for this is that FFFFFF is a special "magic" block that contains the drive's spare table. This block contains information about what kind of ProFile or Widget the drive is, the number of blocks it has, the firmware revision, the total number of spare blocks, the number of spare blocks available, the number of spare blocks in use, and the block numbers of the blocks that have been spared. It might have some other stuff too, but that's everything that I can remember off the top of my head. So block FFFFFF is basically where the Lisa reads when it wants to see the drive's overall characteristics.

The fact that the Lisa fails after reading the spare table makes me think that none of the previous writes for erasing the disk succeeded either. All (or at least most) of these writes probably failed, but the Lisa had no way of knowing since they were writes, not reads. But when we finally go to read from the spare table at the end of the erase, the ArduinoFile probably just can't keep up with the strobe pulses and sends weird nonsense data back over to LOS. This might be where the "not enough space" error is coming from; it tries to read the drive size from the spare table, but receives some strange number that's too small for LOS instead.

And don't bother with making LOS 2.0 disks or anything; Here's a Google Drive link to some ready to go hard disk images that you can copy straight over to the SD card. I've got images made for pretty much every major version of every OS that runs on the Lisa, so you should find everything you need in that zip file. And by the way, LOS 1.0 is for Twiggies, so don't bother with that one unless you're one of the lucky few who has a Lisa 1!

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