CubeMDOS / FAT16+FAT32-OS - for XMASS, Symbiface_2+3,HXC/FlashFloppy

[m_dr_m]

What advantages of CubeDOS are there over UniDOS and vice versa?

See: https://www.cpcwiki.eu/forum/applications/unidos-the-new-multi-device-amsdos-replacement/msg201599/#msg201599 and following posts.

[m_dr_m]

Request #1c: |getpath rsx should return "A:" in |a mode, and HXC path in |Ha / |Hb mode.
Rationale:
* More consistent with other DOS
* |A / |D doesn't set current drive (&a700 by default) -> It makes hard to know programmatically which drive is active!


Thank you!

[SOS]

Request #1c: |getpath rsx should return "A:" in |a mode, and HXC path in |Ha / |Hb mode.

Hmm, this is more complicated as expected.
YANCC uses this function, so it need to be changed.
The function is also be programmed in M4Dos, so it need also be changed.

* More consistent with other DOS
* |A / |D doesn't set current drive (&a700 by default) -> It makes hard to know programmatically which drive is active!

&a700? you must get the correct address from &be7d.
CubeMDOS is here 100% like amsdos

Btw. the loading of large files >64kb seems now to be working (save is open).
But i have no success in testing this with orgams and - what makes me very confused - big problems with only orgams+amsdos (no other ROMs / Mass Storages). Can you please send me a testing file with PM , which i can load & (later) save with orgams?

[m_dr_m]

Bug #80 AMSDOS vs CubeMDOS: Different behaviour for DISC IN CHAR past hard end of file

First I'll start with *common* behaviours: when &1A (ASCII for End Of FILE) is met, flags are NC, NZ.
But for binary files, &1A is a byte like another.
So we dismiss the flags and continue reading, the behaviour is still the same (next char properly read, Carry if not another &1A).


Now, past the "real" end of file, if we continue reading:
* On AMSDOS: We get Carry with garbage chars, until we reach end of AMSDOS "record" (&80 long chunk). Note: that's because AMSDOS cannot know the real end of file, since the precise length is unknown, only the number of records.
* On CubeMDOS: We get &1A, NC, NZ forever.


Implication: if we use a routine that read until flags NC,Z:
- On AMSDOS, we might read a bit too much (post EOF garbage). That's not an issue in most cases.
- On CubeMDOS: infinite loop.
This provoked bug #11c on Orgams


Now the caller can use a workaround:
- For pure ascii text, stop at &1a.
- For binary text, the caller needs to know the real length in some way, or use an unambiguous sentinelle.
Yet it would be nice to be as compatible as possible.


Reference: see joined little source used for analysis.

[CraigsBar]

Yes |DRIVE is caught by CubeMDOS, but when execute, i'm doing a decision "ParaDOS found?", so if yes, I execute the ParaDOS-RSX.
Works here   
Could you reproduce that in WinApe?
Same effect with Parados 1.2?
You can attach the big-floppy-drives? (so Parados is loaded correctly)
Please, could you send me the "?peek(&b0c7)"  and b0c8 & b0c9 values

SOrry to dig up such an old topic. But i have just got around to installing this all on my XMASS on my 2nd 6128+ that has no mods. I will however be using a Parados 1.2+ cartridge to get rid of the boot menu!

Here's the problem. As detailed by the original poster, I cannot access the DRIVE for Parados, I guess because it is the 1.2+ version. Anyway the requested PEEK'ed values are

&b0c7 = 5
&b0c8 = 6
&b0c9 = 36

[Cwiiis]

Using cubemdos with the RSF3, making a directory doesn't seem to work correctly - it takes a very long time (reasonable, I suppose?) but afterwards, if you change to the directory, a listing will hang indefinitely. Looking at the filesystem on a Windows machine afterwards, the directory appears to be created correctly, but creation/modification time appears blank. Removing and recreating the directory on Windows restores normal behaviour in cubemdos.

I also notice that orgams requires |v2 to load files, but saving works in both |v1 (the default) and |v2. Loading in orgams also works correctly when inside a .dsk. Game support inside .dsk images seems to be a mixed bag, presumably because of games doing things like direct access - notably, Pinball Dreams just spins the disk drive indefinitely after launching, but that same game does work with the disk emulation on the usifac2 - maybe because it assumes drive A? A similar drive A emulation mode for .dsk images, if possible, may help with compatibility.

Overall, I've found cubemdos quite pleasant to work with, though I get the feeling that compatibility with legacy software isn't quite as good as unidos. Certainly looking forward to the next version, whenever that may be

[XeNoMoRPH]

Although I know that right now @SOS is inactive, I would like to know if someone has successfully configured CubeMDOS for access "DSK" to use it on a CPC464?
According to the specifications it should work, in fact I have managed to access the content of a DSK on a couple of occasions, but I don't remember how I did it, because I was trying many combinations and I think it was by chance.

Hardware used: RSF3 ( it's like a Simbiface 3 really for CubeMDOS)

[Galatronic]

Hi all, I'm experiencing problems using Cubemdos and 32RomBooster roms togheter, on a megaflashrom card. They seems to can't work togheter, I have placed Cubemdos on slot 6 and Booster on slot 15, I have to deactivate Booster rom to allow Cubemdos to works fine, otherwise only the booster rom is detected. Any tip about?  I'm using a cyboard (SF2 clone) + Megaflahrom + 1mb ram expansion.Thanks

[HAL6128]

Don't know about the Problem, but instead of using the old Booster Rom you could try the more modern Firmware Rom 3.15 / 3.16?

[Galatronic]

Don't know about the Problem, but instead of using the old Booster Rom you could try the more modern Firmware Rom 3.15 / 3.16?

Can you tell me more please?

[HAL6128]

Hm, maybe I was a little too fast with my assumption. I thought that the MegaFlash could also replace the Lower ROM, but it seems that it doesn't. So, the Firmware ROM ( X-MEM - CPCWiki ) won't be usable (which initialize ROMs 0-31).
How about using UniDOS as an IDE interface driver? Which interface do you use?

[Galatronic]

Hm, maybe I was a little too fast with my assumption. I thought that the MegaFlash could also replace the Lower ROM, but it seems that it doesn't. So, the Firmware ROM ( X-MEM - CPCWiki ) won't be usable (which initialize ROMs 0-31).
How about using UniDOS as an IDE interface driver? Which interface do you use?

I prefer cubemdos because most easy to use... I'm using a cpc6128 and  a megaflash that could be able to replace the rom 0 (but not the dos rom 7) . But seems that cubemdos and 32rombooster rom can't live togheter ...

[HAL6128]

Here are two more possibilities / alternativs. Maybe it helps? Look at the thread from @Ast 
A piece of assembler code by him or the use his ImpDos ?
https://www.cpcwiki.eu/forum/programming/rom-initialisation/

[Ast]

This piece of code is also used in iMPdos, i confirm !