dml attempts a Raven

[agranlund]

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've currently got all of the RAM slots populated but since I'm using hardly any ram for what I do I'll take one out to match your configuration.
(I have been using only 1 and 2 sticks before though)

My current rom stick is populated with SST39LF802C, my other one has SST39LF401C.

I quite frequently boot a very minimal system and sometimes just mono and without NOVA driver, but that being said I pretty much always run RVBIOS.PRG.
And for those kinds of minimal-boot occasions I'm basically going directly to EmuTOS console to parcp over cross-compiled something to run (driver or related low-level stuff where I expect to fatally crash and reboot often hence the minimal boot and no need for fancy-anything )

[dml]

@agranlund thanks for the last 2 posts & extra info - would be very interesting to know if you (or anyone else!) can repro any of the effects I see on a clean boot to mono-desktop EmuTOS with no RVBIOS.

Specifically: double-click on random .TXT files under M:\DOCS on the default ROM drive, repeatedly (and click or hit key to scroll then exit).

Sometimes each TXT view returns to the desktop with a fresh directory listing. Most often it returns to an empty window, but clicking on the window causes the icons to suddenly appear. Occasionally viewing the .TXTs will LineF and halt either while drawing the text chars, or on returning to the desktop. Sometimes it just LineFs on the desktop while opening dialogs/menus but less often.


I re-inspected the board under microscope after cleaning. Found some tiny stray solderballs/splashes on the underside of the board which i removed. None looked like a short but still better removed. Top side is clean, still no bridges or other issues. Washed it again (some stubborn flux still there), drying again, will return to it when dry for more tests.

[PhilC]

I can replicate the empty directory that then populates once I scroll the window. I just presumed it was a graphics or Emutos driver issue.

[dml]

I can replicate the empty directory that then populates once I scroll the window. I just presumed it was a graphics or Emutos driver issue.

Thanks - that's one more thing I don't need to worry about :p

But presumably, no LineF fun at your side?

[agranlund]

One thing just occured to me that might be worth knowing, but I have no idea if relevant to this particular scenario.

I have been meaning to, but haven't gotten around to implementing the suggested workaround for 68060 Rev.5 load/store bug.
The easy fix for that is just a setting in the PCR register that disables load/store buffer bypass optimisations.

Speaking of, I should probably look at the errata documents for all cpu revisions to see if there are more suggested workarounds to implement for that and other revs too.. I don't know what bugs the earlier cpu revisions had but I'm under the impression they had a few until reaching rev.6 (or 4 in the case of LC)

[agranlund]

Specifically: double-click on random .TXT files under M:\DOCS on the default ROM drive, repeatedly (and click or hit key to scroll then exit).

Hmmn. I can not replicate the empty directly phenomenon (nor crash).

Tried without IDE attached. First franticly viewing text files on the rom drive and then same on the ram drive.
Then with my regular IDE attached but without loading any acccessories or auto programs. No luck reproing on the rom drive nor with text files on the IDE drive.

This was with some WDC graphics card attached but no drivers loaded, so just mono and EmuTOS being responsible for VDI.
I can test again with an ET4000 later on.

My ROM is from latest code so newer than what you would be running but I wouldn't expect any of the recent changes to have an impact on that kind of stuff. Nevertheless, I'll try to find a time to update the release zip this evening just in case.

Long shot, but could you run just "cfg" in the monitor to list the config params?
(mon.tos on the romdrive, or pressing the nmi button to get to the monitor over serial)
I'm looking for the off chance st_ram_cache or tt_ram_cache is set to copyback mode or something like that (0 is writethrough and should be default unless changed or there's a bug somewhere )

[dml]

I don't know what bugs the earlier cpu revisions had but I'm under the impression they had a few until reaching rev.6 (or 4 in the case of LC)

I first noticed the LineF panic on the Rev. 6 CPU. I only switched it to LC afterwards in case that CPU was faulty in some way. I will switch back to the Rev. 6 for re-testing though.

[dml]

Quick update, after reassembling etc.

I did the test suggested by @dhedberg - to leave it running for a period to see if it crashes without interaction.

The answer is no - it's been running for 30 mins now without any problems. Occasionally I move the mouse around a bit (but without activating the GEM dropdowns or opening windows - just moving the pointer). No crashing. It's still running.

However before that, I did a different test - deliberately causing window/text redraws - and produced 2 more crashes very quickly. See attached pics.

The one thing that seems to be in common in all cases is rendering TEXT.

[edit] ---- could this be trying to use LineA $Axxx ops for drawing and sometimes spuriously getting $Fxxx instead?????


One of the crashes just involved moving the mouseptr back and forth across the dropdown menus. One was in the middle of a .TXT print refresh. While the second case involved access to M:\, the former case did not access disk.

So it seems like there's a problem talking to the gfx card or something else involving drawing text from ROM. (It might not be limited to text but it always seems to involve text drawing).

This is with the original config - Rev. 6 CPU back at 40/80MHz.

[dml]

@agranlund

Here is the result from the MON cfg check.

[update]

I tried dumping & disassembling a long sequence of memory locs using MON and just letting it scroll for a while. I'm not seeing crashes from that, despite it rendering lots of text. <-- that was short lived, did crash eventually

mon1.jpg (486.73 KiB) Viewed 1342 times

mon2.jpg (408.75 KiB) Viewed 1342 times

[PhilC]

I fired up the Raven to see if I could emulate your issues and well, now it's broke

Gets as far as intmfp and nothing else, #annoying