Octoate's News - QuickCMD v2.2

[MiguelSky]

For those that missed this too :

The "fast DIR" : when your Amstrad CPC got started, user just has to press CTRL+TAB to enter QuickCMD. Then, TAB key is expected to execute DIR command. Once the user chose a file to execute, the first characters composing the filename can be typed and then the filename can be auto-completed using the TAB key. Finally, press ENTER key to execute file. This workflow is ultra-fast, you will get quickly used to the CTRL+TAB then TAB scheme! Way faster than typing CAT command under BASIC then using SHIFT + arrow keys to select a filename then pressing COPY key to copy/paste filename then pressing CTRL+left arrow then pressing CTRL+ENTER to RUN" the file.

[TotO]

Well, that's a good argument but which kind of drive it would be

A drive that you don't expect today, because CPC is immortal.

so !Q is fine. And if you read the RSX command as IQ then this command is quick, neat, usefull and funny too

Using "!" instead of "|" is quick, neat, usefull and funny too... But it's not accurate for this usage... Except if we can accept that for laziness?

[norecess]

In next release, there will be (like Protext already does with its |PROTEXT and |P RSXs) :


|Q
|QCMD


That will do the exact same thing. CTRL+TAB will be binded to |Q to switch even faster between QuickCMD and AmsDOS.



Everyone agree ?

[SyX]

YEAH!!! 

[TFM]

Agreed 

[norecess]

I did the change on my side. I also fixed a problem with the ROMS command versus nameless-roms.


But I don't want to spam everyone with new versions every 2 days, so, this will be integrated in a later revision..

[Terje_Norway]

Hi,


So that's reason why the ROMS command doesn't work when You have the any of the three additional CPM+ roms.
I have been wondering why it didn't work, until I yesterday erased them by accident  . Without these roms, the ROMS command works perfect.


The three roms are as following (it could perhaps also be other roms, for all I know) :
- CPMacc1.rom
- CPMcrch.rom
- Dbreed1.rom

Just a small suggestion for You.
There is still some free space in the "QCMD.ROM". What if You, as a great programmer, managed to integrate the functions of the "BOOSTER.ROM" into the "QCMD.ROM". The "BOOSTER.ROM" does it's job, but it does unfortunately have a few drawbacks in my opinion. The biggest is that it more or less kills the "|HELP" command from the Arnor ROMS. Typing "|HELP" with "BOOSTER.ROM" in 15 only lists ROM 0. If You are filling the MegaFlash with 32 Roms, You would need a command like "|HELP", unless You got a very good memory remembering every RSX in every ROM.


Looking forward to further updates of the "QCMD.ROM".


Yours


Terje Grind
NORWAY

[Gryzor]

Two other suggestions: custom color schemes (especially white font on a dark background) and a command history accessible like in today's terminals, through the Up key (though this would need some bytes of memory with whatever consequences, so I'm not sure it's doable)...

[redbox]

There is still some free space in the "QCMD.ROM". What if You, as a great programmer, managed to integrate the functions of the "BOOSTER.ROM" into the "QCMD.ROM". The "BOOSTER.ROM" does it's job, but it does unfortunately have a few drawbacks in my opinion. The biggest is that it more or less kills the "|HELP" command from the Arnor ROMS. Typing "|HELP" with "BOOSTER.ROM" in 15 only lists ROM 0. If You are filling the MegaFlash with 32 Roms, You would need a command like "|HELP", unless You got a very good memory remembering every RSX in every ROM.

Nooooooooooooooooo!!!

@norecess: Please don't put the BOOSTER.ROM code in QuickCMD, it would ruin it in my opinion - I would rather decide if to use the BOOSTER or not, and I would have no choice if you did this.

@Terje: I know the BOOSTER.ROM code is very buggy, but I do intent to disassemble and re-write it (am half way there already) so then you could use it on your own ROM with anything else you want in it.

[TFM]

I know the BOOSTER.ROM code is very buggy, but I do intent to disassemble and re-write it (am half way there already) so then you could use it on your own ROM with anything else you want in it.

I don't agree! The Inicrons did a great job creating the booster ROM. In my hands (and in the hands of much others) it always worked well. There is no reason to insult the work of others. And honestly what you call a bug may be a feature.
No offense aginst you Redbox, but the Inicrons know how to deal with ROMs, while your seemingly still learn it.

[redbox]

I don't agree! The Inicrons did a great job creating the booster ROM. In my hands (and in the hands of much others) it always worked well. There is no reason to insult the work of others. And honestly what you call a bug may be a feature.
No offense aginst you Redbox, but the Inicrons know how to deal with ROMs, while your seemingly still learn it.

Well, in my (obviously beginner) opinion here's what's wrong with it:

1. It was made with RomGEN which produces spaghetti, long and unstructured code
2. It appears to initialise twice
3. It appears to checksum twice (and it's not necessary to do this even once really)
4. It also appears to copy unnecessary code to RAM which could interfere with other programs

I want to isolate the main routine (which is a really cool piece of programming), optimise it and make the source code available to others so that they can incorporate it into their own utility ROMs.  I eventually want to make a library of such routines from other ROMs, a 'build your own ROM' kit if you like.

If you're not interested in this, then that's fine with me but I still think it's very much worth doing.

[norecess]

I feel that command history + file copy functions are more important than the BOOSTER thing. Still about BOOSTER, I think its position is fixed (to 15), which is something I want to avoid.


I currently have something like 2-3 Kb free in QuickCMD, so this gives rooms for later improvement.


But right now, I won't do anything - I need to take a break off the CPC for few weeks.. I spent lots of time lately on it (too much actually!).

[Terje_Norway]

Hi,


It seems like I did start a small kind of "riot" with my suggestion for further updates of the "QCMD.ROM".
That was not my intention. What I tried to suggest was this :


1.) There are almost 3K of free space in the "QCMD.ROM" (That is based on the size of the .ROM file itself (16384-13463=2921 bytes free))
2.) The "BOOSTER.ROM" comes as 16K ROM. The size of the actual code seems much less. It takes less than 1K.
Based on the size of these two roms, they "could" both be fitted into one rom (It would still be over 2K free in the ROM)
3.) "BOOSTER.ROM" works. It does exactly what it was meant to do. Nothing more or less ! ! ! And the fact that it uses an entire ROM for only 1K of code. To me it seems a bit of waste that over 15K is left free ! ! ! That space could have been put to better use (That is my opinion at least ! !)
4.) I wouldn't go so far as to calling it "bugs" in the "BOOSTER.ROM" since it works, and I couldn't clam that I could do it any better myself. My point was only that I think it could be improved. If I was a programmer, I would have done a few adjustments to it. I think redbox is on the right track with his ideas.

Well, in my (obviously beginner) opinion here's what's wrong with it:

1. It was made with RomGEN which produces spaghetti, long and unstructured code
2. It appears to initialise twice
3. It appears to checksum twice (and it's not necessary to do this even once really)
4. It also appears to copy unnecessary code to RAM which could interfere with other programs

Yours


Terje Grind
NORWAY

[TFM]

Well, in my (obviously beginner) opinion here's what's wrong with it:

1. It was made with RomGEN which produces spaghetti, long and unstructured code
2. It appears to initialise twice
3. It appears to checksum twice (and it's not necessary to do this even once really)
4. It also appears to copy unnecessary code to RAM which could interfere with other programs

I want to isolate the main routine (which is a really cool piece of programming), optimise it and make the source code available to others so that they can incorporate it into their own utility ROMs.  I eventually want to make a library of such routines from other ROMs, a 'build your own ROM' kit if you like.

If you're not interested in this, then that's fine with me but I still think it's very much worth doing.

Sorry, that's wrong.

- It was not made with ROMGen, they just used ROMGen as tool to put a binary program into a ROM. And why shouldn't they use their own tool. Still there is no alternative to ROMGen.

- It must initialize twice, but the second time it doesn't really initialize. It just get's called, but it sensed, that it's job was already done. (Use an advanced !HELP command, to see the ROM RSX base address).

- Point 3 is - THE FECK - nitpicking! (You see I'm more and more into Father Ted  )

- How can code that gets copied to RAM interfere with other programs? It does that when the CPC is switched ON, there IS no other code in RAM.

I appreciate that you reengenier the Booster, and I hope you will create something better. But I don't appreciate that you make others well done software bad.

If you want to "isolate" the ROM-Booster routine, why don't you use the Softbrenner ROM, that was used to create it. Just get that piece of code back, instead of disassembling the RGEN framework.    So good luck with that.

[TFM]

2.) The "BOOSTER.ROM" comes as 16K ROM. The size of the actual code seems much less. It takes less than 1K.
Based on the size of these two roms, they "could" both be fitted into one rom (It would still be over 2K free in the ROM)

Now, this is the reason why the Inicrons used the RGEN to put the Booster-routine in a ROM. Using Softbrenner you can easiely add other programs (Basic and Binary!) to that ROM. So neither the space is wasted, nor RGEN was the "wrong" tool of choice. So, what the Inicrons did, all has a deeper sense!

[redbox]

- It was not made with ROMGen, they just used ROMGen as tool to put a binary program into a ROM. And why shouldn't they use their own tool. Still there is no alternative to ROMGen.

Errrr, so the ROM was made with ROMGen then.  I didn't say the routine, I said the ROM.  Surely the alternative to ROMGen is to just write your own ROM code...!!!

- It must initialize twice, but the second time it doesn't really initialize. It just get's called, but it sensed, that it's job was already done. (Use an advanced !HELP command, to see the ROM RSX base address).

Errrr, so it doesn't need to do this.  And as previously pointed out, this ROM knackers the |HELP command, yet another bug it has.

- Point 3 is - THE FECK - nitpicking! (You see I'm more and more into Father Ted  )

Not nitpicking, was showing you another piece of pointless and unnecessary code.  Father Ted rocks. 

- How can code that gets copied to RAM interfere with other programs? It does that when the CPC is switched ON, there IS no other code in RAM.

Because you might add more ROMs and then want to initialise them again via RSX from BASIC.  Then the RAM grab could be a problem.

I appreciate that you reengenier the Booster, and I hope you will create something better. But I don't appreciate that you make others well done software bad.

I wasn't saying this at all.  The routine is great.  The ROM is buggy and has lots of bad code that could be removed.  This is what I have been saying all along.

If you want to "isolate" the ROM-Booster routine, why don't you use the Softbrenner ROM, that was used to create it. Just get that piece of code back, instead of disassembling the RGEN framework.    So good luck with that.

Thank you for the information but I've already disassembled it, and just as well really because I got to see for myself how badly organised and redundant most of the code in the ROM is.  I therefore feel if you use Softbrenner to add more programs to the ROM you'll just end up putting good code onto bad foundations.

[norecess]

Come on guys, keep it easy and relax..

[redbox]

If you want to "isolate" the ROM-Booster routine, why don't you use the Softbrenner ROM, that was used to create it. Just get that piece of code back, instead of disassembling the RGEN framework.    So good luck with that.

I've tried this and the file it extracts is only half the story.  The ROM does lots of really strange things when booting up...!

I've just spent 3 hours disassembling the ROM, and I can assure you it's got lots of unnecessary and weird buggy code.

Nice idea, but really badly implemented.  The work continues 

[redbox]

Ok, I've extracted it.  What a pain that was, but understand how it works now.

Neat method Inicron, but lots of pointless code.  Maybe it's there to be red herrings?

[norecess]

@redbox: if you are able to disassemble it, understand it, and eventually document it ; it could be a nice addition to the community if you could add it onto the wiki !

[redbox]

@redbox: if you are able to disassemble it, understand it, and eventually document it ; it could be a nice addition to the community if you could add it onto the wiki !

Of course - will do exactly that when I've finished with it 

[redbox]

Actually, looking more into it, I think the developer built some tables and some conditional routines to aid in the creation of the ROM - the values could be changed so they could experiment with it.  When it was finished, these were kept rather than optimising it.


I'd rather write a clearer example so that you can see actually how it's done - and it's this version I would share with everyone 


It's got an interesting patch that appears to detect and initialise AMSDOS (or whatever is in ROM 7) independently.  I assume this is because a ROM in position 15 (where BOOSTER has to go) does something to position 7 (disc OS ROM) - is this correct?

[norecess]

When CPC gets started, the ROM 0 will be initialized. Most of the times, ROM 0 is BASIC.


BASIC will then initialize all the ROMs, starting from ROM 15 to ROM 1, then finally execute himself.


I believe that BOOSTER will initialize ROMs from 31 to 16, then will accumulate space required for each of them in RAM and end the initialization process.

[Bryce]

Was booster 464 compatible? Don't forget that the 464 (The classic one at least, not sure about the Plus) only initialised ROMs 7 to 0, not 15 to 0. Also, they may be initialising ROM 7 first, then doing the others.

Bryce.

[redbox]

@norecess - I think it's the OS that walks the ROMs, not BASIC, but I see what you're saying.

@Bryce - I think you're right here because I skipped this code and the AMSDOS ROM didn't initialise.  The reason for the order is unclear, but I'm getting there!