SainT

That’s good to know! With one test I set the buffer sometimes to GPU RAM and sometimes to DRAM based on the value of a counter, and that didn’t hang. However it was not very GPU heavy, mostly it was going to DRAM. So there must be some odd timing / contention related issue? If I have a tight loop of calculating the next span location and then starting the blitter and immediately waiting for completion it hangs pretty quickly (within a couple of seconds) but run fine forever when writing to DRAM. I’d certainly be interested to see any GPU code you have with blitter use like this. It might be if I just add a large delay (which will actually be time taken by processing the buffer) after the blit wait has completed it may be happier. I’m just trying to get a proof of concept of getting the data where I need it before proceeding! The idea here is rather than using the GPU to process the DDA to fetch multiple bytes at an arbitrary angle from a byte map, get the blitter to do this and put it in a linear buffer for far easier processing by the GPU and in parallel.

A bit more poking -- if I set the destination address to the object processor line buffer, that works, or anywhere in main RAM it works. Even Jerry RAM works, although it's quite slow. I'm starting to think you may only be able to blit into GPU RAM when the GPU is halted? Which would be a bit crap. And just for reference this is using 32bit per pixel, in pixel mode, with A2 as destination so A1 can scan arbitrarily across some data. All buffers are phrase aligned.

Is it possible to blit into GPU RAM while the GPU is running? Am I missing some magic? I have some code which, for test, is copying some data to some screen memory. I can see if copying, it's a small buffer, there's no overflow, and it's working fine. If I change the dest address to be within the GPU RAM it just dies. 🤷‍♂️ I've seen quite a few comments about blitting into GPU RAM, and there is even the write only 32bit space at G_RAM+$8000 specifically for this purpose. It seems crazy this isn't working...

It's nothing to do with memory contents as far as I am aware, in the case of Battlemorph the Jaguar is missing an interrupt from the JagGD which then causes it to just wait forever. I don't know why this is happening (I'll continue to look into it, as it's really annoying me!), but as soon as it starts booting it seems to be pretty stable. So it really is strange. The only thing I can think is tiny timing changes when accessing different versions on the memory card is somehow allowing the interrupt to register. It really does make no sense!

Fantastic! I'm really pleased to hear this last update has been generally successful for everyone. 😄

It varies, sometimes I need to boot it 10 times to get it to run, other times it runs first time. Having multiple copies on the same memory card and running different versions also seems to change behaviour. This is one area I want to figure out. The Jag is missing an interrupt and I really don’t know why.

Fantastic, glad it’s working for you! I think the general consensus is that this latest update does seem to have improved stability a bit further. There’s still a couple more things I’d like to have a look at which may help further again, but in general I’m starting to feel reasonably happy with the CD support. 😄

Hmm, I could have sworn Philia and Elansar were working. Or at least they appeared to be — I.e. I could see they were creating sensible save files. I’ll have to check on those again. I know robinsons requiem is not working, it comes up with a ‘not enough space’ error and I don’t know why. Debugging is a pain as it seems to use a tokenised scripting system which really makes the code flow very hard to follow. 🙄

It’s not possible to have overlays, no. It’s not an emulator. I don’t really see the point in having them in the game menu either as you will have forgotten them by the time you get to the game? You’d be better off searching for it on your phone while playing so you can reference it.

Press the massive “DOWNLOAD FIRMWARE” button which is in blue. I tried to make it as obvious as possible. This will get the latest firmware for your cart. You can also use a version specific file if you want (downloaded as .ovr), but delete the file after it’s updated or it will update every time you boot.

You pressed option twice, that’s the serial number screen. Press option again to get to the update link screen. Option switches between them.

Ok, that's fixed now, new firmware available. Exactly the same as the last, except it actually updates everything properly! It's been a couple of years since I touched the code and I'd forgotten I'd not completely segregated the updater as I normally would, so the updater for the Jaguar side is relying on the menu firmware rather than the boot firmware. I'd made some changes to add functionality which required an update on the Jaguar side too, which then broke the updater as that code does not change. Anyway, fixed.

That completely explains why it doesn't work! I'll dig into it. I have a gut feeling as to what's happening but will confirm in a day or so when I get the chance to have a look.

I've removed the update for the moment as people seem to have had issues. I have an idea to what it might be, so I'll investigate further. Likewise the link for the old version of the cart has also been removed until I can figure out what's happening.

Having the menu at an older version will definitely cause bad things to happen with the latest firmware. I’ll investigate further as it sounds like it’s not an isolated issue.

There’s some question as to whether it’s updating everything. Check the versions by hitting 0 on the menu and see what you get. If the menu version is wrong, rename the .upd to .ovr and see if that works. If it’s still doing nothing, try copying it to a blank memory card and trying again.

Update files are one shot use, so don’t keep them. Make sure after update that the versions numbers are correct when you hit 0 on the menu. There’s no reason they shouldn’t be, but it sounds like some people’s didn’t update. If you have any issues with the update then get another QR update link and click the top link on the versions list. This will download a firmware.ovr file. Update using this, it forces everything to update rather than just the bits that changed.

There’s one thing it might be. See how you get on, I may do a private update for you to test with just one change. At least it would help rule things out. Is ROM loading affected?

Interesting. Stick with 1.13 then! It's definitely been no worse on my Jag, and generally a bit better. Unfortunately there's little I can do to figure out why, either.

DM'd.

If you have a cart which has the QR update system, you have to use it. There's about 200-ish JagGD carts in existence which don't have it, so of the active user base it's very few. I don't like posting the link for the older carts publicly as everyone with the new carts then downloads it and asks why it doesn't work.

Ok, a new firmware update has been released. I've fixed one of the issues I was seeing with WTR which was causing instability, it still dies if left on soak, but I think it's improved. Likewise I've fixed some other potential issues, but am not sure how much things have improved due to this. Issues with memory track on homebrew (notably Yopaz and Alice) have been fixed. These were actually due to junk being passed instead of a filename, so I've accommodated for this by using "NONAME" where junk is passed. Save on Robinsons Requiem is still misbehaving and I don't understand why.

WTR is a pain, I know it has issues. There does appear to be an issue with one of the CD tracks missing data markers, but I don't *think* this is actually causing any issues.

Sure, there's a hidden folder on the root of the memory card called "MTRACK". This contains all the memory track save data.

It has crossed my mind, but it would mean starting again from the ground up, so it's not at the top of my list of things to do!