You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(88) |
Nov
(58) |
Dec
(53) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(35) |
Feb
(43) |
Mar
(89) |
Apr
(54) |
May
(32) |
Jun
(36) |
Jul
(121) |
Aug
(40) |
Sep
(8) |
Oct
(55) |
Nov
(52) |
Dec
(36) |
2005 |
Jan
(68) |
Feb
(91) |
Mar
(24) |
Apr
(77) |
May
(31) |
Jun
(3) |
Jul
(3) |
Aug
(22) |
Sep
(35) |
Oct
(10) |
Nov
(6) |
Dec
(9) |
2006 |
Jan
(10) |
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
(6) |
Jun
(8) |
Jul
(61) |
Aug
(54) |
Sep
(12) |
Oct
(7) |
Nov
(6) |
Dec
(9) |
2007 |
Jan
(37) |
Feb
(61) |
Mar
(66) |
Apr
(90) |
May
(197) |
Jun
(130) |
Jul
(112) |
Aug
(79) |
Sep
(41) |
Oct
(55) |
Nov
(107) |
Dec
(53) |
2008 |
Jan
(38) |
Feb
(35) |
Mar
(105) |
Apr
(26) |
May
(41) |
Jun
(74) |
Jul
(20) |
Aug
(29) |
Sep
(12) |
Oct
(51) |
Nov
(79) |
Dec
(41) |
2009 |
Jan
(52) |
Feb
(34) |
Mar
(58) |
Apr
(20) |
May
(24) |
Jun
(53) |
Jul
(20) |
Aug
(17) |
Sep
(25) |
Oct
(63) |
Nov
(29) |
Dec
(14) |
2010 |
Jan
(22) |
Feb
(8) |
Mar
(5) |
Apr
(4) |
May
(25) |
Jun
(11) |
Jul
(6) |
Aug
(14) |
Sep
(31) |
Oct
(40) |
Nov
(10) |
Dec
(76) |
2011 |
Jan
(122) |
Feb
(47) |
Mar
(27) |
Apr
(108) |
May
(32) |
Jun
(42) |
Jul
(21) |
Aug
(12) |
Sep
(22) |
Oct
(2) |
Nov
(17) |
Dec
(17) |
2012 |
Jan
(85) |
Feb
(55) |
Mar
(28) |
Apr
(16) |
May
(38) |
Jun
(44) |
Jul
(40) |
Aug
(23) |
Sep
(23) |
Oct
(36) |
Nov
(21) |
Dec
(78) |
2013 |
Jan
(45) |
Feb
(20) |
Mar
(4) |
Apr
(6) |
May
(65) |
Jun
(32) |
Jul
|
Aug
|
Sep
(4) |
Oct
(8) |
Nov
(12) |
Dec
|
2014 |
Jan
(3) |
Feb
(5) |
Mar
(10) |
Apr
|
May
|
Jun
(5) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2015 |
Jan
|
Feb
(1) |
Mar
(40) |
Apr
(31) |
May
(171) |
Jun
(45) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(13) |
Nov
(6) |
Dec
(6) |
2016 |
Jan
|
Feb
|
Mar
(23) |
Apr
(12) |
May
(56) |
Jun
(57) |
Jul
(39) |
Aug
(8) |
Sep
(13) |
Oct
(35) |
Nov
(28) |
Dec
(6) |
2017 |
Jan
(12) |
Feb
(7) |
Mar
(8) |
Apr
(7) |
May
(5) |
Jun
(22) |
Jul
(9) |
Aug
(27) |
Sep
(19) |
Oct
(10) |
Nov
(11) |
Dec
(8) |
2018 |
Jan
(11) |
Feb
(25) |
Mar
(6) |
Apr
(6) |
May
(2) |
Jun
(20) |
Jul
(9) |
Aug
(7) |
Sep
(12) |
Oct
|
Nov
(3) |
Dec
(17) |
2019 |
Jan
(7) |
Feb
(10) |
Mar
(5) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(5) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(7) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2021 |
Jan
(1) |
Feb
(26) |
Mar
(8) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(7) |
Dec
|
2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(3) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
(5) |
Feb
(3) |
Mar
(8) |
Apr
(5) |
May
(5) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
From: Sergio B. <ser...@gm...> - 2024-09-24 20:58:47
|
On 23/9/24 19:24, Alberto Garcia wrote: > Hi, > > as you know the Fuse emulator has been available in Flathub (the main > Flatpak "app store") for many years and it has been doing reasonably > well with an average of 30 downloads per day (numbers similar to > FS-UAE or Vice): > > https://flathub.org/apps/net.sf.fuse_emulator > > One small thing that I would like to do is mark the app as "Verified", > which means that it was published or approved by the original > developers. > > ... > > So if this all sounds good to you I would only need someone with > access to the project's home page to create the file with the ID that > I will provide (I need to apply for it first, but I wanted to confirm > with you before proceeding). Hi Berto, sounds good to me. Wait some days for more opinions and apply for that key, barring objections. I can upload it to sf.net Thank you for your efforts. Cheers, Sergio |
From: Alberto G. <be...@ig...> - 2024-09-23 17:24:42
|
Hi, as you know the Fuse emulator has been available in Flathub (the main Flatpak "app store") for many years and it has been doing reasonably well with an average of 30 downloads per day (numbers similar to FS-UAE or Vice): https://flathub.org/apps/net.sf.fuse_emulator One small thing that I would like to do is mark the app as "Verified", which means that it was published or approved by the original developers. There are two things that need to be done: 1. Change the Flatpak ID to represent the actual canonical URL of the project's home page. I cannot verify the app with the current "net.sf..." name. This is something that I can handle completely on my own and is not a problem. 2. I have to prove control over the home page. This means that I have to create a file at this URL: https://fuse-emulator.sourceforge.net/.well-known/org.flathub.VerifiedApps.txt The file simply needs to contain an alphanumerical id provided by Flathub, and no further action is needed. So if this all sounds good to you I would only need someone with access to the project's home page to create the file with the ID that I will provide (I need to apply for it first, but I wanted to confirm with you before proceeding). Regards, Berto |
From: Alistair <ali...@zx...> - 2024-09-02 17:09:11
|
On 2024-09-02 16:39, desertkun wrote: > Don't know about zx-net particularly, but I have invested significant > time to support Spectranet, which is a different cartridge, but I assume > does similar thing. It's entirely different. Spectranet's W5100 has hardware packet buffers etc so is much easier to emulate. Everything the IF1 does is bit banged on the wire by the CPU. |
From: desertkun <des...@gm...> - 2024-09-02 15:40:14
|
Don't know about zx-net particularly, but I have invested significant time to support Spectranet, which is a different cartridge, but I assume does similar thing. See my fusex fork on speccytools.org regular fuse also supports it but it's buggy and cumbersome. Other emulators like es.pectrum also support it. On Mon, Sep 2, 2024, 14:39 Derek Fountain <der...@gm...> wrote: > Can anyone advise on the status of the ZX-Net emulation in the Interface 1 > code? > > There's a bit of chat in one of the Spectrum forums about getting a couple > of Fuse instances talking (same host), and someone has opened up a feature > request ticket (#153). It looks to me like there's code already there, but > it's not documented, and it's not clear how to use it, if it works, or if > it ever worked. > > Does anyone know where this feature got to? > _______________________________________________ > fuse-emulator-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel > |
From: Derek F. <der...@gm...> - 2024-08-28 16:29:51
|
Can anyone advise on the status of the ZX-Net emulation in the Interface 1 code? There's a bit of chat in one of the Spectrum forums about getting a couple of Fuse instances talking (same host), and someone has opened up a feature request ticket (#153). It looks to me like there's code already there, but it's not documented, and it's not clear how to use it, if it works, or if it ever worked. Does anyone know where this feature got to? |
From: Sergio B. <ser...@gm...> - 2024-06-30 07:04:44
|
Thank you for your offer. I guess main developers already a little hardware collection. If anyone is interested will contact you. Cheers, Sergio El sáb, 29 jun 2024 a las 22:22, thraex via fuse-emulator-devel (< fus...@li...>) escribió: > Hi all, > > I still have a ZX Sinclair Spectrum along with an alphacom 32 thermal > printer and a microdrive (no idea whether they still work). I don't use > them as Fuse is much more convenient, but I was wondering if donating it > do the developers would make sense. > > If you're interested, I'd be happy to send them to aid the advancement > of the project. > > Best regards. > > > _______________________________________________ > fuse-emulator-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel > |
From: thraex <th...@nu...> - 2024-06-29 20:22:03
|
Hi all, I still have a ZX Sinclair Spectrum along with an alphacom 32 thermal printer and a microdrive (no idea whether they still work). I don't use them as Fuse is much more convenient, but I was wondering if donating it do the developers would make sense. If you're interested, I'd be happy to send them to aid the advancement of the project. Best regards. |
From: <kos...@an...> - 2024-06-23 19:18:41
|
Hello, everyone! After a few weeks of (successful) testing I would like to ask the wider audience to join me. Recently I came up with a patch enabling FUSE to interface with any serial device (or a pair of FIFOs) presenting those as I/O Port 14 of the AY 8912. Not all emulators are able to do the same: https://sourceforge.net/p/fuse-emulator/patches/442/ If you have few minutes to spare, I’d appreciate you reviewing the proposed change and sharing your opinion. Thank a lot! |
From: Szász G. <sz...@hu...> - 2024-05-03 17:47:22
|
On Fri, May 03, 2024 at 04:57:55PM +0000, Szász Gergely via fuse-emulator-devel wrote: > On Thu, May 02, 2024 at 03:59:24PM +0200, Mentore Siesto wrote: > > Hello everyone, first time here so let me introduce myself: > > > > I'm an italian developer really loving FUSE and using it daily. > > > > I'm also an OS/2 old time enthusiast and I'm porting software in my spare > > time. I just gave a shot at FUSE 1.6.0 and got a somehow working executable > > using GCC 9.2 and SDL interface, but the executable crashes with the error > > > > > > fuse: error: font contains invalid character > > fuse: error initialising -- giving up! > > > > Wondering what may be the culprit, without any clue on that. The font file > > is currently present and untouched. > > > > I configured the source package like this > > > > and make worked like a charm after giving the correct location for > > libspectrum files. > > > > Is there something I can do to debug the problem? Do I have to do something > > to the font file in order to use it? > > > > Thanks in andvance, > > > > Mentore Siesto > > Hi Mentore, > > You have to copy fuse.font file into $(datadir)/fuse - on linux this is /usr/share/fuse or /usr/local/share/fuse directory (depending on compile time "prefix" > > You may need here some other files too: > cassette.bmp > fuse.font > keyboard.png > keyboard.scr > menu_data.ui > microdrive.bmp > plus3disk.bmp > > And you need at least 48.rom in the roms directory... hmm.. maybe /usr/share/fuse/roms ??? > > Maybe your font file is in place, but "bogus". > The fuse.font file length is 1818 byte. > > Best regards, > Gergely And one more... It looks like you can copy all the files to the directory where fuse(.exe) is.0 Gergely > > > _______________________________________________ > > 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 |
From: Szász G. <sz...@hu...> - 2024-05-03 16:58:25
|
On Thu, May 02, 2024 at 03:59:24PM +0200, Mentore Siesto wrote: > Hello everyone, first time here so let me introduce myself: > > I'm an italian developer really loving FUSE and using it daily. > > I'm also an OS/2 old time enthusiast and I'm porting software in my spare > time. I just gave a shot at FUSE 1.6.0 and got a somehow working executable > using GCC 9.2 and SDL interface, but the executable crashes with the error > > > fuse: error: font contains invalid character > fuse: error initialising -- giving up! > > Wondering what may be the culprit, without any clue on that. The font file > is currently present and untouched. > > I configured the source package like this > > and make worked like a charm after giving the correct location for > libspectrum files. > > Is there something I can do to debug the problem? Do I have to do something > to the font file in order to use it? > > Thanks in andvance, > > Mentore Siesto Hi Mentore, You have to copy fuse.font file into $(datadir)/fuse - on linux this is /usr/share/fuse or /usr/local/share/fuse directory (depending on compile time "prefix" You may need here some other files too: cassette.bmp fuse.font keyboard.png keyboard.scr menu_data.ui microdrive.bmp plus3disk.bmp And you need at least 48.rom in the roms directory... hmm.. maybe /usr/share/fuse/roms ??? Maybe your font file is in place, but "bogus". The fuse.font file length is 1818 byte. Best regards, Gergely > _______________________________________________ > fuse-emulator-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel |
From: Mentore S. <men...@al...> - 2024-05-02 14:26:46
|
Hello everyone, first time here so let me introduce myself: I'm an italian developer really loving FUSE and using it daily. I'm also an OS/2 old time enthusiast and I'm porting software in my spare time. I just gave a shot at FUSE 1.6.0 and got a somehow working executable using GCC 9.2 and SDL interface, but the executable crashes with the error fuse: error: font contains invalid character fuse: error initialising -- giving up! Wondering what may be the culprit, without any clue on that. The font file is currently present and untouched. I configured the source package like this and make worked like a charm after giving the correct location for libspectrum files. Is there something I can do to debug the problem? Do I have to do something to the font file in order to use it? Thanks in andvance, Mentore Siesto |
From: Alberto G. <be...@ig...> - 2024-05-01 13:13:10
|
On Wed, May 01, 2024 at 09:01:30AM +0000, Szász Gergely via fuse-emulator-devel wrote: > You have to unzip the .tzx or .tap file. FWIW Fuse supports reading .zip files since 2016: https://sourceforge.net/p/fuse-emulator/patches/343/ Berto |
From: Szász G. <sz...@hu...> - 2024-05-01 09:01:55
|
On Wed, Apr 24, 2024 at 10:19:04PM -0400, Bill Blasingim wrote: > 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 Hi Bill, You have to unzip the .tzx or .tap file. In ManicMiner.tzx.zip archive there is a ManicMiner.tzx or "Manic Miner.tzx" file, you need this file. You can unzip the archive from command line: unzip ManicMiner.tzx.zip. Now you should see: Archive: ManicMiner.tzx.zip inflating: Manic Miner.tzx Now you can open the tzx file more than one way: - File->Open "Manic Miner.tzx" .. now tape loaded automatically and the game start up. - Media->Tape->Open "Manic Miner.tzx" .. now you have to type LOAD "" and [ENTER] (J, Ctrl-P, ctrl-P, ENTER) .. now tape loaded and the game started If you want to hear/see the original loading sound/effects and border stripping, etc. you have to unset three option: - Options->Media->Fastloading - Options->Media->Use tape traps - Options->Media->Accelerate loaders If you uncheck the Options->Media->Detect Loaders than you have to control manually the tape player: - Type LOAD "" - Media->Tape->Play A 48k game normal loading time from tape is around 10' :) On the irc://irc.oftc.net:6667 we have a #fuse-emulator irc channel (quite empty nowadays...): Best regards, Gergely > _______________________________________________ > fuse-emulator-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel |
From: Alan P. <ala...@gm...> - 2024-04-26 16:49:04
|
Silly question - did you do LOAD “” command in the Spectrum, after you did the tape steps you mentioned? > On 25 Apr 2024, at 03:19, Bill Blasingim <bla...@be...> wrote: > > 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...> <mailto:fus...@li...> > > Thanks for any help, > Bill > > <fuse1.png><Fuse2.png> > _______________________________________________ > fuse-emulator-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-emulator-devel |
From: Alberto G. <be...@ig...> - 2024-04-25 09:36:10
|
On Wed, Apr 24, 2024 at 10:19:04PM -0400, Bill Blasingim wrote: > 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. Hi, it should just work as you say. Maybe you don't have "Auto-load media" enabled in Options -> Media ? I would also like to point out that this mailing list is for the development of Fuse. For general questions about the Spectrum, how to use emulators, load software, etc, I recommend you to have a look at the Spectrum Computing forums, which are very active and where you will find more people who can help you: https://spectrumcomputing.co.uk/forums/ Welcome to the Spectrum world :-) Regards, Berto |
From: Bill B. <bla...@be...> - 2024-04-25 03:10:13
|
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 |
From: Alan P. <ala...@gm...> - 2024-04-02 14:38:25
|
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¬proccesed=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 |
From: Szász G. <sz...@hu...> - 2024-04-01 07:45:37
|
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 |
From: Andre L. <an...@le...> - 2024-03-27 14:27:16
|
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 > |
From: Alexander L. <moo...@gm...> - 2024-03-27 13:17:27
|
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 > |
From: Andre L. <an...@le...> - 2024-03-27 12:34:07
|
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 |
From: Alan P. <ala...@gm...> - 2024-03-23 14:23:40
|
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 |
From: Sergio B. <ser...@gm...> - 2024-03-23 06:08:56
|
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 > |
From: Alan C. <al...@ll...> - 2024-03-19 21:22:56
|
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 |
From: Alan P. <ala...@gm...> - 2024-03-16 21:32:14
|
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 |