JagCF. Coming Soon or Dead to the World?

[+doctorclu]

Something else that may belong in the 'Flashcart FAQ' - if your power supply is marginal or some odd underperforming third party one, you may have issues with the flashcart. It uses a bit more power than regular carts do. And a wee bit more than the Skunkboard.

 

You know this is the weird thing about under powered third party power supplies, first off, it is hard to find a power supply of the right voltage and amperage. What some people try to pass off as the right power supply I wouldn't feel good using. Right voltage, waaayyy under amperage. Andthey tell me "This will work with a Jaguar" Yeh but it will run hot. I gave up on the third party idea and just bought a Jaguar power supply from B&C.

[RGB_Gamer]

Something else that may belong in the 'Flashcart FAQ' - if your power supply is marginal or some odd underperforming third party one, you may have issues with the flashcart. It uses a bit more power than regular carts do. And a wee bit more than the Skunkboard.

 

 

I am in the process of testing each and every game that works and doesn't work. will report the results soon and upload a good working set to usenet or something

[+doctorclu]

Something else that may belong in the 'Flashcart FAQ' ...

 

 

So is anyone up to the task of writing a Flash Cart FAQ?

[BuddyBuddies]

Something else that may belong in the 'Flashcart FAQ' ...

 

 

So is anyone up to the task of writing a Flash Cart FAQ?

actually its called a "Flash Card" not a "Flash Cart", i know this because thats what it says on the ones the have serial numbers . Most games should load to the Flash Card,i havent heard of any that didnt that i can remember,but i guess its possible.

[+doctorclu]

Something else that may belong in the 'Flashcart FAQ' ...

 

 

So is anyone up to the task of writing a Flash Cart FAQ?

actually its called a "Flash Card" not a "Flash Cart", i know this because thats what it says on the ones the have serial numbers . Most games should load to the Flash Card,i havent heard of any that didnt that i can remember,but i guess its possible.

 

Another basic fact to add to the FAQ.

 

Seems some games start right up after load, others require you to power down the JAguar, disconnect the "card" somehow, and power it back on to work right. Any ideas why that is?

 

In my case just glad my flash card is fine and not glitchy.

[RGB_Gamer]

Something else that may belong in the 'Flashcart FAQ' ...

 

 

So is anyone up to the task of writing a Flash Cart FAQ?

actually its called a "Flash Card" not a "Flash Cart", i know this because thats what it says on the ones the have serial numbers . Most games should load to the Flash Card,i havent heard of any that didnt that i can remember,but i guess its possible.

 

Another basic fact to add to the FAQ.

 

Seems some games start right up after load, others require you to power down the JAguar, disconnect the "card" somehow, and power it back on to work right. Any ideas why that is?

 

In my case just glad my flash card is fine and not glitchy.

 

 

Yea it's like this for me. Well, whatever way the games work, I am happy with. It's not that big of a deal to have to turn the system off and then on. I just wish someone would make a GUI frontend for the flash utility (and support long file names) or perhaps a linker that doesn't require the Jaguar to be near the PC.

[+doctorclu]

Yea it's like this for me. Well, whatever way the games work, I am happy with. It's not that big of a deal to have to turn the system off and then on. I just wish someone would make a GUI frontend for the flash utility (and support long file names) or perhaps a linker that doesn't require the Jaguar to be near the PC.

 

I'll pass on that you said that to some people. Don't worry about that for a bit. In the meantime, enjoy the Jaguar Flash CARD (taking Buddy Buddies's correction there) and what it can do for images, demos, dev tinkering.

 

Oh, if there WERE to be such a GUI interface, what features would you want on it?

[+remowilliams]

Another basic fact to add to the FAQ.

Yeah my bad, it does say Card right on it.

 

Seems some games start right up after load, others require you to power down the JAguar, disconnect the "card" somehow, and power it back on to work right. Any ideas why that is?

Must have something to do with the way the flash card code handles the boot vs the game code. Especially in cases where it won't start at all unless the cable is physically disconnected.

 

One other thing I've been thinking about doing is putting the card into another jag cart case. One that's been predrilled for lots of ventilation. The little bugger gets pretty hot.

 

Also worth noting that the flash software works under VMware virtualization if you have a DOS vm setup. Pretty handy.

[Gorf]

Though I dont know if any developer used it, it is very simple to code a game

on the Jag such, that it wont boot from a flash. It's like two lines of code or so.

 

My guess is that might be the case. Gorf Classic cant run on an alpine, flash or

a BJL, even if you extract the executable from the CD. It would have to be

hacked a bit to run on either.

[kskunk]

About the JagCF, we'll have more news in a few days, at the RGC 2008

 

Europe is too far for some of us. It's too bad too, since all the cool parties seem to be happening over there this year.

 

For those of us who couldn't make RGC, what did we miss??

 

- KS

[Zerosquare]

For those of us who couldn't make RGC, what did we miss??

Lots of fun.

 

But seriously, about the JagCF, not much. Pocket was mistaken, we didn't make a presentation this time. Lots of progress has been done, but it is "internal" : modifications to be able to use a QFN package for the FPGA instead of a BGA one (it will make the PCB much easier to manufacture) and a lot of VHDL coding. Not something you can really demonstrate to a non-technical audience.

[kskunk]

For those of us who couldn't make RGC, what did we miss??

Lots of fun.

 

 

But seriously, about the JagCF, not much. Pocket was mistaken, we didn't make a presentation this time. Lots of progress has been done, but it is "internal" : modifications to be able to use a QFN package for the FPGA instead of a BGA one (it will make the PCB much easier to manufacture) and a lot of VHDL coding. Not something you can really demonstrate to a non-technical audience.

 

Sounds smart to me. Tursi used a cheap Malaysian place to do the Skunkboards, and they even had problems placing a few of the 0.5mm leaded QFPs. BGAs would be big trouble unless you find a very good manufacturer. A few extra dollars spent on a good manufacturer will pay for itself in improved yield...

 

Come to Classic Gaming Expo in 2009! I will be there for sure.

 

- KS

[Tursi]

Just a quick reply to an old comment:

 

Or it could be the same issue as the Skunkboard's : perhaps the Flash cart is slower than the regular ROM chips (but I doubt it).

 

Skunkboard's flash is much faster than the regular ROM chips. But it runs at half the bus width, that's the most likely place for incompatibility to strike.

[Zerosquare]

Just a quick reply to an old comment:

 

Or it could be the same issue as the Skunkboard's : perhaps the Flash cart is slower than the regular ROM chips (but I doubt it).

 

Skunkboard's flash is much faster than the regular ROM chips. But it runs at half the bus width, that's the most likely place for incompatibility to strike.

Yup, I meant the Skunkboard as a whole, not the Flash chips themselves : they're going to be faster than old ROMs from 1994, of course

[kskunk]

Just a quick reply to an old comment:

Skunkboard's flash is much faster than the regular ROM chips. But it runs at half the bus width, that's the most likely place for incompatibility to strike.

Yup, I meant the Skunkboard as a whole, not the Flash chips themselves : they're going to be faster than old ROMs from 1994, of course

 

The Skunkboard as a whole is twice as fast as a Jaguar ROM cartridge when running 68K code or texture mapping. When doing bulk copies or object processor access, it is the same speed. That's because it runs its half-size bus at double-speed.

 

So in many circumstances the Skunkboard improves performance, but in the worst case it produces the same performance. We should document that fact so some poor developer doesn't do all his development on the Skunkboard only to discover that performance is reduced once he burns a real cart!

 

One interesting side effect of this is that you can actually get better texture mapping performance from Skunkboard->DRAM than DRAM->DRAM (since you avoid page thrashing). Unfortunately, anyone using this trick is confined to the Skunkboard/JagCF... or CoJag. CoJAG has two DRAM banks set up in this way to improve blitter performance.

 

- KS

Edited November 15, 2008 by kskunk

[Zerosquare]

Very interesting !

 

So I misunderstood your previous explanations, since I thought that the Skunkboard could be slower than a real cartridge in some cases.

 

It raises an interesting point : as the Skunkboard is always at least as fast as the real thing, from where could the compatibility issues with existing games come ?

Does that mean there are games that are so broken that they don't work with faster memory accesses ?

Or which rely on a specific cartridge data bus width (but you'd have to almost do that on purpose, since the hardware hides it) ?

 

Or is it the lack of an EEPROM, or other things ?

Edited November 15, 2008 by Zerosquare

[Tursi]

I haven't done extensive compatibility testing because we don't support existing games, so I don't need to have that information. Of the failure cases I am aware of -- JagCD and Stubulator BIOS -- JagCD is a mystery and Stubulator assumes both the bus width and the start address, both assumptions are wrong on Skunkboard. It's entirely feasible that other programs may also make bad assumptions, but those are the only two I'm aware of.

[kskunk]

It raises an interesting point : as the Skunkboard is always at least as fast as the real thing, from where could the compatibility issues with existing games come ?

 

Does that mean there are games that are so broken that they don't work with faster memory accesses ?

Or which rely on a specific cartridge data bus width (but you'd have to almost do that on purpose, since the hardware hides it)?

 

Or is it the lack of an EEPROM, or other things ?

 

Those are the main theories I've come up with. The EEPROM thing shouldn't be a problem since Atari told developers they must use the Atari code to access the EEPROM. The Atari code fails gracefully if no EEPROM is there. Still, it's possible some developer didn't handle this correctly...

 

Another one is that any writes to ROM space will cause huge problems. It's easy for me to imagine somebody storing debug information in Alpine RAM and then just leaving that code in -- it would be harmless on a cart, but break the Skunkboard. (BTW, developers, this is another way to make sure your code won't run on Skunkboard. )

 

I honestly don't know how well 3rd party games work. A few betas have been publicly released and people are reporting that those are working. So compatibility might be exceptionally good. That's not really what I was designing for though.

 

- KS

[Atari_Owl]

Another one is that any writes to ROM space will cause huge problems. It's easy for me to imagine somebody storing debug information in Alpine RAM and then just leaving that code in -- it would be harmless on a cart, but break the Skunkboard. (BTW, developers, this is another way to make sure your code won't run on Skunkboard. )

 

- KS

 

OK this sounds scarey

 

Do you LITERALLY mean that it will damage the functioning of the board - or just that it will only affect that particular application and that once it has been reset everything will be ok again?

 

If its that one rogue write to the skunk can damage it - then whoah thtas a fairly major fault i'd say.

Calrification would be much appreciated

[Zerosquare]

I'll let ksunk answer, but I seriously doubt it would cause any permanent harm. At worst you can make the flash chips stop returning normal data, but it will go away with a reset.

 

(though I see a way you could cause permanent damage to the board, but it's not something going to happen by mistake ; it would have to be deliberate).

[kskunk]

I'll let ksunk answer, but I seriously doubt it would cause any permanent harm. At worst you can make the flash chips stop returning normal data, but it will go away with a reset.

 

Doh, yeah, I just meant it would mess things up until you power cycled, not permanently.

 

(though I see a way you could cause permanent damage to the board, but it's not something going to happen by mistake ; it would have to be deliberate).

 

I think this was fixed. Tursi's recent BIOS update protected sensitive parts of the Skunkboard on boot up. So I think users are safe from malicious Jaguar code. Feel free to PM me if I'm wrong!

 

It's still possible to change the BIOS if you can coerce someone to install a hacked JCP. But even then I don't think you can ever cause permanent damage because there is a bootloader ROM (non-flashable) that always executes on the built-in MCU. Thus, using JCP you can always recover all flashable parts of the board. This is actually how blank boards are programmed at "the factory" (Tursi's bedroom).

 

This thread is probably way off topic by now.

 

- KS