Jump to content

SainT

Members
  • Content Count

    1,656
  • Joined

  • Last visited

  • Days Won

    25

SainT last won the day on October 29 2019

SainT had the most liked content!

Community Reputation

5,113 Excellent

About SainT

  • Rank
    Stargunner

Profile Information

  • Gender
    Male
  • Location
    Gloucestershire, UK

Recent Profile Visitors

15,243 profile views
  1. Try giving the memory card and memory card socket a clean if you can. Unfortunately if this doesn’t work it may well be a bad contact on the memory card socket. I’ve seen this a few times and you’ll need to get a replacement. 😕
  2. I don’t produce any sound in the menu, so there is no audio to drown out the poorly shielded audio cabling. It is entirely normal for old systems to have buzz in the audio. The change in pitch, etc, is the interference from the video signal being manifested as sound.
  3. No idea, not something I’ve ever needed to do.
  4. Yes, from the GD game menu, press B+A with a game selected. Look at where it says "Save:". It needs to say "EEPROM". If the game supports EEPROM saves, and it is shown to be enabled in the header as described above, then it should work. The ".e2p" EEPROM file will not be written to the memory card until the game tries to write to the EEPROM. So unless the game tries to write to the EEPROM, then to save file will be created. I have no idea if other flash carts check the header info before enabling EEPROM support, but I support all possible EEPROMs from 128B upto 1KB, so I check for support and also size before enabling. If all the above checks out, but you still have no ".e2p" file, then it's possible there is a fault. It's not something I have encountered so far, though.
  5. The issue with certain homebrew is a known issue, and as far as I am aware there are fixed versions of these games available. Unless the LNX file indicates the cartridge has an EEPROM, it will not work. Make sure the LNX file is correctly setup. You can view what the settings in the header are by pressing B+A (I think?) from the menu on the game.
  6. Yep, I need to have a look at that ISO, I have not done yet. With homebrew stuff there is every chance the disc has been mastered without the required header and footer signatures in places. This is incorrect from a standards point of view, but may well actually work OK. Games will have their own marker data in the track for alignment purposes. There is one other title (Robinson's Requiem I believe) which also has this issue on one track. It appears to run OK, but I don't know for sure if it tried to access that particular track whether it will fail.
  7. Please do let me know what the outcome is! All information about why things are not working is useful.
  8. At this point I can only think Tom is faulty. I can't rule out there is some other issue I am not aware of with the cartridge, but it appears to be doing what I would expect, however the interrupt is not being handled. The interrupt processing is reading / writing to the FPGA on the cart, but given you can get to the point of even loading a game, general reading and writing to the FPGA must be working. At this point, I can only suggest trying a different console or different GD cart.
  9. Ok, interesting. So if the interrupt is making it through to the actual pin on Jerry then either Jerry is faulty, or the external interrupt relay from Jerry to Tom is not working. It's the GPU (Tom) which actually deals with the interrupt, but it's triggered via Jerry. Looking at the schematics and technical reference you have DINT going from Jerry to Tom for this -- pin 24 on Jerry and pin 47 on Tom. This will be the next thing to check.
  10. Lol, wtf?! It does make sense, but then that means the pin numbering on the larger chips is all over the shop. Totally nuts.
  11. I have to say that's the weirdest pin numbering I've seen on a chip. It's customary to have either the middle or edge pin be pin 1, not a pin three in from the edge. That's nuts. I've doubled checked the schematics, though, and it is indeed correct. Pin 35 as marked above goes to R9 just below the chip, which is correct!
  12. I can't see how a list of games and MD5's would be an issue myself, it's in no way linking to anything copyrighted.
  13. More details provided and followed up in PM thread as well, but for anyone else reading -- the cart should not boot to the Jaguar logo at all. It is setup to boot directly to the RetroHQ logo. If it boots to the Jaguar logo it is not reading the boot ROM on the cart correctly, either a dirty cart edge / connector or an issue with the actual data on the FLASH or even damage to the cart.
  14. I've just had a look, EINT1 isn't used currently and EINT0 is used for the interrupt driven data transfer, so that is correct. So the cartridge *IS* correctly generating EINT0 to indicate data is available, but the Jaguar is not responding. So it does look like a faulty console, not cartridge at this point. Next is to check the connection between the cartridge port pin for EINT0 (B25) and pin 36 on Jerry. I think it's a direct connection without and buffer chips in-between. It's also pulled up to VCC at R9, so that's worth checking continuity there as well. You may find there is a bad solder joint on Jerry at this pin, or the trace may be bad at some point along the way. Try testing at the trace edge of the chip leg and also the top of the chip leg away from the trace. It can be useful to test at both locations, as with a dry joint you can appear to get a signal near the trace, but you will not at the top of the chip leg. If this is the case reflowing this joint with some flux should sort it. All very interesting!
  15. No, not yet. I'll publish the source before long -- as ever, just trying to find some spare time to get it done. Someone will be able to do a Mac build easily.
×
×
  • Create New...