ST536 STE EDITION

[Badwolf]

I should say I don't recall exactly which firmware is flashed at this point, I'm afraid. Probably best to flash the current one so you're in a known working state.

[exxos]

I should say I don't recall exactly which firmware is flashed at this point, I'm afraid. Probably best to flash the current one so you're in a known working state.

Yeah I have flashed the version what is currently compiled my computer

It's run through 10 passes on GB6 running from alt-ram so far...

Using C_DIS seems to screw up the ROM to RAM copy.. I hope recall @dml mentioning something along these lines will memory is very vague here... That disabling the cache could screw up 32bit access or something ?

I'm running GB6 from your IDE card (copied from floppy to c:)

Not simple to check mono as I need to go find my VGA monitor (but can do that later)

But is there anything specific to me to try which shows up the problem you was having ?

When I find my CF card, ill run DOTT...

[dml]

Using C_DIS seems to screw up the ROM to RAM copy.. I hope recall @dml mentioning something along these lines will memory is very vague here... That disabling the cache could screw up 32bit access or something ?

Is that a hardware-side cache inhibit signal?

TBH disabling the cache shouldn't cause problems. The problems only begin when the cache is re-enabled and has stale contents.

I don't remember what consequences there are (if any) for inhibiting cache from the HW side but it would normally only be applied statically on the same memory areas - fixed address decoding for hardware register areas etc. - so mismatching cache/ram contents can't really happen.

If you start inhibiting the cache selectively/randomly though at any fixed address, you could start to get interesting problems.

[exxos]

Is that a hardware-side cache inhibit signal?

Yes, it prevents the ROM to TTram copy from working, it just comes up address errors, no idea why.

The problems only begin when the cache is re-enabled and has stale contents.

True, only changing it with power turned off anyway.

IMG_3954.JPG (213.11 KiB) Viewed 385 times

[exxos]

@Badwolf

DOTT seemed to run fine..

IMG_3957.JPG (306.84 KiB) Viewed 385 times

[exxos]

No problem in mono.

IMG_3958.JPG (324.67 KiB) Viewed 376 times

IMG_3960.JPG (350.51 KiB) Viewed 376 times

However I am getting this problem which is a problem I had years ago during my DMA research...

IMG_3959.JPG (351.83 KiB) Viewed 376 times

So I need to look into that now

Odd thing is only seems to happen when copying from IDE to floppy... I can copy floppy to floppy fine .. no errors..

EDIT:

So I flashed CURRENT18 and so far that problem seems to have gone.. So maybe I broke something in the current (unreleased) firmware.. I need to check what I was doing..

EDIT2:

Ah might be as I was building ST firmware and forgot where and what I was doing with it all now

EDIT3:

Yep that was it!

So I will retest everything, but I can't find anything wrong with your stuff so far @Badwolf ..

Well other than that odd C_DIS thing.. and ROM in TTram might not survive a reset, but that's not a big issue for now as its not on my radar of things to do currently.

EDIT4:

OK spoke to soon maybe as its just locked up on a GB6 test.. I wonder if it's because I just changed the firmware ..hmm... Oddly seems fine again but will leave it on for a little while...

EDIT5:
So I was poking around the board and pressed the simms and it locked up.. so ill investigate that.. ill start by cleaning the simms with IPA..and parity simms!

EDIT6:
Done that and poking doesn't cause any crash now..
Onward with more soak testing..

EDIT7:
Nope locked up again.. maybe it was the firmware difference then..

[exxos]

Been running for the past few hours now...

EDIT: Now on loop 80 - turning it off now

IMG_3970.JPG (19.29 KiB) Viewed 343 times

I think it is a clock sync issue.. As originally I had the clocks in perfect sync and it was causing problems so I backed off a bit.. I had notes of this in various iterations of the firmware going back at least several revisions..

For some reason @Badwolf machine is acting differently to all the others, and not sure why, but also coincidentally it has allegedly "Good DMA" so maybe thats a factor as most machines have a -38.

Anyway I'd adjusted the clock sync again and it seems to be behaving fine now..

[Badwolf]

I was about to say 'bloody typical' that my machine suddenly starts working the minute it hits the debug desk.

...but if it's acting up now then I'll say 'bloody typical' that my machine is misbehaving!



And no, there wasn't really anything specific. Nothing really was stable. DOTT inclusive.

BW

[exxos]

I will do more tests tomorrow but it seems stable how it is now.. so there isn't really much else I can do unless something trips up.

It does however raise the odd thing as to why rom copy fails when cdis is closed though. I've no idea about that one. But my 536 does exactly the same as well.

Also notice that your jumpers are a pretty loose fit and probably not making good connections. I've has the same with those taller jumpers and tend not to use them much now.

EDIT:

OK that's odd.. my original TOSCOPY.PRG copies fine, but my code in TOS doesn't like when CDIS is closed..

I think the only difference is I used longword ROM copy in later builds, and the builds which work are WORD access..

I will have to build some new copy routines tomorrow to see if longword is the problem.. Though I would have assumed longword copy to ROM should be fine anyway It could just be masking a deeper problem, but no idea what.

[exxos]

I did a quick copy routine in STOS to longword copy ROM to TTram and its currently copying... But it's not going to be as fast as assembly code. So probably not a fair test.

oh.. now its scrolling bus error.. that's interesting... BUT STOS itself has crashed scrolling that error.. it's not a runtime error in my program where it simply quit...

WORD copy was well strange, STOS scrolling all sorts of errors and corrupted the screen and crashed .. never seen that before! So thats win I guess

It runs for a while before it errors, so maybe is a length problem.

Shaved off a few bytes in the copy length.. $FFFF0 is the end of the copy clock was $FFFFC before...and same problem..

It shouldn't matter me copying 512K.. hmm.. Well lets try $7FFF0 then... That copied fine ..

The upper 512K should just copy from the ROM anyway.. It would either copy the upper 512K bank, or wrap around and copy the lower 512K bank.. I'm to tired to work that out But point being, eitherway.. it shouldn't matter what the data is..



I think I'm getting confused with all the ranges. I think in STOS I'm copying 1024k.. But my 68k code copies 512k block..