Gorf

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.

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.

I see you've had no answer there poobah. Not suprised ..... 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. JUST DO IT!

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 . Absolutely true, but the Jag is a little higher up the food chain. 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.

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.

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.

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. 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. 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.) 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. Show me one example. Clone or otherwise. Outside of doom which a few people have actually had use of, it aint happening. 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.

Yes. No they have not been fixed. In fact the latest bugs were reported in the latest versions. 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. 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.

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.

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.

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.

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.

Time! Well... the lack of to be exact . Excuses, excuses.....( and quit stealing mine .)

Looks promising beoran. I'll have to check it out when I can find a moment. Thanks for your efforts.

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?

Not to sound like Sarah Palin or nothing but...."You betcha!"

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. Thanks, Gorf

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 Matthias 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.

I only intend to have one round of levels of 'Birds Of Prey' ready for the show.

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.

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 subject. 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: 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.

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.

the 7800 survived this long without four ports

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!

The 7800 is an expansion module for a 2600.