Activity for Alberto Garcia
-
Alberto Garcia posted a comment on discussion Open Discussion
I just removed .fuserc completely, started Fuse, Options -> Peripherals -> General, made sure that only "Interface 1" is enabled, restarted the emulated Spectrum, and it works just fine, CAT 1 lists the contents.
-
I tried with if1-1.rom and if1-2.rom (their MD5 sums are 5c11c61a2dd2ca4bf39328d9ff42d289 and 31b704ae925305e74f50699271fddd9a). It works fine with both. I'm using Fuse 1.6.0 in Linux. All peripherals are disabled except for Interface 1, check if you have others enabled just in case. When I type CAT 2 I get an error: Microdrive not present, 0:1. With CAT 1 I see the list of files normally and I can load them using the microdrive commands.
-
It works fine for me with this one for example: https://archive.org/download/World_of_Spectrum_June_2017_Mirror/World%20of%20Spectrum%20June%202017%20Mirror.zip/World%20of%20Spectrum%20June%202017%20Mirror/sinclair/magazines/Outlet/OutletIssue001.mdr.zip You need to indicate the drive number, e.g. CAT 1, and make sure that Interface 1 is enabled. Have a look at the manual here: http://www.retro8bitcomputers.co.uk/Content/downloads/manuals/ZXInterface1-Microdrive-Manual.pdf
-
You need to indicate the drive number, try CAT 1. Have a look at the manual here: http://www.retro8bitcomputers.co.uk/Content/downloads/manuals/ZXInterface1-Microdrive-Manual.pdf
-
Ok, that version is correct. Did you have install flex installed from the beginning or did you install it when make gave you an error? If it's the latter case then clean the repository completely and run autogen.sh again. If that does not fix the problem then run make V=1 in order to see what is actually happening there.
-
This is probably because you're using an old version of Flex. In Debian and Ubuntu install flex instead of flex-old.
-
Hi, what's the status of SDL2 support in Fuse ? SDL1 is going to be removed from e.g. Debian and the only alternative would be to use sdl12-compat (which seems to work fine btw) https://github.com/libsdl-org/sdl12-compat
-
It looks like the compressed versions (*.raw.bz2, *.img.gz, ...) are still there. But before removing those I would take a closer look at the full list, I'm not sure that things like .csw should have the ZX Spectrum icon. I think that I would reduce that list to the extensions that Fuse can open directly if you run it with fuse <filename>, and maybe for the bash completion script we can keep some additional extensions.
-
I don't think it makes sense to open ROM files directly, it's not like a tape or snapshot which the emulator can load automatically. And .img and .raw files can be anything, really. So I would only keep those that are actually ZX Spectrum formats.
-
On second thoughts I wonder if it's fine to use the ZX Spectrum icon for extensions like .img, .raw or .rom, which are very generic and can have any content, really.
-
This patch solves the problem for me. See here for a related bug: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2190
-
ZX Spectrum icons don't appear in the file chooser
-
Use the WebKitGTK 4.1 API builds when available
-
I've been testing the feature-135-arbitrary-scaling branch, with Wayland (gnome-shell 3.38.5) there's a lot of artifacts if I resize the window manually. With X11 (same desktop session but using XWayland) everything seems to work fine.
-
You can see the manual page online in some distribution's web site, e.g. for Ubuntu it is here: https://manpages.ubuntu.com/manpages/bionic/en/man1/fuse-gtk.1.html About the ROM path: when you build Fuse yourself from sources it does not have a predefined path for ROMs, it will install all internal files in the same folder (e.g. /usr/local/share/fuse). Some distributions do put ROMs somewhere else, /usr/share/spectrum-roms is the path used by Debian and Ubuntu so those ROMs can be shared among different...
-
Add ZIP files to the bash completion script
-
An alternative approach would be to turn tape_playing into an enum Well, I decided to upload this version as well so you can see the difference and judge for yourself.
-
Ok, here's version 2 of the patch. The previous one would keep the embedded pause at the end of a block in two cases; 1) When libspectrum tells fuse to stop (e.g. because we reached the end of the tape) 2) When autoplay and tape_traps is on and the following block is a standard ROM loader. Keeping the embedded pause in case (1) is what fixes the bug with Chuckie Egg 2 (and with 1942 from what I can see after running the tests). Keeping the embedded pause in case (2) confuses the loader detection...
-
Ok, this is not directly related to the bug, but while running the tests I thought that it would be much simpler to use SQLite to store the database (it's a very small one after all) rather than have a full instance of MySQL/MariaDB installed and running. Here's the patch in case it's useful for anyone.
-
Your patch looks good to me too.
-
I see, thanks !
-
Where are those tests? Are they published in a repository that I can download and try myself?
-
Oh, I see, this is endless ... ':-D It seems that all "broken" games load, it's just that the loader detection or the tape traps don't work. I'll have a look at those too.
-
I think the problem is that when Fuse receives FLAGS_STOP from libspectrum it stops the tape immediately and ignores the last edge. This effectively removes the embedded pause at the end of the last data block, and when Fuse's loader detection code plays the tape again (this time from the beginning) it is as if there was no pause between both blocks. Here's a proposal to fix the problem.
-
I think that the Chuckie Egg 2 problem is a bug in Fuse after all. I opened bug #480 to keep track of it: https://sourceforge.net/p/fuse-emulator/bugs/480/
-
Chuckie Egg 2 does not load with --detect-loader --no-accelerate-loader
-
So there are two problems here: 1) The patch messes with the code that decides whether to use loader acceleration, i.e. acceleration_detector() returns a different result with and without the patch. This is almost certainly what makes Lord of Chaos behave differently, and I bet it affects many other games. 2) Chuckie Egg 2 fails to load when "Detect loaders" is enabled and "Accelerate loaders" is disabled. This is a pre-existing problem, it's just that it's triggered because of (1). So, about (2):...
-
Ok so my earlier analysis was not so wrong after all. It seems that the problem can be reproduced without the patch if you use --detect-loader, unless you also add --accelerate-loader. Both options are enabled by default, so you need to unset the latter. In other words, with an empty .fuserc you can reproduce the problem like this: $ fuse --no-accelerate-loader Chuckie\ Egg\ 2.tzx My guess is that with the new patch the "accelerate loader" feature gets confused with this tape, so the option is not...
-
Ok, I must have been testing it incorrectly because you're right, I can reproduce the problem now. I'll investigate, sorry for the noise !
-
Hmm, actually with Lords of Chaos I do see a difference with these options (after removing the .fuserc config file): --accelerate-loader --fastload --traps Here the game loads very fast with and without the patch, but with the patch I can see the loading stripes for a brief moment. It doesn't really affect the loading process that much (it takes maybe half a second more) but there is definitely a difference. I'll try to debug it.
-
Ok, those are the two files that I was also testing. I tried with different command-line options and the problem that you describe with Chuckie Egg 2 (resets after loading) happens when I use --detect-loader regardless of whether I use the patch or not. I don't see that the patch is having any effect. With Lords of Chaos I also don't see any difference. If I enable tape traps then the loading screen appears immediately, but the data block after that loads at normal speed (or faster if I enable -...
-
No, sorry, Chuckie Egg 2 loads fine too. I was testing it with --detect-loader, and it fails with that option, but it works fine without it. Checking the TZX files I see that both Chuckie Egg 2 and Lords of Chaos contain only standard ROM blocks so I'm not even sure how this patch would have an effect.
-
Ok I can reproduce the problem with Chuckie Egg 2 (I haven't debugged it yet), but Lords os Chaos seems to work fine. Can you tell me the exact version that you used and the settings? I tried the only TZX available in WoS.
-
I haven't had the time to review your patch yet, but yes, ideally the tests should only use the public API and we should not export internal symbols. Anyway #433 is now closed, maybe you could open a new one so this patch does not fall through the cracks?
-
PZX files are broken on big-endian systems
-
libspectrum: Hide all symbols except the ones in the public API
-
Run libspectrum tests with 'make check'
-
I will have a look at those two and come back with my findings. Thanks!
-
I admit that the spec is a bit ambiguous. The 'current pulse level' after playing the blocks ID 10,11,12,13,14 or 19 is the opposite of the last pulse level played, so that a subsequent pulse will produce an edge. My understanding is that this is talking about when those blocks don't have an embedded pause, because you obviously want to be able to concatenate two data blocks without a pause between them. This also applies to 'Data' blocks that have some pause duration included in them. And what I...
-
No, they are independent things, you can actually try any combination of both test cases and both patches (Mask.tzx for #431 and trailing-pause-block.tzx for #458). I'll explain: Bug #458 deals with pauses: they should always produce an edge to ensure that the previous data block is correctly terminated. This should happen for trailing pauses in a data block and also for separate pause blocks (as in the attached test case). So this patch fixes the latter case by simply ensuring that a pause block...
-
Normally if you want to build Fuse you need to build libspectrum first. I skipped that part in this case because libspectrum is already available in Ubuntu, so you are using that one. However if you want to build the latest development version of Fuse you would also need to build the latest development version of libspectrum, because of some changes that Fuse had recently. In this case you only want the 4x scaler, so 9d8538c4 is the identifier of the latest change in Fuse that works with the version...
-
Hi, I don't know how familiar you are with this whole process so I'll try to use very simple instructions. If you're using Ubuntu I recommend that you install the Fuse packages already available in the distribution (they contain the ROMs and all other necessary files), and then build a more recent version of the emulator. So first make sure that you have at least fuse-emulator-gtk, fuse-emulator-common and spectrum-roms (if you were using Fuse you should have them already). Then you can download...
-
Hi, I can help you to build Fuse on Linux, what operating system are you using?
-
Hi, I think this proposal of embedding Python in Fuse would help you solve your problem: https://sourceforge.net/p/fuse-emulator/mailman/fuse-emulator-devel/thread/20180702214116.GA4088%40blackstar.local/#msg36358765 I'm just not sure about the current status of the implementation!
-
Hi, and thanks for the work! I gave it a quick test and the scalers look good, although I find them quite similar to each other. Do you have an example where their differences are very visible? (I think that we already have a lot of scalers in Fuse, and some don't look very good, but that's just my opinion). A few problems that I noticed with the patch: You made a reverse diff: the new scalers are removed, not added. I had to pass -R to patch or git apply. There are a lot of lines in the patch where...
-
Here's a quick fix. You still get the error message but Fuse "ejects" the missing cartridge and carries on. I'm not sure if I'm using the proper method to clear the setting, someone please review.
-
It works fine here for me on Linux/GTK, what operating system are you using?
-
From what we've seen it seems that adding SDL2 support can be done with a couple of not very big patches. There's no need to create a branch in the central repository for that. Individual developers can of course create a branch in their local repositories and do their work and tests there.
-
Hi, Alsa is always the default audio driver for the GTK UI. If you want to use SDL audio with the GTK UI you have to build Fuse with --with-audio-driver=sdl SDL can also be used for the joystick driver, so even if you use the GTK UI and Alsa audio Fuse will use SDL for the joystick. You can use --disable-ui-joystick to prevent that. EDIT: this is worth clarifying a bit more. Some UI libraries have their own joystick support. The SVGA UI has its own joystick code, the Win32 ui has its own joystick...
-
Hi, Alsa is always the default audio driver for the GTK UI. If you want to use SDL audio with the GTK UI you have to build Fuse with --with-audio-driver=sdl SDL can also be used for the joystick driver, so even if you use the GTK UI and Alsa audio Fuse will use SDL for the joystick. You can use --disable-ui-joystick to prevent that.
-
Hi, the master branch is where the main development happens. Once we have enough new features and fixes then a new version is released, and a tag (not a branch) with the new version number is created on the master branch. I'm not sure that I understant what you propose with keeping the master branch for actual stable release. All changes in the master branch are for the next release and are meant to be stable. For experimental development there are many other branches in the repository. The version...
-
Ok, here's the patch to add SDL 2 support for the audio and joystick drivers. SDL 2 is now selected by default but there's the new --disable-sdl2 option to select SDL 1 instead. The SDL UI still requires SDL 1, so if Fuse is built using --with-sdl then SDL 1 is also selected. One benefit of this is that users of the GTK UI don't need to depend on the obsolete SDL 1 library anymore, so I think this patch can already be applied (in fact I started using it for the Flatpak build because the Flatpak runtime...
-
Unfortunately I do not have resources to pursue the path of corectly enabling SDL2 into the fuse emulator without breaking other functions No problem, I can help with that part! :-) We actually have the situation that right now it's already possible to use SDL2 as long as it's only for the joystick and audio driver and not for the UI. So the GTK build can benefit from that. If you want I can prepare the necessary changes to configure.ac to support SDL2 for audio and joystick, and then we try to integrate...
-
Thanks for the new patch! A few things: This patch breaks joystick support. Passing --with-x --with-audio-driver=sdl should enable the GTK UI, SDL audio and joystick support (using also SDL). This works in master. There's three audio drivers now: sdl, sdl1 and sdl2. There should only be one. In general I would not treat SDL and SDL2 as two separate drivers, neither for audio nor for the UI. Bear in mind that it's not possible to use both SDL versions at the same time, you cannot have SDL1 UI and...
-
Ok, you can have a look at the current method in configure.ac: AM_PATH_SDL($SDL_VERSION, sdl_available=yes, sdl_available=no) and then use the value of $sdl_available as needed. You could use the same for SDL2 using AM_PATH_SDL2. Also, in Debian at least both SDL versions come with pkg-config files so you don't really need sdl.m4 or sdl2.m4 and you can use PKG_CHECK_MODULES instead: PKG_CHECK_MODULES([SDL2], [sdl2], [sdl2_available=yes], [sdl2_available=no]) But maybe there's a good reason why we...
-
It seems that it's not possible to use the GTK UI and the SDL audio driver now, is that intentional? Available audio drivers: alsa oss null I have SDL 1.2 and SDL 2 installed in my system. Without the patch: Available audio drivers: alsa sdl oss null
-
Oh, don't worry, it won't be necessary :-) I'm used to handling and reviewing large patches. Ideally the patch would need to apply on top of the current master branch (it seems to conflict with the recent changes in configure.ac), but no need to worry about that now. I can actually do that, I was the one making a lot of changes to configure.ac since Fuse 1.5.7 came out. Thanks again!
-
Hi! I just gave it a quick test, so far it seems to work fine, thanks !! When I have some time I would like to give a closer look to the code itself.
-
I think that patches belong here rather than in the discussion forum :) This is great stuff, thanks a lot for the work! There was some work on SDL2 already (patch #326) but I think it had some issues. I think Sergio Baldoví was the one testing it ?
-
Fix build with GCC 10: multiple definition of widget_options_settings
-
This looks like the same as this one (patch included there): https://support.dcmtk.org/redmine/issues/759
-
Hi, warning 1 seems legitimate. When BITS_IN_JSAMPLE is 16 then MAXJSAMPLE is 65535 and therefore after i > 55822 the result of FIX(0.58700) * i cannot be stored in a 32-bit signed integer. It would need to be unsigned at least.
-
Yes, just make sure that +D support is enabled in Options -> Peripherals -> Disk -> +D Interface.
-
You have to type RUN, not LOAD "".
-
I can load that with: fuse --plusd --plusddisk Scene+61-Disk1.img And then RUN from BASIC.
-
I think that we would need to see the actual contents of that file to see what kind of image it is.
-
That's great! I think I'll do the same changes in the Debian / Ubuntu packages.
-
The Scorpion ROMs (256s-0.rom to 256s-3.rom) include illegal modifications of the official Spectrum ROMS copyrighted by Amstrad, and Fuse does not distribute them. If you get them from somewhere you can tell Fuse to use them: Options -> Select ROMs -> Machine ROMs -> Scorpion ZS 256 Select all 4 ROM files from your hard drive, and then go to Options -> Save
-
ok, I uploaded the new Flatpak version. Please update and tell me if everything works fine now.
-
Thanks, any information that allows us to reproduce and/or work around the problem is actually useful, so I'm happy that you shared it with us. What I'm going to do when I have some minutes is to release a new Flatpak version using the SDL audio driver instead of ALSA. That should hopefully fix the problem.
-
I'm ok with committing the pulseaudio driver, although as you say it should not be the default. I just tested it now and, although it works, games feel noticeably jerkier. Take anything that should run smoothly (like Sabre Wulf or the title credits of Rescate Atlántida) and you'll see the difference.
-
I'll simplify because the Linux audio system has a lot of different components: ALSA is a library that applications can use to play sound (it's more than that, but let's leave it here). Pulseaudio is a software that receives audio from all running apps, mixes everything together and sends the output to the sound card. SDL is a library for writing games. It has an audio component but it simply sends the output to ALSA, PulseAudio, DirectX (in Windows), etc. So depending on how you combine all those...
-
Ok... sucks to have problems with the audio drivers. Some years ago it was the SDL driver that was having problems but lately it's seems that it's always ALSA. Maybe I should default to the SDL audio driver for fuse-gtk, what do you think Sergio? At least with SDL people can choose the actual audio driver on runtime using the environment variable.
-
Although you prefer the GTK version (so do I) the idea is to see if using SDL audio solves the problem. The GTK version uses ALSA by default, but it can be compiled to use SDL audio, so we could explore that option if it solves your problem (or if we don't do that in the official packages I can help you build fuse-emulator-gtk with SDL audio yourself).
-
Although you prefer the GTK version (so do I) the idea is to see if using SDL audio solves the problem. The GTK version uses ALSA by default, but it can be compiled to use SDL audio, so we could explore that option if it solves your problem (alternatively I can help you build fuse-emulator-gtk with SDL audio).
-
From Ubuntu, what package did you try? They use different audio libraries: fuse-emulator-gtk uses ALSA and fuse-emulator-sdl uses SDL. So since you seem to have problems with ALSA you could try SDL and see if things improve. Note also that SDL still uses a real audio driver internally, so you have to use SDL through PulseAudio, SDL through /dev/dsp, or SDL through ALSA. I'm not sure which one is the default, but you can select the one to use with the SDL_AUDIODRIVER environment variable, have a look...
-
The wave is not compressed, here's the encoding scheme: http://www.worldofspectrum.org/TZXformat.html#DIRECTREC
-
Hi, when you use Media->Tape->Record Start and Record Stop then Fuse records the raw output of the emulated Spectrum. That is, it does not record the bytes of your program (as you would have on a TAP file), but the complete audio signal (similar to recording a WAV file). This is useful for custom tape routines. However the TAP format cannot store that information, so you need to use save it as TZX. This will also take much more space on disk. If you are using the standard ROM tape routines and what...
-
I agree with Sergio's comment, and I have experienced this same problem when running Fuse inside a virtual machine. I don't think Flatpak makes a difference here.
-
PROPOSED PATCH v2 I had this half-written several months ago already, but it hasn't been until now that I found the time to finish it. My previous attempt confused the loader detection code so I decided to try a simpler approach this time. The idea is that if you play a tape you should always get the same signal with the same polarity, no matter if you start from the beginning or from a different point. This is necessary especially for games like MASK, that are polarity sensitive but are also multi-load....
-
This patch for libspectrum fixes the problem.
-
Tape loading error if there's a trailing pause block
-
Ok, I uploaded a workaround to Debian that defaults to X11 over Wayland when the former is available. This should be the least annoying option for users until we fix the Wayland problems completely. https://tracker.debian.org/news/1055211/accepted-fuse-emulator-157dfsg1-2-source-into-unstable/
-
Right, I see. Thanks!
-
I forgot to say: I have never used the Mir backend, I don't know how many users are out there, so I was just being conservative with the patch keeping the same backend order used by GTK.
-
If x11 is not available then it will continue with the rest of the backends on the list. The * at the end ensures that Wayland will also be tried. I suspect that most Wayland users have xwayland installed in case there's an app that only supports X11.
-
Sergio, what's this DISPLAY_ASPECT_WIDTH doing here? Shouldn't this be DISPLAY_SCREEN_WIDTH ??? int ui_init( int *argc, char ***argv ) { /* ... */ gtkui_drawing_area = gtk_drawing_area_new(); /* ... */ /* Set minimum size for drawing area */ gtk_widget_set_size_request( gtkui_drawing_area, DISPLAY_ASPECT_WIDTH, DISPLAY_SCREEN_HEIGHT );
-
I'm thinking that since this is a known problem that is already affecting users we could simply default to the X11 backend over the Wayland one until this is fixed. The attached patch does that. The list of backends is taken from the GTK code [1], I'm simply keeping the order but without Wayland. The user can override it by setting GDK_BACKEND=wayland. I'll probably apply this to the Debian package. [1] https://gitlab.gnome.org/GNOME/gtk/blob/3.24.5/gdk/gdkdisplaymanager.c#L266
-
Ok, thanks. It's not the first time that someone reports problems with Fuse and Wayland, I actually had to disable the Wayland socket in the Flatpak build for this reason (see https://github.com/flathub/net.sf.fuse_emulator/issues/1 and https://bugs.debian.org/872994). I haven't had the time yet to debug the problem and see what is really going on, but I suppose that a workaround for Wayland users would be to unset the WAYLAND_DISPLAY environment variable before running Fuse, e.g. $ WAYLAND_DISPLAY=""...
-
As Linux distributions continue moving towards Wayland (it's the default display server in Debian 10 "buster") more users will hit this bug. See e.g. https://sourceforge.net/p/fuse-emulator/discussion/314872/thread/3f0ae5443f/ and https://github.com/flathub/net.sf.fuse_emulator/issues/1.
-
I forgot: we also have a bug about this in the Fuse bug tracker: https://sourceforge.net/p/fuse-emulator/bugs/367/
-
Ok, thanks. It's not the first time that someone reports problems with Fuse and Wayland, I actually had to disable the Wayland socket in the Flatpak build for this reason (see https://github.com/flathub/net.sf.fuse_emulator/issues/1 and https://bugs.debian.org/872994). I haven't had the time yet to debug the problem and see what is really going on, but I suppose that a workaround for Wayland users would be to unset the WAYLAND_DISPLAY environment variable before running Fuse, e.g. $ WAYLAND_DISPLAY=""...
-
Are you using Wayland ? If so, can you try with X.org and see if that makes a difference ?
-
I don't see any side effect. I'll schedule for next release. I hope Phil or Fred could have a look. Yes, I'd like to have someone else reviewing it too. I just updated the patch with a longer description and ChangeLog entry.
-
The last patch is incorrect, it works for this test case but the libspectrum_tape_get_next_edge() call returns end-of-block too early with the last edge missing. I created a TZX file with two consecutive Raw Data blocks and this fails: without any patch because the last part of the first block has the level flag flipped, and it also fails with my previous patch because the last part is missing. Here's a new patch, with this one I can load all files without errors. Update 22 Jan: I uploaded the patch...
-
I managed to fix this accidentally while working on the fix for [bugs:#431], so after having a quick look at this game here's what I think it happens: After the basic code there's an 8643 byte loader that ends with a 7ms pause and is followed by a list of pulses of different lenghts (I suppose that this is a copy protection mechanism). Back to the 8643 byte loader: trap_load_block() puts the code in memory and updates all registers but doesn't touch the value of tape_microphone. Since libspectrum...
-
As you can see, tape2wav produces audio that is by far the outlier here. It is much longer than what is generated by Tapir I don't understand that, I just tried with tape2wav and WinTZX and the results have very similar length and size on my computer ... (around 670 KB). Fuse will skip the last bit of the audio generated by winTZX, but will load it if I invert the phase of the audio. I confirm that this is the same as [bugs:#369] and the patch that I posted there on the 11th of January solves the...
-
Sergio, did you try my patch from the 11th of January? That one solves the problem and doesn't have any side effect that I'm aware of. I think it is rather important because without it Fuse cannot load its own saved tapes.
-
Dan Dare has a significally longer loading time (x5) with these patches when traps are enabled. I see, the loader detection code gets confused after the changes I made to the pauses. I think I have a simpler idea to solve this whole problem, I'll try to write a new patch.
-
I've tested both patches with check_loaders (fuse-automation) and there are more tapes that can load succesfully: ActionForce II, 1942, Gryzor, Gauntlet II, Leader Board Par 3, MatchDay II, Outrun and SplATTR. They have bug entries at SF, so seems you have made a good progress here. Oh, but those were cases of tapes that could be loaded without acceleration but failed with some options enabled (detect loaders, traps, etc.). That's an unexpected side effect because I didn't debug that problem at all...
1 >