DSTB1 - official firmware tests

[exxos]

I started this new thread because all my tests were using experimental firmware previously.

My test setup is with a H5 motherboard (no blitter) and using flashyclock for the TOS206 decoding.

Firmware as released.

IMG_0539.JPG

Tests done with GB6 with altram.prg (ran from AUTO) .

IMG_0540.JPG

I repeated this test with altram.prg run from desktop as @Badwolf pointed out, TOS seems to allocate *something* in alt-ram as the LED is flashing. I never heard TOS by default loading anything into alt-ram. So not sure if anyone else knows any more about this?

Looks like there are no change in GB6 tests.

IMG_0542.JPG

I tried running altrom.prg after altram.prg but no change. I thought then to just run altrom.prg but then the floppy goes nuts..

IMG_0541.JPG

But not sure if it's going to help with a external ROM decoder in the mix ?


YAARTTT seems ok ...

IMG_0543.JPG

[Badwolf]

I tried running altrom.prg after altram.prg but no change. I thought then to just run altrom.prg but then the floppy goes nuts..

But not sure if it's going to help with a external ROM decoder in the mix ?

Yep AltROM.PRG replaces AltRAM.PRG -- it'll simply refuse to run if run when AltRAM already active.

Not sure what's going on with the floppy, though. External decoder shouldn't make a difference as once AltROM has done its thing it takes over decoding for the CPU.

Interesting, though. That's the first time I've seen that. Run from AUTO again?

BW

[exxos]

Interesting, though. That's the first time I've seen that. Run from AUTO again?

Yep.

Something is amiss somewhere even before loading anything. I clean booted into TOS104 earlier and when I opened from floppy GB6.PRG icon was not correct. Though it only did that once and I have not been able to replicate that again yet :roll:

EDIT:

Actually same problem it seems as this post https://www.exxosforum.co.uk/forum/viewt ... =30#p84405

[Badwolf]

Something is amiss somewhere even before loading anything. I clean booted into TOS104 earlier and when I opened from floppy GB6.PRG icon was not correct. Though it only did that once and I have not been able to replicate that again yet :roll:

EDIT:

Actually same problem it seems as this post https://www.exxosforum.co.uk/forum/viewt ... =30#p84405

In TOS 1.04!?

WTF? :o

BW

[exxos]

In TOS 1.04!?

WTF? :o

WTF indeed. There must be something with the RAM tripping up as I have similar problems in the other thread with the experimental firmware :shrug:

[Badwolf]

WTF indeed. There must be something with the RAM tripping up as I have similar problems in the other thread with the experimental firmware :shrug:

So this is in 'stock' configuration under TOS1.04? That means doing 16MHz switching, but no AltRAM as, well it's TOS1.

Perhaps it's 'coming back' too quickly from DMA?

BW

[exxos]

So this is in 'stock' configuration under TOS1.04? That means doing 16MHz switching, but no AltRAM as, well it's TOS1.

Yep.

Perhaps it's 'coming back' too quickly from DMA?

Not sure. I'll take a look at your code and see if I can see anything. It is somewhat difficult to follow someone else's program in a language you are not very familiar with tho :lol: :roll:

Though I may look at the firmware build I did a few days back aswell as that one seemed to basically "work".

[Badwolf]

Perhaps it's 'coming back' too quickly from DMA?

Not sure. I'll take a look at your code and see if I can see anything. It is somewhat difficult to follow someone else's program in a language you are not very familiar with tho :lol: :roll:

Though I may look at the firmware build I did a few days back aswell as that one seemed to basically "work".

Cool. If you ignore all the SDRAM stuff, it's not that much logic.

We could perhaps add an AS_HOLDOFF term that blocks AS asserting until (say) two clock cycles after BGK goes high?

Something like

Code: Select all

wire [1:0] AS_HOLDOFF;
FDCP ff_asholdoff0( .D( ~BGK ), .C( ~CLK8 ), .CLR(1'b0), .PRE( ~BGK ), .Q( AS_HOLDOFF[0] ) );
FDCP ff_asholdoff1( .D( AS_HOLDOFF[0]  ), .C( ~CLK8 ), .CLR(1'b0), .PRE( ~BGK ), .Q( AS_HOLDOFF[1] ) );
...
assign AS = AS_HOLDOFF[1] | ( ... the other terms ... );

Only obvious thing I can think of.

BW

[Badwolf]

In TOS 1.04!?

WTF? :o

WTF indeed. There must be something with the RAM tripping up as I have similar problems in the other thread with the experimental firmware :shrug:

Had another idea. I think I've set up the FRB cookie incorrectly. I don't remember exactly, but I don't think I'm TSRing -- the FRB memory is probably being returned to the OS & subject to being overwritten.

I may have been lucky that nothing critical happened, but I think altram.prg is fundamentally wrong in that regard & needs repair work.

I'll bet that's the problem you're seeing.

BW

[exxos]

Had another idea. I think I've set up the FRB cookie incorrectly. I don't remember exactly, but I don't think I'm TSRing -- the FRB memory is probably being returned to the OS & subject to being overwritten.

I may have been lucky that nothing critical happened, but I think altram.prg is fundamentally wrong in that regard & needs repair work.

I'll bet that's the problem you're seeing.

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.