avatar_SOS

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

Started by SOS, 00:18, 23 March 18

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


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

Quote from: m_dr_m on 23:11, 22 May 21
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.


Quote from: m_dr_m on 23:11, 22 May 21
* 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

Quote from: SOS on 08:33, 13 November 18Yes |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

IRC:  #Retro4All on Freenode

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)







your amstrad news source in spanish language : https://auamstrad.es

Powered by SMFPacks Menu Editor Mod