Cyprian

great news, my 7800 just flies to me, and would be cool to buy the Dragonfly

https://github.com/theRemovers/jconverter there is converter.py / rgb2cry.py thanks

great, I'll check that

I've tried to compile it under Cygwin: *** Compiling src/eeprom.cpp... src/eeprom.cpp:19:10: fatal error: direct.h: No such file or directory 19 | #include <direct.h> | ^~~~~~~~~~ regarding VS it shows error message regarding the lack of "QApplication". That's obvious as I have no QT. Can you pleas point me out correct dl link? I somewhere found qt installation file, but I'm not sure whether it is ok or no. thanks

@ggn yep, that macro was an example, for e.g. extract many sprites from one image. It's easier to have all needed data in "dc.l" than do a lot of manipulations with 68k code. Thanks for explanation. Now I can work around that with 'incbin'. What about .org statement? And I've faced another issue with labels between a .gpu and .68000 code, but I have verify that once more.

Can someone build this cool container for me? I made a few attempts under Win/Cygwin, unfortunately to no avail. Thanks

trace at source level sounds cool, can you elaborate that more? Btw any progress with Rx?

ops my fault,

https://www.mulle-kybernetik.com/jagdox/memorymap.html https://github.com/mamedev/mame/blob/master/src/mame/drivers/jaguar.cpp I wonder why those registers are mentioned in Mame but not in TechRef/JagDox, and whether there are more "hidden" registers. F08800-F08D9F R/W xxxxxxxx xxxxxxxx LBUF - 32-bit access to line buffer A F09000-F0959F R/W xxxxxxxx xxxxxxxx LBUF - 32-bit access to line buffer B F09800-F09D9F R/W xxxxxxxx xxxxxxxx LBUF - 32-bit access to line buffer currently selected F0B000-F0BFFF R/W xxxxxxxx xxxxxxxx 32-bit access to local GPU RAM

@DrTypo any news about your project?

---deleted---

@LinkoVitch would be possible to add jconverter to your container?

understandable, you're more experienced than me and your code is more advanced than mine. I do only some simple tests and VJ is fine for me atm

I have the skunk but at that moment I use VirtualJag and COF files. It's easier and faster to do some simple tests

it triggers an error message, JagTST.s 6: Error: .org permitted only in GPU/DSP/OP, 56001, 6502 and 68k (with -fr switch) sections it seems that's the limitation of RMAC, more than one ".org" isn't allowed in case of Jag 68000 code In that case, I have no problem with that limitation. I'd like to place the only BSS segment in the RAM, and the 68000 code can be placed in the ROM area.

Ok, in attached GPUINT.tst.zip in file gpu_list.s I added test macros: Macro_Test UpdateList, 32 ;<-- Works ok Macro_Test jagbits, 32 ;<-- Doesn't work Macro_Test width, 32 ;<-- Doesn't work how do you generate COF then? rmac with -fb flag gives me only .O file. yes, in makefile jaguar.bin is defined as jagbits. ok, now I use ".incbin" for jaguar.bin, and "include" for other .S files, and problem with external variables has gone. but I faced another problem with ".org" in JagTST.zip currently all variables point to the same address $4000 lea v_bmp_lowl,A0 lea a_hde,A0 lea main_obj_list,A0 When I comment ".org $4000" from row 62, then those variables point to the same address $0 When additionally I comment ".org objList" from row 41, they point to correct unique address (based on definition from makefile), but my ".objproc" points to address in the rom. which isn't ok. GPUINT.tst.zip JagTST.zip

great @masteries

@swapd0 that variable is defined in makefile rln $(ALNFLAGS) -o gpuint.cof $(OBJ) -i jaguar.bin jagbits @ggn a) ok, I usually do that - one big .S file, but this time I tried to follow the Atari's workshop way - makefile with separate .S files. regarding b) when I try to pass jagbits to my macro I see following error message gpu_list.s 238: Error: undefined expression gpu_list.s 226: Error: undefined expression gpu_list.s 226: Error: undefined expression gpu_list.s 260: Error: undefined expression gpu_list.s 260: Error: undefined expression makefile:16: recipe for target 'gpu_list.o' failed if it's needed I can post a source code (it is actually a bit modified Atari's workshop)

I wonder why BITMAP has LINK address. It's obvious in case of BRANCH because of flow control. Is it any useful case for adding it to BITMAP?

I have a simple code with an external variable: .extern jagbits and now, that works: dc.l jagbits and that generates an error: TAKIETAKIE EQU jagbits Error message: rmac -fb -u -v gpu_list.s gpu_list.s 269: Error: undefined expression makefile:16: recipe for target 'gpu_list.o' failed make: *** [gpu_list.o] Error 1 The same error is shown when I use external variable in my macro. is there any workaround?

ok, VI counts halflines. theoretically, in interlace mode, in the even field, a scanline starts with even halfline, and in case odd field - odd halfline. Now we have branch for only even halflines and anyway would be cool to have values truncated for OP opcodes

the latest RMAC generates branch with wrong YPOS (shifted left by one bit), and also doesn't truncate YPOS to the max value $7FF is it ok?

great idea @neo_rg that looks cool

and actually I wonder whether other STOP bits are somehow used, and what else we can see in the Jag Netlist?

nice, it would allow to write a driver and use Extended Joystick as a normal one