dml

Hi, Well it's a nice idea - I might do something along those lines for engine programming, although so many techniques covered in those threads have since lost value for all but developing on retro hardware (maybe not quite, but close). Still it's good practice to crunch these problems, for working in other areas - there may be some middle ground that has some interest value.

Well thanks for the comments on progress, especially given this a Jag area and not a Falcon/ST forum - although I should say thanks also to all the A.F. members who put up with me over there I also agree with anyone who has given the opinion that it would be *hard* to implement a Quake based engine on the Jag. That is certainly true. I just suggest that it is doable, that past Jag games (especially from that time!) are not proof of hard limits - and that if JC was curious to try it at the time I'm sure he would have got results.

Yes, I'll stick by that. With Doom and Quake It's not enough to just roughly understand how that stuff works, with aim to change or improve on it. It's better to know *exactly* how it all works, or you'll miss something important and not even know. With Doom that applies to some areas. With Quake it applies to most areas.

Guilty! (hi, neo_rg! )

Oh that's ok, I can hold my own. Granted - that translating the *game* would involve compromises and changes to make it worthwhile - and I'm not recommending that. But the technology is useful and repurposable, and it's doable on a Jag.

I haven't seen anything first-hand, but I would not be surprised if JC threw some tests together, just because he could. IMO (and I can back it up) the Quake rendering system could have been translated to Jaguar at some limited resolution, and run well enough for single play, with some compromises. Framerate might even be workable for multiplayer - but that is less forgiving of framedrop. The lightmap system would probably need to be changed. Probably using more than one drawing pass and maybe dropping dynamic lightmaps completely. That's more speculation though, since the Jag could still do some specific things here. The game engine side of it - I'm less sure. There are a lot of animated meshes, lots of 3D collision detection going on and the particles are horribly expensive on any platform. Specialized work on the former (as was done in the JagDoom source, employing the DSP for it) and just dropping the latter might have done it. The QuakeC thing would also have been dumped for 100% native code on Jag. The problem with Quake on the Jag probably wasn't anything to do with JC getting technically stuck - more like the incentives didn't add up, compared with the other work they wanted to do at the time.

I have identified use cases for the chip in realtime 3D which can't be handled easily by the CPU or DSP, and will be making extensive use of it soon. It's pretty useless to try to accelerate simple 3D math using FPU but it does have its place for more subtle cases. Just hasn't been exploited much yet on Ataris - not to my knowledge.

Yes, it uses it a lot.

68882 support was implemented some time ago, but the main benefit of the chip is precision - not speed - So the DSP outperforms it for all the jobs which are needed for that engine. It is still used for the internal profiler which is used to assist with optimizing the engine, but no longer used by the engine itself. Keeping it in the engine just prevents it from running on a Falcon without 68882 (and making it switchable offers no benefit). (FPU will likely be needed for my next project, which is different in nature from Doom - which was always designed for a 16/32 integer machine)

Umm, I'm late as usual - but here goes: Afterburner040 Falcon + 20MHz bus + 50MHz DSP + CFlash <---- my old Atari 'workhorse' CT60 Falcon + SuperVidel/SVL + CFlash <---- still being ...configured stock Falcon030 + 14MB + HxC/USB + CFlash <---- lightly repaired, live 'test box' for new code stock Falcon030 + 4MB <---- seriously repaired (rated 'Steve Austin/Bionic Man' on a scale of 1-10), now lingering in a cupboard (And yes, I should really do something about the one in the cupboard).

I've been using this cross-compiler successfully with ST/STE/Falcon for some time now. (It's not MiNT-specific BTW, the built executables will run under TOS). http://vincent.riviere.free.fr/soft/m68k-atari-mint/ It can be used as-is, or combined with VASM assembler which handles Devpac assembly format, providing you configure VASM to output GCC compatible objects.

Cisco Heat (ADMA, BLIT, ?EPAL?) The last one probably needs checked/compared, I can't remember for sure...

If the machine generally works but is flaky with time or temperature, it's probably one of the age-sensitive parts. - power supply. check the DC out for AC ripple. if you can't do that, replace any old electrolytic capacitors on it if not done already. they dry out over time, esp. with raised temperature. - electrolytic capacitors on the main board, especially any under or near the warm power supply. - dry joints on the pcb. can be hard to find, a hot-air station can be used to reflow the solder in specific places if you can narrow it down a bit. Remove any peripherals for debugging (e.g. floppy drive) since these can also be a source of problems and can stress the power supply even if the rest of the machine is working ok. When you're testing, make sure you always test the same way (same duration/ambient temperature) and use several tests each time - to avoid confusing yourself with erratic results. The board can be tested with a non-Atari power supply (like a PicoPSU or ATX) to rule out PSU problems but it should be done with care (and use existing reference from others who have tried). This is general advice - you could have other problems like a damaged IC socket, poor ground contact or something. It's best to have this done by somebody with the proper tools (i.e. scope, ic-safe continuity tester, solder/air station) and experience.

I wouldn't mind finding a card for my old Mega 4! I think they are nearly impossible to find these days though? :-z

If the machine has a 020 or 030 CPU, it will either be coupled to an FPU 'properly' - most likely on the same board (and therefore be compatible with any other programs that expect 0x0+88x), or it won't have any FPU coupling at all. I don't think there is an in-between scenario. I really doubt an 020/030 can couple to an 88x chip using the '68000 hack' method (e.g. an 030 board trying to talk to an 881 somewhere else in the system, intended for a 68000) and even if that is possible, I don't expect such a machine would benefit much from that arrangement (the 68000 kind of coupling is necessarily slow). So if you have an 030 and 88x on the same board (be that a mainboard or accelerator board), you don't need to worry about unusual/incompatible coupling. It will just work. If you have an 030 on an accelerator board and an 88x on the mainboard - that's a bit suspect but assuming the 'original' mainboard CPU was also 020+ class, it will likely still 'just work'. If the original CPU was a 68000, the coupling to the 88x probably won't work. I'm probably making that look more complicated than it is

Impressive stuff. it r0x0rz.

Yes, quite a lot of stuff on the Falcon using the 56k now... I felt like I was alone playing with it back in the mid '90s but things have changed since :-) I recently unearthed quite a bit of 3D code I wrote for this chip including a portal engine, texture mapping and some other stuff I'm still identifying. Having to get data in and out via the 8-bit triplet host port on an already slow bus, or via audio-bandwidth DMA was the biggest annoyance for me (a fast path would have been nice for graphics or GPDSP tasks!) but that aside it was a great feature of the F030 and it's nice to see so much good stuff surfaced for it.

The 68881 and 68882 only differ by performance/timings. There are no compatibility issues between them, or 'extras' in the 68882, or stuff that works with one but not the other. There is however a different way of 'wiring' an FPU to a 68000 which makes it incompatible with code made for 68020+ with FPU. This has to do with the way instructions are encoded for comms between the older 68k CPU and the FPU. This doesn't affect Falcons or TTs at all since they are 030 based. The 881 or 882 will work equally well but 882 will be quicker. And double precision values are not mandatory when using the FPU. The chip can handle single (32bit) or double (64bit) precision values in memory, and internal operations are always slightly greater than both (80bits) without incurring extra cost. i.e. arithmetic is always 80-bits internally but the extra bits do not have to be moved to/from memory (which is where extra cost would show). Whether singles or doubles are used is up to the software using it. The chip handles both types nicely just like the FPU in modern PCs (the 881 was very advanced for its time). The 881/2 also has hardware versions of more advanced functions which the later 68040/68060 chips don't have (those need emulation). So the 881/2 chip is technically more 'capable' than the later CPUs with builtin FPUs. However the subset of functions implemented by the 040/060 chips are much much faster than the old FPUs. Not much 'old' software uses the FPU, but any more recent stuff ported from other systems will benefit from having one. It's hard to find projects these days that don't use floats for something as it's now almost assumed as a standard hardware capability... As for comparisons... software floating point libraries are *awful*. I have studied them in detail. The simplest arithmetic must involve calls out to libraries and redundant packing/unpacking of data types for every single add, subtract, multiply etc. This overhead costs nearly as much as the arithmetic does. A hardware FPU has none of that - single instructions, no calls to libraries, no copying stuff around in memory. Can be orders of magnitude faster. If you have a program that wants to use floats, it's worth having one. Speeds - the 882 can typically be clocked 2x and sometimes 3x it's rated value. Many chip MFRs had a habit of making good chips and then stamping different numbers on them to suit different markets. You could have 3 chips all with the same tolerances but marked 16mhz, 33mhz, 40mhz and nobody could tell the difference. Only way to find out is to overclock and see. If one doesn't clock well, try another. They don't cost very much now.

A few points on the build used in the video. I had to build it 'blind' and send it to sh3rg without seeing what was in it, since I no longer have a working Jag devkit. I just have the source and data files. So it was pot luck really. Having looked at the vid, it's clear the level is an old alpha test setup - I can tell by the schoolboy-error tile repeats in the tunnel. i.e. unpolished map and 'enemy' placements very simplistic for easy AI testing. There is a much more polished version of this level schema which is probably the one seen in the earlier videos (pre-cart-wiping-accident) but I haven't located the data for that level yet. In any case, the sourcecode is intact even if the final demo level has been lost. Big thanks to sh3rg for taking the time to test it, make the vid and host the demo for the last show. It wouldn't have resurfaced without his support. N.B. it doesn't look or play anything like Thunder Force II, even taking the iffy level data into account. the map route is very constrained for a start, and the enemies are linked together and respond to indirect triggers. Yes it's a top-down 8-way job, but that's about where it ends. OTOH, I do agree that a lot of the finer points e.g. enemy linkage and indirection will not show in this very limited demo map.

Thanks for all the comments. Will keep updating as I find and test things. A bit short on time just now due to work but I'll give it as much attention as I can.

I'll put some binaries up for d/l soon although they aren't all interesting. A few small tests for the particle system, enemies, polygon/texturemapping and so on. Some early playfield tests. One or two very early level tests. I don't quite have the full preview going (the one in the vid) because we split the data away from the executable when it started getting big, and used a script to launch it on the Alpine. It's in two parts and I can't remember how to bake it all into a single ROM. Would need some to time to pick at it and figure it out. Normal (I think) Jaguar, with an Atari Alpine board in the cart slot - the one that looks like a sail. If you were not careful you could easily catch the thing going past the table and drag the board, the jag, cables, monitor and half of the room along with you. I witnessed at least one accident like this with the Alpine. We didn't use PCs at the time. All work was done on Falcon030's with the TOS toolchain. Cheers

Today I posted a short writeup on the project here: http://www.leonik.net/dml/sec_atari.py

I have unearthed a few COF files from a Jaguar project I was building in the mid/late 90's - some of which seem work ok but others don't work at all. I can provide some of these binaries if it helps with debugging/improving VJ. I imagine new Jaguar test code doesn't show up very often. PM me if I can help. (the project is described here: http://www.leonik.net/dml/sec_lw.py)