exxos blog - random goings on

[exxos]

ah crap So I will try 33pF on the clock next. Had no end of issues with that on STE boosters in the past.

IMG_0982.JPG (44.24 KiB) Viewed 1268 times

[stephen_usher]

If you look at the second set of traces from your ‘scope. The second one goes low far earlier than the first.

Is that the bus request line?

It's BR but I wouldn't read into timings to much as I was having to zoom in and out signals to capture them for best image.

It's still double the length. The timebase is the same on both images.

[exxos]

It's still double the length. The timebase is the same on both images.

It varies if you look at it in real time. I've not checked specifically , but either 2 or 3 different timings on that.

[exxos]

The first pass with 33pF worked. I have also soldered some "crowbar diodes" to the clock. This is before and after.

IMG_0984.JPG (245.07 KiB) Viewed 1253 times

IMG_0985.JPG (272.89 KiB) Viewed 1253 times

IMG_0986.JPG (399.41 KiB) Viewed 1253 times

Will keep on testing.

EDIT:

2nd pass is fine. Onto the 3rd..

EDIT2:

3rd pass is fine.. Onto the 4th..

[exxos]

So 4th pass started to see corrupt file names again But this time the names are different and its not actually crashed. So something has changed.

Capture.PNG (345.19 KiB) Viewed 1230 times

I think I will add those 2 caps back on again and see if its a combination of problems not one single problem on something. Though I think its pretty conclusive the STE doesn't like IMP Blitter chips.

EDIT:

The filenames have gone OK again now. So something is borderline still somewhere.

[exxos]

2 caps back on.. Very boring (and time-consuming) having to watch the file deletes all the time .

IMG_0992.JPG (421.62 KiB) Viewed 1217 times

Currently past 4 times..

[czietz]

Grabbed the latest EMUTOS and didn't get very far @czietz ?

I see that you've moved on before I even noticed myself being mentioned. Sorry! But I still wanted to comment on your question. The message that you got is only supposed to happen when the total folder depth for a Desktop operation (like copying files) hits 14(!) folders; which is the same limit as Atari TOS, btw.

I just confirmed that for me it works as expected:



In practice, however, considering how rare 13-level deep folder structures are, I have only hit this error when there was corruption in the file system; e.g., a folder pointing to itself, causing an apparent infinite folder depth.

[exxos]

I see that you've moved on before I even noticed myself being mentioned. Sorry! But I still wanted to comment on your question. The message that you got is only supposed to happen when the total folder depth for a Desktop operation (like copying files) hits 14(!) folders; which is the same limit as Atari TOS, btw.

That's odd then. I count 12 deep (unless i've miss counted. ) in my tree download/file.php?id=32099

But either way, it works fine in TOS all the way through the deletion, so I don't see how EMUTOS is the same when it fails ?

[czietz]

But either way, it works fine in TOS all the way through the deletion, so I don't see how EMUTOS is the same when it fails ?

Here is Atari TOS 2.06 failing in the exact same way: 13 levels deep works, 14 levels deep cannot be copied.



Hence, I'm interested in what you do differently...

[exxos]

Hence, I'm interested in what you do differently...

Maybe because I have thousands of files and folders also ?

I can probably PM you my files, it's about 62MB zipped if you want to dump that on a SD card and try. All I can say is it works in TOS, but EMUTOS doesn't.