Emulated discs - a modest proposal

discussion of beeb/electron applications, languages, utils and educational s/w
crj
Posts: 322
Joined: Thu May 02, 2013 4:58 pm

Emulated discs - a modest proposal

Postby crj » Mon Oct 02, 2017 2:17 am

There are several systems out there which allow you to stick disc images in SD cards or similar and have them appear as virtual drives on the Beeb. I get the impression all of these work by offering hacked versions of DFS/ADFS.

So. We have many hacked DFSes and ADFSes in circulation, all mutually incompatible.

What if, instead, we hacked DFS and ADFS to indirect all disc accesses via a service call? The obvious numbers to use would be service call &7F for DFS and &72 for ADFS. On entry:
  • A=&72/&7F
  • X=your ROM number
  • Y=disc number
  • (&F0)=request descriptor in OSWORD &72/&7F format
If a ROM decides to provide disc Y, it handles the request and sets A=0. Now different drives can be provided dynamically by different alternatives to the real floppy/hard disc hardware.

I've not yet dug around inside either filesystem to see how close its internal read/write calls are to the respective OSWORDs; I imagine they'd be pretty similar. If they're not, an alternative would be to play nice with DFS/ADFS by accepting requests in whatever internal format they each use.

duikkie
Posts: 2711
Joined: Fri Feb 07, 2014 3:28 pm

Re: Emulated discs - a modest proposal

Postby duikkie » Mon Oct 02, 2017 6:27 am

try it with smart-spi all software is free and lot of explaining files , the trouble is the software it is loading even args is sometimes a problem (elite) , some software use osword calls to direct disc access, and so on .

i see allso a problem with chips mmc/mmb systems use userport , real disc 8271/1170 , ch375b use tube ( no chip from bbc)

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

Re: Emulated discs - a modest proposal

Postby hoglet » Mon Oct 02, 2017 6:47 am

It's not just providing an abstraction for disk access. You also need to consider all the utilities needed to make a SD card filesystem usable, analogous to things you might to physically with a floppy disk, such as:
- *DIN (choose a disk and put it in the drive)
- *DOUT (remove a disk from the drive)
- *DOP U/P (manage the write protection)
- *DCAT (list the disks in your disk box)

The code for these needs to go somewhere.

Taking a different tack, I've been rather struck by BeebSCSI, which emulates an original SCSI hard disk in such a way that the original version of ADFS work perfectly (well done Simon!). On the SD Card it uses a FAT filesystem, so it's easy to manage the disk images, and they are directly compatible with BeebEm (I think...).

Something that did the same for floppy disks would be very neat, i.e. plugged into the floppy disk port.

Yes, they do exist (Gotek, HxC) commercially but you don't hear them being used on Acorn machines very much, and they are quite expensive (edit: actually cheaper than I thought....)

Coincidentally, rhe source for the Gotek has just been released:
http://www.stardot.org.uk/forums/viewto ... 16&t=13718

Dave

User avatar
sydney
Posts: 1986
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne

Re: Emulated discs - a modest proposal

Postby sydney » Mon Oct 02, 2017 7:31 am

Would it be possible to somehow connect a pi to the floppy disk controller IC socket and have some bare metal code imitating a floppy controller but using a usb stick as the source for ssd's. Something like pitubedirect - pifloppydirect maybe?

duikkie
Posts: 2711
Joined: Fri Feb 07, 2014 3:28 pm

Re: Emulated discs - a modest proposal

Postby duikkie » Mon Oct 02, 2017 8:52 am

For usb stick use ch375b project with smart- usb on tube connector

sydney wrote:Would it be possible to somehow connect a pi to the floppy disk controller IC socket and have some bare metal code imitating a floppy controller but using a usb stick as the source for ssd's. Something like pitubedirect - pifloppydirect maybe?

User avatar
danielj
Posts: 5346
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester

Re: Emulated discs - a modest proposal

Postby danielj » Mon Oct 02, 2017 9:06 am

No good if I want to use the tube though :(

I think the combination of HxC/gotek and beebscsi caters for "completely compatible solid state using original filesystems", then the MMC/SD/USB solutions work for the "more convenient".

Hence->I like the idea of making the gotek more convenient :) The HxC has the added benefit of being able to run protected disk images derived from raw flux images :D.

d.

duikkie
Posts: 2711
Joined: Fri Feb 07, 2014 3:28 pm

Re: Emulated discs - a modest proposal

Postby duikkie » Mon Oct 02, 2017 9:19 am

you can still use the tube for all other stuff only 3 adress are used , user hardware adress if i am right :)

danielj wrote:No good if I want to use the tube though :(

I think the combination of HxC/gotek and beebscsi caters for "completely compatible solid state using original filesystems", then the MMC/SD/USB solutions work for the "more convenient".

Hence->I like the idea of making the gotek more convenient :) The HxC has the added benefit of being able to run protected disk images derived from raw flux images :D.

d.

User avatar
DutchAcorn
Posts: 1631
Joined: Fri Mar 21, 2014 9:56 am
Location: Maarn, Netherlands

Re: Emulated discs - a modest proposal

Postby DutchAcorn » Mon Oct 02, 2017 9:37 am

How about an HxC that you can control through commands on the Beeb. Ideally you'd want to keep the user port free but if you could use the user port to catalogue and mount image files that are present on the HxC you could create a separate support rom and keep the DFS/ADFS roms original.

Just a thought... :D
Paul

crj
Posts: 322
Joined: Thu May 02, 2013 4:58 pm

Re: Emulated discs - a modest proposal

Postby crj » Mon Oct 02, 2017 3:00 pm

hoglet wrote:It's not just providing an abstraction for disk access. You also need to consider all the utilities needed to make a SD card filesystem usable, analogous to things you might to physically with a floppy disk, such as:
- *DIN (choose a disk and put it in the drive)
- *DOUT (remove a disk from the drive)
- *DOP U/P (manage the write protection)
- *DCAT (list the disks in your disk box)

The code for these needs to go somewhere.

My intention was that such things - and the service call handler - would go in an interface-specific utility ROM. Or sideways RAM. Or whatever.

Yes, on the BBC Micro DFS is an 8K ROM, which kinda invites using the other 8K for interface-specific extensions. But that space isn't free in the BBC Master. What's more, if I'm going to meddle with DFS and ADFS I'd like to do that just once and have a stable Master ROM, while still being able to play with different hardware.

This also appeals to my notions of modularity and elegance. It feels like the right way, the Acorn way, to do such things. In a slightly inverted sense, it's even reminiscent of the ADFS/FileCore distinction in RISC OS.

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Emulated discs - a modest proposal

Postby sweh » Mon Oct 02, 2017 3:15 pm

Solidisk did something similar with their DDFS and ADFS ROMs. They would check a magic location (?&3A3==3, I think) and if so would call OSWORD 78/79/7B to do lower level block stuff. This allowed for RAMdisks; just intercept those calls and check the drive number (?&CF==?&10FF) and then read/write the necessary blocks.
Rgds
Stephen

User avatar
jgharston
Posts: 2759
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Emulated discs - a modest proposal

Postby jgharston » Mon Oct 02, 2017 4:05 pm

crj wrote:What if, instead, we hacked DFS and ADFS to indirect all disc accesses via a service call? The obvious numbers to use would be service call &7F for DFS and &72 for ADFS.

No, the obvious calls would be an OSWORD service call. The APIs are already defined:
Perform external MFM sector access
Perform external FM sector access

The documentation says "for RAMFS" but anything could respond. ADFS 1.x3 revision 23 already does external calls for drive 6 and 7, I just haven't got around to writing any drivers to respond to it yet.

Similarly, John Kortink's patched filing systems for use with the GoMMC/GoSDC translate disk access to an OSWORD &B0 call, so the patched filing systems are already available, just write a driver to respond to the OSWORD call.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 2759
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Emulated discs - a modest proposal

Postby jgharston » Mon Oct 02, 2017 4:15 pm

crj wrote:Yes, on the BBC Micro DFS is an 8K ROM, which kinda invites using the other 8K for interface-specific extensions. But that space isn't free in the BBC Master.

DFS 2.24 is only about 12K. I stuck a mouse driver and a few other bits in the spare space in my machine.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

crj
Posts: 322
Joined: Thu May 02, 2013 4:58 pm

Re: Emulated discs - a modest proposal

Postby crj » Tue Oct 03, 2017 4:50 am

jgharston wrote:No, the obvious calls would be an OSWORD service call.

Well... I guess it doesn't hurt to make it an OSWORD call. Though it feels very important to me that it be possible for there to be more than one claimant for different drive numbers, so you could have, say, one person's IDE hard drive, a second person's SD card and a third person's ramdisc.

This would also require a culture of APIs that let people mount virtual discs to specific drive numbers, and subsequently dismount them.

I'm guessing you wrote the specifications for those OSWORDs rather than merely transcribing them to the wiki? It feels as though the spec should be tightened to distinguish between drive not present (simply pass the call on for someone else to handle) and media not present (return an error).

OSWORD &B0 doesn't seem to support multiple drives at all? Unless I misunderstand. This is surprising, as it seems natural someone might want two different GoMMC virtual disks on different drive numbers simultaneously.


I also feel it would be helpful if the call was made for all disc numbers, not just ones lacking native support in DFS/ADFS. Someone might well want to cover their physical drive 0 with a virtual drive 0.

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Emulated discs - a modest proposal

Postby sweh » Tue Oct 03, 2017 10:30 pm

crj wrote:
jgharston wrote:No, the obvious calls would be an OSWORD service call.

Well... I guess it doesn't hurt to make it an OSWORD call. Though it feels very important to me that it be possible for there to be more than one claimant for different drive numbers, so you could have, say, one person's IDE hard drive, a second person's SD card and a third person's ramdisc.

That happens automatically; if your ROM looks at the call and doesn't like it ("not my drive") then you just restore the registers and return and the OS will continue to call the next ROM.
Rgds
Stephen

crj
Posts: 322
Joined: Thu May 02, 2013 4:58 pm

Re: Emulated discs - a modest proposal

Postby crj » Tue Oct 03, 2017 11:23 pm

sweh wrote:That happens automatically


Not quite.

It's easy to do, but it doesn't happen unless you specify it's how claimants ought to behave.

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Emulated discs - a modest proposal

Postby sweh » Wed Oct 04, 2017 1:29 am

From the Advanced User Guide

If a ROM does not wish to provide the service, it should exit with all the registers preserved. If, however, the ROM performs the requested service, and wishes to prevent other ROMs also performing the service, the accumulator should be zero on exit.


We can argue about "provide the service", but the intent (to me) is clear; if this call (service call 8, in this case) isn't intended for this ROM (e.g. wrong drive number) then it should follow the standard. You have to explicitly set A=0 to prevent other ROMs from seeing the call.
Rgds
Stephen

User avatar
jgharston
Posts: 2759
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Emulated discs - a modest proposal

Postby jgharston » Thu Oct 05, 2017 12:29 am

crj wrote:This would also require a culture of APIs that let people mount virtual discs to specific drive numbers, and subsequently dismount them.
As with any virtual disk access system, such as *SDCDISC on GoSSD, *DIN on the system that uses *DIN. I quite like the syntax of *MOUNT drivenum filename and if the service ROM sees the *MOUNT command with more than one parameter it ignores it and allows the MOS to pass it to the filing system to be implemented as the normal filing system command.

crj wrote:I'm guessing you wrote the specifications for those OSWORDs rather than merely transcribing them to the wiki?

No, Acorn wrote them. &76 and &77 were cloned from the hardware OSWORDs for use with RAMFS with the identical parameters so an image call is identical to a hardware call.

crj wrote:It feels as though the spec should be tightened to distinguish between drive not present (simply pass the call on for someone else to handle) and media not present (return an error).

Drive not present (somebody else handle) -> don't claim the OSWORD, as with any other service call
Media not present (return an error) -> claim the OSWORD and return an error. Specifically, OSWORD &77 return result=&1E (disk or drive not present), OSWORD &76 return (I think) result=&02 (drive door open).

crj wrote:OSWORD &B0 doesn't seem to support multiple drives at all?

Yes it does. GoMMC/GoSDC implements it as each drive as an offset into the image, but there is absolutely nothing to stop an OSWORD &B0 driver translating that offset into a specification for individual images. For example, instead of &40000+x being drive 1 within a single selected image file, &40000+x is offset x into the image file selected for drive 1.

crj wrote:I also feel it would be helpful if the call was made for all disc numbers, not just ones lacking native support in DFS/ADFS. Someone might well want to cover their physical drive 0 with a virtual drive 0.

OSWORD &B0 IS made for all drives, as the patched filing systems have no concept of physical drives, all access goes via OSWORD &B0, with - in the default setup - the GoMMC/GoSDC ROM claiming the call. Just use the appropriate patched filing system and a different support ROM that responds to OSWORD &B0, and provides commands - as GoMMC/GoSDC do - to specify what the OSWORD &B0 call translates to. For example, *SDCDisc GAMES1 results in OSWORD &B0 accessing the image file GAMES1 on the SDC card.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 7 guests