LisaList2

Advanced search  

News:

2019.06.07 fixed NChat for the "Curve" theme, will eventually move it to its own page and add it to the default theme as well. Other plugins are next. see post in the Meta board for details

Pages: 1 ... 8 9 [10]
 91 
 on: October 04, 2021, 12:33:58 pm 
Started by AlexTheCat123 - Last post by AlexTheCat123
Quote
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 :D ) 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.

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

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

 92 
 on: October 04, 2021, 05:31:49 am 
Started by AlexTheCat123 - Last post by stepleton
Quote
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 :D ) 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.

 93 
 on: October 03, 2021, 10:08:40 pm 
Started by AlexTheCat123 - Last post by 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.

Quote
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?

 94 
 on: October 03, 2021, 06:49:57 pm 
Started by AlexTheCat123 - Last post by AlexTheCat123
Quote
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.

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

 95 
 on: October 03, 2021, 02:23:31 pm 
Started by AlexTheCat123 - Last post by 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

 96 
 on: October 03, 2021, 12:36:54 pm 
Started by AlexTheCat123 - Last post by 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!

 97 
 on: October 02, 2021, 12:06:12 pm 
Started by compu_85 - Last post by rayarachelian
Did Apple ever release it?

I remember MSFT successfully killed basic for the Mac ( https://www.folklore.org/StoryView.py?story=MacBasic.txt ) so they could push theirs, they had an expiring Apple II basic contract that they held hostage, but not sure if that also included a 3.0 Basic Plus version for the Lisa.

Would certainly love to see it.

For those interested, you can find MacBasic here:

 * http://macintoshgarden.org/apps/macbasic-10
 * http://macintoshgarden.org/apps/vintage-macbasic-books

 98 
 on: October 01, 2021, 07:29:11 pm 
Started by AlexTheCat123 - Last post by 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;
}

 99 
 on: October 01, 2021, 06:42:16 pm 
Started by AlexTheCat123 - Last post by 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.

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


 100 
 on: October 01, 2021, 10:04:51 am 
Started by AlexTheCat123 - Last post by 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.

Pages: 1 ... 8 9 [10]