dml attempts a Raven

[dml]

Can I ask you who your dealer is?

...PM'd

[luciodra]

Can I ask you who your dealer is?

...PM'd

Ok, thank you !

[dml]

I took the machine apart today and cleaned the board very carefully for inspection again. I'm not expecting to find anything though - have done this a couple of times already (albeit without the severe WD40 + ISO + soap washing session).

The chips have been removed. I'll re-clean the pins with glass fibre brush & contact cleaner, then realign before restoring them.

I tried the other PSU this morning with no change in behaviour so that was a herring. I'll check the 3.3V rail next time I reassemble.


So... thus far I have swapped the following things - with some differences in results but always eventually throwing the LineF panic/exception using the same test always - randomly, repeatedly opening .TXT files from the 'M' ROM drive from a disk-less EmuTOS boot.

- changed the CPU (MC68060RC50 -> MC68LC060RC50)
- changed the MC68150 (Freescale FN33, Mot FN40, Mot FN33)
- changed both MFPs (ceramic pair for plastic DIP pair)
- changed the video card (ET4000AX -> Mach32 -> and back again)
- re-seated all the chips, cleaning the pins on the PLCC chips
- changed the clock from 40MHz to 48MHz (40MHz annoyed the LC CPU a lot, only rarely booting to the desktop - but when it did boot, it behaved the same way, working for a time then LineF - both chips boot 48MHz and same LineF after a time)
- changed the RAM stick (using a single stick to keep things simple, but changed to the second one)
- changed the PSU

None of this helped. Always LineF panic.

I did not change the ATF1508 but it's a 7nS new part from Digikey. Im not super excited about trying to order another one of those when it doesn't seem like it should be the cause (?)

I also did not change the ROM yet. This is worth trying I think.

I did not try putting the single RAM sim in the middle slot (vs. the last slot) although I'm not sure if that's even a supported config.

I am now also wondering - if I am the only one to be partially-populating my SIMM slots in reverse, could this be a cause? I unfortunately don't have a way to test this idea without soldering the 3rd SIMM socket and once I do that, it's messy to remove it again. So it would be a one-way decision (and I dump my fancy cooler idea). If there's any way this could be a factor though, I'd take that option. It would probably require someone else to do the test for me though using the semi-recent Nessi firmware...

Beyond that, it will be difficult to debug because its not an insta-boot fault. It's a random fault after several seconds of interaction - and always with the same LineF and the same reported PC address (although, different other register states). Maybe the stack will hold some info but it seems like it will not be the most easily accessible thing from the crashed/dead state....

[dhedberg]

Does it require interaction in form of keyboard and/or mouse or does it also crash eventually without interaction?

[dml]

Does it require interaction in form of keyboard and/or mouse or does it also crash eventually without interaction?

Hi Daniel!

This is an interesting question - I don't have a very clear answer yet. I will try harder though to get a better answer :)

I first noticed it with the PS2 mouse connected and clearly using a mouse causes a lot more interaction (packets, responses to actions running more varied ROM code, more VDI drawing/refresh in response to that etc....) so I immediately suspected the PS2 mouse support being involved (I mention this in a post from a few days ago where I think the crashes were first seen).

Later, I got suspicious and removed the PS2 mouse, trying to cause the crash using just the keyboard. I used the TOS keyboard bindings to control the mouseptr and do basically the same kinds of things as with the mouse (dropdown menus, dialogs, open windows, click on stuff) - it took a lot longer to get the LineF crash but it did occur after a time. So it is not the PS2 mouse or packets - but it may still be tied to responses to interactions.

The most reliable case is to open the .TXT files and let them scroll. Most of the time it displays the text and scrolls. Sometimes it crashes either while drawing the first page of text, or while refreshing the desktop & window afterwards. Which does point towards drawing related instability.

I have not seen a crash from just waiting on an empty desktop - but I have mainly been spending time changing things and testing with the mouse.

Anyway I should really do that test next - boot the thing and just wait patiently.... will see what happens. I'm sure it will take a lot longer, if it crashes at all - but it is quite possible that it will just sit there, working.... :)


The fact it always throws a LineF and it always seems to be drawing something at the time is very suspicious though.

[dhedberg]

I guess you could put an executable in the auto folder that invokes various parts of the VDI.
Viewing a text file also involves disk access.

[dml]

I guess you could put an executable in the auto folder that invokes various parts of the VDI.
Viewing a text file also involves disk access.

Yes, it will be easier to do some specific tests if/when I can get a disk mounted in the machine. I have been relying on it booting the ROM disk with PARCP, to get things across - but of course the LineF curse makes sure that all goes away every time :)

So I have a few things to investigate next...

- see what happens when left alone
- try again, to get FAT16 IDE disk prepared externally in order to get specific tests onto the machine which don't self-delete
- try the other ROM board (although, not expecting much from that)

I also now realise that I may currently be in a small set of 1 users trying to use the default mono display driver on the disk-less EmuTOS booted desktop, since everyone else is disk-booting the Raven BIOS by now. Perhaps this issue is the same for everyone but not being seen? That's probably a stretch but it wouldn't be the first time I trapped myself in a small set of 1 users with a stupid problem :p

[PhilC]

@dml I could do a copy of my boot CF card and send it to you and another ATF1508 10ns as well as the ET4000 PCB?

[agranlund]

Speed through messages to try and catch up on the thread so sorry in advanced if I missed some details :)

The crash PC is suspect and perhaps the best lead so far -- or a particularly shifty red herring :)
CPU doing a vectored interrupt, and getting the wrong vector number perhaps?
If D[7:0] is 0x00 when the CPU is expecting the vector number from a device then it would happily look at address 0, find exactly 0x602e0206 and try to jump there.

But it's hard to tell why at this point, or if it's just some fluke.
a) the interrupt signal itself was bogus and nothing was actually signalling the interrupt
b) a device did signal for a vectored interrupt, but something is going bad in the iack dance
c) a device did signal for a vectored interrupt, and interrupt ack is all good, but the data it put on the bus for the cpu is all pulled low for any of many different reasons (*)
d) my cpld code is to blame
e) all of the above

(*) soldering issue somewhere, timing issue somewhere, some device hogging the databus longer than expected or when it's not supposed to. CF adapter perhaps since they come in so many flavours and qualities and is going to be a bit different user to user? (Yeah I know, I'm just wildly speculating now :) )


Regarding the crash on activity I have had something similar happen here.
You mentioned opening of a menu brought back some memories of something like that happening here too doing that. It was enough time ago that I'm not sure anymore, but I think I just re-seated the graphics card and it went away.
(But since you already tried different cards I doubt that's it for you)

[dml]

@dml I could do a copy of my boot CF card and send it to you and another ATF1508 10ns as well as the ET4000 PCB?

That would be super helpful Phil - the board is drying now after hot air blasting so I don't want to reassemble just yet - but I will try to get PC-prepared CF working in it as soon as I can & report if I can get a different result with the loaded bios - maybe save you the trouble with the CF card part.

A second, known-good ATF to try would help since I only have the one to test with (and I can return it once I know the result)


Daniel's point about the crash being possibly tied to interaction - and specifically display refresh - has me suspecting the problem could be SW/FW related in fact. I should try to get the bios loaded and into a different displaymode, possibly testing with more gfx cards also... it may not be the Raven board specifically but whatever EmuTOS is trying to do by default.