Cyrano Jones

Cyrano - are you sure it's the lack of an eeprom that breaks Raiden? All official carts are supposed to be able to tolerate the failure of the eeprom. I do seem to remember some discussion of Raiden having issues but I never actually had time to investigate it in depth. If you did some research to prove it I might be able to use your research to look at the issue.

I'm pretty sure it is, I was going to fix it myself but it's in a packed file in the ROM and I lost the will to live while looking at it

First, it's the bickering in general that annoys me, I'm not accusing people of flaming the skunkboard (although the jab about EEPROMs, whichever thread that was in, was annoying. I'm not aware of any title that fails to run for lack of EEPROM so that's not exactly a compatibility issue).

No barb, or negativity intented. I love my skunk. You *know* that.

BTW - Raiden fails (I believe, after a brief bit of debugging) due to the no EEPROM, so there is at least one. Not an issue, I've got 2 carts of it

[Edited for spelling]

Anyway, any chance you guys can call off the hounds?

If you'd like me to stop saying how much I love my Skunk for development, I'll be happy to oblige

DSP

Utilisé le DSP uniquement pour la musique est peut être un gâchis monstrueux. Je peux me tromper, mais certains jeux ont des musiques très discrètes, inutile d'utiliser toute la puissance du DSP pour le son.

page 4 : It may also be used for general processing tasks. Cette courte phrase en anglais est très claire : le DSP est le véritable cerveau de la Jaguar ! Et avec ses 8 Ko interne, c'est la fête au village. Le manuel a été construit un peu à l'envers.

Err, no. The DSP is crippled by it's 16-bit access to RAM. DSP<>RAM use saturates the bus killing the bandwitch for the other processors.

Hi

I had to google translate that from French to english, but it would appear you are after a game engine?

Check out the specs of our P1 sh'm'up engine here: http://dbug.kicks-ass.net/reboot/web/p1-page/tech.html

Our engine is complete, but we will not be using it to finish our game off. If you feel it can be adapted to this then please, by all means, send me a PM if you'd like to talk more ;-)

Bare minimum Jagtopia requires just over 2k - including the BIOS

I'd be more than happy to donate the code to this project if it helps to stop the sale of crazy overpriced CD Bypass carts on ebay and other sites.

The "BJL emulation" part is already planned. Check the FAQ for details

 

I thought about the CD-bypass feature too ; I'm not sure if we'll have enough space to include it (we only have a few kilobytes for the code), but if we can we'll do so

Chat on IRC

But if developers really want this feature, we could implement it.

Not something we'd ask for. We use Skunkboard for development, this will be for distribution. As you say, different end goals, different designs

Since all original games had to use Atari's eeprom code, would it be possible to write a tool that scans a rom, finds the eeprom code (if it's always the same source it should compile to the same binary) and replaces it with a compatible one for the new chip?

 

Or just make the general commercial release use the 128b eeprom, and have the 2k one available for developers doing bulk releases.

Most binaries in original carts are compressed, so this won't work for all. I'd have to say, if possible, make two versions. If thats not possible, just make the 2k version. Who wants to flash Checkered Flag anyway?

Whooohoooo! This is fantastic news! No more CDs!!

Must be a problem with the windows builds then, 1.7 and GUI 2.0 versions still making junk files, but the one you posted above was good.

Try this one... it converts as garbage here

(I know my code is correct, converting with zeros prg works)

NEBULA.bmp

You are quite correct, they're 320x200 (my mistake - I changed the format in my app after posting) - however the files are still junked :/

I tried all 4 in my app and they all looked like random data...

however your header in the .s says 320x200

the image i uploaded was 340x255.... so that might explain that

Subsidiary question: how to view CRY15/RGB15 picture on a Jag?

I naively thought it was just needed to add VARMOD when setting VMODE, but it does not seem to work as I expect...

Put the jag in 16bit CRY and set VARMOD. Works fine

Seb, I wouldnt worry about the colours being wrong - the output files are full of random pixels and don't wrap at the correct end of line positions. The pixels it does get in the right place are all the correct colour.

Whatever you want to do - I'd say try and make your "level" last <3 minutes tho, so it can be completed (or failed) and move onto the next screen.

As long as its a binary, and we can pass a few parameters (like level!) to it so we can loop them and make it more and more challenging, I don't care if it's written in PILOT!

I'm up for suggestions for how to set this up best for everyone - *if* there's enough interest.

As I said, CRY15 is perfect - CRY16 is producing junk files.

Just tried Zeros convertors and they work great THANKS!

When you say "always", does it really mean always or is it only for CRY 16 bits?

As said above, the problems are only in CRY16 mode - other modes produce valid files.

Is the in game music really mandatory ?

Of course not. It'll be our (Jagware) game, we can do what we want! POULPE POWER!!!!

C'mon - who's up for this?

Had an idea this morning to involve all the jagware teams.... or anyone else that might be interested.

How about we create a set a graphics (a few sprites, font, etc) and hand them to the teams and get each team to make a single screen game using them (whatever they want or imagine!)

We then take all the screens and bolt it together into a multi level game. Could be fun!

We'd obviously need some "rules" like:

1) You must use the graphics provided

2) You can add extra graphics if required but not for the "main game elements"

3) Your binary must fit inside say 1.5mb of RAM and pack to less than 512k

We could keep the same music playing for all the screens.

What do you think?

Reboot are back at work coding as well ;-)

It's definatly going to be a good year.

Ok, I'll investigate that, maybe at the AC next week-end

Further information...

It's processing the input file correctly - because outputting 15 bit CRY makes a valid file. However it is definatly screwing up the regular 16 bit CRY output - also had it with several other files today.

Tried importing them as JPG, GIF, etc - same result in the output. Exported as 15bit - worked ok (but obviously useless for lighting efects)

Also, neither your or zerosquare's convertors handle RGB 0,0,0 (black) correctly (for transparecny) - yours outputs $0001, and Zero's output's $something01 (can't remember) - a search and replace with $0000 fixes this but it's a bit of a pain.

Further note - *both* your convertors *always* get the first word in the file wrong (pixel 0,0).

eg, give it a pure black bitmap, and the entire file will contain a single repeating word, with the first word +1 intensity.

Hope this helps.

Hi,

Just tried the converter on the attached BMP, and it converted incorrectly with blue stripes all over the image. Zerosquare converted it correctly for me via his app - just passing the info along

space.bmp

Thanks

There's a slight problem with 3 of the unlock codes on the released version. We'll be fixing those up and hopefully adding a few more features and will be releasing 1.1 to the net shortly (a few days).

1.1 will also be the retail/Collectors Edition.