Zerosquare

Yes, serial EEPROM is planned. There's nothing preventing you from using a sector in the Flash chip if you want to save the cost of the EEPROM chip, but you need to be 100% sure there's no way for the code to accidentally erase/write to the wrong sector, otherwise you can end up with a game that corrupts itself - that would be a nightmare if it happens after the game is in customer's hands. Another possible issue is that all Flash chips don't have the same blocks layout ; it doesn't matter if you always use the same chip, but we've had to change the chip model several times on the Jagtopus because the previous was either out-of-stock or discontinued.

The boards would be sold with all the components soldered, you'd only have to program them. This is both for technical reasons, and because I know not all developers like playing with a soldering iron Not yet. It depends on several things: memory size, banking scheme implementation, whether I can find a factory in China with both decent quality and competitive prices (I know a few of them, but I'd have to benchmark them)... "Just pulling the trigger" may be optimistic ; I have the theory laid out, and a partially completed older design. It was based on discrete logic though, which may not be the best solution now that I've revisited the idea. Let's say I'm not starting from scratch More than 16 MB would certainly be possible, the main limitation is memory prices (parallel NOR Flash is significantly more expensive than the serial NAND Flash that's used in memory cards and SSDs). Exactly ; not relying on old EPROMs was one of the main goal of the original Jagtopus boards, ten years ago. It turned out that the supply of EPROMs did not dry up like I was expecting (the amount of old/recycled parts you can get from China is amazing...), but you still have more guarantees with new parts. @SCPCD is the one who designed and manufactured the programmers; I don't remember their cost exactly, but it was several hundreds euros if memory serves, not including the time he spent soldering and testing them (which is why only 3 or so of them have been manufactured). Ouch -- I had no idea the stocks levels were so low! Thanks for the warning.

Besides the $800000 ~ $DFFFFF cartridge ROM area, the Jaguar has a few other areas that are accessible over the cartridge bus: GPIO0 & GPIO1 are not available (they control the cartridge's EEPROM), but other should be usable to put the banking register(s) in. The register(s) bit layout has not been decided yet, it will depend on the banking scheme. Yeah, I should have put a link to the Jagtopus v1 thread for info: I have not set a target price yet. I prefer to evaluate the various options first. Yeah, "real" gold (as opposed to flash gold, which is just a very thin layer) is expensive There are two existing options for programming Jagtopus PCBs: - uploading the code from a PC thru the 2nd joystick connector. But since the throughput is limited, it would probably be too cumbersome for 8+MB games. - using an external programmer designed by SCPCD. It's a much better option for mass production, since it can program 4 PCBs in parallel. But the hardware is not cheap (the design hasn't been optimized for cost, and the 4 cartridge connectors alone are pricy). Using the JagCD is a possibility, but my religion forbids me from even looking at that thing (seriously though, anyone wishing to try it is welcome, but don't expect me to.) Using a JTAG programmer may be an option, but that requires a CPLD with connections to the entire address and data buses, which may raise the price. One possibility I've considered is a modified Jaguar: the ROM image would be stored on a SD card connected to the joystick or DSP port, and a custom BIOS would automatically program the Jagtopus PCB.

Yes, bankswitching is needed to make it work. The simplest scheme would be this: - $800000 ~ $BFFFFF: fixed area, always maps to the first 4 MB of the ROM - $C00000 ~ $DFFFFF: configurable area, can be switched to any bank More elaborate banking schemes are possible, but I don't yet know how they would impact the price (depends whether a small CPLD is significantly more expensive than discrete logic).

Yes, scaled sprites take longer to be processed by the object processor than standard ones, even at unity zoom.

A few years ago, I started working on the next version of the programmable Jagtopus cartridge. I wanted to add support for larger Flash memories (8 MB and up) and larger save EEPROMs (say, 32 kB), and maybe a few other extras. I designed a schematic, started routing the PCB, then I got distracted by other projects and never finished it. To be honest, the lack of demand for bigger carts was also a factor. Recently, there have been talks of projects needing more than 4 MB of ROM. Yeah, I know what's you're thinking: what's the point of such a project, now that the JagGD exists? Well: - not everybody has one - some people prefer physical cartridges over SD cards or digital downloads, either because they like collecting physical stuff, or because they feel part of the nostalgia is using the console like it was used back in the day. Here's where I need your feedback. As homebrew developers: - what do you think of the idea? - would such a product be useful to you, and if so, how would you use it? - besides the larger memories, are there any extra features you'd find useful? (please note that unlike the Skunkboard and the JagSD, this would be a cost-optimized design for releasing games, not a development tool or a multicart. So don't expect anything too fancy ;)). At the moment, this is just a potential interest check. No promises, no preorder lists, nothing has been decided yet

Yes.

Yes. Once a game has been copied into the Skunkboard, you can use it like a regular cartridge.

It depends on the ROM chips that are used in Genesis cartridges. If they're the same as those in Jaguar cartridges, it should work as well.

A Windows version of those two games is available, and the VCS is basically a PC running Linux, so in the worst case you could possibly use Wine to play them on the VCS. Also, while Orion_'s site doesn't mention it, I think he made Linux versions of some of these games at one time ; but I can't remember if Elansar and Philia are among those.

Interesting. I didn't imagine you looked like that. ...oh wait, you said stickler. Never mind...

Try erasing and programming again. If the files are the correct size, there's no reason why it shouldn't work.

You need to type this in a command line: copy /b AVP.HI+AVP.HI AVP_HI.BIN copy /b AVP.LO+AVP.LO AVP_LO.BIN You'll get two 4096 kB files, AVP_HI.BIN and AVP_LO.BIN. Those are the files you should use to program your two M27C322 EPROMs.

M27C322 EPROM chips appear to have the same pinout as the original ones, except pin #32 is A20 instead of /BYTE. So this should work, but you need to program the original ROM file contents into both halves of the EPROM. The programming software may have an option to do that, otherwise you can use a command prompt to create a suitable ROM file for your 4 Mb EPROMs: copy /b input_file.rom+input_file.rom output_file.rom

In theory yes, but you'd have to design a new PCB. It would also make cartridge access slower, which may cause problems with some games. I don't think anyone has ever tested it.

Wait a minute... I can see a mouse in your picture!

There's a piece of cardboard under the PCB. Have you looked to check there's not something nasty here?

Indeed, but the frequency difference is tiny: 26.590906 MHz for NTSC models, 26.593900 MHz for PAL ones. So a switched console will have timings that are off by 0.01126%. A more significant difference is the color encoding. Switched consoles keep their original subcarrier frequency and phase inversion setting, even when they're switched to the other mode. In other words, a PAL console switched to NTSC mode will in fact output 60 Hz PAL, not true NTSC. It may be an advantage or a annoyance depending on the TV/monitor/converter you're using (unless you're using the RGB output signal, in which case it doesn't matter).

@dilinger has created a fork of Virtual Jaguar with added debugging features: But I don't know if it supports CD emulation.

While you're right about the smell of leaky capacitors, I don't recall seeing any or hearing about them being an issue in Jaguars, unlike some other consoles.

Just as a reminder: some of @CyranoJ's ST ports include mouse support, but dead ones won't work.

Nothing unexpected here. Cats tend to catch mice, you know.

@Austin: did you record the part where you played the "normal" Tempest X3 mode as well? I find it interesting as well, even if it's not quite Tempest 2000.

Does it include randomly failing to load games? Otherwise, it's not an accurate emulation.

Demand is obviously higher for rarer genres and well-made games, but the Jaguar community also includes a significant number of people who are willing to pay for anything, regardless of the quality or novelty (whether they actually play those cartridges is another matter).