Spectrum Computing

A new release of Fuse, the Free Unix Spectrum Emulator, is now available at the SourceForge project:

https://sourceforge.net/projects/fuse-emulator/

Highlights of this release include:

• Prevent crash when we try to disassemble an instruction with many DD or FD prefixes.
• Fix crash when setting debugger variables.
• Prevent crash when we try to profile an instruction with many DD or FD prefixes.
• GTK+ UI: Improve behaviour of default button on dialogs.
• GTK+ and win32 UIs: Support hex numbers in load/save binary and pokefinder dialogs.
• SDL UI: Allow to select the video mode used in full-screen.

Many thanks to everyone who's contributed to this release. Source code and binaries for Windows are currenly available on the SourceForge site; compiled binaries for various other platforms should become available in the next few days.

Thanks [mention]Fred[/mention] Its great that Fuse is getting frequent updates.

Yep thanks. I've started using FUSE, mainly for MLT screen dumps, if you implement a built in assembler it could well become my main emulator of choice

+1, thanks [mention]Fred[/mention] and the Fuse team for all your hard work!

R-Tape wrote: ↑Tue Feb 27, 2018 7:32 pm Yep thanks. I've started using FUSE, mainly for MLT screen dumps, if you implement a built in assembler it could well become my main emulator of choice

+1 an assembler would be lovely!

Has anyone got a copy of the UNIX source for 1.5.1 they can put somewhere? Sourceforge has been down for several days now.

Yea sourceforge seems to be having some real problem with the whole website, in fairness to them from what they posted they had to do something with the drop in performance of the website. This seems like a needed intervention on their part. I get the feeling that whatever they thought was causing the problems turned out to have either been a much bigger issue or had a domino effect.

Hopefully it all gets resolved soon. They must feel terrible.

Nomad wrote: ↑Sat Mar 03, 2018 11:26 am Yea sourceforge seems to be having some real problem with the whole website, in fairness to them from what they posted they had to do something with the drop in performance of the website. This seems like a needed intervention on their part. I get the feeling that whatever they thought was causing the problems turned out to have either been a much bigger issue or had a domino effect.

Hopefully it all gets resolved soon. They must feel terrible.

Yes, Slashdot hasn't been updated for a couple of days either. Something pretty catastrophic must be happening.

Shame, 'cos I'm still snowed in, I have a bit of time on my hands this Saturday morning, and I can't get to the new release of Fuse!

Try here until sourceforge recovers:
https://www.dropbox.com/sh/7t53k7pa21vl ... AD57a?dl=0

Fred wrote: ↑Sat Mar 03, 2018 12:23 pm Try here until sourceforge recovers:
https://www.dropbox.com/sh/7t53k7pa21vl ... AD57a?dl=0

Brilliant, thanks Fred

It looks as though sourceforge is up again.

https://sourceforge.net/projects/fuse-emulator/files/

Not for me. Try clicking any other links, like Tickets, News, etc.

Hi, I was just there to download fuse-utils.

Yeah, some of the projects have their older versions available. Most everything else is down: https://twitter.com/sfnet_ops

What is the benefit of the virtual typist feature? It seems that when I drag and drop a TAP file onto the Fuse window, Fuse does a reset of the machine, then 'types' LOAD "" and presses return. It never occurred to me to wonder how it used to handle the drag and drop before: I just did it and the load happened in a split second.

It seems the extra step of the virtual typist has been introduced. Why? What's now better than what it did before?

dfzx wrote: ↑Sun Mar 04, 2018 1:01 pm What is the benefit of the virtual typist feature? It seems that when I drag and drop a TAP file onto the Fuse window, Fuse does a reset of the machine, then 'types' LOAD "" and presses return. It never occurred to me to wonder how it used to handle the drag and drop before: I just did it and the load happened in a split second.

It seems the extra step of the virtual typist has been introduced. Why? What's now better than what it did before?

That’s my exact problem with this feature. It tremendously slows down development. Previously, as soon as I pressed the “Assemble and Run” shortcut in my assembler, the code was up and running by the time the OS switched to Fuse. I could make tons of small corrections in a short span of time. Now I have to wait for the reset and the virtual typing to finish.

The only scenario this feature might be beneficial in, is loading the very few early titles that overwrite the system variables area and don’t have a BASIC loader. You do need to type LOAD "" CODE to run them. Sure, it’s nice to have, but you should be able to turn it off, in my book.

I rolled back to 1.4.1 for the time being.

Ast A. Moore wrote: ↑Sun Mar 04, 2018 7:22 pm That’s my exact problem with this feature. It tremendously slows down development. Previously, as soon as I pressed the “Assemble and Run” shortcut in my assembler, the code was up and running by the time the OS switched to Fuse. I could make tons of small corrections in a short span of time. Now I have to wait for the reset and the virtual typing to finish.

The only scenario this feature might be beneficial in, is loading the very few early titles that overwrite the system variables area and don’t have a BASIC loader. You do need to type LOAD "" CODE to run them. Sure, it’s nice to have, but you should be able to turn it off, in my book.

I rolled back to 1.4.1 for the time being.

I happen to have an old build of 1.3.5 on my system, so I tried that because I'd forgotten what it did. That doesn't do the reset, or the typing. It just magically makes the program appear in the emulated Spectrum's memory and start running. How does it work, do you know?

It has something to do with the old system being inflexible and overwriting option settings. In theory, as long as fastloading etc. are enabled, the new system shouldn't be significantly slower though, no?

Is there a user guide or other documentation for Fuse. The utils have very good documentation.

utz wrote: ↑Sun Mar 04, 2018 7:42 pm It has something to do with the old system being inflexible and overwriting option settings. In theory, as long as fastloading etc. are enabled, the new system shouldn't be significantly slower though, no?

On my Linux system the only thing which takes any appreciable time is the Spectrum's reset, which I guess is maybe 2 seconds? With fastloading the phantom typist and code loading then take no discernible time to load a TAP file consisting of a BASIC loader and a m/c block.

PeterJ wrote: ↑Sun Mar 04, 2018 7:51 pm Is there a user guide or other documentation for Fuse. The utils have very good documentation.

The man page is comprehensive. It should be installed with your package or build.

dfzx wrote: ↑Sun Mar 04, 2018 7:40 pm It just magically makes the program appear in the emulated Spectrum's memory and start running. How does it work, do you know?

Well, not really. I’m on macOS, and it has its own build of Fuse. From what Fred tells me, there are some bugs in the latest version for macOS that prevent Fuse from accelerating the resetting/typing sequence. If, when he fixes the bugs, things return to the pre–virtual typist era speed-wise, I’ll be okay with it. If not, I guess I’m going to have to stick to v1.4.1.

dfzx wrote: ↑Sun Mar 04, 2018 1:01 pm What is the benefit of the virtual typist feature? It seems that when I drag and drop a TAP file onto the Fuse window, Fuse does a reset of the machine, then 'types' LOAD "" and presses return. It never occurred to me to wonder how it used to handle the drag and drop before: I just did it and the load happened in a split second.

It seems the extra step of the virtual typist has been introduced. Why? What's now better than what it did before?

Before phantom typist, Fuse has been using SZX snapshots saved after LOAD "" + Enter to auto-load tapes. In fact, there was a snapshot for every machine (48K, 128K, +2, +2A, +3, timex, pentagon, etc). That has some drawbacks:

• If the user runs a machine with an attached peripheral, Fuse would need (X machines * Y peripherals) snapshots or do some unreliable trick.
• Customs roms could have different entry points and code execution path.

Phantom typist is not an extra step but a different approach to autoload media, with better compatibility when using customised machines. Check this thread at SourceForge for more details.

Ast A. Moore wrote: ↑Sun Mar 04, 2018 9:23 pm

dfzx wrote: ↑Sun Mar 04, 2018 7:40 pm It just magically makes the program appear in the emulated Spectrum's memory and start running. How does it work, do you know?

Well, not really. I’m on macOS, and it has its own build of Fuse. From what Fred tells me, there are some bugs in the latest version for macOS that prevent Fuse from accelerating the resetting/typing sequence. If, when he fixes the bugs, things return to the pre–virtual typist era speed-wise, I’ll be okay with it. If not, I guess I’m going to have to stick to v1.4.1.

On Linux I don't see any delay as emulation speed runs at full throttle. It seems that Fuse for macOS needs to improve this feature.

serbalgi wrote: ↑Sun Mar 04, 2018 9:35 pm

Ast A. Moore wrote: ↑Sun Mar 04, 2018 9:23 pm Well, not really. I’m on macOS, and it has its own build of Fuse. From what Fred tells me, there are some bugs in the latest version for macOS that prevent Fuse from accelerating the resetting/typing sequence. If, when he fixes the bugs, things return to the pre–virtual typist era speed-wise, I’ll be okay with it. If not, I guess I’m going to have to stick to v1.4.1.

On Linux I don't see any delay as emulation speed runs at full throttle. It seems that Fuse for macOS needs to improve this feature.

Well, I’ll take your word for it, however, in the thread, Philip says that the reset sequence does add a delay. I don’t know if this has been addressed by enabling full acceleration during that sequence.