Jump to content
Jagware

Starcat

Members
  • Content count

    88
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Starcat

  • Rank
    Great giana sister
  • Birthday 06/24/1985

Contact Methods

  • Website URL
    http://www.larshannig.com
  • ICQ
    82373757

Profile Information

  • Gender
    Male
  • Location
    Germany
  • Interests
    Game development, reading, writing, music, movies, playing video games.

Previous Fields

  • Skills - Compétences
    Concept Development, Game Design, Writing Concept Art, 3D Modelling, Rendering, Animation, 2D Graphics Programming: 68k, GPU/DSP Assembler, C, C++
  1. Instability in big binaries

    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.
  2. Instability in big binaries

    Of course, that makes sense. :-) It has to store the adresses afterall.
  3. Instability in big binaries

    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
  4. Instability in big binaries

    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
  5. Getting back into Jag dev

    Thanks!
  6. Getting back into Jag dev

    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.
  7. Getting back into Jag dev

    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
  8. BLACKOUT! Released now

    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)
  9. BLACKOUT! Released now

    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.
  10. Cheap cartridges for developers and gamers

    @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.
  11. Cheap cartridges for developers and gamers

    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.
  12. Cheap cartridges for developers and gamers

    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.
  13. Cheap cartridges for developers and gamers

    @ Zerosquare: There is one thing I may have misunderstood in the first post, when you were refering to pricing. Did you mean to say for 10 boards, each one would costs ~15 Euro? (+ shell, manufacturing etc?)
  14. Cheap cartridges for developers and gamers

    @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.
  15. Cheap cartridges for developers and gamers

    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)
×