DSTB1 - official firmware tests

[Badwolf]

Maybe but that died without even loading anything. I have tried EMUTOS a few times in the mix as well.. I will try EMUTOS on my current build just to rule that out.

OK, so stock firmware + external decoder isn't stable, but it was running fine when I hacked the very first version to do TOS206 decoding, right?

Next obvious test would be to remove flashy clock, boot into TOS1.04 and run EMUTOS.PRG, I suppose.

BW

[Badwolf]

OK, after having spoken with @exxos off-thread, I'm now of the understanding that, at the moment, the only yet identified problem with the stock firmware in the test configuration is that FrontBench craps out when the music comes in.

Configuration under test is H5 with TOS1.04 and EmuTOS.PRG loaded from disc.

The most obvious thing would be that the YM chip's DTACK is still asserted when FB starts its next AltRAM cycle.

To test this, since we know there's no problem with FB *without* AltRAM, we'll deny the switching, so Exxos I'll supply a stock build bar a 16MHz inhibit. If you could please test in the above configuration on Monday and feed back, I'd be grateful.

I'll check that firmware works for me over the weekend (if it doesn't, we may have opened the lid on a different issue).

Cheers,

BW

[exxos]

Using my firmware (as I need TOS206) SLOW = 1'b0;

IMG_0555.JPG (41.06 KiB) Viewed 2682 times

Basically craps out the same as when trying "slave mode".

[Badwolf]

Using my firmware (as I need TOS206) SLOW = 1'b0;

Basically craps out the same as when trying "slave mode".

OK, that is something I was worried about and need to check this end, then. Ta.

But it's not the test config of 1.04 + EmuTOS.PRG, is it?

(I have lost trust in my AltRAM.PRG until I have time to fix the FRB mapping I consider it an unreliable way of testing )

BW

[exxos]

But it's not the test config of 1.04 + EmuTOS.PRG, is it?

I knew you was going to say that.. FB and EMUTOS don't fit on the same floppy

IMG_0556.JPG (206.85 KiB) Viewed 2677 times

Reflashed with your firmware next & TOS104 & EMUTOS.PRG

IMG_0557.JPG (225.88 KiB) Viewed 2675 times

Just the same. When alt-ram gets accessed it crashes.

[Badwolf]

Ok, grand, thanks.

That’s definitely something that has slipped through the checking process. It ought to have no dependency on processor speed.

Will take a look.

BW

[exxos]

Its like I was saying earlier . The more time the CPU spends in 8mhz the worse ram stability seems to be. Just switching to 16mhz on ram access is worse than switching to 16mhz with RAM,ROM,AS. On that basis if the CPU ran at 16mhz all the time then it would in theory work better still

But I keep forgetting how you say sdram works. But with refresh cycles in the mix and a "slow" CPU at 8mhz, then would it try and latch data at the point sdram panics into doing a refresh cycle ? 16mhz CPU might be the tipping point there. On that basis if the CPU ran a fraction faster then it would likely be more stable.

I'm starting to think it's getting more trouble than its worth with SDRAM. It was a bit fickle on the TF536 as well.

[Badwolf]

But I keep forgetting how you say sdram works. But with refresh cycles in the mix and a "slow" CPU at 8mhz,

Shouldn't make any difference -- my controller should take care of all that. But...

I'm starting to think it's getting more trouble than its worth with SDRAM. It was a bit fickle on the TF536 as well.

Too right! 80% of all my dev time has been on bloody SDRAM. That said, the price... the volume... Gah!

Did start designing a latched version of DSTB1 to try and reduce the SDRAM PITA factor, but I couldn't quite make them fit on the board (as they're unidirectional so require two 16 bit chip + control lines). I went with what I know in the end. If I had unlimited space, I'd try that next.

Screenshot 2022-05-07 at 12.15.50.png (251.95 KiB) Viewed 2634 times

(there is actually one chip on the top side and one on the bottom for 'in' and 'out'!)


But anyway, back to the point in hand...

BW

[Badwolf]

Right, @exxos. Not wishing to be 'that guy', but it works here, guv.

Stock firmware modded slightly for 206 decoding (I don't need it, but want to make sure it's in there) and proper LED flashery.

Tested, works.

OK, then hard-coded to 8MHz:

IMG_5348.jpeg (185.16 KiB) Viewed 2633 times

IMG_5349.jpeg (115.79 KiB) Viewed 2633 times

...and I've just checked and MiNT works too.

I was quite prepared to believe the H5 and STE worked differently with respect to the YM chip, but AltRAM working at 8MHz here and not there?! I wasn't expecting that.

Can you give this firmware a crack when you're back? If it doesn't work either, I'm going to have to have a proper head-scratch.

Ta,

BW

altram_68k_8mhz_206decoding_220407.zip

(10.09 KiB) Downloaded 81 times

!Message from: Moderator

@Badwolf, we have placed your attachments in-line so they display correctly in your post. Here's the how-to guide.

[exxos]

Right, @exxos. Not wishing to be 'that guy', but it works here, guv.

...and I've just checked and MiNT works too.

But you have problems still with mint at 16mhz ?

Maybe thing to do is just send you this board back for you to try. Could be that there is a bad solder joint or something on it causing the issues. The H5 works fine with PLCC or DIP 68K and the TF536. Kinda out of ideas now.