ggn

And one for me please Panos

Me too actually

You could ask @Gaztee and @omf if they're still doing physical releases. Otherwise AtariAge publishes Jaguar games as well.

Hi there, I didn't see your post in time sadly. FWIW here's what we use to test the 6502 part of rmac. Perhaps you could use it to cross reference stuff? 6502.zip The idea is that running the source file past the assembler should produce an identical listing to the .ref file.

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!

Hmm, that's odd 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.

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!

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?

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)

Without going any further I noticed some weird things. For starters, brownboot.o: 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: 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?

Are you able to diff a few object files now?

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: 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

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!

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.

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 :).

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

Also while I was at it, I submitted a patch for one of @dilinger's bug reports in post #75

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 :).

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!

Okay, interesting. I'll definitely take a look at it soon (perhaps tomorrow).

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.

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.

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

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) 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)

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)