exxos's Atari, Amiga & retro forum

Hi, all.

My DFB1X worked perfectly. Until today.

I admit: I have worked on the machine's shielding, to make it fit the DFB1X. Ultimately to show off here. It looks OK - but.....

I also removed the NVRAM battery and replaced it.


When I booted it up and tried to access NVRAM, it said 'CRC error' but let me configure it nonetheless. After that I never saw the error anymore.
But when I tried to boot MiNT I found out the ALT-RAM wasn't active anymore. Opened the case again, removed the shielding to make sure I did not short any jumper or so.....no change.

Maybe this NVRAM problem was related? Or not? Is there any way I can detect if MAPROM_C really did its work in the AUTO folder? Any other test I can run? I am quite desperate....:-(

IF I damaged anything, which is possible of course but not very likely (we worked on the case with the machine separated from it), I'd rather be sure and maybe save up and order a new one........if it's beyond repair.

Regards,
unlucky René

Follow-up: LED D4 never lits up. So the ALT-RAM is not accessed as far as I can see. Still hope it is some kind of weird software thingy, maybe because of a time-leap in the AUTO folder as a result of me fiddling with the battery? Ongoing

Original TOS 4.04 has no support for Fastram. I use on my DFB1 a spezial patched TOS 4.04 with Fastram support onto the DFB1 ...

YAARTTT (see viewtopic.php?f=25&t=28) will allow you to test undeclared memory.

The SDRAM is always available, TOS has to be told to use it (that's what MAPROM does -- amongst other things. Personally, I prefer the non-mapped FASTRAM prog. I like version 0.9 the best as other have reset issues, I've found).

Because it's always sitting there at 0x01000000 to 0x09000000 you can test it with YAARTTT using the secret 'M' option when it ask for 'S' or 'T' at start up.

This'll show you if you've a hardware fault or a software one.

BW

Hi, Frank and Badwolf.

YAARTTT produces errors. So there is no RAM there as far as YAARTTT is concerned.

So you might say it's a hardware failure.

But I'm still not convinced that's the whole story ;-) Could it be that some 'reset' was produced when I removed the alternative nvram board (and replaced it again)? NVRAM interfering?

Just asking because the hardware option really is expensive (I'll have to order a new one and YES it's out of stock...) and somehow I can not imagine I damaged anything ;-)

Mmm repairing would be the only route left if I can't solve this. Maybe @exxos can help a bit. @exxos are you around? :-)

R

renato3 wrote: 26 Sep 2024 10:56 So you might say it's a hardware failure.

If you run Gembench 6, what is your Integer Division time?

BW

Hi, @Badwolf !

Currently I am abroad and for the next few weeks - I won't have any access to my Falcon - so I can't tell you the exact number that Gembench 6 reports.

What I DO know (remember) is that the percentage was about 250% (compared to stock Falcon without booster) so that's why I am quite certain that the booster itself works. But the memory expansion doesn't show up.

Now I HAVE fiddled with the NVRAM replacement. It was too 'high' a profile but it was fixed by cutting just a few mm off the pins. The NVRAM does work as far as I can see from NVRAM.PRG - it successfully saves the common settings like language, keyboard, resolution. But then: could NVRAM (e.g. some contact missing or failing) have ANYthing to do with it?

Regards,
René
(I'll be back at my Falcon by around the 18th of October)

Badwolf wrote: 26 Sep 2024 21:51

renato3 wrote: 26 Sep 2024 10:56 So you might say it's a hardware failure.

If you run Gembench 6, what is your Integer Division time?

BW

renato3 wrote: 30 Sep 2024 21:51 Now I HAVE fiddled with the NVRAM replacement. It was too 'high' a profile but it was fixed by cutting just a few mm off the pins. The NVRAM does work as far as I can see from NVRAM.PRG - it successfully saves the common settings like language, keyboard, resolution. But then: could NVRAM (e.g. some contact missing or failing) have ANYthing to do with it?

I can't immediately see any way the NVRAM could affect decoding of the TT-RAM nor could interfere with *only* TT-RAM access, no.

I think a screenshot of one page of YAARRTT errors would help.

BW

renato3 wrote: 26 Sep 2024 10:56 Hi, Frank and Badwolf.

YAARTTT produces errors. So there is no RAM there as far as YAARTTT is concerned.

So you might say it's a hardware failure.

Hi @renato3, did you resolve this? What was the outcome?

René very kindly gave me his DFB1x, and I have the same result on my Falcon (which has no NVRAM issues), i.e; the ALT-RAM is not detected but the rest works fine, and it's quite a speed boost :)

I ran some more tests to see: all jumpers are open on the card, I tried YAART 0.2.3, and it doesn't detect the ALT-RAM either
Testing the range 0x01000000 to 0x09000000 using YAART's 'M' option gives tons of errors, all of them like

Pass: 1, Test #1: Address test , own address
Errors: 4242. Last error: 0x01004246 (ffff!=4244)

The "ffff" doesn't change, it's the same for all errors.
So indeed it looks like something is fried :D