Starcat

So as it's probably an alignment problem, can you tell me some alignment ciritical things to look out for?

If I remember correctly the RISC processors need longword alignment of main ram locations to savely read from and write to.

The 68k probably even addresses to branch to and use word/longword operations on.

Then there is the alignment of the Object List which needs to be QPhrase aligned for scaled objects to work, right?

When I say things crash, what I mean is the display goes blank (to background color). So it may be that just the OP crashes in that case.

Of course, that makes sense. :-) It has to store the adresses afterall.

Some reorganizing of the data fixed it for now, but it's still strange.

It's running from RAM. Maybe it's an alignment problem, but I doubt it.

Do I remember correctly that a 68k instruction is a word in size?

TEXT: 82688 bytes

DATA: 680064 bytes

BSS: 0 bytes

Hi folks!

I'm having a strange problem. Once a binary reaches a certain size, my project gets instable and crashes.

I believe it may have something to do with graphics and code parts being too far apart in memory.

Sometimes I got things fixed by rearranging my data.

Have you ever noticed anything like that?

I'm currently using RLN, but have noticed similar problems with the original tools back in the day.

Cheers,

Lars

Thanks!

Just got it fixed already. :-)

Thanks to Linkovitch and Lawrence Staveley.

I wasn't aware that the OP List Link adresses that were created by the GPU routine were not relative and pointing at the wrong location.

Hey everybody!

I'm finally getting back into Jag dev again and ran into a problem with my old code.

The GPU creates the object list that is then copied each VBL. The OP only uses the copy.

However when the GPU doesn't build a new list, things get odd.

Only the first Object is displayed, even though the whole list is copied.

I'm not sure what the problem is.

I did a little test program. The GPU creates an object list with three bitmap objects (not to mention the branch and stop objects to keep things going.

The list is copied to the location from which the OP fetches its list. Things work fine.

After a while I put the 68k in an endless loop. The GPU doesn't build a new list anymore. The VBL catches on and copies the existing list as it did before.

However now only one bitmap is visible.

I'm confused. Maybe somebody who knows his object stuff can take a look at my code.

Here is the link: Object Test

That would be great! I'd really like to know what's wrong.

Cheers

Lars

i thought raiden had issues with pal as well?!?

 

Well, there's the regular version that looks very letterbox on PAL (the version I have - I paid a *lot* on import as soon as it came out ;-) ) Then there's an E-version that is full screen for PAL. That's just from memory. I think there's a few carts with E-versions like this.

Raiden was probably one of the Jag games I played most back in the day. I never noticed any problem with it. I'm not sure if I had the E version, though.

Good to hear that future Stormworks titles will support PAL/NTSC.

I'm looking forward to see what the future holds for the Jag. Of course that's true for all new games. (Including my own, hehe)

Congrats on this new release!

It's especially nice to see new cart based games, looks nice!

I agree with Orion, but then again it's good to see that the binary will be available for people to play.

However I wonder why 50/60 Hz compatibility wasn't added? Except for Dragon's Lair a 50/60 Hz switch wasn't really necessary on any Jaguar.

@Zerosquare: I just got an idea. You said, in a way the new cart works like the skunkboard. There has to be code to pass the encryption and later start the actual rom image on the cart, right?

Is a BJL Jag required to flash data to the cart, or could a function to upload code to the Jag's ram or the flash cart be added (when a certain button combo is pressed on boot up for example), so that you don't need a BJL Jag, but just the BJL cable?

I'm just thinking if it's not much trouble and doesn't add extra cost, it may be a cool feature.

That way any Jag could act as BJL Jag. Maybe even add a Jagtopia feature (if reboot agrees to this), while you're at it

Just an idea.

Yes, in reality the prices will be lower, because we will be manufacturing much more than 10 cartridges. The price I gave above is a maximum

 

We know it can add up to a lot of money in total. One solution is to ask for prepayment, or at least a money deposit, for preorders. That way you'll know how much persons are going to order, and you'll have some money from the start

That's true.

Still, it may be worth a thought (if you didn't already intend to do this), to collect orders from multiple developers at the beginning to see how the prices will be.

Maybe it could be discussed in an ordering forum thread or so, when the time is there.

Of course you are right, I could also ask for preorders and then only produce as many carts of a game, as were preordered.

Anyway, regarding the savegame eeprom, if you consider this, I'd vote for the idea of having "developers carts" with 2k serial eeprom so our games can make use of larger savegames.

Hmm, isn't there a way to get cheaper prices when ordering more parts at once, like doing a bigger runs? Maybe it would be possible to ask developers and collect orders to get lower prices?

I'm just saying this because as thrilling as these news are, even if I had a new release ready, it's really a lot of money a developer would have to put into production of a cartride run without knowing how much he'll sell.

While CD games are not as cool, not as relieable and you reach less people, but at least they are really low-cost and can be done on demand, so you don't loose as much money on a release.

@ Zerosquare: There is one thing I may have misunderstood in the first post, when you were refering to pricing.

for 10 boards, the PCB and parts alone add up to less than 15 € (approx $19)

Did you mean to say for 10 boards, each one would costs ~15 Euro? (+ shell, manufacturing etc?)

@Zerosquare: That's great news. I would really like the option of a 2k eeprom, as it would allow more complex savegames, even user levels for example, if a game supports it. You could take a look at Matthias' site at: http://www.mdgames.de/je2prombrowser.htm to see what is required to acces larger e2proms or if they are compatible.

Another question: The serial eprom to store savegames is the standard 128 bytes one, right? Are there any plans to add a higher capacity one?

I don't remember if it needs different code, but this was a topic discussed on the underground mailing list some years ago. Back then Matthias Domin also wrote a e2prom browser that supported higher capacities and few people modified their alpines with bigger savegame eproms.

I'm just thinking it might make sense. 128 bytes is not very much for more complex games.

Would it be possible to use a part of the flash memory to store savegame data, if a game doesn't require the whole 4MB? (of course in this case the cart can't be locked I guess)

This is so amazing!! I ALWAYS wanted to develop games for cart and I will definately consider it in the future.

I wanted an affordable solution to create carts ever since I started on the Jag. This really is a dream come true. Hats off to the whole team.

A few questions:

Is there a way to detect individual flash carts, like an individual serial on the skunkboard?

Are there any plans for bigger carts? (4MB is awesome already, but if there was a way to get more like 6 or more it would be even better.)

So did I get it right that there is no limited run.. If I decide I want to release a game in a few years, I could get these carts?

Thanks to fadest on Atariage, who already answered my question about "locking" carts after programming.

Also another thought, if you could find a way to get manuals and boxes printed, Jagware could become the new one-stop source to help developers create cart releases of their games. Well, I'm just very excited at the moment. hehe.

Regards, Lars.

Thank you very much!

Does it work for you now?

It's supposed to be ready. What browser are you using?

Hello everybody!

After several weeks of hard work, the new completely revised Eerievale Homepage is finally online!

A lot has changed around the project, as you can read in the blog section of the website. In many ways we took a new direction. To do justice to the progress, the website was redesigned and filled entirely with new content.

It will be bilingual, in English and German.

From now on there will also be regular updates, background information, progress reports and further special content.

Before I drift off or go into too much detail here, please head over to the new home of Eerievale and give it a look yourself.

http://www.eerievale.com

Regards, Lars.

Did the SNASM2 kit actually have their own assembler/linker? If so, can those also be used with the atari kit?

Would be really interesting to get my hands on them.

Do you have a SNASM2 kit? If so, how is it compared to the alpine?

I recently found out that cross products, the developers of the snasm2 kit actually developed the official dreamcast dev kit, too.

Thanks Cyrano!

The problem was my nmake.exe which was not the original provided by atari. Make doesn't work in dosbox for me, but your nmake file does.

This is really confusing. It's pointing to the right location and the make file is from 1994. So it HAS to run in dos, as nothing else was there at that time.

Dosbox just doesn't seem to like it for whatever reason.

Cyrano what version of dosbox are you using?

Cyrano, when I try to run Make or Nmake using dosbox, it says the program can not run in dos mode. Which is kind of weird.

No matter if I use a version of make from 94 or a current one.

How did you get make to work in dosbox?

I just tried it and I could compile it after a few changes. However the gcc doesn't support dos.

Which means using dosbox for linking and windows for compiling and at the same time keeping all library files in the project folder, which is kind of annoying at the moment.

I hope we find a better way to do it, maybe support for the .a file could be added to sln? No idea how much effort it would take though.

Also, keep in mind that dos only supports 8 symbols + 3 symbols extensions. in other words files like interrupt.o need to be renamed.

Thanks

There is no windows version, just the dos version that atari provided. I attached them to this message.

Other than that, there only is SMAC and SLN.

MAC.zip

ALN.zip