Zerosquare

A very important option that should always be used when developing stuff for the Jaguar.

...but it hasn't prevented them from doing so in the past. If you want to be extra sure, next time just remove the Atari logo/name. That's the only thing they care about.

Even if you disregard the technical and financial aspects, it boils down to this: you want some piece of knowledge to be available to certain people (legitimate developers, who need to know how the technical protections work), but not to other people (pirates, who would use this knowledge to duplicate games). How do you achieve this? On which criteria do you decide "this person is/isn't a legitimate developer"? What happens if someone you trusted turns rogue? Commercial companies solve this problem by making people sign Non-Disclosure Agreements, which are legal contracts which allows them to sue people who don't respect them. But you can't do that with homebrew developers. (Note: this is a bit of a simplification. There are also technical means to try to solve the problem, but they're too heavyweight to make sense for homebrews.)

That was exactly the mindset I had when the Jagtopus was designed back in 2010. Unfortunately, since then, there have been several cases of people making and selling counterfeits of Jaguar homebrew releases. And at least one of them apparently spent money creating a (poor) custom board just for this: I'm not saying that your decision is wrong, just that piracy is unfortunately still a problem. There is an USB-based BJL adapter for modern computers: It hasn't been publicly released, since more convenient options for development (Skunkboard and JagGD) became widespread, and production mostly used a dedicated programmer. But the design is complete and functional. It could probably be reused with AA carts if there's a demand for it. One advantage of using an inverter is that it's completely separate from the bankswitching, so it can be used even if the bankswitching logic isn't populated because the game is small enough not to need it. It could even be used on traditional ROM boards, by putting the SPI EEPROM and the inverter on a small PCB that would be soldered where the Microwire EEPROM normally is. But yeah, it's a pretty minor difference. And depending on how you latch the signals, it may even be possible to write code which supports both schemes transparently.

Going back to this for a moment: Can you or @Albert tell more about the status of the design? Is it "fully-closed" - something made specifically for AA, with no public technical details? Is it "partially-open" - while the boards themselves are only made by AA for AA, some/all of the technical details are public? Is it "fully-open" - the design is owned by AA, but someone would be allowed to make compatible boards? Something else? The answer will impact future projects for me, and possibly others. Especially regarding compatibility (or incompatibility, if you want to prevent AA code from running on a non-AA board, to thwart certain sleazy individuals making pirate copies.) Thanks.

With current prices for Jaguar stuff, that must be worth something like $100,000, right?

The CS pin is active-high for Microwire, but active-low for SPI (and it needs to remain active while you're transferring the command and data bits). And you can't control the state of the CS signal from the Jaguar directly, you can only trigger a short low pulse on it. So you need an inverter on this signal to make SPI work. Here's a basic test program: SPI EEPROM read test.s It reads the first 64 bytes of the EEPROM and sends them to the serial port at 9,600 bps. I used an EEPROM that was already programmed, so there's no code to write to it, but it shouldn't be difficult to add by following the steps described in the EEPROM datasheet. I wouldn't recommend hot-swapping Jaguar carts And it wouldn't work anyways, unless you modify your Jaguar not to power-off when there's no cartridge. So, BJL, indeed. Or JagCD, if you're crazy and only need to program the cart once (as after it's programmed, the Jaguar will boot from the cart, not the CD). For BJL, I have some software made for the Jagtopus, as well as an USB adapter to connect to modern PCs which don't have parallel ports. There's a high chance that the software would work with your cart, either as-is (the programming commands are the same on most Flash chips) or with minor modifications. It's not really user-friendly, more like a developer tool, but it works. Let me know if you're interested. (We can discuss the details in private if you prefer.)

@mdkdue : basically, you're saying Wave 1 Games promised this: but delivered this: ? Yeah, must be a one-time fluke. I mean, it's not like it had happened before with his products. Not once, and definitely not ten times. /s

Oh, that part's easy. You can do that by adding a few 0 ohm resistors on the Flash memory address lines. That way, you can bypass the bankswitching logic completely if you don't need it.

OK, it doesn't really count since I never did finish routing the board: You mean something like this? I can confirm, it works fine. EDIT: if you need test source code for the SPI EEPROM, just ask.

Or at least, if you don't want to spend money until you know the Jaguar is working, forget messing with RF, and tap into the composite video signal directly:

No, the cartridges PCBs are the usual thickness (1.6 mm). The issue is the connector that the cartridges are made to plug into.

Yes, you can program thru the cartridge connector, either by using the Jaguar directly (connected to a PC by BJL) or with an external programmer. That's how it's currently done on the Jagtopus. But since getting Jaguar cartridge connectors is getting more and more difficult and expensive, I agree that an additional connector would be useful. I'd have to see how much traces rerouting would be needed to add it.

You could do that, by adding a separate programming connector and adding voltage translation logic to replace the CPLD. But at this point, you'd have essentially transformed a Skunkboard into a Jagtopus. But if a product-breaking bug is discovered after release, commercial companies have the financial means to do a product recall and fix it (even if they hate this). For an individual homebrew author, doing so would probably wipe out most or all of the profits. Also, the specifics and granularity of write protection tend to vary between models of Flash memories (top-boot vs bottom boot, etc.). And past experience with the Jagtopus taught me that you can't rely on a specific part number (or even manufacturer) if you don't want your design to be obsolete in 6 months when the memory chips are no longer available. Especially now, with the semiconductor shortage. Again, if you want to use Flash memory for saving instead of the EEPROM, you can do it: the hardware supports it. I'm just pointing out the potential issues.

If it had only the Flash memory on them, how would you program it? Also, IIRC, the Skunkboard uses the CPLD to do 5V/3.3V voltage translation as well.

Yes, you can do that. But there's the risk that a bug could cause an erase/write to the wrong sector and corrupt your game code or data. Whereas with a separate EEPROM for saves, you can write-protect the Flash and be 100% sure that won't happen. I believe it's a choice each developer should make themselves. You could potentially achieve that (I'd have to check to be sure) by running the data transfer code in a timer interrupt, or in the idle loop on the DSP. But I very much doubt it'd be fast enough to be useful for anything, and it would waste a lot of bus bandwidth (even without the overhead, you'd be wasting 64-bit bus cycles to transfer just a single bit at a time).

The largest EEPROM which is a drop-in replacement is indeed the 93LC86, which stores 2 kilobytes. Larger EEPROMs are not available with a Microwire interface, which is what the Jaguar carts were designed for. Using a SPI EEPROM instead would allow much larger sizes, but requires a bit of extra logic on the cart. But now that you mention it, it would be possible to make a very small PCB with the SPI EEPROM and the logic, that could be soldered where the original EEPROM normally is. That would allow upgrading existing cartridge PCBs. I wouldn't rely on it to store game code or data, though -- the data path is only 1-bit wide, and it's slow to access.

I'm sorry to say this, but I think you may have an addiction problem.

Yes. For 6 MB you have two solutions: Use a 4 MB chip and a 2 MB chip Use a single 8 MB chip Since the second solution is both simpler and cheaper than the first one, there's no reason not to go 8 MB. You don't even need to anything, as long as you make sure the default configuration maps the first 6 MB of the Flash memory to the 6 MB address space. Games made for 6 MB don't attempt to bank switch, and thus won't even be aware than there is more than 6 MB of data accessible.

Yes, it's possible. I have designed some logic for it, but not tested it yet.

That's nonsense. They're exactly the same size as American bits, they're just upside-down.

Bubsy could be compressed into a zero byte file with no loss of enjoyability.

I already have a working solution for this. It requires only minor hardware and software modifications. Good points. A simple and cheap programmer would be useful as well.

Here are the values I measured: Height: 88.4mm Width: 108.0mm Thickness: max. 19.5mm These are the outside dimensions, including the handle. Thickness is hard to measure exactly since surfaces are curved. All official games use either charcoal (most common) or black plastic. Some homebrew releases use translucent or clear cases. First-party games feature an Atari logo at the back of the case, third-party releases don't have it. Otherwise there is no difference. Game region doesn't matter, as there is no zoning and all games are compatible with both NTSC and PAL consoles. (A small number of them were re-released later with a few optimizations for PAL consoles.)

Also, be aware that the current semiconductor shortage is hitting hard on memory chips. Sourcing them is an issue (unless you're OK with buying zero-guarantee stock from China, maybe...)