Command Line Tools

[+cubanismo]

For most carts, you can already do that via jaggd -ux demo.j64. It doesn't go through a normal boot process though, it just execs the code. It would be cool if the reset function had another mode though, where it reset without touching the ROM-space RAM and hence  booted the cartridge like it does when selecting a ROM from the menu, enabling a workflow like this:

# Wish this worked:
$ jaggd -u myrom,a:$800000  # Load a ROM
$ jaggd -rb # Reset GD and boot the ROM using the regular Jaguar boot process

But I assume that requires at least new firmware. In the meantime, you can try faking it using this tiny stub program I wrote using the JagGD Homebrew SDK (Which I stumbled upon after taking a look at the jaggd source) that calls GD_Reset(GD_RESET_NORMAL).

# This works sometimes, but not always. Why?
$ jaggd -rd -u mygame.rom # Reset to the debug stub and upload a ROM to $800000
$ jaggd -ux boottorom.cof 

You just upload your ROM to $800000+ with jaggd -u, then upload and exec boottorom.cof with jaggd -ux, and it boots your ROM using a normal boot flow through the Jaguar BIOS. Note this includes validating the ROM/checking the ROMs encryption, so be sure it has a valid header!

 

Sorry to keep editing this, but the above workaround only works sometimes. It seems flaky somehow, and I don't know why. YMMV. I've had it work 5 times in a row with different ROMs, then not work for several attempts. Very confusing.

 

boottorom.c boottorom.cof

Edited May 7, 2022 by cubanismo
Nope, still not working 100%

[42bs]

Great idea! As I wrote in another thread, I have also the problem that an upload does only works n of m times, with n much smaller then m. 

[SainT]

On 5/7/2022 at 9:09 AM, 42bs said:

Double this. Mean while I use a SD card expander to avoid wearing out the release mechanic in the GD. But during intro testing I need to rewrite the SD a dozen of times. 

Actually it would be cool to write directly into this RAM which holds the ROM for boot. And of course being able to start this via jaggd.

Same for booting a game by sending the name:

jaggd -b demo.j64

 

You can just specify $802000 as the load address and jump to that address to run from ROM.

 

I'll add the reboot and run option as well as write to memory card. I'm also investigating reliability issues now as well (started last week and have fixed a few things already).

[42bs]

 

Ha, it partly works. ?

 

I can upload to $800000 and then do a HW reset (push button in my Jaguar) and get a normal boot. So no need to swap SD cards any more.

 

And @cubanismo 's trick works for me.

 

Edited May 9, 2022 by 42bs

[SainT]

New firmware available and new command line tool with changes requested.

 

https://github.com/RetroHQ/JagGDCmd/releases/tag/v1.01

 

jaggd [commands]

-r          Reboot
-rd         Reboot to debug stub
-rr         Reboot and keep current ROM
-wf file    Write file to memory card

From stub mode (all ROM, RAM > $2000) --
-u[x[r]] file[,a:addr,s:size,o:offset,x:entry]
            Upload to address with size and file offset and optionally eXecute directly or via Reboot.
            Prefix numbers with $ or 0x for hex, otherwise decimal assumed.
-e file[,size]
            Enable eeprom file on memory card with given size (in byes, default 128)
-x addr     Execute from address
-xr         Execute via reboot
-q          Quiet, use first to suppress all non-error messages

 

For the firmware hit OPTION on boot and put the URL in, but change the /fw/ bit to /bfw/ to grab this latest beta update. If everyone is happy I'll make it public.

[42bs]

Short feedback:

-uxr works quiet well, only one should not mix it with other modes. Means doing -r, -xr, -rd make the GD hang after a while (ok, one can call is mis-use).

 

Combination "-u file" + "-xr" works also.

 

Should jaggd stay in stub-mode after a "-rd"? Currently I need to use "-rd -uxr"

[SainT]

47 minutes ago, 42bs said:

Short feedback:

-uxr works quiet well, only one should not mix it with other modes. Means doing -r, -xr, -rd make the GD hang after a while (ok, one can call is mis-use).

 

Combination "-u file" + "-xr" works also.

 

Should jaggd stay in stub-mode after a "-rd"? Currently I need to use "-rd -uxr"

 

I'll need to investigate further on odd hang still, but I'm glad it's otherwise working.

 

The stub mode is when the Jaguar is running the debug stub code and displaying the small RetroHQ logo. I need the code running on the Jaguar to be able to interact with it. So you'll need to do -rd before any time you want to upload data. The -wf option will work anywhere (more or less) as it doesn't need the Jaguar at all.

 

[42bs]

56 minutes ago, SainT said:

I need the code running on the Jaguar to be able to interact with it

Ah, ok. So it is possible, I somehow "destroy" the stub and this will prevent certain function from working.

[42bs]

Some other issue I came across: I use an SD card expander. But since it does only provide the SD card signals the GD does not detect a change of SD card (guess it is a GPIO).

So maybe pressing "Option" or "Pause" could be used to force a re-read of the SD card.

 

BTW: I was taking the 0 in "(0) Version" as O like (O)ption.

 

Ah, and since there is a key-pad, how about short-cuts for the first 9 (ROM) entries?

[+cubanismo]

Thanks @SainT, this is great support for, as you say, something it's likely very few of us use ?

 

Since you're looking at things, I want to mention another issue I noticed: I've been messing with the SDK/Homebrew interface a lot the last few days (Hopefully I'll have a cool demo to share soon. Needs more debugging first), but one thing I've noticed is if I use the SD file interface, I have roughly a 0% chance of the debug stub being usable after a reboot. It just hangs when I try to upload stuff. I have to hard power cycle instead. I'm using the GPU-based GD_FRead() command for the most part, both the synchronous and asynchronous variants, and my code ends with crashes right now, so it's definitely possible I'm leaving things in a bad state, but I would have hoped a reset of the Jaguar would reset the portions of the interface on the GD side that deal with it sufficiently for communication to work again as well. As-is, it's not a huge deal, just adds a little time to each debug cycle and puts a little wear on my power button. Now that I've worked out the semantics of the async operations, the SD card access itself appears to be very reliable.

[Chilly Willy]

5 hours ago, SainT said:

New firmware available

I checked the link from the cart and it says it's still the latest firmware.

[SainT]

51 minutes ago, cubanismo said:

Thanks @SainT, this is great support for, as you say, something it's likely very few of us use ?

 

Since you're looking at things, I want to mention another issue I noticed: I've been messing with the SDK/Homebrew interface a lot the last few days (Hopefully I'll have a cool demo to share soon. Needs more debugging first), but one thing I've noticed is if I use the SD file interface, I have roughly a 0% chance of the debug stub being usable after a reboot. It just hangs when I try to upload stuff. I have to hard power cycle instead. I'm using the GPU-based GD_FRead() command for the most part, both the synchronous and asynchronous variants, and my code ends with crashes right now, so it's definitely possible I'm leaving things in a bad state, but I would have hoped a reset of the Jaguar would reset the portions of the interface on the GD side that deal with it sufficiently for communication to work again as well. As-is, it's not a huge deal, just adds a little time to each debug cycle and puts a little wear on my power button. Now that I've worked out the semantics of the async operations, the SD card access itself appears to be very reliable.

Yep, if you get the cart into a bad state it will not accept any more instructions and therefore not reset. If you can provide examples which are hanging the GD but you think they should not I will look into why.

[SainT]

2 hours ago, 42bs said:

Some other issue I came across: I use an SD card expander. But since it does only provide the SD card signals the GD does not detect a change of SD card (guess it is a GPIO).

So maybe pressing "Option" or "Pause" could be used to force a re-read of the SD card.

 

BTW: I was taking the 0 in "(0) Version" as O like (O)ption.

 

Ah, and since there is a key-pad, how about short-cuts for the first 9 (ROM) entries?

I was thinking a refresh would be handy myself. The -wf works when the menu is running, so a refresh would be useful if you just want to upload ROMs this way. The card change is detected by the physical insertion of the card on the card socket.

[SainT]

31 minutes ago, Chilly Willy said:

I checked the link from the cart and it says it's still the latest firmware.

 

5 hours ago, SainT said:

For the firmware hit OPTION on boot and put the URL in, but change the /fw/ bit to /bfw/ to grab this latest beta update. If everyone is happy I'll make it public.

 

[+cubanismo]

12 minutes ago, SainT said:

Yep, if you get the cart into a bad state it will not accept any more instructions and therefore not reset. If you can provide examples which are hanging the GD but you think they should not I will look into why.

I want to clarify it *does* reboot, and shows the debug stub small logo screen. It just doesn't seem to accept commands afterwards, as if some link in the chain is locked up or out of sync or something.

 

I'll try to put together something usable by others shortly that demonstrates this. Right now I have a jaguar program and some files it depends on that I don't have the right copyrights to share, so I'll have to make something more minimal.

[Ericde45]

hello

 

thanks for the improvments !

 

i did some test with writing file, and i got :

 

$ ./jaggd.exe  -wf scrolling1.abs
WRITE FILE (scrolling1.abs)... OK!

 

$ ./jaggd.exe  -wf scrolling1_jiffi.rom
WRITE FILE (scrolling1_jiffi.rom)... OK!

 

but no file listed in the GD menu, even after -r and -rd + -r reboots

i tried with also the .rom version of the file

 

i put the SD in my PC and i have some stange files named ")" , "∩" and "▀" 

 

the file was not already present on the SD

 

renaming "∩" for example to .abs , and it is working in the GD menu

 

 

[42bs]

2 hours ago, Ericde45 said:

but no file listed in the GD menu, even after -r and -rd + -r reboots

Saw the same but different letters and thought this command is to save Memory Card files not for ROM files.

[SainT]

I've obviously broken something, I'll check that later!

 

It's for writing general files direct to the memory card rather than removing and adding via a card reader.

Edited May 10, 2022 by SainT

[SainT]

https://github.com/RetroHQ/JagGDCmd/releases/tag/v1.02

 

New release of the command line tool. I'd managed to not set the filename for the write file command, so it was just writing gibberish.

[42bs]

Works, _but_, directory is not reloaded. So it needs a "jaggd -r".

(But for the development-cycle it is sufficient, as for example, I write always a.j64.)

 

Just discovered, "4"/"6" jump to top/bottom of the list ?

Edited May 11, 2022 by 42bs

[SainT]

10 minutes ago, 42bs said:

Works, _but_, directory is not reloaded. So it needs a "jaggd -r".

(But for the development-cycle it is sufficient, as for example, I write always a.j64.)

 

Just discovered, "4"/"6" jump to top/bottom of the list ?

Yeah, just a quick command line tool fix, not touched the menu.

 

You can always do --

 

jaggd -wf somefile.rom -r

 

If you want to reboot to the (refreshed!) menu. Execute from memory card could also be a handy feature? Something like --

 

jaggd -wf somefile.rom -rd -x somefile.rom

 

To load the ROM from memory card then reboot execute.

 

I'll get on to the other bits as well shortly.

Edited May 11, 2022 by SainT

[SainT]

11 minutes ago, 42bs said:

Just discovered, "4"/"6" jump to top/bottom of the list ?

Those are the L/R bumpers on a pro controller, that's the same as A+UP/DOWN (page up / down). You also have other listing movement options on A+??.

[Ericde45]

hello ,

 

working fine, and the execute the loaded file would be welcome

 

thanks also for the tips for 4/6

 

 

[42bs]

19 minutes ago, Ericde45 said:

execute the loaded file would be welcome

I thought the same, but "-uxr" does what it needs.

 

But yes, a "jaggd -rd -fxr <name.j64>" whould be nice as well. No need to switch from keyboard to joypad.

("f" for file instead of "-u" for upload).

[SainT]

Yes, for the most part just using -ux or -uxr should do what you need. It's only if you happened to have separate data on the memory card and a static executable ROM that it becomes useful to upload the ROM once to memory card then run it multiple times.