dilinger

I have tried to update JiFFI to include a ELF support; after some efforts, I put it a way for a while. Recently I've decided to move the source from Basic to C/C++ (64bits). It will be easier to maintain, at least for me. It is not yet ready for Release but hereafter a screenshot from the WiP version. Do someone knows where the lo_inp executable source code can be found? It is used in the original JiFFI version.

Hi. Sure. I have applied the patch and tested, the issue is mostly fixed. I have added a comment in the issue tracker. Thanks.

Thank you for the information. I have open a bug about it with repro steps. Please let me know if you need more information. Using the RLN -s option will add the symbols in the file but the offsets / values seem to not make sense. I will try to dig up before to open a different bug report.

Hi, I think I've found an issue with RLN V1.6.1. If the options related to symbols are not used, the PSymbolTable and NumberOfSymbols fields in the coff will still be set. It will create a problem if the fields are used by a tool or a debugger, because no symbols will be found in the file. Could it be possible to fix this problem? If the source code is available on Git, please let me know, I will try to have a look at the issue.

You are correct. I have done benchmarks, for 68000, from gcc 4.8.0 to gcc 10.0.0. I have generated most of the toolchains by myself, so they may not be perfect. The "fastest" for the moment is gcc 5.2.0 and 5.5.0; I have read from a Sega homebrew developer that the gcc 3.x has better support for the 68K. Anyway, doing C is also not the best way to code for the console.

I know this subject is 10 years old, but the download section of the site is not accessible (which is not really surprising). Does someone owns the cmi-1.0.0.src.tar.gz ?

Thank you for the info. Il will continue to follow your progress.

I've not tested it in Linux environment, but let me know if you meet issues. Do you have a link to the removers version's extra debugging stuff? Or are you referring to the jserve tool? Meanwhile, at Skynet headquarters...

Thank you for sharing. Some time ago, I did a jcp2 version based on the original jcp to include features such as: * ELF binary format support * USB port, Bus and Port, and Skunkboard serial number selections * Libusb 1.0.x support https://github.com/djipi/Skunkboard In theory, with your script, it would be possible to have a remote farm of consoles with Skunkboard.

Thank you for sharing this. Do you plan to release the sources in the future?

Works well on the Virtual Jaguar emulator too.

I have a such device, got it from a collector a year ago; it was included with some more interesting stuff. The cart of my device is not transparent, otherwise same HW. No easy to use for sure, and need an additional flash device. May be suitable for a game developer willing to keep build versions on the same cart, before the GD came out. I prefer to use my Skunkboards, and to use the GD in the future.

Without a cart, the Jaguar won't turn on (no led, nothing).

Thank you for the update. I had a look at the ELF format support. I use Vasm and Vlink, the makefile for your demo was easy to adapt. Unfortunately, I'm not able yet to have a ELF executable due to the reference to undefined symbols: U235SE_playback_rate U235SE_playback_period U235SE_ptr_sample_bank U235SE_playmod U235SE_pad1 U235SE_sfxplaylist_ptr However, these symbols are in the dsp.elf.obj symbol table. What tool have you used to generate the dsp.elf.obj file?

The 240p test suite version source code is written in C and, depend the platforms, assets are encoded in asm. Never heard about this tool but thank you to have bring it up.

I have attached a screenshot of what I see.The code is storing a value in the ROM. I have tried it with "Allow writes to cartridge ROM" option on and off, and both show the message box; with this option on, the code should be allowed to do it without message box. I will check my modifications in the emulator with the option set as on; in the meantime, you can also check your code to avoid the ROM writing. Regarding the video output, I have to put it back sooner or later.

Sorry about this trouble. I'm not using the .cof format, only the ELF/DWARF one. I can check if I can write the message in the command line or the log file. In the Alpine or Debugger tab configurations, you can also turn off the rom check writing detection, it will not display the message boxes. In your case, the PC executable points outside the Jaguar address ranges, so a problem may occur in your code or in the emulator. Could you send me your testjag.cof file?

Hi, I wanted to share a new version of my Virtual Jaguar modifications to include a debugger. Except the screenshot feature, the new features are programming oriented. https://github.com/djipi/Virtual-Jaguar-Rx/releases I do changes and add features for my needs/requirements so it may be not relevant to you at all. The "Allow writes to cartridge ROM" option on and off has been fixed.

Beside the object list refresh, you can also keep the illegal and set his vector #4 in accordance and do whatever you want (infinite loop in your case). Vector #, Address, Exception name, Trigger condition 0, 000000, Reset SP, Not really a vector. Used to initialize the stack pointer. 1, 000004, Reset PC, Reset/startup 2, 000008, Bus error, Bus cycle couldn't complete properly. 3, 00000C, Address error, Misaligned (odd) word or longword memory access. 4, 000010, Illegal instruction, Tried executing an invalid opcode.

Thank you, It was very helpful.

Hi, I'm looking to create a timer, I have read there is a Programmable Interrupt Timer but I'm looking for source code example(s) to handle such interrupts using the CPU. Thank you,

Hi, I have tried your new package within the ELF format and I have the same issues as the previous package. I got some warnings in u235se.inc, not a big deal but just had the wish to report them. The symbol <U235SE_sfxplaylist_ptr> is defined 2 times; the remaining warnings are redefinition symboles: U235SE_ptr_sample_bank, U235SE_playmod and a_vde. There are also various imported symbols not referenced but doesn't prevent the assembly. Unfortunately, I'm not able yet to have a ELF executable due to the reference to undefined symbols: U235SE_playback_rate U235SE_playback_period U235SE_ptr_sample_bank U235SE_playmod U235SE_pad1 U235SE_playmod U235SE_sfxplaylist_ptr

Thank you for the source code. I had a look at it with the GFA Basic on Windows. I've some memory of the Basic GFA on Atari ST, hopefully it will be enough. I will keep you updated.

Hi, Thank you for the information about JiFFI; well, I will have a look at the source if you will decide to release it. I just had the wish to add a feature in the tool. Unfortunately COFF format is no longer supported by recent GNU (gcc, binutils, etc.). ELF format supports also the DWARF debug format which can be handy for debugging in C and a little bit for asm. I guess we can close the thread now.

I wanted to have a look at your ELF object. I have used your demo, it was easy to adapt his makefile for vasm and vlink. However I got some warnings in u235se.inc, one of them is probably easy to fix: The symbol <U235SE_sfxplaylist_ptr> is defined 2 times. Unfortunately, I'm not able yet to have a ELF executable due to the reference to undefined symbols: U235SE_playback_rate U235SE_playback_period U235SE_ptr_sample_bank U235SE_playmod U235SE_pad1 U235SE_playmod U235SE_sfxplaylist_ptr These symbols are in the dsp.elf.obj symbol table but considered as *UND*. Could you tell me with what tool you have generated the dsp.elf.obj file?