Falcon Doom

All about games on the Falcon, TT & clones

Moderators: Mug UK, moondog/.tSCc., [ProToS], lp, Moderator Team

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Fri Jan 25, 2013 10:00 am

Eero Tamminen wrote:I wasn't clear on what I was asking was for, it was about what should happen on *each* executed instruction. Should I record just that there was miss, or how many misses executing the current instruction at this point (once) incurred ie. should I increase the sum of misses for given address by 0-1 or by 0-3.


I think recording the sum of misses by 0-3 is more useful - this way all information is captured.

Eero Tamminen wrote:Also, does the DSP have any kind of cache / cache misses?


No it has a simple onboard / external static ram arrangement for all memory, but it does have some less obvious complexities to it's (otherwise quite simple) timing scheme.

There are 3 internal memories (X: data, Y: data, P: program/instructions) and assuming all memory sources for a given instruction come from one of those, the timing is 'ideal' i.e. usually 2 oscillator clocks or whatever the manual says for that instruction (most are 2, 4 or 6).

If one of the sources used by the instruction (be that instruction fetch, or a data read/write) comes from external memory (anything above address $200 for X: and Y: or above address $100 for P:) this will be free - no effect on timing.

However if 2 or more sources come from external memory there is a 2-clock penalty for each source. So if an instruction is in external memory, and fetches from both X: and Y: in external memory, there is a 2x2 clock penalty on top of the instruction time.


There is a further complexity which is also covered in the manual but limited to certain instructions. There are costs for special addressing modes and for jump address calculation (jx), the latter being more complex. The manual says '6+jx' but jx can be quite large IIRC depending on the opcode encoding, and where the instruction lives! There are one or two other details but more trivial.


Eero Tamminen wrote:What about TT, does that also have burst mode normally off?


The TT sacrificed its Blitter to gain a 32bit bus, so I imagine it retained its burst mode. I don't know for sure though.

Eero Tamminen wrote:Latter point affects just timings, right? Anyway, that's more for Laurent than me... :-)


I think so, although I don't know that it affects it in a trivial way :) I have seen a description/writeup of how the Falcon varies from Motorola timings because of this, but I can't vouch for that either. Laurent has a difficult task generally :)

I started writing a new benchmark tool (really an instruction pattern timing tool) to help me figure some of these things out for optimizations. Some of the things I found already were found by experiment and testing only.


Eero Tamminen wrote:I get following statistics:
- 0: 29282934
- 1: 43281
- 2: 3323
- 3: 6510


If this is instruction cache only, it looks reasonable for longword misses yes. I think it's important to keep i-cache and d-cache results separate though.

The analysis looks good! I'll do some tests with it as soon as I can. I think I know roughly what to expect already so I should be able to tell if things make sense in context or not (hopefully :-) ).

User avatar
LaurentS
Captain Atari
Captain Atari
Posts: 250
Joined: Mon Jan 05, 2009 5:41 pm

Re: Falcon Doom

Postby LaurentS » Fri Jan 25, 2013 10:26 am

Hi,

For the DSP part, I think I've already implemented all the case you mention into Hatari (X:Y memory access with the extra +2 clock cycles after the first external access, jx and the other specific timings related into the motorola DSP doc) ...
Except if there's a little bug somewhere, I really think the DSP timings are OK.
You can easily see them if you use the dsp_disasm command under the hatari debugger and trace a few lines.

For the 68030 part, I've just explained a few things in my previous message (the last one on the 7th page of this thread).
The problem is that I don't spend a lot of time on this part actually (I have nearly no time free these days).
I wish days end after 30 hours instead of 24 ;)

Doug, if you find some useful informations about 68030 timings that would help for hatari accuracy, don't hesitate to help us, I'm not that strong in this part (I took it because there was nothing done on this point, but I'm pretty sure I've forgotten many important parts that should be taken into account in a good Falcon emulation before starting to play with the timings as I did ) (I think it's the little part of the task, but there's probably an important work to do in the general bahaviour of the Falcon emulation before playing with the details).

I don't know how to express it better, but before playing with a few cycles, one should verify that the main parts of the emulation are OK, like BUS access priority, Videl access, DMA, memory aligment, ...
All of this can vary the cycles by a lot and only after, trying to fix correctly the 68030 timings.

And of course, there's the Videl which is not emulated at all.

I had this discussion with Nicolas a few month ago : in hatari, the main clock is given by the CPU, so, without an accurate CPU timings emulation, no Videl, no good sound and no DSP accuracy is possible.
But the CPU is also dependant of the DSP, Videl and DMAs access to the BUS, so it seems to be the problem of the egg and the chicken.! /)

I'm probably not strong enough on this part to do it lonely.
We should be more than one here (with some average acknoledges about how the 68030 and the Falcon work internally) to manage this.
This may take a few month, but the result would be really great (they did it in the amiga world, we can do it too, as we are clever than them ;) )

But the result would be really great.

My motivation on hatari is multiple :
- being able to understand better how the Falcon works
- having a good tool to develop quickly under a modern machine for my Falcon
- having the possibility to continue to see all the games and demos of the Atari world when my real hardware will break (this will happend one day or the other)
- meeting nice fellows
- learn
- ...

Let's spend a few month together (Mikro, Eero, Doug, Nicolas, Thomas, and all the other here that are still involved into the atari world).
Hatari is an open project, let's improve it together.

Regards

Laurent

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1482
Joined: Sun Jul 31, 2011 1:11 pm

Re: Falcon Doom

Postby Eero Tamminen » Fri Jan 25, 2013 4:41 pm

dml wrote:I think recording the sum of misses by 0-3 is more useful - this way all information is captured.


Ok, that's what the earlier patch does. I'll commit it to the Hatari repository.


dml wrote:I started writing a new benchmark tool (really an instruction pattern timing tool) to help me figure some of these things out for optimizations. Some of the things I found already were found by experiment and testing only.


Is this tool that generates native code and times it, or some kind of a post-processing tool?

I started myself to think how I might post-process Hatari emulator results with function address information so that one can get a list of functions taking most of time. I was thinking of just assigning everything between successive symbol addresses to the preceeding symbol. That of couse assumes that one does have symbol info for all functions in the code, but I hope it's not a problem.

That could be done even in the Hatari profiler itself, but if one wants to post-process it later to get get callgraphs or have functions include time spent by sub-functions, doing it with post-processing would probably be better[1]. I think I'll add add profile save functionality and use post-processing.

[1] Best would be to generate Valgrind callgrind/KCachegrind compatible output:
http://valgrind.org/docs/manual/cl-format.html

And view it in KCachegrind:
http://kcachegrind.sourceforge.net/

But I'm not sure whether KCachegrind supports profiling data which references binary files it doesn't understand...


dml wrote:
Eero Tamminen wrote:I get following statistics:


If this is instruction cache only, it looks reasonable for longword misses yes. I think it's important to keep i-cache and d-cache results separate though.


It's just i-cache, as you said that to be most useful. Should I add support also for profiling d-cache misses?

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Fri Jan 25, 2013 6:40 pm

Eero Tamminen wrote:Is this tool that generates native code and times it, or some kind of a post-processing tool?


It performs actual timings, since I was looking for a way to analyse differences from the documented timings.

It would execute a block of code many times, and then execute it again with certain operations missing, in order to measure instruction head/tail and buffered memory effects with different patterns. This wasn't supposed to build a magic database of any kind, just a way for me to test optimizations in a harness.

Eero Tamminen wrote:I started myself to think how I might post-process Hatari emulator results with function address information so that one can get a list of functions taking most of time. I was thinking of just assigning everything between successive symbol addresses to the preceeding symbol. That of couse assumes that one does have symbol info for all functions in the code, but I hope it's not a problem.


Yes that should be fine. It would make for a better high level view.

Eero Tamminen wrote:That could be done even in the Hatari profiler itself, but if one wants to post-process it later to get get callgraphs or have functions include time spent by sub-functions, doing it with post-processing would probably be better[1]. I think I'll add add profile save functionality and use post-processing.


That makes sense, providing the post-processing is easily accessed from different platforms (e.g. Python :) ) without too many fussy dependencies.


Eero Tamminen wrote:
[1] Best would be to generate Valgrind callgrind/KCachegrind compatible output:
http://valgrind.org/docs/manual/cl-format.html

And view it in KCachegrind:
http://kcachegrind.sourceforge.net/

But I'm not sure whether KCachegrind supports profiling data which references binary files it doesn't understand...


I think making the output accessible for cursory inspection is the most important thing. Being able to analyse it in other tools is very helpful, but secondary.

Eero Tamminen wrote:It's just i-cache, as you said that to be most useful. Should I add support also for profiling d-cache misses?


It would be nice to have that too :) but more often the i-cache impacts actual performance.

The d-cache can be a drag much of the time so perhaps seeing d-cache misses would help make the d-cache more useful on the Falcon? It's worth some thought.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1482
Joined: Sun Jul 31, 2011 1:11 pm

Re: Falcon Doom

Postby Eero Tamminen » Fri Jan 25, 2013 6:59 pm

dml wrote:
Eero Tamminen wrote:It's just i-cache, as you said that to be most useful. Should I add support also for profiling d-cache misses?


It would be nice to have that too :) but more often the i-cache impacts actual performance.

The d-cache can be a drag much of the time so perhaps seeing d-cache misses would help make the d-cache more useful on the Falcon? It's worth some thought.


Data cache usage isn't so clear in WinUAE sources. Could you at some point look into end of the src/cpu/newcpu.c and comment at which point(s) in write_dcache030() and read_dcache030() functions you think profiler should increase the miss counter for the instruction?

I also guess you would prefer data read and write misses to be counted separately?

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Fri Jan 25, 2013 7:05 pm

Eero Tamminen wrote:Data cache usage isn't so clear in WinUAE sources. Could you at some point look into end of the src/cpu/newcpu.c and comment at which point(s) in write_dcache030() and read_dcache030() functions you think profiler should increase the miss counter for the instruction?

I also guess you would prefer data read and write misses to be counted separately?


Ok I'll have a look at it soon - and keeping read/write misses separate is a good idea too yes.

AnthonyJ
Atari nerd
Atari nerd
Posts: 46
Joined: Sat Jan 26, 2013 8:16 am

Re: Falcon Doom

Postby AnthonyJ » Sat Jan 26, 2013 8:26 am

dml wrote:Looks like Anthony and his source have 'gone offworld'. :-z

Good luck finding it - his old email address is dead and waybackmachine doesn't know about the zip.


Hiya - interesting to see some activity on bad mood again!

I don't currently have any active webspace (it probably was still archived on my BT webspace until they killed them off recently). I don't have my falcon accessible anymore but pretty sure I can lay my hands on the final source snapshot. I'll take a look and attach here later. Probably don't have much time to work on it much myself though.

I like the idea of splicing the BM renderer onto the doom codebase. It might be worth looking at some of the GL ports of doom as they may have already partitioned the renderer from the gamecode.

AnthonyJ
Atari nerd
Atari nerd
Posts: 46
Joined: Sat Jan 26, 2013 8:16 am

Re: Falcon Doom

Postby AnthonyJ » Sat Jan 26, 2013 9:04 am

dml wrote:Looks like Anthony and his source have 'gone offworld'. :-z

Good luck finding it - his old email address is dead and waybackmachine doesn't know about the zip.


Oddly my previous post hasn't come online (maybe moderation for first posts?), but I've got more info now anyway...

I only went off Atari-world but can still be found in the Doom / Quake worlds (albeit newer generations!), and unfortunately have changed ISP a couple of times since which is why my contact details have decayed, and BT have now taken down user webspaces so even that archive is gone.

Attached to this post is the DEU8-SRC.zip that used to be on my website so is presumably the final build I put online. I don't know if I had local changes that never got released onto the website - that is possible. I have an archive CD which I can check to see if there is a newer build, although I don't have access to that right now but I'll see what I can do (I moved house recently, and that box is currently still in the garage!)

I like the idea of attaching BM onto the Doom codebase - seems a good decision as there is probably quite a lot more to getting a full game than it would seem. It would be worth investigating the various GL ports of Doom because they may have cleanly separated out the renderer from the gamecode already.
You do not have the required permissions to view the files attached to this post.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Sat Jan 26, 2013 12:52 pm

Hi Laurent,

LaurentS wrote:For the DSP part, I think I've already implemented all the case you mention into Hatari (X:Y memory access with the extra +2 clock cycles after the first external access, jx and the other specific timings related into the motorola DSP doc) ...
Except if there's a little bug somewhere, I really think the DSP timings are OK.


Yes I think you did a great job I already saw the timing information in the current Hatari. I didn't use it much yet but I will need it very soon. With my own profiler I got a good view on *where* the time is being spent in BadMood and have made some high level changes there. With Hatari profiler I will be able to see *why* the time is spent in some places which look ok at source code level... it will be a very useful tool for this area.

LaurentS wrote:For the 68030 part, I've just explained a few things in my previous message (the last one on the 7th page of this thread).
The problem is that I don't spend a lot of time on this part actually (I have nearly no time free these days).
I wish days end after 30 hours instead of 24 ;)


I know what you mean ;) And it was easier to find coding time at 18, 20, and even 25yrs... but much more tricky now!

LaurentS wrote:Doug, if you find some useful informations about 68030 timings that would help for hatari accuracy, don't hesitate to help us, I'm not that strong in this part (I


I'll tell you about anything I can find for certain - but like you I have no special source of information at this time - lots of reading, guessing, trying things. I will get some additional data soon from my benchmark tests on a real 030 and report anything useful/different.

(BTW one difference I saw already is 'nop' timing - it is always 4 cycles in Hatari for i-cache 100%hit/100%miss/disabled. But on real Falcon it is 2 or 8. However I will do that test again soon and get you figures without relying on my poor memory...

I also found some 'overlapping' instruction cases while writing BadMood long ago, which again need measured properly.

LaurentS wrote:I don't know how to express it better, but before playing with a few cycles, one should verify that the main parts of the emulation are OK, like BUS access priority, Videl access, DMA, memory aligment, ...
All of this can vary the cycles by a lot and only after, trying to fix correctly the 68030 timings.


I think that is the only sensible way yes - otherwise it could never settle down to accuracy.

LaurentS wrote:And of course, there's the Videl which is not emulated at all.


Thankfully, the Videl is already a 'variable' in a real Falcon and is only expressed as a %age loss of bus time. I doubt any real program relies in Videl timing although some programs may run a little bit faster or slower...

I think though it would be difficult to express these costs through CPU timings since the CPU is clever enough to 'keep working' when the bus is blocked. The WinUAE core really needs to deal with bus cycle wait states to emulate this properly.

(I really don't know the emulation cores very well so my advice is not the best source at all!)

LaurentS wrote:I had this discussion with Nicolas a few month ago : in hatari, the main clock is given by the CPU, so, without an accurate CPU timings emulation, no Videl, no good sound and no DSP accuracy is possible.
But the CPU is also dependant of the DSP, Videl and DMAs access to the BUS, so it seems to be the problem of the egg and the chicken.! /)


Yes hopefully the emulation cores provide a way to deal with this kind of thing properly without messing with CPU timing directly, otherwise it looks like an impossible task.

I know the Amiga bus works differently from the ST/Falcon and is much more synchronous - device costs are well hidden much of the time (but at a somewhat higher cost overall). I don't know if that influenced WinUAE design for bus timing problems (?)

LaurentS wrote:I'm probably not strong enough on this part to do it lonely.
We should be more than one here (with some average acknoledges about how the 68030 and the Falcon work internally) to manage this.
This may take a few month, but the result would be really great (they did it in the amiga world, we can do it too, as we are clever than them ;) )


It looks like an amazing job so far. I can run BadMood and it runs at relatively close speed! :-)

LaurentS wrote:Let's spend a few month together (Mikro, Eero, Doug, Nicolas, Thomas, and all the other here that are still involved into the atari world).
Hatari is an open project, let's improve it together.


If i can help in some way with anything I find or learn I will definitely try - however it will probably be small crumbs compared with the huge and impressive work done so far :)

Best,
Doug.

Dal
Administrator
Administrator
Posts: 4039
Joined: Tue Jan 18, 2011 12:31 am
Location: Cheltenham, UK
Contact:

Re: Falcon Doom

Postby Dal » Sat Jan 26, 2013 3:49 pm

AnthonyJ wrote:
dml wrote:Looks like Anthony and his source have 'gone offworld'. :-z

Good luck finding it - his old email address is dead and waybackmachine doesn't know about the zip.


Hiya - interesting to see some activity on bad mood again!

I don't currently have any active webspace (it probably was still archived on my BT webspace until they killed them off recently). I don't have my falcon accessible anymore but pretty sure I can lay my hands on the final source snapshot. I'll take a look and attach here later. Probably don't have much time to work on it much myself though.

I like the idea of splicing the BM renderer onto the doom codebase. It might be worth looking at some of the GL ports of doom as they may have already partitioned the renderer from the gamecode.


Hi Anthony - yes first 3 posts require moderation before your account is properly activated (one more to go). Thanks for popping by and attaching your BM sources - if you do find anything else, I'm sure it would be greatly appreciated! :)
FireBee, Falcon -Soundpool case: CT63@95Mhz + 14MB/512MB + 16GB SSD + FPU + Phantom 25/50 + SuperVidel + SoundPool FDI + FA8 + ADAT + Eiffel, TT030: 4MB/16MB + Crazy Dots, Mega"SST" 12, STbook, STacy 2, MegaSTE, STE: Desktopper case, IDE interface, UltraSatan (8GB + 512Mb) + HXC floppy emulator. Plus some STE's/STFM's

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Sat Jan 26, 2013 3:53 pm

AnthonyJ wrote:Attached to this post is the DEU8-SRC.zip that used to be on my website so is presumably the final build I put online. I don't know if I had local changes that never got released onto the website - that is possible. I have an archive CD which I can check to see if there is a newer build, although I don't have access to that right now but I'll see what I can do (I moved house recently, and that box is currently still in the garage!)

I like the idea of attaching BM onto the Doom codebase - seems a good decision as there is probably quite a lot more to getting a full game than it would seem. It would be worth investigating the various GL ports of Doom because they may have cleanly separated out the renderer from the gamecode already.


Yay! Anthony is back with the DEU code :) We thought we had lost you.

GL Doom isn't bad idea for reference - although I'd probably diff them to see where the adaptations lie and work with the original source as much as possible. The approach makes sense though.


BTW I have made some progress on BM code performance despite being mostly offline with flu. I'll post an update when I get a bit more time to type it up...

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Sat Jan 26, 2013 3:55 pm

AnthonyJ wrote:Attached to this post is the DEU8-SRC.zip


...actually it looks like you attached the binary instead of the source?

AnthonyJ
Atari nerd
Atari nerd
Posts: 46
Joined: Sat Jan 26, 2013 8:16 am

Re: Falcon Doom

Postby AnthonyJ » Sat Jan 26, 2013 4:25 pm

Dal wrote:Hi Anthony - yes first 3 posts require moderation before your account is properly activated (one more to go). Thanks for popping by and attaching your BM sources - if you do find anything else, I'm sure it would be greatly appreciated! :)


Yea, read the message properly on my second post - the first was done from my phone which is why I didn't read too much!

dml wrote:
AnthonyJ wrote:Attached to this post is the DEU8-SRC.zip


...actually it looks like you attached the binary instead of the source?


Oops. I verified I had the source, and then attached the wrong file... it should be there this time.
You do not have the required permissions to view the files attached to this post.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Sat Jan 26, 2013 7:49 pm

AnthonyJ wrote:Oops. I verified I had the source, and then attached the wrong file... it should be there this time.


Got it now - thanks :)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Sat Jan 26, 2013 8:04 pm

So the floor fragmentation problem has been fixed - the engine can now defragment floor/ceiling (visplanes) across sector boundaries in some cases (it already defragmented between wall segments).

grab2a.png



And in a bad case it seems to do better than Doom itself...

grab2b.png


Image

...although further defragmentation is unlikely unless everything is extracted from the DSP long before drawing, instead of leaving most of it onboard and allowing the DSP to schedule visplane perspective work ahead of time (which I think is more valuable than better defragmentation)
You do not have the required permissions to view the files attached to this post.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1482
Joined: Sun Jul 31, 2011 1:11 pm

Re: Falcon Doom

Postby Eero Tamminen » Sat Jan 26, 2013 9:09 pm

Here are some tricks I guess I hadn't mentioned yet, but which can be useful for automating things:

* you can ask Hatari to parse debugger commands right in the beginning, with "--parse <file>" command line option.
I use this to load symbols for TOS, setup specific breakpoints etc.

* If you use "--bios-intercept" option, your *Atari* program can invoke Hatari command line options, shortcuts, debugger commands etc, by using XBios call 255. Argument is a string which starts with prefix identifying how rest of the string should be interpreted. For example: "hatari-debug profile on".

* One way to stop execution and drop to debugger from Atari code, is inserting an illegal instruction with inline asm to it, and setting Hatari breakpoint for that opcode ("b (pc).w = 0xabcd"). If you don't want to interact with debugger, you can set a tracing breakpoint, or one that executes debugger commands from file (those are always always tracing breakpoints, ones that don't stop emulation to debugger, but continue after doing what was asked).

* In latest Hatari release "--bios-intercept" enables also outputting TOS console output to terminal where Hatari is running. With Hatari version in Mercurial, you need "--conout 2" for that (it catches TOS conout vector 2 output by parsing stack and outputs it to Hatari console). With BIOS level hook some of the console outputs were missed (MiNT output, EmuTOS panics etc), that's why I changed hooking to happen at lower level.

* If you want to get some debug output from your Atari program without messing what's on TOS screen, you can output it to some other device than console and set that device (midi, serial, parallel) to stdout for Hatari. In Hatari version from Mercurial you can also use NativeFeatures "stderr" device:
http://wiki.aranym.org/natfeats/proposal
like EmuTOS does:
http://emutos.cvs.sourceforge.net/viewv ... iew=markup

PS. cache miss profiling is now in Hatari Mercurial repo + I just added change needed to save profiling result. You can do that like this:
profile addresses 0 profile-out.txt

(giving zero as "count" asks debugger to output all addresses that had activity during profiling, both in RAM & ROM, to the given file.)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Sun Jan 27, 2013 4:42 pm

I now have a working Cygwin/X build of Hatari from Mercurial using WinUAE core, so I should be able to start doing experiments with the profiler next week.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1482
Joined: Sun Jul 31, 2011 1:11 pm

Re: Falcon Doom

Postby Eero Tamminen » Mon Jan 28, 2013 10:14 pm

FYI: Doug has mailed about some issues in the profiles and they're being addressed + scripts are being added to convert Devpac listing symbol tables & DSP LOD files to symbol information format [1] understood by Hatari.

[1] similar to 'nm' output.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Tue Jan 29, 2013 12:25 pm

Let's assume for a minute that a 68882 FPU/coprocessor could be used to speed up BadMood/'Falcon Doom' in some way. Perhaps lot by a large amount but some positive contribution (e.g. less code == better CPU i-cache performance + some extra concurrency with CPU).

Lets also assume it was an all or nothing decision - you either need one or you don't. Would that be a bad thing?

The stock model Falcon didn't ship with a coprocessor, but OTOH they are cheap and common and solder-free to install (Atari provided the empty socket) and I'm not sure if other ports (e.g. Amiga?) would hold back from adopting FPU if it helped. Not that I've looked into it much but it seems like it might be fair game.

So far BadMood hasn't used the FPU at all and so it will work on any Falcon but I'm not sure what people think about 'min spec' for a Doom engine on Atari? Should it be aimed at 'stock model' machines all the way?

Note: we're probably talking %age points here and it's not clear it will help at all yet - but I will be looking at it.

User avatar
DarkLord
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4118
Joined: Mon Aug 16, 2004 12:06 pm
Location: Prestonsburg, KY - USA
Contact:

Re: Falcon Doom

Postby DarkLord » Tue Jan 29, 2013 12:51 pm

I can't speak for everyone but personally I added an FPU to every Falcon I've
ever owned.

(as well as every other Atari I could, examples my STacy and Mega STe)

If you were going so far as to add the math coprocessor code, how much
harder would it be to add detect code? (this is assuming you find a benefit
from supporting it in the first place).

Thanks, and thanks for continuing work on this awesome project. :cheers:
Welcome To DarkForce! http://www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS - Telnet:darkforce-bbs.dyndns.org 520

User avatar
alexh
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2512
Joined: Wed Oct 20, 2004 1:52 pm
Location: UK - Oxford
Contact:

Re: Falcon Doom

Postby alexh » Tue Jan 29, 2013 1:00 pm

What does having a Nemesis (or other such bus accelerator) do for your 68882 clocking?

Just a quick google, they are very cheap. £8 + postage for a 40MHz rated MC68882FN40A

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 831
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: Falcon Doom

Postby EvilFranky » Tue Jan 29, 2013 1:33 pm

An FPU is hardly an extravagant expense or a rare component, do what you have to do Doug :wink:

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Tue Jan 29, 2013 1:55 pm

DarkLord wrote:If you were going so far as to add the math coprocessor code, how much
harder would it be to add detect code? (this is assuming you find a benefit
from supporting it in the first place).


It might not amount to much work in fact - there are perhaps 2 or 3 places where it might beneft - the bulk of the hard work is DSP based anyway.

However if it turned out pretty useful I might not want to maintain 2 versions of big wodges of code so it's good to know how people felt about it before I go near it.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3430
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Tue Jan 29, 2013 2:04 pm

alexh wrote:What does having a Nemesis (or other such bus accelerator) do for your 68882 clocking?
Just a quick google, they are very cheap. £8 + postage for a 40MHz rated MC68882FN40A


An overclocked FPU would likely help - the internal cycle throughput for fadd/fmul/fdiv will likely be the main bottleneck and that's what would be reduced by overclocking.

Nemesis provided a clock feed to the FPU, but it can be done by hand in isolation as well. Not that I recommend doing that - and I wouldn't do any FPU programming that needed an overclocked FPU to make it useful. If it's not useful at 16MHz I probably wouldn't use it at all :-)

User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4087
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: Falcon Doom

Postby nativ » Tue Jan 29, 2013 3:53 pm

Hi,

I have a 68882 16 in my falcon with a 40 ready to fit when I get some desk space!

Can your FPU code be enabled on the 040 and 060?

It does raise the bar of a 'stock' Falcon by using the FPU . But I think if you have 'reached a point' thats satisfactory without using it then break and continue with it. If possible keep dual compatibility but not necessarily.

:cheers:
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4

http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records


Social Media

     

Return to “Games”

Who is online

Users browsing this forum: No registered users and 2 guests