ggn

How about... 10 X=1:GOSUB 100 20 X=6:GOSUB 100 30 END 100 FOR T = 1 TO 5 110 PRINT X 120 X=X+1 130 NEXT T 140 RETURN

Can confirm - I made it explode in so many weird and wonderful ways while adding elf support to rmac

Personally I'd advise to start clean and try out Bastian's tips and nothing else. Those should lead to an absolute binary without much fuss.

Also, small reminder/updater: http://brownbot.mooo.comis based on Compiler Explorer and lets you see the assembly output as you type your C code immediately! Also, under the "C" section there is now the option to use a couple of ST compilers using a thin emulation layer. It's fun to sometimes see gcc producing worse code than a 90s compiler .

Now, I won't pretend I remember all the things we tried when we were working on browncc/brownout, but I'm sure we tried a few things with linker scripts. The results we got was that ld would crash or ignore our scripts with the back then current binutils. So instead of trying to report our issues or hope they magically fix them we just went ahead with-Ttext-segment=0 and then wrote brownout to do the rest of the work. But hey, if that linker script above works, then it's good news!

I think I get what you mean - we do that in our tiny startup .s file here and link it as early as possible. But still ld at its convenience chose to not place _start at the entry point. (and that's why we added code to check for that in brownout). I agree what you say about having a dedicated linker script since on Jaguar you want to produce an absolute binary, although I'm not sure if that would help with _start placement.

I can assure you it's nothing like that If you skim back a bit, the problem with that approach was that the entry point is not known (ld can place _start at whatever address it suits itself). So while we were developing brownout we added a step in which we hunted for the _start symbol and placed a "jmp XXXXXXXX" instruction at the start of the binary. Since this is TOS .prg and we are in charge of outputting the final relocation info, it doesn't matter much since we can shift the start of the actual program by a few bytes downwards. Perhaps swapd0 could have done this by altering brownout source himself but it's not the way he chose to go.

Another idea would be to start with a touched up image with less colours. For, example the Atari ST version:

Firstly, that "clr.b d0" does the magic of aligning the address to 256 byte boundary. Since 256 is $100 in hex, it means that if we just make sure that the lower 8 bits of our address are 0 then we're done. So, what's the extra "ds.b 256"? Well, consider this: section bss label1: ds.w 4 label2: ds.l 1 screen: ds.b 32000 If we take "screen"'s address and clear the lower 8 bits then the address will move up in memory (as an example: if "screen"'s address is $60024, it will become $60000). So it's certain that if we use the modified address, label1 and label2 will get clobbered by screen data. (the exception to this is "screen" already being an address with the 8 lower bits 0) So, to counter that we need to add some dummy bytes before "screen". That's what the "ds.b 256" does. If we knew the address our program will be loaded we could simply reserve as many bytes as needed. But we don't know beforehand the address our program will be loaded so we just put in the maximum amount of bytes we can move back: 256. (well, technically it should be 254 but what's 2 bytes between friends). Hope this makes sense now.

Another option would be to perform a so called "unity build", in which you compile a single file that includes every other files your project contains. Then the only thing the linker has to do is plug in the absolute addresses and won't bother with any alignment at all since everything will be resolved at compile time. Of course if you also link in assembly object files which aren't gas compatible format this will turn hairy very quick. (And I assume you do).

Check out this post where I tried to explain graphically what happens. In general you can think of 256 colours as 16 palettes of 16 colours each. So for example if you assign the particle/text layer to use CLUT (palette) 15 then you need to make sure that the last 16 colours (240-255) have the colour indexes of the font you're going to use. Try a 256 colour tool like Grafx2 or Pro Motion that have palette editing features so you can see what's happening.

From the page I linked: TA_ALIGN 8 Word size for pointer alignment TA_BASE 0x400 Address of tinyalloc control data structure TA_DEBUG undefined Trace debug information TA_DISABLE_COMPACT undefined Disable free block compaction TA_DISABLE_SPLIT undefined Disable free block splitting during re-alloc TA_HEAP_START 0x1010 Heap space start address TA_HEAP_LIMIT 0xffffff Heap space end address TA_HEAP_BLOCKS 256 Max. number of memory chunks TA_SPLIT_THRESH 16 Size threshold for splitting chunks I think all that pretty much covers what you said?

Lately I've seen one person using https://github.com/thi-ng/tinyalloc

BS Agreed!

BTW would anyone like to post a small working example of this so everyone will get some closure?

http://virtualjaguar.kicks-ass.net/builds/ Or if you require the source: git clone http://shamusworld.gotdns.org/git/rmac

From the standard assets.txt template: ' - For graphics conversion you can use "gfx_clut" or "gfx_noclut" to convert a .BMP file into jaguar raw format and optionally export the paletter or not (clut=yes, noclut=no). ' This applies to 1-, 2-, 4- and 8-bit graphics only. ' For 16-bit and 24-bit graphics no clut is created (because there isn't a need for one). Which means "whether you use _clut/_noclut in 16 or 24bpp mode it won't matter". I simply left the option in so people won't be confused in the case of switching asset bitplanes (say you had a 16bpp object that you converted to 4bpp later on). Sadly it seems to confuse people in other ways

Hi, Attached is a modified project from the ones rb+ is shipped (pack). It contains a 16bpp image just to prove that flipping works. Also, it scrolls upwards because I added animation and told it that each frame is 352*2 bytes further from the previous. First of all, flipping works in 16bpp images, so you probably need to double check your settings. Secondly, you don't need to add any offset to your x coordinate when flipping. It's done for you behind the scenes. As for your question: Yes, you can define multiple objects that have the same source address. That's how (for example) F.A.C.T.S. demo draws so many sprites in the first part - they're all the same! Hope this helps. pack.zip

Btw, I realise that link might have been a bit obscure, so here's another one that might make what I wanted to say more clear!

Well, if you do get around to it, the Jaugar could finally get a chip tracker that supports it!

Hi Jac!, Great job with the IDE as usual . With the latest 0 install bundle that includes Java I finally got off my butt and tried it out a bit. I don't have Java installed on my computer and I don't fancy having it installed for everyone, so that's great! As a first time user I was a bit weirded out that the bundled Altirra displays a blank screen no matter what you try to load, be it a assembled binary from the IDE or any atr/xex/etc. After a bit of looking around I found out that the issue is that the selected firmware is something called "JacOS" which is not present on the archive at all. Changing this to one of the bundled AltirraOSes fixed this. Next was the "C:\jac|" hard dependency. A bit inconvenient as I might want to work on machines I don't have admin access, so a more portable version would be nice. That took a bit of convincing but I managed that eventually! First of all, modify the shortcut's target to: C:\Windows\System32\cmd.exe /c start /D c:\wudsn Tools\IDE\Eclipse\4.x.x-win32-x86_64\eclipse\eclipse.exe"Start in" shouldn't matter, but I set it to "." anyway. Now eclipse can run from any folder, but the paths are messed up! Plus, a "c:\jac" folder will be created regardless. So, time to edit some files! - Edit "Tools\IDE\Eclipse\4.x.x-win32-x86_64\eclipse\configuration\.settings\org.eclipse.ui.ide.prefs" and remove "C\:\\jac\\wudsn\\" - Edit "Tools\IDE\Eclipse\4.x.x-win32-x86_64\eclipse\configuration\org.eclipse.osgi\bundles\104\data\49071014\artifacts.xml" and remove "C\:\\jac\\wudsn\\" - Edit "Tools\IDE\Eclipse\4.x.x-win32-x86_64\eclipse\configuration\org.eclipse.osgi\bundles\104\data\-615013262\artifacts.xml" and remove "C\:\\jac\\wudsn\\" - Edit "Workspace\.metadata\.plugins\org.eclipse.core.runtime\.settings\com.wudsn.ide.asm.prefs" and remove "C\:\\jac\\wudsn\\" - Edit "Workspace\.metadata\.plugins\org.eclipse.ui.ide\dialog_settings.xml" and remove "C\:\\jac\\wudsn\\" If you do all these then hopefully clicking the .lnk file will launch the IDE and have the default WUDSN view showing! In the diff I made between the original archive and my own install there are some other files changed but I don't think these matter. In any case, again thanks to Jac! for all the hard work put into this project, and if anyone tries the changes I posted above, I'd be glad to know whether they work or not for them .

Here I got nm swapd0.o 00000000 T _gpu_code_start U _gpu_sprite 00f00000 a BASE 00f03000 a G_RAMSo, probably update your rmac?

Modified the code a bit to be more self contained and assemble: BASE EQU $F00000 ; TOM Internal Register Base G_RAM EQU BASE + $3000 ; GPU Internal RAM _gpu_code_start:: .gpu .org G_RAM movei #_gpu_sprite,r0 .long _gpu_sprite:: dc.l 0 Assembled with rmac 1.13.5 using "rmac -fe -l*swapd0.lst swapd0.s". I assume you want elf .o objects. The listing for this looks like: 1 =00F00000 BASE EQU $F00000 ; TOM Internal Register Base 2 =00F03000 G_RAM EQU BASE + $3000 ; GPU Internal RAM 3 4 _gpu_code_start:: 5 .gpu 6 .org G_RAM 7 8 9 00000000 9800xxxxxxxx movei #_gpu_sprite,r0 10 11 12 00000006 0000 .long 13 14 00000008 00000000 _gpu_sprite:: dc.l 0 BASE 0000000000F00000 a G_RAM 0000000000F03000 a _gpu_code_start 0000000000000000 tg _gpu_sprite 0000000000F03008 ag Looks like the symbols are tagged as global here. Let's look at the .o file itself: ELF Header Class: ELF32 Encoding: Big endian ELFVersion: Current Type: Relocatable file Machine: Motorola m68k family Version: Current Entry: 0x0 Flags: 0x0 Section Headers: [ Nr ] Type Addr Size ES Flg Lk Inf Al Name [ 0] NULL 00000000 00000000 00 00 000 00 [ 1] PROGBITS 00000000 0000000c 00 AX 00 000 04 .text [ 2] STRTAB 00000000 00000021 00 00 000 01 .shstrtab [ 3] SYMTAB 00000000 00000060 10 04 004 04 .symtab [ 4] STRTAB 00000000 00000028 00 00 000 01 .strtab Key to Flags: W (write), A (alloc), X (execute) Symbol table (.symtab) [ Nr ] Value Size Type Bind Sect Name [ 0] 00000000 00000000 NOTYPE LOCAL 0 [ 1] 00000000 00000000 SECTION LOCAL 1 [ 2] 00f00000 00000000 NOTYPE LOCAL 65521 BASE [ 3] 00f03000 00000000 NOTYPE LOCAL 65521 G_RAM [ 4] 00000000 00000000 NOTYPE GLOBAL 1 _gpu_code_start [ 5] 00f03008 00000000 NOTYPE GLOBAL 0 _gpu_sprite Section Data: .text [00000000] 98 00 30 08 00 f0 00 00 00 00 00 00 .shstrtab [00000000] 00 2e 73 68 73 74 72 74 61 62 00 2e 73 79 6d 74 [00000010] 61 62 00 2e 73 74 72 74 61 62 00 2e 74 65 78 74 [00000020] 00 .symtab [00000000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000010] 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 01 [00000020] 00 00 00 01 00 f0 00 00 00 00 00 00 00 00 ff f1 [00000030] 00 00 00 06 00 f0 30 00 00 00 00 00 00 00 ff f1 .strtab [00000000] 00 42 41 53 45 00 47 5f 52 41 4d 00 5f 67 70 75 [00000010] 5f 63 6f 64 65 5f 73 74 61 72 74 00 5f 67 70 75 [00000020] 5f 73 70 72 69 74 65 00 Generated by ELFIO (C++ library for ELF file processing) http://elfio.sourceforge.net/ Again the symbols look global. So as far as I can see it's not rmac's fault. You'll have to tell us some more info like the version of rmac you used, the command line you used, and whether your compiler/linker requires extra undercores (or no underscores at all). Maybe your symbols need to be defined using a double underscore (for example __gpu_sprite).

Should not happen.... but does Anyway, the issue has been discussed in this thread but no consensus has been reached.

Alternatively you could change your object to 4bit colour depth, so each line then would need 16x4=64 bits (one phrase)