philipj

The 68020 would be better... The internal cache would've been a wonderful addition especially keeping the 68K off of the bus even for but a short time. At least if someone does an fpga copy of the Jaguar hardware they could possibly use a 68020 or higher model chip.

Ok... Here's a non related synth chip called the "DSP-G1" by a company called "DSP Synthesizers"... Just a small little perspective on the current state of affairs concerning modern day synth chips. I know the "Speakjet" had some potential, but didn't really specialize in music or didn't have anyone to exploit it's musical potential. It's good to see synth chips are still being made today; it would be cool to see them do something with the AMY specs.

They're always out of stock when I visit this sight... Is there anywhere else they sell these boards??? I'd like to get my hands on one.

Right... And the "GPU-to-main work around" requires full 64bit due to a bug with the multiplexer not getting enough current when making jumps, which means more cycles lost, but is still somewhat useful provided the access isn't in a tight loop less you wind up "Hammering the GPU". Makes for great limited use like AI and the such, but still very limited when it comes to graphics for texture mapping in a speedy manner. The GPU has a great ALU on it that's fast; it seems like procedural textures would be ideal considering the two 16bit multipliers running parallel, but I guess that ram issue is always going to slow things down at some point. Here's something from the Jag manual concerning it's math capabilities... The GPU is also intended to perform rapid floating-point arithmetic. It has no floating-point instructions as such, but has some specific simple instructions that allow a limited precision floating-point library to be capable of in excess of 1 MegaFlop. One of the reasons I chose 2.5D for the GPU is because of the fast math; it would be overkill for that sort of thing... I still stay hopeful, but it's not all that surprising considering every good Jag programmer all express their frustration with the system and its bugs. At 32bits that would be 8bits x 4, but would mean 4 times the data in cache... Another reason I would refer to the DSP, 68K or both to do some 3D work prior it the GPU handling whatever the outputs are. By the time it reaches the GPU, a great majority of the work is already done. Simply let the GPU do some fast 2D rendering based on the per-calculated stuff since the DSP have full access to main ram at 16bits. But the info you're dishing is very helpful only confirming a lot of stuff that I here from Jag programmers. I read somewhere that the Jaguar can do 720x480... Every tried another resolution size? Your vertical res is low, but you use a lot of lines within that low res. If the Jag can handle that many lines, seems like something a little more modest in resolution might be in order, which could help to free up some cycles.

There's one more thing I forgot to mention about "Project M" on the Atari XE130... The texture used in the "Wolfenstien" demo; they didn't use any bit maps, but was done in assembly/binary code, which I thought was pretty interesting. It's a very note worthy mention; I wonder if the Jag could do something procedural with texture mapping for the sake of speed and memory? That would certainly help tilt the unbalanced nature of the buggy Jaguar if the textures were very small, compact, yet machine code fast for that on-the-fly real-time rendering.

And to think I had a 1200XL and sold it... What was I thinking. It was the "Mr Wizard" Atari system of all systems. lol Well the info I got from the "M Project" came straight from the horses mouth/the guy who posted the YouTube in a comment some years back when he first posted it. At first I thought he was using some raycasting on the Atari 8 computer, which was done once before, but not quite the way this guy seemed to have pulled it off at that kind of resolution. I can't seem to find the actual quote, but no ray casting was used, it was full on scan-lines using interrupts to do all of the pseudo 3D effects; that much I do remember considering at that time I was looking at the Atari 7800 graphic chip able to use display-list, which is very different then the 130xl graphic chip, yet share some common ground with the Jaguar's OP able to display almost in similar manner. It seem like whatever the Jaguar OP lacks in comparison to the Atari 8s graphic ability, could be made up in speed, but then again, even the Atari 8bit computer had a little more ram to do more graphical things then the Jags GPU with only 4KB of internal. My thing is this, the GPU is a 2D monster very capable of doing 2D display and manipulation in real-time without breaking a sweat, which I've always credited as the Jaguar's strength... If 3D can be done using the DSP or the M68K or both very minimally using low poly based 3D models, and I mean low poly to the bone for the sake of speed and broad view distance, the GPU can interpret 3D data and render fairly accurate pseudo 3D/2.5D based of real 3D math as a way to fake high polygon objects in a similar fashion a voxel height-map is used or 2D meta-balls are used to render high detailed 3D images to screen only in this case, pseudo 3D is faked to look like real 3D high poly objects when in reality no real polygon is used, it just looks that way. It doesn't have to be voxel or metaballs per-say; just a smarter way to convey high detailed 3D in a way that takes the polygon count out of the equation or "Limitless 3D" as I use to say back in the old JS2 days; only its a new day today, I have a better understanding on things today then I did back in the day. That's what I mean by faking the living daylights out of 3D if that make any since to anyone.

Hold up now... First off I respect the mods over there and what they've brought to the table on Facebook. I don't know about anyone else, but they've been nothing but kind and inviting to me over there otherwise I wouldn't have vented there; I regard them as great people a particular moderator as good friend he's a straight up fellow if you ask me. Please dude... Don't insult my friends.

Hey man, I apologize for that; I didn't realize the gravity of what I did until after the comments. Besides my frustration was elsewhere beyond the forum and I just vented needlessly. I certainly don't want to cause the stir that I did, but it happened and I kind of wish it didn't after the fact. I don't want to make anymore problems for anyone here and I usually don't and haven't in times past. Now I've had people come me and start trouble with me here in the past and I simply never fed into that sort of thing thus was one of the reasons I left the scene for a minute, but I'm not here for that today. I took something the wrong way not really knowing if any of that old stuff from the JS2 days really died down since I've left the scene; it's hard to read attitudes behind sarcastic one liners. I'm sorry it came up, but I'm glad it came up to clear the air "I sincerely apologize for whatever trouble that post has caused". You don't know how far reaching your actions at a social media or forum are until after the fact. I want to be a contributing factor here and see more innovative stuff on the Jag personally, but I like original new releases in 2D and what-have-you even emulation. I like to see Neo Geo games work on the Jag to be honest, not to be sold, but just a great little project to work on.

Only if you make it a group thing... I usually don't get in to politics in a game forum like that.

Well that's quite a legacy; that nearly beats out some Neo Geo carts... It pulls off quite a few feats on the Jag for its time and the programmer is quite knowledgeable with the Jag; they cracked the cartridge encryption using a custom key before the official one went public in case people forgotten. I hardly call that a disappointment, but everyone is entitled to their opinion. #LegacyMatters

For that matter is that why the Jag CD units sell for so much... BTW I wish I'd gottten that game when Scatalogic first published it.

Hopefully no contraband will be found in these systems... lol This video below had me in tears when I first saw.

Dude that's awesome work... The graphics looks a little modular like it's following a path of some sorts rather than a modeled 3D environment... Kind of reminds me of "Checkered Flag"; despite the choppy frame rate, that game is probably one of the most open world 3D games to have a set of reusable 3D objects in a game. It seems like if the game wasn't in a loop with the race tracks, it could go on forever. You really got something on your hands there buddy; I really hope this engine comes out really solid for some really meaningful 3D gaming, which is a little lax these days as far as home-brewing. Great stuff man. Out of curiosity I'd find a use for it... I'll take it.

Ok... Here's another little nugget that can serve as a great example for using the Object Processor... If my memory serves me well, the "Wolfenstien" demo for the Atari 8bit wasn't a raycasting program, but was a scan-line based program that used "interrupts" to pull of the pseudo 3D effects. Someone can correct me if I'm wrong with the info or give a link to the topic that covers this project as I would like to know more about it. I guess Doom for the Jag kind of demonstrates very efficient scan-line based rendering in real-time. I'd like to see more creative stuff in this regard.

Well that goes without saying obviously; its ability to scale pixels really fast... My thing real-time manipulation of the OP list via the RISC before it actually reaches the OP, but that's for another day. Here's an insert from the Jaguar Manual... I want to exploit the living day-lights out of those "Conditional Actions" on a whole-other level if possible... At least that's my intentions. Well... I know it can't be programmed like the RISC or the 68000 can, but you can certainly do more stuff in comparison to the 7800 graphics chip that's totally dependent on 6502 that slows the system down by default... That's the point I was conveying.

Sort of reminds me of the Atari 7800 graphics chip that uses a display list where the graphics isn't pixel based per-say, but based on list being sent to the graphics chip only in the case of the Jaguar, the OP is programmable... Very fast graphics and untapped potential never fully taken advantage of.

Cartridge pins probably just need a thorough cleaning... Get some rubbing alcohol (99% Proof) and some Q-tips to clean the cartridges out. That worked for me in the past and if the screen is still showing red, then you'll know if the system's a lemon or not.

Ok... Here's another impressive game call "Racin' Force" that uses voxels as well as the 68000 processor; I see the arcade board uses a series of graphic chips, but I don't see if they were math chips... Whatever the case, this looks feasible to do on the Jaguar hardware considering it's ability to do voxel really well. Any kind of fast pseudo 3D for the Jag will probably be volumetric in nature in order to get those blazing fast non polygonal pseudo 3D graphics. Voxels doesn't look very good unless it's in high resolution, but it's possible to cheat jagged edges from voxels by clipping the edges at it's drawing points via the object processor. Just some tid-bit thought on some ideas; sometimes I look at 3D stuff and my brianstorming goes into overdrive. http://www.system16.com/hardware.php?id=574&gid=854#854

I was never an Atari ST owner, just a 2600 buff in the 80s, I wish I had an ST back in the day though. Recently I ran into a book at www.archive.org when looking for some Motorola 68000 assembly programming books. The book is called "Real-Time 3D Graphics for The Atari ST" and one other 3D graphic book for the ST that's sparked my interest a little more toward the 68K so I'm certainly looking at some possibilities with the CPU... I'll leave a couple of pdf files. https://archive.org/details/Real-Time_3D_Graphics_for_the_Atari_ST_1991 Real-Time_3D_Graphics_for_the_Atari_ST_1991.pdf Atari_ST_3D_Graphics_Programming_Concepts_And_TechniquesuBee.pdf

Don't forget mine... Here's my confirmation Number: 2010257 Date Ordered: Friday 25 February, 2011 Detailed Invoice: https://www.legacyengineer.com/storefront/index.php?main_page=account_history_info&order_id=2010257 Products ------------------------------------------------------ 1 x 7800 Expansion Module (7800XM1) = $99.99 ------------------------------------------------------ Sub-Total: $99.99 United States Postal Service (1 x 3.50lbs) (Priority Mail (2 - 3 days)): $13.20 Total: $113.19 Delivery Address ------------------------------------------------------ Billing Address ------------------------------------------------------ Payment Method ------------------------------------------------------ Credit Cards - Visa/Mastercard/AMEX/Discover Visa XXXXXXXXXXXX7112

@VladVR I remember some years back I had a discussion about the Jaguar's ability to do "Parallel Processing" and from that discussion it became very clear that the Jag bus bottleneck issue will probably require a less parallel technique to getting over the bottleneck issues... Not that it isn't possible, just a bit of a nuisance and potentially problematic towards progression so I've always bear that in mind; I think that whole discussion started from my curiosity of why "Checkered Flag" ran so sluggish on the Jaguar. It was assumed back then that the M68K was hitting the bus too hard doing a lot of game logic and AI functions thus is why I was a bit hard on keeping the 68K off back in the day. A less or non parallel way of processing would probably mean a less or non traditional method of real-time graphic display in a meaningful way. That's where my head is for Jag development. It was my understanding that the phrase "2.5D" mean "Pseudo 3D" like raycasiting, Doom style rendering which is different then ray-casting, 3D voxels using 2D sliced images to make up a 3D object or 3D box values in 2D space, 2D metaballs or even 3D metaballs that use simple shapes to produce countless polys on the fly and so-on... My hope is to one day find a way beyond the traditional confines of a large 3D data set and take away the restrictions of polygon counts. Inspired by the old VistaPro program, the file sizes prior to being rendered are a fraction of what the program actually produces on account that the program has to calculate all of the 3D math to produce it. Well the Jaguar's strength is in the 2.5D/Pseudo 3D stuff so a hybrid of both 2.5D (third mention) and real 3D seems to be the thing to pursue with the Motorola and/or DSP doing some real 3D work while the GPU with OP and BP rendering something in Pseudo 3D or fake 3D based on a real 3D framework and maybe some other pre-rendered or pre-calculated stuff to fake a high polygon object that may have been modeled in Blender or Zbrush without it being a large data set. https://en.wikipedia.org/wiki/2.5D Man I got to commend you on the 3D work you managed to get out of the Jaguar so far... Keep up the good work. Duly noted buddy... I was looking at the old "Chase The Beam" theory for the Jag... It's more like "Chase The Line" in the Jaguar case. Even by 1995, just a couple of years after the Jaguar release, the average PC that did 3D graphics ran at 60 or more megahertz, which wasn't available to the masses in 93 and 94 unless one owned a graphics workstation like the SGI stuff. Even the 3DO arms chip was proven in the Acorn PCs to do decent 3D stuff. Don't mean to give a history in that sort of thing and throw the topic off, but the best you had with 3D past 60fps was Doom, Super Burnout, Val d'Isere Skiiing, and Atari Karts showing some promise and let's not forget the voxel stuff. I want to get the GPU to produce better 3D graphics in the same kind of way it was able to produce those fast frame rates in these 2.5D games only smarter.

OK... Here's a good example of a low poly engine running an X68000 computer... It's very fast with no surfaces, just straight wire-frames running decently fast on a 68k processor. For the Jag, I would use low poly using the DSP, or the M68k, or both for speed and let the GPU render a high-poly version to screen using a type of scan-line render-er using the OP. Or if I could just fake the living daylights out of 3D using 2.5D methods at the GPU level based on the real low-poly 3D stuff, I'd settle for that; the Jaguar's strength is in it's 2.5D rendering. I've always been a firm believer in that fact. That's my vision a 3D engine for the Jaguar in a nutshell.

Ok here's an example of a low level view of Vistapro animation sequence before it's rendered on an Amiaga... It runs much faster on an IBM machine. Just an illustration to bat in a point. https://youtu.be/xd0L4TbHPm4?t=3m31s

@VladR I wouldn't have consider composition stuff to be that of a lazy coder... I think my point is being missed a little here when I mention the word composition. First off let me make an important note here my philosophy for Jag development is to "Think really Big, but Start Small." That's really the driving force behind a lot of my ideas; I got the phrase from a solar power company and become somewhat of an epiphany that stuck with me for years. When I mention the word composite, I'm thinking in terms of the Jag doing composition on a very small scale in a way that's feasible. You probably can't do shaders in the sense that a modern PC or game console can do, however, you might can trick some of the more simpler Jag mechanics to do some similar using low depth color, low poly objects or just simple bounding boxes in main for the DSP or M68K to manage until an actually reaches the GPU for fast rendering. Large data sets doesn't have to occupy physical memory, but rather a representation of such data can be present in the machine before an actual rendering takes place. We can't make the Jag get on the PS4 level-it just not built that way, but we can get on the Jaguars level where data and throughput can be very small and quickly manageable for real-time purposes. It all sounds good to me, but I know the reality of Jags complexity so I try and keep and open mind these days.That's also why I say in other topics that there need to be a radical re-thinking of how to program the Jaguar because system is what it is and any other 3D pipeline that came after it wasn't designed to be put on the Jag due better system architectures. @ LinkoVitch The same answer I gave VladR can also somewhat apply and I hope it give better understanding to a lot of my comments. There's a couple of old 3D programs that I use to work in in the late 90s called "Impulse Imagine 3D, which was in direct competition with the original "3D Studio" ; the other program is called "Vistapro" which was a landscape program that seems to use fractals to render landscape, which I'm going to post a couple of stuff I did in Vistapro (and showboat a little ). Both of these programs were out during the Jags hay day and were both consider ray-tracer based programs on the Amiga, but my versions was on IBM pc. These programs would start out as low poly bounding boxes or in Vistapro's case as low level fractals before anything was every rendered. If you think about the game Doom, it started as a low key binary tree set that resided in ram and didn't actually get rendered until the GPU actually picked it up via one of the Jag processors right? Well the same principal can apply for a real-time 3D render-er; the key would be the consolidation of the 3D sets for fast low bit depth recovery at the right time. Now the videos I made back in 2006, actually for a grade in a couple of college classes I was doing at the time, started out as low fractal height maps that looks very similar to "Rescue on Fractalus" for the Atari 8bit systems. Not to through this off topic, but to get a point across, Before I rendered the actual video you see, I would preview it in a height map fractal view designed for real-time viewing on an IBM 386 or higher. Not that I saying we should use fractals exclusively, what I'm saying is that the same principal low level fast small data set can be handled by the other processors on the Jaguar, before it actually reaches the GPU, Blitter, and OP for real-time polygon rendering or some other fast rendering scheme... Something like THAT should be the design philosophy behind the technicalities. Native Land Treasure: I rendered this in "VistaPro" for Windows, compose the music using "Acid" beat loops and edited everything in Adobe Premier back in 2005 or 06. A high res "VistaPro" rendering I also did in 2006. Sigh. Great memories...

Ok... Here's a post of two racing games; one is "Riding Hero" for the Neo Geo and the other is "Super Burnout" for the Atari Jaguar. Both are doing similar style graphics of zooming sprites using both system sprite zooming features. For the Atari Jag it would be the "Object Processor" doing all of the work and for the SNK, although the system has less ram than the Jag, the Neo Geo pulls off some pretty good stuff on its own merit. Riding Hero for the Neo Geo Super Burnout for the Atari Jaguar