Beebem save state and load state

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
fuzzel
Posts: 208
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside

Beebem save state and load state

Postby fuzzel » Wed Mar 01, 2017 9:33 am

I'm trying to understand how the save state and load state commands in Beebem affect saved .ssd and .dsd discs.

When I use save state it saves the entire memory which is great for saving games especially arcade games.
It also appears to have an impact on the attached disc though.

Am I right in thinking that if I start playing a disc text adventure having used load disc (eg. myorem.ssd) and then *SAVE a saved position eg *SAVE SAVE1 within the game to disc 0 and also save state eg save1.uef, and then later on *SAVE SAVE2 file and save state again to save2.uef, this will save both files to myorem.ssd. If I later on load state save1.uef will this over-write the original myorem.ssd disc so I will lose SAVE2 (until I reopen save state SAVE2) ?
i.e. Is there a copy of the .ssd disc in the save state file which when you open it overrides the .ssd image which is attached ?

The reason I'm asking is I use save state a lot and I seem to lose a few save files now and again if I go back to previous save states.

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Wed Mar 01, 2017 12:58 pm

I managed to replicate the problem using the disc image of Myorem from bbcmicro.co.uk, but I think there's a more general principle at work here, which is that DFS seems to cache the disc catalogue (the detailed list of files on a disc) in RAM, and doesn't refresh the cache immediately after a *SAVE.

You can see this if you start up BeebEm, insert a disc image (or create a blank one), make sure write-protection is disabled, type *SAVE X 0 0, wait for the disc-drive sound to stop, and then immediately type *CAT. The disc catalogue will be displayed without any physical access to the disc: i.e. there'll be no disc-drive sound straight after the *CAT, which means that DFS is relying on the cached copy of the catalogue in RAM to determine what files are on the disc. But if you then type *CAT for a second time, the disc drive will be accessed!

The upshot is that because Myorem (like several other games) essentially does a *SAVE to save your position to disc, the game program won't necessarily know about any savegames you've added to the disc in a later Saved State and won't be able to load them. And in fact you might end up overwriting them when you next do an in-game SAVE.

:?:

Coeus
Posts: 469
Joined: Mon Jul 25, 2016 11:05 am

Re: Beebem save state and load state

Postby Coeus » Wed Mar 01, 2017 2:09 pm

Looking at the code it appears to save the filename in the UEF file, not the contents of the SSD.

If this is down to caching this is probably a bug. The proper behaviour of DFS is to discard the cached catalogue once the disk stops spinning and re-read on the next disc access. Whether that means the DFS rom in use is buggy or whether there is a bug in BeebEm's disc emulation I don't know.

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Wed Mar 01, 2017 3:24 pm

lurkio wrote:You can see this if you start up BeebEm, insert a disc image (or create a blank one), make sure write-protection is disabled, type *SAVE X 0 0, wait for the disc-drive sound to stop, and then immediately type *CAT. The disc catalogue will be displayed without any physical access to the disc: i.e. there'll be no disc-drive sound straight after the *CAT, which means that DFS is relying on the cached copy of the catalogue in RAM to determine what files are on the disc. But if you then type *CAT for a second time, the disc drive will be accessed!

Coeus wrote:If this is down to caching this is probably a bug. The proper behaviour of DFS is to discard the cached catalogue once the disk stops spinning and re-read on the next disc access. Whether that means the DFS rom in use is buggy or whether there is a bug in BeebEm's disc emulation I don't know.

I'm using BeebEm 4.14 in Model B mode on Windows, and I always see the same behaviour, no matter whether I use Acorn DFS 0.9, Acorn DFS 1.2, or Watford Electronics DFS 1.44.

However, the behaviour is different if you switch to Master 128 mode, which uses DFS 2.24: then the first *CAT does access the disc.

:idea:

Coeus
Posts: 469
Joined: Mon Jul 25, 2016 11:05 am

Re: Beebem save state and load state

Postby Coeus » Wed Mar 01, 2017 3:58 pm

lurkio wrote:I'm using BeebEm 4.14 in Model B mode on Windows, and I always see the same behaviour, no matter whether I use Acorn DFS 0.9, Acorn DFS 1.2, or Watford Electronics DFS 1.44.

However, the behaviour is different if you switch to Master 128 mode, which uses DFS 2.24: then the first *CAT does access the disc.

:idea:


I am not sure if that proves it is the DFS ROM or BeebEm, though as it maybe to do with which disc controller chip each ROM uses. The original DFS ROM expected an Intel 8271, the master series used a WD1770 and BeebEm has different modules to emulate each chip.

What makes it more complicated is that some third party disk system manufacters adopted the WD1770 early, as it was a current chip and cheap, whereas the i8271 was discontinued and becoming increasingly expensive. That meant they could undercut the Acorn price for the disk system and Watford were one of those manufacters. Acorn subsequently release their own WD1770 disk system which appeared to have exactly the same hardware as the Watford one.

When I have more time I could do some more digging, or maybe someone who keeps more of the detail in his head will join in.

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Wed Mar 01, 2017 7:28 pm

lurkio wrote:... if you start up BeebEm, insert a disc image (or create a blank one), make sure write-protection is disabled, type *SAVE X 0 0, wait for the disc-drive sound to stop, and then immediately type *CAT. The disc catalogue will be displayed without any physical access to the disc: i.e. there'll be no disc-drive sound straight after the *CAT, which means that DFS is relying on the cached copy of the catalogue in RAM to determine what files are on the disc. But if you then type *CAT for a second time, the disc drive will be accessed ... I'm using BeebEm 4.14 in Model B mode on Windows, and I always see the same behaviour, no matter whether I use Acorn DFS 0.9, Acorn DFS 1.2, or Watford Electronics DFS 1.44. However, the behaviour is different if you switch to Master 128 mode, which uses DFS 2.24: then the first *CAT does access the disc.

Coeus wrote:I am not sure if that proves it is the DFS ROM or BeebEm, though as it maybe to do with which disc controller chip each ROM uses. The original DFS ROM expected an Intel 8271, the master series used a WD1770 and BeebEm has different modules to emulate each chip.

I can't run the test on a real Beeb because I don't have access to one at the mo. But if a real Model B exhibits the same behaviours I've been describing in this thread, then neither the DFS ROM(s) nor BeebEm need fixing.

:idea:

Coeus
Posts: 469
Joined: Mon Jul 25, 2016 11:05 am

Re: Beebem save state and load state

Postby Coeus » Wed Mar 01, 2017 8:32 pm

lurkio wrote:I can't run the test on a real Beeb because I don't have access to one at the mo. But if a real Model B exhibits the same behaviours I've been describing in this thread, then neither the DFS ROM(s) nor BeebEm need fixing.


I knew it was documented somewhere - see a thread on this board http://stardot.org.uk/forums/viewtopic.php?f=4&t=11633&p=150740#p150740. So Acorn DFS 0.9, Acorn DFS 1.2 and Watford DFS 1.44 all use the i8271. That suggests the i8271 emulation in BeebEm has a bug. You could try one of the DFS ROM that use a WD1770 with BBC mode so, for example, Watford 1.54 or any 2.X Acorn DFS.

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Wed Mar 01, 2017 8:43 pm

Coeus wrote:
lurkio wrote:I can't run the test on a real Beeb because I don't have access to one at the mo. But if a real Model B exhibits the same behaviours I've been describing in this thread, then neither the DFS ROM(s) nor BeebEm need fixing.

I knew it was documented somewhere - see a thread on this board http://stardot.org.uk/forums/viewtopic.php?f=4&t=11633&p=150740#p150740. So Acorn DFS 0.9, Acorn DFS 1.2 and Watford DFS 1.44 all use the i8271. That suggests the i8271 emulation in BeebEm has a bug.

Does a real Beeb with a real 8271 FDC and a real i8271-using DFS ROM exhibit the same behaviours that I've been describing in this thread? If so, then BeebEm is simply emulating a real Beeb.

:?:

steve3000
Posts: 1711
Joined: Sun Nov 25, 2012 12:43 am

Re: Beebem save state and load state

Postby steve3000 » Wed Mar 01, 2017 9:43 pm

Just reading this with interest, as I've seen the same issue in BeebEm.

And it just happens that I'm sat next to my BBC B with Acorn DFS 0.9 (8271) interface and a blank disc in the drive... So...
lurkio wrote:You can see this if you start up BeebEm, insert a disc image (or create a blank one), make sure write-protection is disabled, type *SAVE X 0 0, wait for the disc-drive sound to stop, and then immediately type *CAT. The disc catalogue will be displayed without any physical access to the disc:

I can confirm a real BBC does not do this. The real BBC accesses the drive immediately again on *CAT, and file X is present.

User avatar
CMcDougall
Posts: 5623
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland

Re: Beebem save state and load state

Postby CMcDougall » Wed Mar 01, 2017 9:51 pm

^only stupid ADFS does not refresh the disc with a *CAT, so better to *MOUNT 0 to force it to refresh :roll: :evil:

SaveState ONLY saves what is in memory at that point in time, so therefore whatever was in the *CAT (&E00 to 1100) is still same.
It also looks for the disc it had in 'memory'/Drive0 at time of SaveState, so if disc has been changed afterwards, it will load in the 'newer' disc, not same as original SaveState time.
hence:
try.jpg
err

but, press anykey /OK, then it will continue anyways, so flip knows what would happen IF you save something to disc.... :?

EDIT: do now :D Disc fault 18 at :0 00/09
Last edited by CMcDougall on Wed Mar 01, 2017 9:59 pm, edited 1 time in total.
ImageImageImage

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Wed Mar 01, 2017 9:58 pm

steve3000 wrote:Just reading this with interest, as I've seen the same issue in BeebEm. And it just happens that I'm sat next to my BBC B with Acorn DFS 0.9 (8271) interface and a blank disc in the drive... So...
lurkio wrote:You can see this if you start up BeebEm, insert a disc image (or create a blank one), make sure write-protection is disabled, type *SAVE X 0 0, wait for the disc-drive sound to stop, and then immediately type *CAT. The disc catalogue will be displayed without any physical access to the disc:

I can confirm a real BBC does not do this. The real BBC accesses the drive immediately again on *CAT, and file X is present.

Thanks!

So this would appear to be quite a significant bug in BeebEm then..?

:shock:

steve3000
Posts: 1711
Joined: Sun Nov 25, 2012 12:43 am

Re: Beebem save state and load state

Postby steve3000 » Wed Mar 01, 2017 10:07 pm

lurkio wrote:So this would appear to be quite a significant bug in BeebEm then..?

I definitely think there is some type of caching bug in the 8271 emulation. So it was nice to be able to confirm this.

I had previously noticed that when changing between discs on BeebEm (using the menu entry to Load disc 0), the first *Cat on the new disc usually shows the previous disc. The second *Cat always correctly shows the new disc.

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Thu Mar 02, 2017 8:48 am

fuzzel wrote:I'm trying to understand how the save state and load state commands in Beebem affect saved .ssd and .dsd discs ... The reason I'm asking is I use save state a lot and I seem to lose a few save files now and again if I go back to previous save states.

So, if you've been following this thread, you'll see that the reason you've been losing savegames is probably because there seems to be quite a major bug in the way BeebEm emulates an 8271 disc interface.

:(

The best advice I can offer till the bug's fixed is that you should only use BeebEm's Save State feature -- and avoid saving your position to .SSD/DSD in-game.

:idea:

fuzzel
Posts: 208
Joined: Sun Jan 02, 2005 1:16 pm
Location: Cullercoats, North Tyneside

Re: Beebem save state and load state

Postby fuzzel » Fri Mar 03, 2017 12:54 pm

Sound advice Lurkio and thanks for all contributions everyone. Looks like I'm not going senile after all although I'm still not sure where all those save files have actually ended up!
Does anyone know how often Beebem is updated? Also I presume people send Mike Wyatt a list of bugs to be fixed in the next version....

User avatar
CMcDougall
Posts: 5623
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland

Re: Beebem save state and load state

Postby CMcDougall » Fri Mar 03, 2017 6:19 pm

^ it used to get updates about every 3month, but not been updates for now about 5years....
Jon (on the forum) was the last to do good updates =D>
ImageImageImage

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Fri Mar 03, 2017 10:18 pm

fuzzel wrote:I'm still not sure where all those save files have actually ended up!

The problem manifests in Mac BeebEm as well. You can see this if you create a blank, writable .SSD and then do this:

    1.png
Then save state with filename s1.uef.

The .SSD now contains one file: F1.

Then *SAVE three more files:

    2.png
The .SSD now contains four files: F1, F2, F3 and F4.

Now load Saved State s1.uef and *SAVE a new file: X. Then catalogue the disc:

    3.png
Files F2, F3 and F4 have been overwritten by file X because state s1.uef "doesn't know" about them (thanks to the 8271 catalogue-caching bug we've been discussing in this thread)!

CMcDougall wrote:^ it used to get updates about every 3month, but not been updates for now about 5years....
Jon (on the forum) was the last to do good updates =D>

I emailed Jon Welch (Mac BeebEm developer), who said he's on holiday but will have a look at the 8271 code when he gets back. I also emailed Mike Wyatt (Win BeebEm), but haven't had a reply yet.

:idea:

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Beebem save state and load state

Postby pstnotpd » Sat Mar 04, 2017 7:26 am

I can confirm this occurs in my "draft" 4.15 build for windows as well. I'm not very familiar with the code but can have a look. If Jon or others respond please let us know so I can incorporate it in my build.

I was thinking about publishing to the stardot github community when I think it's stable. There's now a weird "invalid map" bug in "B" emulation.

Build environment W10, VS 2015 and the legacy Directx SDK

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Beebem save state and load state

Postby pstnotpd » Sat Mar 04, 2017 8:34 am

Right, I've uploaded the sources of my "working" BeebEm 4.15 W10 version to github for those interested.

https://github.com/pstnotpd/BeebEm

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Sat Mar 04, 2017 8:59 am

pstnotpd wrote:Right, I've uploaded the sources of my "working" BeebEm 4.15 W10 version to github for those interested. https://github.com/pstnotpd/BeebEm

Have you fixed the 8271 emulation bug?

:?:

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Beebem save state and load state

Postby pstnotpd » Sat Mar 04, 2017 9:11 am

lurkio wrote:Have you fixed the 8271 emulation bug?


Nope, but as this is a work in progress I hope it will be picked up in the stardot area where we can combine forces to get a fresh new windows version. There's now also a weird invalid map bug in BBC B emulation which shows a messagebox but doesn't seem to have any adverse effect further on.

g7jjf
Posts: 354
Joined: Sun Aug 07, 2005 7:29 pm
Location: Notts, England
Contact:

Re: Beebem save state and load state

Postby g7jjf » Sat Mar 04, 2017 10:32 am

I am on holiday at the moment so don't have access to my PC to check anything out but looking at the BeebEm source code on my phone, I have found something which may be relevant (if someone else can double check and perhaps verify).

In disc8271.cpp, there is a function called DoReadDriveStatusCommand which returns the current drive status in the following line :

Code: Select all

  ResultReg=0x80 | (Selects[1]?0x40:0) | (Selects[0]?0x4:0) | (Track0?2:0) | (WriteProt?8:0);

This implies that bits 2 and 6 reflects the currently selected drive, ie bit 2 is set when drive 0 is selected and bit 6 when drive 1 is selected.

However, looking at the data sheet for the 8271 controller, this says that these bits indicate the current state of the input pins and these pins are active low (again, according to the data sheet).

So, should the above line read :

Code: Select all

  ResultReg=0x80 | (Selects[1]?0:0x40) | (Selects[0]?0:0x4) | (Track0?2:0) | (WriteProt?8:0);

instead ?

The disassembly of the *CAT command shows :

Code: Select all

8AD8 JSR setCECF_driveno      834D
     JSR GetDriveNo_withInit  8358
     JSR FDC_DriveReady       8BBD  check bit 2, zero if ready
     BEQ LoadCurDrvCatalog
     LDA CurrentDrvCatalog    1082
     CMP CurrentDrv           CF
     BNE LoadCurDrvCatalog
     RTS
.LoadCurDrvCatalog
     STUFF TO RE-READ THE DISC

which is looking for a zero bit to re-read the disc rather than used the stored cache.

I can't recompile any code to check but this might be the problem.

Or I am more likely waffling and talking rubbish as usual.

Jon

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Beebem save state and load state

Postby pstnotpd » Sat Mar 04, 2017 10:54 am

g7jjf wrote:So, should the above line read :

Code: Select all

  ResultReg=0x80 | (Selects[1]?0:0x40) | (Selects[0]?0:0x4) | (Track0?2:0) | (WriteProt?8:0);

instead ?
.....
Jon


Tested this on the W10 build. It completely locks up on initial >*CAT now :(

Reverted back to the original and it works as usual.

User avatar
ThomasAdam
Posts: 91
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: Beebem save state and load state

Postby ThomasAdam » Sat Mar 04, 2017 11:23 am

pstnotpd wrote:Right, I've uploaded the sources of my "working" BeebEm 4.15 W10 version to github for those interested.

https://github.com/pstnotpd/BeebEm


Are you wanting me to archive the current repository and fork this one to it?

g7jjf
Posts: 354
Joined: Sun Aug 07, 2005 7:29 pm
Location: Notts, England
Contact:

Re: Beebem save state and load state

Postby g7jjf » Sat Mar 04, 2017 11:41 am

pstnotpd wrote:
g7jjf wrote:So, should the above line read :

Code: Select all

  ResultReg=0x80 | (Selects[1]?0:0x40) | (Selects[0]?0:0x4) | (Track0?2:0) | (WriteProt?8:0);

instead ?
.....
Jon


Tested this on the W10 build. It completely locks up on initial >*CAT now :(

Reverted back to the original and it works as usual.


Oh well, worth a shot.

I will have to single step through the DFS code when I get back and have a proper look.

User avatar
hoglet
Posts: 6626
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Beebem save state and load state

Postby hoglet » Sat Mar 04, 2017 11:50 am

Edit: Move thoughts on github BeebEm to the Beebem on Github thread.

Dave

g7jjf
Posts: 354
Joined: Sun Aug 07, 2005 7:29 pm
Location: Notts, England
Contact:

Re: Beebem save state and load state

Postby g7jjf » Tue Mar 07, 2017 5:14 pm

steve3000 wrote:Just reading this with interest, as I've seen the same issue in BeebEm.

And it just happens that I'm sat next to my BBC B with Acorn DFS 0.9 (8271) interface and a blank disc in the drive... So...
lurkio wrote:You can see this if you start up BeebEm, insert a disc image (or create a blank one), make sure write-protection is disabled, type *SAVE X 0 0, wait for the disc-drive sound to stop, and then immediately type *CAT. The disc catalogue will be displayed without any physical access to the disc:

I can confirm a real BBC does not do this. The real BBC accesses the drive immediately again on *CAT, and file X is present.


Can you please double check this as looking through the DFS 0.9 code, it does look like the catalogue is cached the first time after doing the *SAVE and not re-read from disc (as well as other commands like *DELETE). B-Em also does the same as BeebEm as well.

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Tue Mar 07, 2017 7:16 pm

g7jjf wrote:
steve3000 wrote:it just happens that I'm sat next to my BBC B with Acorn DFS 0.9 (8271) interface and a blank disc in the drive... So...
lurkio wrote:You can see this if you start up BeebEm, insert a disc image (or create a blank one), make sure write-protection is disabled, type *SAVE X 0 0, wait for the disc-drive sound to stop, and then immediately type *CAT. The disc catalogue will be displayed without any physical access to the disc:

I can confirm a real BBC does not do this. The real BBC accesses the drive immediately again on *CAT, and file X is present.

Can you please double check this as looking through the DFS 0.9 code, it does look like the catalogue is cached the first time after doing the *SAVE and not re-read from disc (as well as other commands like *DELETE). B-Em also does the same as BeebEm as well.

Yes, it would be good if someone could either corroborate or contradict that result because I'm getting this nagging feeling that my old Beeb from BITD used to do the same thing that BeebEm does -- i.e. perform a *CAT without physically accessing the disc drive by just using the cached catalogue instead. That was on DFS 1.2 (DNFS), which is the only DFS I ever had back then.

Is that what actually used to happen, or am I just going mad?

:? :?:

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Wed Mar 08, 2017 11:57 am

If you have access to a real Beeb with an 8271 Floppy Disc Controller and DFS (ideally DFS 0.9 or 1.2 or both!), could you please try the following on a real disc-drive with a real non-write-protected floppy disc?:

    Type *SAVE X 0 0 and wait for the disc-drive to stop spinning and go quiet. Then immediately type *CAT.

      Is the disc catalogue displayed without any physical access to the disc? (I.e. are there no sounds made by the disc-drive straight after the *CAT?)
    If you then type *CAT for a second time, what happens?
:?:


fuzzel wrote:I'm trying to understand how the save state and load state commands in Beebem ...
Coeus wrote:If this is down to caching this is probably a bug ...
steve3000 wrote:Just reading this with interest, as I've seen the same issue in BeebEm.
CMcDougall wrote:^only stupid ADFS does not refresh the disc with a *CAT ...
pstnotpd wrote:I can confirm this occurs in my "draft" 4.15 build for windows as well ...
g7jjf wrote:I am on holiday at the moment ...
ThomasAdam wrote:Are you wanting me to archive the current repository and fork this one to it? ...
hoglet wrote:Edit: Move thoughts on github BeebEm ...

User avatar
hoglet
Posts: 6626
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Beebem save state and load state

Postby hoglet » Wed Mar 08, 2017 2:07 pm

lurkio wrote:If you have access to a real Beeb with an 8271 Floppy Disc Controller and DFS (ideally DFS 0.9 or 1.2 or both!), could you please try the following on a real disc-drive with a real non-write-protected floppy disc?:

    Type *SAVE X 0 0 and wait for the disc-drive to stop spinning and go quiet. Then immediately type *CAT.

      Is the disc catalogue displayed without any physical access to the disc? (I.e. are there no sounds made by the disc-drive straight after the *CAT?)
    If you then type *CAT for a second time, what happens?
:?:

With Acorn DFS 1.21 (DFS 1.20 patched for 3.5" drives) there doesn't seems to be any caching of the catalogue. Both *CAT's in the above sequence span up the drive and re-read the physical disk.

This does seem to differ from the behaviour in B-Em, which doesn't spin up the drive for the first *CAT after a *SAVE (or a *LOAD).

I would say there is an emulation bug here.

Dave
Last edited by hoglet on Wed Mar 08, 2017 2:18 pm, edited 1 time in total.

User avatar
lurkio
Posts: 1292
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Beebem save state and load state

Postby lurkio » Wed Mar 08, 2017 2:18 pm

hoglet wrote:
lurkio wrote:If you have access to a real Beeb with an 8271 Floppy Disc Controller and DFS (ideally DFS 0.9 or 1.2 or both!), could you please try the following on a real disc-drive with a real non-write-protected floppy disc?:

    Type *SAVE X 0 0 and wait for the disc-drive to stop spinning and go quiet. Then immediately type *CAT.

      Is the disc catalogue displayed without any physical access to the disc? (I.e. are there no sounds made by the disc-drive straight after the *CAT?)
    If you then type *CAT for a second time, what happens?

With Acorn DFS 1.21 (DFS 1.20 patched for 3.5" drives) there doesn't seems to be any caching of the catalogue. Both *CAT's in the above sequence span up the drive and re-read the physical disk.


Thanks, Dave! Don't suppose you can check DFS 0.9 at all?

:?:


Return to “emulators”

Who is online

Users browsing this forum: oss003 and 1 guest