ggn

Well if you're up for it https://github.com/ggnkua/Atari_ST_Sourcesis awaiting for your contribution

Fs in chat for FL! And a happy new year to everybody [EDIT] After looking at the graphics, I agree with FL - they look much more detailed than the other versions. A pity the 16 bit versions didn't use these as a basis and just lazily ported some other 8-bit port (C64 or CPC?).

It'd be a different game. And by the time anyone realises how much work this needs, they'd give up. Or, preferably, work on something original that they'd like to do instead of someone else's vision.

Hey, why the defeatist attitude? Here we go, as promised I cleaned up the source a little bit to remove profanity and ULS creation. I make no excuses for the quality or any warranties. The code is written in GFA Basic 32, you should be able to find an "abandonware" version around the internet if you look for it. Just hit "run" and it should start up. Or "Compile/Build" it to make an executable version. Happy Christmas to everyone! jiffi_142_src.zip

You're confusing ELF object files with ELF binaries. JiFFI was never a linker so it will not handle object files of any format. What it does instead is convert between executable binary formats.

When I read this post (probably the same day as it was posted), I started typing a long reply. Then deleted it. Then tried typing one again. Then I deleted that too. This time I'll keep it short: a) JiFFI source release can certainly happen b) It won't contain the CD creation feature c) I'll have to do some more cleanup before release d) It's a very ugly source, which is one of the reasons I stopped working on it e) It's written in GFA Basic 32, are you sure you want this? If the above didn't put you off, just let me know and I'll prepare a source release. BTW I'm puzzled about why you want to add ELF format in the first place. Doesn't COFF or absolute cover just about anything?

They're not available yet.

Actually the Falcon version also contains a background identical to the first Jaguar Downfall, among many others. As for ST version, I've been contacted by two people who wanted to make a ST and STE version respectively. One got the full source code and assets for the Falcon version but I never heard of him since the initial handover. The other person did a tech demo that contained the background, scrolling platforms and sample playback (on STF) which he showed me at a demo party. He wasn't very pleased with it so he stopped working on it for now.

And Falcon Chronologically, first Downfall on Jaguar was released, then the Falcon version, then Downfall+ on Jaguar again. As for Simon's version for the a8 - yes, the development did continue in more privacy, I was invited to test as I wrote the Falcon version and had atari 800 gear to test his binaries. It's quite complete - main sprite is there with inertia and all, can walk on platforms and can pick up bonuses. The only apparent thing that's missing is the game over check (i.e. if you fall off the screen you just stay there), also possibly the power up handling.

Bitwise not will turn %00000001 to %11111110, not %10000000 (bit reverse) like ascrnet asked . I'm not sure if there is a reverse bits function in mads but worst case you can probably create a macro that does this for you. Or maybe tebe can add that functionality.

Well, my thought was that you are going to run a binary that gcc/ld/whatever else outputted in ROM directly. Then your code and data will be at $802000, and the bss will have to be in main RAM. But if you plan to copy the binary from ROM to RAM and run it there, no problems.

One thing I'm puzzled over this approach is what would you do when you want to create a rom file where text+data won't be contiguous with the BSS - perhaps it would be best to modify brownout directly for this?

ld can link rmac elf object files no problems.

Did you rebuild everything from scratch without -flto? Both compiler and linker settings have to be in sync.

Other random thought: are you using link time optimisation (-flto)? This can seriously mess up the order of object files.

It's been a while since we messed with this so memory is a bit hazy. Your main entry point is always at _main (or __main if you're compiling with underscores), but that doesn't help you much - you need to run your startup code first (brownboot.s is what we use). What we discovered while developing brownout is that the binutils elf linker doesn't necessarily put objects in the order you ask it, especially your entry point. The way we solved that is to inject a "bra.w" (or "jmp") at the very start of the code and then search for the location symbol "_start" (or "__start") which is the start of brownboot.s code. Then we patch the address during final program output. For your case you could do something like set your TEXT start at $4006, then after ld does its job, take the output binary, insert a "jmp" opcode in front, then search the map file for your "_start" and plug that address after the "jmp". Not elegant but it should do the trick. I'm not sure if there's a more elegant way but we didn't look into it further as we did have to perform the elf->prg conversion. By the way, if you want to use output from brownout on jaguar you'll have to perform relocation on startup because that's how .prg files work.

This startup code was written by dml after a lot of experimentation. I seem to recall that this has to be called when you're using c++ things (constructors/destructors). At least this and this seems to indicate that this is the case. So for C only programs you can probably get away with not calling it I think this is not a biggie Wait, that looks like output from brownout. This is our (me and dml's) tool that converts native elf binaries to TOS PRG compatible executables. Since you'll be linking to absolute addresses you most certainly don't need this!. At least from my experiments you don't need a script file to perform this. In one of my project I've used something like the following line to link the final program: gcc -m68000 -mshort -nostartfiles -nostdlib -o $FILENAME $ALL_OBJECT_FILES -Wl,--oformat,binary,-Ttext=0x00e00000,-Tbss=0x00000400,-e,ostext -Xlinker -Map=output.mapThis links all .o files, instructs the linker to produce an absolute binary with the text segment located at $e00000, data will be immediately after text and bss will be at $400. Finally output a map file of all symbol addresses. Not sure the "-m68000 -mshort -nostartfiles -nostdlib" have any effect, but I probably use them in order to be 100% compatible with the way I compiled the source. Hope this helps!

Well, tell you what: you go ahead and do your thing and if you come up with something instead of feature requests (a binary for example), we can all flog/guilt trip Zerosquare into adding this to his code and then to RB+ . RB+ has always been development driven: when someone does stuff and is missing a feature and we deem it useful (and feeling up to it) then we add it in.

Hi there, The only source I could find after looking around is this: https://github.com/ggnkua/Atari_ST_Sources/blob/master/C/Rodney%20Volz/mercsrc/release.src/src/uucico_1.lst(and https://github.com/ggnkua/Atari_ST_Sources/blob/master/C/Rodney%20Volz/mercsrc/release.src/src/uucico_2.lst for the original). From a quick look they seem to open the ST's serial port and do some stuff with it, so you might be able to get some hints. As for the TT serial ports, I guess you should read the Atari Compendium. I'm pretty sure all ports should be documented there. Best of luck with your project, it sounds fun!

It might be that the compiler's code printing is single pass, so at the time the movem.l is written the compiler has no idea if there are going to be any save/restore happening. So at the time the rts is written, it has decided that no register saving needs to happen, so the movem that would pop the stack is simply omitted. Just out of interest, I pasted a more complex function from another thing I'm working on here: http://brownbot.mooo.com/z/TE8Pqj. The compiler is being instructed to push l90 into the stack, which at the end of the function we see that it's defined as "reg a2/a3/d2/d3/d4/d5/d6/d7". In contrast, notice that l13 at the simple function is defined as pretty much nothing. So I guess that vasm knows about this and in this case simply discards the superfluous movem.

If you have any issues that are the script's fault, you are welcome to raise an issue at https://bitbucket.org/ggnkua/bigbrownbuild/issues. Especially if you have a fix Also I totally forgot I have packaged up gcc 8.2 for macs (built on El Capitan) here: http://d-bug.mooo.com/various/brownart.tar.bz2. So worst case you could give this a shot!

Well no problem - let me know if it works for you or if you encountered any issues with the script. Also worth noting is that part of the build process is compiling MiNTlib, and maybe you can use parts of it on the Jaguar as well. Of course all I/O stuff is out, but maybe there's some useful bits.

As usual, the truth lies inbetween (http://brownbot.mooo.com/z/KLw0Y_): int16_t test1__(int32_t a, int32_t b) { return a + b; } _test1__ movem.l l13,-(a7) move.l (8+l15,a7),d0 add.l (4+l15,a7),d0 l13 reg l15 equ 0 rts As usual, you always need to check the compiler's output and learn all the nuances and magic compiler switches Also, when you start diffing output code between compilers you also start wondering. (http://brownbot.mooo.com/z/-3vjKr)

You can always use https://bitbucket.org/ggnkua/bigbrownbuild- tested with success in El Capitan and High Sierra.

Well, that's what bcx is used for in rb+, just an easy way to control program the libraries running on the J-RISCs that do the actual work. Well, obviously gcc targets proper c++. Other than that, its code generation should be more mature than vbcc's. If you like you can check it out the two compilers live here: http://brownbot.mooo.com/z/XwMJ3e(you're of course free to edit the code and see the output)