exxos's Atari, Amiga & retro forum

Does anyone know of a blitter accuracy test program that'll run from AltRAM?

Basically I need it to thrash the blitter from & to AltRAM but check the results.

I know of the blitter BGK tester, but I'm not sure that's relevant yet and also the blitter 'bob' demo with visual timing, but that only works from ST-RAM.

I'm (perhaps foolishly) trying to support blitting into AltRAM again and I'm getting artefacts when menus close. Would like something more quantitative to be able to infer what's amiss.

Cheers,

BW

I've got the CPX that allows you to set programs to run from TT-RAM - is there anything that
will do the same for ALT-RAM?

@Cyprian created some blitter test PRGs for the Blitter recreation project. viewtopic.php?p=92943#p92943

There are a few littered in that thread @Badwolf

Icky wrote: 27 Jul 2024 05:41 @Cyprian created some blitter test PRGs for the Blitter recreation project. viewtopic.php?p=92943#p92943

There are a few littered in that thread @Badwolf

Cheers! I'll have a nose.

It did occur to me overnight that since I see the problem blitting menus to and from the screen, I could probably simply write my own program and simply use the VDI blit commands to mimic the behaviour.

BW

Darklord wrote: 26 Jul 2024 23:36 I've got the CPX that allows you to set programs to run from TT-RAM - is there anything that
will do the same for ALT-RAM?

Thanks. Changing the flags isn't the problem, though. If the program doesn't know about AltRAM, though, asking it to run there can result in the screen being allocated there & then nothing works (that's the issue with the bob test).

BW

PS. as per our other discussion the OS doesn't know the difference between my style AltRAM and TT style AltRAM -- it's all the same 'AltRAM' to it so those flags apply to both.

Okay, it was just a random thought.

Hmm, so to keep this clear in that (mostly empty) storage space that I try to pass off as my head,
am I reading things that, using the SI (System Information) CPX, if I set the flag on a program to
TT-RAM, and I have the STorm-ST board with it's ALT-RAM, that the program will then execute
from the ALT-RAM? Or will it do nothing at all?

Thanks. :)

Darklord wrote: 27 Jul 2024 19:29 if I set the flag on a program to TT-RAM, and I have the STorm-ST board with it's ALT-RAM, that the program will then execute from the ALT-RAM? Or will it do nothing at all?

There are various program flags:- https://freemint.github.io/tos.hyp/en/g ... am_20flags

The two that reference altram are the second and third flags.

The first of these allows the OS to load the program into AltRAM. Basically if enough AltRAM is available, it will then be loaded there. If it's not, it'll fall back to ST-RAM. If it's not set, it'll only ever load to STRAM.

The second one controls how the default Malloc() call works. If the program allocates memory from the OS using the default Malloc() call, this determines if it will be from AltRAM by preference, or only ever from ST-RAM.

The program may override this second flag by using the extended Mxalloc() call. It tends therefore, to be less important than the first flag, however you could imagine a scenario where it's useful:

Say you have a game or piece of software that has no knowlege of AltRAM, but sets up double-buffering for its screen. If it uses the default malloc() to get those memory blocks, then setting the program to run in AltRAM but alloc from STRAM would let it work nicely.

This rarely applies, though and normally any software that does funky stuff on the screen (eg. games) end up having to be run from ST-RAM.

BW

I wrote a simple program that prints some text down the screen to give me something to look at then:

1) blits the entire screen to ST-RAM
2) blits the entire screen to AltRAM

3) blits the AltRAM version back to the screen
4) loops back to 3 unless a key is pressed, when it:

5) blits the ST-RAM copy back to the AltRAM buffer
6) goes back to the loop in 3).

What this has shown is it's the blitter write operation into AltRAM that shows inconsistencies. A word here or there is not properly written. The image is stable in the tight loop showing that read is reliable, but if you press a key to trigger a rewrite to AltRAM you can get patterns of 16 px messing up on the screen.

These corruptions tend to fall in specific places which I'm guessing come at the end of the blitter cycle. Perhaps I'm picking up an erroneous write? Is the timing of the blitter write cycle a bit off?

I've not been able to improve things much by adding delays here and there, but interestingly delaying the onset of the write operation by even 15ns (one 66MHz clock cycle caused by me using a sampled UDS/LDS rather than the async input) causes many more errors to appear. Still in relatively fixed patterns, though.

I'm going to go looking for a blitter hardware manual, but I suspect I shantt find that much. I may have to read through all the various blitter diagnostic threads, much of which I don't follow.

Does anyone (@Icky, @ijor?) have any blitter write timing information that's not a trade secret they can point me towards?

Cheers,

BW

Badwolf wrote: 29 Jul 2024 12:35 Does anyone (@Icky, @ijor?) have any blitter write timing information that's not a trade secret they can point me towards?

I will elaborate later. In the meantime, is your Verilog code that implement this feature available?

ijor wrote: 29 Jul 2024 14:54

Badwolf wrote: 29 Jul 2024 12:35 Does anyone (@Icky, @ijor?) have any blitter write timing information that's not a trade secret they can point me towards?

I will elaborate later. In the meantime, is your Verilog code that implement this feature available?

Thanks Ijor.

This is my altram controller: https://github.com/dh219/DSTB/blob/altr ... au_sdram.v

Called from the top level here: https://github.com/dh219/DSTB/blob/altr ... 68k.v#L147

Cheers,

BW