Before starting the coding, I need to know what are your expectations ?
Ideas are welcome, of course.
Humm... I am going to say something stupid. It turns out that the device seems to perform much, much faster than the floppy drive. It would be awesome to be able to use it in CP/M Plus like a super-big hard drive. Thinks like our adventure would benefit immensely from it. Not to mention how great would be able to use this in combination with X-MEM in CP/M supporting automatic bank switching. We could create awesome games with this using the standard tools we have available, at least adventure games :laugh:
I think every X-Mass owner would like to have first a ROM which contains:
- X-Mass driver
- X-Mass formater (alreayd exist, isn't it ? :D )
- X Mass RSXs to access file under AMSDOS (read, write, folders etc...)
In ccl, everybody expect a clone of the ACME Rom ???
Quote from: Kris on 15:40, 04 March 16
I think every X-Mass owner would like to have first a ROM which contains:
- X-Mass driver
- X-Mass formater (alreayd exist, isn't it ? :D )
- X Mass RSXs to access file under AMSDOS (read, write, folders etc...)
In ccl, everybody expect a clone of the ACME Rom ???
Totally agree :) I want to use my X-MASS DoM 128M (or greater, maybe 1GB/2GB? ) to create one or more partitions, directories, ... and read,copy,write from & to floppy drives. Also I want to work with apps & play games from the DoM.Similar tasks that I can do it with my ZX's ... +2A/+2B & +3
Quote from: ||C|-|E|| on 15:33, 04 March 16
Not to mention how great would be able to use this in combination with X-MEM in CP/M supporting automatic bank switching.
It would be nice to have a C library that can do allocation and object retrieval while automatically performing bank switching for you. However, you'd need to have some way of doing it optimally. The compiler could probably help, but it's not a completely static problem. I also don't know if you'd be able to detect all cases of dangling pointers statically (where you have a pointer hanging around that is for the wrong bank), so it would still require careful coding. I can't help thinking that there must be some kind of abstraction that can make life easier anyway, though TBH I think you would probably never be able to write code as efficient as that using manual bank switching (hey, it's nice to dream)!
Edit: Aha, it has been done before :) http://sydney.edu.au/engineering/it/~scholz/publications/cases06.pdf (http://sydney.edu.au/engineering/it/~scholz/publications/cases06.pdf)
Edit2: Hmm, apparently gcc can do it (but not automatically) for code using the "far" directive (for the 68HC11 and 68HC12 backends). I don't know if this work looks at data as well, which would seem to be a much harder problem.
Edit3: Actually they are only looking at minimising the bank switching instructions, not at automatically assigning code/data to banks. So not so useful :(
Edit4: This is the ticket: EMBARC (http://dl.acm.org/citation.cfm?id=997190)
The thing is that if automatic bank switching could be implemented in the operating system, even if it is slow, tools like PAWS would recognize the extra memory automatically and this would be completely transparent for the user of the framework. Speed is something not critical if we talk about a text adventures... of course, the other option is to develop a new and better framework that already uses these features and runs in a more suitable operating system, but this seems a harder task :'(
In any case, having X-MASS support in CP/M Plus would be a blast, because I am loading the pictures in real time from the floppy drive, and this is not fast by any means :-X If I could install the game on it it would be awesome.
Quote from: ||C|-|E|| on 19:53, 04 March 16
The thing is that if automatic bank switching could be implemented in the operating system, even if it is slow, tools like PAWS would recognize the extra memory automatically and this would be completely transparent for the user of the framework. Speed is something not critical if we talk about a text adventures... of course, the other option is to develop a new and better framework that already uses these features and runs in a more suitable operating system, but this seems a harder task :'(
I don't think having an automatic system that is not too bad is that hard, but doing it in a principled, optimal way is. Without doing that you will probably get odd corner cases. For some things it would be fine, for sure.
Quote from: ||C|-|E|| on 19:53, 04 March 16
In any case, having X-MASS support in CP/M Plus would be a blast, because I am loading the pictures in real time from the floppy drive, and this is not fast by any means :-X If I could install the game on it it would be awesome.
True. I got bit off topic.
Quote from: ||C|-|E|| on 19:53, 04 March 16
In any case, having X-MASS support in CP/M Plus would be a blast, because I am loading the pictures in real time from the floppy drive, and this is not fast by any means :-X If I could install the game on it it would be awesome.
Hi,
I modified my CP/M+ in order to access X-MASS.
Certainly it's not perfect, but it works for me. Currently I have four additional drives available (E:1MB, F:512K, G:,H:8MB). The drives are different, because I'm playing around with allocation tables, hashing, data and dir buffers and so on.
(to keep things simple I used CHS, no partitions table and other simplifications)
In addition I'm using a RAM expansion, which is not dktronics compatible.
Perhaps look at this:
Re: X-MASS, a mass-storage expansion for all CPC. (http://www.cpcwiki.eu/forum/news-events/x-mass-a-mass-storage-expansion-for-all-cpc/msg118626/#msg118626)
Kind regards
netmercer
Quote from: Ast on 15:18, 04 March 16
Before starting the coding, I need to know what are your expectations ?
Ideas are welcome, of course.
I started working on a file manager. It should have the look an feel from Norton/Midnight-Commander. But I was only able to do that in BASIC (apart sector reading, writing commands, or floppy routines which are in MC or just firmware). Because of the limitation of RAM I run out of memory. The BASIC file is at the moment 25k big. At &8E00 starts the MC / RSX routines. I'm not able to write good MC code for such kind of app.
How about that?
Quote from: ||C|-|E|| on 15:33, 04 March 16
Humm... I am going to say something stupid. It turns out that the device seems to perform much, much faster than the floppy drive. It would be awesome to be able to use it in CP/M Plus like a super-big hard drive. Thinks like our adventure would benefit immensely from it. Not to mention how great would be able to use this in combination with X-MEM in CP/M supporting automatic bank switching. We could create awesome games with this using the standard tools we have available, at least adventure games :laugh:
I've been using the X-MEM with Infocom games and copying everything on the RAM drive with PIP C:=A:*.*
It works like a charm in emulation. Haven't been able to try it on real hardware yet.
Though to be frank, the access time didn't seem to be much reduced, I felt I gained like 10% on a 2s text loading. It mainly removed the disc sounds.
It may prevent from saving your game though.
Tested with WinAPE 2.0b2, 4M RAM and the CP/M ROMs.
Quote from: ||C|-|E|| on 19:53, 04 March 16Speed is something not critical if we talk about a text adventures...
Not critical but a damn inconvenience. Action games load their whole level in RAM and then the gameplay is uninterrupted until the player is done with it. With adventure games, each command requires a disc access to check whether the command is valid and load the correct reply or load the next scene. The gameplay is littered with short loadings as the players types furiously everything that goes in their mind to try and advance in the game. Text adventure games would probably be one of the genre with the most benefits of RAM pre loading.
Thank you all!
So, the main problem I have is that I cannot actually use X-MEM with our adventure, it is just too big :picard: (that is why I did not try it). However, on the bright side, all the database of the game fits in the RAM, so you only have loading times when moving from location to location (around 3 seconds). It is not ideal, but much much better than accessing the disc all the times to check for simple commands. Everything you type that does not involve moving the player has an immediate response. In that sense, fitting everything in the X-MASS would be great, I remember that it was able to load a whole game like Barbarian in about a second, and the graphics we are using are "just" 8KB each :) .
https://www.youtube.com/watch?v=_yG0oFP1V5U (https://www.youtube.com/watch?v=_yG0oFP1V5U)
Of course, maybe it would be not possible to have everything working as fast as that from CP/M, I do not know, but this would be a dream come true :)
How do you not have enough space in the X-MEM? How many discs are you using haha? I would suggest to keep the data compressed even in RAM. There will be an additional delay to decompress stuff, but at least you would remove the disc accesses.
As for the X-Mass, one of its uses according to TotO is to have folders behaving like independent virtual discs. Copying the entirety of a disc in a folder and loading the executable supposedly works. If your game isn't copy protected, the easiest way to improve the loading times would be to suggest this specific use ("installation") in the manual.
Well, the game requires two discs and the second one needs to be 720KB :laugh: (the second floppy contains the adventure and the graphics for the locations). In the first disc goes the loading screen, the font selector and the CP/M. I would love to compress the data in RAM, but I am using PAWS, the classical old framework that works in CP/M Plus and, if this is possible, I ignore how to do it :) . My game is not copy protected by any means, but it runs natively on CP/M Plus, and it is required to load the operating system before the adventure itself, that is why I would need specific support for the device, something like netmercer implemented but, if possible, no comprimising the TPA a lot (the adventure already uses 59KB and the final version will be probably 60KB, we have squeezed everything as much as possible).
Quote from: HAL 6128 on 23:33, 04 March 16
I started working on a file manager. It should have the look an feel from Norton/Midnight-Commander. But I was only able to do that in BASIC (apart sector reading, writing commands, or floppy routines which are in MC or just firmware). Because of the limitation of RAM I run out of memory. The BASIC file is at the moment 25k big. At &8E00 starts the MC / RSX routines. I'm not able to write good MC code for such kind of app.
How about that?
All ideas are good to take...
The Rom will be coded in asm z80, no c library (sorry but we are on cpc and i'd like to use my x-mass on my cpc!)
No cpm version, only z80 code assembled for a new Rom.
...m
For the moment, i worked on differents things :
Identify in one X-Mass is connected (works)
ùcat : display directory (works)
ùcd,"MYFOLDER" (works)
....
The Rom takes places...
Hi,
meanwhile I have found another solution for placing some part of the X-Mass driver and I don't need a RSX any longer for X-Mass and CP/M+. Now full TPA of 61KB is available and booting from X-Mass is also possible.
(profile.sub on X-Mass is marvelous)
Kind regards
netmercer
Quote from: HAL 6128 on 23:33, 04 March 16
I started working on a file manager.
I too. (nearly finished), i will it call "YANCC" (yet another norton-commander clone).
The driver for the mass-memory part i can only start to write, when a solution (final/beta/maybe alpha) exist (IDE or CH376-based).
(07.03.):
Ok,due to the likes, some more infos:
- Feature-freezed
- Unstructured tests with no open error, so structured tests are coming for me
- While the main-focus is on mass storage, so i only support 2 Disk-Drives & 64 KB
- ROM-Version (not compiled for &C000)
- copy-function used sector-read/write, so it's fast
- tested some 'big'-formats like Vortex & Parados80
Screenshot:
Hi,
A Dsk/HFE mounting/uncrushing feature would be great.
I've just tried your format tool, works like a charm :)
Tx for all your hard work.
Here is a little movie to see how it runs :
@Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573)
Would it be Possible to Just send a Picture of your Startup screen Please.
Thanks Ray
For CH376 a rudimentary Z80 driver can be found here, i think it only needs minor changes to work on the CPC (Port Adresses, OS-Call for Textoutput).
[AQUARIUS] Micro-Expander: RAM, ROM, AY-8910 and more! - Intellivision (http://atariage.com/forums/topic/243063-aquarius-micro-expander-ram-rom-ay-8910-and-more/#entry3351655)
@Audronic (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1169) :
As you could see I'm working directly on the X-Mass Rom and Copy it directly in my X-mem for tests.
A Strange bug appeared because my X-Mass is "Not Detected" and it works correctly. I probably forgot a variable.
@Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573)
Thanks
Ray
X-Mass Detection bug is now ready... Pfewww !
Here you can see with a sample of code... (OrgAms Coding of course!)
For those who are interrested, one other link (http://amstradplus.forumforever.com/t214-Initiation-la-X-Mass.htm), but written in french... Google Translate will be your friend !
A most beautifull video showing you it's working now !
How can I execute a Basic program in an Asm Code ? Which call ? which rom ? etc...
Quote from: Ast on 18:09, 08 March 16
How can I execute a Basic program in an Asm Code ? Which call ? which rom ? etc...
Unofficial Amstrad WWW Resource (http://www.cpctech.org.uk/source.html)
At the very top of the Page "Running BASIC programs from assembly"...
Quote from: Ast on 14:58, 08 March 16
A most beautifull video showing you it's working now !
Hi AstGood work.
Please list the roms that you use and their positions.
Thanks
Keep up the GOOD work
Ray
The most simple was to take a photo from "the editor" of X-Mem's Roms.
The iMPdos is working fine... I'm going on doing my best to make you a good X-Mass manager!
Great choice :)
This video shows you some news commands as :
ùcd,".
&
ùrun,"myfile
Just one minor detail.
The command CD . should stay in the current directory, while CD.. should jump to the parent directory.
Other than that, it's looking nice!
You're right robcfg but it's always wip.... Don't burn the step ! ^^
Does anyone else have this king of error ?
Quote from: Ast on 14:07, 09 March 16
The most simple was to take a photo from "the editor" of X-Mem's Roms.
The iMPdos is working fine... I'm going on doing my best to make you a good X-Mass manager!
Thanks for Rom.Jpg.
Ray
@Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573) is the accented u character (ù) available easily on UK machines? Because it isn't a standard one, maybe you could use something more accessible for those of us without French keyboards?
Is this a ROM?
Anyway, looking awesome :)
Quote from: Munchausen on 00:04, 10 March 16
@Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573) is the accented u character (ù) available easily on UK machines? Because it isn't a standard one, maybe you could use something more accessible for those of us without French keyboards?
Is this a ROM?
Anyway, looking awesome :)
Nothing needs to be changed, it's just the way the AZERTY ROM is mapped.
So on your English ROM you will simply use the traditional '|" in front.
? chr$(124) on an AZERTY will display
ù
? chr$(124) on an English QWERTY will display
|
How to type the bar symbol on a French 6128+ (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/how-to-type-the-bar-symbol-on-a-french-6128/)
Cheers,
Shane
Quote from: 00WReX on 01:21, 10 March 16
Nothing needs to be changed, it's just the way the AZERTY ROM is mapped.
So on your English ROM you will simply use the traditional '|" in front.
? chr$(124) on an AZERTY will display
ù
? chr$(124) on an English QWERTY will display
|
How to type the bar symbol on a French 6128+ (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/how-to-type-the-bar-symbol-on-a-french-6128/)
Cheers,
Shane
Aha ok :)
This is awesome
The fact is the pipe symbol is exactly at the same place on all CPC keyboard and work for all CPC. :-\
But, lazy french users use the ù key instead (w/o SHIFT), because the linked caracter is the same on the ASCII table for them.
Quote from: TotO on 14:09, 10 March 16But, lazy french users use the ù key instead (w/o SHIFT), because the linked caracter is the same on the ASCII table for them.
And it's soo convenient, I love it. Especially so as we'll be using it routinely when using the X-Mass, going through folders, managing files.
Also it makes for a fun way to pronounce CPC commands: ücépéhèm! how do you even say |CPM anyway? pipeCPM?
Quote from: khaz on 15:18, 10 March 16And it's soo convenient, I love it. Especially so as we'll be using it routinely when using the X-Mass, going through folders, managing files.
On both keyboards, I have always used the pipe key because it is at the same place. Buy the way, I prefert to use the QWERTY keyboard.
Quote from: khaz on 15:18, 10 March 16Also it makes for a fun way to pronounce CPC commands: ücépéhèm! how do you even say |CPM anyway? pipeCPM?
barcépéhèm! :-\
Quote from: khaz on 15:18, 10 March 16
how do you even say |CPM anyway? pipeCPM?
Bar Sea Pea Emm. Sounds like a dodgy pub.
CraigsBarSeaPeaEmm? ???
@Prodatron (http://www.cpcwiki.eu/forum/index.php?action=profile;u=13) : do you write some byte(s) anywhere in the ide support to know what will be the next cluster to write ?
I explain :
First your ide is formatted.
So all sectors are cleaned.
You save a file. Do you save anywhere the cluster number ?
It's important to know because if you do that with each file you could follow easily where you are. It will be much easy to find where to write for the next folder or file.
I was just having a think about X-Mass as it is nearly Easter.
X-Mass Preparation
What Programs/RSX's do the Headings Below use :-
1) Format the DOM (FAT 16). (IMPFOR - Others) ??
2) Create some directories. ??
3) Copy Files to Root or Directories of DOM. ??
4) Copy Files from DOM to Floppy. ??
5) Erase Files on DOM. ??
6) Files 8.3 (TESTING1.TXT) or Other.
-===================================-
What ROMs do we require.
Do we work within a Shell (FuturOS, etc) or accessible from Basic.
Will the file system be Compatible with "" ACMEDOS "" (GodotDOS) ;) :( .
Or do you Make some Other
Above are just some thoughts.
Ray
Quote from: Ast on 23:26, 10 March 16
@Prodatron (http://www.cpcwiki.eu/forum/index.php?action=profile;u=13) : do you write some byte(s) anywhere in the ide support to know what will be the next cluster to write ?
I explain :
First your ide is formatted.
So all sectors are cleaned.
You save a file. Do you save anywhere the cluster number ?
It's important to know because if you do that with each file you could follow easily where you are. It will be much easy to find where to write for the next folder or file.
Reposted if Prodatron missed this one... No answers ?
Hi @Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573),
sorry, I wasn't around for about 1 week. I am very impressed by your progress, it's really so cool!!
The first free cluster number is saved inside the FSINFO sector when using the FAT32 format. FAT12 and FAT16 don't support this, it's a FAT32 feature only. SymbOS supports this feature, so the FSINFO sector is always up-to-date.
Is this what you need to know??
Keep on the great work!
CU,
Prodatron
So how do you do to make/emulate this feature on SymBOs with fat 16 ?
I only want to know to make iMPdos compatible with SymBos. Without that it Will be difficult to make our project compatibles.
My idea and what i do in iMPdos was i created-emulated this function in sector #ff.
the first two bytes countain the Current/last cluster and the four last bytes, the size of the last file/directory written.
What do you think about it ? Do you think you could use the same ´trick' in SymbOS to be compatible with iMPdos ?
Really cool video!
Quote from: Ast on 07:06, 15 March 16So how do you do to make/emulate this feature on SymBOs with fat 16 ?
With FAT12/FAT16 you always start searching for a free cluster at the beginning of the FAT table. Problem with such special sectors (like #ff in your case) is, that it wouldn't meet the FAT standard anymore.
Let's say iMPdos is later used with a normal SYMBiFACE II as well. Here you may have completely different data storages connected (like small CF cards, harddiscs with different sizes etc.). You may want to read/write them at a PC as well. Having a static special sector like #FF for storing non-FAT-standard information could cause problems with the filesystem integrity then, and you don't know if sector #FF is already used for storing the FAT/files/directories on other storages, so maybe you even destroy something.
If you want to speed-up the cluster search, I would recommend to store the number of the first free cluster in ram. So when doing a search for the first time after you switched on the computer you have to walk through the whole FAT once, but after this you can use the cluster number stored in memory.
I'm looking for someone who could test iMPdos v1.0 wip. Who is interrested ? PM please !
I can ;)
Quote from: Prodatron on 17:26, 15 March 16
Really cool video!
With FAT12/FAT16 you always start searching for a free cluster at the beginning of the FAT table. Problem with such special sectors (like #ff in your case) is, that it wouldn't meet the FAT standard anymore.
Let's say iMPdos is later used with a normal SYMBiFACE II as well. Here you may have completely different data storages connected (like small CF cards, harddiscs with different sizes etc.). You may want to read/write them at a PC as well. Having a static special sector like #FF for storing non-FAT-standard information could cause problems with the filesystem integrity then, and you don't know if sector #FF is already used for storing the FAT/files/directories on other storages, so maybe you even destroy something.
If you want to speed-up the cluster search, I would recommend to store the number of the first free cluster in ram. So when doing a search for the first time after you switched on the computer you have to walk through the whole FAT once, but after this you can use the cluster number stored in memory.
Couldn't the number be stored as a file or kinda "reused" 4 byte
Volume Serial Number?FAT Partition Boot Sector (http://www.ntfs.com/fat-partition-sector.htm)
Good idea !
Quote from: Prodatron on 17:26, 15 March 16
Let's say iMPdos is later used with a normal SYMBiFACE II as well.
We want IMPdos compatible with our symbiface II !! :D
Quote from: Joseman on 19:51, 15 March 16
We want IMPdos compatible with our symbiface II !! :D
Yes, it would be great to be able to use SF2 and FAT file system in the native OS (12 years after the release of the hardware) eventually. :) :) :)
Quote from: TFM on 20:20, 15 March 16
Yes, it would be great to be able to use SF2 and FAT file system in the native OS (12 years after the release of the hardware) eventually. :) :) :)
Joseman, TFM, and others, my priority is the X-Mass but if I could, i will do it !
Quote from: Ast on 20:54, 15 March 16
Joseman, TFM, and others, my priority is the X-Mass but if I could, i will do it !
As i understood, the xmass is hardware compatible with the SF2.
Is a pity that a good DOS as IMPdos is starting to be will not work on the great SF2 (that dozens of people have!)
i don' t know if iMPdos run or not with symbiface yet but i think the answer is yes !
Quote from: Singaja on 19:35, 15 March 16
Couldn't the number be stored as a file or kinda "reused" 4 byte Volume Serial Number?
FAT Partition Boot Sector (http://www.ntfs.com/fat-partition-sector.htm)
The problem is, that other filesystem implementations won't update it. So if iMPdos is using this, it won't be actual if another system wrote something on the storage. So you have to make a check for the first free cluster once anyway....
So why not in the last sector ?
The question is:
How can iMPdos be sure, if the information is up to date?
Other FAT-systems won't update such a non-standard sector. So iMPdos will probably have to search for the first free cluster anyway.
Finding the first free cluster is not a problem, iMPdos already does it!
The remaining 2 bytes could be squeezed out of constant signature 55 aa , last 2 bytes in the boot sector for fat12 & fat16. That would probably render it unusable under Dos/Windows so a tool would be needed to restore it.
EDIT: Fat12 has no serial number though, but I reckon it's not the format of prime focus.
EDIT2: Alternatively 2 or 6 bytes could be sacrificed from 8 byte OEM name/version. It shouldn't break compatibility like the signature thingie.
I use this for reference:
The FAT filesystem: FAT (https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html)
Quote from: Ast on 22:36, 15 March 16
Finding the first free cluster is not a problem, iMPdos already does it!
Yes sure, so I think it's better to keep the FAT standard. For improving the performance for FAT16 it makes more sense to use RAM variables.
Another video to show you how iMPdos runs a program copied on a directory.
Sorry for the bad quality!
Have fun!
It is absolutely great! :D
Some informations about the last iMPdos version here (http://amstradplus.forumforever.com/t214-Initiation-la-X-Mass.htm?start=120#p2601) but in French. Thanks to Dirtybb for his feed-back.
I did a test with edited Fat16 partition on Windows 8.1
With oem name/version: CPC6128 and 0x0 padding in green
and volume serial set to OWNZ (actually the number as a serial is read as big endian).
Windows didn't complain and the partition is fully useable 8)
(http://s22.postimg.org/8w6yd0nj5/fat16.png)
So is impdos a replacement for acmedos? Is acmedos shelved? Or are we in the crazy situation of having 2 close to completion amsdos fat32 drivers? Am I the only one confused?
All i Know is i'm working Hard to offer you a solution to use your x-Mass. ACMEdos or iMPdos, that will be your choice ;-)
@Singaja (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1284) : Thanks for informations !
Quote from: Singaja on 20:47, 16 March 16
I did a test with edited Fat16 partition on Windows 8.1
With oem name/version: CPC6128 and 0x0 padding in green
and volume serial set to OWNZ (actually the number as a serial is read as big endian).
Windows didn't complain and the partition is fully useable 8)
(http://s22.postimg.org/8w6yd0nj5/fat16.png)
Soon you could do that directly with iMPdos...
Quote from: CraigsBar on 20:51, 16 March 16
So is impdos a replacement for acmedos? Is acmedos shelved? Or are we in the crazy situation of having 2 close to completion amsdos fat32 drivers? Am I the only one confused?
I think it's FAT16, saying it's a replacement for Acmedos is a bit harsh. People have their preferences and some will need FAT32 for more space.
Ahhh, so one is fat16 and the other fat32. I think I'll vote acmedos.
ACMEdos is FAT16 too :)
Definately vote acmedos. But will try them both and make a choice.
Quote from: CraigsBar on 21:34, 16 March 16
Definately vote acmedos. But will try them both and make a choice.
Why you vote acmedos?
have you tried acmedos or impdos?
and why vote anything anyway?
is a pleasure and a big luck that 2 solutions will appear on the cpc, and even use the 2!
Fat 32! My symbos installs are both on fat32 partitions and I don't fancy reinstalling if it's not necessary. *that* is a feature i'd vote for.
Quote from: Wikipedia on 21:34, 16 March 16
(http://s9.postimg.org/ndh8hhukf/Screen_Shot_2016_03_16_at_21_46_34.png)
There is a trade off in compatibility mostly for DOS, but the partition could be restored (the most compatible value is "IBM 2.0"). Volume serial remains the least invasive way.
This guy jumps into detail and covers some cases:
On OEM IDs (http://seasip.info/Misc/oemid.html)
Same video as yesterday, but HD version.
I added two others functions in the Rom :
- ùrd,"DirectoryName" as remove directory
- ùdelete,"FileName" as delete file on x-Mass
Any pict from iMPdos' help screen (ùhlp is your friend)
And there you are as well, behind the camera :laugh:
Yeahhh, it's me !
From this 1994 usenet post Google Gruppi (https://groups.google.com/forum/?hl=la#!msg/comp.os.msdos.programmer/ZGE7qkh4eI0/1vssg3Yt3nkJ:)
Quote
PC-DOS 3.0
Result Condition
------ ---------
ignore BPB OEM[1-4] != 'IBM '
use BPB OEM[6-8] == '2.0'
ignore BPB otherwise
Compaq DOS 3.0
Result Condition
------ ---------
use BPB OEM[1-4] == 'CCC ' && OEM[6-7] == '2.'
ignore BPB OEM[1-4] != 'IBM '
use BPB OEM[6-8] == '2.0'
use BPB OEM[6-8] == '3.0'
ignore BPB otherwise
PC-DOS 3.1
Result Condition
------ ---------
ignore BPB OEM[1-4] != 'IBM '
use BPB OEM[6-8] == '2.0'
use BPB OEM[6-8] == '3.1'
ignore BPB otherwise
PC-DOS & MS-DOS 3.2 and 3.21
Result Condition
------ ---------
ignore BPB OEM[1-4] != 'IBM '
use BPB OEM[6-8] == '2.0'
ignore BPB OEM[6-7] != '3.'
use BPB OEM[8] == '0'
use BPB OEM[8] == '2'
ignore BPB otherwise
MS-DOS 3.3
Result Condition
------ ---------
ignore BPB OEM[1-4] != 'IBM '
use BPB OEM[6-8] == '2.0'
ignore BPB OEM[6-7] != '3.'
ignore BPB OEM[8] <= '0'
use BPB otherwise
Compaq DOS 3.31
Result Condition
------ ---------
ignore BPB Doesn't start w/jmp or jmp short & nop
ignore BPB Any of the chars in OEM[1-7] < 20h or >6Eh (doesn't
check OEM[8], apparently a bug)
ignore BPB High order nibble of media desc != 0Fh
ignore BPB cluster size not a power of 2
ignore BPB OEM[1-4] == 'IBM ' && OEM[6-8] == '3.0'
use BPB otherwise
PC and MS DOS 5
Result Condition
------ ---------
ignore BPB Doesn't start w/jmp or jmp short & nop
ignore BPB High order nibble of media desc != 0Fh
ignore BPB Sector size not 512
ignore BPB cluster size not a power of 2
use BPB OEM[6-8] == '2.0'
use BPB OEM[5-7] == '10.'
use BPB OEM[5-7] == '20.'
ignore BPB OEM[6-7] == '0.'
ignore BPB OEM[6-7] < '3.' (word compare, OEM[7] most significant)
use BPB OEM[6-7] > '3.' (ditto)
ignore BPB OEM[8] < '1'
use BPB otherwise
So it turns out the best (in terms of compatibilty) OEM name to use BPB(Bios parameter block) would be : "IBM ?2.0". (question mark being in range of 0x20-0x6E inclusively).
For character out of this range "IBM x2.0" would break compatibility with Compaq DOS 3.31.
It's not possible to reuse 2bytes from the OEM field and keep compatiblity with DOSes 3.x line (btw the 3.x has maximum fat16 partition capacity @ 32 MB).
If one cares only about PC and MS DOS 5.x and above (that would include Windows3.1-ME) keeping the OEM as "xxxxx2.0" is good enough.
I wonder if any (actual) FAT implementation cares about the OEM name? IIRC there are no rules about it in the FAT specification.
Quote from: Prodatron on 22:44, 17 March 16
I wonder if any (actual) FAT implementation cares about the OEM name? IIRC there are no rules about it in the FAT specification.
But we need it to store our informations.
If we want symbos, impdos and why not acmedos compatibles.
It will be easy for us to follow these informations and stay compatibles with each others.
It would be great if iMPdos and ACMEdos will be compatible. :) Well, since ACMEdos is not out now... not the most easy task. Good luck! :)
Quote from: Ast on 22:55, 17 March 16
But we need it to store our informations.
If we want symbos, impdos and why not acmedos compatibles.
It will be easy for us to follow these informations and stay compatibles with each others.
Just keep it FAT compatible. Then it will be compatible with Acmedos, SymbOS and everything else. And you will be able to exchange data storage with other computers. I don't see any sense to break FAT compatibility for increasing the speed when writing something for the first time.
Quote from: Prodatron on 22:44, 17 March 16
I wonder if any (actual) FAT implementation cares about the OEM name? IIRC there are no rules about it in the FAT specification.
That's correct, but IRL old DOSes (80s era) relied on it to some extent as mentioned in the web resources I quoted. Actually making them sometimes not cross compatible back in the day. Ideally if @Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573) could squeeze the additional information he'd like to hold to 5 bytes (assuming using 4bytes Volume Serial too) it would be almost ideally compatible (minus the Compaq Dos 3.31). I do agree the last sector approach is not a good idea and can lead to data corruption.
Quote from: Ast on 14:59, 17 March 16Any pict from iMPdos' help screen (ùhlp is your friend)
Hmm... Couldn't a less generic command be used? Something like |IMPHELP maybe?
[edit] It's just that as each ROM wants to come with its own help screen, we will start to get a profusion of |help |hlp |helpme |hlpme |helping |aide ... with no way of remembering which does what. I have the same concern about |HELP in FW3.15 too.
Quote from: khaz on 16:30, 18 March 16
Hmm... Couldn't a less generic command be used? Something like |IMPHELP maybe?
[edit] It's just that as each ROM wants to come with its own help screen, we will start to get a profusion of |help |hlp |helpme |hlpme |helping |aide ... with no way of remembering which does what. I have the same concern about |HELP in FW3.15 too.
Totally agree! Suggesting:
- FW3.15: !HFW
- ACMEdos: !HAC
- iMPdos: !HIMP
- FutureOS: !FHELP
Loger names are nice, but not for a eveydays usage, keeping is short saves keyboards. ;)
Quote from: TFM on 19:29, 18 March 16
Totally agree! Suggesting:
- FW3.15: !HFW
- ACMEdos: !HAC
- iMPdos: !HIMP
- FutureOS: !FHELP
Loger names are nice, but not for a eveydays usage, keeping is short saves keyboards. ;)
I thought the command for FutureOS would be |FHILFE ;)
Why not ?
Propose your own commands...
We Will vote for them
Quote from: Singaja on 19:54, 18 March 16
I thought the command for FutureOS would be |FHILFE ;)
Nope, kept it international. Just !FVER... upps !FHELP. ;) :)
I'm still working on news instructions which could give you
an Easy way to use iMPdos... Z80 Coding is so interesting...
@Prodatron (http://www.cpcwiki.eu/forum/index.php?action=profile;u=13) : can you tell me where you store the N value you need to calculate where the next file will be written ?
Some news from yesterday (saturday night!)
iMPdos is growing up. Thanks for all comments. You give me the energy to go on.
I've added the * in the ùcopy's rsx which allows you to copy all or certain file present on the disc on your x-Mass.
Name of the files displayed come from my beta-tester Dirtybb. Great idea !
(http://img110.xooimage.com/files/4/2/f/image-4ecf59c.jpeg) (http://amstradplus.forumforever.com/image/110/4/2/f/image-4ecf59c.jpeg.htm)
The |HELP command from the FW3.1x EXP ROM just replace/overload the existing |HELP command from UTOPIA with the same informations and usage.
So, It not have to be renamed to something custom... It is system related.
In Conclusion all available ROMs should be investigated for |HELP and patched to not get into conflict with other ROMs...
Maxam also has |HELP...
For the DOSes i wish that they can hook their Routines into the OS-Vectors so that the Programs dont need to be patched to run from the Media in Control of the DOS (Albireo, ACME, iMP...) and the usual Basic Commands (CAT, LOAD, SAVE ...) work as expected...
|IMP.ACT (eg. |AMSDOS)
|IMP.IN (eg. |DISC.IN)
|IMP.OUT (eg. |DISC.OUT)
AMCEDOS directly use the commands (LOAD, RUN, SAVE, CAT...) and RSX (|DIR, |ERA, |REN, ...) to work.
Quote from: Ast on 21:52, 18 March 16@Prodatron (http://www.cpcwiki.eu/forum/index.php?action=profile;u=13) : can you tell me where you store the N value you need to calculate where the next file will be written ?
It's an internal value inside the memory, it's not stored on the harddisc. For FAT12 and FAT16 partitions you always have to walk through the whole FAT once when searching for the first free cluster.
Ok,I agree of what you wrote but why don't simply use some unused bytes into the boot ? I was thinking about fake serial number written in the Boot.... for example...
My philosophy : It will be easy and faster to find the last sector written (and store here) instead of searching on the whole fat the most bigger sector.
All you have to do is :
On each file written, you'll just have to write the last sector used and store it onto the boot (sector 0) in the fake serial number.
I don't know if i'm definitively clear...
And what happens when someone writes to the drive using another tool that doesn't update your magic value? You just overwrite the sector and corrupt the drive?
Right !
That's why we discuss about making Something compatible and usable by all.
Edit : That's why i've decided to open "the solution" i used and discuss with other people to see how they do.
Why not storing it in the Place where a/the Bootloader would reside at the Bootsector?
*edit*
But, how will this value be helpful when the drive gets more and more fragmentated over the time?
*/edit*
It's a bit late in the day to try and persuade everyone of a new requirement for FAT drives. And then you have the problem that the last written block may not be immediately followed by a free block, so you're just going to end up moving the scan to the end of each block write, rather than the beginning....
The incorrect bootloader could mess up with other operating systems so I think it's not the best approach.
My idea is following use the volume serial , and the most safe 5-th byte of OEM as checksum mod 255 (or any other approach squeezing the checksum to 1byte). The chances of fake-positive clash from other systems not using this approach would be very very low.
Quote from: pelrun on 20:22, 20 March 16
And what happens when someone writes to the drive using another tool that doesn't update your magic value? You just overwrite the sector and corrupt the drive?
Pelrun and Andycadley are right. IMHO such a hack doesn't make much sense. At least in SymbOS I am not allowed to do such a trick at all, as it runs on systems which removeable IDE devices, and which are also handled by the native OSes of the machines (MSX-DOS, EXOS). If SymbOS would use such an optimizations, people would destroy their filesystems/storages. The same for the CPC and the SYMBiFACE II: You usually swap CF-cards/harddiscs with a PC for transfering data, and in this case it would be corrupted, too.
It would be an X-MASS-only solution, but why should you limit your new IDE-DOS in this way?
Quote from: Prodatron on 20:51, 20 March 16
It would be an X-MASS-only solution, but why should you limit your new IDE-DOS in this way?
But, for information, iMPdos was first developped for the x-Mass :)
Quote from: Ast on 20:29, 20 March 16That's why we discuss about making Something compatible and usable by all.
No, there will always be someone who uses a tool that doesn't follow your "standard". Or they connect the DOM to their PC to access it.
Since you can't force everyone to update their FAT support, and you can't force your users to only use the tools you cooperate with, the only correct way to handle this is to do it the way the FAT standard tells you to. Any "shortcut" you try to implement will be *wrong*. You may as well make your own format and renounce any sort of FAT compatibility.
ah! That's better like that.
I don't want to force anyone to use a system instead of his own.
Correct me if I'm wrong but if there was a way to identify whether Ast's optimisation is used or not wouldn't it be good enough? If a drive is not using it, a search would be made to find the value and it would get stored then. Maybe I'm missing something
Quote from: Singaja on 21:07, 20 March 16
Correct me if I'm wrong but if there was away to identify whether Ast's optimisation is used or not wouldn't it be good enough? If a drive is not using it, a search would be made to find the value and it would get stored then. Maybe I'm missing something
Standard FAT-implementations don't know about Asts modification, and there is no fast way for iMPdos to find out, if a drive was modified by a system with standard FAT-implementation.
Quote from: Prodatron on 21:17, 20 March 16
Standard FAT-implementations don't know about Asts modification, and there is no fast way for iMPdos to find out, if a drive was modified by a system with standard FAT-implementation.
Quote from: Singaja on 20:41, 20 March 16My idea is following use the volume serial , and the most safe 5-th byte of OEM as checksum mod 255 (or any other approach squeezing the checksum to 1byte). The chances of fake-positive clash from other systems not using this approach would be very very low.
I just proposed a relatively fast way few posts back^.
Quote from: Singaja on 21:21, 20 March 16
I just proposed a relatively fast way few posts back^.
Maybe I don't get you, but another FAT implementation wouldn't change the volume serial/OEM. So how should you recognize any changes on the filesystem?
Quote from: Prodatron on 21:29, 20 March 16
Maybe I don't get you, but another FAT implementation wouldn't change the volume serial/OEM. So how should you recognize any changes on the filesystem?
Let's consider the case of Dos/Windows formatted FAT16. It will have some arbitrary 4byte volume serial number and OEM of something like "DOS 5.0" "WIN 4.0" (I did this cover the other OEMs in detail in my previous post for reference). Now the drive gets connected and it's X-mass like device running on CPC.
Ast's Impdos reads the 4byte volume serial and computes a checksum. I did suggest using a 1 byte checksum (it's not a necessary condition though a bigger checksum would be even better), because that would be least invasive for DOS3.x from various vendors (also covered in my OEM post).
Now the computed checksum is checked against the place against where the stored checksum is expected. If they are not equal (and for the above case they should not be equal but it's important to minimise the chance of false positive clash) then voila it's not a "pimped by Ast" Fat16 so time for searching. When done the value is found it should get stored, the checksum computed and stored too. The opposite case is pretty straightforward, the volume serial vs the checksum matches so it's safe to use the volume serial storing Ast's special value.
That's exactly this way... This debate is very exciting.
Step 1. Use the drive with iMPdos so that it sets this custom value.
Step 2. Write to the drive with something else that doesn't update the value and *doesn't* automatically overwrite the volume label.
Step 3. Write to the drive with iMPdos. iMPdos reads the label, sees the checksum is intact, reads the custom value, then overwrites the wrong sector with new data. BAM, you've corrupted it.
The *only* way to ensure you don't hit a corruption path is to ensure it's only ever written to by iMPdos. At that point, there's no reason to pretend to be FAT compatible, you're effectively doing your own thing anyway.
Quote from: pelrun on 22:09, 20 March 16Step 2. Write to the drive with something else that doesn't update the value and *doesn't* automatically overwrite the volume label.
...which is usual for all FAT-implementations. So this is the standard case.
Quote from: pelrun on 22:09, 20 March 16Step 3. Write to the drive with iMPdos. iMPdos reads the label, sees the checksum is intact, reads the custom value, then overwrites the wrong sector with new data. BAM, you've corrupted it.
And because of this such hacks won't work, when using multiple FAT-implementations for the same storage.
Did you already test, how long it takes to find the first free cluster on a 128MB DOM which is nearly full, when starting from the beginning?
As I said before, you only need to do it once after booting, so even if it takes some seconds it's not an issue IMHO.
Quote from: pelrun on 22:09, 20 March 16
Step 1. Use the drive with iMPdos so that it sets this custom value.
Step 2. Write to the drive with something else that doesn't update the value and *doesn't* automatically overwrite the volume label.
Step 3. Write to the drive with iMPdos. iMPdos reads the label, sees the checksum is intact, reads the custom value, then overwrites the wrong sector with new data. BAM, you've corrupted it.
The *only* way to ensure you don't hit a corruption path is to ensure it's only ever written to by iMPdos. At that point, there's no reason to pretend to be FAT compatible, you're effectively doing your own thing anyway.
Ok, I must admit this is a problem. I'm reading about Last Access Time and/or Write Access Time of Directory Entry Structure (having the root directory in mind). Perhaps it could be useful but I'll need my mind fresh to evaluate it. More to come I hope :P
@Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573)
Please make Impdos fully compatible with FAT 16.
Quote from Prodatron
""Did you already test, how long it takes to find the first free cluster on a 128MB DOM which is nearly full, when starting from the beginning?As I said before, you only need to do it once after booting, so even if it takes some seconds it's not an issue IMHO.""
Please keep up the good work.Ray
Quote from: Singaja on 22:59, 20 March 16I'm reading about Last Access Time and/or Write Access Time of Directory Entry Structure (having the root directory in mind).
I think there is no rule to update timestamps of parent directories, if you write into sub directories. So this shouldn't work as well.
Quote from: Audronic on 23:06, 20 March 16
@Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573)
Please make Impdos fully compatible with FAT 16.
I agree! :)
Here is a new video showing iMPdos in action... It's good and Fast ! Mmmmm !
Do you agree ?
It is really awesome!
A new video, just to show you how you can copy all files from drive a/b to x-Mass.
Usage :
ùcopy,"* -> copy all files
Life is so beautifull!
As you probably know, you can't write many and many files on your x-Mass.
Fat 16 has his limit. Root can allow up to 512 files and Directory up to 64 files per directory, of course.
It's what's i did this afternoon. Result ? It works very well.
Great progress! You are really fast!
Quote from: Ast on 17:08, 23 March 16Fat 16 has his limit. Root can allow up to 512 files and Directory up to 64 files per directory, of course.
Sub directories are not limited, only the root is limited to 512 entries (files and subdirectories). For FAT12 this is 224.
The total amount of files/directories on a FAT16 partition is 65536 (due to the fact, that the FAT itself is limited to 65536 entries). So in theory a subdirectory could contain nearly this amount of entries.
Quote from: Prodatron on 17:36, 23 March 16
Great progress! You are really fast!
Sub directories are not limited, only the root is limited to 512 entries (files and subdirectories). For FAT12 this is 224.
The total amount of files/directories on a FAT16 partition is 65536 (due to the fact, that the FAT itself is limited to 65536 entries). So in theory a subdirectory could contain nearly this amount of entries.
I wanted to say 64 entries per sub-directory. ^^
Quote from: Ast on 18:29, 23 March 16
I wanted to say 64 entries per sub-directory. ^^
The only limit to the number of entry in a sub directory is the size of your partition. When your cluster is full, just allocate a new one and chain it.
Quote from: Ast on 18:29, 23 March 16
I wanted to say 64 entries per sub-directory. ^^
A subdirectory can contain something above 65500 entries. More than 64 entries are not a problem at all :)
@Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573) : Great to see how quick you advance!!! Really amazing!!! :) :) :)
Some news in Amstrad Plus (http://amstradplus.forumforever.com/t214-Initiation-la-X-Mass.htm?start=150#p2625) forum. I precise that it's written in french so use your google translate for non french reader.
@TFM (http://www.cpcwiki.eu/forum/index.php?action=profile;u=179): i 'm working on this Rom all my free time and for me, it's not enough fast for me to propose you my work.
I am still in work, looking at hidden bugs found by MadRam.
I know it's not enough fast but i do my best.
I hope sharing you iMPdos as soon as possible.
A nice X-MASS application should be a SCUMM port. 8)
And, as I told somewhere else, if something like that existed, I would really try to make a cool point and click!! :D :D
A good x-mass application Will allows that, believe it !!!
I need help concerning the memory command.
When you do "memory &7fff" some bytes are modified in address XXXX.
I found some of them but I think one or more are missing... Who could help me ?
here are the address i found :
#ae5E-#ae5F, #b071-#b074, #B078-#B079
Quote from: Ast on 18:28, 31 March 16
I need help concerning the memory command.
When you do "memory &7fff" some bytes are modified in address XXXX.
I found some of them but I think one or more are missing... Who could help me ?
here are the address i found :
#ae5E-#ae5F, #b071-#b074, #B078-#B079
http://cpctech.cpc-live.com/docs/firmware.pdf (http://cpctech.cpc-live.com/docs/firmware.pdf)
It is in this doc. Address is different for basic v1.0.
I already know it but thanks ^^
adresses i have written are, of course, valable on cpc 664 & 6128 (Old&Plus) only !
Quote from: Ast on 19:55, 31 March 16
I already know it but thanks ^^
adresses i have written are, of course, valable on cpc 664 & 6128 (Old&Plus) only !
np. You can also look here:
http://cpctech.cpc-live.com/docs/basic.asm (http://cpctech.cpc-live.com/docs/basic.asm)
it's the basic v1.1 disassembly I made. I have commented quite a bit.
Quote from: ||C|-|E|| on 16:38, 31 March 16
And, as I told somewhere else, if something like that existed, I would really try to make a cool point and click!! :D :D
This has been discussed in a lot of threads and year after year... but nothing really happens
We need this application, why not crowfunding this and pay someone to make such IDE for PC?
This is a LOT of job, i doubt that anybody will do this for free..
IMHO the question is not about money. IMHO it's about: How can do it AND has the time to do it?
But let's ask: Anybody out there who would volunteer for a nice bunch of cash?
Why would the X-Mass be needed for SCUMM?
Because of all the tons of data, which have to been loaded between the scenes...
Quote from: TFM on 20:35, 31 March 16
But let's ask: Anybody out there who would volunteer for a nice bunch of cash?
I suspect cash, unless it really is a lot, is probably less interesting than the sheer challenge of it.
Unfortunately there doesn't seem to be a lot of documentation on how SCUMM works, so it's not exactly obvious where one would start. Then there's the question of whether just cloning an early version of SCUMM is necessarily better than designing something from scratch.
@Ast (http://www.cpcwiki.eu/forum/index.php?action=profile;u=573)
Please have a look at the PM
Thanks Ray
Megachur had started the scumm adaptation some years ago. Maybe he will be interested by restarting this project... Who knows ?
At ray : look at you emails... You will be happy. iMPdos is waiting for you.
I guess that if this project saw the light it would be very interesting to support X-MEM as well. However, considering how fast X-MASS is, I guess that it should be possible to use it as RAM, right?
Quote from: Prodatron on 21:44, 31 March 16
Because of all the tons of data, which have to been loaded between the scenes...
Yes. And because, that allow to make it working like the PC/Amiga/ST versions by using the same folders and files structure.
(should be a SymbOS application, using extra memory and audio features too)Quote from: ||C|-|E|| on 00:32, 01 April 16I guess that if this project saw the light it would be very interesting to support X-MEM as well. However, considering how fast X-MASS is, I guess that it should be possible to use it as RAM, right?
Using the X-MEM only will require to store a game on the ROM side or having long floppies loading/unpack to fill the RAM.
On X-MASS, you can store more SCUMM games on folders and easilly create a new "Point and Click" by using files structure.
Better to not use the X-MASS as RAM (direct access), else you will finish to kill its flash memory with to much writes on it.
Quote from: Ast on 22:46, 31 March 16
Megachur had started the scumm adaptation some years ago. Maybe he will be interested by restarting this project... Who knows ?
I know, as I have converted the Monkey Island fonts for his tests, years ago.
Maybe we should start a new (and definitive) thread for the scumm subject?
I have nothing more to said about... It is just an X-MASS application idea.
Quote from: TotO on 09:40, 01 April 16
I have nothing more to said about... It is just an X-MASS application idea.
it's easy to have application ideas for mass storage solutions, with 4gb, fat32 and 512k's solutions almost any 16bit era game can be ported, or have 10000 levels, 1000 cinematic sequences..., the problem then is like the modern PC's, needs more than one single person to do a game... unintentionally we have traslated a PC problem here, the games now can be infinite in graphic terms, music, gfx, levels... some games require a group of persons to do the games... of course the scumm games were made by a team of programmers.
Start a scumm port for CPC by only one person for me is just crazy... of course there is need for various persons, not only the code, the graphics, sounds, IA, script... it's crazy to do this only one person!... and for free... c'mon he will need month or years to do this... really for free? i doubt it, we have jobs, children, family... it's impossible without a compensation for this person.
and not only this,
X-mass, Symbiface II or any other mass storage solution, the important here is to have a good DOS / fat 32 support that works on any compatible hardware... nowadays we haven't...
evidently a scumm game will benefit of the SF2 mouse port too... or other mouse solutions of course...
but, as i said better on other thread...
Sorry for hijack this thread!
Certainly, the "bigger" the machine the harder to produce something something that actually makes good use of it. We have been almost 8 months with our adventure and the database (without graphics) is only 60KB. Then, we have around 600KB of graphics as well. If the machine had 512KB of RAM and 128MB of HDD, well, I cannot imagine how long it would take, but it would be awesome :laugh: On the other hand, we would be able to use lots of tricks that are RAM consuming: for instance, we could increase the number of colors and do lots of overscan :D
Quote from: andycadley on 22:41, 31 March 16
... Then there's the question of whether just cloning an early version of SCUMM is necessarily better than designing something from scratch.
Totally agreed! :) :) :)
I now have a working X-Mass and am doing some functional tests of ImpDOS16-1 (Madram) Version for " Ast ".
NB:- This is a Work In Progress not a release Yet
The ImpDOS comes as an 8K Rom That can be Placed in any spare slot.
I have chosen slot 2 on the X-Mem.
It Boots up with a Mode 1 screen which has a Reddish Background.
I have tried i think most of the commands that are available, which can be seen if you type in " |HLP ".
|HLP Help File
|CAT To Catalog the Hard Drive
CAT To Catalog the Floppy drives |A - |B
|cd To Change Directory on the Hard Drive
|L To load a file from the Hard Drive
|R To Run a File from the Hard Drive
|format To Format the DOM 2 types of format.
|md To Make a Directory on the Hard Drive
|cp To Copy Files EG |CP,"* Copy all Files to Hard Drive
|copy To Copy Files EG |CP,"* Copy all Files to Hard Drive
|rd To Remove a Directory from the Hard Drive
|del To delete Files from the Hard Drive
|edit To Edit (View)(Hard Drive) Sectors
|Load To Load a Program to Memory from the Hard Drive
|Run To Run a program from the Hard Drive
I have have been able to Use all of the above with NO PROBLEMS.
I have made a Movie of some of the commands in action. Please download it and have a look.
Please skip through some of the longer sections whilst copying 21 Files from Floppy to DOM
which appears to be Drive X/ ??
https://www.dropbox.com/s/8wv2325zz1g7h8l/ImpDOS16-1.mp4?dl=0
Thanks Ray
Well done Ray.
This version is only WiP and it stays many bugs to explode.
I took few days to be quiet because i am not in my best.
That's sweet indeed :)
Could you implement a "dir /w" and "dir /p" style outputs?
Also, what tunes does it work with - what must a user whistle?
Quote from: Gryzor on 18:39, 02 April 16
That's sweet indeed :)
Could you implement a "dir /w" and "dir /p" style outputs?
Also, what tunes does it work with - what must a user whistle?
OOOps I was whistling while i was waiting for the 21 items to be copied and forgot that the camera had SOUND.Yes |CAT /W and a |CAT /P would be good.
Ray
Euh, what are /w and /p ?
/w means: display directory in "wide" format. Less information but more files can be displayed at the same time
/p means: wait for keypress after displaying one screenpage
Thanks for lightening my brain!
So yes, it would be cool to be implemeted!
As i saw it's not clear for most of people, i've decided to give you more informations about iMPdos :
-Drive X is used as "X-Mass", that's all
-You can't access Drive X by typing |x or ùx because this drive does not exist.
To display the directory, i simply read the data written on the X-Mass then i print them.
-iMPdos is simply based on i/o ide routines (Thanks prodatron) which allow to read/write data from X-Mass expansion.
I used to always use dir /p /w /o:n
Huh, can you believe it, I had never realized you had to use /o:n to sort them... or I just don't remember it!
I don't really understand what you want to tell.
Quote from: Ast on 14:23, 13 April 16
I don't really understand what you want to tell.
DIR /o:n --> DIR Will list the files sorted by name
You will find all DIR specifcs option here :
https://en.wikipedia.org/wiki/Dir(command)#Options.2FSwitches (https://en.wikipedia.org/wiki/Dir_(command)#Options.2FSwitches)
Quote from: Ast on 14:23, 13 April 16
I don't really understand what you want to tell.
No need for a fake ms-dos with all its problems. Just do it your way. :) :) :) Typing all this slashes and letters is a pain in the behind anyway. Let's do it better on CPC side. :) :) :)
TBH when you've used unix, DOS is a really horrible shell. CPC is even more archaic :(
But at least it's functional, and with IDE/FAT support, who cares? :)
most "ls" (dir equivalent in unix) implementations automatically do wide view and alphabetic listing. To make it pause you can pipe the output of ls into another command, "more", so it becomes "ls | more". This has greater flexibility - "more" can be used with any command to make the output pause when it fills the screen, and you can also scroll up and down in the output, and search it for specific text. Also in unix multiple options can be chained together into a single switch, so "ls -l" which gives detailed listings, and "ls -a" which shows hidden files, can be combined to "ls -la" or "ls -al" as a shorthand for "ls -l -a", unlike in DOS where each must be given separately
Remember we are on Cpc. All must be done from zero. It's the purpose of iMPdos!
Quote from: Ast on 08:48, 14 April 16
Remember we are on Cpc. All must be done from zero. It's the purpose of iMPdos!
Yeah sorry, I'm not expecting you to implement a full modern unix shell on the CPC on top of AMSDOS! I probably shouldn't compare unix to the DOS on an 8-bit micro, it isn't fair!
Don't forget SamaruX for CPC (CP/M) which provides some functionalities of a Unix shell like cp, cat, grep and piping it with | to different command.
In principle it is possible (a little bit restricted :) but possible for an 8-Bit) and FloppySoftware also provides the source code which is written in Small-C.
Quote from: HAL 6128 on 15:33, 14 April 16
Don't forget SamaruX for CPC (CP/M) which provides some functionalities of a Unix shell like cp, cat, grep and piping it with | to different command.
In principle it is possible (a little bit restricted :) but possible for an 8-Bit) and FloppySoftware also provides the source code which is written in Small-C.
You talk about CP/M now, which can do pretty much all that file sorting and waiting already just by using the DIR [full] command.
btw: Check out the Z3Plus if you want an Unix felling for the CPC, it has way more features than SamaruX (which is a great thing too). :)
IMHO it's not the purpose of a DOS to contain a SHELL in addition.