philipj
-
Posts
979 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by philipj
-
-
On 10/29/2021 at 12:38 PM, Atariman said:
Not sure how excited software folks would get about that, but it seems like that would be awfully nice to be able to have everything in ROM transferred to RAM, decompression be damned. At this point I guess the biggest benefit would be for future homebrew CD titles? Anyway, just one of the things I've been chewing on for the last few days.
Compression seemed to have the way of the world during the Jaguar's heyday and probably for good reason... Back in my music making days compression was how I packed a lot of stuff to fit on diskettes that I should've never been able to save otherwise. It would be nice, however, to add ram similar to how the N64 was able to do so using ram modules... You still have the "cartridge port" and the back "extension port" on the Atari Jaguar where the DSP have access to both ports... Not very sure if the GPU would have access to the back port in the same way the DSP does; the only thing GPU seem to have access to back there is the video/display chip that's so famously mentioned in the old "Atari Docs". As far as schematics goes, it's still a bit foreign to me; I haven't looked at the Jag schematics in ages; all in all it would be very neat to put a ram module through the back "extension port" for (at least) the DSP to have access; Not sure if it would be 64-bit access, but at least that's one way to add extra memory.
-
10 hours ago, Stephen said:
Of course - just don't use the 68000 and run GPU in main
8 hours ago, JagChris said:I believe this also hurt the Jag. Atari was still putting out arcade style games. 2-3 different screens etc. Damn near ten years after the success of Mario World, Castlevania etc.
The only thing the Jag got like that was Rayman. And it wasn't their doing.
It's funny the 7800 is mentioned... the "Maria" graphics chip on the 7800 is able to read display list supper fast until the main processor slows things down especially when it's accessing the "Tia" sound chip... It was always my assumption that similar principles apply on the Jaguar when the Motorola 68K accesses the BUS slowing the other processors down when in use "Hogging the BUS".
-
On 7/27/2021 at 11:50 AM, zzip said:
I found the Jaguar on clearance. At $49, it was worth a look. Another $49 for the CD unit. But this was also at the time I was getting into PC.
I had a few fun games for the Jag, some mediocre ones. The biggest problem I had was space. I was engaged but not married yet, not living on my own yet. The Jaguar was in the way. So I started seeing which Jaguar games I could get on PC and sold the Jaguar.
Atari told us to "Do the Math". Well I did the math and I could not make it add up to 64-bit, and I was in a Computer Science program learning about about system architectures at the time! I could make a more convincing argument that the ST and other 68000-based computers were actually 32-bit than I could for the Jag being 64-bit.
In general, measuring computing power in bits is snake oil, it doesn't mean much because different system components use different bit-widths.
Atari was arguing the bus width made it 64-bit, but for everything else we measure it based on the CPU. There's no standard on this.
Well... It had a 64bit programmable Blitter; not neccessarily a full fledged processor in the truest since, but can be controlled by any of the other 32bit processors... According to Atari, because of the Blitter being 64bit sitting on a 64bit BUS, "The Jaguar is 64bits when it needs to be and 32bits when it needs to be" with the "Motorola 68000" to give the programmer a "Warm and fuzzy feeling..." for those who are familiar with just programming with the M68K... One could just use the Motorola and the Object processor to just make 2D games thus it would directly compete with the SNES and Genesis that way.
-
On 7/7/2021 at 3:41 PM, Clint Thompson said:
Outside curiosity, not sure why anyone would want to bother even attempting to use such an archaic system for Jaguar 3D today though I see your point that at the time in the 90s, it might have been an interesting idea. An idea Atari would have never even considered due to pricing alone.
Well I'm thinking more exclusively for Jaguar 3D development more than anything else... I think it would merit some effort using the Jag for that purpose. I think Atari had a missed opportunity with the Jaguar and ST... Certainly with the lower 520ST computers, I think interfacing the ST with a Jag for commercial use back during the system's hey day would've been nice.
13 hours ago, Stephen Moss said:I like Gmax, a free cutdown equivalent of an older version of 3DS max but as I recall I have to use the Starfleet Command exporter (3DS exportation disabled when made free) and pass that through MilkShape to create the 3DS files. You could use MilkShape directly, which at about 30 euros is not expensive but it has more of a freehand drawing interface and I find the numerical entry option available in Gmax easier (probably due to prior experience with mechanical CAD software and lack of drawing skills).
Man it's been years since I used "GMAX" or 3D Studio... I remember "MilkShape... It was some kind of 3D modeller for low polygon 3D objects that were used in games for the original XBOX and PS2; at least the older version was. That stuff brings back fond memories when I was at VC for CAD, but they also had a lot of computer animators and 3D modellers there using those big black "Alienware" computers. I was very fortunate enough to take up some 3D modelling although I never master texturemapping and I pass lighting class by the skin of my teeth... Still very fun times back then.
-
Here's something interesting I had in my "YouTube" archives... It was "SYMBOLICS" 3D software package that would later be used for the "Nintendo 64"... It was possibly used to make "Super Mario 64", which just completely turned the gaming world upside down at the time of its release... It would've been great if the Jaguar had something similar that could handle those kinds of graphics... Very cool stuff in my opinion; I'd love to see something like this on the "Atari Jaguar" for 3D game development.
-
On 6/24/2021 at 2:34 PM, Sauron said:
*yawn*
Well... Sigh... I've spent a lot of time thinking backwards and forwards about how the Jaguar works, but never really implemented any kind of game development... QBASIC was a language I ran into some years back on an old "IBM 486 PC" I had in the mid 90 I never really fully understood so QB64 seems to be a bit of a second chance at the language...? I have some history with the old language running the executable including that came with the package; can't really think of a better language to try and grasp the concept of making games and what it takes to make them well... I can't help but feel like it's all talk at this point, but that's where my head is right now I'll probably eventually get to the tools yall have made, but for now, I have too many other priorities in real life and family that seems to take a lot my attention these days... I'm just going to have to force myself at the compiler at some point.
On 6/26/2021 at 6:40 PM, Cyprian said:GPU has 32bit access to the main ram and in case of DSP and 68k it is 16bit.
Regarding Jumps from to the main ram, GPU can do them but there are some restrictions like proper alignment for the destination.
Yea I got a lot of old documentations on much of that... I know the DSP has a 16bit interface on it even though it's a 32bit processor... The GPU jumps from internal cache to main ram, I hear you have to be a bit lenient on the GPU accessing main unless wind up hammering it where you can literally fry an egg on the chip using a consistent loop or something to that affect. That's another experiment sitting on the back burnner for another time... I think it's important at this point in time I just focus on the game; also I got hard copies of this book that discusses making real time 3D on the Atari ST in "Assembly", which I've chosen to be my Assembly language trainer to help head me in the right direction... It doesn't matter if I use the 3D engine in the book or not, what matters is getting an understanding on 3D programming in Assembly Language; that's the ultimate goal.
-
3 hours ago, sirlynxalot said:
I tried out wipeout 64 on an emulator recently and was very pleasantly surprised how good of a game it was. Imo it looked and played better than the PS1 version of Wipeout 1.
I actually had the game in my N64 library before I sold it on ebay some years back... Was supper impressed with the game and the digital music coming from the sound chip... Kudos to the music composer.
-
3
-
-
On 6/22/2021 at 12:44 PM, agradeneu said:
I don't think its about "secret programming tricks" not known to Jag coders yet.
The game is a nice example of how production values, great artwork and design make an impressive gaming experience.
So even if you know how its done theoretically you still have practically 0% of the game done.
Yea that's true... Still I'd like to know how some things are done for future use... Was just looking at "Virtua Racing" was done on the "Sega Genesis" and it appears that both VR and "Starblade" shoot sprite pixels to the Geny graphics chip to be displayed very quickly... If there's a way to get the Jag to do fast 3D that's very natural to what the system was originally designed to do, then yes I'll always keep an open mind to those things. I consider it a little fun to brainstorm those things no matter how crazy the idea, but you're absolutely right I should just focus on game making instead of all of this other stuff.
-
1
-
-
On 6/22/2021 at 8:23 PM, Clint Thompson said:
...but the Jag's GPU is an absolute monster compared to the Genesis, even with the bugs. As it should be though, it's a 3-year gap just like the Jag is to the N64.
Yea but wouldn't the Motorola and DSP have better access to main ram...? I guess the GPU would have it as well, just can't make jumps from internal cache to main ram... If that's the case, then yea the GPU is probably the only chip I need to work with-with main ram being the slower memory to use in comparison to the GPU internal memory. I never really agreed with the notion of just cutting the 68K off completely for the other processor, but that's another issue entirely. That's one of the reasons I choose to learn QB64 so I can just focus on making games without the hardware restrictions and worry about that other stuff later...
-
11 hours ago, agradeneu said:
Looks impressive! The backgrounds are definitely prendered. But if you can shoot polygon objects (collisions), it means they are most likely real time rendered. Not a huge problem for a 12 Mhz Motorola CPU.
Yep... Same speed as the 68K on the Jag... I could've given too much thought on Namco pulled off the graphics on the Sega CD... with the screen resolution being smaller than the average FMV on "Starblade", it's quite possible that uncompressed sprites/stamps are being streamed directly to the Genesis video chip. The Sega CD has 700KB of memory set aside for storing CD data, which is a very considerable amount of memory to work with if used in the right way; Sega originally was going to use 1MB of memory, but instead ran with the 700KB to cut cost. The Sega CD seems like a great little well rounded system to study, draw inspiration, and pull ideas from without all of the bugs that the Jaguar has, but can use (learned concept) in similar fashion.
-
3 hours ago, agradeneu said:
I disagree the Sega CD was better used - it mostly was underused and had only a handful exclusives that used some of its extra capabilities like the hardware scaling. It also had some drawbacks like a slow single speed drive and very lousy FMV quality. It was also very expensive. Which might explain why it never got popular.
True that... Really FMV should've been more of an 80s thing with games like "Dragon's Lair" and such instead of coming out in the late 80s/early 90s like it did... It seem like some of those FMV companies were trying to make up for lost time and lost profits, but that's another story. "Starblade" for the Sega CD was rumored to have used both polygons and FMV on the to pull off 3D graphics; the game was made so well it was somewhat hard to tell which one was FMV or which one is real polygons. Personally I think the wireframe objects in the game are the real polys and the rest are some kind of FMV or some kind of streaming data from the CD... It's possible they could've used the Sega CD extra hardware to stream background polys while the Genesis render the wireframe stuff much like what "Silpheed" did; of course the background for that game was most likely all FMV with the Genesis rendering the playable 3D low-poly 3D spaceship objects in real-time including the bosses (except the final boss and one other boss).
-
1
-
-
The "Jaguar" is obviously more powerful than the "Sega CD", but there's one thing I admire about the Sega CD unit and that's the ASIC chip that allows for fast scaling and rotating sprites much like the Jag's "Object Processor"... Of course they work differently, but they both handle sprites in similar fashion with the OP being the more advanced processor.
-
Battlesphere was one of the only games that worked around the Jaguar's encryption... think that might have something to do with it not working correctly? Might not be the same deal with "BS Gold" where the encryption keys were available to the public around the release date of that game... Just a thought; I could be wrong.
-
VladVR was one of the few to tackle 3D on the Jaguar... Very admirable if you ask me... It's too bad the game never came along further. Despite the polygonal look, I think the game gets a pass for being a home-brew... As long as the game-play is good, I've played a lot of bad polygonal games that were very fun to play and thus got a pass on being so blocky. Too expect too much more from the Jaguar would require pulling some tricks beyond the normal, which is what I'd like to do someday... Until then, you have to settle for what you can get out of the Jaguar system.
-
That's kind of unfortunate about that... The demo VladVR was not too shabby in my opinion... One thing about all of 3D stuff on the Jaguar; the more I look into what the Jag can actually do with 3D versus what I'd like to see it do, the more I'm starting to look closer at more of a 2D pseudo 3D rout in classic form that looks more appealing with faster gameplay like "Super Burnout" for the Jag using sprites. Maybe one day I'll find a way to trick the Jag system into producing fast 3D using 2D methods; that has always been my philosophy concerning the Atari Jaguar and that's its ability to produce fast pseudo 3D on the fly thus the art of faking 3D. A couple of games come to mind... "S.T.U.N. Runner" for the Atari Lynx and "Night Striker" for the Sega CD as great futuristic sci-phi racers using scaling sprite based graphics... I haven't personally played "TUBES" yet on the Jag, but it seems decent enough. I've always considered "STUN Runner" to be another version of "RoadBlaster" redone in 3D with a different vehicle mechanic.
-
On 3/9/2021 at 9:23 PM, Neko Koshaichi said:
Um... you forgot the N64. Also, you forgot a few handhelds that were in the 32 to 64 bit ranges.
Nintendo basically did what Sega did by going to an industry standard when they made the N64 back when Mario would make appearances on electronic bill boards in basketball game as a real-time CGI; they basically went the way of SGI (Silicon Graphics) type technology IMO... Same way with Sega when they created the "Virtual Racing" arcade game, however it seems like Sega was trying to do their own thing based on the "sprite based" arcade games that they were already doing with such games as "Out Run, Space Harier," and so-on thus the Saturn hardware seem to reflect some lessons from those proven technique. The good thing is that the "Atari Jaguar" seems to be right on the heels of the kind of graphics Sega was producing with the "Object Processor" originally designed for the Panther... I can go on and on about that sort of thing so forgive me if it seems like I'm coming out of the blue. The only problem with the Atari Jaguar is the "Video RAM" or lack there of in comparison to systems like the "3DO, Sega 32X (which has less RAM then the Jaguar, but better access to more memory than the Jag), and the Sega Saturn" which has more than enough video memory to give the Playstation 1 a run for a short time.
-
Well... I was young when I got into collecting Jaguar stuff... When I sold my Jag collection on ebay I thought I was finish with the Jaguar, but I started kind of missing it a little so the first thing I did was I got a Jag from ebay along with a couple of skunkboards and decided I'm in for the long haul; would be a shame to put all my Jag knowledge to waist... But it would be even nicer to have some new fresh perspective from some a newer generation of Jaguar enthusiast... Someone out of the wood-works would probably want to see the system push to the limit at some point in time like I did once they find out how powerful the Jaguar really is... And how flawed and buggy the system is as well unfortunately. Anyone crazy enough to program the Jaguar find that they have to take the good with the bad just like the programmers before them.
-
1
-
-
4 hours ago, Zerosquare said:
You've spent years telling us again and again about your ambitious Jaguar projects and how advanced they would be (here's an example from less than a day ago).
Yet you have released absolutely nothing, not even an "Hello world" project.
Well... I'm still messing around with QB64... I remember a conversation I had some time back with someone telling me if I really want to learn to make games, start making them on the PC first before programming the Jaguar. Well I'm listening now thus I'm still watching online tutorials whenever they post things... I'm using QB64 as a prototyping tool for game concepts this way I can make what I want on the PC without the Jaguar's bottleneck. Better to have somethings in place before tackling the Jaguar hardware although I do have to say I still have the Atari ST "Realtime 3D Programming In Assembly For The Atari ST" book that I've been reading on and off... I did however run into this book called "The Revolutionary Guide To QBASIC" published in 1996 by four different authors that talks about making realtime 3D in old-school QBASIC, which is pretty astounding if you ask me... There was even articles on a 3D engine in QBASIC that supported texture-mapping on a platformer game where they had a frog hopping around a mapped 3D world all written in QBASIC... Some engines supported gouraud shading but were only seen in demos. They seem to have been a tight little community for QBASIC back in the day that lasted until early 2000s when DOS was becoming obsolete; they made games, demos, push boundaries with QB until it got old and people went their separate ways. Today QB64 the newer people in the community has really been trying to push people into making games because the world has seemingly moved on with just a few games made using QB64... I Didn't mean to ramble on like that, but that's the current state of affairs with me right now... Don't want to throw this topic off track.
So back to the topic...
-
1
-
-
7 hours ago, Clint Thompson said:
4 channels didn't stop Tempest 2000 from being (arguably?) the best Jaguar gaming soundtrack ever though and I assure you, less is more for the Jag, the DSP had almost no real synth sound capabilities which is why Trevor McFur came out sounding like a dying robot, right?
It would take literally all of 30 seconds to take a MOD and throw it into rB+, having an actual Jag playing this MOD and probably a few weeks to make a single level SF-clone if someone really wanted to mash one up.
True that man... That Tempest mod track demonstrated a lot of how you can make the most of the four channels of sound... That whole mod tracking scene really did push boundaries almost beyond what a professional recording studio could produce and people are still producing four channel music today on their 16bit computers.
6 hours ago, Zerosquare said:Don't waste your time. philipj is that friend that goes on and on about how he's gonna be a rock star when he grows up. But you've never heard him playing anything, because he always has an excuse: his amp is broken, or he hurt his hand while playing tennis, or his guitar is out of tune, or...
Dude...! WTF are you talking about??? Once again you assume things about me that you know nothing about... I rarely post stuff over here that much and already you're on that BS without any reasonable purpose other than to get people out of character... But carry on Zero, your rep for attacking people with no real reason has proceeded AA with a flood of Jag fans lighting the forum up waiting to meet the great "Zerosquare". I never claimed to be a rock star, I'm just enthusiastic about what I talk about, but don't confuse enthusiasm with being arrogant and egotistical...
-
I looked at "Time Sharing" at one point in time to address the bus issue... If I was to make a game engine for the Atari Jaguar, it would probably be centered around a "graphics and sound buffer" using a "non parallel" way of processing everything where each CPU would take turn using the main bus similar to old-school "Time Sharing". It's a bit crude in theory, but seem to hold some benefits like allowing each processor to have full access to all of the systems resources for more potent processing potentials, but that's just a theoretical remedy I came up with till I can get a better understanding of the Jaguar. It would be all about maintaining the graphic and sound buffers which would probably mean the use of a "double or triple buffer" situation to ensure smooth data flow for fast action playability... At least that's my game plan; I haven't tried it yet so I wouldn't advise others to do so (do at your own risk), but that's where my head has been for a while now. I know most would rather shoot for that fast on the fly real-time action, which is usually a good policy especially for real-time 3D stuff and I'm not knocking it, but given the bottleneck troubles with the "main bus", I would try my hand with the "Time Sharing" thing...
Now back to the topic. lol
-
3
-
-
I gotta try my hand with a mod tracker... Definitely on my to-do list. My only issue is the 4 channels to work with; I'd like to do more with the DSP's synth capabilities using more than 4 measly channels... Other than that, the track sounds great dude, I'd love to see SF on the Jaguar.
-
1
-
-
I'm interested in getting a couple of skunks... Can't wait for the release.
-
The first time I saw "Cybermorph" on the Atari Jaguar was in 93 or 94 when it was displayed at a "Sams Club" store... At that time I thought the game looked pretty impressive for that time period. It certainly looked better than "Starfox" for the SNES.
-
1
-
-
10 hours ago, jeremiahjt said:
As somebody who planned on buying an XM when it was finished but did not keep up with it closely, what is the status of the XM?
The XM was Curt's pet project wasn't it...? Very sad... I really was looking forward to the module being released at some point in time. It would probably be wishful thinking for the module to be released "as-is" in its current state. Very sad state of affairs indeed if the project has been let go at this point; it wouldn't be too surprising, but it would be a little sad. If they do release the XM, I think it should be labeled the "XM Legacy Module or XMLM" (or something meaningful like that) in honor of Curt Vendel himself, but that's probably more wishful thinking. ?
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
"Practical" Jaguar Hardware Upgrades
in Atari Jaguar
Posted
Never the less... No need in throwing a good idea to waste... 12-bits is better than nothing at all, or you can just continue to use the 2MB of RAM that's already in there... Beggar's can't be choosers unless there's another way; probably the best way is to add memory is on a cartridge, which is the most obvious choice... Just putting some options out there... That is all.
Oh one more thing, can the "Jaguar Gamedrive" flash/write to SD such as for saving for high score...? If so, the flash drive can serve as a type of virtual memory of some type especially if it's really fast or make a custom cartridge that uses fast flash memory to serve as a fast ram system.