X-MASS, a mass-storage expansion for all CPC.

[netmercer]

Is there a known incompatibility between AcmeDOS/FAT and SymbOS? I was able to format my DOM (|FORMAT) and create directories, copy files to it, but after I've copied SymbOS to D:\SYMBOS I ran it once, since then I can't copy files using |CPH to the drive. It says just "file length zero"... 

Hi,
perhabs you are trying to copy a file without AMSDOS Header.
Why don't you use your SYMBOS for filecopy?? 

Kind regards
netmercer

[Poliander]

perhabs you are trying to copy a file without AMSDOS Header.

You're totally right - I wasn't aware of that. 

Copying using SymCommander works fine. Is it possible to boot SymbOS completely from DOM? It seems that SymbOS doesn't find its configuration when started from D:\SYMBOS

[HAL6128]

Yes, it's possible. There's a release from @Prodatron on a disc (not the ROM version) which has the files: sym.bas, sym0.bin, sym4.bin, sym5.bin etc... . Just copy the files in the root directory. But before you can start it you should have to configure the symbos.ini file from disc (add IDE mass storage and change system path to d:/), save it to disc and copy it (with the symcommander) to your x-mass. Now it should work if you start "sym.bas" from x-mass. It starts - by the way - as fast as the ROM version.

[Poliander]

Thank you very much. It's absolutely amazing how well the X-MASS/ACMEDOS setup already works. I'm currently digging through my games collection to see which games can be copied to HDD.

The FLASHER utility from the X-MEM install disk could probably need a little update. It's already possible to select drive |D in the built-in shell, but changing the directory is not yet possible, e.g. "cd roms"

[TotO]

Thank you to SyX for his great reactivity:
- V0.7.1B: Add support to |CPH for copying Ascii files.
- V0.7.0B: Implementation of CAS_IN_CHAR, CAS_RETURN and CAS_TEST_EOF.

Download as usual from the X-MASS GitHub repository.

[SyX]

@madram: I can promise you that is not because laziness. It's more simple, i wanted a more bug free rom before adding the read/write byte functionality, instead of making more spaghetti code as i am doing now

And even now, that i am adding the last function, CAS_OUT_CHAR; i sincerely don't know if this is going to be good enough for your project. I took a lot of decisions (a few good ones and surely a lot of bad ones ),  in the best way that i could and knowing that i could not please to everybody. A few examples:

Because i am using directly the 512 bytes sector buffer, that means that i am ignoring completely the 2KBs buffer passed as parameter in CAS_IN_OPEN, CAS_OUT_OPEN and CAS_CATALOG.

Or i am using the 16 bits filesizes, instead of the 24 bits ones (although the places where 24 bits should be used are well commented). And not because 24 bits math is slower, the reason is for saving bytes and in this moment we are getting the ram variables are getting around $BEF0, and i will fight for not reaching $BF00... and i made a few recursive programs (fractal graphics and similars) that eat stack until corrupts these variables.

But i am sure that we will make your program works before my time window closes again until the end of the year.

PS: It's nice to see at last Tasword3 working from HD... at least for loading

PS2: AcmeDOS 0.7.x is wip (in this moment i am adding the write byte routine) and has not been tested at all (only tasword3 and a few basic programs), because that surely it will bring new amazing bugs and it's not recommended to replace the "stable" 0.6.x yet.

[madram]

I know SyX had done his best to cover most of the usages first into the beta version.

Yes, this is clearly a great work to be as transparent as possible.

He probably have not expected that was early required to use CAS_IN_CHAR with 512K RAM and 128MB SSD.

On the contrary! Lots of RAM and mass storage means we can play with bigger files, that we have to handle somehow: CAS_IN_DIRECT doesn't cut anymore.   

Because i am using directly the 512 bytes sector buffer, that means that i am ignoring completely the 2KBs buffer passed as parameter in CAS_IN_OPEN, CAS_OUT_OPEN and CAS_CATALOG.

For CAS_IN_DIRECT, it was a great decision, since AMSDOS doesn't use it either and most coders didn't bother to set the buffer at an adequate location.
But for CAS_IN_CHAR, I'm relying on it, to maintain full speed. My 'DISC_READ_CHUNK' routine takes both destination and size as parameters, and the behavior is:
   * call CAS_IN_CHAR to trigger filling of buffer (1st time)
   * take arbitrary chunck: if wanted size exceed buffer, copy first part, set AMSDOS variables to retrigger buffer fill, and looping until we've got expected size.
   * adjust AMSDOS variables (so we are pointing the current position in buffer).

Why wouldn't you reuse AMSDOS mechanism ? You can reuse AMSDOS variables as well, so no overhead in &BF00 neighbour.

On the other hand, I can also adapt my routine to fit your way of doing thing. It would require:
   * to known for sure whether the file is opened via ACME-DOS (e.g. active drive in A701)
   * a robust way to get the address of your buffer pointer (hardcoding the address isn't change-proof).
          -> maybe it could be queried via a routine at fixed address *in ROM* (e.g. D000).
   
I like this solution less, not because it's work on my side, but because it's uglier architecture-wise: the whole point of vectors is to separate responsibilities, so the client doesn't have to know if the file is on tape, on disc, on X-MASS, on the net, ...
(Ok here I'm cheating because I'm digging in AMSDOS's internals, but we can see them as standardized internals!)

Anyway, thank you very much for the fantastic job!

[SyX]

Why wouldn't you reuse AMSDOS mechanism ? You can reuse AMSDOS variables as well, so no overhead in &BF00 neighbour.

I am using and abusing of Amsdos variables already, but only when they make sense, hehehe.

[xesrjb]

Is it usefull to make an image from the DOM to recover it from a PC if you need? The attached file is running under XP SP2 (I just used it in a Windows 7 System)

On the other hand is there a possibility to exchange this images (128MB)?


xesrjb

[protek]

Hi, returning to this topic after a long break.

I finally bit the bullet and cleaned my 6128's expansion port contacts with IPA to address the issues of the 6128 not always booting to the X-Mem and being too touchy to the computer moving. The cleaning seemed to do the trick.

I went and reformatted the DoM with Ast's IMP Format. After that I was able to initialize the X-Mass under SymbOS usint Prodatron's LBA patched Mass storage tool. Had to set X-Mass as unpartitioned to get it working.

SymCommander now sees the created C drive and I can create folders into it. I don't seem to be able to copy files from floppy to the X-Mass, as the copy tool and SymbOS freezes, requiring me to do a reboot.

Anyone experienced similar issues?

[TotO]

V0.7.3B fix some bugs in CAS_IN_CHAR and now work with Notepad+4.

[HAL6128]

Hi TotO,
I'm not able to flash the current Rom with the flasher program. It prints out an "ERROR" message?!
HAL6128
...forget that bullshit. I forgot to set the X-Mem switch to "free"...

[TotO]

Usually, it is not required to set the X-MEM to LOCK... Except if you want to be sure that nothing will write on it.

[merlinkv]

Hi.

I've just installed ACMEDOS 0.7.4B with success. So, I can format, create dirs and copy files with |CPH also I can run some games OK.

But I have one question ... I can use wilcards with |CPH? like |CPH,"ABADIA?.*" or |CPH,"ABADIA*.*" or ..... ?

I have some tools for file operations, but they can't work with the DoM, just A and/or B ...

And ... another question ... I can setup XMEM with RAM Drive |C with the 0.7.4B rom?

Thanks 

[merlinkv]

Similar? I dont know.
[attach=2]

Hi ... It's possible to download this tool? It looks great!

[SOS]

Hi ... It's possible to download this tool? It looks great!

Not at this moment, i wait for the CAS_OUT_DIRECT version of Acmedos, i think (hope) it should be released in the next month.
I need the function for copy ASCII- and Big Files (>41KB).
I have prepare my commander to use that function, which works under AMSDOS/PARADOS - but i wait for Acmedos.
When it's released i will do my final test and talk with two beta testers....

[merlinkv]

OK.

I can't wait .....  (it's a joke)

Copy files with |CPH is a tedious task ... 

[merlinkv]

Hi again.

I have four new DoM's 2x2GB and 2x4GB, 44 pins, Industrial Quality. But the XMASS don't recognize these DoM's (installed with pins inverted & set to Master) just boot with black screen ..... it's an ACMEDOS issue or is the XMASS firmware?

Thanks 

[TotO]

What are your DOMs models?

[merlinkv]

Labelled as: KingSpec OIndustrial ...

The same as is showed here: Kingspec 44PIN IDE PATA MLC 2GB 4GB 8GB 16GB 32GB DOM SSD Disk On Module For

I've tested the XMASS with CF adapter and one 2GB CF card .... The CPC boots and I can format but it shows one 128MB partition/123MB free (the PC shows the correct size ... FAT partition 1,87GB free) ...

Edited: ROM used is ACMEDOS 0.7.5B

[TotO]

I confirm those low cost DOM don't work with the X-MASS board (no 8bit mode).
And yes, ACMEDOS actually only support the native X-MASS capacity.

[merlinkv]

I confirm those low cost DOM don't work with the X-MASS board (no 8bit mode).
And yes, ACMEDOS actually only support the native X-MASS capacity.

OK. Thanks.

It's planned that the ACMEDOS can support more bigger partitions in the near future?

[TotO]

When all will be perfect for the X-MASS itself... As 128MB is already big for this computer.

[HAL6128]

Yes, 128MB is huge! I'm working with it a couple of month, and there's still 114 MB of free space, despite lots of games and different files copying onto X-Mass from time to time.
(...but I won't give up )

[TotO]

100MB hard drive was a standard capacity on most PC 486 in 1995.