swapd0

Done and it compiles the game, but I haven't tested it.

I think that it mess around with .globl or :: directives to define a global symbol into GPU sections. .68000 nop lea m68k_foo,a0 nop .long m68k_foo: dc.l 0 m68k_bar: dc.l 0 .GPU .org $f03000 nop movei #gpu_foo,r0 nop .long gpu_foo: dc.l 0 Output: swapd0$ rmac -fe test.s -o out.elf swapd0$ nm out.elf 00f0300c a gpu_foo 00000010 t m68k_bar 0000000c t m68k_foo Now m68k_foo and gpu_foo are defined as global(: .68000 nop lea m68k_foo,a0 nop .long m68k_foo:: dc.l 0 m68k_bar: dc.l 0 .GPU .org $f03000 nop movei #gpu_foo,r0 nop .long gpu_foo:: dc.l 0 Output swapd0$ rmac -fe test.s -o out.elf swapd0$ nm out.elf U gpu_foo 00000010 t m68k_bar 0000000c T m68k_foo swapd0$ Last code using old version of rmac: swapd0$ rmac-old -fe test.s -o out.elf swapd0$ nm out.elf 00f0300c A gpu_foo 00000010 t m68k_bar 0000000c T m68k_foo

I've compiled the just game (not the library) with the old version of rmac, and this is the output of nm with the gpu.o: swapd0$ nm obj/gpu.o 00f02200 a A1_BASE 00f02208 a A1_CLIP 00f02220 a A1_FINC ... 00f00000 a _BASE 00f0323c A _GPU_MAX_VIDEO_X 00f03240 A _GPU_MAX_VIDEO_Y 00f03234 a _GPU_SPRITE_OFFSETS 00f03234 A _GPU_SPRITE_OFFSET_X 00f03238 A _GPU_SPRITE_OFFSET_Y 00f03048 A _gpu_build_sprite_list 00000000 T _gpu_code_start 00f03008 A _gpu_events 00f03044 A _gpu_events_list 00f0322c A _gpu_sprite_dst 00f03096 a align_last_sprite 00f030bc a build_sprite 00f030ee a continue_build_sprite 00000011 A event_fn 00000012 A events 00000013 A list_ptr 00000010 A return The same thing with the new version of rmac, there are some labels without an address. swapd0$ nm obj/gpu.o 00f02200 a A1_BASE 00f02208 a A1_CLIP 00f02220 a A1_FINC 00f02204 a A1_FLAGS ... 00f00000 a _BASE U _GPU_MAX_VIDEO_X U _GPU_MAX_VIDEO_Y 00f03234 a _GPU_SPRITE_OFFSETS U _GPU_SPRITE_OFFSET_X U _GPU_SPRITE_OFFSET_Y U _gpu_build_sprite_list 00000000 T _gpu_code_start U _gpu_events U _gpu_events_list U _gpu_sprite_dst 00f03096 a align_last_sprite 00f030bc a build_sprite 00f030ee a continue_build_sprite U event_fn U events U list_ptr U return swapd0$

It's not easy to write a small example, here it's what I have. - C/Asm library where I got some references to a GPU symbols that it's not compiled with the library, all GPU code files are copied into the include directory. - The game includes the library code - I have a gpu.s file like this: .include "jaguar/jaguar.inc" _gpu_code_start:: .gpu .org G_RAM movei #G_ENDRAM,r31 moveta r31,r31 .include "katu/gpu_event.s" .include "katu/gpu_sprite.s" This way I can include more files with gpu code specific to that game. These two files must be included, and gpu_event.s must be first. The game complies with no problem but I have linker errors for all symbols defined in gpu_event.s and gpu_sprite.s that are referenced from the library. edit: I've tried with .globl directive or with -u option but it have the same error, undefined reference.

working on it. edited: by the way I'm using gcc linker, not rln but it worked with the older version of rmac.

Sorry 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. I've also seen that I can't create a label name like "x" or "y" (it was a register equate), anyway I've changed them to cx or cy. No problem.

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.

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, I'm looking at rmac code and you can use -I option only one time, I've also tried with ':' but the code looks for a ";" Ok, but now I've "invalid include path" error, and I've tested that both path exists... weird, I'll run rmac with the debugger.

After some days off (maybe two weeks?), I've updated rmac to 2.0.12 and now I get an error when I try to compile my projects, I've this definition in the makefile: RMAC = rmac -fe -i/opt/local/bin/gcc68k/include;/Users/Shared/apps/Jaguar/projects/lib When I call make I get rmac -fe -i/opt/local/bin/gcc68k/include;/Users/Shared/apps/Jaguar/projects/lib -o obj/gpu.o gpu.s /bin/sh: /Users/Shared/apps/Jaguar/projects/lib: is a directory make: *** [obj/gpu.o] Error 126 Of course that it's a directory...

Yeah, that was long time ago... Try to get a skunk board, it saves a lot of headaches and the upload speed it's a lot faster.

But with BJL you are restricted to 2MB of RAM, you can't use the ROM space as "mass-storage".

9.2MB and 153,798 lines

I'm a bit busy now and not I'm sure how to upload a patch and if I can do it, anyway I've changed the following, tested and work with huge files. File token.c line 25 -> uint16_t curlineno; -> uint32_t curlineno; File token.h line 157 -> uint16_t curlineno; -> uint32_t curlineno;

I'm using U235-SE 0.24 and works flawlessly.

Maybe I changed the version from 1.13.5 to 1.13.6 because a few months ago I had to compile it and change the line number from short to int because I was checking a disassembled file and I got errors with weird line number.

Nope, I'm not building a SE command, that comes a bit later in the code, but it's executed each time that I play a new sounds. Maybe I'm using an older version of rmac, mine it's 1.13.6.

I'm using rmac.

IMHO they never tried to code a real game while the hardware was in development, because you'll find a lot of bottlenecks and fixing them could improve a lot the machine. You can't make an After Burner (sprite + scaling + rotation) without a lot of headaches, and it's a game from 1987...

I've the following code in my sound engine, it's using u253se. The d0 has a sound channel (4 to 7) and d1 holds a sample number. It always hangs. ; register sound move.b d1,channel_sound(pc,d0.w) move.b d0,sound_channel(pc,d1.w) Even this version hangs, WTF!?!?! ; register sound moveq #0,d0 moveq #0,d1 move.b d1,channel_sound(pc,d0.w) move.b d0,sound_channel(pc,d1.w) As you can see I'm writing bytes so there are no problems about alignment, anyway I've a .long directive before channel_sound definition. But, I've done a quick test with this code and it works... ; register sound moveq #0,d0 moveq #0,d1 move.w d1,channel_sound(pc,d0.w) ; move.b d0,sound_channel(pc,d1.w) There are any problem with byte memory access from the 68000? I don't understand why it hangs, if I comment the code it works.

68000 it's too slow for a 32/64 bit machine. Maybe a Motorola 88000 could be nice instead of the other RISC. A better solution, remove the 68000, DSP & GPU and put three existing RISC (all the same of course), one for the main logic, IO, AI, etc, other for graphics and the last one for the sound system. The time saved could be used to fix some blitter bugs and improve the performance.

There's a typo in the docs. The value should be 10010010 = $92, isn't it? Voice Status Register (U235SE_voice_status) Represents the current sample processing status of each voice. If a voice is currently processing a sample (even if that sample is silence), then its corresponding bit will be set. If the voice is idle and has no sample to play then the bit will be clear. For example, if there were samples playing on voices 1,4 and 7 only, then the voice status register would be $4a (binary 01001010 – remember voices start at 0)

IMO even with a better hardware it would fail but at least the oficial game library could be 10 times bigger.

You are right, in my case I've the jaguar on the right side of the computer that's the reason that I would prefer the upper position and I'm in the 1% (actually 0.1%?) of the people that will use it. Anyway it's a great product.

The only thing that I don't like is that the USB port is on the right side of the cart, IMHO it's better if is placed on the upper side.