Print

[AlexTheCat123]

Great news! I just finished the code for the ProFile emulator and I plugged the device into the Lisa for the first time (I was using a USBWidEx instead of an actual Lisa to test it up until this point) and it was actually able to boot BLU off the SD card! I was guessing that I'd have to fiddle with the timings some more to get the Lisa to communicate with my emulator properly, but it actually worked first try! Now it's just a matter of trying to install LOS on it to see if it still works with a much more complex operating system!

[stepleton]

Did it work? 

If not, did you run into the issue where the ProFile sometimes has to see a $55 on the bus from the Apple even though the Apple doesn't cycle ~PSTRB?

If so, that's the same thing I ran into after moving Cameo/Aphid from UsbWidEx over to the Lisa. The boot ROM cycles ~PSTRB for those $55 bytes, but the Office System is a different story...

[AlexTheCat123]

MacWorks XL 3.0 and MacWorks Plus worked great when I tested them, but unfortunately the Office System did not. I copied an image of LOS 2.0 from my Cameo/Aphid over to my device and after a few seconds of trying to boot the Lisa just restarts itself. I tried LOS 3.0 as well and it just gives a 10707 (Cannot initialize the File System volume) error when I try to boot it.

I don't think the issue has anything to do with the cycling of STRB with a $55 on the bus because my code isn't paying attention to the strobe when checking for the $55. It only looks at the strobe when receiving the command bytes, sending or receiving data for a block, and sending the status bytes.

I tried booting into the LOS installer and initializing my emulated ProFile, but it always fails with an error saying something to the effect of "The Lisa can't write to the disk." The logic analyzer seems to show that reading from the disk is working fine, but that when writing to the disk the Lisa never lowers CMD after sending the command bytes for some reason. The Lisa then proceeds to try the write operation again two more times, with the same result each try, before giving up and showing the error message.

I also realized that I somehow completely forgot about the parity signal and it just stays low all the time. USBWidEx and the other operating systems that I've tried on the Lisa don't seem to care about this and work fine, but maybe the Office System is different?

[stepleton]

Interesting! Well, I'm sure you'll track down the error soon!

I don't actually know if the Office System is worried about parity when it reads and writes (I've never checked), but the OS does have two obvious error codes relating to parity, one for reading and one for writing:

662    Parity error while sending command or writing data to ProFile
663    Checksum error or CRC error or parity error in data read

It's interesting that the ProFile is responsible for computing parity on the bus no matter which device on either side of the cable is putting bytes there. A lookup table is an easy way to compute parity, but I'm guessing that you might find it irritating to spend 256 bytes of your available 8K. For computing parity on data from the Lisa, Cameo/Aphid uses a method described here:

http://graphics.stanford.edu/~seander/bithacks.html#ParityParallel

note the text talking about how that method "may be optimized to work just on bytes" by omitting some operations.

[AlexTheCat123]

I figured out why the Lisa would sometimes never lower CMD after sending the command bytes. It appears that the Office System will sometimes start a handshake in order to make sure that a drive is there, but never finishes it once it's satisfied that the drive is alive and well. Also, when the LOS installer reads the spare table to determine the drive type, it only cares about the identifying information at the beginning and not the table of spared blocks itself, so it just stops sending stobe pulses after it gets the data that it wants and expects the drive to time out and get back into its idle state, ready to receive the next command. I had my timeouts set to around one second, so I was waiting way too long and was missing subsequent commands from the Lisa. Unfortunately, making the timeouts a lot shorter didn't fix the "Lisa can't write to the disk" error message, but at least we're not missing commands anymore while waiting around in exorbitantly long timeouts!

At this point, I'm guessing that it probably has something to do with the parity since I don't really see much else that could be wrong.

A lookup table is an easy way to compute parity, but I'm guessing that you might find it irritating to spend 256 bytes of your available 8K.

Unfortunately, I think a lookup table is going to be my only option here. I'm already significantly pushing the limits of the Arduino's processing power and the overhead of adding a routine to calculate parity would almost certainly cause us to start missing strobe pulses. Heck, even the lookup table might be too slow. If it is, I might have to add an LS280 to my PCB to handle all of the parity stuff for me.

[rayarachelian]

A lookup table is an easy way to compute parity, but I'm guessing that you might find it irritating to spend 256 bytes of your available 8K.

You could also split the byte into 4 bit nibbles and then use only 16 bytes for the lookup table. You'd then XOR the two values.

Or more efficiently, you could do something like this from C:

Code: [Select]

parity=(!!(d & 128))^(!!(d & 64))^(!!(d & 32))^(!!(d & 16))^(!!(d & 8))^(!!(d & 4))^(!!(d & 2))^(!!(d & 1));

In Python, you can do this - though you'd probably be able to optimize it a bit, and admittedly, looks fugly. But it does work.
You can reverse (0,1) to (1,0) in every expression below to get even parity if (0,1) not compatible with the Lisa's parity circuit.

Code: [Select]

parity = (0,1) [ ((128 & d)!=0)^((64 & d)!=0)^((32 & d)!=0)^((16 & d)!=0)^((8 & d)!=0)^((4 & d)!=0)^((2 & d)!=0)^((1 & d)!=0) ]

Or (still python) if you're fine with a boolean result instead of 0 or 1, this is a bit cleaner:

Code: [Select]

parity = ((128 & d)!=0)^((64 & d)!=0)^((32 & d)!=0)^((16 & d)!=0)^((8 & d)!=0)^((4 & d)!=0)^((2 & d)!=0)^((1 & d)!=0)

This might help too: http://graphics.stanford.edu/~seander/bithacks.html#ParityMultiply if you can use a multiply in that microcontroller. This is even cleaner:
http://graphics.stanford.edu/~seander/bithacks.html#ParityParallel - in the case for the profile you can discard operations on the high bytes.

So just:

Code: [Select]

uint8 parity(uint8 data) {
  uint32 v=data;
  v ^= v >> 4;
  v &= 0xf;
  return (0x6996 >> v) & 1;
}


[AlexTheCat123]

Thanks for all of the parity suggestions! Unfortunately, they were all too slow for the Arduino, so I ended up borrowing an LS280 parity generator from one of my ProFiles instead. Now that we have parity, attempting to boot from a ready-made Office System 3.0 image still gives the same 10707 error as before, but I do get a bit farther when trying to install LOS from floppies. Now the installer is able to make it through the disk erase/initialization process, but it always fails at some point during the actual installation (the farthest it's ever made it is to disk 4). When it fails, it either gives the same "can't write to the disk" error as before or it gives a message stating that there isn't enough room on the disk, which doesn't make any sense to me. It's weird that it can boot MacWorks Plus, MacWorks XL 3.0, the Cameo/Aphid Selector, and BLU just fine, but that LOS doesn't work. Hopefully I can figure this out!

[rayarachelian]

Thanks for all of the parity suggestions! Unfortunately, they were all too slow for the Arduino, so I ended up borrowing an LS280 parity generator from one of my ProFiles instead.

Uh, that's a bit disturbing, so the q is, is it going to be fast enough to work as a profile emulator fully, if it can't do a few XORs and shifts?

Now that we have parity, attempting to boot from a ready-made Office System 3.0 image still gives the same 10707 error as before, but I do get a bit farther when trying to install LOS from floppies. Now the installer is able to make it through the disk erase/initialization process, but it always fails at some point during the actual installation (the farthest it's ever made it is to disk 4). When it fails, it either gives the same "can't write to the disk" error as before or it gives a message stating that there isn't enough room on the disk, which doesn't make any sense to me. It's weird that it can boot MacWorks Plus, MacWorks XL 3.0, the Cameo/Aphid Selector, and BLU just fine, but that LOS doesn't work. Hopefully I can figure this out!

Do you know what state in the state machine of the write it failed in?
see: http://john.ccac.rwth-aachen.de:8000/patrick/data/profile_write_cycle.png

[AlexTheCat123]

Uh, that's a bit disturbing, so the q is, is it going to be fast enough to work as a profile emulator fully, if it can't do a few XORs and shifts?

I'm definitely pushing the limits of the Arduino with this project! Adding parity calculation causes it to start occasionally missing /PSTRB pulses, but it's really reliable as long as it doesn't have to calculate parity.

Do you know what state in the state machine of the write it failed in?

The weird thing is that it doesn't fail during a write. The Office System just gives up in between writes according to the logic analyzer. When I look at the writes that occured immediately before it gives the error, they all seem to be perfectly normal, so I don't really know what's going on.

During my troubleshooting, I decided to change the spare table so that my device reports itself as being a 10MB ProFile instead of a 5MB ProFile and now the Office System installs and boots just fine! It boots up pretty fast (around 40 to 45 seconds) and it seems to be quite stable. I have no clue why making it a 10MB drive would cause it to start working, so I'll definitely have to look into this more tomorrow!

[rayarachelian]

I'm definitely pushing the limits of the Arduino with this project! Adding parity calculation causes it to start occasionally missing /PSTRB pulses, but it's really reliable as long as it doesn't have to calculate parity.

You might be good now, but it means you can't upgrade this thing or add much else to it. So it's gonna be a dead end. Might want to consider the next model up.

Do you know what state in the state machine of the write it failed in?

The weird thing is that it doesn't fail during a write. The Office System just gives up in between writes according to the logic analyzer. When I look at the writes that occured immediately before it gives the error, they all seem to be perfectly normal, so I don't really know what's going on.

During my troubleshooting, I decided to change the spare table so that my device reports itself as being a 10MB ProFile instead of a 5MB ProFile and now the Office System installs and boots just fine! It boots up pretty fast (around 40 to 45 seconds) and it seems to be quite stable. I have no clue why making it a 10MB drive would cause it to start working, so I'll definitely have to look into this more tomorrow!

This sounds more like LOS thinks the drive is shared with MacWorks, but doesn't have enough free space.
Or maybe the spare table is incorrectly formed for 5MB and reports too many spared blocks?

[stepleton]

You might be good now, but it means you can't upgrade this thing or add much else to it. So it's gonna be a dead end. Might want to consider the next model up.

I think I'm more optimistic than that!

The Lisa will eat up all your cycles while it's talking to you: ~PSTRB is a pretty demanding boss. But in between some well-defined and limited parts of the read/write cycle, the ProFile can sit there holding down ~PBSY while it thinks, and the Lisa will just have to wait or decide to time out.

The thing is that you've already implemented all of the really time-critical parts by now, and all of the bells and whistles that you might want to add (e.g. Selector compatiblity ) are things that the Arduino will do while ~PBSY is asserted and the Lisa is waiting. I think the little microcontroller will be able to accomplish a lot in those intervals. Sure, it'll have limits --- it won't be able to run Doom in the background and send dithered bitmap frames down the parallel cable for the Lisa to render on its display, something which is definitely not a gimmick I've been thinking of doing for months on Cameo/Aphid --- but virtually all "reasonable" extras should be doable, i would think.

[AlexTheCat123]

The thing is that you've already implemented all of the really time-critical parts by now, and all of the bells and whistles that you might want to add (e.g. Selector compatiblity ) are things that the Arduino will do while ~PBSY is asserted and the Lisa is waiting.

Exactly! Any additions that I make will take place at times when we can hold BSY low for pretty much as long as we want and I won't be adding anything to the time-critical sections, so as long as the Arduino can reliably handle these timing-intensive sections as they are now, it should be able to handle things like Selector compatibility that I add later.

You might be good now, but it means you can't upgrade this thing or add much else to it. So it's gonna be a dead end. Might want to consider the next model up.

I was originally planning on using a more powerful microcontroller, like the Teensy or ESP32, but I decided to stick with a slower Arduino Mega because the Mega uses 5V logic levels and all of the faster offerings use 3.3V levels. One of my major goals with this project is to minimize the cost and complexity of the device and eliminating the need for level shifting definitely makes the hardware cheaper and simpler.

Once I figure out the strange 5MB problems with LOS, I'll get started with adding Selector compatibility. It seems like it will be pretty straightforward to implement, although the SD card library that I'm using only supports 8.3 filenames, so I'll have to figure something out there since the Selector lets you use names that are much longer than this. Maybe I'll need to find a different library that can handle longer names!

it won't be able to run Doom in the background and send dithered bitmap frames down the parallel cable for the Lisa to render on its display, something which is definitely not a gimmick I've been thinking of doing for months on Cameo/Aphid

You should totally do that! It would be so cool to see Doom "running" on the Lisa!

[AlexTheCat123]

It's finally time for another update on the ArduinoFile! I've implemented almost complete Selector compatibility, which really increases the usefulness of the device. The only things that I don't have working are modification dates when the Selector asks for information about a file (I can't get the getModifyDateTime() function in the SDFat library to work properly for some reason), the uptime counter, and the key-value store (I'm not looking forward to implementing that one).

I should hopefully be able to get the modification date and key-value store working, but the uptime counter is a bit of a lost cause. Since I have to keep interrupts off throughout most of the code to keep things fast enough, I have no way of accurately tracking the passage of time since the millis() function only works when interrupts are enabled. The Selector seems to send emulator status requests once every two seconds, so I've just settled for incrementing the uptime by 2 seconds each time we get a status request. This solution isn't ideal because the uptime will stop incrementing whenever we're not in the Selector (or when the Selector's screensaver activates), but it's better than nothing.

I just put the ProFile emulator code on GitHub if anyone's interested: https://github.com/alexthecat123/ArduinoFile

I also just finished designing a much more compact PCB that stacks on top of the Arduino, much like the Cameo/Aphid cape for the PocketBeagle. I've added a status LED, a reset button, and the LS280 parity generator to the board and I'll put the new board design on GitHub once I get the boards in the mail and test them.

[stepleton]

Congratulations on your progress, it sounds really impressive! I had wondered how things were going.

The uptime counter is not very important at all --- like the manual says, "It serves little purpose except to look 'geeky' and to demonstrate that the Cameo/Aphid is operating and responsive." If you ask me, since it can't really keep time in a meaningful way, and since keeping time isn't very useful, you ought to make it count backwards Or just animate it some other way, like

Code: [Select]

0d 00:00:01
0d 00:00:10
0d 00:01:00
0d 00:10:00
0d 01:00:00
0d 10:00:00
1d 00:00:00
I think the Selector's rate for pinging the uptime counter is a bit faster than once every 2 seconds, but I've never timed it.

I don't know how to solve the modification time problem, but for the key/value store I'd probably just hijack the filesystem on the SD card in some cheap and cheerful way. You'd have to be careful about some characters that you're not allowed to use, and I guess case sensitivity could be a problem, but otherwise it's kind of a key/value store already...

[AlexTheCat123]

Update: I finally got the revision 2 PCBs in the mail from China and they seem to work great, so I've updated the hardware section of readme.md to provide links to all the parts needed for this project and I put the new board files in the PCB folder. Now that there's a parts list and a fully functional PCB, people should actually be able to make one of these!

https://github.com/alexthecat123/ArduinoFile