Advanced search  


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 [2] 3 4 ... 10
 on: May 11, 2022, 06:28:30 pm 
Started by dmark - Last post by dmark
Do you have advice where good test points for each voltage rail is?

I think this is still "current"  ::) ...

...nice one! (the joke, and the voltage measurement guide)

Now, the 5V rails look fine... But the 12V rails seem way out of whack on the I/O board. +7V and -17.5V respectively.  :o
Which is weird, because before I measured a clean +12V on the Lite Adapter board, so I assumed that the same rail was ok elsewhere!
Just to make sure, I pulled out the Lite Adapter board again and measured on the floppy header, and am still getting a very neat +12V there.

So... at least I have a concrete issue to track down. It's almost as if 5V is being subtracted (or negative voltage added I guess) to the 12V rails!?

 on: May 11, 2022, 05:44:19 pm 
Started by blusnowkitty - Last post by rayarachelian
I have SuperDrives installed in all four of my Lisa's, and they function exactly the same as 800K drives.  The only benefit is that the SuperDrives are newer and a little more reliable mechanically.

Well, you're using them for at most 800K access so you wouldn't see any difference in normal use. (BTW, perhaps you could document how you've wired them to work with the Lisa's controller?)

However, they are capable of reading and writing ~2x the rate of normal drives, which means that the heads are going to be more sensitive. Now this might be done by increasing the data rate of the shift register used, and/or playing with the speed.

In general some later read/write heads also have an erase coil that runs just before the r/w head - this erase head is going to be wider than the r/w head so as to leave some space around to prevent data bleed to other tracks. So when the heads go off center, you wind up with that drive being mostly able to read/write from its own disk and do a marginal jobs of accessing media written to by other drives.

This gap is what we're after:

Code: [Select]
Assuming a liner track, it might look like this:

             trk1            trk2
   | gutter| data | gutter | data | gutter |
   | gutter| data | gutter | data | gutter |
   | gutter| data | gutter | data | gutter |
   | gutter| data | gutter | data | gutter |

Now when trying to do data recovery, we don't care about the erase head at all, and the width of the track, we just want to access the data:

Code: [Select]
Here XX's show mechanical damage to data:

   | gutter| data| gutter |
   | gutter| data| gutter |
   | gutter| daXX| gutter |
   | gutter| daXX| gutter |
   | gutter| XXXX| gutter |
   | gutter| daXX| gutter |
   | gutter| daXX| gutter |

In this second case, using a more sensitive head, and purposefully forcing the drive head to go off center, can recover the "da" data bits, but not the XXXX case. This is a moonshot ofc, damage is not always going to be offcenter, and could span multiple tracks depending on the geometry of the damage. But you might be able to get some more data out of it than not.

And yes, I am suggesting that you modify the drive to get at the data. This is called microstepping. This is a step too far perhaps for some as it will render that drive usable only for recovery use. Also, you may need to change this in both directions - once to be slightly to the left, then try to read multiple times and see if you get different data, and then once to the right, again, with repeated attempts to read the damaged areas.

This will give you a whole bunch of data that's going to be different (and fail checksum). So next you'd have the massive task of trying each of those passes to see if any got you further or not.

If you take a look at the opposite problem, on how fully destroy magnetic media, you see that multiple write passes are required with various patterns. This is so you remove any left over signal. see:

In conventional terms, when a one is written to disk the media records a one, and when a zero is written the media records a zero. However the actual effect is closer to obtaining a 0.95 when a zero is overwritten with a one, and a 1.05 when a one is overwritten with a one. Normal disk circuitry is set up so that both these values are read as ones, but using specialised circuitry it is possible to work out what previous "layers" contained. The recovery of at least one or two layers of overwritten data isn't too hard to perform by reading the signal from the analog head electronics with a high-quality digital sampling oscilloscope, downloading the sampled waveform to a PC, and analysing it in software to recover the previously recorded signal. What the software does is generate an "ideal" read signal and subtract it from what was actually read, leaving as the difference the remnant of the previous signal. Since the analog circuitry in a commercial hard drive is nowhere near the quality of the circuitry in the oscilloscope used to sample the signal, the ability exists to recover a lot of extra information which isn't exploited by the hard drive electronics (although with newer channel coding techniques such as PRML (explained further on) which require extensive amounts of signal processing, the use of simple tools such as an oscilloscope to directly recover the data is no longer possible).

Using MFM, we can go even further than this. During normal readback, a conventional head averages the signal over the track, and any remnant magnetization at the track edges simply contributes a small percentage of noise to the total signal. The sampling region is too broad to distinctly detect the remnant magnetization at the track edges, so that the overwritten data which is still present beside the new data cannot be recovered without the use of specialised techniques such as MFM or STM (in fact one of the "official" uses of MFM or STM is to evaluate the effectiveness of disk drive servo-positioning mechanisms) [7]. Most drives are capable of microstepping the heads for internal diagnostic and error recovery purposes (typical error recovery strategies consist of rereading tracks with slightly changed data threshold and window offsets and varying the head positioning by a few percent to either side of the track), but writing to the media while the head is off-track in order to erase the remnant signal carries too much risk of making neighbouring tracks unreadable to be useful (for this reason the microstepping capability is made very difficult to access by external means).

Now the difference between using highly specialized equipment and doing the above is that reading a 0.95th of a "1" signal is that we lose the indication that it was 0.95 and not 1. A fact which might have proven useful when doing data recovery. In other words, we don't have access to the analog levels of the bit strength which might provide a clue.

Imagine the magnetic media gets scraped by something, but not fully all the way down to the plastic part of the cookie. So maybe, think of it as a road with a pothole, but it hasn't gone down all the way to sand. If the road were magnetized, there might still be 25% of the media there, and its orientation is still readable.

But because the circuitry past the head has a discriminator that wants a whole 1 or whole 0, you cannot read this "1" bit and get a zero bit instead. This is the big issue here. But if we had access to analog levels with some degree of sensitivity, the original data might be recovered.

OFC, when the road is scraped all the way down to the sand layer underneath the concrete and asphalt, there's no way to get at the direction of the tiny magnetic fragments as there are none to see.

So this would give you maybe a 10%-20% chance of improvement.

Now if you were to build your own analog floppy controller and make it very sensitive, well, that would increase your chances a lot more. This is very difficult and would need a lot of processing power as well as a lot of code to write, but would allow us to recover a whole lot more. You may also need to do other things like read the data a lot more slowly, etc. and have some way to distinguish between different types of damage.

And ofc, the unmentioned thing here is dirt. Cleaning both the drive heads and the media is useful. However we have to be careful to not dissolve the media or damage it by doing this. I'm not an expert in this area at all, so not going to comment on IPA vs other substances, and leave that to those who have done it before. It's certainly possible to clean the media and then read it and recover it as well as causing permanent long term damage such that it won't be readable again some time in the future. This is going to be the same argument for/against retrobrite on cases, etc.

Final edit: all this said, this is theoretical, I personally don't know if you can modify a 2M Sony SuperDrive so the track is slightly off center, perhaps someone here has done that repair and can help describe it.

 on: May 11, 2022, 03:39:08 pm 
Started by blusnowkitty - Last post by Lisa2
maybe there's other things that can be done, such as using a 1.44M Apple SuperDrive floppy to read them which has a narrow head..
Not to muddy the waters here, but I don't think size of the head is any different on a SuperDrive.  SuperDrive's have the same TPI and number of tracks that standard DS drives have.

I have SuperDrives installed in all four of my Lisa's, and they function exactly the same as 800K drives.  The only benefit is that the SuperDrives are newer and a little more reliable mechanically.

 on: May 11, 2022, 03:00:04 pm 
Started by blusnowkitty - Last post by pintoguy
Thanks @stepleton.

If Al Kossow is reading this, can he provide more detail ? Perhaps a hard error count (e.g formatted capacity of a blank floppy) before and after wiping. I'll try to gather such data myself and will report.

 on: May 11, 2022, 02:41:43 pm 
Started by blusnowkitty - Last post by stepleton
In re IPA, I looked back into some old discussions. Al Kossow (who has tersely advocated against IPA here) says elsewhere that in his experience, it damages the binder (that presumably attaches magnetic media to the substrate), and I assume not the plastic itself.

Lubrication is cited as an additional cyclomethicone benefit, although it obviously cannot help this way once it has evaporated away.

 on: May 11, 2022, 01:58:57 pm 
Started by rayarachelian - Last post by rayarachelian
Recently, Ubuntu had a new LTS, 22.04, which switches the sound system to PipeWire. This is in the long term a good thing, however, previous versions used pulseaudio, and before that OSS, and before that ALSA.

With PulseAudio, an OSS proxy package was provided that allowed applications that used OSS's dev tree muxes/dsp end points to allow applications expecting them to work on PulseAudio.

Unfortunately there's some issue/bug/other with the current 22.04 release. After installing OSSPD (the proxy package), I've noticed that the sound implementation in wxWidgets will lock up a mutex permanently when a wave file is being played in a loop. Unfortunately this is the method I use to generate sound on LisaEm.

So the effect is that whenever the Lisa plays a sound, LisaEm will permanently lock up.

A bunch of this is related to wxWidgets not supporting anything else, and on GTK requiring SDL for wave playback. There's a note that says wxWidgets requires SDL for this, which is less than ideal as it requires me to link in yet another library that's not quite large, but misused as SDL also does graphics and other things that are unused.

Sound seems to be a second class citizen in wxWidgets currently, and for backwards compatibility this is also an issue. All it can do is play a single wave file at a time, optionally asynchronously, and optionally looping the same sound. If another sound play call is issued the current sound stops playing. This works ok for windows and macos without SDL (I think), but never for GTK+ (Linux, *BSD, *Solaris). There were some discussions in the wxWidgets forums about this, but nothing has been implemented. So I'm leaning either for a workaround, or a replacement.

Unfortunately since my current daily driver development machine runs Linux this is a blocker.

Since I'm getting ready for a prod release, this is a problem as it requires a new, mostly untested, solution.

There's what I'm looking at as strategies:

* change the wave file size I'm using to several seconds instead of using looping - this would require more memory use and a work around, but it might work, haven't tested to see if I can stop the sound early successfully if it's something like 5-10 seconds of a wave file.
* directly talk to SDL and see if I can produce working sound that way.
* switch to OpenAL or SoundVox, and a few others - of the two, OpenAL is the smallest and most widely compatible - leaning to this as well. There's a small snag here, OpenAL is no longer provided for modern macos, however it does still compile there, and can run fine. No telling if it will still work in the future, but it's no different than X11 or OpenGL support. As part of Apple's war on all things GPL (including bash, and gcc) and closing off source code they've removed this as well in favor of proprietary frameworks.
* directly targeting the PipeWire calls is not an option, as I'd like to avoid writing platform specific code as much as possible and worse, elder Linux and other OS's that may use ALSA, pulseaudio, OSS, JACK, etc. would then also need yet another exception to work.

Ideally I need something that can play multiple wave files in the background (floppy, widget, imagewriter, etc), but also optionally constantly play sound data preferably without having to create a wave file either in RAM or on disk and then calling the play function. Something like a circular buffer that I can feed new values from the shift register of the VIA to generate sound - like a mixer or the way classic macos does.

The sound output of the VIA is just 1 bit, so it's an 8 cycle (8 bits in SR) timed square wave pattern at a specific volume so perhaps a synth output would be a good shortcut so I don't have to manually generate a large repeating buffer in memory with it.

 on: May 10, 2022, 11:14:51 pm 
Started by sigma7 - Last post by sigma7
"What if I don't know the address that is causing the bus error?"

More Difficult Bus Errors v.2022-05-15-A

There may be circumstances when you don't know the address causing the bus error. For example, you may not be able to get into service mode because the hardware isn't working well enough to get there.

In this case one has to troubleshoot solely by examining what the hardware is doing.

On startup, the ROM does not expect to encounter any Bus Errors in a working system until the point where expansion card slots are tested and found empty. Since this is the last step of the self-test, a bus error generated during the self test due to a problem with the Lisa hardware is likely to be the first bus error that occurs.


This is straightforward to troubleshoot with a logic analyzer, so assuming that one is not available...

If an oscilloscope is available, one can trigger off the Bus Timeout signal on the CPU board (eg. U15B pin 9). Then use the other channel to probe signals of interest just at/before the time the fatal bus error occurs after reset.

If an oscilloscope or logic analyzer is not available, you are likely in advanced difficulty mode and will need to be creative. Even with an oscilloscope the following may be helpful for efficient troubleshooting...

Disable the bus timeout delay
  • If the problem bus error is the first encountered after reset, then one can disable the bus timeout by grounding pin 8 of U15B on the CPU board. In this configuration the CPU will wait forever for the problematic bus cycle to complete, and one can investigate the state of signals with even a simple voltmeter or logic probe.

Extend the bus timeout delay
  • If the bus error is not the first after reset (eg. occurs while loading an operating environment), then the bus timeout may be extended instead of disabled.

    On the CPU board, U15B pin 8 is the signal that resets the bus timeout timer. As long as pin 8 is mostly low (perhaps toggling rapidly between low and not quite low), the CPU is executing bus cycles normally. When a bus error is in progress, pin 8 will rise in voltage to approximately 3.3V which then triggers the bus timeout (the voltage at pin 8 will be changing slowly as the timeout capacitor charges). If the timeout delay is long enough, one has time to investigate signals around the Lisa.

    During the long timeout delay of the problematic bus cycle, one can disable the bus timeout as described above.

    The 556 timer's formula is generally 1.1RC
    The stock values of C9 = 0.01uF and R3 = 5.1K give a time constant of 56 us
    To increase the time to approximately 1 second, one could change R3 to 100k and C9 to 10 uF

    While experimenting with a long delay (~60 seconds), the Lisa would reset at the end of the self test, as if in power cycle mode. It is not clear whether this is due to ROM programming (ie. this signifies power cycle mode) or some unexpected consequence of using a long bus timeout (more testing needed).
Eliminating the bus error caused by an empty expansion slot
  • If the problem bus error is the first to occur after checking expansion slots, it may be desirable to disable the bus timeout and have the slots appear populated (so they do not generate bus errors).

    The straightforward solution is to install 3 working expansion cards, but if that is not possible, one can make an empty expansion slot appear populated with a ghost card by adding a diode to assert DTACK when the empty slot is accessed.

    To do this, one diode is required for each slot to be affected; the cathode(s) (banded end) connected to /SLn on the CPU board:
    • U13F-15 for slot 1
    • U13F-13 for slot 2
    • U13F-11 for slot 3

    All of the anode(s) is/are connected to DTACK:
    • U3A-1 on the CPU board

    This modification prevents a bus error due to an empty expansion slot from occurring during the self-test. At the end of the tests there may be an error message showing "bad expansion slot card", which is due to the ghost expansion card not having a valid identification ROM; regardless of this error, one can then proceed to the startup-from menu and continue to load an operating environment.

Double Bus Faults

There is a more unusual hardware error called a "Double Bus Fault"; this is what happens when another bus error occurs while trying to handle a bus error exception (ie. what would be an endless loop of bus error exceptions). A Double Bus Fault causes the CPU to halt and stop attempting to process instructions. A Double Bus Fault caused by hardware is probably due to some problem with the core bus cycle logic on the CPU board, in which case it is likely the Lisa will not run at all. The procedure above to troubleshoot Bus Errors is probably useful in this case too.

A Double Bus Fault can also be caused by software. eg. if the bus error vector (@ $000008) points to unmapped space, or address $8 is unmapped, presumably due to an error in MMU programming, then a bus error will result in a Double Bus Fault.

edit 1: 2022-05-14-A Substantially rewritten due to erroneous thought that bus errors may occur before empty slots are encountered
edit 2: 2022-05-15-A Updated after testing ghost expansion card modification, formatting adjusted in an attempt to improve readability

 on: May 10, 2022, 10:29:09 pm 
Started by dmark - Last post by sigma7
how do you test the CPU board in operation? Is there something like an extender board to run the computer with the card cage outside the case?
There's no such extender board, sorry. You might be able to create one ...

General purpose off-the-shelf commercial extenders tend to be quite expensive, and you'd need two for the different sized connectors, so a home-made one is tempting.

An alternative to using an extender is to use the chassis wiring outside of a chassis; I've been using a home-made extender on the power/video connector for quite some time, and use a drive/keyboard cable removed from a chassis for the other connector (instead of a second extender). I think others have all the wiring outside of the chassis, but maybe that is only practical with an external monitor.

Since the signals in the Lisa are relatively 'slow' (ie. much less than 1 GHz) they tolerate a modest extension without difficulty. The fastest signal between the motherboard and chassis is the B&W video signal (~ 20 MHz) and since it is B&W it would have to degrade quite a lot before the video became unusable. On my extender I used coax for this one signal, the rest are plain wire (~ 18 AWG I think) between a (female) card edge socket and a veroboard with (male) card edge contacts. Extension length is about 8" (20 cm)

Now that one can get inexpensive boards produced in China, that may be a good way to go if someone has time to do the artwork. Perhaps there is enough interest to get some pre-orders here.

If you are tempted I would suggest:
  • Make the extender in two pieces (one with 0.100" spacing, the other with 0.156" spacing), as the alignment of the two sizes of connectors is different in the Lisa 2/5 and 2/10
  • Break out and mark the power supply voltages
  • It may be helpful to have the possibility of headers on the floppy signal extender to connect drives behind the computer. For maximum utility one could have pads for two set of headers, one pair of 26 pins for the 2/5 and one 20, one 26 for the 2/10.
  • Consider a potentiometer to reduce the speaker volume and (adjustable?) +12V power for a small fan that draws air through the PSU.

edit 1: Another advantage to using an extender is being able to adjust the PSU voltage in real-time with the actual load.

 on: May 10, 2022, 10:17:29 pm 
Started by blusnowkitty - Last post by blusnowkitty
I wonder if there's any relevance to looking at Omnis3 for Mac or if the two are completely separate codebases... I'm too tired, I'll dig into it some more later.

 on: May 10, 2022, 10:06:46 pm 
Started by blusnowkitty - Last post by rayarachelian
Wow, it really is it's own Environment.

Pages: 1 [2] 3 4 ... 10