Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Gorf

  1. For a small project one could probably get away with the simplest single input makefile and just "include" or "incbin" the relevent sub components and get on with learning the machine? That might make it more palatable.


    IMHO, that's not a bad way to go. A while back, actually quite a while back now, I had a similar experience with OpenGL and C on SGI. Used to jam on those computers professionally and I really liked them. One day, I was reading something about OpenGL, and stumbled on a really great Oreilly demo code. It had just the basics, keyboard, mouse, and a graphics loop. I think it drew a cube, or something simple. Basically, it was turn on the lights, setup the polys, do your transforms, and such... The code filled maybe two screens.


    It was enough to build on, so I did. At first, I did my own shapes, then I built up an array of polygons with cool colors and had a few hundred of them spinning and moving on the screen. It took a bit to get each thing done. File I/O, graphics, etc... and ended up producing a nice little STL file viewer that was actually useful. On a modern machine, it can render maybe half a million polys no sweat, and do so at a reasonable frame rate.


    Viewstl is the project name, and it's still out there, if you want to see the rank amateur I am :)


    My point is that took maybe a few months to get done, and it was fun, and it was possible for somebody willing to think it through a little. I know there isn't something cool like OGL on the Jag, but maybe there could be.


    That spinning cube, or maybe sticking with 2D, sprites moving and bouncing maybe with the game controller might just get people cooking. The key is to take as many of the barriers away, leaving people with something they can just chip away on, getting stuff done.



    This was done years ago with my getting started lessons of JSII. They were available to everyone at one point. JagChris

    is the only one that ever bothered to use them. They were as simple and self explanitory as you could get. I even had

    idiots complaining about how 'pedantic' they were!!!! Imagine that!! Clearly I was'nt pedantic enough.

  2. {snip long response comparing jag scene to other platforms, decided it wasn't worth it}


    bottom line: there's a difference between "hand holding" and a helping hand. If the goal is more Jag devs, there has to be an easier run at it. We all don't have time to tear apart code running on multiple processors to figure out how to use the machine, or spend days/weeks/months prodding the hardware to see what does work well, especially if there are experts that already know this stuff.


    The tutorials, discussion of techniques (like code in main) and libraries are absolutely necessary to expanding the dev scene. I thank you for those resources! If more devs shared their favorite Jag techniques and libraries as you are, the scene would grow tremendously.


    You are right it's not worth it...it's just plain foolish to compare this machine with any before it. It's a completely

    different playing field. The only thing Jag has in common with the consoles before it is they are consoles. After that

    it's an entirely different way of thinking due to the multiprocessor nature of the Jag.


    On others helping:


    They have! What more else do you want? What is not out there that you need to start a game? Just name one thing!!!


    You can't because all you need to write a game is readily availbe on this site and many other sites. TRust me,

    People want it handed to them....they helping hand has been give 100 fold over and over. Ther eis no more excuses

    and it's clear to me those that complain the loudest are the ones who bother the least.



    You keep complaining about this but you have yet to site one example of it.

  3. I see you've had no answer there poobah. ;) Not suprised :D ..... however.....


    I've blown my Jag up a million times crashing the system running code with trial and error. There is absolutely no

    reason why anyone else can't do that now. Especialy now that you have 100 times the info and examples I ever had when

    I started to code this machine > 15 years ago. It sounds like laziness and a true lack of will to me. It sounds also

    as if everyone wants to wait around until someone does it for them. Grab the tools and use the examples and go for it.

    This is the only real hope you have. Of course you can ask questions which I will always be happy to answer but I

    dont even see any one(besides JagCris and one or two others) actually even bothering to do that. All I see is a bunch

    of wannabees complaining about stuff that is not even true. Now stop being wannabees and be doers. I am, and you can to.


  4. Imagine if a C++ coder on any other platform decided they were deliberately not going to use stdio, or were going to throw out the whole STL and re-implement basic functions themselves just for the hell of it. They'd be laughed at, whereas here things seem the other way round.


    Not in the embedded world. If I use printf on some of the micros I've worked with there is no space in the ROM for the application :lol:.

    Absolutely true, but the Jag is a little higher up the food chain. :cool:


    I'd love a nice set of GPU OP routines. Too much reinventing of the wheel on the Jag.


    Abstract away some of the arcane details and people will start writing more stuff. Although some of us can write assembly code, most people today have never seen it, and would be lost without object::method(foo). If you want a wider base of programmers, you need to step back a bit from the hardware. I think there's a big space between living solely on the 68K and Gorf-level knowledge of the RISCs. Some tools and libraries to exploit that space will bring more developers.



    I'd have written new tools if that was my bag....that is a science in its own right. I am a logic coder mostly.

    I make the games think and act. I could probably do those other things but then I'd really never get anything

    done trying to do it all....that is why teamwork helps. I have a team...they are slow...very slow but a team none

    the less.


    If you want these things so bad...write them...we had to from scratch and reading docs. Im no mega guru here.

    I read, I write and I trial and error.

  5. 0) Tools, Tools, Tools... The Jag is crying for a decent dev tool set, sadly the odds of that happening are close to nil


    1) Distribution Medium... As mentioned above, too few JagCDs, and carts are expensive. Need a simple flash board.


    2) Community... Too secretive and adversarial. This seems to be getting a little better


    3) Techniques... Follows on from 2, but but much of "how to accomplish X" hasn't been disclosed, and isn't readily discovered. On other platforms, people share new discoveries and techniques, not so much on Jag. (Tutorials on JS2 are a start, and the main code discussion has been very informative)


    4) See 0!



    Who's being secretive? I think that is yours and everyone elses inagimation.

    Those Lessons on JSII are mine and so is the mani RAM GPU execution, so who

    is this being secretive? Please....do tell us what is this 'X' and who has

    not disclosed it? Should I just upload every piece of source code I have

    written or ever write? not that it would matter since no one has done one

    damn thing with the tons of source readily available to the masses.



    I call shenanigans on you and anyone else who tries/cries this nonsense!


    I am working on LIBS that WILL greatly benifit those who have the balls to

    use them...unfortunately no one wants to do any work unless you hold their

    hands every step of the way.


    The only one you have any hope for being correct on is 0. The rest is

    you repeating the typical sour grapes of those that feel we write code

    for thier pleasure. I really dont see what anyone else can expect that

    has not already been handed to them. There are TONS of resource for any

    one with a pair to get rolling on coding the JAguar. No on is going to

    write it for you.


    Now please....prove me wrong....good luck on that.

  6. Nothing is 'stopping' me from coding the Jaguar. I however choose not to release the games I have planned without

    a worthy renderer. The work is still being done. In the mean time I am doing a few mini games but they too take

    time and I have very litle of that. Plus I am NOT depending on someone elses code to write them. I am writting

    my own sprite engines and AI engines and what have you engines. All of which take time which is limited.

  7. What exactly makes a game "Jag worthy", and who is the judge of that?


    How about one that uses the entire system and the way recommended by Atari...which BTW was to boot with the 68k then lay off it?

    Not that everything Atari says is gospel...after all if we listened to them on everything, I would have never bothered to try to

    jump around in main RAM with the GPU.


    Also we're ALL using pre-made libs. Everyone has to use the Atari supplied startup code if they have

    any hope of getting things to display right


    No, WE are not ALL using pre-made libs. The start up code is NOT a lib. It's is a necessary part to get

    the system up and running and is better equated to a bios or part of an OS. It is also recommended by Atari. There is

    only one useful way to boot the Jag system so re-writing the start-up is re-inventing the wheel. Using 68k based libs

    when there is so many more efficient ways to do things on the Jag is another. Start-up code != to a lib.


    Given how many basic functions of the Jag are left as exercises for the developers (OP list maintenance for example), I think a nice generic set of library routines can only be a Good Thingtm.


    Which will ONLY get you a nice 'generic' set of games. Scott used Sinister...as a guide....and from it wrote our player

    from the ground up entirely in DSP assembler. Using a lib/source as a guide is one thing, even I agree with this. Depending on it

    is another and will limit you and the type of games you can come up with on the Jaguar (or any system for that matter.)


    I agree, anyone could code simple games (and simple games can be great fun), but not many people are doing so. Why not?


    Some of us are. But we are NOT relying on other peoples libraries. Plus I am not against anyone using a library if it

    offers a useful function. IT just seems too many people depend on them and do very little to explore a system on their own.

    Simple games are the best games....but why can't you go beyond the simple use of the 68k and the OPL as a simple sprite engine?

    Most of the free libs are based around the 68k and would be better suited toward coding a Genny or an ST. Show me a lib that

    makes use of the real power of the Jaguar system,then you'll impress me....yes I AM working on such a lib....when I get time

    it will be finished and it will offer a much better and more efficient use of the system.


    How do you know nobody has made use of them. What counts as "use" in your opinion? Maybe nobody has released a clone of them, but that doesn't mean they haven't been useful.


    Show me one example. Clone or otherwise. Outside of doom which a few people have actually had use of, it

    aint happening.


    Years ago I learnt how BSP trees work by reading the Doom source. I'd read maybe a dozen tutorials before and none of them made any sense, until I saw the code and walked through it in my head. Different things are useful to different people.


    I think you mean that is how you 'learned' how BSP trees work. That is very different than just using the code and never

    actually learning anything about the actual functionality of a BSP system. VERY different than cloning code.


    Again learning something by using something else as a guide is one thing and that is how everyone learns anything.

    Being a copy cat is hardly impressive. For novices, I have no problem with libs. For people that have claimed they

    have coded for years, its almost inexcusable.


    Even I have used the 3D renderer supplied by Atari, but even then we greatly optimized it(and it still sucks

    performance wise.) This is why I am working on a ground up renderer. It is also why I have not release any of

    my 3D apps. I want them to be optimal and effecient to the best of the Jaguar's ability. Im in no rush to

    release anything if it means releasing garbage or for he sake of bragging rights or in hopes of amking others

    look like they are doing nothing like some around have done.

    • Like 2

  8. What bugs? What blow ups? Did you report them?




    They should be fixed by now if you have as he's been Johnny on the spot in the past for tackling bugs. Have you checked the website for updates? Do you have the latest version?


    No they have not been fixed. In fact the latest bugs were reported in the latest versions.


    I think he said he wasn't getting bug reports and people showed little interest in SMAC and SLN. This community is so dead we're gonna lose our only tool man after years of everyone bitching about wanting new updated tools.


    I've been telling our tool man about these bugs for a year now. Our tol man like most of us has real lofe issues to deal with

    so Im not blaming him, nor have I forgotten about his hard work. Most of my games are in too far deep to bother converting

    over to tools that are still not working enough to deal with what I am doing. I want those tools for future endevors. Like

    the game that was formerly Gorf 3D. If he indeed fixes those bugs and I am sure he will when he gets a chance, I will consider

    moving my current code to them, but since we are getting serious blow ups in some circumstances it just not worth trying to

    move them over to SMAC/SLN.


    Maybe you or AO will see fit sometime to do a small demo using SMAC macros like an Amiga bouncing ball demo just to put SMAC through its paces.


    I dont have the time...I have more than enough on my plate. Plua you are talking about doing this from scratch as these are

    as far as I can tell all assembly and 6502/68000 are not compatible with J-RISC instruction wise.

  9. You did not need a Skunk board to develope. There are many cheap and simple ways. The fact is no one is writting any

    Jag worthy games from the ground up. They are porting rehashes of ST games, and in some cases using pre made libs.

    All fine and dandy but where's the beef? I too have a few simple games Im working on but Im looking to push the Jaguar

    once I get my renderer finished. These things take time. Anyone can write simple games. Using the Jaguar's real power

    in the GPU/DSP , Blitter and OPL need a lot of hard work and laborious debugging. The sources for several games were

    released over a year ago now and not one person even made use of those. The Jaguar is not a cakewalk to code for if you

    want to do something that truly takes advantage of the ability of the machine. They are being worked on by some of us

    but we have lives and jobs and family to deal with. They will come and you will see them, Lord willing.

    • Like 1

  10. Anyone want to tackle a little lesson on this?


    By sprites you can mean one of three things. OPL objects as sprites, Blitted Sprites or

    straight up software sprites. I recommend using the OPL. However this is not a 'little'

    lesson as you do need to understand how the OPL and it's list(s) operate.


    I think you should start out with a software based sprite, then use the blitter to replace the

    software draw, then use the OPL. Regardless, you will still need to know what to do with the OPL

    before you can use any of these methods on the Jaguar as it is the OPL that allows you to put

    anything on the screen to begin with. The OPL is indeed the backbone of the Jaguar's video system

    and you can't display anything without it...unless you want to write with really tight timing and

    precision directly to the line buffers...but you still need to set up the OPL minutely even for this.


    You have the 6 lessons I posted. Take a look at those as you will see how the OPL is dealing with

    the screen. If you want help. Let me know. I will show you how to add more objects to the list.


    I am working on a skeletal source for using the OPL as a sprite engine. It's got a ways to go but

    it uses the GPU to deal with the list where the lessons use the 68k and that setup is intended mainly

    for a 3D buffer and not exactly ideal for a 2D sprite based engine, although it will work for that if

    you want it to.

  11. Hello!



    For relative jumps (JR):


    Those jumps are calculated on the processor counter (PC) being already incremented,

    so what if a JR is the very last command in a page?


    Is it then a page-miss if the jump is backwards? (based on the PC)


    Or is it a page-miss if the jump is forwards? (based on the address where the JR is placed)



    Kind regards




    I avoid this but have tested this and it seems to be fine as long as the JR goes to a long aligned

    address outside the page. Since all instructions fall on some even numbered address you should not

    encounter any issue as long as you follow the rules. The bug is not effected because of the PC as far

    as I can tell. Also, according to Downix who has studied the nets, it is based on a lack of adequate

    power supplied to the MMU during main bus accesses. It causes a pipeline issue because outside of local

    the pipeline does not work correctly. This is why you need to clear the pipeline when jumping from

    main to local or local to main. Remember, the pipeline adheres to the 32 bit nature of the internal

    space of the RISC's. Outside of the RISC space its another ball game. I do not think you will encounter

    any issues if you just stick with the rules provided. Of course you are welcome to run your own tests to

    show us the error of our ways....just add any new rules you find to this thread if you do indeed find any

    such issues.



    • Like 1

  12. Probably something we need to consider in the plastics drawings. Perhaps add a millimeter or two of space

    to ensure these other games fit....and hopefully execute.

  13. You can get a couple of ez430 RF devices from Farnell (electronic parts supplier based in the UK) :-




    They each cost £13.43 (ex VAT) and run from AAA cells.


    You'd need to know MSP430 assembler or "C" for development.


    I kinda agree with ZeroSquare on this one....I never had an issue with wired controllers. But GB,

    what's a guy gotta do to convince you to do some coding for the Jaguar? ;)

  14. Perhaps some day people on the side lines will understand that no one owes them anything and they should be grateful

    for when anyone puts their hard work into a project. If you folks that are bitching and moaning about what you wish

    you had or had not are so upset about it, you can always learn how to do it yourself like we all had to and then you

    can do as you wish. Until then lay off. Let the developers do as they seem fit before you scare them all off due to

    completely uneccesary and beyond unreasonable complaining. You will know soon enough what the expmod will have. If it

    does not suit your happy place, either do not obtain one or come up with your own. It's easy to sit in your chair behind

    a monitor and fire off compliants but for once, all of you( and you know who you are) try to put yourself in our shoes.


    All these projects are hard enough to work on and we all would appreciate it if you did not make it harder for us with

    the whinning. If others woking on projects wish to share their info with you before the fact, that is their right and

    their perogative. Please give us the same respect. You might also do your self a favor and not expect anything because

    that will always be a sure fire way to being disappointed.





    • Like 1

  15. Hello Gorf!



    My pleasure Matthias...but I fear you might be the only one outside of a handful that ever even attempt to use

    the main code workaround. Lots of people like to talk the talk and bitch and moan that no one likes to share

    this and that, but I have found out that the reason for this is those people are usually not coders and are

    hoping some other coder makes use of it for their own greedy selfish desires, forgetting the hard work that

    goes into these projects.


    Even if it'll disappoint you, i am afraid it will take a while before i will start using the given RISC-Execution-In-Main-RAM-rules. I probably would try it out immediately, and i am a master of adding NOPs to code sequences, but the necessary adress-alignments (with differences for page/non-page jump) seem to be a too high hurdle for me.



    But could you or AtariOwl (or who else has the necessary experience) please add some info about the speed advantages or disadvantages of running RISC-code in main RAM to the sticky thread in the Programming section? Thanks in advance!



    Kind regards




    Main code ram execution can run almost as fast as in the local or not depending on the bus activity. In its worse case

    it is by far faster then the 68k. The idea is to run your AI out in main and do all your drawing in local in that order.

    If you use tight loops you will notice a serious drop inperfromance so it is recommended to unroll loops so that each

    iteration of a loop from begining to end has several instructions between them and the loop jump. If you abide by these

    quidelines you will increase your perfomance greatly over using the 68k by leaps and bounds.

  16. If want you extra controller ports, I think it's just better to use a Genesis multitap and have a few games that are programmed to use it.

    I found a tech document on the Sega Multitap, and it doesn't look like it would be possible for a 7800 program to interact with it. It needs a working SELECT line, and that pin in the 7800 is tied to +5v.

    Maybe the EA one is different, I didn't find info on it.



    Jaguar Team tap anyone? Two ports are plenty. get over it it peoples.

  17. AJ.....Im just going to say these few things..... I have done all the research, discussed this with Curt

    AT LENGHT and pretty much know what I am talking about. As for you, you are quite clueless concerning the



    Too expensive and costly are the same thing so enough with the symantics as if no one will notice.


    Doer? What have you ever done besides 'act' is if you know what you are talking about when clearly you do not.


    I have released games and do understand FPGA/VHDL and coding a variety of processors.


    Just so you understand tht this is the case.....


    Marty wrote:


    Guys, you're all arguing about stuff we've already pursued for years now and still have in the back burner. Nothing new to see in this thread, no new ideas, arguments, etc. If it's picked up by Atari any time soon, you can be sure we'll let all of you know.



    This is the very thing I already discussed with Curt AT LEGNTH.


    @ Marty.....trust me there is no argument. Just me correcting AJ who does not do his homework

    or does not bother to read your above words before posting me back.


    @ Wood_jl


    I hope the answer to this rather time wasting post of AJ's has educated you. We also understand the limited

    if any profits concering these kind of niche market products. When and if the time is right, if I have things

    my way you will see such a device in one form or another.

    • Like 1

  18. My whole point is simply the viability of such an all -console system and its cost. A Spartan 3E could

    do just about any classic system on up to the Jaguar. I know Mike J is working on ST VHDL as we speak.

    It's been a while since I have checked his progress but its certainly more than possible.

  19. And where are you expecting him to get the money from exactly? :ponder:



    Raise it. If he believes in it and it's as viable as he claims then it won't be hard, will it?


    Take it to Mr. Vendel and present it to Atari. Don't just talk.



    You seem to do alot more talking than I my friend. Two problems....Curt is way busy

    working on other things and Atari would not give a rats ass about it. I already HAVE

    thought about it. Problem is, you need someone capable of doing the VHDL code. Oh,

    that's right...it's already done. Code for just about every console from the 2600 on

    up is done already. Also, I HAVE talked it over with 'MR Vendel" as you put it already.

    To discuss that any further with you, I'd have to kill you. ;)


    Go look at the FPGA Arcade website.


    You said it would be too costly and that is just plain you shooting your lips off. Cost

    has little to do with it. FPGA chips especially ones big enough to handle it cost nothing.

    The code already exsists if you want to really know and it's just a matter of packaging and selling it.


    So, with all that said, I hear all the talk coming from you and nothing to prove me wrong

    or otherwise. Perhaps since you are such a hardware and VHDL expert, you can explain to

    every one how it's TOO costly and not market viable?


    That's what I thought! :roll:

    • Like 2
  • Create New...