SainT

I'm not sure how you save with Highlander, but it's detecting and using the memory track just fine. Very odd game. 😆

Nope, this is a SCART cable thing.

Do you make sure the wide sync setting is enabled with the latest tink4k firmware?

Ok, figured out what's going on, the GDBIOS is not being correctly initialised from Raptor. Not sure why yet. The bindings on GitHub call GD_Init on installing the GDBIOS. The test ROM above is not doing this. The only thing the init function does currently is to map the FIFO block into memory so it can be read directly for faster data transfers, which is why the data coming in is junk (or just FF in this case) when running from ROM. When running via USB upload it jumps to the code directly and the FIFO is still mapped in. The reason small files worked is that for transfers less than 32 bytes it does a byte by byte copy from the serial FIFO register rather than using the memory mapped FIFO. I'll liaise with @CyranoJ to get this fixed.

Looking at this now.

Ok, I now have USB transfers of 4MB ROM's working reliably. I *think* it's resource contention on the microcontroller, I had an inkling it might be this as this was actually one of the problems with WTR. As there's lots of DMA activity going on between the memory card and Jaguar, somehow some of the clocks were being missed from the memory card causing data loss. In this case I think similar weirdness is happening between the USB and Jag DMA channels, although you have no control over the USB DMA priority, so I've just opted to make sure the USB and Jag DMA channels aren't active at the same time. The actual data coming in from the USB was always correct as I CRC'd and displayed it on every read (USB actually has CRC checking as part of it), so the data going to the Jag was somehow being dropped or corrupted due to contention. The result -- it's now working solidly with 4MB ROM's, where it really just would not work at all for me.

Hi! Download the menu ZIP and extract it to your FAT/FAT32 formatted memory card, that should be all you need to do. https://www.retrohq.co.uk/products/atari-lynx-gamedrive-classic-flash-cartridge It may take a second or two on the "INSERT GAME" screen on the Lynx before the menu loads.

I’ll figure out where the issue is! I’ll go step by step and crc each section to figure out where the issue is. It may be a timing issue between the Jag and GD or might be USB. I don’t have much of a clue yet, as I’ve not dug very deep, I’ve got as far as confirming it’s not a write error on the Jaguar side into cartridge RAM, which I thought it may have been. So one step down…

It may depend on your USB setup and definitely depends on the data size. I think @CyranoJ said it improved when he got a new hub or went direct to the PC with the USB cable, or something along those lines. The good news is, I've been able to replicate it quite reliably by loading up a ROM via USB and rebooting the console and getting the Jag to do a CRC check. 2MB ROM's will work most of the time, but do red-screen pretty randomly, while 4MB ROMs rarely work. I'm now trying to figure out where along the pipeline data is getting dropped or corrupted. 😬

Working on these things at the moment. Just having a look at the USB upload stability currently, then I'll have a look at the other dev stuff.

If it says unsupported, then the mapper is not currently supported. I may be able to add support, but it depends on the mapper used. I'm not sure if they are DPC+ (ARM) based games, if they are, they will never be supported. If they are just one of the various homebrew mappers, then maybe!

I’ve got virtually no space free, so supercharger support is very unlikely.

This is rather an old post to reply to, but I just happened to see it. Do not plug non-Sega Master System / Mega Drive peripherals into the Mega7800. Just as you would not plug your Atari Vox into your Master System, do not plug it into your Mega7800. Power and ground are in different places on the different pin-outs. Thankfully not in such a way which is likely to cause damage, but it's generally not a good idea.

I can always make an alternative firmware which ditches 2600 support in favor of bigger and better 7800 features...

Oh, now that's cool. Always nice to see some of the what-could-have-been hardware in action!