Gorf
-
Posts
4,585 -
Joined
-
Days Won
3
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Gorf
-
-
{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.
-
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!
-
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
.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.
-
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.
-
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.
-
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.
-
2
-
-
What bugs? What blow ups? Did you report them?
Yes.
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.
-
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.
-
1
-
-
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.
-
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
Matthias
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.
-
1
-
-
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.
-
But GB,
what's a guy gotta do to convince you to do some coding for the Jaguar?
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.
-
You can get a couple of ez430 RF devices from Farnell (electronic parts supplier based in the UK) :-
http://uk.farnell.com/texas-instruments/ez430-rf2500t/board-target-wireless-ez430-rf2500/dp/1740341
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?
-
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
-
1
-
-
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
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.
-
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.
-
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:
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.
-
1
-
-
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
-
And where are you expecting him to get the money from exactly?
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!
-
2
-
-
The 7800 is an expansion module for a 2600.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
What's stopping you programming the Jaguar?
in Atari Jaguar
Posted
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.