Only if that code is called, which it's not in the case of the peripheral being disabled. I suggest you step through the emulation loop with a debugger to work out what's going on, as it's pretty subtle (these are not normal gotos).
we can use array of function pointers which filled only with functions for currently active peripherials, and use simple loop to iterate thru it. heh, it actually can be even faster than this gotos. %-)
I'd put money on that being slower than the current implementation. Do you have evidence to show otherwise?
it can be even easier to understand than the current codebase.
The core emulation loop is one of the few places I'm prepared to make compromises on readability of code in order to get speed.
>Only if that code is called, which it's not in the case of the peripheral being
>disabled.
ah, yes. i've missed some macros. %-) clever trick.
>these are not normal gotos
yes, i know what 'computed goto' is.
and what about my second idea? overhead: one 'if'. and we can 'hint' that condition is mostly 'false', so branch predictor will succes most of the time.
cons: takes more memory; have to call register/unregister functions each time 'enabled' flag changed. slower on 'trap hit' (but this can be ignored, i think). slightly messy code for peripherial driver registration.
pros: no speed penalty for 'non-trap' addresses and turned off peripherials. no need to patch Z80 emulation each time new peripherial driver added.
am i missed something in this case?
p.s.: btw, is speed *so* important? heh, instruction interpreter is huge 'switch', and it can use computed gotos instead. so some speed already sacrificed. %-)
p.s.: btw, is speed *so* important? heh, instruction interpreter is huge 'switch', and it can use computed gotos instead. so some speed already sacrificed. %-)
No. Any compiler worth its salt is already converting that switch into an indirect jump: I suggest you look at the generated assembly.
That's what I'd rather avoid: having to learn how peripheral code interacts with the rest of the emulator. Instead, I'd rather learn a documented procedure of adding a peripheral I could even debug off of FUSE, and not to worry about the main code base. Just as drivers in Linux are handled: I can write a device driver for Linux without knowing 95% of the source code of the kernel itself.
Don't forget that you're going to want your interface to actually do something at some point :-) There might be an odd few peripherals whose behaviour can be described entirely in terms of port read/writes and memory traps, but I suspect that most peripherals are going to require things like writing to the audio stream, modifying the display routines, file selectors, config options, recording state in SZX snapshots and so on. You're not going to get very far with those things without knowing something about the general architecture of Fuse.
Of course, it's in the Fuse developers' own interests to make all of those things as modular and standalone-hackable as possible, and they're continually making efforts towards that - but it's a long way from creating formal APIs for them all. Perhaps the real wishlist item here is "more/better documentation aimed at peripheral developers", if that's what's stopping you from diving into the source...?
in a lot of ways it (and forgive the pun) re-kendall'ed my passion for Spectrum's!
I currently run Fuse on my *Nix box, XBox (kinda the same thing), PSP and Windows..
I would be lost without them, so all I could ask more of fuse is to just be more Awesome! if that were possbile.
to be honest I dont use enough features of fuse, so it would be wrong of me to recommend or proffer more. so instead this is a cheer-leading post and all those that think Fuse is great, grabs some pom-poms and cheer =)
Perhaps the real wishlist item here is "more/better documentation aimed at peripheral developers", if that's what's stopping you from diving into the source...?
yeah but that's assuming that the plug-in is written for fuse... :)
I was thinking more like a generic peripheral emulation API.
Imagine for example that fuse had such a plugin architecture, and a handful of GPL plugins. Ok, now woody implements the API in specemu from the api specification right. I write a plugin for specemu and release it how is that a fuse derivative work? :)
If a user downloads my specemu plugin and loads it into fuse that's not a GPL violation... What have I started here lol
yeah but that's assuming that the plug-in is written for fuse... :)
I was thinking more like a generic peripheral emulation API.
Imagine for example that fuse had such a plugin architecture, and a handful of GPL plugins. Ok, now woody implements the API in specemu from the api specification right. I write a plugin for specemu and release it how is that a fuse derivative work? :)
If a user downloads my specemu plugin and loads it into fuse that's not a GPL violation... What have I started here lol
What are the chances of Woody rewriting SpecEmu to accomodate plugins?
Slightly less than zero :lol:
And more seriously where does that leave Woody when he has used Fuse's API?
>And more seriously where does that leave Woody when he has used Fuse's API?
reimplementing API is perfectly legal. one even can reuse header file, as long as it contains no code, only pure declarations.
Woody explained that one of the reasons it doesn't get emulated is because the Timex FDD is a computer in itself (with its own Z80), not just a peripheral, and that makes things... complicated. :)
Complicated? Right. If someone wrote a 2 ROM gameboy emulator capable of running 2 different ROMs at same time...
Z80 emulation is done and today computers can run 2 Z80 emulations at full speed...
I wouldn't say it is complicated... but challenging. Why write another ZX Spectrum emulator? Aren't there enough?
A few people who work in emulator development told me that if there was enough interest and there was a wiki page with enough information, it could inspire them to work on it. Every time I was told that I pointed them to the pages on your websites.
But to be honest, we can count with the fingers of one hand the amount of people that want Timex FDD emulation...
At least a TOS Emulation...:\
It was so superior to +3DOS...
You may know more people who like and use the Timex FDD, but since they're not active in the Spectrum community, emulator authors don't see the point of developing such a feature.
The challenge to make a emulation of 2 computers at the same time? :)
We may not have Timex FDD emulation, but John Elliot kindly created an utility (at my request) to convert backed up 3" Timex disks (in EDSK format) to +3DOS images. It may not be ideal, but it helps us extract files from those images. :)
There was a old utility I used long ago to extract and copy files from a TOS disk to MS-DOS. That utility allowed me to make a program I called TAP2TOS that "convert" TAP files to TOS files and load them from disk.
I wouldn't say it is complicated... but challenging. Why write another ZX Spectrum emulator? Aren't there enough?
Just as an aside (in a thread of many asides)... I don't think there are anywhere near enough. Spin and SpecEmu are no longer in active development (although hopefully that may change one day?), Spud and Zero aren't currently very mature in terms of features. So in terms of native, PC-based, well featured, emulators in active development - there is fuse and Spectaculator, only one of which is free.
Having written a couple or three fairly low-spec open source 8 bit emulators from scratch in the distant past, I think it's reasonable to say that most people have absolutely no concept of the sheer amount of work involved. We are talking about the equivalent of tens of thousands of pounds worth of software development and testing at least. Hardly surprising there aren't that many of them, and also hardly surprising that there's often a fairly high level of disenchantment among authors of free (as in beer) speccy emulators.
There is always room for more speccy emulators, I think. :)
active development is over rated... when something's finished it's finished :)
One issue there, is organisations like Microsoft moving the goalposts - just because an emulator works perfectly under XP doesn't mean it works pefectly (or at all, even) under Win7. I guess this issue will become more of a problem as time goes on. Not so bad for open source emulators, but it's a real threat to any closed source that isn't being actively maintained. That code will ultimately rot unless someone takes it on...
One issue there is organisations like Microsoft moving the goalposts - just because an emulator works perfectly under XP doesn't mean it works pefectly (or at all, even) under Win7. I guess this issue will become more of a problem as time goes on. Not so bad for open source emulators, but it's a real threat to any closed source that isn't being actively maintained. That code will ultimately rot unless someone takes it on...
Actually Microsoft don't really move the goalposts very much. The usual problem is that people write software that relies on things it shouldn't rely on :p
Even having open source code doesn't help in some cases as you find you have a program that relies on some library which isn't being developed and the last version won't run on this OS version and it won't compile with a modern compiler etc etc etc.
Having written a couple or three fairly low-spec open source 8 bit emulators from scratch in the distant past, I think it's reasonable to say that most people have absolutely no concept of the sheer amount of work involved. We are talking about the equivalent of tens of thousands of pounds worth of software development and testing at least.
Another perspective is that this is a good reason to contribute to improve an existing emulator rather than write another one from scratch.
@encarnado: There is not enough interest to justify creating TOS emulation. That's the reality. I'm being realistic, not pessimistic. :) From the WOS's community point of view, you and I appear to be the only Timex FDD users. We know this isn't true, but those who should show up and show interest don't want to post here because they might feel their English isn't good enough. And I honestly believe that most of them can't even be bothered to create an account.
The Portuguese and Polish Timex users were supposed to be actively participating in this forum and the retro scene in general, but you hardly hear anything from them. American Timex FDD users? I know of one who posted once in the TS Yahoo group in the past 5 years... Some people have Timex FDDs in their collection, and that's it. Just a collectors item. No interest, no contribution, no participation.
When there's enough interest in something, people with the right skills feel encouraged to develop something. The Spectranet is a good example of that.
It's the same when you create new hardware. If it appeals to a large group of people, it will be kept alive, offered for sale by several people and even emulated. If it doesn't, it ends up being a curiosity for which some pictures and videos appear online. Nothing more.
I've been talking about the Timex (almost as much as Andrew Owen) since 2006. I tried to obtain support for the emulation of certain Timex peripherals. I've been active on WOS, CSS, ECSS, Speccy.org, the TS2068 Yahoo group, the ZX81 forum (which also supports the TS1000 and TS1500) and I've even tried to create a group specifically for Timex users in Portuguese. That last one didn't work.
So *takes deep breath*, just wanted to share with you this point of view. :) It's not that emulator authors have anything against the Timex or the TOS. It's not they don't care. :) There's simply not enough interest. They do these things on their own free time, and it's a lot more rewarding to code something if you know that a lot of people will be using it.
Before we see any Timex FDD or Timex TOS emulation, we would have to see the emulation of other things that the preservation team has been asking for a couple years now. There are several software titles that were released commercially in media for which the drive isn't emulated yet. If anyone from the preservation team is reading this, please confirm.
edit: omg, I'm starting to suffer from E.W.G.F. (Extensive word-generating fever)
Before we see any Timex FDD or Timex TOS emulation, we would have to see the emulation of other things that the preservation team has been asking for a couple years now. There are several software titles that were released commercially in media for which the drive isn't emulated yet. If anyone from the preservation team is reading this, please confirm.
Generally speaking if you want something that no-one else is interested in you write it yourself ;)
Some very good reasons for why Timex disk emulation hasn't been done because folks that want it stay away from WOS
There's also the fact that the vast majority of the folks on this forum (the more vocal ones, at least) just aren't very nice people. And yes, I include myself in this assessment. There's been some truly awful behaviour on the part of regulars here with no desire for anything but back-stabbing and splitting/ostracising people off from the scene, to the extent that people often try to get others banned.
Is there any wonder people with less than perfect English skills avoid this place?
TO: Zx Bruno & Encarnado... My sympathy goes out to you both... you must feel very lonely here in WOS!!!... But seriously though... I think you both make good points, but I would hesitate to suggest that it is "lack of interest" that holds development back, so much as a sheer lack of knowledge concerning these peripherals...
I can honestly say with hand on heart that I HAVE NEVER EVEN HEARD of a Timex FDD 3000, or TOS operating system for the ZX systems... And I bet that I am not alone in this. What we have here is not a lack of interest, but a BIG information gap... I would be surprised if large numbers of the English speaking ZX scene (UK & US) had even heard of the FDD 3000... I am amazed, quite frankly, about how little I know about ZX based systems ourside of the UK. Im starting to hear and learn more about the Russian scene but the Portuguese and Polish scene are something of a mystery to me, and probably to many other WOS users... The truth is, we here simply don't hear enough about such systems...
I had to google referrences to the Timex FDD just to try to understand and follow what you were all talking about on this thread. I didn't even see any pointers or links or hypertext markers pointing in this thread to help guide me. We were all talking about the FDD Timex system, and even then, no-one thought to post any links... why is that?... Is it because there is no information out there?... And that is precisely the problem, no one knows anything about this, and anyone who does, isn't pointing to information about this system:
Here's is what I found on google for those who don't know:
...now that I do know, Im interested and curious... And Ill bet that others who learn of this system will likewise be curious... So we're not looking at a lack of interest, more a lack of widespread familiarity...
Most of those websites or pages were created by Encarnado or borrowed content from his websites. The Timex pages on Speccy.org also have content from Encarnado's websites. Most if not all technical information about the FDD came from him. :-) He has worked for more than a decade trying to gather as much information as possible and it's been there for a long time.
I agree that all the available information still needs to be organized and maybe added to the Timex wiki, but the Timex FDD and its clones never became popular outside of Portugal and Poland. It "suffered" from the same problem as the +3: 3" drives. Our Polish friends made it "better" by replacing one or two of the drives with 5 1/4 ones, but it never became as popular as, for example, the Plus
The major Speccy magazines of the mid 80s announced what Timex was doing, but it was probably seen as "just another expensive toy that no Specchum can afford."
It was exported to the U.S. but I only know two people who have one.
If someone wants to learn more about it, Encarnado is the man.
If someone wants to know more about the actual hardware, Jos? Leandro is the person to talk to.
John Elliot already analyzed the data structure of Timex TOS disks.
I have hope that I'll see this Timex hardware emulated one day, but I'm not holding my breath.
I would love to see the debugger improved. The breakpoint list, event list, stack view, registers and disassembly should all have their own resizeable windows with user-selectable fonts.
Load and save symbols tables in text format
Be able to select and copy anything (including register values) in the debugger windows to the clipboard.
I would like to see the ability to open additional memory watch windows (with no limit on the number you can open) pointing either at fixed addresses or registers, with ASCII and hex/decimal byte/word views.
A graphical watch window would be nice as well along the same vein as the memory watch window. To cater for different views maybe a very simply scripting language could be implemented. Refresh of individual watch windows could be either done every time the code is stepped or when PC or the watch window's base pointer is within defined ranges, something along the lines of this:
refresh m $a000-$a800
refresh PC $85c0
tile 4,1
for 16
m, m+2, m+4, 0, m+1, m+3, m+5, \r
m+10, m+8, m+6, 0, m+11, m+9, m+7, \r
m+=12
next
Which would display the mask and sprite for four frames of a 24x32 masked sprite in zig-zag format.
It would also be nice if the register pairs had additional formats shown, i.e. rather than the following:
PC 0x02ae
AF 0x00a9
BC 0xFDFE
DE 0xffff
HL 0x002e
Have this instead:
PC 0x02ae (686)
AF 0x00a9 (0)
BC 0xFDFE (65022)
253, 254
DE 0xffff (65535)
255, 255
HL 0x002e (46)
0, 46
It might be good if all those extra debugger status and watch window settings could be saved as separate project files to go with a particular snapshot as well as being saved as defaults. Perhaps the convention might be to only update the project file if one is being used otherwise save as default if that's enabled.
As someone else said before, visibility of screen writes as they are done rather than when the full frame is drawn. Perhaps if the previous frame could be drawn at half brightness and the current screen is refreshed at full brightness up to the current beam position? This would make it easier to debug border effects as well. I haven't looked at the code for the screen emulation though so I don't know how difficult it would be to retrofit that into the system given the number of different display emulation options.
Save movies in animated GIF or APNG format rather than separate files for each frame.
If there's anything I can do to help let me know. I can't promise anything as much of my time is not my own anymore but I do know how to code and could probably get up to speed with the source if there was a specific area of the code to target.
If there's anything I can do to help let me know. I can't promise anything as much of my time is not my own anymore but I do know how to code and could probably get up to speed with the source if there was a specific area of the code to target.
If there's a feature you want and are prepared to code yourself, then I (and the rest of the Fuse team) are more than happy to help you contribute. Get yourself onto the fuse-emulator-devel list and/or #fuse-emulator on irc.oftc.net (channel key: 16384) and fire away with any questions you have.
There is no grand overarching plan for Fuse, so essentially any feature is welcome.
Comments
Only if that code is called, which it's not in the case of the peripheral being disabled. I suggest you step through the emulation loop with a debugger to work out what's going on, as it's pretty subtle (these are not normal gotos).
I'd put money on that being slower than the current implementation. Do you have evidence to show otherwise?
The core emulation loop is one of the few places I'm prepared to make compromises on readability of code in order to get speed.
>disabled.
ah, yes. i've missed some macros. %-) clever trick.
>these are not normal gotos
yes, i know what 'computed goto' is.
and what about my second idea? overhead: one 'if'. and we can 'hint' that condition is mostly 'false', so branch predictor will succes most of the time.
cons: takes more memory; have to call register/unregister functions each time 'enabled' flag changed. slower on 'trap hit' (but this can be ignored, i think). slightly messy code for peripherial driver registration.
pros: no speed penalty for 'non-trap' addresses and turned off peripherials. no need to patch Z80 emulation each time new peripherial driver added.
am i missed something in this case?
p.s.: btw, is speed *so* important? heh, instruction interpreter is huge 'switch', and it can use computed gotos instead. so some speed already sacrificed. %-)
No. Any compiler worth its salt is already converting that switch into an indirect jump: I suggest you look at the generated assembly.
Don't forget that you're going to want your interface to actually do something at some point :-) There might be an odd few peripherals whose behaviour can be described entirely in terms of port read/writes and memory traps, but I suspect that most peripherals are going to require things like writing to the audio stream, modifying the display routines, file selectors, config options, recording state in SZX snapshots and so on. You're not going to get very far with those things without knowing something about the general architecture of Fuse.
Of course, it's in the Fuse developers' own interests to make all of those things as modular and standalone-hackable as possible, and they're continually making efforts towards that - but it's a long way from creating formal APIs for them all. Perhaps the real wishlist item here is "more/better documentation aimed at peripheral developers", if that's what's stopping you from diving into the source...?
there are enough chars to make me completely insane, so i'll take your word for it.
Firstly let me just say Fuse is AWESOME!
in a lot of ways it (and forgive the pun) re-kendall'ed my passion for Spectrum's!
I currently run Fuse on my *Nix box, XBox (kinda the same thing), PSP and Windows..
I would be lost without them, so all I could ask more of fuse is to just be more Awesome! if that were possbile.
to be honest I dont use enough features of fuse, so it would be wrong of me to recommend or proffer more. so instead this is a cheer-leading post and all those that think Fuse is great, grabs some pom-poms and cheer =)
\o/ !YAY! \o/\O/ FUSE \O/\o/ !YAY! \o/
Yes! I'd say so :)
yeah but that's assuming that the plug-in is written for fuse... :)
I was thinking more like a generic peripheral emulation API.
Imagine for example that fuse had such a plugin architecture, and a handful of GPL plugins. Ok, now woody implements the API in specemu from the api specification right. I write a plugin for specemu and release it how is that a fuse derivative work? :)
If a user downloads my specemu plugin and loads it into fuse that's not a GPL violation... What have I started here lol
that user violated GPL, so he looses the right to use FUSE and must deinstall it.
Slightly less than zero :lol:
And more seriously where does that leave Woody when he has used Fuse's API?
leave him? no-where as far as I am aware, again that can't be a GPL violation, he's not using any GPLed code at all.
reimplementing API is perfectly legal. one even can reuse header file, as long as it contains no code, only pure declarations.
Nope, the user can do whatever he likes with GPLed code unless he is distributing it.
Complicated? Right. If someone wrote a 2 ROM gameboy emulator capable of running 2 different ROMs at same time...
Z80 emulation is done and today computers can run 2 Z80 emulations at full speed...
I wouldn't say it is complicated... but challenging. Why write another ZX Spectrum emulator? Aren't there enough?
At least a TOS Emulation...:\
It was so superior to +3DOS...
The challenge to make a emulation of 2 computers at the same time? :)
There was a old utility I used long ago to extract and copy files from a TOS disk to MS-DOS. That utility allowed me to make a program I called TAP2TOS that "convert" TAP files to TOS files and load them from disk.
Having written a couple or three fairly low-spec open source 8 bit emulators from scratch in the distant past, I think it's reasonable to say that most people have absolutely no concept of the sheer amount of work involved. We are talking about the equivalent of tens of thousands of pounds worth of software development and testing at least. Hardly surprising there aren't that many of them, and also hardly surprising that there's often a fairly high level of disenchantment among authors of free (as in beer) speccy emulators.
There is always room for more speccy emulators, I think. :)
ah. so i shouldn't stop writing DSP5! (yes, DSP3 and DSP4 are already dead %-)
active development is over rated... when something's finished it's finished :)
sure it'd be nice to have the few bugs in spin or eightyone sorted out but they're all in the "extras" not the actual core speccy emulation.
(course you could say none of them are ever "finished" as people keep discovering new z80 or ula behaviour just to throw a spanner in the works :))
Actually Microsoft don't really move the goalposts very much. The usual problem is that people write software that relies on things it shouldn't rely on :p
Even having open source code doesn't help in some cases as you find you have a program that relies on some library which isn't being developed and the last version won't run on this OS version and it won't compile with a modern compiler etc etc etc.
Another perspective is that this is a good reason to contribute to improve an existing emulator rather than write another one from scratch.
I wrote one that doesn't work properly on Windows and now I'm using it to write one that doesn't work properly on the DS...
The Portuguese and Polish Timex users were supposed to be actively participating in this forum and the retro scene in general, but you hardly hear anything from them. American Timex FDD users? I know of one who posted once in the TS Yahoo group in the past 5 years... Some people have Timex FDDs in their collection, and that's it. Just a collectors item. No interest, no contribution, no participation.
When there's enough interest in something, people with the right skills feel encouraged to develop something. The Spectranet is a good example of that.
It's the same when you create new hardware. If it appeals to a large group of people, it will be kept alive, offered for sale by several people and even emulated. If it doesn't, it ends up being a curiosity for which some pictures and videos appear online. Nothing more.
I've been talking about the Timex (almost as much as Andrew Owen) since 2006. I tried to obtain support for the emulation of certain Timex peripherals. I've been active on WOS, CSS, ECSS, Speccy.org, the TS2068 Yahoo group, the ZX81 forum (which also supports the TS1000 and TS1500) and I've even tried to create a group specifically for Timex users in Portuguese. That last one didn't work.
So *takes deep breath*, just wanted to share with you this point of view. :) It's not that emulator authors have anything against the Timex or the TOS. It's not they don't care. :) There's simply not enough interest. They do these things on their own free time, and it's a lot more rewarding to code something if you know that a lot of people will be using it.
Before we see any Timex FDD or Timex TOS emulation, we would have to see the emulation of other things that the preservation team has been asking for a couple years now. There are several software titles that were released commercially in media for which the drive isn't emulated yet. If anyone from the preservation team is reading this, please confirm.
edit: omg, I'm starting to suffer from E.W.G.F. (Extensive word-generating fever)
Generally speaking if you want something that no-one else is interested in you write it yourself ;)
There's also the fact that the vast majority of the folks on this forum (the more vocal ones, at least) just aren't very nice people. And yes, I include myself in this assessment. There's been some truly awful behaviour on the part of regulars here with no desire for anything but back-stabbing and splitting/ostracising people off from the scene, to the extent that people often try to get others banned.
Is there any wonder people with less than perfect English skills avoid this place?
D.
I can honestly say with hand on heart that I HAVE NEVER EVEN HEARD of a Timex FDD 3000, or TOS operating system for the ZX systems... And I bet that I am not alone in this. What we have here is not a lack of interest, but a BIG information gap... I would be surprised if large numbers of the English speaking ZX scene (UK & US) had even heard of the FDD 3000... I am amazed, quite frankly, about how little I know about ZX based systems ourside of the UK. Im starting to hear and learn more about the Russian scene but the Portuguese and Polish scene are something of a mystery to me, and probably to many other WOS users... The truth is, we here simply don't hear enough about such systems...
I had to google referrences to the Timex FDD just to try to understand and follow what you were all talking about on this thread. I didn't even see any pointers or links or hypertext markers pointing in this thread to help guide me. We were all talking about the FDD Timex system, and even then, no-one thought to post any links... why is that?... Is it because there is no information out there?... And that is precisely the problem, no one knows anything about this, and anyone who does, isn't pointing to information about this system:
Here's is what I found on google for those who don't know:
http://en.wikipedia.org/wiki/Timex_FDD3000
http://timex.comboios.info/FDD3000.html
http://8bit.yarek.pl/computer/timex.fdd3/
http://8bit.yarek.pl/computer/timex.fdd3000/index.html
...now that I do know, Im interested and curious... And Ill bet that others who learn of this system will likewise be curious... So we're not looking at a lack of interest, more a lack of widespread familiarity...
I agree that all the available information still needs to be organized and maybe added to the Timex wiki, but the Timex FDD and its clones never became popular outside of Portugal and Poland. It "suffered" from the same problem as the +3: 3" drives. Our Polish friends made it "better" by replacing one or two of the drives with 5 1/4 ones, but it never became as popular as, for example, the Plus
The major Speccy magazines of the mid 80s announced what Timex was doing, but it was probably seen as "just another expensive toy that no Specchum can afford."
It was exported to the U.S. but I only know two people who have one.
If someone wants to learn more about it, Encarnado is the man.
If someone wants to know more about the actual hardware, Jos? Leandro is the person to talk to.
John Elliot already analyzed the data structure of Timex TOS disks.
I have hope that I'll see this Timex hardware emulated one day, but I'm not holding my breath.
Which would display the mask and sprite for four frames of a 24x32 masked sprite in zig-zag format.
Have this instead:
If there's anything I can do to help let me know. I can't promise anything as much of my time is not my own anymore but I do know how to code and could probably get up to speed with the source if there was a specific area of the code to target.
If there's a feature you want and are prepared to code yourself, then I (and the rest of the Fuse team) are more than happy to help you contribute. Get yourself onto the fuse-emulator-devel list and/or #fuse-emulator on irc.oftc.net (channel key: 16384) and fire away with any questions you have.
There is no grand overarching plan for Fuse, so essentially any feature is welcome.