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

[fuse-emulator-devel] Fuse

[Bill B. <bla...@be...>]

I'm interested in learning something about the ZX Spectrum. More than 
just games, but I have to start somewhere. I've worked with many 
emulators. I installed fuse from my Linux distros software manager, it's 
version 1.6.0. I've read and watched videos. It seems very 
straightforward. I have the 48.rom. I watched a video that played Manic 
Miner. So I downloaded that in both tap and tzx format. Like the video I 
do File>Open>ManicMiner.tzx.zip. In the video it immediately begins to 
play. All I get it a return to the same initial screen. No errors...no 
messages...no nothing. I also tried Media>Tape>Open>ManicMiner.tap.zip 
then Play. I was told unzipping was unnecessary. But I also tried 
pointing to the unzipped files. I thought I'd start it from the command 
line to see if any messages pop up... but again nothing. However there 
was this email address that said
For help, please mail <fus...@li...>

Thanks for any help,
Bill

Re: [fuse-emulator-devel] Disciple Support on 128K Spectrum

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

Hi Gergely 
More than happy to, but it won’t let me create an account (whatever answers I give the security trivia question don't work and it goes in an endless loop asking same questions)
The help link says ro contact admins, but no way to do so…


Latest version temporarily here (1st row in table):
https://spectrumcomputing.co.uk/zxdb/add/public/history.php?user=disciplePalGuy&notproccesed=0&filetypefilter=0&filter_id=NaN


which when published will end up on this page:
https://spectrumcomputing.co.uk/index.php?cat=96&id=1000117


Happy for you to upload to https://sinclair.wiki.zxnet.co.uk/wiki/DISCiPLE  if you have access ?
It also has PlusD information too.

Alan

> On 1 Apr 2024, at 08:25, Szász Gergely via fuse-emulator-devel <fus...@li...> wrote:
> 
> Hi Alan,
> 
> Could you publish the PAL equivalent logic in https://sinclair.wiki.zxnet.co.uk
> 
> e.g. on the https://sinclair.wiki.zxnet.co.uk/wiki/DISCiPLE page or as an "Integrated Circuit" https://sinclair.wiki.zxnet.co.uk/wiki/Category:Integrated_Circuit
> 
> best regards,
> gergely
> 
> :)
> 
> On Tue, Mar 05, 2024 at 11:01:48PM +0000, Alan Pearson wrote:
>> Hi All,
>> 
>> 
>> I'm the guy wrote 'The Disciple PALs finally unveiled' and I found this thread discussing the issue on WoS by accident while trying to figure out why the disciple isn't working on FUSE in 128K mode.
>> https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1???
>> What an interesting thread , and i was shocked to see my doc referenced.
>> I haven???t been able to create an account on WoS to reply there, it seems the admin may have gone on holiday or something???. so I came here.
>> 
>> First, the document:
>> 1) This was a direct reverse engineer of working PAL chips, put on a logic analyser by Rudy Biesma, then turned into the equations manually by myself then jedec files created.
>> 2) All the findings & equations seem to correspond to known info about the disciple (manual, Ramsoft guide and Rudy's disassembly)
>> 3) The proof however was in real world testing - I repaired a broken disciple by programming the PAL chips with the jedec files created and it works perfectly on a 128k +2 (grey).
>> 4) There is a typo... N1 should be M1 throughout the doc, but I think you guys worked that out already
>> 
>> Now, from my reading of the WoS thread and the Rudy disassembly, it seems there is no way the disciple should work on a 128K (at least no way it should initialise)... but it does.
>> The code path just doesn't make sense on a 128K machine at reset time.
>> 
>> Let's change tact - the PlusD uses EXACTLY the same initialisation code, lands in the same place in the ROM when it unpages itself at reset (location #52) and makes no attempt (on reset at least) to figure out if it's a 1128K or 48K or 128k spectrum or which spectrum rom is in.
>> How does the plusD then work under FUSE ? It's very weird.
>> It's worth saying that the PlusD does have routines specific to 128K paging/unpaging but they are only used when the COPY command finishes and the machine resets after completion.
>> The PlusD TO_NEW routine essentially jumps to location #C7 on a 128k (reset routine in the editor ROM) or #11B7 in 48K. 
>> Relevant routines below, but as I said they are NOT called when the system resets.
>> 
>> From Rudy's +D disassembly :
>> 
>> THE 'UNPAGE 128 ROM' SUBROUTINE
>> This routine pages out the +D system and returns to the 128K ROM at address #0049. That
>> address contains a RET instruction so the effect is a jump to BC with the 128K ROM paged
>> in. 
>> 
>> 0046 UNPAGE_BC  PUSH BC                  Stack return address.
>> 0047 UNPAGE_0   OUT  (231),A             Page out +D system.
>> 0049            RET                      ? This statement is not reached from
>>                                         above.
>> 004A            DEFB #00,#00,#00,#00,#00 Unused locations.
>> 
>> THE 'NEW' PATCH
>> When the file copy command is finished the +D jumps to the 'NEW' routine. With System 2a
>> a selection is made for 48K or 128K 'NEW'
>> 
>> 3137 TO_NEW     BIT  4,(IY+1)            Jump if not in 128K mode HL contains
>> 313B            JP   Z,#004F,UNPAGE_HL   #11B7, the address of 48K 'NEW'.
>> 313E            CALL #5B00,SWAP          Call the paging subroutine of the 128.
>> 3141            DI
>> 3142            LD   BC,#00C7            Address of 128 'NEW' routine.
>> 3145            JP   #0046,UNPAGE_BC
>> 
>> 
>> 
>> Regarding the PALs, I suspect the equations are right, and the fact the code exists in both the +d and Disciple to initialise them suggests that it should be used, so I don't think this is a problem of paging in the interfaces at the wrong time. That said, I can't see how it all should work on a 128, but it does. So this can't be a disciple specific problem, can we trace the +D codepath in FUSE in  128K mode?? I'm not sure how to do this myself.
>> 
>> 
>> It would be great to see Disciple working in 128K models... there are difference between the interfaces that I've run into in converting a program to load from disc (specifically the interface 1 hook code #32, which does a RET on the disciple, but on the PlusD allows any ROM addresss to be called via DE register)
>> 
>> I know this is a horrible kludge, but can we not monitor location #52 on both inrwefaces and if we have a 128K ROM paged in, simply jump to #00C7 after the OUT instruction ?
>> 
>> 
>> 
>> Any thoughts ?
>> 
>> Alan
> 
> 
>> _______________________________________________
>> 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] Disciple Support on 128K Spectrum

[Szász G. <sz...@hu...>]

Hi Alan,

Could you publish the PAL equivalent logic in https://sinclair.wiki.zxnet.co.uk

e.g. on the https://sinclair.wiki.zxnet.co.uk/wiki/DISCiPLE page or as an "Integrated Circuit" https://sinclair.wiki.zxnet.co.uk/wiki/Category:Integrated_Circuit

best regards,
gergely

:)

On Tue, Mar 05, 2024 at 11:01:48PM +0000, Alan Pearson wrote:
> Hi All,
> 
> 
> I'm the guy wrote 'The Disciple PALs finally unveiled' and I found this thread discussing the issue on WoS by accident while trying to figure out why the disciple isn't working on FUSE in 128K mode.
> https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1???
> What an interesting thread , and i was shocked to see my doc referenced.
> I haven???t been able to create an account on WoS to reply there, it seems the admin may have gone on holiday or something???. so I came here.
> 
> First, the document:
> 1) This was a direct reverse engineer of working PAL chips, put on a logic analyser by Rudy Biesma, then turned into the equations manually by myself then jedec files created.
> 2) All the findings & equations seem to correspond to known info about the disciple (manual, Ramsoft guide and Rudy's disassembly)
> 3) The proof however was in real world testing - I repaired a broken disciple by programming the PAL chips with the jedec files created and it works perfectly on a 128k +2 (grey).
> 4) There is a typo... N1 should be M1 throughout the doc, but I think you guys worked that out already
> 
> Now, from my reading of the WoS thread and the Rudy disassembly, it seems there is no way the disciple should work on a 128K (at least no way it should initialise)... but it does.
> The code path just doesn't make sense on a 128K machine at reset time.
> 
> Let's change tact - the PlusD uses EXACTLY the same initialisation code, lands in the same place in the ROM when it unpages itself at reset (location #52) and makes no attempt (on reset at least) to figure out if it's a 1128K or 48K or 128k spectrum or which spectrum rom is in.
> How does the plusD then work under FUSE ? It's very weird.
> It's worth saying that the PlusD does have routines specific to 128K paging/unpaging but they are only used when the COPY command finishes and the machine resets after completion.
> The PlusD TO_NEW routine essentially jumps to location #C7 on a 128k (reset routine in the editor ROM) or #11B7 in 48K. 
> Relevant routines below, but as I said they are NOT called when the system resets.
> 
> From Rudy's +D disassembly :
> 
> THE 'UNPAGE 128 ROM' SUBROUTINE
> This routine pages out the +D system and returns to the 128K ROM at address #0049. That
> address contains a RET instruction so the effect is a jump to BC with the 128K ROM paged
> in. 
> 
> 0046 UNPAGE_BC  PUSH BC                  Stack return address.
> 0047 UNPAGE_0   OUT  (231),A             Page out +D system.
> 0049            RET                      ? This statement is not reached from
>                                          above.
> 004A            DEFB #00,#00,#00,#00,#00 Unused locations.
> 
> THE 'NEW' PATCH
> When the file copy command is finished the +D jumps to the 'NEW' routine. With System 2a
> a selection is made for 48K or 128K 'NEW'
> 
> 3137 TO_NEW     BIT  4,(IY+1)            Jump if not in 128K mode HL contains
> 313B            JP   Z,#004F,UNPAGE_HL   #11B7, the address of 48K 'NEW'.
> 313E            CALL #5B00,SWAP          Call the paging subroutine of the 128.
> 3141            DI
> 3142            LD   BC,#00C7            Address of 128 'NEW' routine.
> 3145            JP   #0046,UNPAGE_BC
> 
> 
> 
> Regarding the PALs, I suspect the equations are right, and the fact the code exists in both the +d and Disciple to initialise them suggests that it should be used, so I don't think this is a problem of paging in the interfaces at the wrong time. That said, I can't see how it all should work on a 128, but it does. So this can't be a disciple specific problem, can we trace the +D codepath in FUSE in  128K mode?? I'm not sure how to do this myself.
> 
> 
> It would be great to see Disciple working in 128K models... there are difference between the interfaces that I've run into in converting a program to load from disc (specifically the interface 1 hook code #32, which does a RET on the disciple, but on the PlusD allows any ROM addresss to be called via DE register)
> 
> I know this is a horrible kludge, but can we not monitor location #52 on both inrwefaces and if we have a 128K ROM paged in, simply jump to #00C7 after the OUT instruction ?
> 
> 
> 
> Any thoughts ?
> 
> Alan


> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel

Re: [fuse-emulator-devel] Saving a snapshot right after the tape load ends

[Andre L. <an...@le...>]

0x0805 is what I needed, thanks!

On 2024-03-27 13:16, Alexander Lyashuk wrote:
> When loading images, I remember I had success with first pausing the 
> fuse and then opening the file.
> If you load data from tape in "real-time", I suspect that putting a 
> breakpoint at address 0x34BB should help (if you want to catch the 
> moment a BASIC loader calls the CODE block, 
> https://skoolkid.github.io/rom/asm/34B3.html; if you want to capture a 
> moment the loader returns to BASIC after loading a module, it's likely 
> be address 0x0805, https://skoolkid.github.io/rom/asm/0802.html).
>
>
> Am Mi., 27. März 2024 um 13:34 Uhr schrieb Andre Leiradella 
> <an...@le...>:
>
>     Hi All,
>
>     It's as the subject says, is it possible to save a snapshot right
>     at the
>     point where the tape finishes loading?
>
>     The game in question uses standard ROM loading routines.
>
>     Thanks,
>
>     Andre
>
>
>
>     _______________________________________________
>     fuse-emulator-devel mailing list
>     fus...@li...
>     https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>

Re: [fuse-emulator-devel] Saving a snapshot right after the tape load ends

[Alexander L. <moo...@gm...>]

When loading images, I remember I had success with first pausing the fuse
and then opening the file.
If you load data from tape in "real-time", I suspect that putting a
breakpoint at address 0x34BB should help (if you want to catch the moment a
BASIC loader calls the CODE block,
https://skoolkid.github.io/rom/asm/34B3.html;  if you want to capture a
moment the loader returns to BASIC after loading a module, it's likely be
address 0x0805, https://skoolkid.github.io/rom/asm/0802.html).


Am Mi., 27. März 2024 um 13:34 Uhr schrieb Andre Leiradella <
an...@le...>:

> Hi All,
>
> It's as the subject says, is it possible to save a snapshot right at the
> point where the tape finishes loading?
>
> The game in question uses standard ROM loading routines.
>
> Thanks,
>
> Andre
>
>
>
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>

[fuse-emulator-devel] Saving a snapshot right after the tape load ends

[Andre L. <an...@le...>]

Hi All,

It's as the subject says, is it possible to save a snapshot right at the 
point where the tape finishes loading?

The game in question uses standard ROM loading routines.

Thanks,

Andre

Re: [fuse-emulator-devel] Disciple Support on 128K Spectrum

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

Thank you very much for this.

Shame the Disciple guy is not active, but hopefully this is all that is needed.
Do you know if the guy who does the MAC port is still around ? I’d love to get a Mac build with this enabled, but failed to be able to do so myself (I did email him)

Alan


> On 23 Mar 2024, at 06:08, Sergio Baldoví <ser...@gm...> wrote:
> 
> Thank you for your feedback. Unfortunately the guy that worked on DISCiPLE emulation is not active these days.
> 
> DISCiPLE ROM is by default located at 0x0000 except when memory is swapped by 0x7b port. Maybe you have detected a situation where it shouldn't be swapped.
> 
> I've disabled the trap at 0x0001 and DISCiPLE seems to work on a 128K, at least with FORMAT and CAT commands, but I think we can do something clever to enable trap 0x0001 when the machine hasn't been reset. See patch 441:
> https://sourceforge.net/p/fuse-emulator/patches/441/
> 
> El dom, 17 mar 2024 a las 0:02, Alan Pearson (<ala...@gm... <mailto:ala...@gm...>>) escribió:
>> Replying to my own post in case anyone is listening.
>> 
>> 
>> There are two questions that need answered to get disciple working on 128K:
>> 
>> 1) Does the Disciple ROM get paged in when PC hits 0001 ? If so, this undoubtedly runs code that won't work when on 128K and ROM0 (128 editor) is in, and ends up calling a 48K ROM NEW routine.
>> 2) Does the Disciple ROM get paged in on RESET ?
>> 
>> Answers
>> 1) I can conclusively say YES, the Disciple ROM gets paged in when PC hits 0001 - EXCEPT when machine is RESET. I've proven this two ways - (1) Recheck the PAL decoding - this is correct and there is no way it won't get paged in when address bus hits 0001 and (2) on a REAL 128K machine by running machine code which pages in EDITOR ROM and then JP to location 0. With Disciple not attached the machine initialises as expected back to the menu system. With the Disciple attached the machine crashes. With Disciple inhibited machine goes back to menu system as expected. This proves beyond a shadow of a doubt that the Disciple is paged in when PC=0001
>> 
>> 2) The Disciple gets PAGED OUT on a RESET. The PAL equations prove this, and I've updated the doc with this correction. In RESET the Disciple never sees or reacts to PC=00001 as I'm guessing the reset line stays LOW longer than it takes the PC to advance past 0001, keeping the Disciple OUT via PAL logic. This is obviously a race condition and I've no reason to believe this would be different on a 48K machine.
>> 
>> I also noticed FUSE puts the Disiple ROM at 0x2000 and RAM at 0x0000 which is incorrect - in normal operation ROM should be at 0x0000, and if the Disciple Boot Flip Flop flips them, then it means System needs reloaded,
>> Described here by RAMSOFT:
>> 3.1 DISCiPLE PORT 7Bh AND MEMORY ADDRESSES ==========================================
>> Port 7Bh (123 decimal) is available only on the DISCiPLE and has a flip flop attached to it. It can be used to swap the RAM/ROM addresses in this way:
>> Access ROM RAM Purpose
>> IN 0x0000 0x2000 reset ff OUT 0x2000 0x0000 set ff
>> This feature is used by GDOS to know if it necessary to load the system
>> file from disk on boot or after two consecutive resets without any DOS command between them; UNIDOS ignores this feature, so any swap attempt will result in a system crash.
>> In GDOS there is a variable located in RAM at offset 0x1DE4 that is set to
>> 0x44 ('D') after a BASIC syntax check (i.e. after a RST 08h with a code lower than 1Bh) and after a bootstrap: this variable indicates that the DOS services have been called almost once. Whenever the user resets the computer, the flip flop attached to port 7Bh is reset, so the ROM will be placed at 0x0000. When the first interrupt occurs, the keyboard scanning routine is called at 0x028E
>> and the DISCiPLE memory is automatically paged in. At offset 0x028E in the DISCiPLE's ROM there's a routine that checks if the variable we said above holds 0x44: if it's the case, then the same routine puts 00h in there to say
>> that DOS services haven't been called since last reset; otherwise the routine
>> sets the variable to 0x53 ('S') and copies the first 2335 (0x091F) bytes of
>> ROM in the RAM: in this case the system file has to be loaded again.
>> When all is finished, the memories will be swapped again (i.e. the flip flop
>> will be set) by OUTing to port 7Bh, the DISCiPLE paged out by OUTing to port BBh and the keyscan routine is finally executed.
>> INning from port 7Bh has the same meaning of a system reset for the DOS, so after reading 2 times from port 7Bh without typing a DOS command between them the system file needs to be reloaded.
>> NOTE that since all this is based on the keyscan routine in the Spectrum's ROM, nothing will happen by INning from port 7Bh if the call is not performed (i.e. if interrupts are disabled in IM 1 or we're not in IM 1 or keyboard is scanned in a custom way); however the last operation with port 7Bh must be an OUT before the routine in the ROM is executed if you want to keep the system safe by resetting once.
>> 
>> So to get this working under emulation in 128K mode, we need to do things:
>> 
>> 1) Not page the disciple in when it hits location 0001 (easiest not to do it in any circumstances)
>> 2) Change the ROM to be located at 0x0000 and observe the function of the flip flop as described above.
>> 
>> I’ve updated the Disciple pals document and it should be available here shortly : 
>> DISCiPLE Interface at Spectrum Computing - Sinclair ZX Spectrum games, software and hardware
>> spectrumcomputing.co.uk
>> <apple-touch-icon.png>
>>  <https://spectrumcomputing.co.uk/entry/1000117/Hardware/DISCiPLE_Interface>DISCiPLE Interface at Spectrum Computing - Sinclair ZX Spectrum games, software and hardware <https://spectrumcomputing.co.uk/entry/1000117/Hardware/DISCiPLE_Interface>
>> spectrumcomputing.co.uk <https://spectrumcomputing.co.uk/entry/1000117/Hardware/DISCiPLE_Interface>	<apple-touch-icon.png> <https://spectrumcomputing.co.uk/entry/1000117/Hardware/DISCiPLE_Interface>
>>  
>> Anyone out there who can make this happen in FUSE ?
>> 
>> 
>>> On 5 Mar 2024, at 23:01, Alan Pearson <ala...@gm... <mailto:ala...@gm...>> wrote:
>>> 
>>> Hi All,
>>> 
>>> 
>>> I'm the guy wrote 'The Disciple PALs finally unveiled' and I found this thread discussing the issue on WoS by accident while trying to figure out why the disciple isn't working on FUSE in 128K mode.
>>> The Disciple clone... doable?
>>> worldofspectrum.org
>>> <LVRVCSMJENQX.jpg>
>>>  <https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1>The Disciple clone... doable? <https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1>
>>> worldofspectrum.org <https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1>	<LVRVCSMJENQX.jpg> <https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1>
>>> What an interesting thread , and i was shocked to see my doc referenced.
>>> I haven’t been able to create an account on WoS to reply there, it seems the admin may have gone on holiday or something…. so I came here.
>>> 
>>> First, the document:
>>> 1) This was a direct reverse engineer of working PAL chips, put on a logic analyser by Rudy Biesma, then turned into the equations manually by myself then jedec files created.
>>> 2) All the findings & equations seem to correspond to known info about the disciple (manual, Ramsoft guide and Rudy's disassembly)
>>> 3) The proof however was in real world testing - I repaired a broken disciple by programming the PAL chips with the jedec files created and it works perfectly on a 128k +2 (grey).
>>> 4) There is a typo... N1 should be M1 throughout the doc, but I think you guys worked that out already
>>> 
>>> Now, from my reading of the WoS thread and the Rudy disassembly, it seems there is no way the disciple should work on a 128K (at least no way it should initialise)... but it does.
>>> The code path just doesn't make sense on a 128K machine at reset time.
>>> 
>>> Let's change tact - the PlusD uses EXACTLY the same initialisation code, lands in the same place in the ROM when it unpages itself at reset (location #52) and makes no attempt (on reset at least) to figure out if it's a 1128K or 48K or 128k spectrum or which spectrum rom is in.
>>> How does the plusD then work under FUSE ? It's very weird.
>>> It's worth saying that the PlusD does have routines specific to 128K paging/unpaging but they are only used when the COPY command finishes and the machine resets after completion.
>>> The PlusD TO_NEW routine essentially jumps to location #C7 on a 128k (reset routine in the editor ROM) or #11B7 in 48K. 
>>> Relevant routines below, but as I said they are NOT called when the system resets.
>>> 
>>> From Rudy's +D disassembly :
>>> 
>>> THE 'UNPAGE 128 ROM' SUBROUTINE
>>> This routine pages out the +D system and returns to the 128K ROM at address #0049. That
>>> address contains a RET instruction so the effect is a jump to BC with the 128K ROM paged
>>> in. 
>>> 
>>> 0046 UNPAGE_BC  PUSH BC                  Stack return address.
>>> 0047 UNPAGE_0   OUT  (231),A             Page out +D system.
>>> 0049            RET                      ? This statement is not reached from
>>>                                          above.
>>> 004A            DEFB #00,#00,#00,#00,#00 Unused locations.
>>> 
>>> THE 'NEW' PATCH
>>> When the file copy command is finished the +D jumps to the 'NEW' routine. With System 2a
>>> a selection is made for 48K or 128K 'NEW'
>>> 
>>> 3137 TO_NEW     BIT  4,(IY+1)            Jump if not in 128K mode HL contains
>>> 313B            JP   Z,#004F,UNPAGE_HL   #11B7, the address of 48K 'NEW'.
>>> 313E            CALL #5B00,SWAP          Call the paging subroutine of the 128.
>>> 3141            DI
>>> 3142            LD   BC,#00C7            Address of 128 'NEW' routine.
>>> 3145            JP   #0046,UNPAGE_BC
>>> 
>>> 
>>> 
>>> Regarding the PALs, I suspect the equations are right, and the fact the code exists in both the +d and Disciple to initialise them suggests that it should be used, so I don't think this is a problem of paging in the interfaces at the wrong time. That said, I can't see how it all should work on a 128, but it does. So this can't be a disciple specific problem, can we trace the +D codepath in FUSE in  128K mode?? I'm not sure how to do this myself.
>>> 
>>> 
>>> It would be great to see Disciple working in 128K models... there are difference between the interfaces that I've run into in converting a program to load from disc (specifically the interface 1 hook code #32, which does a RET on the disciple, but on the PlusD allows any ROM addresss to be called via DE register)
>>> 
>>> I know this is a horrible kludge, but can we not monitor location #52 on both inrwefaces and if we have a 128K ROM paged in, simply jump to #00C7 after the OUT instruction ?
>>> 
>>> 
>>> 
>>> Any thoughts ?
>>> 
>>> Alan
>> 
>> _______________________________________________
>> fuse-emulator-devel mailing list
>> fus...@li... <mailto:fus...@li...>
>> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel

Re: [fuse-emulator-devel] Disciple Support on 128K Spectrum

[Sergio B. <ser...@gm...>]

Thank you for your feedback. Unfortunately the guy that worked on DISCiPLE
emulation is not active these days.

DISCiPLE ROM is by default located at 0x0000 except when memory is swapped
by 0x7b port. Maybe you have detected a situation where it shouldn't be
swapped.

I've disabled the trap at 0x0001 and DISCiPLE seems to work on a 128K, at
least with FORMAT and CAT commands, but I think we can do something clever
to enable trap 0x0001 when the machine hasn't been reset. See patch 441:
https://sourceforge.net/p/fuse-emulator/patches/441/

El dom, 17 mar 2024 a las 0:02, Alan Pearson (<ala...@gm...>)
escribió:

> Replying to my own post in case anyone is listening.
>
>
> There are two questions that need answered to get disciple working on 128K:
>
> 1) Does the Disciple ROM get paged in when PC hits 0001 ? If so, this
> undoubtedly runs code that won't work when on 128K and ROM0 (128 editor) is
> in, and ends up calling a 48K ROM NEW routine.
> 2) Does the Disciple ROM get paged in on RESET ?
>
> Answers
> 1) I can conclusively say YES, the Disciple ROM gets paged in when PC hits
> 0001 - EXCEPT when machine is RESET. I've proven this two ways - (1)
> Recheck the PAL decoding - this is correct and there is no way it won't get
> paged in when address bus hits 0001 and (2) on a REAL 128K machine by
> running machine code which pages in EDITOR ROM and then JP to location 0.
> With Disciple not attached the machine initialises as expected back to the
> menu system. With the Disciple attached the machine crashes. With Disciple
> inhibited machine goes back to menu system as expected. This proves beyond
> a shadow of a doubt that the Disciple is paged in when PC=0001
>
> 2) The Disciple gets PAGED OUT on a RESET. The PAL equations prove this,
> and I've updated the doc with this correction. In RESET the Disciple never
> sees or reacts to PC=00001 as I'm guessing the reset line stays LOW longer
> than it takes the PC to advance past 0001, keeping the Disciple OUT via PAL
> logic. This is obviously a race condition and I've no reason to believe
> this would be different on a 48K machine.
>
> I also noticed FUSE puts the Disiple ROM at 0x2000 and RAM at 0x0000 which
> is incorrect - in normal operation ROM should be at 0x0000, and if the
> Disciple Boot Flip Flop flips them, then it means System needs reloaded,
> Described here by RAMSOFT:
> ------------------------------
> 3.1 DISCiPLE PORT 7Bh AND MEMORY ADDRESSES
> ==========================================
> Port 7Bh (123 decimal) is available only on the DISCiPLE and has a flip
> flop attached to it. It can be used to swap the RAM/ROM addresses in this
> way:
> Access ROM RAM Purpose
> ------------------------------
> IN 0x0000 0x2000 reset ff OUT 0x2000 0x0000 set ff
> This feature is used by GDOS to know if it necessary to load the system
> file from disk on boot or after two consecutive resets without any DOS
> command between them; UNIDOS ignores this feature, so any swap attempt will
> result in a system crash.
> In GDOS there is a variable located in RAM at offset 0x1DE4 that is set to
> 0x44 ('D') after a BASIC syntax check (i.e. after a RST 08h with a code
> lower than 1Bh) and after a bootstrap: this variable indicates that the DOS
> services have been called almost once. Whenever the user resets the
> computer, the flip flop attached to port 7Bh is reset, so the ROM will be
> placed at 0x0000. When the first interrupt occurs, the keyboard scanning
> routine is called at 0x028E
> and the DISCiPLE memory is automatically paged in. At offset 0x028E in the
> DISCiPLE's ROM there's a routine that checks if the variable we said above
> holds 0x44: if it's the case, then the same routine puts 00h in there to say
> that DOS services haven't been called since last reset; otherwise the
> routine
> sets the variable to 0x53 ('S') and copies the first 2335 (0x091F) bytes of
> ROM in the RAM: in this case the system file has to be loaded again.
> When all is finished, the memories will be swapped again (i.e. the flip
> flop
> will be set) by OUTing to port 7Bh, the DISCiPLE paged out by OUTing to
> port BBh and the keyscan routine is finally executed.
> INning from port 7Bh has the same meaning of a system reset for the DOS,
> so after reading 2 times from port 7Bh without typing a DOS command between
> them the system file needs to be reloaded.
> NOTE that since all this is based on the keyscan routine in the Spectrum's
> ROM, nothing will happen by INning from port 7Bh if the call is not
> performed (i.e. if interrupts are disabled in IM 1 or we're not in IM 1 or
> keyboard is scanned in a custom way); however the last operation with port
> 7Bh must be an OUT before the routine in the ROM is executed if you want to
> keep the system safe by resetting once.
> ------------------------------
>
> So to get this working under emulation in 128K mode, we need to do things:
>
> 1) Not page the disciple in when it hits location 0001 (easiest not to do
> it in any circumstances)
> 2) Change the ROM to be located at 0x0000 and observe the function of the
> flip flop as described above.
>
> I’ve updated the Disciple pals document and it should be available here
> shortly :
> DISCiPLE Interface at Spectrum Computing - Sinclair ZX Spectrum games,
> software and hardware
> <https://spectrumcomputing.co.uk/entry/1000117/Hardware/DISCiPLE_Interface>
> spectrumcomputing.co.uk
> <https://spectrumcomputing.co.uk/entry/1000117/Hardware/DISCiPLE_Interface>
> [image: apple-touch-icon.png]
> <https://spectrumcomputing.co.uk/entry/1000117/Hardware/DISCiPLE_Interface>
> <https://spectrumcomputing.co.uk/entry/1000117/Hardware/DISCiPLE_Interface>
>
>
> Anyone out there who can make this happen in FUSE ?
>
>
> On 5 Mar 2024, at 23:01, Alan Pearson <ala...@gm...> wrote:
>
> Hi All,
>
>
> I'm the guy wrote 'The Disciple PALs finally unveiled' and I found this
> thread discussing the issue on WoS by accident while trying to figure out
> why the disciple isn't working on FUSE in 128K mode.
> The Disciple clone... doable?
> <https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1>
> worldofspectrum.org
> <https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1>
> <LVRVCSMJENQX.jpg>
> <https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1>
> <https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1>
> What an interesting thread , and i was shocked to see my doc referenced.
> I haven’t been able to create an account on WoS to reply there, it seems
> the admin may have gone on holiday or something…. so I came here.
>
> First, the document:
> 1) This was a direct reverse engineer of working PAL chips, put on a logic
> analyser by Rudy Biesma, then turned into the equations manually by myself
> then jedec files created.
> 2) All the findings & equations seem to correspond to known info about the
> disciple (manual, Ramsoft guide and Rudy's disassembly)
> 3) The proof however was in real world testing - I repaired a broken
> disciple by programming the PAL chips with the jedec files created and it
> works perfectly on a 128k +2 (grey).
> 4) There is a typo... N1 should be M1 throughout the doc, but I think you
> guys worked that out already
>
> Now, from my reading of the WoS thread and the Rudy disassembly, it seems
> there is no way the disciple should work on a 128K (at least no way it
> should initialise)... but it does.
> The code path just doesn't make sense on a 128K machine at reset time.
>
> Let's change tact - the PlusD uses EXACTLY the same initialisation code,
> lands in the same place in the ROM when it unpages itself at reset
> (location #52) and makes no attempt (on reset at least) to figure out if
> it's a 1128K or 48K or 128k spectrum or which spectrum rom is in.
> How does the plusD then work under FUSE ? It's very weird.
> It's worth saying that the PlusD does have routines specific to 128K
> paging/unpaging but they are only used when the COPY command finishes and
> the machine resets after completion.
> The PlusD TO_NEW routine essentially jumps to location #C7 on a 128k
> (reset routine in the editor ROM) or #11B7 in 48K.
> Relevant routines below, but as I said they are NOT called when the system
> resets.
>
> From Rudy's +D disassembly :
>
> THE 'UNPAGE 128 ROM' SUBROUTINE
> This routine pages out the +D system and returns to the 128K ROM at
> address #0049. That
> address contains a RET instruction so the effect is a jump to BC with the
> 128K ROM paged
> in.
>
> 0046 UNPAGE_BC  PUSH BC                  Stack return address.
> 0047 UNPAGE_0   OUT  (231),A             Page out +D system.
> 0049            RET                      ? This statement is not reached
> from
>                                          above.
> 004A            DEFB #00,#00,#00,#00,#00 Unused locations.
>
> THE 'NEW' PATCH
> When the file copy command is finished the +D jumps to the 'NEW' routine.
> With System 2a
> a selection is made for 48K or 128K 'NEW'
>
> 3137 TO_NEW     BIT  4,(IY+1)            Jump if not in 128K mode HL
> contains
> 313B            JP   Z,#004F,UNPAGE_HL   #11B7, the address of 48K 'NEW'.
> 313E            CALL #5B00,SWAP          Call the paging subroutine of the
> 128.
> 3141            DI
> 3142            LD   BC,#00C7            Address of 128 'NEW' routine.
> 3145            JP   #0046,UNPAGE_BC
>
>
>
> Regarding the PALs, I suspect the equations are right, and the fact the
> code exists in both the +d and Disciple to initialise them suggests that it
> should be used, so I don't think this is a problem of paging in the
> interfaces at the wrong time. That said, I can't see how it all should work
> on a 128, but it does. So this can't be a disciple specific problem, can we
> trace the +D codepath in FUSE in  128K mode?? I'm not sure how to do this
> myself.
>
>
> It would be great to see Disciple working in 128K models... there are
> difference between the interfaces that I've run into in converting a
> program to load from disc (specifically the interface 1 hook code #32,
> which does a RET on the disciple, but on the PlusD allows any ROM addresss
> to be called via DE register)
>
> I know this is a horrible kludge, but can we not monitor location #52 on
> both inrwefaces and if we have a 128K ROM paged in, simply jump to #00C7
> after the OUT instruction ?
>
>
>
> Any thoughts ?
>
> Alan
>
>
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel
>

Re: [fuse-emulator-devel] Disciple Support on 128K Spectrum

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

On Sat, 16 Mar 2024 21:31:44 +0000
Alan Pearson <ala...@gm...> wrote:

> Replying to my own post in case anyone is listening.
> 
> 
> There are two questions that need answered to get disciple working on 128K:
> 
> 1) Does the Disciple ROM get paged in when PC hits 0001 ? If so, this undoubtedly runs code that won't work when on 128K and ROM0 (128 editor) is in, and ends up calling a 48K ROM NEW routine.

You probably want to just fork it (but pick up all the unmerged patches
in Linux distribution trees).

Alan

Re: [fuse-emulator-devel] Disciple Support on 128K Spectrum

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

Replying to my own post in case anyone is listening.


There are two questions that need answered to get disciple working on 128K:

1) Does the Disciple ROM get paged in when PC hits 0001 ? If so, this undoubtedly runs code that won't work when on 128K and ROM0 (128 editor) is in, and ends up calling a 48K ROM NEW routine.
2) Does the Disciple ROM get paged in on RESET ?

Answers
1) I can conclusively say YES, the Disciple ROM gets paged in when PC hits 0001 - EXCEPT when machine is RESET. I've proven this two ways - (1) Recheck the PAL decoding - this is correct and there is no way it won't get paged in when address bus hits 0001 and (2) on a REAL 128K machine by running machine code which pages in EDITOR ROM and then JP to location 0. With Disciple not attached the machine initialises as expected back to the menu system. With the Disciple attached the machine crashes. With Disciple inhibited machine goes back to menu system as expected. This proves beyond a shadow of a doubt that the Disciple is paged in when PC=0001

2) The Disciple gets PAGED OUT on a RESET. The PAL equations prove this, and I've updated the doc with this correction. In RESET the Disciple never sees or reacts to PC=00001 as I'm guessing the reset line stays LOW longer than it takes the PC to advance past 0001, keeping the Disciple OUT via PAL logic. This is obviously a race condition and I've no reason to believe this would be different on a 48K machine.

I also noticed FUSE puts the Disiple ROM at 0x2000 and RAM at 0x0000 which is incorrect - in normal operation ROM should be at 0x0000, and if the Disciple Boot Flip Flop flips them, then it means System needs reloaded,
Described here by RAMSOFT:
3.1 DISCiPLE PORT 7Bh AND MEMORY ADDRESSES ==========================================
Port 7Bh (123 decimal) is available only on the DISCiPLE and has a flip flop attached to it. It can be used to swap the RAM/ROM addresses in this way:
Access ROM RAM Purpose
IN 0x0000 0x2000 reset ff OUT 0x2000 0x0000 set ff
This feature is used by GDOS to know if it necessary to load the system
file from disk on boot or after two consecutive resets without any DOS command between them; UNIDOS ignores this feature, so any swap attempt will result in a system crash.
In GDOS there is a variable located in RAM at offset 0x1DE4 that is set to
0x44 ('D') after a BASIC syntax check (i.e. after a RST 08h with a code lower than 1Bh) and after a bootstrap: this variable indicates that the DOS services have been called almost once. Whenever the user resets the computer, the flip flop attached to port 7Bh is reset, so the ROM will be placed at 0x0000. When the first interrupt occurs, the keyboard scanning routine is called at 0x028E
and the DISCiPLE memory is automatically paged in. At offset 0x028E in the DISCiPLE's ROM there's a routine that checks if the variable we said above holds 0x44: if it's the case, then the same routine puts 00h in there to say
that DOS services haven't been called since last reset; otherwise the routine
sets the variable to 0x53 ('S') and copies the first 2335 (0x091F) bytes of
ROM in the RAM: in this case the system file has to be loaded again.
When all is finished, the memories will be swapped again (i.e. the flip flop
will be set) by OUTing to port 7Bh, the DISCiPLE paged out by OUTing to port BBh and the keyscan routine is finally executed.
INning from port 7Bh has the same meaning of a system reset for the DOS, so after reading 2 times from port 7Bh without typing a DOS command between them the system file needs to be reloaded.
NOTE that since all this is based on the keyscan routine in the Spectrum's ROM, nothing will happen by INning from port 7Bh if the call is not performed (i.e. if interrupts are disabled in IM 1 or we're not in IM 1 or keyboard is scanned in a custom way); however the last operation with port 7Bh must be an OUT before the routine in the ROM is executed if you want to keep the system safe by resetting once.

So to get this working under emulation in 128K mode, we need to do things:

1) Not page the disciple in when it hits location 0001 (easiest not to do it in any circumstances)
2) Change the ROM to be located at 0x0000 and observe the function of the flip flop as described above.

I’ve updated the Disciple pals document and it should be available here shortly : 
https://spectrumcomputing.co.uk/entry/1000117/Hardware/DISCiPLE_Interface
 
Anyone out there who can make this happen in FUSE ?


> On 5 Mar 2024, at 23:01, Alan Pearson <ala...@gm...> wrote:
> 
> Hi All,
> 
> 
> I'm the guy wrote 'The Disciple PALs finally unveiled' and I found this thread discussing the issue on WoS by accident while trying to figure out why the disciple isn't working on FUSE in 128K mode.
> https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1
> What an interesting thread , and i was shocked to see my doc referenced.
> I haven’t been able to create an account on WoS to reply there, it seems the admin may have gone on holiday or something…. so I came here.
> 
> First, the document:
> 1) This was a direct reverse engineer of working PAL chips, put on a logic analyser by Rudy Biesma, then turned into the equations manually by myself then jedec files created.
> 2) All the findings & equations seem to correspond to known info about the disciple (manual, Ramsoft guide and Rudy's disassembly)
> 3) The proof however was in real world testing - I repaired a broken disciple by programming the PAL chips with the jedec files created and it works perfectly on a 128k +2 (grey).
> 4) There is a typo... N1 should be M1 throughout the doc, but I think you guys worked that out already
> 
> Now, from my reading of the WoS thread and the Rudy disassembly, it seems there is no way the disciple should work on a 128K (at least no way it should initialise)... but it does.
> The code path just doesn't make sense on a 128K machine at reset time.
> 
> Let's change tact - the PlusD uses EXACTLY the same initialisation code, lands in the same place in the ROM when it unpages itself at reset (location #52) and makes no attempt (on reset at least) to figure out if it's a 1128K or 48K or 128k spectrum or which spectrum rom is in.
> How does the plusD then work under FUSE ? It's very weird.
> It's worth saying that the PlusD does have routines specific to 128K paging/unpaging but they are only used when the COPY command finishes and the machine resets after completion.
> The PlusD TO_NEW routine essentially jumps to location #C7 on a 128k (reset routine in the editor ROM) or #11B7 in 48K. 
> Relevant routines below, but as I said they are NOT called when the system resets.
> 
> From Rudy's +D disassembly :
> 
> THE 'UNPAGE 128 ROM' SUBROUTINE
> This routine pages out the +D system and returns to the 128K ROM at address #0049. That
> address contains a RET instruction so the effect is a jump to BC with the 128K ROM paged
> in. 
> 
> 0046 UNPAGE_BC  PUSH BC                  Stack return address.
> 0047 UNPAGE_0   OUT  (231),A             Page out +D system.
> 0049            RET                      ? This statement is not reached from
>                                          above.
> 004A            DEFB #00,#00,#00,#00,#00 Unused locations.
> 
> THE 'NEW' PATCH
> When the file copy command is finished the +D jumps to the 'NEW' routine. With System 2a
> a selection is made for 48K or 128K 'NEW'
> 
> 3137 TO_NEW     BIT  4,(IY+1)            Jump if not in 128K mode HL contains
> 313B            JP   Z,#004F,UNPAGE_HL   #11B7, the address of 48K 'NEW'.
> 313E            CALL #5B00,SWAP          Call the paging subroutine of the 128.
> 3141            DI
> 3142            LD   BC,#00C7            Address of 128 'NEW' routine.
> 3145            JP   #0046,UNPAGE_BC
> 
> 
> 
> Regarding the PALs, I suspect the equations are right, and the fact the code exists in both the +d and Disciple to initialise them suggests that it should be used, so I don't think this is a problem of paging in the interfaces at the wrong time. That said, I can't see how it all should work on a 128, but it does. So this can't be a disciple specific problem, can we trace the +D codepath in FUSE in  128K mode?? I'm not sure how to do this myself.
> 
> 
> It would be great to see Disciple working in 128K models... there are difference between the interfaces that I've run into in converting a program to load from disc (specifically the interface 1 hook code #32, which does a RET on the disciple, but on the PlusD allows any ROM addresss to be called via DE register)
> 
> I know this is a horrible kludge, but can we not monitor location #52 on both inrwefaces and if we have a 128K ROM paged in, simply jump to #00C7 after the OUT instruction ?
> 
> 
> 
> Any thoughts ?
> 
> Alan

[fuse-emulator-devel] Disciple Support on 128K Spectrum

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

Hi All,


I'm the guy wrote 'The Disciple PALs finally unveiled' and I found this thread discussing the issue on WoS by accident while trying to figure out why the disciple isn't working on FUSE in 128K mode.
https://worldofspectrum.org/forums/discussion/42567/the-disciple-clone-doable/p1
What an interesting thread , and i was shocked to see my doc referenced.
I haven’t been able to create an account on WoS to reply there, it seems the admin may have gone on holiday or something…. so I came here.

First, the document:
1) This was a direct reverse engineer of working PAL chips, put on a logic analyser by Rudy Biesma, then turned into the equations manually by myself then jedec files created.
2) All the findings & equations seem to correspond to known info about the disciple (manual, Ramsoft guide and Rudy's disassembly)
3) The proof however was in real world testing - I repaired a broken disciple by programming the PAL chips with the jedec files created and it works perfectly on a 128k +2 (grey).
4) There is a typo... N1 should be M1 throughout the doc, but I think you guys worked that out already

Now, from my reading of the WoS thread and the Rudy disassembly, it seems there is no way the disciple should work on a 128K (at least no way it should initialise)... but it does.
The code path just doesn't make sense on a 128K machine at reset time.

Let's change tact - the PlusD uses EXACTLY the same initialisation code, lands in the same place in the ROM when it unpages itself at reset (location #52) and makes no attempt (on reset at least) to figure out if it's a 1128K or 48K or 128k spectrum or which spectrum rom is in.
How does the plusD then work under FUSE ? It's very weird.
It's worth saying that the PlusD does have routines specific to 128K paging/unpaging but they are only used when the COPY command finishes and the machine resets after completion.
The PlusD TO_NEW routine essentially jumps to location #C7 on a 128k (reset routine in the editor ROM) or #11B7 in 48K. 
Relevant routines below, but as I said they are NOT called when the system resets.

From Rudy's +D disassembly :

THE 'UNPAGE 128 ROM' SUBROUTINE
This routine pages out the +D system and returns to the 128K ROM at address #0049. That
address contains a RET instruction so the effect is a jump to BC with the 128K ROM paged
in. 

0046 UNPAGE_BC  PUSH BC                  Stack return address.
0047 UNPAGE_0   OUT  (231),A             Page out +D system.
0049            RET                      ? This statement is not reached from
                                         above.
004A            DEFB #00,#00,#00,#00,#00 Unused locations.

THE 'NEW' PATCH
When the file copy command is finished the +D jumps to the 'NEW' routine. With System 2a
a selection is made for 48K or 128K 'NEW'

3137 TO_NEW     BIT  4,(IY+1)            Jump if not in 128K mode HL contains
313B            JP   Z,#004F,UNPAGE_HL   #11B7, the address of 48K 'NEW'.
313E            CALL #5B00,SWAP          Call the paging subroutine of the 128.
3141            DI
3142            LD   BC,#00C7            Address of 128 'NEW' routine.
3145            JP   #0046,UNPAGE_BC



Regarding the PALs, I suspect the equations are right, and the fact the code exists in both the +d and Disciple to initialise them suggests that it should be used, so I don't think this is a problem of paging in the interfaces at the wrong time. That said, I can't see how it all should work on a 128, but it does. So this can't be a disciple specific problem, can we trace the +D codepath in FUSE in  128K mode?? I'm not sure how to do this myself.


It would be great to see Disciple working in 128K models... there are difference between the interfaces that I've run into in converting a program to load from disc (specifically the interface 1 hook code #32, which does a RET on the disciple, but on the PlusD allows any ROM addresss to be called via DE register)

I know this is a horrible kludge, but can we not monitor location #52 on both inrwefaces and if we have a 128K ROM paged in, simply jump to #00C7 after the OUT instruction ?



Any thoughts ?

Alan

Re: [fuse-emulator-devel] Removal of deprecated `gdk_display_get_default` function

[Philip K. <ph...@sh...>]

On Sun, Feb 18, 2024 at 11:09 AM Alberto Garcia <be...@ig...> wrote:

> On Sun, Feb 18, 2024 at 09:38:10AM +0000, Philip Kendall wrote:
> > Hey, I actually wrote some code!
> >
> >
> https://sourceforge.net/p/fuse-emulator/fuse/ci/patch-440-remove-gdk_keymap_get_default/tree/
> >
> > Given I can't remember how any of this works :( if anyone wants to
> > look it over and tell me if I've broken anything that would be much
> > appreciated!
>
> Hi, the patch looks fine to me, but I don't think you strictly need
> the global gtkui_default_display variable... gdk_display_get_default()
> simply returns
>
>    manager->default_display
>
> so you're not saving a lot here by caching the result.
>

Agreed, simpler version without caching now merged.

Thanks!

Phil

Re: [fuse-emulator-devel] Removal of deprecated `gdk_display_get_default` function

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

On Sun, Feb 18, 2024 at 09:38:10AM +0000, Philip Kendall wrote:
> Hey, I actually wrote some code!
> 
> https://sourceforge.net/p/fuse-emulator/fuse/ci/patch-440-remove-gdk_keymap_get_default/tree/
> 
> Given I can't remember how any of this works :( if anyone wants to
> look it over and tell me if I've broken anything that would be much
> appreciated!

Hi, the patch looks fine to me, but I don't think you strictly need
the global gtkui_default_display variable... gdk_display_get_default()
simply returns

   manager->default_display

so you're not saving a lot here by caching the result.

Either way it looks good to me.

Regards,

Berto

[fuse-emulator-devel] Removal of deprecated `gdk_display_get_default` function

[Philip K. <ph...@sh...>]

Hey, I actually wrote some code!

https://sourceforge.net/p/fuse-emulator/fuse/ci/patch-440-remove-gdk_keymap_get_default/tree/

Given I can't remember how any of this works :( if anyone wants to look it
over and tell me if I've broken anything that would be much appreciated!

Thanks,

Phil

Re: [fuse-emulator-devel] spectrum keyboard

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

On Fri, Jan 12, 2024 at 08:40:54PM +0200, Alexandru Goia wrote:
> Greetings !
> Please help me with this matter (I know it is not a devel thing, but
> it is the only mailing list I know)

Hi, for general usage questions you can use the sourceforge forums:

   https://sourceforge.net/p/fuse-emulator/discussion/

Although I think that any forum about the Spectrum can help you with
this.

> How to obtain in fuse (Spectrum Emulator) STEP, TO, THEN, on D, F, G
> pc keys ?

On the Spectrum you get those keywords by pressing SYMBOL SHIFT and
the appropriate letter.

Fuse maps the Control and Alt keys to SYMBOL SHIFT.

So: Ctrl+D, Alt+D, etc.

Berto

[fuse-emulator-devel] spectrum keyboard

[Alexandru G. <goi...@gm...>]

Greetings !
Please help me with this matter (I know it is not a devel thing, but
it is the only mailing list I know)

How to obtain in fuse (Spectrum Emulator) STEP, TO, THEN, on D, F, G pc keys ?

Thank you very much !
Alexander,
Romania
PC & HC hobbyist

Re: [fuse-emulator-devel] Libretro core license

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

On Thu, 4 Jan 2024 18:15:19 +0000
Andre Leiradella <an...@le...> wrote:

> Hi,
> 
> I was wondering if Fuse could have a LGPL license for the Libretro core, 
> to allow it to be used with Libretro frontends that are not GPL.
> 
> Disclaimer: I intend to pack it with a custom frontend and explore ZX 
> Spectrum games commercially. If commercial use is not wanted but LGPL 
> is, commercial usage could be explicitly disallowed in the license in 
> addition to the LGPL terms.

No it couldn't. The LGPL forbids additional restrictions.

Alan

Re: [fuse-emulator-devel] Libretro core license

[Andre L. <an...@le...>]

On 2024-01-04 21:59, Alan Cox wrote:
> On Thu, 4 Jan 2024 18:15:19 +0000
> Andre Leiradella <an...@le...> wrote:
>
>> Hi,
>>
>> I was wondering if Fuse could have a LGPL license for the Libretro core,
>> to allow it to be used with Libretro frontends that are not GPL.
>>
>> Disclaimer: I intend to pack it with a custom frontend and explore ZX
>> Spectrum games commercially. If commercial use is not wanted but LGPL
>> is, commercial usage could be explicitly disallowed in the license in
>> addition to the LGPL terms.
> No it couldn't. The LGPL forbids additional restrictions.
>
> Alan

Oh sorry, I've seen it and thought it was possible, thanks for letting 
me know.

The original pledge remains, however.

Andre

[fuse-emulator-devel] Libretro core license

[Andre L. <an...@le...>]

Hi,

I was wondering if Fuse could have a LGPL license for the Libretro core, 
to allow it to be used with Libretro frontends that are not GPL.

Disclaimer: I intend to pack it with a custom frontend and explore ZX 
Spectrum games commercially. If commercial use is not wanted but LGPL 
is, commercial usage could be explicitly disallowed in the license in 
addition to the LGPL terms.

Thanks,

Andre

Re: [fuse-emulator-devel] Speed "surge"

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

On Thu, Apr 13, 2023 at 10:48:40PM +0200, mir...@gm... wrote:

> Interestingly, there is an open bug report from 2004, hinting to
> sound drivers as well.
> 
> As Fuse allegedly relies on sound driver/hw when calculating timing.
> 
> https://sourceforge.net/p/fuse-emulator/bugs/18/

The official Debian packages use the SDL audio driver since 2020
because some users were reporting problems with Alsa.

So if you're building Fuse yourself I suggest that you try passing
--with-audio-driver=sdl to the configure script.

Berto

Re: [fuse-emulator-devel] Speed "surge"

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

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style></head><body lang=SK link=blue vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Interestingly, there is an open bug report from 2004, hinting to sound drivers as well.</p><p class=MsoNormal>As Fuse allegedly relies on sound driver/hw when calculating timing.</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><a href="https://sourceforge.net/p/fuse-emulator/bugs/18/">https://sourceforge.net/p/fuse-emulator/bugs/18/</a></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Miroslav / Arki55</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>From: </b><a href="mailto:be...@ig...">Alberto Garcia</a><br><b>Sent: </b>štvrtok 13. apríla 2023 15:34<br><b>To: </b><a href="mailto:fus...@li...">fus...@li...</a><br><b>Subject: </b>Re: [fuse-emulator-devel] Speed &quot;surge&quot;</p></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>On Wed, Apr 12, 2023 at 06:02:44PM +0100, Phil Reynolds wrote:</p><p class=MsoNormal>&gt; Recently I have noticed the emulation speed surging to 2500% or so then</p><p class=MsoNormal>&gt; slowly dropping back - an effect I'd not seen before. It seems to</p><p class=MsoNormal>&gt; happen after using the menus, among other things.</p><p class=MsoNormal>&gt; </p><p class=MsoNormal>&gt; This is on Debian bullseye, using a self compiled fuse and</p><p class=MsoNormal>&gt; libspectrum.  What could be causing this odd effect?</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Can you try with a different audio driver? Alsa instead of SDL or vice</p><p class=MsoNormal>versa.</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Berto</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>_______________________________________________</p><p class=MsoNormal>fuse-emulator-devel mailing list</p><p class=MsoNormal>fus...@li...</p><p class=MsoNormal>https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel</p><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></body></html>

Re: [fuse-emulator-devel] Speed "surge"

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

On Wed, Apr 12, 2023 at 06:02:44PM +0100, Phil Reynolds wrote:
> Recently I have noticed the emulation speed surging to 2500% or so then
> slowly dropping back - an effect I'd not seen before. It seems to
> happen after using the menus, among other things.
> 
> This is on Debian bullseye, using a self compiled fuse and
> libspectrum.  What could be causing this odd effect?

Can you try with a different audio driver? Alsa instead of SDL or vice
versa.

Berto

Re: [fuse-emulator-devel] Speed "surge"

[Szász G. <sz...@hu...>]

On Wed, Apr 12, 2023 at 08:48:35PM +0100, Phil Reynolds wrote:
> On Wed, 12 Apr 2023 10:30:14 +0000
> Szász Gergely <sz...@hu...> wrote:
> 
> > On Wed, Apr 12, 2023 at 06:02:44PM +0100, Phil Reynolds wrote:
> > > Recently I have noticed the emulation speed surging to 2500% or so
> > > then slowly dropping back - an effect I'd not seen before. It seems
> > > to happen after using the menus, among other things.
> > > 
> > > This is on Debian bullseye, using a self compiled fuse and
> > > libspectrum. What could be causing this odd effect?  
> > Hi Phil,
> > 
> > What UI? GTK2/3, SDL, X11?
> 
> Seems to be GTK affected - SDL OK.
Uhum..

Maybe something around timer_estimate_reset() and fuse_emulation_pause()/fuse_emulation_unpause() ??

Gergely

p.s.: looks like fuse try to catch themself after spent some time in "menu"...

> 
> -- 
> Phil Reynolds
> mail: phi...@ti...
> Web: http://phil.tinsleyviaduct.com/
> 
> 
> 
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel

Re: [fuse-emulator-devel] Speed "surge"

[Phil R. <phi...@ti...>]

On Wed, 12 Apr 2023 10:30:14 +0000
Szász Gergely <sz...@hu...> wrote:

> On Wed, Apr 12, 2023 at 06:02:44PM +0100, Phil Reynolds wrote:
> > Recently I have noticed the emulation speed surging to 2500% or so
> > then slowly dropping back - an effect I'd not seen before. It seems
> > to happen after using the menus, among other things.
> > 
> > This is on Debian bullseye, using a self compiled fuse and
> > libspectrum. What could be causing this odd effect?  
> Hi Phil,
> 
> What UI? GTK2/3, SDL, X11?

Seems to be GTK affected - SDL OK.

-- 
Phil Reynolds
mail: phi...@ti...
Web: http://phil.tinsleyviaduct.com/

Re: [fuse-emulator-devel] Speed "surge"

[Szász G. <sz...@hu...>]

On Wed, Apr 12, 2023 at 06:02:44PM +0100, Phil Reynolds wrote:
> Recently I have noticed the emulation speed surging to 2500% or so then
> slowly dropping back - an effect I'd not seen before. It seems to
> happen after using the menus, among other things.
> 
> This is on Debian bullseye, using a self compiled fuse and libspectrum.
> What could be causing this odd effect?
Hi Phil,

What UI? GTK2/3, SDL, X11?

Gergely

> 
> -- 
> Phil Reynolds
> mail: phi...@ti...
> Web: http://phil.tinsleyviaduct.com/
> 
> 
> 
> _______________________________________________
> fuse-emulator-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel