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

[SOS]

I reproduce ~50% of the time.
* Booting on D.
* Working on D.
* Resetting to exist Orgams.
* |A

Could you describe the steps a Little bit more?
"Resetting to exist Orgams." ?
CPC-Reset, starting Orgams from ROM, save & load something on A or ?

Here is what I've understood. I might be wrong:
- If I choose FAT format, it will try to use 400Mb. So, once the first 128Mb of the DOM is used, all hell breaks loose.

I want to quote Connor MacLeod here: There can only be one.
Yes, CubeMDOS supports only the 1st Partition of a media, so the Format kills every existing Partition. (i do not Change this)

Not counting the 2ko for cat, cannot we reuse some AMSDOS buffer (like the one used to read sectors)?
Do you plan to maintain the 64 files directory limit (I would be fine with that)?

hmmm....
my english is not very perfect    (so i dont know exactly, if i understand you correctly)

For CAT i use the 2KB Buffer, when i detect buffer-overflow, i will print an information in the cat-buffer.
The ReadSector-Buffer in AMSDOS i use it intensively.
64-Files-Limit?
I copied with YANCC 68 files in one directory and do a save&load in BASIC , so 69 files are no problem.
=> i need a more reproduceable szenario

I could do the sorting routine, if you wish!

(thanks)
Hmmm, i dont know
The problem is, that my ROM is nearly full and this may break the 16KB-Size.
I think, the sorting will be very problematic.
The whole Directory must be read by the CPC (e.g. 712 Files) and then sorted in the memory.
It could consume a lot of the 64KB Main-RAM....

[Fessor]

Sorting, kind of, could be done by |dir,"a*", |dir,"b*" etc..Maybe a command like |dira2z could be introduced, which intern runs through the alphabet and calls the dir-output with filemasks from "a*" to "z*"

[m_dr_m]

1/ |A
OK I can reproduce consistently: if firmware zone is zeroed, then I have to enter |AOFF to access A, despite my configuration (cf config.bas).
I like the fact that:
• X-MASS is the default on reset.
• The path is conserved across warm resets.
I'd like to have AOFF behavior forced all the time.

3/ 64 files per directory limit
I got a crash each time I reached 65 files.

Code: [Select]

|mkdir,"tmp":|cd,"tmp"
for i=1 to 99:print i:save str$(i):next-> Boom after i=63.

4/ FAT format
I'm not sure to see why FAT32 format couldn't be restricted to 128Mb, so that:
• |FREE is accurate
• More importantly, disc full is properly detected and no overwriting occurs!

9/ Sort directory712 files !? I don't mind if the sorting is kind of disabled for such extreme cases.
It doesn't mean it should be thrown away for day to day usage !
We could come with a pretty fast solution for directories with <=128 files.
And not that big in memory! Tell me how much space do you have (:


13/ Starkos hangs with 'GetDir'
It could be a bug with Starkos, but if the ROM is fully AMSDOS compatible why wouldn't it work?

Thank you for your attention!

[m_dr_m]

Sorting, kind of, could be done by |dir,"a*", |dir,"b*" etc..Maybe a command like |dira2z could be introduced, which intern runs through the alphabet and calls the dir-output with filemasks from "a*" to "z*"

That's an interesting approach, modulo some caveats:

• What if all files begins by A? By the time you fix these kinds of issue, you realize that you should have done radix sort from the beginning!
• Calling dir and then filtering is elegant design-wise, but would be too inefficient.
• No, you shouldn't introduce a new RSX! You don't want a ton of commands with distinct flaws. You should have one command only, which does the right thing!

[SOS]

1/ |A
OK I can reproduce consistently: if firmware zone is zeroed, then I have to enter |AOFF to access A, despite my configuration (cf config.bas).
I like the fact that:
• X-MASS is the default on reset.
• The path is conserved across warm resets.
I'd like to have AOFF behavior forced all the time.

the "firmware zone" is zeroed could be a problem.
Please could you describe the completely point "1" with PM more clearly?

3/ 64 files per directory limit
I got a crash each time I reached 65 files.

Code: [Select]

|mkdir,"tmp":|cd,"tmp"
for i=1 to 99:print i:save str$(i):next-> Boom after i=63.

I can reproduce that now (thanks), crashes only on FAT16.
Prio 1

4/ FAT format
I'm not sure to see why FAT32 format couldn't be restricted to 128Mb, so that:
• |FREE is accurate

FAT32 is not restricted to 128MB, you can use large media's.
I dont optimize the format.bas anymore, because you can format your media with Windows, Linux, ....
The FREE-Display on FAT32 must be correct, else it's a strong indicator, that something is going very wrong!
FREE on FAT16 is.....        So this should be nearly correct....

• More importantly, disc full is properly detected and no overwriting occurs!

I have checks against possible overwriting-issues, so this "should" be not occur.
Disc full detection: Should be work too
Do you have problems with this two points?

And not that big in memory! Tell me how much space do you have (:

Much too few.
Maybe (or not) i will later release an add-on-rom, where i have enough space.

13/ Starkos hangs with 'GetDir'
It could be a bug with Starkos, but if the ROM is fully AMSDOS compatible why wouldn't it work?

I check this later

I must now hurry-up to continue with Symbiface3-Programming, i think maybe april-mai i will correct the bugs.
(there are other open issues, which i want to fix, e.g. FlashFloppy-Support on a Plus-Machine)

[TotO]

The FAT32 strange limitation is to not be able to support partitions under 32MB.

[angelcaio]

Hi. I have connected a DOM to the PC with an adapter and I have presented it to WinApe:
   


With the ROM’s configuration (with firmware 3.16 and extensions)


The Format.bas utility does not do anything either. Leave it as it was
 

I have formatted it from Windows with Fat format and then, from Windows I can create subdirectories and files that are then visible from WinApe

In WinApe, can read from the DoM and browse the subdirectories, read and execute programs, but I can not create files or directories.


   
 Again I  executed format.bas with the same result

What am I doing wrong?

[gerald]

The FAT32 strange limitation is to not be able to support partitions under 32MB.

It's not a strange limitation, it's a logical one.
There is no need to have 32bit fat entry when 16bit are enough. So you use FAT16.

[TotO]

There is no need to have 32bit fat entry when 16bit are enough. So you use FAT16.

You have no need... This "fake" limitation avoid to use really common 32MB MMC/SD cards on devices not compatible with FAT16 (HxC in example).
Next, because FAT32 allows to support long filenames and a faster acces to the files.

[gerald]

You have no need... This "fake" limitation avoid to use really common 32MB MMC/SD cards on devices not compatible with FAT16 (HxC in example).

That's laziness  . There is not much to do to support FAT12/FAT16.
 It's just a matter of dealing with a fixed place root directory for FAT12/16 and cluster number to sector conversion.

Next, because FAT32 allows to support long filenames and a faster acces to the files.

Long filename is a extension of directory entry and has no implication on FAT itself.
You can use long filename on a floppy (FAT12) if you want.
 DOS 3.1 will only show you short names, but windows will show you the full name.

[TotO]

Sure, I know that... But that not fix my HxC issue when I have offered a 32MB MMC bonus for R-TYPE 128K box versions, to use it like a floppy.
I only got an answer to explain that is not possible to support the FAT32 for a next update of the HxCFloppyEmulator! 

[SOS]

Hi. I have connected a DOM to the PC with an adapter and I have presented it to WinApe:
…
The Format.bas utility does not do anything either. Leave it as it was
…
I have formatted it from Windows with Fat format and then, from Windows I can create subdirectories and files that are then visible from WinApe
…
In WinApe, can read from the DoM and browse the subdirectories, read and execute programs, but I can not create files or directories.
...

Hi, strange things you reported 
It seems that the Partition is write-protected.

Ok, i do some Tests too:
- Plug in a 4GB Fat16 USB-Stick, it's writeprotected too (so i can reproduce your issue)
- Make an Image from the Stick and mount them in WinApe -> It's writeable!!!!!
- Format in Winape the 4GB-USB-Stick with ACMEDOS and Change the ROM to CubeMDOS.
  It's writeable from Winape.

I cant do in Z80 a difference: WinApe IDE-Image or Logical Drive-Letter -> It looks the same.
The only logical conclusion must be, that WinApe has a problem / bug and not CubeMDOS (?!)

I try to contact Executioner to talk with him, about this problem.
But "last active" was 07 June 18 .... maybe he will not answer....

[GUNHED]

Regarding the IDE part I'm not sure if the SF2 is emulated 100%. At the beginning my IDE code had problems, but I don't know it the missing status bits have been added. Therefore please do tests on real hardware. 

[m_dr_m]

FAT32 is not restricted to 128MB, you can use large media's.
I dont optimize the format.bas anymore, because you can format your media with Windows, Linux, ....

Hum! I like my CPC self-contained (:

The FREE-Display on FAT32 must be correct, else it's a strong indicator, that something is going very wrong!
FREE on FAT16 is.....    So this should be nearly correct....
I have checks against possible overwriting-issues, so this "should" be not occur.
Disc full detection: Should be work too
Do you have problems with this two points?

No problem so far, as I am only using ~10Mb for now! Simply the doc mentioned:

Three presets of formats you can choose
Format 1: Original ACEMDOS, with the Identifier "X-MASS" at #2B of LBA 0, 128MB Volume
Format 2: First Primary Partition FAT16, 400MB partition Table (Type #06, 8192 Bytes/Cluster)
Format 3: First Primary Partition FAT32, 450MB partition Table (Type #0B, 4096 Bytes/Cluster)

But as I understand now, this was a limitation of format.bas and not CUBEOS's.
The recommended solution is to format the 128MB DOM with a 128MB FAT32 partition by another mean (e.g. via SymbOS).
Is that correct?

[m_dr_m]

I'm encountering an issue with YANCC.
All OrgamS sources larger than 32k copied to a sub-directory are corrupted at the end (but the file size seems correct).
I couldn't reproduce that with a binary file, so maybe it's because .O are ASCII.
That being said, thank you for your helpful answers and attentiveness.

[m_dr_m]

Another one for your Sunday (:

Code: [Select]

|cd,"/plad"
|o     <- OK
|cd,"/plad/archive3"   <- existing dir
|o     <- unknown command

My Orgams ROMs are in &a,&15,&1a. Dedicated RAM memory starts at &ABF8.
Amsdos RAM memory start at &A6F0 (yes it is shifted).

[SOS]

Hi m_dr_m,

First thanks about your mails, to make CubeMDOS better 

13/ Starkos hangs with 'GetDir'
It could be a bug with Starkos, but if the ROM is fully AMSDOS compatible why wouldn't it work?

I checked Starkos.
The reason, why the access to the Massstorage is problematic, starkos re-init (why?) the ROM 07,
so the hook of CubeMDOS is re-init to Amdos-Default - no Massstorage-ROM anymore :-(
When i disable these init or mount CubeMDOS at ROM7: Starkos did not function correctly.
The CAT-Buffer from CAS_CATALOG is build correctly, but some routines in Starkos prevent
from function.
So the Starkos-Author must be change his program to get a functional Massstorage-Application.

Simply the doc mentioned:But as I understand now, this was a limitation of format.bas and not CUBEOS's.
The recommended solution is to format the 128MB DOM with a 128MB FAT32 partition by another mean (e.g. via SymbOS).
Is that correct?

The Format.bas should only have a small number of Presets for possible DOM's. So CubeMDOS is not restricted in detection of the Format. So the only rule is "first Partition", e.g. FAT16 with 1GB, FAT32 with 400MB or 40GB are possible.
For the 128MB DOM i will Always recommend the 128MB ACMEDOS FAT16-Format (1st Preset).
Btw. TotO almost convinced me to extend the format.bas with other/additional presets, but i must check, if i have the DOM's in my roof.

I'm encountering an issue with YANCC.
All OrgamS sources larger than 32k copied to a sub-directory are corrupted at the end (but the file size seems correct).
I couldn't reproduce that with a binary file, so maybe it's because .O are ASCII.
That being said, thank you for your helpful answers and attentiveness.

Ok, i will check that later.

Another one for your Sunday (:

Code: [Select]

|cd,"/plad"
|o     <- OK
|cd,"/plad/archive3"   <- existing dir
|o     <- unknown command

My Orgams ROMs are in &a,&15,&1a. Dedicated RAM memory starts at &ABF8.
Amsdos RAM memory start at &A6F0 (yes it is shifted).

Hmmmm, in Winape this works
- I used your ROM-Numbers (Orgams in &a, orgext in &15 and monogams in &1a)
- CubeMDOS in ROM6
- I created the directories and make a cold-reset.
- I used your RSX-Codes, i leave Orgams with CTRL+B

Orgams make a memory restore of the high-memory.
In my test i noticed, that orgams does not restore the complete memory from himem up to the stack-end.
The first &81 bytes are missing, i not checked at the moment, if this is important.
I think the exact ROM-Configuration could be important

[m_dr_m]

First thanks about your mails, to make CubeMDOS better 

You are very welcome!
Another option to make CubeMDOS better is to release the source (:

So the Starkos-Author must be change his program to get a functional Massstorage-Application.

Yep, fair enough, that's what I've thought.
Thanks for looking at it.
Anyway soon no one won't need Starkos anymore as a native CPC tracker!

For the 128MB DOM i will Always recommend the 128MB ACMEDOS FAT16-Format (1st Preset).

Oh, why is that, since FAT32 is better (faster access, less space wasted, more common...)?
According to https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Size_limits, the min size is 32Mb.

Btw. TotO almost convinced me to extend the format.bas with other/additional presets, but i must check, if i have the DOM's in my roof.

Always listen to TotO, he is wise. (:

Ok, i will check that later.

Nice! I've done some more tests. It also fails when copying from D to A or from A to D.
BTW when trying to copy back a corrupted &8400 long ascii file (on D) to A, I got:
Error close Destination-File. Abort Operation

Hmmmm, in Winape this works
- I used your ROM-Numbers (Orgams in &a, orgext in &15 and monogams in &1a)
- CubeMDOS in ROM6
- I created the directories and make a cold-reset.
- I used your RSX-Codes, i leave Orgams with CTRL+B

Actually the scenario with /plad/archive3 also fails at RESET.

Orgams make a memory restore of the high-memory.
In my test i noticed, that orgams does not restore the complete memory from himem up to the stack-end.The first &81 bytes are missing, i not checked at the moment, if this is important.

Maybe related to this bug: mailto:http://orgams.wikidot.com/bugs#toc40
Anyway, as said above, I get the issue from a cold start as well.

I think the exact ROM-Configuration could be important

1: CubeIOS
2: UTOPIA
3: YANCC
4: LAUNCH
5: HACKIT
6: PARADOS
7: AMSDOS
9: Flash burn
10: Orgams
12: TurboAss
15: OVL v2
The others ROMS are extensions (02) or data (03).

[m_dr_m]

10/ Fix |DRIVE
When wrong number of arguments, you should lift the command to overridden DOS rom.
Right now we cannot invoke Parados copier anymore.

Since YANCC doesn't allow A to A copy, this request would have a very good utility/work ratio!

[SOS]

Another option to make CubeMDOS better is to release the source (:Yep, fair enough, that's what I've thought.

The Projects CubeMDOS+YANCC are not started as an open-source project
=> Not planned at the moment, maybe (maybe not) later in this year.

Oh, why is that, since FAT32 is better (faster access, less space wasted, more common...)?

Backward-compatibillity to ACMEDOS+IMPDOS.

Actually the scenario with /plad/archive3 also fails at RESET.
Maybe related to this bug: mailto:http://orgams.wikidot.com/bugs#toc40
Anyway, as said above, I get the issue from a cold start as well.
1: CubeIOS
2: UTOPIA
3: YANCC
4: LAUNCH
5: HACKIT
6: PARADOS
7: AMSDOS
9: Flash burn
10: Orgams
12: TurboAss
15: OVL v2
The others ROMS are extensions (02) or data (03).

The ROM's 9+12 i haven't found.
The other Orgams-ROMs i put it in 11+12.
But i can't reproduce your problem in WinApe 
Could you reproduce that in Winape?

[m_dr_m]

Nice summer to you!


Another bug detected: cannot save an ASCII file larger than 64k. The result is truncated.
Is a new version planned anytime soon? (:

[SOS]

Nice summer to you!
Another bug detected: cannot save an ASCII file larger than 64k. The result is truncated.
Is a new version planned anytime soon? (:

Thanks, for you too ;-)

"Soon" is very relative ;-)
My actual versions (CubeMDOS+YANCC) are stable in Winape, so i "only" Need to test it on real Hardware.
The changelog of the next Version is:
- Bugfix of FlashFloppy-Support (Amstrad+)
- CAT/DIR: Possible false display in the path name  (thnx netmercer)
- Display VolumeName during boot - Changed/Fixed - again :-(
- No MSD-Hardware found, correct exit
- Make-Directory: Convert Directory-Names to Uppercase (else Directory can't read by Windows)
- FAT16: Can't create more than 64 DirEntries  - checked 20000 save's   (thnx m_dr_m)
- FAT32: Saves to LBA 65535 crashes
- Internal Restructure->Some more games should be run.
- V1 (default) & V2 mode introduce ->Some more games should be run.
- |disc , then cat crashes
- CAS_IN_CHAR: Reads sometimes a little bit too much bytes & improved 1A-Handling (Orgams)
- Sometimes deleted directories will be displayed (thnx netmercer)

Open are you two issues:
- Globs doesn't work as in AMSDOS (dir+era)     (thnx m_dr_m)
  E.g. |DIR,"*.BAK"
  E.g. |ERA,"*.BAK"
- Cannot save an ASCII file larger than 64k. The result is truncated.        (thnx m_dr_m)
  => But i must check, if this is solveable....

[m_dr_m]

- Make-Directory: Convert Directory-Names to Uppercase (else Directory can't read by Windows)

Oh that's a pity! I enjoy the lowercase names (more legible).
[/size]
[/size]

- Cannot save an ASCII file larger than 64k. The result is truncated.        (thnx m_dr_m)
  => But i must check, if this is solveable....

Why not? It works like a charm in Amsdos.


I would be happy to beta-test!

[SOS]

I would be happy to beta-test!

https://sourceforge.net/projects/symbiface3/files/Alpha%20%28Next%20Version%29/
(Version runs without an Problem in Winape)
You need an YANCC-Update and configure CubeMDOS with the Config.bas in the DSK-File

But Problems, Questions & …. please only per PM

[TotO]

I would like to know if any updates was made for your tools to update the X-MASS installer?