fuse-emulator-devel — Development of Fuse (the Free Unix Spectrum Emulator), the associated utilities and libspectrum, the ZX Spectrum file-format handling library.

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[David H. <da...@be...>]

Although I don't really have much spare time, I would second a move over to
github, because integration/release pipelines can easily be built and
automated there - to help move away from the reliance on volunteer builds
that are (or could be) out-of-date.  And also, of course, the ability to
collaborate with the authors of the forks and pull back into mainline -
everyone wins.

On Mon, 22 Sept 2025 at 14:39, Alan Pearson <ala...@gm...> wrote:

> Hi All,
>
> It’s been a week and I haven’t seen any further traffic on this.
> How can we advance it ? Would the devs on this list be willing to move
> across to github ?
> If Philip is no longer in a position to maintain it, would anyone else
> volunteer to do so ?
>
> I’m saying this, but I’m not a FUSE dev, at best I can understand some of
> the code, but could never contribute in any meaningful way.
>
>
> (-1 on Discord by the way, the preferred way for me is mailing lists that
> are archived, searchable and public ….  much like the LKML)
>
> Thanks,
> Alan
>
>
>
> On 15 Sep 2025, at 22:31, Peter Moore <pet...@gm...> wrote:
>
> As a Fuse contributor (with unreleased changes), I’m really happy to see
> the new activity here!
>
> I would propose creating a GitHub org called fuse-emulator. It doesn’t
> exist at time of writing! It can be created here:
> https://github.com/account/organizations/new?plan=free. I didn’t create
> it, because I feel like Philip or people in the existing support team
> should be the ones that own it or decide what names they are happy with
> etc, and if they are happy to relocate from soureforge to GitHub.
>
> Then the various repos will appear underneath github.com/fuse-emulator
> which seems perfect (to me).
>
> There are a few user forks of fuse already on GitHub, but I feel like an
> official org is the way to go for the canonical source. It isn’t possible
> to use the org name “fuse” because a user called fuse already exists.
> “fuse-emulator" feels like a good alternative (and is similar to e.g.
> ubuntu package name).
>
> Discord sounds like a great choice too - this could be easily documented
> and linked from GitHub. Discussions and Wiki can also be enabled in GitHub
> repos which is another way to bolster engagement.
>
> This feels like it could be an exciting turning point! :-)
>
> Pete
>
>
> On 15. Sep 2025, at 14:09, Joerg Pleumann <joe...@gm...>
> wrote:
>
> +1 for GitHub
>
> And may I suggest a Discord for the communication? I have found that a
> very effective means of community building and information exchange in
> several other projects. I’m willing to set it up (not that it’s very
> complicated) and might even have a spare Nitro boost from my monthly
> subscription.
>
> Am 15.09.2025 um 13:56 schrieb Alan Pearson <ala...@gm...>:
>
> Hi Everyone,
>
> Chipping in on this thread.
> Thanks Joerg for raising this, and thanks Philip for coming back.
> I think a lot of users have been waiting a long time for a new release,
> myself included.
>
> I completely get you’re at a different life stage now, and we all move on,
> you’ve left one heck of a legacy that make many people happy.
> I’d come back on one of your comments if I may, the use case of fuse.  I
> think it’s well past playing Manic Miner (there are so many other ways to
> do that today, including a web browser), and for me, the use case of fuse
> is Spectrum/Z80 tinkering and development.
>  I use FUSE because of the extensive hardware emulation (particularly
> +D/Disciple & the 128k models), and have spent many happy hours doing
> things such as converting games to load from disk, to messing around with
> crazy things like learning all about the differences between the FDC in the
> +3 and +D.
> FUSE has a lot of abilities, some could be built upon to make it even
> better (remote control debugging / execution, hooking it into Spectrum
> Analyser for example).
>
> On the Mac build.. some years ago, with the help of this list I got it to
> build on both Intel and Apple Silicon (after some serious efforts getting
> the dependencies right), but alas it crashed opening the first window. On
> investigation this was due to a change in more recent versions of Mac OS
> where it was doing something that apple have now termed illegal. For the
> life of me, I can’t remember what it was.
> Maybe I’ll try again and report the error here so someone could help
>
> Philip I hope you can either become active again (supporting patches,
> releasing builds, and please, please, please move to GitHub !) or find
> someone to take on those tasks.
>
> Please don’t let FUSE wither, it’s such a great tool, with so many uses.
>
>
>
>
>
> Thank you from a very grateful user.
>
> Alan
>
>
>
>
>
> On 15 Sep 2025, at 12:24, Joerg Pleumann <joe...@gm...> wrote:
>
> Hi Phil,
>
> thanks a lot for the response — and for all the hard work and dedication
> that went into Fuse since it was conceived in 1999. Apart from CSpect,
> which I use for Next-specific stuff, Fuse has been my favorite 48K/128K
> emulator for a long time now, especially due to the fact that it’s
> available on so many platforms.
>
> I agree Fuse is quite mature, but, as you mentioned, platforms move on and
> software may have to adapt from time to time in order not not become
> obsolete. I’m not sure how much assistance I could provide here, but I’m
> definitely willing to test and provide feedback. I regularly use Intel and
> Arm Macs as well as Ubuntu machines.
>
> I already tried to build the latest Mac version, with the intention of
> getting a bit of understanding of the code base and maybe solving my little
> issues locally, then provide a patch, but so far I even failed to checkout.
> Is there a chance you establish contact with Frederick Meunier, so I can
> ask him a few questions?
>
> Best regards
> Joerg
>
> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh...>:
>
> > Did everybody move on to other things or is it because the project is so
> mature (almost) no changes are needed? :)
>
> [ Wakes up from slumber ]
>
> I'd say both. Certainly from my point of view, I'm at a very different
> stage of my life than I was in 1999 when the project started and I'm pretty
> sure that will apply to a number of the other "core" developers as well.
>
> But I'd also agree that the project - and in fact, the software Spectrum
> emulation scene in general - has reached maturity; you can see this in that
> the rate of development of all the other major emulators has pretty stopped
> as well - because they do everything that 99% of users want to do, which is
> to play Manic Miner. The notable exception here is Spectrum Next emulation,
> but that is _such_ a different machine even if it uses a "CPU" which is a
> superset of the Z80.
>
> With regards to the macOS version in particular, we always had a single
> point of success of the one developer who owned a Mac; I'm not aware of
> anyone even vaguely active who is trying to make new macOS builds - and as
> you note, the evolution of the Apple hardware ecosystem means there's
> probably a lot of catching up to do.
>
> Please nobody let me be a blocker to getting things done with the project
> - I'm happy to talk about what privileges someone would need to get new
> releases out if there's someone who is genuinely interested in doing so.
>
> Thanks,
>
> Phil
>
>
>
>
>
> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm...>
> wrote:
>
>> Hi Alberto,
>>
>> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to
>> other things or is it because the project is so mature (almost) no changes
>> are needed? :)
>>
>> I am using Fuse as emulator in a multi-platform Z80 compiler environment
>> I’ve been developing for a while now. I have a couple of issues, including
>> a bigger one with multi-line debugger commands fed into Fuse via the
>> command line. In the meantime, I’ve been able to solve the latter, but
>> would still prefer a more „solid“ solution. From the back of my head,
>> here’s my full list of issues/questions:
>>
>> 1) Could there be an alternative --debugger-command-file that points to a
>> file containing the debugger commands? If there are many and complex
>> breakpoints the command line gets extremely long, and those newlines scare
>> me a lot when pushing everything though my tools and a shell process until
>> it arrives in Fuse.
>>
>> 2) As an alternative idea to 1): The CSpect emulator uses certain invalid
>> opcodes (such as $dd $01) as breakpoints. That means the opcodes would be
>> part of the program itself and not have to be specified on the command
>> line. Is that something you could consider?
>>
>> 3) Could the default behavior for 128K .sna files be changed? Currently
>> the system interprets them as Pentagon snapshots, does not find the ROMs (I
>> am not interested in Pentagon) and „crashes“ into a 48K machine. I
>> understand this is possibly a „historical decision“, but in my opinion
>> there’s nothing inherently Pentagon about the format. Would something like
>> this work: If the Pentagon ROMs are not there and/or the user specified
>> —machine 128 on the command line, treat this as a 128K snapshot, not as
>> Pentagon? Or simply a checkbox in the preferences?
>>
>> 4) Could there be a „step over“ button in the debugger UI that basically
>> does what „n“ does in the debugger commands (as a convenience)?
>>
>> 5) Last but not least, the Mac version seems to be a bit behind the
>> latest upstream (and have some bugs of its own). Not sure if the main Mac
>> developer is on this list, but is there a chance for an update? I’m very
>> much willing to provide feedback for Intel and Arm Macs. I could also try
>> building either locally, but I probably won’t be much help with the actual
>> development because I don’t know the codebase.
>>
>> Best regards
>> Joerg
>>
>> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig...>:
>> >
>> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>> >> sorry for using the developer list for this question, but since all
>> >> the other places (especially the SourceForge project for Mac Fuse,
>> >> which is the flavor I am using) are so inactive, I was wondering
>> >> if the project might have moved elsewhere. Is there a Discord or
>> >> another place where one might ask questions, or are things really as
>> >> inactive as they seem?
>> >
>> > You can ask questions here, I guess, but the project is certainly
>> > stalled at the moment...
>> >
>> > Berto
>> >
>> >
>> > _______________________________________________
>> > fuse-emulator-devel mailing list
>> > fus...@li...
>> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>
>>
>>
>> _______________________________________________
>> fuse-emulator-devel mailing list
>> fus...@li...
>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>
>
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>
>
>
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>
>
>
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Alan P. <ala...@gm...>]

Hi All,

It’s been a week and I haven’t seen any further traffic on this.
How can we advance it ? Would the devs on this list be willing to move across to github ?
If Philip is no longer in a position to maintain it, would anyone else volunteer to do so ?

I’m saying this, but I’m not a FUSE dev, at best I can understand some of the code, but could never contribute in any meaningful way.


(-1 on Discord by the way, the preferred way for me is mailing lists that are archived, searchable and public ….  much like the LKML)

Thanks,
Alan



> On 15 Sep 2025, at 22:31, Peter Moore <pet...@gm...> wrote:
> 
> As a Fuse contributor (with unreleased changes), I’m really happy to see the new activity here!
> 
> I would propose creating a GitHub org called fuse-emulator. It doesn’t exist at time of writing! It can be created here: https://github.com/account/organizations/new?plan=free. I didn’t create it, because I feel like Philip or people in the existing support team should be the ones that own it or decide what names they are happy with etc, and if they are happy to relocate from soureforge to GitHub.
> 
> Then the various repos will appear underneath github.com/fuse-emulator which seems perfect (to me).
> 
> There are a few user forks of fuse already on GitHub, but I feel like an official org is the way to go for the canonical source. It isn’t possible to use the org name “fuse” because a user called fuse already exists. “fuse-emulator" feels like a good alternative (and is similar to e.g. ubuntu package name).
> 
> Discord sounds like a great choice too - this could be easily documented and linked from GitHub. Discussions and Wiki can also be enabled in GitHub repos which is another way to bolster engagement.
> 
> This feels like it could be an exciting turning point! :-)
> 
> Pete
> 
> 
>> On 15. Sep 2025, at 14:09, Joerg Pleumann <joe...@gm...> wrote:
>> 
>> +1 for GitHub
>> 
>> And may I suggest a Discord for the communication? I have found that a very effective means of community building and information exchange in several other projects. I’m willing to set it up (not that it’s very complicated) and might even have a spare Nitro boost from my monthly subscription.
>> 
>>> Am 15.09.2025 um 13:56 schrieb Alan Pearson <ala...@gm... <mailto:ala...@gm...>>:
>>> 
>>> Hi Everyone,
>>> 
>>> Chipping in on this thread.
>>> Thanks Joerg for raising this, and thanks Philip for coming back.
>>> I think a lot of users have been waiting a long time for a new release, myself included.
>>> 
>>> I completely get you’re at a different life stage now, and we all move on, you’ve left one heck of a legacy that make many people happy.
>>> I’d come back on one of your comments if I may, the use case of fuse.  I think it’s well past playing Manic Miner (there are so many other ways to do that today, including a web browser), and for me, the use case of fuse is Spectrum/Z80 tinkering and development. 
>>>  I use FUSE because of the extensive hardware emulation (particularly +D/Disciple & the 128k models), and have spent many happy hours doing things such as converting games to load from disk, to messing around with crazy things like learning all about the differences between the FDC in the +3 and +D.
>>> FUSE has a lot of abilities, some could be built upon to make it even better (remote control debugging / execution, hooking it into Spectrum Analyser for example).
>>> 
>>> On the Mac build.. some years ago, with the help of this list I got it to build on both Intel and Apple Silicon (after some serious efforts getting the dependencies right), but alas it crashed opening the first window. On investigation this was due to a change in more recent versions of Mac OS where it was doing something that apple have now termed illegal. For the life of me, I can’t remember what it was.
>>> Maybe I’ll try again and report the error here so someone could help
>>> 
>>> Philip I hope you can either become active again (supporting patches, releasing builds, and please, please, please move to GitHub !) or find someone to take on those tasks.
>>> 
>>> Please don’t let FUSE wither, it’s such a great tool, with so many uses.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Thank you from a very grateful user.
>>> 
>>> Alan
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 15 Sep 2025, at 12:24, Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
>>>> 
>>>> Hi Phil,
>>>> 
>>>> thanks a lot for the response — and for all the hard work and dedication that went into Fuse since it was conceived in 1999. Apart from CSpect, which I use for Next-specific stuff, Fuse has been my favorite 48K/128K emulator for a long time now, especially due to the fact that it’s available on so many platforms.
>>>> 
>>>> I agree Fuse is quite mature, but, as you mentioned, platforms move on and software may have to adapt from time to time in order not not become obsolete. I’m not sure how much assistance I could provide here, but I’m definitely willing to test and provide feedback. I regularly use Intel and Arm Macs as well as Ubuntu machines.
>>>> 
>>>> I already tried to build the latest Mac version, with the intention of getting a bit of understanding of the code base and maybe solving my little issues locally, then provide a patch, but so far I even failed to checkout. Is there a chance you establish contact with Frederick Meunier, so I can ask him a few questions?
>>>> 
>>>> Best regards
>>>> Joerg
>>>> 
>>>>> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh... <mailto:ph...@sh...>>:
>>>>> 
>>>>> > Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>>>>> 
>>>>> [ Wakes up from slumber ]
>>>>> 
>>>>> I'd say both. Certainly from my point of view, I'm at a very different stage of my life than I was in 1999 when the project started and I'm pretty sure that will apply to a number of the other "core" developers as well.
>>>>> 
>>>>> But I'd also agree that the project - and in fact, the software Spectrum emulation scene in general - has reached maturity; you can see this in that the rate of development of all the other major emulators has pretty stopped as well - because they do everything that 99% of users want to do, which is to play Manic Miner. The notable exception here is Spectrum Next emulation, but that is _such_ a different machine even if it uses a "CPU" which is a superset of the Z80.
>>>>> 
>>>>> With regards to the macOS version in particular, we always had a single point of success of the one developer who owned a Mac; I'm not aware of anyone even vaguely active who is trying to make new macOS builds - and as you note, the evolution of the Apple hardware ecosystem means there's probably a lot of catching up to do.
>>>>> 
>>>>> Please nobody let me be a blocker to getting things done with the project - I'm happy to talk about what privileges someone would need to get new releases out if there's someone who is genuinely interested in doing so.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Phil
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
>>>>>> Hi Alberto,
>>>>>> 
>>>>>> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>>>>>> 
>>>>>> I am using Fuse as emulator in a multi-platform Z80 compiler environment I’ve been developing for a while now. I have a couple of issues, including a bigger one with multi-line debugger commands fed into Fuse via the command line. In the meantime, I’ve been able to solve the latter, but would still prefer a more „solid“ solution. From the back of my head, here’s my full list of issues/questions:
>>>>>> 
>>>>>> 1) Could there be an alternative --debugger-command-file that points to a file containing the debugger commands? If there are many and complex breakpoints the command line gets extremely long, and those newlines scare me a lot when pushing everything though my tools and a shell process until it arrives in Fuse.
>>>>>> 
>>>>>> 2) As an alternative idea to 1): The CSpect emulator uses certain invalid opcodes (such as $dd $01) as breakpoints. That means the opcodes would be part of the program itself and not have to be specified on the command line. Is that something you could consider?
>>>>>> 
>>>>>> 3) Could the default behavior for 128K .sna files be changed? Currently the system interprets them as Pentagon snapshots, does not find the ROMs (I am not interested in Pentagon) and „crashes“ into a 48K machine. I understand this is possibly a „historical decision“, but in my opinion there’s nothing inherently Pentagon about the format. Would something like this work: If the Pentagon ROMs are not there and/or the user specified —machine 128 on the command line, treat this as a 128K snapshot, not as Pentagon? Or simply a checkbox in the preferences?
>>>>>> 
>>>>>> 4) Could there be a „step over“ button in the debugger UI that basically does what „n“ does in the debugger commands (as a convenience)?
>>>>>> 
>>>>>> 5) Last but not least, the Mac version seems to be a bit behind the latest upstream (and have some bugs of its own). Not sure if the main Mac developer is on this list, but is there a chance for an update? I’m very much willing to provide feedback for Intel and Arm Macs. I could also try building either locally, but I probably won’t be much help with the actual development because I don’t know the codebase.
>>>>>> 
>>>>>> Best regards
>>>>>> Joerg
>>>>>> 
>>>>>> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig... <mailto:be...@ig...>>:
>>>>>> > 
>>>>>> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>>>>>> >> sorry for using the developer list for this question, but since all
>>>>>> >> the other places (especially the SourceForge project for Mac Fuse,
>>>>>> >> which is the flavor I am using) are so inactive, I was wondering
>>>>>> >> if the project might have moved elsewhere. Is there a Discord or
>>>>>> >> another place where one might ask questions, or are things really as
>>>>>> >> inactive as they seem?
>>>>>> > 
>>>>>> > You can ask questions here, I guess, but the project is certainly
>>>>>> > stalled at the moment...
>>>>>> > 
>>>>>> > Berto
>>>>>> > 
>>>>>> > 
>>>>>> > _______________________________________________
>>>>>> > fuse-emulator-devel mailing list
>>>>>> > fus...@li... <mailto:fus...@li...>
>>>>>> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> fuse-emulator-devel mailing list
>>>>>> fus...@li... <mailto:fus...@li...>
>>>>>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>>> 
>>>> _______________________________________________
>>>> fuse-emulator-devel mailing list
>>>> fus...@li... <mailto:fus...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>> 
>> 
>> _______________________________________________
>> fuse-emulator-devel mailing list
>> fus...@li...
>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
> 

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Joerg P. <joe...@gm...>]

Thanks for digging this up! At least now I know where it comes from.

I am not an expert when it comes to clones, but to me there’s nothing particularly Pentagon-ish in the file format itself. It covers the 128K extended RAM and Beta disk / TR-DOS, which, I think, you could have used with any machine.

It came up because my compiler generates .sna files as one possible (and convenient) target format. Some emulators handle the 128K ones correctly (or maybe I should say „as expected“), but Fuse insists on running them in Pentagon mode.

Best regards
Joerg

> Am 16.09.2025 um 11:19 schrieb Alberto Garcia <be...@ig...>:
> 
> On Mon, Sep 15, 2025 at 09:15:37AM +0200, Joerg Pleumann wrote:
> 
>> 3) Could the default behavior for 128K .sna files be
>> changed? Currently the system interprets them as Pentagon snapshots,
> 
> I didn't even know that this was a thing, but I just checked and
> here's the reason why that happens:
> 
> https://sourceforge.net/p/fuse-emulator/bugs/150/
> 
> Berto
> 
> 
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Alberto G. <be...@ig...>]

On Mon, Sep 15, 2025 at 09:15:37AM +0200, Joerg Pleumann wrote:

> 3) Could the default behavior for 128K .sna files be
> changed? Currently the system interprets them as Pentagon snapshots,

I didn't even know that this was a thing, but I just checked and
here's the reason why that happens:

https://sourceforge.net/p/fuse-emulator/bugs/150/

Berto

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Peter M. <pet...@gm...>]

As a Fuse contributor (with unreleased changes), I’m really happy to see the new activity here!

I would propose creating a GitHub org called fuse-emulator. It doesn’t exist at time of writing! It can be created here: https://github.com/account/organizations/new?plan=free. I didn’t create it, because I feel like Philip or people in the existing support team should be the ones that own it or decide what names they are happy with etc, and if they are happy to relocate from soureforge to GitHub.

Then the various repos will appear underneath github.com/fuse-emulator which seems perfect (to me).

There are a few user forks of fuse already on GitHub, but I feel like an official org is the way to go for the canonical source. It isn’t possible to use the org name “fuse” because a user called fuse already exists. “fuse-emulator" feels like a good alternative (and is similar to e.g. ubuntu package name).

Discord sounds like a great choice too - this could be easily documented and linked from GitHub. Discussions and Wiki can also be enabled in GitHub repos which is another way to bolster engagement.

This feels like it could be an exciting turning point! :-)

Pete


> On 15. Sep 2025, at 14:09, Joerg Pleumann <joe...@gm...> wrote:
> 
> +1 for GitHub
> 
> And may I suggest a Discord for the communication? I have found that a very effective means of community building and information exchange in several other projects. I’m willing to set it up (not that it’s very complicated) and might even have a spare Nitro boost from my monthly subscription.
> 
>> Am 15.09.2025 um 13:56 schrieb Alan Pearson <ala...@gm... <mailto:ala...@gm...>>:
>> 
>> Hi Everyone,
>> 
>> Chipping in on this thread.
>> Thanks Joerg for raising this, and thanks Philip for coming back.
>> I think a lot of users have been waiting a long time for a new release, myself included.
>> 
>> I completely get you’re at a different life stage now, and we all move on, you’ve left one heck of a legacy that make many people happy.
>> I’d come back on one of your comments if I may, the use case of fuse.  I think it’s well past playing Manic Miner (there are so many other ways to do that today, including a web browser), and for me, the use case of fuse is Spectrum/Z80 tinkering and development. 
>>  I use FUSE because of the extensive hardware emulation (particularly +D/Disciple & the 128k models), and have spent many happy hours doing things such as converting games to load from disk, to messing around with crazy things like learning all about the differences between the FDC in the +3 and +D.
>> FUSE has a lot of abilities, some could be built upon to make it even better (remote control debugging / execution, hooking it into Spectrum Analyser for example).
>> 
>> On the Mac build.. some years ago, with the help of this list I got it to build on both Intel and Apple Silicon (after some serious efforts getting the dependencies right), but alas it crashed opening the first window. On investigation this was due to a change in more recent versions of Mac OS where it was doing something that apple have now termed illegal. For the life of me, I can’t remember what it was.
>> Maybe I’ll try again and report the error here so someone could help
>> 
>> Philip I hope you can either become active again (supporting patches, releasing builds, and please, please, please move to GitHub !) or find someone to take on those tasks.
>> 
>> Please don’t let FUSE wither, it’s such a great tool, with so many uses.
>> 
>> 
>> 
>> 
>> 
>> Thank you from a very grateful user.
>> 
>> Alan
>> 
>> 
>> 
>> 
>> 
>>> On 15 Sep 2025, at 12:24, Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
>>> 
>>> Hi Phil,
>>> 
>>> thanks a lot for the response — and for all the hard work and dedication that went into Fuse since it was conceived in 1999. Apart from CSpect, which I use for Next-specific stuff, Fuse has been my favorite 48K/128K emulator for a long time now, especially due to the fact that it’s available on so many platforms.
>>> 
>>> I agree Fuse is quite mature, but, as you mentioned, platforms move on and software may have to adapt from time to time in order not not become obsolete. I’m not sure how much assistance I could provide here, but I’m definitely willing to test and provide feedback. I regularly use Intel and Arm Macs as well as Ubuntu machines.
>>> 
>>> I already tried to build the latest Mac version, with the intention of getting a bit of understanding of the code base and maybe solving my little issues locally, then provide a patch, but so far I even failed to checkout. Is there a chance you establish contact with Frederick Meunier, so I can ask him a few questions?
>>> 
>>> Best regards
>>> Joerg
>>> 
>>>> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh... <mailto:ph...@sh...>>:
>>>> 
>>>> > Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>>>> 
>>>> [ Wakes up from slumber ]
>>>> 
>>>> I'd say both. Certainly from my point of view, I'm at a very different stage of my life than I was in 1999 when the project started and I'm pretty sure that will apply to a number of the other "core" developers as well.
>>>> 
>>>> But I'd also agree that the project - and in fact, the software Spectrum emulation scene in general - has reached maturity; you can see this in that the rate of development of all the other major emulators has pretty stopped as well - because they do everything that 99% of users want to do, which is to play Manic Miner. The notable exception here is Spectrum Next emulation, but that is _such_ a different machine even if it uses a "CPU" which is a superset of the Z80.
>>>> 
>>>> With regards to the macOS version in particular, we always had a single point of success of the one developer who owned a Mac; I'm not aware of anyone even vaguely active who is trying to make new macOS builds - and as you note, the evolution of the Apple hardware ecosystem means there's probably a lot of catching up to do.
>>>> 
>>>> Please nobody let me be a blocker to getting things done with the project - I'm happy to talk about what privileges someone would need to get new releases out if there's someone who is genuinely interested in doing so.
>>>> 
>>>> Thanks,
>>>> 
>>>> Phil
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
>>>>> Hi Alberto,
>>>>> 
>>>>> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>>>>> 
>>>>> I am using Fuse as emulator in a multi-platform Z80 compiler environment I’ve been developing for a while now. I have a couple of issues, including a bigger one with multi-line debugger commands fed into Fuse via the command line. In the meantime, I’ve been able to solve the latter, but would still prefer a more „solid“ solution. From the back of my head, here’s my full list of issues/questions:
>>>>> 
>>>>> 1) Could there be an alternative --debugger-command-file that points to a file containing the debugger commands? If there are many and complex breakpoints the command line gets extremely long, and those newlines scare me a lot when pushing everything though my tools and a shell process until it arrives in Fuse.
>>>>> 
>>>>> 2) As an alternative idea to 1): The CSpect emulator uses certain invalid opcodes (such as $dd $01) as breakpoints. That means the opcodes would be part of the program itself and not have to be specified on the command line. Is that something you could consider?
>>>>> 
>>>>> 3) Could the default behavior for 128K .sna files be changed? Currently the system interprets them as Pentagon snapshots, does not find the ROMs (I am not interested in Pentagon) and „crashes“ into a 48K machine. I understand this is possibly a „historical decision“, but in my opinion there’s nothing inherently Pentagon about the format. Would something like this work: If the Pentagon ROMs are not there and/or the user specified —machine 128 on the command line, treat this as a 128K snapshot, not as Pentagon? Or simply a checkbox in the preferences?
>>>>> 
>>>>> 4) Could there be a „step over“ button in the debugger UI that basically does what „n“ does in the debugger commands (as a convenience)?
>>>>> 
>>>>> 5) Last but not least, the Mac version seems to be a bit behind the latest upstream (and have some bugs of its own). Not sure if the main Mac developer is on this list, but is there a chance for an update? I’m very much willing to provide feedback for Intel and Arm Macs. I could also try building either locally, but I probably won’t be much help with the actual development because I don’t know the codebase.
>>>>> 
>>>>> Best regards
>>>>> Joerg
>>>>> 
>>>>> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig... <mailto:be...@ig...>>:
>>>>> > 
>>>>> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>>>>> >> sorry for using the developer list for this question, but since all
>>>>> >> the other places (especially the SourceForge project for Mac Fuse,
>>>>> >> which is the flavor I am using) are so inactive, I was wondering
>>>>> >> if the project might have moved elsewhere. Is there a Discord or
>>>>> >> another place where one might ask questions, or are things really as
>>>>> >> inactive as they seem?
>>>>> > 
>>>>> > You can ask questions here, I guess, but the project is certainly
>>>>> > stalled at the moment...
>>>>> > 
>>>>> > Berto
>>>>> > 
>>>>> > 
>>>>> > _______________________________________________
>>>>> > fuse-emulator-devel mailing list
>>>>> > fus...@li... <mailto:fus...@li...>
>>>>> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> fuse-emulator-devel mailing list
>>>>> fus...@li... <mailto:fus...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>> 
>>> _______________________________________________
>>> fuse-emulator-devel mailing list
>>> fus...@li... <mailto:fus...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>> 
> 
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Alistair <ali...@zx...>]

On 15/09/2025 13:09, Joerg Pleumann wrote:
> +1 for GitHub
> 
> And may I suggest a Discord for the communication? I have found that a 
> very effective means of community building and information exchange in 
> several other projects. I’m willing to set it up (not that it’s very 
> complicated) and might even have a spare Nitro boost from my monthly 
> subscription.
> 

Anything less crusty than sourceforge would be great for the actual 
source control, but moving away entirely would break the continuity of 
the mailing lists and so on.

That brings me on to the second thing I want to say which is -1 for a 
fuse Discord!

Chatting about emulator dev in an irc or discord channel is a great way 
to get things done, but official project discords have a horrible habit 
of being the only point of contact, and swallowing up everything else.

I can read this mailing list archive all the way back to 2003 - will 
discord posts be as accessible two decades from now?
(well already they are less accessible, since anyone can read the list 
archives without a sourceforge account)

Alistair.

p.s. I'll chuck in a "me too" to a new release. There's been a bunch of 
fixes that it would be great to get out since 1.6.0. Something about a 
perfect 1.7.0 being the enemy of a good point release or something heh

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[desertkun <des...@gm...>]

Let's meet here https://discord.gg/8Bbx3Vrc this is a popular ZX Spectrum
server

On Mon, Sep 15, 2025, 14:31 Joerg Pleumann <joe...@gm...> wrote:

> I just gave it a quick try. It has trouble with the way I am invoking the
> application (via open -a FuseX.app --args ...), probably due to a missing
> permission request for the file system („Operation not permitted“). The
> original, older Fuse for Mac did not have this. I’ll create a ticket in
> your GitHub project. Normal operation is fine, including loading things via
> the open file dialog.
>
> Am 15.09.2025 um 13:31 schrieb desertkun <des...@gm...>:
>
> Hello. I've been semi-maintaining a fork of Fuse called FuseX on
> speccytools.org
>
> It has gdbserver stub built in, so you can connect to it with with
> z88dk-gdb and do things like inspect memory, place breakpoints, observe
> stack, and if your debugger supports (z88dk-gdb does, but it must be built
> by z88dk), show source code mapping to that. I believe this should work
> with z80-binutils, however I have not tested that.
>
> You enable gdbserver in settings and connect with your gdb of choice, of
> which z88dk-gdb is the only one really tested.
>
> On Mon, Sep 15, 2025, 13:25 Joerg Pleumann <joe...@gm...>
> wrote:
>
>> Hi Phil,
>>
>> thanks a lot for the response — and for all the hard work and dedication
>> that went into Fuse since it was conceived in 1999. Apart from CSpect,
>> which I use for Next-specific stuff, Fuse has been my favorite 48K/128K
>> emulator for a long time now, especially due to the fact that it’s
>> available on so many platforms.
>>
>> I agree Fuse is quite mature, but, as you mentioned, platforms move on
>> and software may have to adapt from time to time in order not not become
>> obsolete. I’m not sure how much assistance I could provide here, but I’m
>> definitely willing to test and provide feedback. I regularly use Intel and
>> Arm Macs as well as Ubuntu machines.
>>
>> I already tried to build the latest Mac version, with the intention of
>> getting a bit of understanding of the code base and maybe solving my little
>> issues locally, then provide a patch, but so far I even failed to checkout.
>> Is there a chance you establish contact with Frederick Meunier, so I can
>> ask him a few questions?
>>
>> Best regards
>> Joerg
>>
>> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh...
>> >:
>>
>> > Did everybody move on to other things or is it because the project is
>> so mature (almost) no changes are needed? :)
>>
>> [ Wakes up from slumber ]
>>
>> I'd say both. Certainly from my point of view, I'm at a very different
>> stage of my life than I was in 1999 when the project started and I'm pretty
>> sure that will apply to a number of the other "core" developers as well.
>>
>> But I'd also agree that the project - and in fact, the software Spectrum
>> emulation scene in general - has reached maturity; you can see this in that
>> the rate of development of all the other major emulators has pretty stopped
>> as well - because they do everything that 99% of users want to do, which is
>> to play Manic Miner. The notable exception here is Spectrum Next emulation,
>> but that is _such_ a different machine even if it uses a "CPU" which is a
>> superset of the Z80.
>>
>> With regards to the macOS version in particular, we always had a single
>> point of success of the one developer who owned a Mac; I'm not aware of
>> anyone even vaguely active who is trying to make new macOS builds - and as
>> you note, the evolution of the Apple hardware ecosystem means there's
>> probably a lot of catching up to do.
>>
>> Please nobody let me be a blocker to getting things done with the project
>> - I'm happy to talk about what privileges someone would need to get new
>> releases out if there's someone who is genuinely interested in doing so.
>>
>> Thanks,
>>
>> Phil
>>
>>
>>
>>
>>
>> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm...>
>> wrote:
>>
>>> Hi Alberto,
>>>
>>> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to
>>> other things or is it because the project is so mature (almost) no changes
>>> are needed? :)
>>>
>>> I am using Fuse as emulator in a multi-platform Z80 compiler environment
>>> I’ve been developing for a while now. I have a couple of issues, including
>>> a bigger one with multi-line debugger commands fed into Fuse via the
>>> command line. In the meantime, I’ve been able to solve the latter, but
>>> would still prefer a more „solid“ solution. From the back of my head,
>>> here’s my full list of issues/questions:
>>>
>>> 1) Could there be an alternative --debugger-command-file that points to
>>> a file containing the debugger commands? If there are many and complex
>>> breakpoints the command line gets extremely long, and those newlines scare
>>> me a lot when pushing everything though my tools and a shell process until
>>> it arrives in Fuse.
>>>
>>> 2) As an alternative idea to 1): The CSpect emulator uses certain
>>> invalid opcodes (such as $dd $01) as breakpoints. That means the opcodes
>>> would be part of the program itself and not have to be specified on the
>>> command line. Is that something you could consider?
>>>
>>> 3) Could the default behavior for 128K .sna files be changed? Currently
>>> the system interprets them as Pentagon snapshots, does not find the ROMs (I
>>> am not interested in Pentagon) and „crashes“ into a 48K machine. I
>>> understand this is possibly a „historical decision“, but in my opinion
>>> there’s nothing inherently Pentagon about the format. Would something like
>>> this work: If the Pentagon ROMs are not there and/or the user specified
>>> —machine 128 on the command line, treat this as a 128K snapshot, not as
>>> Pentagon? Or simply a checkbox in the preferences?
>>>
>>> 4) Could there be a „step over“ button in the debugger UI that basically
>>> does what „n“ does in the debugger commands (as a convenience)?
>>>
>>> 5) Last but not least, the Mac version seems to be a bit behind the
>>> latest upstream (and have some bugs of its own). Not sure if the main Mac
>>> developer is on this list, but is there a chance for an update? I’m very
>>> much willing to provide feedback for Intel and Arm Macs. I could also try
>>> building either locally, but I probably won’t be much help with the actual
>>> development because I don’t know the codebase.
>>>
>>> Best regards
>>> Joerg
>>>
>>> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig...>:
>>> >
>>> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>>> >> sorry for using the developer list for this question, but since all
>>> >> the other places (especially the SourceForge project for Mac Fuse,
>>> >> which is the flavor I am using) are so inactive, I was wondering
>>> >> if the project might have moved elsewhere. Is there a Discord or
>>> >> another place where one might ask questions, or are things really as
>>> >> inactive as they seem?
>>> >
>>> > You can ask questions here, I guess, but the project is certainly
>>> > stalled at the moment...
>>> >
>>> > Berto
>>> >
>>> >
>>> > _______________________________________________
>>> > fuse-emulator-devel mailing list
>>> > fus...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> fuse-emulator-devel mailing list
>>> fus...@li...
>>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>>
>>
>> _______________________________________________
>> fuse-emulator-devel mailing list
>> fus...@li...
>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>
>
>

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Joerg P. <joe...@gm...>]

I just gave it a quick try. It has trouble with the way I am invoking the application (via open -a FuseX.app --args ...), probably due to a missing permission request for the file system („Operation not permitted“). The original, older Fuse for Mac did not have this. I’ll create a ticket in your GitHub project. Normal operation is fine, including loading things via the open file dialog.

> Am 15.09.2025 um 13:31 schrieb desertkun <des...@gm...>:
> 
> Hello. I've been semi-maintaining a fork of Fuse called FuseX on speccytools.org <http://speccytools.org/>
> 
> It has gdbserver stub built in, so you can connect to it with with z88dk-gdb and do things like inspect memory, place breakpoints, observe stack, and if your debugger supports (z88dk-gdb does, but it must be built by z88dk), show source code mapping to that. I believe this should work with z80-binutils, however I have not tested that.
> 
> You enable gdbserver in settings and connect with your gdb of choice, of which z88dk-gdb is the only one really tested. 
> 
> On Mon, Sep 15, 2025, 13:25 Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
> Hi Phil,
> 
> thanks a lot for the response — and for all the hard work and dedication that went into Fuse since it was conceived in 1999. Apart from CSpect, which I use for Next-specific stuff, Fuse has been my favorite 48K/128K emulator for a long time now, especially due to the fact that it’s available on so many platforms.
> 
> I agree Fuse is quite mature, but, as you mentioned, platforms move on and software may have to adapt from time to time in order not not become obsolete. I’m not sure how much assistance I could provide here, but I’m definitely willing to test and provide feedback. I regularly use Intel and Arm Macs as well as Ubuntu machines.
> 
> I already tried to build the latest Mac version, with the intention of getting a bit of understanding of the code base and maybe solving my little issues locally, then provide a patch, but so far I even failed to checkout. Is there a chance you establish contact with Frederick Meunier, so I can ask him a few questions?
> 
> Best regards
> Joerg
> 
>> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh... <mailto:ph...@sh...>>:
>> 
>> > Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>> 
>> [ Wakes up from slumber ]
>> 
>> I'd say both. Certainly from my point of view, I'm at a very different stage of my life than I was in 1999 when the project started and I'm pretty sure that will apply to a number of the other "core" developers as well.
>> 
>> But I'd also agree that the project - and in fact, the software Spectrum emulation scene in general - has reached maturity; you can see this in that the rate of development of all the other major emulators has pretty stopped as well - because they do everything that 99% of users want to do, which is to play Manic Miner. The notable exception here is Spectrum Next emulation, but that is _such_ a different machine even if it uses a "CPU" which is a superset of the Z80.
>> 
>> With regards to the macOS version in particular, we always had a single point of success of the one developer who owned a Mac; I'm not aware of anyone even vaguely active who is trying to make new macOS builds - and as you note, the evolution of the Apple hardware ecosystem means there's probably a lot of catching up to do.
>> 
>> Please nobody let me be a blocker to getting things done with the project - I'm happy to talk about what privileges someone would need to get new releases out if there's someone who is genuinely interested in doing so.
>> 
>> Thanks,
>> 
>> Phil
>> 
>> 
>> 
>> 
>> 
>> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
>> Hi Alberto,
>> 
>> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>> 
>> I am using Fuse as emulator in a multi-platform Z80 compiler environment I’ve been developing for a while now. I have a couple of issues, including a bigger one with multi-line debugger commands fed into Fuse via the command line. In the meantime, I’ve been able to solve the latter, but would still prefer a more „solid“ solution. From the back of my head, here’s my full list of issues/questions:
>> 
>> 1) Could there be an alternative --debugger-command-file that points to a file containing the debugger commands? If there are many and complex breakpoints the command line gets extremely long, and those newlines scare me a lot when pushing everything though my tools and a shell process until it arrives in Fuse.
>> 
>> 2) As an alternative idea to 1): The CSpect emulator uses certain invalid opcodes (such as $dd $01) as breakpoints. That means the opcodes would be part of the program itself and not have to be specified on the command line. Is that something you could consider?
>> 
>> 3) Could the default behavior for 128K .sna files be changed? Currently the system interprets them as Pentagon snapshots, does not find the ROMs (I am not interested in Pentagon) and „crashes“ into a 48K machine. I understand this is possibly a „historical decision“, but in my opinion there’s nothing inherently Pentagon about the format. Would something like this work: If the Pentagon ROMs are not there and/or the user specified —machine 128 on the command line, treat this as a 128K snapshot, not as Pentagon? Or simply a checkbox in the preferences?
>> 
>> 4) Could there be a „step over“ button in the debugger UI that basically does what „n“ does in the debugger commands (as a convenience)?
>> 
>> 5) Last but not least, the Mac version seems to be a bit behind the latest upstream (and have some bugs of its own). Not sure if the main Mac developer is on this list, but is there a chance for an update? I’m very much willing to provide feedback for Intel and Arm Macs. I could also try building either locally, but I probably won’t be much help with the actual development because I don’t know the codebase.
>> 
>> Best regards
>> Joerg
>> 
>> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig... <mailto:be...@ig...>>:
>> > 
>> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>> >> sorry for using the developer list for this question, but since all
>> >> the other places (especially the SourceForge project for Mac Fuse,
>> >> which is the flavor I am using) are so inactive, I was wondering
>> >> if the project might have moved elsewhere. Is there a Discord or
>> >> another place where one might ask questions, or are things really as
>> >> inactive as they seem?
>> > 
>> > You can ask questions here, I guess, but the project is certainly
>> > stalled at the moment...
>> > 
>> > Berto
>> > 
>> > 
>> > _______________________________________________
>> > fuse-emulator-devel mailing list
>> > fus...@li... <mailto:fus...@li...>
>> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel <https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel>
>> 
>> 
>> 
>> _______________________________________________
>> fuse-emulator-devel mailing list
>> fus...@li... <mailto:fus...@li...>
>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel <https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel>
> 
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li... <mailto:fus...@li...>
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel <https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel>

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Joerg P. <joe...@gm...>]

+1 for GitHub

And may I suggest a Discord for the communication? I have found that a very effective means of community building and information exchange in several other projects. I’m willing to set it up (not that it’s very complicated) and might even have a spare Nitro boost from my monthly subscription.

> Am 15.09.2025 um 13:56 schrieb Alan Pearson <ala...@gm...>:
> 
> Hi Everyone,
> 
> Chipping in on this thread.
> Thanks Joerg for raising this, and thanks Philip for coming back.
> I think a lot of users have been waiting a long time for a new release, myself included.
> 
> I completely get you’re at a different life stage now, and we all move on, you’ve left one heck of a legacy that make many people happy.
> I’d come back on one of your comments if I may, the use case of fuse.  I think it’s well past playing Manic Miner (there are so many other ways to do that today, including a web browser), and for me, the use case of fuse is Spectrum/Z80 tinkering and development. 
>  I use FUSE because of the extensive hardware emulation (particularly +D/Disciple & the 128k models), and have spent many happy hours doing things such as converting games to load from disk, to messing around with crazy things like learning all about the differences between the FDC in the +3 and +D.
> FUSE has a lot of abilities, some could be built upon to make it even better (remote control debugging / execution, hooking it into Spectrum Analyser for example).
> 
> On the Mac build.. some years ago, with the help of this list I got it to build on both Intel and Apple Silicon (after some serious efforts getting the dependencies right), but alas it crashed opening the first window. On investigation this was due to a change in more recent versions of Mac OS where it was doing something that apple have now termed illegal. For the life of me, I can’t remember what it was.
> Maybe I’ll try again and report the error here so someone could help
> 
> Philip I hope you can either become active again (supporting patches, releasing builds, and please, please, please move to GitHub !) or find someone to take on those tasks.
> 
> Please don’t let FUSE wither, it’s such a great tool, with so many uses.
> 
> 
> 
> 
> 
> Thank you from a very grateful user.
> 
> Alan
> 
> 
> 
> 
> 
>> On 15 Sep 2025, at 12:24, Joerg Pleumann <joe...@gm...> wrote:
>> 
>> Hi Phil,
>> 
>> thanks a lot for the response — and for all the hard work and dedication that went into Fuse since it was conceived in 1999. Apart from CSpect, which I use for Next-specific stuff, Fuse has been my favorite 48K/128K emulator for a long time now, especially due to the fact that it’s available on so many platforms.
>> 
>> I agree Fuse is quite mature, but, as you mentioned, platforms move on and software may have to adapt from time to time in order not not become obsolete. I’m not sure how much assistance I could provide here, but I’m definitely willing to test and provide feedback. I regularly use Intel and Arm Macs as well as Ubuntu machines.
>> 
>> I already tried to build the latest Mac version, with the intention of getting a bit of understanding of the code base and maybe solving my little issues locally, then provide a patch, but so far I even failed to checkout. Is there a chance you establish contact with Frederick Meunier, so I can ask him a few questions?
>> 
>> Best regards
>> Joerg
>> 
>>> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh... <mailto:ph...@sh...>>:
>>> 
>>> > Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>>> 
>>> [ Wakes up from slumber ]
>>> 
>>> I'd say both. Certainly from my point of view, I'm at a very different stage of my life than I was in 1999 when the project started and I'm pretty sure that will apply to a number of the other "core" developers as well.
>>> 
>>> But I'd also agree that the project - and in fact, the software Spectrum emulation scene in general - has reached maturity; you can see this in that the rate of development of all the other major emulators has pretty stopped as well - because they do everything that 99% of users want to do, which is to play Manic Miner. The notable exception here is Spectrum Next emulation, but that is _such_ a different machine even if it uses a "CPU" which is a superset of the Z80.
>>> 
>>> With regards to the macOS version in particular, we always had a single point of success of the one developer who owned a Mac; I'm not aware of anyone even vaguely active who is trying to make new macOS builds - and as you note, the evolution of the Apple hardware ecosystem means there's probably a lot of catching up to do.
>>> 
>>> Please nobody let me be a blocker to getting things done with the project - I'm happy to talk about what privileges someone would need to get new releases out if there's someone who is genuinely interested in doing so.
>>> 
>>> Thanks,
>>> 
>>> Phil
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
>>> Hi Alberto,
>>> 
>>> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>>> 
>>> I am using Fuse as emulator in a multi-platform Z80 compiler environment I’ve been developing for a while now. I have a couple of issues, including a bigger one with multi-line debugger commands fed into Fuse via the command line. In the meantime, I’ve been able to solve the latter, but would still prefer a more „solid“ solution. From the back of my head, here’s my full list of issues/questions:
>>> 
>>> 1) Could there be an alternative --debugger-command-file that points to a file containing the debugger commands? If there are many and complex breakpoints the command line gets extremely long, and those newlines scare me a lot when pushing everything though my tools and a shell process until it arrives in Fuse.
>>> 
>>> 2) As an alternative idea to 1): The CSpect emulator uses certain invalid opcodes (such as $dd $01) as breakpoints. That means the opcodes would be part of the program itself and not have to be specified on the command line. Is that something you could consider?
>>> 
>>> 3) Could the default behavior for 128K .sna files be changed? Currently the system interprets them as Pentagon snapshots, does not find the ROMs (I am not interested in Pentagon) and „crashes“ into a 48K machine. I understand this is possibly a „historical decision“, but in my opinion there’s nothing inherently Pentagon about the format. Would something like this work: If the Pentagon ROMs are not there and/or the user specified —machine 128 on the command line, treat this as a 128K snapshot, not as Pentagon? Or simply a checkbox in the preferences?
>>> 
>>> 4) Could there be a „step over“ button in the debugger UI that basically does what „n“ does in the debugger commands (as a convenience)?
>>> 
>>> 5) Last but not least, the Mac version seems to be a bit behind the latest upstream (and have some bugs of its own). Not sure if the main Mac developer is on this list, but is there a chance for an update? I’m very much willing to provide feedback for Intel and Arm Macs. I could also try building either locally, but I probably won’t be much help with the actual development because I don’t know the codebase.
>>> 
>>> Best regards
>>> Joerg
>>> 
>>> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig... <mailto:be...@ig...>>:
>>> > 
>>> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>>> >> sorry for using the developer list for this question, but since all
>>> >> the other places (especially the SourceForge project for Mac Fuse,
>>> >> which is the flavor I am using) are so inactive, I was wondering
>>> >> if the project might have moved elsewhere. Is there a Discord or
>>> >> another place where one might ask questions, or are things really as
>>> >> inactive as they seem?
>>> > 
>>> > You can ask questions here, I guess, but the project is certainly
>>> > stalled at the moment...
>>> > 
>>> > Berto
>>> > 
>>> > 
>>> > _______________________________________________
>>> > fuse-emulator-devel mailing list
>>> > fus...@li... <mailto:fus...@li...>
>>> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel <https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> fuse-emulator-devel mailing list
>>> fus...@li... <mailto:fus...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel <https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel>
>> 
>> _______________________________________________
>> fuse-emulator-devel mailing list
>> fus...@li...
>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
> 

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Alan P. <ala...@gm...>]

<drops my tea>

Thanks you for FuseX.. especially the MacOS version, now on 1.6 codebase !
Philip, maybe asking a lot, but is there anyway you could link to this on the main FUSE webpage ?
I’m sure it would help many other users.




Alan


> On 15 Sep 2025, at 12:57, Joerg Pleumann <joe...@gm...> wrote:
> 
> Thanks for the link! That sounds interesting. I’ll have a look. Maybe it is something I can support. I don’t have my own debugger right now, though. What I have (https://github.com/pleumann/pasta80) is a clone of Turbo Pascal 3.0, with a similar UI, targeting Z80 machines. I rely on the debuggers present in the emulators. Everything is written in Pascal, not C/z88dk. I use the sjasmplus assembler for the final translation step from generated Z80 source code to binaries.
> 
>> Am 15.09.2025 um 13:31 schrieb desertkun <des...@gm... <mailto:des...@gm...>>:
>> 
>> Hello. I've been semi-maintaining a fork of Fuse called FuseX on speccytools.org <http://speccytools.org/>
>> 
>> It has gdbserver stub built in, so you can connect to it with with z88dk-gdb and do things like inspect memory, place breakpoints, observe stack, and if your debugger supports (z88dk-gdb does, but it must be built by z88dk), show source code mapping to that. I believe this should work with z80-binutils, however I have not tested that.
>> 
>> You enable gdbserver in settings and connect with your gdb of choice, of which z88dk-gdb is the only one really tested. 
>> 
>> On Mon, Sep 15, 2025, 13:25 Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
>>> Hi Phil,
>>> 
>>> thanks a lot for the response — and for all the hard work and dedication that went into Fuse since it was conceived in 1999. Apart from CSpect, which I use for Next-specific stuff, Fuse has been my favorite 48K/128K emulator for a long time now, especially due to the fact that it’s available on so many platforms.
>>> 
>>> I agree Fuse is quite mature, but, as you mentioned, platforms move on and software may have to adapt from time to time in order not not become obsolete. I’m not sure how much assistance I could provide here, but I’m definitely willing to test and provide feedback. I regularly use Intel and Arm Macs as well as Ubuntu machines.
>>> 
>>> I already tried to build the latest Mac version, with the intention of getting a bit of understanding of the code base and maybe solving my little issues locally, then provide a patch, but so far I even failed to checkout. Is there a chance you establish contact with Frederick Meunier, so I can ask him a few questions?
>>> 
>>> Best regards
>>> Joerg
>>> 
>>>> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh... <mailto:ph...@sh...>>:
>>>> 
>>>> > Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>>>> 
>>>> [ Wakes up from slumber ]
>>>> 
>>>> I'd say both. Certainly from my point of view, I'm at a very different stage of my life than I was in 1999 when the project started and I'm pretty sure that will apply to a number of the other "core" developers as well.
>>>> 
>>>> But I'd also agree that the project - and in fact, the software Spectrum emulation scene in general - has reached maturity; you can see this in that the rate of development of all the other major emulators has pretty stopped as well - because they do everything that 99% of users want to do, which is to play Manic Miner. The notable exception here is Spectrum Next emulation, but that is _such_ a different machine even if it uses a "CPU" which is a superset of the Z80.
>>>> 
>>>> With regards to the macOS version in particular, we always had a single point of success of the one developer who owned a Mac; I'm not aware of anyone even vaguely active who is trying to make new macOS builds - and as you note, the evolution of the Apple hardware ecosystem means there's probably a lot of catching up to do.
>>>> 
>>>> Please nobody let me be a blocker to getting things done with the project - I'm happy to talk about what privileges someone would need to get new releases out if there's someone who is genuinely interested in doing so.
>>>> 
>>>> Thanks,
>>>> 
>>>> Phil
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
>>>>> Hi Alberto,
>>>>> 
>>>>> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>>>>> 
>>>>> I am using Fuse as emulator in a multi-platform Z80 compiler environment I’ve been developing for a while now. I have a couple of issues, including a bigger one with multi-line debugger commands fed into Fuse via the command line. In the meantime, I’ve been able to solve the latter, but would still prefer a more „solid“ solution. From the back of my head, here’s my full list of issues/questions:
>>>>> 
>>>>> 1) Could there be an alternative --debugger-command-file that points to a file containing the debugger commands? If there are many and complex breakpoints the command line gets extremely long, and those newlines scare me a lot when pushing everything though my tools and a shell process until it arrives in Fuse.
>>>>> 
>>>>> 2) As an alternative idea to 1): The CSpect emulator uses certain invalid opcodes (such as $dd $01) as breakpoints. That means the opcodes would be part of the program itself and not have to be specified on the command line. Is that something you could consider?
>>>>> 
>>>>> 3) Could the default behavior for 128K .sna files be changed? Currently the system interprets them as Pentagon snapshots, does not find the ROMs (I am not interested in Pentagon) and „crashes“ into a 48K machine. I understand this is possibly a „historical decision“, but in my opinion there’s nothing inherently Pentagon about the format. Would something like this work: If the Pentagon ROMs are not there and/or the user specified —machine 128 on the command line, treat this as a 128K snapshot, not as Pentagon? Or simply a checkbox in the preferences?
>>>>> 
>>>>> 4) Could there be a „step over“ button in the debugger UI that basically does what „n“ does in the debugger commands (as a convenience)?
>>>>> 
>>>>> 5) Last but not least, the Mac version seems to be a bit behind the latest upstream (and have some bugs of its own). Not sure if the main Mac developer is on this list, but is there a chance for an update? I’m very much willing to provide feedback for Intel and Arm Macs. I could also try building either locally, but I probably won’t be much help with the actual development because I don’t know the codebase.
>>>>> 
>>>>> Best regards
>>>>> Joerg
>>>>> 
>>>>> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig... <mailto:be...@ig...>>:
>>>>> > 
>>>>> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>>>>> >> sorry for using the developer list for this question, but since all
>>>>> >> the other places (especially the SourceForge project for Mac Fuse,
>>>>> >> which is the flavor I am using) are so inactive, I was wondering
>>>>> >> if the project might have moved elsewhere. Is there a Discord or
>>>>> >> another place where one might ask questions, or are things really as
>>>>> >> inactive as they seem?
>>>>> > 
>>>>> > You can ask questions here, I guess, but the project is certainly
>>>>> > stalled at the moment...
>>>>> > 
>>>>> > Berto
>>>>> > 
>>>>> > 
>>>>> > _______________________________________________
>>>>> > fuse-emulator-devel mailing list
>>>>> > fus...@li... <mailto:fus...@li...>
>>>>> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> fuse-emulator-devel mailing list
>>>>> fus...@li... <mailto:fus...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>> 
>>> _______________________________________________
>>> fuse-emulator-devel mailing list
>>> fus...@li... <mailto:fus...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
> 
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Joerg P. <joe...@gm...>]

Thanks for the link! That sounds interesting. I’ll have a look. Maybe it is something I can support. I don’t have my own debugger right now, though. What I have (https://github.com/pleumann/pasta80 <https://github.com/pleumann/pasta80>) is a clone of Turbo Pascal 3.0, with a similar UI, targeting Z80 machines. I rely on the debuggers present in the emulators. Everything is written in Pascal, not C/z88dk. I use the sjasmplus assembler for the final translation step from generated Z80 source code to binaries.

> Am 15.09.2025 um 13:31 schrieb desertkun <des...@gm...>:
> 
> Hello. I've been semi-maintaining a fork of Fuse called FuseX on speccytools.org <http://speccytools.org/>
> 
> It has gdbserver stub built in, so you can connect to it with with z88dk-gdb and do things like inspect memory, place breakpoints, observe stack, and if your debugger supports (z88dk-gdb does, but it must be built by z88dk), show source code mapping to that. I believe this should work with z80-binutils, however I have not tested that.
> 
> You enable gdbserver in settings and connect with your gdb of choice, of which z88dk-gdb is the only one really tested. 
> 
> On Mon, Sep 15, 2025, 13:25 Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
> Hi Phil,
> 
> thanks a lot for the response — and for all the hard work and dedication that went into Fuse since it was conceived in 1999. Apart from CSpect, which I use for Next-specific stuff, Fuse has been my favorite 48K/128K emulator for a long time now, especially due to the fact that it’s available on so many platforms.
> 
> I agree Fuse is quite mature, but, as you mentioned, platforms move on and software may have to adapt from time to time in order not not become obsolete. I’m not sure how much assistance I could provide here, but I’m definitely willing to test and provide feedback. I regularly use Intel and Arm Macs as well as Ubuntu machines.
> 
> I already tried to build the latest Mac version, with the intention of getting a bit of understanding of the code base and maybe solving my little issues locally, then provide a patch, but so far I even failed to checkout. Is there a chance you establish contact with Frederick Meunier, so I can ask him a few questions?
> 
> Best regards
> Joerg
> 
>> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh... <mailto:ph...@sh...>>:
>> 
>> > Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>> 
>> [ Wakes up from slumber ]
>> 
>> I'd say both. Certainly from my point of view, I'm at a very different stage of my life than I was in 1999 when the project started and I'm pretty sure that will apply to a number of the other "core" developers as well.
>> 
>> But I'd also agree that the project - and in fact, the software Spectrum emulation scene in general - has reached maturity; you can see this in that the rate of development of all the other major emulators has pretty stopped as well - because they do everything that 99% of users want to do, which is to play Manic Miner. The notable exception here is Spectrum Next emulation, but that is _such_ a different machine even if it uses a "CPU" which is a superset of the Z80.
>> 
>> With regards to the macOS version in particular, we always had a single point of success of the one developer who owned a Mac; I'm not aware of anyone even vaguely active who is trying to make new macOS builds - and as you note, the evolution of the Apple hardware ecosystem means there's probably a lot of catching up to do.
>> 
>> Please nobody let me be a blocker to getting things done with the project - I'm happy to talk about what privileges someone would need to get new releases out if there's someone who is genuinely interested in doing so.
>> 
>> Thanks,
>> 
>> Phil
>> 
>> 
>> 
>> 
>> 
>> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
>> Hi Alberto,
>> 
>> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>> 
>> I am using Fuse as emulator in a multi-platform Z80 compiler environment I’ve been developing for a while now. I have a couple of issues, including a bigger one with multi-line debugger commands fed into Fuse via the command line. In the meantime, I’ve been able to solve the latter, but would still prefer a more „solid“ solution. From the back of my head, here’s my full list of issues/questions:
>> 
>> 1) Could there be an alternative --debugger-command-file that points to a file containing the debugger commands? If there are many and complex breakpoints the command line gets extremely long, and those newlines scare me a lot when pushing everything though my tools and a shell process until it arrives in Fuse.
>> 
>> 2) As an alternative idea to 1): The CSpect emulator uses certain invalid opcodes (such as $dd $01) as breakpoints. That means the opcodes would be part of the program itself and not have to be specified on the command line. Is that something you could consider?
>> 
>> 3) Could the default behavior for 128K .sna files be changed? Currently the system interprets them as Pentagon snapshots, does not find the ROMs (I am not interested in Pentagon) and „crashes“ into a 48K machine. I understand this is possibly a „historical decision“, but in my opinion there’s nothing inherently Pentagon about the format. Would something like this work: If the Pentagon ROMs are not there and/or the user specified —machine 128 on the command line, treat this as a 128K snapshot, not as Pentagon? Or simply a checkbox in the preferences?
>> 
>> 4) Could there be a „step over“ button in the debugger UI that basically does what „n“ does in the debugger commands (as a convenience)?
>> 
>> 5) Last but not least, the Mac version seems to be a bit behind the latest upstream (and have some bugs of its own). Not sure if the main Mac developer is on this list, but is there a chance for an update? I’m very much willing to provide feedback for Intel and Arm Macs. I could also try building either locally, but I probably won’t be much help with the actual development because I don’t know the codebase.
>> 
>> Best regards
>> Joerg
>> 
>> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig... <mailto:be...@ig...>>:
>> > 
>> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>> >> sorry for using the developer list for this question, but since all
>> >> the other places (especially the SourceForge project for Mac Fuse,
>> >> which is the flavor I am using) are so inactive, I was wondering
>> >> if the project might have moved elsewhere. Is there a Discord or
>> >> another place where one might ask questions, or are things really as
>> >> inactive as they seem?
>> > 
>> > You can ask questions here, I guess, but the project is certainly
>> > stalled at the moment...
>> > 
>> > Berto
>> > 
>> > 
>> > _______________________________________________
>> > fuse-emulator-devel mailing list
>> > fus...@li... <mailto:fus...@li...>
>> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel <https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel>
>> 
>> 
>> 
>> _______________________________________________
>> fuse-emulator-devel mailing list
>> fus...@li... <mailto:fus...@li...>
>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel <https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel>
> 
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li... <mailto:fus...@li...>
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel <https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel>

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Alan P. <ala...@gm...>]

Hi Everyone,

Chipping in on this thread.
Thanks Joerg for raising this, and thanks Philip for coming back.
I think a lot of users have been waiting a long time for a new release, myself included.

I completely get you’re at a different life stage now, and we all move on, you’ve left one heck of a legacy that make many people happy.
I’d come back on one of your comments if I may, the use case of fuse.  I think it’s well past playing Manic Miner (there are so many other ways to do that today, including a web browser), and for me, the use case of fuse is Spectrum/Z80 tinkering and development. 
 I use FUSE because of the extensive hardware emulation (particularly +D/Disciple & the 128k models), and have spent many happy hours doing things such as converting games to load from disk, to messing around with crazy things like learning all about the differences between the FDC in the +3 and +D.
FUSE has a lot of abilities, some could be built upon to make it even better (remote control debugging / execution, hooking it into Spectrum Analyser for example).

On the Mac build.. some years ago, with the help of this list I got it to build on both Intel and Apple Silicon (after some serious efforts getting the dependencies right), but alas it crashed opening the first window. On investigation this was due to a change in more recent versions of Mac OS where it was doing something that apple have now termed illegal. For the life of me, I can’t remember what it was.
Maybe I’ll try again and report the error here so someone could help

Philip I hope you can either become active again (supporting patches, releasing builds, and please, please, please move to GitHub !) or find someone to take on those tasks.

Please don’t let FUSE wither, it’s such a great tool, with so many uses.





Thank you from a very grateful user.

Alan





> On 15 Sep 2025, at 12:24, Joerg Pleumann <joe...@gm...> wrote:
> 
> Hi Phil,
> 
> thanks a lot for the response — and for all the hard work and dedication that went into Fuse since it was conceived in 1999. Apart from CSpect, which I use for Next-specific stuff, Fuse has been my favorite 48K/128K emulator for a long time now, especially due to the fact that it’s available on so many platforms.
> 
> I agree Fuse is quite mature, but, as you mentioned, platforms move on and software may have to adapt from time to time in order not not become obsolete. I’m not sure how much assistance I could provide here, but I’m definitely willing to test and provide feedback. I regularly use Intel and Arm Macs as well as Ubuntu machines.
> 
> I already tried to build the latest Mac version, with the intention of getting a bit of understanding of the code base and maybe solving my little issues locally, then provide a patch, but so far I even failed to checkout. Is there a chance you establish contact with Frederick Meunier, so I can ask him a few questions?
> 
> Best regards
> Joerg
> 
>> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh... <mailto:ph...@sh...>>:
>> 
>> > Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>> 
>> [ Wakes up from slumber ]
>> 
>> I'd say both. Certainly from my point of view, I'm at a very different stage of my life than I was in 1999 when the project started and I'm pretty sure that will apply to a number of the other "core" developers as well.
>> 
>> But I'd also agree that the project - and in fact, the software Spectrum emulation scene in general - has reached maturity; you can see this in that the rate of development of all the other major emulators has pretty stopped as well - because they do everything that 99% of users want to do, which is to play Manic Miner. The notable exception here is Spectrum Next emulation, but that is _such_ a different machine even if it uses a "CPU" which is a superset of the Z80.
>> 
>> With regards to the macOS version in particular, we always had a single point of success of the one developer who owned a Mac; I'm not aware of anyone even vaguely active who is trying to make new macOS builds - and as you note, the evolution of the Apple hardware ecosystem means there's probably a lot of catching up to do.
>> 
>> Please nobody let me be a blocker to getting things done with the project - I'm happy to talk about what privileges someone would need to get new releases out if there's someone who is genuinely interested in doing so.
>> 
>> Thanks,
>> 
>> Phil
>> 
>> 
>> 
>> 
>> 
>> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
>>> Hi Alberto,
>>> 
>>> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
>>> 
>>> I am using Fuse as emulator in a multi-platform Z80 compiler environment I’ve been developing for a while now. I have a couple of issues, including a bigger one with multi-line debugger commands fed into Fuse via the command line. In the meantime, I’ve been able to solve the latter, but would still prefer a more „solid“ solution. From the back of my head, here’s my full list of issues/questions:
>>> 
>>> 1) Could there be an alternative --debugger-command-file that points to a file containing the debugger commands? If there are many and complex breakpoints the command line gets extremely long, and those newlines scare me a lot when pushing everything though my tools and a shell process until it arrives in Fuse.
>>> 
>>> 2) As an alternative idea to 1): The CSpect emulator uses certain invalid opcodes (such as $dd $01) as breakpoints. That means the opcodes would be part of the program itself and not have to be specified on the command line. Is that something you could consider?
>>> 
>>> 3) Could the default behavior for 128K .sna files be changed? Currently the system interprets them as Pentagon snapshots, does not find the ROMs (I am not interested in Pentagon) and „crashes“ into a 48K machine. I understand this is possibly a „historical decision“, but in my opinion there’s nothing inherently Pentagon about the format. Would something like this work: If the Pentagon ROMs are not there and/or the user specified —machine 128 on the command line, treat this as a 128K snapshot, not as Pentagon? Or simply a checkbox in the preferences?
>>> 
>>> 4) Could there be a „step over“ button in the debugger UI that basically does what „n“ does in the debugger commands (as a convenience)?
>>> 
>>> 5) Last but not least, the Mac version seems to be a bit behind the latest upstream (and have some bugs of its own). Not sure if the main Mac developer is on this list, but is there a chance for an update? I’m very much willing to provide feedback for Intel and Arm Macs. I could also try building either locally, but I probably won’t be much help with the actual development because I don’t know the codebase.
>>> 
>>> Best regards
>>> Joerg
>>> 
>>> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig... <mailto:be...@ig...>>:
>>> > 
>>> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>>> >> sorry for using the developer list for this question, but since all
>>> >> the other places (especially the SourceForge project for Mac Fuse,
>>> >> which is the flavor I am using) are so inactive, I was wondering
>>> >> if the project might have moved elsewhere. Is there a Discord or
>>> >> another place where one might ask questions, or are things really as
>>> >> inactive as they seem?
>>> > 
>>> > You can ask questions here, I guess, but the project is certainly
>>> > stalled at the moment...
>>> > 
>>> > Berto
>>> > 
>>> > 
>>> > _______________________________________________
>>> > fuse-emulator-devel mailing list
>>> > fus...@li... <mailto:fus...@li...>
>>> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> fuse-emulator-devel mailing list
>>> fus...@li... <mailto:fus...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
> 
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[desertkun <des...@gm...>]

Hello. I've been semi-maintaining a fork of Fuse called FuseX on
speccytools.org

It has gdbserver stub built in, so you can connect to it with with
z88dk-gdb and do things like inspect memory, place breakpoints, observe
stack, and if your debugger supports (z88dk-gdb does, but it must be built
by z88dk), show source code mapping to that. I believe this should work
with z80-binutils, however I have not tested that.

You enable gdbserver in settings and connect with your gdb of choice, of
which z88dk-gdb is the only one really tested.

On Mon, Sep 15, 2025, 13:25 Joerg Pleumann <joe...@gm...> wrote:

> Hi Phil,
>
> thanks a lot for the response — and for all the hard work and dedication
> that went into Fuse since it was conceived in 1999. Apart from CSpect,
> which I use for Next-specific stuff, Fuse has been my favorite 48K/128K
> emulator for a long time now, especially due to the fact that it’s
> available on so many platforms.
>
> I agree Fuse is quite mature, but, as you mentioned, platforms move on and
> software may have to adapt from time to time in order not not become
> obsolete. I’m not sure how much assistance I could provide here, but I’m
> definitely willing to test and provide feedback. I regularly use Intel and
> Arm Macs as well as Ubuntu machines.
>
> I already tried to build the latest Mac version, with the intention of
> getting a bit of understanding of the code base and maybe solving my little
> issues locally, then provide a patch, but so far I even failed to checkout.
> Is there a chance you establish contact with Frederick Meunier, so I can
> ask him a few questions?
>
> Best regards
> Joerg
>
> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh...>:
>
> > Did everybody move on to other things or is it because the project is so
> mature (almost) no changes are needed? :)
>
> [ Wakes up from slumber ]
>
> I'd say both. Certainly from my point of view, I'm at a very different
> stage of my life than I was in 1999 when the project started and I'm pretty
> sure that will apply to a number of the other "core" developers as well.
>
> But I'd also agree that the project - and in fact, the software Spectrum
> emulation scene in general - has reached maturity; you can see this in that
> the rate of development of all the other major emulators has pretty stopped
> as well - because they do everything that 99% of users want to do, which is
> to play Manic Miner. The notable exception here is Spectrum Next emulation,
> but that is _such_ a different machine even if it uses a "CPU" which is a
> superset of the Z80.
>
> With regards to the macOS version in particular, we always had a single
> point of success of the one developer who owned a Mac; I'm not aware of
> anyone even vaguely active who is trying to make new macOS builds - and as
> you note, the evolution of the Apple hardware ecosystem means there's
> probably a lot of catching up to do.
>
> Please nobody let me be a blocker to getting things done with the project
> - I'm happy to talk about what privileges someone would need to get new
> releases out if there's someone who is genuinely interested in doing so.
>
> Thanks,
>
> Phil
>
>
>
>
>
> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm...>
> wrote:
>
>> Hi Alberto,
>>
>> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to
>> other things or is it because the project is so mature (almost) no changes
>> are needed? :)
>>
>> I am using Fuse as emulator in a multi-platform Z80 compiler environment
>> I’ve been developing for a while now. I have a couple of issues, including
>> a bigger one with multi-line debugger commands fed into Fuse via the
>> command line. In the meantime, I’ve been able to solve the latter, but
>> would still prefer a more „solid“ solution. From the back of my head,
>> here’s my full list of issues/questions:
>>
>> 1) Could there be an alternative --debugger-command-file that points to a
>> file containing the debugger commands? If there are many and complex
>> breakpoints the command line gets extremely long, and those newlines scare
>> me a lot when pushing everything though my tools and a shell process until
>> it arrives in Fuse.
>>
>> 2) As an alternative idea to 1): The CSpect emulator uses certain invalid
>> opcodes (such as $dd $01) as breakpoints. That means the opcodes would be
>> part of the program itself and not have to be specified on the command
>> line. Is that something you could consider?
>>
>> 3) Could the default behavior for 128K .sna files be changed? Currently
>> the system interprets them as Pentagon snapshots, does not find the ROMs (I
>> am not interested in Pentagon) and „crashes“ into a 48K machine. I
>> understand this is possibly a „historical decision“, but in my opinion
>> there’s nothing inherently Pentagon about the format. Would something like
>> this work: If the Pentagon ROMs are not there and/or the user specified
>> —machine 128 on the command line, treat this as a 128K snapshot, not as
>> Pentagon? Or simply a checkbox in the preferences?
>>
>> 4) Could there be a „step over“ button in the debugger UI that basically
>> does what „n“ does in the debugger commands (as a convenience)?
>>
>> 5) Last but not least, the Mac version seems to be a bit behind the
>> latest upstream (and have some bugs of its own). Not sure if the main Mac
>> developer is on this list, but is there a chance for an update? I’m very
>> much willing to provide feedback for Intel and Arm Macs. I could also try
>> building either locally, but I probably won’t be much help with the actual
>> development because I don’t know the codebase.
>>
>> Best regards
>> Joerg
>>
>> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig...>:
>> >
>> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>> >> sorry for using the developer list for this question, but since all
>> >> the other places (especially the SourceForge project for Mac Fuse,
>> >> which is the flavor I am using) are so inactive, I was wondering
>> >> if the project might have moved elsewhere. Is there a Discord or
>> >> another place where one might ask questions, or are things really as
>> >> inactive as they seem?
>> >
>> > You can ask questions here, I guess, but the project is certainly
>> > stalled at the moment...
>> >
>> > Berto
>> >
>> >
>> > _______________________________________________
>> > fuse-emulator-devel mailing list
>> > fus...@li...
>> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>
>>
>>
>> _______________________________________________
>> fuse-emulator-devel mailing list
>> fus...@li...
>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>>
>
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Joerg P. <joe...@gm...>]

Hi Phil,

thanks a lot for the response — and for all the hard work and dedication that went into Fuse since it was conceived in 1999. Apart from CSpect, which I use for Next-specific stuff, Fuse has been my favorite 48K/128K emulator for a long time now, especially due to the fact that it’s available on so many platforms.

I agree Fuse is quite mature, but, as you mentioned, platforms move on and software may have to adapt from time to time in order not not become obsolete. I’m not sure how much assistance I could provide here, but I’m definitely willing to test and provide feedback. I regularly use Intel and Arm Macs as well as Ubuntu machines.

I already tried to build the latest Mac version, with the intention of getting a bit of understanding of the code base and maybe solving my little issues locally, then provide a patch, but so far I even failed to checkout. Is there a chance you establish contact with Frederick Meunier, so I can ask him a few questions?

Best regards
Joerg

> Am 15.09.2025 um 11:49 schrieb Philip Kendall <ph...@sh...>:
> 
> > Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
> 
> [ Wakes up from slumber ]
> 
> I'd say both. Certainly from my point of view, I'm at a very different stage of my life than I was in 1999 when the project started and I'm pretty sure that will apply to a number of the other "core" developers as well.
> 
> But I'd also agree that the project - and in fact, the software Spectrum emulation scene in general - has reached maturity; you can see this in that the rate of development of all the other major emulators has pretty stopped as well - because they do everything that 99% of users want to do, which is to play Manic Miner. The notable exception here is Spectrum Next emulation, but that is _such_ a different machine even if it uses a "CPU" which is a superset of the Z80.
> 
> With regards to the macOS version in particular, we always had a single point of success of the one developer who owned a Mac; I'm not aware of anyone even vaguely active who is trying to make new macOS builds - and as you note, the evolution of the Apple hardware ecosystem means there's probably a lot of catching up to do.
> 
> Please nobody let me be a blocker to getting things done with the project - I'm happy to talk about what privileges someone would need to get new releases out if there's someone who is genuinely interested in doing so.
> 
> Thanks,
> 
> Phil
> 
> 
> 
> 
> 
> On Mon, Sep 15, 2025 at 8:15 AM Joerg Pleumann <joe...@gm... <mailto:joe...@gm...>> wrote:
> Hi Alberto,
> 
> it’s a bit sad to hear that Fuse is stalled. Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)
> 
> I am using Fuse as emulator in a multi-platform Z80 compiler environment I’ve been developing for a while now. I have a couple of issues, including a bigger one with multi-line debugger commands fed into Fuse via the command line. In the meantime, I’ve been able to solve the latter, but would still prefer a more „solid“ solution. From the back of my head, here’s my full list of issues/questions:
> 
> 1) Could there be an alternative --debugger-command-file that points to a file containing the debugger commands? If there are many and complex breakpoints the command line gets extremely long, and those newlines scare me a lot when pushing everything though my tools and a shell process until it arrives in Fuse.
> 
> 2) As an alternative idea to 1): The CSpect emulator uses certain invalid opcodes (such as $dd $01) as breakpoints. That means the opcodes would be part of the program itself and not have to be specified on the command line. Is that something you could consider?
> 
> 3) Could the default behavior for 128K .sna files be changed? Currently the system interprets them as Pentagon snapshots, does not find the ROMs (I am not interested in Pentagon) and „crashes“ into a 48K machine. I understand this is possibly a „historical decision“, but in my opinion there’s nothing inherently Pentagon about the format. Would something like this work: If the Pentagon ROMs are not there and/or the user specified —machine 128 on the command line, treat this as a 128K snapshot, not as Pentagon? Or simply a checkbox in the preferences?
> 
> 4) Could there be a „step over“ button in the debugger UI that basically does what „n“ does in the debugger commands (as a convenience)?
> 
> 5) Last but not least, the Mac version seems to be a bit behind the latest upstream (and have some bugs of its own). Not sure if the main Mac developer is on this list, but is there a chance for an update? I’m very much willing to provide feedback for Intel and Arm Macs. I could also try building either locally, but I probably won’t be much help with the actual development because I don’t know the codebase.
> 
> Best regards
> Joerg
> 
> > Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig... <mailto:be...@ig...>>:
> > 
> > On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
> >> sorry for using the developer list for this question, but since all
> >> the other places (especially the SourceForge project for Mac Fuse,
> >> which is the flavor I am using) are so inactive, I was wondering
> >> if the project might have moved elsewhere. Is there a Discord or
> >> another place where one might ask questions, or are things really as
> >> inactive as they seem?
> > 
> > You can ask questions here, I guess, but the project is certainly
> > stalled at the moment...
> > 
> > Berto
> > 
> > 
> > _______________________________________________
> > fuse-emulator-devel mailing list
> > fus...@li... <mailto:fus...@li...>
> > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel <https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel>
> 
> 
> 
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li... <mailto:fus...@li...>
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel <https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel>

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Joerg P. <joe...@gm...>]

Hi Alberto,

it’s a bit sad to hear that Fuse is stalled. Did everybody move on to other things or is it because the project is so mature (almost) no changes are needed? :)

I am using Fuse as emulator in a multi-platform Z80 compiler environment I’ve been developing for a while now. I have a couple of issues, including a bigger one with multi-line debugger commands fed into Fuse via the command line. In the meantime, I’ve been able to solve the latter, but would still prefer a more „solid“ solution. From the back of my head, here’s my full list of issues/questions:

1) Could there be an alternative --debugger-command-file that points to a file containing the debugger commands? If there are many and complex breakpoints the command line gets extremely long, and those newlines scare me a lot when pushing everything though my tools and a shell process until it arrives in Fuse.

2) As an alternative idea to 1): The CSpect emulator uses certain invalid opcodes (such as $dd $01) as breakpoints. That means the opcodes would be part of the program itself and not have to be specified on the command line. Is that something you could consider?
 
3) Could the default behavior for 128K .sna files be changed? Currently the system interprets them as Pentagon snapshots, does not find the ROMs (I am not interested in Pentagon) and „crashes“ into a 48K machine. I understand this is possibly a „historical decision“, but in my opinion there’s nothing inherently Pentagon about the format. Would something like this work: If the Pentagon ROMs are not there and/or the user specified —machine 128 on the command line, treat this as a 128K snapshot, not as Pentagon? Or simply a checkbox in the preferences?

4) Could there be a „step over“ button in the debugger UI that basically does what „n“ does in the debugger commands (as a convenience)?

5) Last but not least, the Mac version seems to be a bit behind the latest upstream (and have some bugs of its own). Not sure if the main Mac developer is on this list, but is there a chance for an update? I’m very much willing to provide feedback for Intel and Arm Macs. I could also try building either locally, but I probably won’t be much help with the actual development because I don’t know the codebase.

Best regards
Joerg

> Am 14.09.2025 um 23:58 schrieb Alberto Garcia <be...@ig...>:
> 
> On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
>> sorry for using the developer list for this question, but since all
>> the other places (especially the SourceForge project for Mac Fuse,
>> which is the flavor I am using) are so inactive, I was wondering
>> if the project might have moved elsewhere. Is there a Discord or
>> another place where one might ask questions, or are things really as
>> inactive as they seem?
> 
> You can ask questions here, I guess, but the project is certainly
> stalled at the moment...
> 
> Berto
> 
> 
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel

Re: [fuse-emulator-devel] Is Fuse alive (and where)?

[Alberto G. <be...@ig...>]

On Sun, Sep 14, 2025 at 10:32:08AM +0200, Joerg Pleumann wrote:
> sorry for using the developer list for this question, but since all
> the other places (especially the SourceForge project for Mac Fuse,
> which is the flavor I am using) are so inactive, I was wondering
> if the project might have moved elsewhere. Is there a Discord or
> another place where one might ask questions, or are things really as
> inactive as they seem?

You can ask questions here, I guess, but the project is certainly
stalled at the moment...

Berto

[fuse-emulator-devel] Is Fuse alive (and where)?

[Joerg P. <joe...@gm...>]

Hello,

sorry for using the developer list for this question, but since all the other places (especially the SourceForge project for Mac Fuse, which is the flavor I am using) are so inactive, I was wondering if the project might have moved elsewhere. Is there a Discord or another place where one might ask questions, or are things really as inactive as they seem?

Best regards
Joerg

Re: [fuse-emulator-devel] Next release of fuse

[Alan C. <al...@ll...>]

On Tue, 11 Feb 2025 08:09:45 +0100
Miroslav Arki <mir...@gm...> wrote:

> Hi,
> 
> Yes, the mailinglist is still active. I can see your emails.
> Unfortunately the evolution stalled around 2020. From my observations
> release must be done by the original author, which however did not do much
> in last years.
> 
> There were some changes accepted by second author, but even with him the
> possibilities are limited. Some of My pull requests were not processed or
> commented in 2 years. Some were thou.

Similar experience with the patches to make the Russian stuff work, only
over an even longer period. It's a pity because zesarux is a buggy mess
in many areas (SD emulation is very poor, ZX Uno memory handling is
totally wrong etc) and the author rarely responds.

Alan

Re: [fuse-emulator-devel] Next release of fuse

[Miroslav A. <mir...@gm...>]

Hi

Alfi you say?
That's just 2x steppers and a pen hooked up to parallel port. Have its box
still in my drawer.

;)




Any new ideas can be documented in the official sourceforge project. Feel
free to open a ticket there.


If the provided file format is a snapshot file that is to be just loaded
into speccy memory, that is not that hard. Done that already.
If on other hand it needs emulating hw and loading that file into it, that
is more work.
And there is also the problem that additional hw might not be accepted into
the base fuse app. Especially if it is a local hw, not used widely.
In such a case it can be made available only within a fork.. just like i
made one in github.


Anyway i think this discussion is now off the original question ;)



Miro


Dňa ut 11. 2. 2025, 22:05 Tomáš <to...@vo...> napísal(a):

> D40 is emulated for many years. The first version, with WD2797 controller.
>
> I am looking for some further development too. For example low level
> microdrive cartridge format, like ZEsarUX has. LEC and Sinsoft memory
> extensions. Plotter device (Alfi).
>
> I can provide the technical docs to developers, but I am not enough
> experienced in Fuse internal structure to code it by myself.
>
> Here is the description of ZEsarUX  .mdv file format for example-
>
> The first 256 bytes is a header:
>
> offset Description
> 0 “RAWMDV” 6 bytes
> 6 -Version. byte. current: 0
> 7 -Creator: 30 bytes. String ended with 0 byte (0 final optional).
> Example “ZEsarUX 11.1-SN”
> 37 -Machine: What machine uses this microdrive. String ended with 0 byte
> (0 final optional). 20 bytes: examples:
>          “Spectrum”
>          “QL”
> 57 19 bytes.
>          -Date: 19 bytes. String ended with 0 byte (0 final optional)
>          “DD/MM/AAAA HH:MM:SS”
>
> 76-79 Usage counter, times the microdrive has been full read (times the
> header position has passed position 0). Unsigned integer 32 bits, little
> endian
> 80-255 Reserved. Set to 0
>
> After the header comes the data and then the type of all data. For
> example, for a 90 KB raw microdrive, here it comes:
>
> 90 KB of data: just the raw data
> 90 KB of type for all the data: every position of data can be: gap or data.
> And also, every position can be marked as "bad position" (emulating a
> microdrive with sections of data that can't be written or read).
> Every one of this data type is a mask of bits, currently only bits 0 and
> 1 are used:
>
> Bit 0: Data or Gap. If set bit, it's a data. If not, it's a gap
> Bit 1: Bad position. If set, it's a bad position. If not, it's a "good"
> position
>
> For example if the first 5 bytes of data are: Gap, Gap, Data, Data,
> Data+Bad, the data types will be:
>
> 00, 00, 01, 01, 03
>
> Following the same 90 KB example, the total size of the RMD file will
> be: 256+92160+92160=184576 bytes
>
> Omikron
>
>
> Dne 11.02.2025 v 8:09 Miroslav Arki napsal(a):
>
> > If interested I have a fork on github, look for arki55. Unmerged stuff
> > is only around Didaktik 128k with floppy D40 thou. I've created github
> > workflows for auto building multiple versions within PRs, also created
> > workflow for nightly builds. Limited to win32 packages only thou.
>
> --
> Tento e-mail byl antivirovým softwarem AVG zkontrolován na viry.
> www.avg.com
>

Re: [fuse-emulator-devel] Next release of fuse

[Tomáš <to...@vo...>]

D40 is emulated for many years. The first version, with WD2797 controller.

I am looking for some further development too. For example low level 
microdrive cartridge format, like ZEsarUX has. LEC and Sinsoft memory 
extensions. Plotter device (Alfi).

I can provide the technical docs to developers, but I am not enough 
experienced in Fuse internal structure to code it by myself.

Here is the description of ZEsarUX  .mdv file format for example-

The first 256 bytes is a header:

offset Description
0 “RAWMDV” 6 bytes
6 -Version. byte. current: 0
7 -Creator: 30 bytes. String ended with 0 byte (0 final optional). 
Example “ZEsarUX 11.1-SN”
37 -Machine: What machine uses this microdrive. String ended with 0 byte 
(0 final optional). 20 bytes: examples:
         “Spectrum”
         “QL”
57 19 bytes.
         -Date: 19 bytes. String ended with 0 byte (0 final optional)
         “DD/MM/AAAA HH:MM:SS”

76-79 Usage counter, times the microdrive has been full read (times the 
header position has passed position 0). Unsigned integer 32 bits, little 
endian
80-255 Reserved. Set to 0

After the header comes the data and then the type of all data. For 
example, for a 90 KB raw microdrive, here it comes:

90 KB of data: just the raw data
90 KB of type for all the data: every position of data can be: gap or data.
And also, every position can be marked as "bad position" (emulating a 
microdrive with sections of data that can't be written or read).
Every one of this data type is a mask of bits, currently only bits 0 and 
1 are used:

Bit 0: Data or Gap. If set bit, it's a data. If not, it's a gap
Bit 1: Bad position. If set, it's a bad position. If not, it's a "good" 
position

For example if the first 5 bytes of data are: Gap, Gap, Data, Data, 
Data+Bad, the data types will be:

00, 00, 01, 01, 03

Following the same 90 KB example, the total size of the RMD file will 
be: 256+92160+92160=184576 bytes

Omikron


Dne 11.02.2025 v 8:09 Miroslav Arki napsal(a):

> If interested I have a fork on github, look for arki55. Unmerged stuff 
> is only around Didaktik 128k with floppy D40 thou. I've created github 
> workflows for auto building multiple versions within PRs, also created 
> workflow for nightly builds. Limited to win32 packages only thou. 

-- 
Tento e-mail byl antivirovým softwarem AVG zkontrolován na viry.
www.avg.com

Re: [fuse-emulator-devel] Next release of fuse

[Miroslav A. <mir...@gm...>]

Hi,

Yes, the mailinglist is still active. I can see your emails.
Unfortunately the evolution stalled around 2020. From my observations
release must be done by the original author, which however did not do much
in last years.

There were some changes accepted by second author, but even with him the
possibilities are limited. Some of My pull requests were not processed or
commented in 2 years. Some were thou.

I myself am a newcomer to this project. Have ideas, but lost time to be
able to work on them either.

For basic usage old version still does the job. And who has a problem,
usually has also the remedy and can build it.

If interested I have a fork on github, look for arki55. Unmerged stuff is
only around Didaktik 128k with floppy D40 thou. I've created github
workflows for auto building multiple versions within PRs, also created
workflow for nightly builds. Limited to win32 packages only thou.
It is still glitchy, needs the final kick..

 I still keep the hope that speccy users did not die out yet and so believe
there will still be some further evolution in the future.

Br,
Miroslav Ďurčík
Bratislava

Dňa ut 11. 2. 2025, 0:56 Peter Moore via fuse-emulator-devel <
fus...@li...> napísal(a):

> Is this mailing list still active?
>
> > On 10. Jan 2025, at 14:03, Peter Moore <pet...@gm...> wrote:
> >
> > Hi,
> >
> > I was curious if there is a plan to make a new release of fuse? I
> contributed a patch last January, but I think it hasn’t been released yet.
> >
> > Many thanks,
> > Pete
>
>
>
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>

Re: [fuse-emulator-devel] Next release of fuse

[Peter M. <pet...@gm...>]

Is this mailing list still active?

> On 10. Jan 2025, at 14:03, Peter Moore <pet...@gm...> wrote:
> 
> Hi,
> 
> I was curious if there is a plan to make a new release of fuse? I contributed a patch last January, but I think it hasn’t been released yet.
> 
> Many thanks,
> Pete

[fuse-emulator-devel] Next release of fuse

[Peter M. <pet...@gm...>]

Hi,

I was curious if there is a plan to make a new release of fuse? I contributed a patch last January, but I think it hasn’t been released yet.

Many thanks,
Pete

Re: [fuse-emulator-devel] Multiple settings files

[Adam A. <ada...@gm...>]

Sorry, I only just saw this as it went into my spam folder.

Thanks for adding to the bug report.

I didn't realise until after I posted that there are a lot more command
line switches than are provided by the propgram help text, to the point
where I could probably reproduce my examples using a script similar to
yours.

Cheers,

Adam

On Fri, 25 Oct 2024 at 10:04, Alberto Garcia <be...@ig...> wrote:

> On Thu, Oct 24, 2024 at 12:51:53PM +0100, Adam Ainsworth wrote:
>
> > would it be possible to allow multiple 'profiles' by being able to
> > select the config file via a command line switch?
>
> I agree that it would be nice to have a better way to select the
> location of the configuration file.
>
> It could be as simple as a flag (--configfile ~/.fuserc-48k) or an
> environment variable (FUSE_EMULATOR_CONFIG_FILE=$HOME/.fuserc-48k).
>
> Related bug report: https://sourceforge.net/p/fuse-emulator/patches/443/
>
> > It would be nice to be able to quickly choose whether you want (for
> > instance) a standard 48 set up (ie. for Microdrives), standard 128
> > for daily use, +3e for disk manipulation or Pentagon for watching
> > demos.
> >
> > I realise I can do some file jiggery-pokery by replacing .fuserc but
> > having it native would be awesome
>
> You can also do that without having to replace .fuserc if you use a
> separate launcher script or shell alias / function.
>
> For example I have this in ~/.bashrc:
>
> fuse-slowtape () {
>         fuse --no-detect-loader --no-auto-load --no-traps \
>              --no-fastload --no-accelerate-loader "$@"
> }
>
> Berto
>
>
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>

Re: [fuse-emulator-devel] Multiple settings files

[Alberto G. <be...@ig...>]

On Thu, Oct 24, 2024 at 12:51:53PM +0100, Adam Ainsworth wrote:

> would it be possible to allow multiple 'profiles' by being able to
> select the config file via a command line switch?

I agree that it would be nice to have a better way to select the
location of the configuration file.

It could be as simple as a flag (--configfile ~/.fuserc-48k) or an
environment variable (FUSE_EMULATOR_CONFIG_FILE=$HOME/.fuserc-48k).

Related bug report: https://sourceforge.net/p/fuse-emulator/patches/443/

> It would be nice to be able to quickly choose whether you want (for
> instance) a standard 48 set up (ie. for Microdrives), standard 128
> for daily use, +3e for disk manipulation or Pentagon for watching
> demos.
> 
> I realise I can do some file jiggery-pokery by replacing .fuserc but
> having it native would be awesome

You can also do that without having to replace .fuserc if you use a
separate launcher script or shell alias / function.

For example I have this in ~/.bashrc:

fuse-slowtape () {
        fuse --no-detect-loader --no-auto-load --no-traps \
             --no-fastload --no-accelerate-loader "$@"
}

Berto