| Author |
Message |
d0DgE
Member |
Hi there, I'm running into a curious situation here. I have a bulk of graphics data stored in several data sections "section myData,data". It's all bitplane graphics with a width in multiples of 64 bit ( i.e. 320 or 512 pixels wide ). When I assemble the whole project and run it on my OS3.9 it works like a charm. Yet, when I'm testing the same executable on a "clean setup", that is boot w/o startup sequence, a certain number of these graphics that are copied into a chipmem buffer get totally distorted. It extends to a degree that even the P61 replayer seems to be affected by this -- the tune starts to stutter. Oddly enough ALL of the gfx-data stored in chipmem sections gets displayed correctly. I switched around the binary includes in the pub-mem sections and it seems to me a location issue. For example: scenario #1
cnop 0,8
section openertexts,data
opener1: incbin "path/to/data/opener1.raw" ; bitplane gfx 320x180, 7 planes
opener2: incbin "path/to/data/opener2.raw" ; same thing
opener3: incbin "path/to/data....well you know
result in scenario #1, the 3rd gfx ( opener3) would be distorted ... trashed. Now I switched them about just to see if it causes the behavior to change scenario #2
cnop 0,8
section openertexts,data
opener2: incbin "path/to/data/opener2.raw"
opener3: incbin "path/to/data....well you know
opener1: incbin "path/to/data/opener1.raw"
Lo and behold, the gfx for "opener1" got distorted. And it's just under a plain No-Startup boot. All works fine on a booted OS3.9. My OS Startup does a "cpu cache burst datacache databurst copyback" and has the Oxypatcher running. ATM I didn't ask my folks to test it on their machines on a Non-StartupSequence Boot but the reports from the alpha testing came out all right ... at least on their OS and emulators. Is that an alignment issue ? Do I have to follow certain rules when it comes to bigger data sections on AGA ? |
d0DgE
Member |
Maybe this post by Kalms long ago brings some light into my trouble: All the classic custom-chipset DMA requires the data to be 2, 4- or 8-byte aligned (exact alignment depends on what type of DMA). Audio DMA, for instance, needs 2-byte alignment.
You might encounter this if you attempt to include a module into your program. All samples inside of the module are located at an even number of bytes from the beginning of the module, so if the module itself begins at an even address -> all samples will be located at even addresses.
Align by doing a CNOP 0,2 before including the module.
DMA will generally not fail if a non-aligned address is specified -- it simply ignores the lowest bit(s) of the address (assumes that they are zero).
I should also point out that just doing CNOP 0,1024 will not guarantee that the following chunk of code/data will be 1024-byte aligned in memory: the CNOP command aligns the code/data with respect to the start of the current section, not with respect to memory address 0. To get 1024-byte alignment, the section itself must be 1024-byte aligned. What is the situation under AmigaOS?
AmigaOS's executable-loader will load the program into memory one section at a time. Before loading a section into memory, a buffer large enough to hold the section is allocated using an AllocMem() or similar call. AllocMem() happens to always return 8-byte aligned chunks under all versions of AmigaOS so far.
So: Sections will get 8-byte aligned, and therefore a CNOP 0,2 / CNOP 0,4 / CNOP 0,8 will behave as expected.
|
d0DgE
Member |
With the words of Jayne Cobb: This is start'n to damage my calm !
Just tested the latest alpha from the Dropbox on my WinUAE under NonStartupSequence setup and the damn thing ran OK. Minor UAE issues with sprites and shit but nothing to be concerned about.
Maybe, just maybe MY system (i.e. my 64 Megs of RAM or OS software ) is corrupted and distorts the DARTA ...
|
Angry Retired Bastard
Member |
Sorry if I missed something (I may not have bothered to read it all) but are you saying that:
Bitplane data stored in public sections sometimes gets corrupted, while the same type of data in chip sections doesn't?
If so, that's not terribly surprising. :)
The public sections will some times be in chip and sometimes in fast, depending on what other memory is available (in large enough sections).
Sounds like the public stuff (or at least the relevant parts of it) ends up in chip when you boot completely, thus being display correctly, and other times it gets into public mem and stuff gets unpredictable.
Always have stuff that is to be directly accessed by the amiga chipset (not just the CPU), i.e. bitplanes, sprites and samples, in chip mem.
(Unless your music player handles samples in fastmem explicitly but that's not the case for The Player)
As for WinUAE; I have used versions where it would happily treat data in fast as if it was in chip, not sure if that has been fixed later. (and the opposite goes for code in chip which it would execute without any performance penalty vs fast).
|
Angry Retired Bastard
Member |
Hmm, I later saw the bit about "these graphics that are copied into a chipmem buffer". If you are actually copying them to chip before displaying then it should of course be all ok. Have you checked whether the data is actually correctly organized in memory? Sounds like you're overwriting it somewhere else in your code. :)
|
d0DgE
Member |
I have tried a lot of things including to force the storage sections to be in fast RAM ( section blablub,data_f ). The goal is to have gfx data stored away and move it to chipmem buffer by a CPU only copy-loop when it's needed, i.e. for blitter actions or just plain displaying the picture. Just like this:
routine:
; calling a macro ... simplifying by leaving out the measurements and modulos etc.
lea pic1,a0
lea buffer,a1
COPYTOCHIPMEM a0,a1
; dubblebuffer macro swapping buffers "display" <->"buffer"
SWAPSCREENS
rts
section gfxdata,data ; or data_f
pic1: incbin "path/to/picture.raw"
section screendata,bss_c
buffer:
ds.b planesize*bitplanes
display:
ds.b planesize*bitplanes
Have you checked whether the data is actually correctly organized in memory? Sounds like you're overwriting it somewhere else in your code. :) Since I'm not the most skilled mem-reader/writer on the planet, it is entirely possible that some chunks get trashed by some action. Is there a function in the ASM Pro that can organise this ... ( I'm dreaming of stuff like "organise imports" :D ) But when I'm trashing stored data due to bad Kung Fu, why on earth does the OS3.9 seem to handle it very well ? |
Angry Retired Bastard
Member |
Well, with a CPU-only copyloop and using the same chip destination buffers over & over again (with some of the graphics being correct and some distorted) you can probably rule out any alignment issues.
Sounds like some of your public data gets corrupted before it is ever copied. This could just as well corrupt your code and crash stuff of course but the buffer that overflows is probably closer in memory to the data (typically if you have some ds.<x> or dcb.<x> in a section of similar type.
A quick shotgun approach would be to build a bunch of different test versions where you skip/disable different parts of the code that are usually executed before displaying the corrupt graphics and then see when it looks ok again, to work out which part of your code messes it up.
If you also get it to trigger while running in AsmPro you could check out the corrupted data to see if it looks familiar (i.e. similar to data you write in another part of the code), or check which buffers are placed nearby the corrupted ones.
In the case you described it's always the last graphics that gets corrupted so I would look for effects that can write "above" their allocated memory, like CPU-"sprites" that aren't clipped against the upper part of their screen buffer. :)
|
Angry Retired Bastard
Member |
OS3.9 might handle it simply because the memory allocation for the different buffers change when "all the OS stuff" is running, meaning that you probably overwrite memory somewhere else (potential future crash, possibly after exiting the demo).
|
d0DgE
Member |
I'm actually in the process of testing one of the distorted scenes singularly.
It works fine in the ASM Pro ( to be expected ).
It works fine assembled and run on the OS3.9.
It runs with distorted data and starts to let the tune stutter on NonStartup Boot.
In another test I skipped all preceding scenes by an immediate rts when entered so that no code other than "rts" was executed in them, just to rule out any potentially bad stuff during the actual runtime.
Same result :/
[edit]
The next test was to skip even the entire story board during VBInterupt, leaving the P61 playing back the tune.
ASM Pro: OK
OS3.9: OK
NonStartup Boot: stuttering exactly at the time the image distortions would have been appeared.
next thing ... was to change tunes and re-activate the storyboard; so now I'm looking at an interesting "remix" of Leap Of Faith ;D
ASM Pro: OK
OS3.9: OK
NonStartup Boot: no stuttering of tune, distortions of the usual gfx suspects
|
Angry Retired Bastard
Member |
Could be a longshot but what about disabling the music? If that makes any difference: do you use packed samples (I guess not as it is a demo)? I once caused some crashes by not initializing a2 before initializing the player but I cant remember if that was due to me being stupid (too small decrunch buffer or something similar) or the player doing anything unexpected.
|
d0DgE
Member |
In order to test it without music I had to isolate a scene that's affected by the distortions.
Deactivated ALL P61 stuff ( code + tune ) and ran the scene just like in post #9 at the start.
The scene is simply an animation of 12 pictures that are copied from fastRAM to a chipbuffer and then
a doublebuffer routine. There's virtually nothing that would cause the overwriting of the stored gfx data because I just read from it.
no use....
ASM Pro: OK
OS3.9: OK
NonStartup Boot: distorted
...I put the word out to my folks regarding tests ... I have no idea what causes this
|
Blueberry
Member |
Maybe some uninitialized register? Try clearing all registers (except A7) to zero at the start of your code.
|
d0DgE
Member |
Nah ... no effect but it's a good idea anyway to add a general register wipe ( moveq #0,dn & sub.l an,an) to the start of the code.
Think I'll wait what the gang has to say when they had the time to test the latest alpha.
|
d0DgE
Member |
Novel tested the thing on his machine. It ran fine ... on all setups o_O.
So maybe it's my hardware config. I'm running a quite elaborate setup with a ZIV board, a Mediator ZIV, a Repulse ZII Soundcard, a Voodoo 4000 PCI and an Ethernet PCI board ...
Now perhaps this contraption, without an OS to manage it, corrupts certain parts of the FastRAM.
|
Angry Retired Bastard
Member |
Argh, that's quite frustrating. :/ Let us know if there's any change at any point.
And if you bring the machine where the issue is reproducible to Revision then it might be fun to have a go at it there (given that my own coding is finished and the booze-to-debugging ratio is ok). ;)
|
d0DgE
Member |
Positive testing confirmed by Dirtie. On his setup the stuff ran fine on all scenarios. I'll bring my Monster ( the tower with the big damn steel handle on top :) ) as it is tradition for an Easter Party :)  |
xxxxx
Member |
I don't know what the problem is, but barring faulty ram, I would guess it would be something in your code. I'd think the smartest way to track this down would be to write some kind of memory checksum calculator, calculate the checksum of the blocks (both in the original memory location, and in chip mem after the copy), and call that checksum code from everywhere, until you find somewhere where it is not correct.
it the checksum code on startup, and it fails, then it could be something in the assembler not including data properly, or the system loader failing. If the checksum is correct on startup, but is incorrect at a later point then it's just a matter of narrowing down to where it gets corrupted.
(And make sure you store all registers before entering the checksum code, in case it is a register left over from one function that is accidentally used in another function)
|
d0DgE
Member |
By now I got reports from 3 different A1200 060 setups that couldn't be much more different from another.
ALL of them reported that the latest version from the Dropbox ran FINE on a NonStartup Boot.
So, chances are that it is the config of my machine screwing up.
|
Alexco
Member |
Maybe it is just that your startup-sequence patches HDD drivers, filesystems, etc.? And that your file gets corrupted because it is hitting the 4GB barrier or something similar?
Does the file fits on a floppy disk? And then try from floppy?
|
dirtie
Member |
d0dge is this happening on your little travel-amiga with sd-card instead of hd? Maybe is that the problem?
|
d0DgE
Member |
@Alexco: it's a filedemo with approx. 2.3 MB ... so no floppy ;)
@dirtie: Imma check it out. Gotta get that Amiga up from the cellar. And even then it might not work because last time at Evoke it failed with ROM error ... ungrateful junker!
...
[edit]
so, got the old horse to run for a moment (frakkin' ROMs and dysfunct CTRL key) and ran a version
on NonStartup Boot that definitely distorted on my big machine in the same scenario.
It ran like a charm ! Was a good idea, so now we also know that it runs very fine on an 030 w/ 32 Megs :)
Since this is the 4th test machine running it flawlessly I think we can assume that the distortions are the result of some memory fuckup on my big machine when there are 4(!) expansion boards routed through the extension slot (and the processor + its FastRAM) without their libraries and configs loaded.
|
Alexco
Member |
Hmm. What happens if you start at least setpatch?
Or try to start it from a different partition?
|
d0DgE
Member |
@Alexco: I've been through all that ... I'm continuing to finish this prod as it is safe to assume that it will run on the compo machine setup. Finding out the quirks on my 10+ year old High-End setup is for leisure time which is next to non existent for a freelance coder in real life ;)
|
d0DgE
Member |
10 points to Alexco for hinting on the HDD.
I tested again on my big machine on NonStartup Boot but copying the executable to RAM: beforehand and running it from there. Lo and behold: it ran fine.
So the culprit seems to be the HDD and/or its configuration.
|
Alexco
Member |
Cool!
Now just list the setup and we will probably find the real reason.
But please finish the production first :-)
|
blakkhar
Member |
HD accesses can be limited/dangerous when the system is like a virgin (started without S-S). Think about all the limits it has when "no" software (patches) are running first.
|
