Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

ggn

Members
 View Profile  See their activity

  • Content Count

    1,684

  • Joined

  • Last visited

Posts posted by ggn

  5. Posted

    Okay, my computer gave me the day off yesterday as it needed to install some very important updates, but I'm back at the helm now.

     

    What I did just now was to try and match my brownboot.o with the brownboot-old.o in post #120. I assume that one is linking fine for you. Skipping swiftly past the fact that jaguar.inc was different than the stock one and had to be recreated, I'm now able to produce a 1:1 copy of brownboot-old.o.

     

    My version is built from head (http://shamusworld.gotdns.org/cgi-bin/gitweb.cgi?p=rmac;a=snapshot;h=821279dcb7b5d069d175767edcd413b833b0cae3;sf=tgz) with the following changes:

     

    object.c: line 235 replaced with: 

    	uint16_t st_shndx = SHN_ABS;	// Assume absolute (equated) number

    lines 243 and 244 replaced with: 

    	else if (globflag && !(w1 & DEFINED) && (w1 & REFERENCED))
	{
		st_shndx = SHN_UNDEF;
	}

    object.h: the following inserted in the file (around line 35 but shouldn't matter) 

    //
// ELF special section indices (field st_shndx)
// Lifted from glibc (https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/elf.h)
//
#define SHN_UNDEF       0               /* Undefined section */
#define SHN_ABS         0xFFF1          /* Associated symbol is absolute */
#define SHN_COMMON      0xFFF2          /* Associated symbol is common */

    and that's it. If I want to match brownboot-new.o from post #120 I can do so by replacing line 561 in object.c with 

    			shstSize += DepositELFSHSTEntry(&shstPtr, "TEXT");

    and "DATA", "BSS" in lines 570 and 579 respectively.

     

    Now, again, if brownboot-old.o links ok for you then this should also link as it should produce the same object file!

    • Like 2

  6. Posted · Edited by ggn

    Hmm, that's odd

     

    image.thumb.png.a8ca6ff2fd09be6d9ea5cbcf792f9e78.png

     

    The differences start yet again on the name of the segments - old has ".text", new has "TEXT" etc. Did you apply that fix?

     

     

    [EDIT]

     

    On second thoughts, could you attach brownboot.s? I'll take a look at it here and not have to bother you.

  7. Posted

    Oh, I see. Well, v2.0.20 doesn't have the proposed fixes of this thread yet (because we're still investigating). So what you could do is to grab the latest snapshot of the source code (currently http://shamusworld.gotdns.org/cgi-bin/gitweb.cgi?p=rmac;a=tree;h=234f42879ceda29cd6a37a50ff287730f4ac632e;hb=HEAD - just click "snapshot") and then apply the things on this thread.

     

    This means posts #102 and #108. Then recompile and generate brownboot.o. I expect that with this you'll get equal sized files but with a few diffs.

     

    I hope we're getting to the bottom of this soon!

  8. Posted

    Oh hi, I lost track of this thread because I missed the edit in the last post.

     

    So, my guess that now you should be able to make equal sized brownboot.o files but with some slight differences. Could you try that?

  9. Posted · Edited by ggn

    Sorry, but the invocation is wrong, it should be:

      

    swapd0$ rmac-old -fe -o brownboot-old.o brownboot.s
swapd0$ rmac-new -fe -o brownboot-new.o brownboot.s

     

    (yes, it's a remnant from the old MadMac times, the idea behind this is that you can assemble multiple files from the command line that have different options you can switch on and off. So whenever rmac encounters an input file, it goes and assembles without parsing the rest of the arguments)

     

    (I still believe there's an issue since the register clashing is real fwiw)

  10. Posted

    Without going any further I noticed some weird things.

     

    For starters, brownboot.o:

     

    image.thumb.png.5ad44ef5b52fc29b33fc22945dd9730e.png

     

    That's 68000 code in there, and it seems that after that 4E75 (RTS) where everything starts mismatching very badly there is a "10a8 60c1 4e75" (which is move.b $6061(a0),a0) / rts) snippet inserted in the "old" version instead of just a "4ef9" which appears on the "new" version.

     

    Similarly, in gpu.o:

     

    image.thumb.png.52b9c575d9a8f6e230125c65382e4fb7.png

     

    A "0000 0000" is inserted at offset $78 which seems to derail the whole binary afterwards.

     

    The other two sets of .o files seem to be an identical match, but I'm puzzled about these two. It seems like they're assembled from a different version of the source codes. Is it possible that this is the case?

  11. Posted

    11 minutes ago, swapd0 said:

    Done, ".text" changed for "TEXT", and the same for data and bss

     

    Now the file size is sightly bigger (290,932 bytes) but still smaller than the one using old rmac. The labels are still clashing.

    Are you able to diff a few object files now?

  12. Posted

    I just realised that I actually have some of these files since they're from dml's tiny startup code - d'oh!

     

    So I tried assembling brownboot.s using a pre-2.0.0 version of rmac, as well as the latest with all the the above proposed fixed applied. Then I binary diffed them and something stood out:

     

    image.thumb.png.a2d9d881a21bc0449113adfdc88c0c93.png

     

    Seems like the name of the section names was turned to lower case at some point and nobody complained until now. So, current theory: the linker is anal about case sensitivity in section names, sees the label names, loads them into a different section, then sees that the sections aren't used, and then zaps them from orbit.

     

    So let's try something. Around line 561 of object.c there should be a line like 

    			shstSize += DepositELFSHSTEntry(&shstPtr, ".text");

    and a similar line below for ".data" and ".bss". Change those to "TEXT', "DATA", and "BSS" (note: no leading dot "."). Recompile rmac and test things out. I have a good feeling about this :)

  13. Posted

    Hi there,

     

    Thanks a lot for the files. From the little I can gather it seems like the linker is rejecting the data from the symbols. So my guess is that while it's importing the symbols correctly, it thinks that the data associated with the symbols is 0 in length, maybe that's the reason you see symbol addresses clashing.

     

    Also, since we get such a large difference in the final binaries, it makes little sense to binary compare them. Instead, it'd be really useful if you could binary diff the object files generated by the two rmacs. For example brownboot.o. At least there I more or less expect to see the same file sizes but some bytes will be different, most likely in the symbol table. So it'd be great if I could have such a diff.

     

    Also, as for a visual hex diff client you can try https://winmerge.org - just go to edit->options under "binary" and append the file extension you'll diff (most likely ".o"). Then drag the two object files and it'll do its job.

     

    Thanks for going through with this so far!

  14. Posted

    If it's only rmac that's different between the 2 builds you could even binary compare the two different output files. Also, producing a map file ("-Xlinker -Map=output.map" for gcc) when linking might also shed some clues. Or, even better, binary diffing the object files produced by the 2 rmacs would help tremendously.

  15. Posted

    Hi,

     

    There are a lot of things that could have gone wrong there. Also many questions like:

     

    1) Do you still have your own install? Is <installdir>\bin\m68k-atari-mint-gcc.exe present?

    2) Do you compile your programs from the command line or from an editor (like notepad++, check out tutorial #1 for more info)

    3) When you say "re-installed" do you grab a zip from github and unpack it, or do you use the installer (bad idea, it's outdated)?

    4) If you compile from console did you execute any other commands other than build.bat?

    5) What do you get if you execute "echo %RBTOOLS%" on a new console and after you build something?

    6) Did you get any other build errors? If yes, what were they?

    ...

     

    I could go on with this list but I guess there's little point since you're back in operation now. Unless you want to help troubleshoot this, in which case we'll need to narrow it down. But you'll have to help me by answering a lot of bizarre questions :).

  16. Posted

    Ok, so what probably happens now is that rmac optimistically exports all global symbols as Absolute. Reading your post (thanks for bearing with this btw) I think the problem isn't in skunk.s but brownboot.s, or rather the way symbols are exported in brownboot.s.

     

    Last time I asked you to remove these two lines in object.c: 

        else if (globflag)
        st_shndx = 0;        // Global, not absolute

    This time I ask of you to replace them with  

    	else if (globflag && !(w1 & DEFINED) && (w1 & REFERENCED))
	{
		st_shndx = SHN_UNDEF;
	}

    This will hopefully fix all your "multiple definition" issues (unless there's some other case I'm not considering right now, which is possible!). So give it a go and let us know what happens.

     

    Thanks

  18. Posted

    Right, I might have fixed it.

     

    If you can compile your own rmac (I assume you can judging from the fact that you have patched it in the past), open object.c and go to lines 243 and 244 and comment them out. To be 100% clear, these should read:

      

        else if (globflag)
        st_shndx = 0;        // Global, not absolute

     

    Then recompile and test. I checked and this code hasn't been touched since it was initially committed so when we added a fix for another issue (see above), the rmac listing reported your global/absolute symbol as:

      

               gpu_foo 0000000000F0300C  ag


    (a=absolute, g=global)

    However the exported symbol needed the magic value fff1 (at least according to https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-94076.html#chapter6-tbl-16). Anyway, do try this out and tell us if it works so we can apply it to the main tree :).

  19. Posted

    10 hours ago, cubanismo said:

    -Anyone know what variant of ADPCM IMA encoding avi_ima_encode.exe uses/this decoding code expects?  ffmpeg lists 14, 2 of which (adpcm_ima_qt, adpcm_ima_wav) it can encode.  I started trying to compare the ffmpeg decoders with the DSP code, but figured I could just ask first.  I'm still working on my command-line cinepak conversion tool, and I'd like to pull as many parts of the process into this one tool as possible to simplify things.

     

    Are we talking about @Zerosquare's DSP routines as used, for example, here?

     

    If yes, after a bit of fiddling I found that the tool sox can create adpcm μlaw samples just fine:

     

    sox <input> --channels 1 --bits 8 --encoding mu-law <output.ul> --show-progress rate -v <rate>

     

    From what I recall, it's very important for the output file extension to be "ul". Other than that it should be fine. Hope this helps!

  21. Posted

    LOL, was about to hit submit but @Zerosquare beat me to it :D.

     

    FWIW what I was going to post:

    Basically just use Zerosquare's code from [url=http://www.jagware.org/index.php?/topic/822-joypads-teamtaps-and-other-controllers/&do=findComment&comment=11629]here[/url] and you're done!

     

    As a bonus: unless someone uses a modified joypad, if you read the direction joypad bits and detect both left+right pressed at the same time you can assume that a rotary is plugged in. So: auto detection! (That's what I did i n Downfall Falcon)

     

    Oh and since sampling frequencies were mentioned: on the Falcon 200Hz sampling rate was more than enough with my rotary but YMMV.

    • Like 2

  22. Posted

    Right, after getting a good night's sleep the letters typed above start making sense :).

     

    We're still lacking more info about the symbols themselves. Can you give an example of how they're defined? The last thing we fixed in symbol exporting had to do with symbols that were EQUd and GLOBALd at the same time. Seems like here we've stepped into a edge case we haven't considered.

  23. Posted

    6 minutes ago, swapd0 said:

    The symbol name are _gpu_events_list, _GPU_SPRITE_OFFSET_X, _GPU_SPRITE_OFFSET_Y, and a few more, by the way the symbols are defined into a GPU chunk but referenced from 68000 code.

     

    So, a small test case which we could try without doing (perhaps wrong) stuff at random and declaring it works is....?

  24. Posted · Edited by ggn

    46 minutes ago, swapd0 said:

    Yes, I've just seen it... f*ck because they have changed the way it works, but there's a function called nthpath that looks for ';' to get multiple paths from a single argument.

    Nope, no we haven't changed the way it works. We just added code that validates the paths entered. But sadly there were issues in the routine that validates the paths. A patch has been submitted, but not yet applied to main. If you like you can apply it and recompile.

     

    Also, I do appreciate the obscene language, makes it feel worth the trouble :)

     

    (Seriously, we try to never change functionality because it might break stuff for people. We're really concerned about this every time we extend the assembler to support more things)

     

    26 minutes ago, swapd0 said:

    It looks that there are more changes, for example I've in a source file a label defined with two colons at the end, so it's supposed that the label it's global, this label it's referenced from a second file and I've an .extern directive at the beginning but I get a linker error of an undefined reference even if I put a .globl label in the first file. :(

     

    Repro case please, and we'll look into it. What is the problematic symbol's name?

     

    (asking because there is a known issue of symbols clashing with register names, especially now since we added DSP56001 mode. It's something that I hope will be resolved soon)

     

  25. Posted

    How about turning off interrupts, saving page 0 and disable ROM? Then when/if you require i/o then restore page 0 and enable ROM again. The o/s in theory wouldn't know what happened during the time it was off.

     

    (Never tested this kind of thing on the Atari 800 hardware but on the ST it's not an uncommon practice if we want to take advantage of low ram addressing)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...