Excuse me this question but please help. I missed CPC world almost 25 years. :( Please give me a link to program to view the plain text files like TYPE at CP/M. I also need an easy editor for the plain texts like Microsoft Windows Notepad. Thanks.
Do you have ED on the CP/M disk?
There is also Wordstar.
I am sorry but I do not know much about CP/M.
Quote from: litwr on 14:51, 11 July 14
Excuse me this question but please help. I missed CPC world almost 25 years. :( Please give me a link to program to view the plain text files like TYPE at CP/M. I also need an easy editor for the plain texts like Microsoft Windows Notepad. Thanks.
protext will do this on Rom for amsdos or disc for cp/m.
For viewing only text files in a very fast and pleasant way, try mine C-View from C-Lab collection.
You can create executable files as well with the Linker tool.
Another easy solution is through DiscoMagic programm. It has view file option...
Thanks! :) But...
1) ed is only for CP/M and a bit too *savage* - a full screen editor required.
2) protext is too complex and its disk is protected. I need only a simple notepad.
3) WordStar is for CP/M only. I like WordStar, I spent a lot of time with Turbo Pascal 3 at 80s. ;) I want to find something like Turbo Pascal editor but without Pascal.
The editor should not be protected. I am going to distribute it with my program. So it has to be on disk.
Linux has dozen such editors: vi, joe, jed, nano, mcedit, pico, ... Is there something of this kind for AMSDOS?
VDE would fit the bill, but like the rest it's CP/M again
About VDE - VDE Editor (https://sites.google.com/site/vdeeditor/Home/about-vde)
Craig
Quote from: litwr on 14:51, 11 July 14
Excuse me this question but please help. I missed CPC world almost 25 years. :( Please give me a link to program to view the plain text files like TYPE at CP/M. I also need an easy editor for the plain texts like Microsoft Windows Notepad. Thanks.
Quote from: litwr on 21:15, 11 July 14
Thanks! :) But...
1) ed is only for CP/M and a bit too *savage* - a full screen editor required.
2) protext is too complex and its disk is protected. I need only a simple notepad.
3) WordStar is for CP/M only. I like WordStar, I spent a lot of time with Turbo Pascal 3 at 80s. ;) I want to find something like Turbo Pascal editor but without Pascal.
The editor should not be protected. I am going to distribute it with my program. So it has to be on disk.
Linux has dozen such editors: vi, joe, jed, nano, mcedit, pico, ... Is there something of this kind for AMSDOS?
OK, your first post made it seem like you wanted a CP/M program, now we know you want a copyright free Amsdos program you should get a lot more suggestions in future.
This little program from Amstrad Action Issue 53 Forum will simulate the CP/M TYPE command:
10 INPUT"Filename:",a$:OPENIN a$:WHILE NOT EOF:LINE INPUT#9,b$:PRINT b$:CALL &BB18:WEND:CLOSEIN
If you want to keep the text flowing like CP/M TYPE command, I suggest removing the "CALL &BB18" from it.
Quote from: CraigsBar on 21:26, 11 July 14
VDE would fit the bill, but like the rest it's CP/M again
About VDE - VDE Editor (https://sites.google.com/site/vdeeditor/Home/about-vde)
Or for Amsdos TexTool has some pretty snazzy ASCII editing functions
http://www.genesis8bit.com/frontend/utility/textool.zip (http://www.genesis8bit.com/frontend/utility/textool.zip)
Craig
Quote from: AMSDOS on 23:20, 11 July 14
This little program from Amstrad Action Issue 53 Forum will simulate the CP/M TYPE command:
Thank you! :D I begin to think that the only way to get proper editor is to write it in Basic. :o
Quote from: CraigsBar on 21:26, 11 July 14
VDE would fit the bill, but like the rest it's CP/M again
VDO/VDE looks fine. I need it but there is uneasy job of CP/M(MS-DOS, Unix, ...)->AMSDOS conversion for a newbie. :( It is also possible to try Unix C sources... Is there an easier way?
Quote from: CraigsBar on 23:39, 11 July 14
Or for Amsdos TexTool has some pretty snazzy ASCII editing functions
I've just tried TeXTool. It is protected and I couldnot force it to edit ASCII plain text. :(
anoth public domain disc......
http://www.genesis8bit.com/frontend/file/u010.zip
This one has 2 word processors on it "domain word" and "wordpro" they might be worth a look
Quote from: CraigsBar on 08:44, 12 July 14
anoth public domain disc......
http://www.genesis8bit.com/frontend/file/u010.zip (http://www.genesis8bit.com/frontend/file/u010.zip)
Thank you very much! :) This archive is very useful. It looks like that WordPro and Domain Word are close to my needs. It is only sad that Word Pro help system is broken. :( Are there links list to such kind of archives? BTW I am seeking also a way to convert ASCII text of BASIC program to the format acceptable by CPC. ;)
Quote from: litwr on 12:12, 12 July 14
Are there links list to such kind of archives? BTW I am seeking also a way to convert ASCII text of BASIC program to the format acceptable by CPC. ;)
Well most sites are mirrored at ftp://ftp.barnyard.co.uk/ (http://ftp://ftp.barnyard.co.uk/)
with nice front ends
http://www.genesis8bit.fr/index.php (http://www.genesis8bit.fr/index.php)
T.A.C.G.R. - Welcome (http://tacgr.emuunlim.com/)
Craig
Quote from: CraigsBar on 12:47, 12 July 14
Well most sites are mirrored at http://ftp://ftp.barnyard.co.uk/ (http://ftp://ftp.barnyard.co.uk/)
This link is not working.
:(
Quote from: litwr on 14:33, 12 July 14
This link is not working. :(
Take the http:// off the front
@litwr (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1057): You could search in CPC-Power (http://www.cpc-power.com/) by "word", "text", "edit" or similar words to try a few more applications.
@CraigsBar (http://www.cpcwiki.eu/forum/index.php?action=profile;u=482): Have you configured VDE for using it in a PCW or 6128 with CP/M+???
Quote from: SyX on 18:20, 12 July 14
@CraigsBar (http://www.cpcwiki.eu/forum/index.php?action=profile;u=482): Have you configured VDE for using it in a PCW or 6128 with CP/M+???
I have used VDE under CP/M on both my CPC 6128 and 6128plus. I used it for writing Basic as it provides excellent editing tools and will output Pure ASCII with nothing else included. It is a long time ago however and I cannot remember if I needed to do any conversion on the result, or if I just changed the extension to BAS and ran it ;)
Quote from: SyX on 18:20, 12 July 14
@litwr (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1057): You could search in CPC-Power (http://www.cpc-power.com/) by "word", "text", "edit" or similar words to try a few more applications.
Wow! It needs months to look at all these programs. :D Thanks!
Quote from: CraigsBar on 18:27, 12 July 14
I have used VDE under CP/M on both my CPC 6128 and 6128plus. I used it for writing Basic as it provides excellent editing tools and will output Pure ASCII with nothing else included. It is a long time ago however and I cannot remember if I needed to do any conversion on the result, or if I just changed the extension to BAS and ran it ;)
Why to write Basic text under CP/M? IMHO it is more natural under AMSDOS. So it gives a theoretical question. Is it easy to convert open source program from CP/M to AMSDOS?
I forgot that CPC Basic unlike Commodore may use pure ASCII sources.
I'm a little late to this party but one of the early Amstrad Action type-ins was a decent text editor in BASIC. It's called "Text Editor" and it's on the issue 23 (September 1987) type-ins .DSK:
http://www.cpcwiki.eu/index.php/File:AA_type-ins_issue24.dsk.zip (http://www.cpcwiki.eu/index.php/File:AA_type-ins_issue24.dsk.zip)
Quote from: litwr on 05:55, 13 July 14
Why to write Basic text under CP/M? IMHO it is more natural under AMSDOS. So it gives a theoretical question. Is it easy to convert open source program from CP/M to AMSDOS?
I forgot that CPC Basic unlike Commodore may use pure ASCII sources.
Because the editing tools are better, You can jump up and down between lines of code without needing to edit <line number> etc. I just used to modify my code as I went along, nine times out of ten I'd change the values printed to a menu or similar as I went along.
Using VDE meant I could just cursor up to the line and change it. Much quicker and easier than using Amsdos directly - although I admit you had to save and test separately so reloading time was a pain when bug shooting.
Craig
Quote from: Zoe Robinson on 08:43, 13 July 14
I'm a little late to this party but one of the early Amstrad Action type-ins was a decent text editor in BASIC. It's called "Text Editor" and it's on the issue 23 (September 1987) type-ins .DSK:
I've found another text editor from AA53 (February 1990) called
Swift Text Editor, which Swift Software also included with their game creation package
Pandora (http://www.cpc-power.com/index.php?page=detail&num=5286). I've even fixed a couple of bugs! :)
The attached DSK file contains the corrected version of the program (SWTEXT.BAS) and a version that has been modified to work in BASIC 1.0 (SWTEX464.BAS). There's a really weird bug in BASIC 1.0 where if you want to run or open some files, it sometimes uses the wrong filename. ??? But in any case, the program doesn't work all that well in BASIC 1.0 even after being fixed, especially if you're working with large text files.
Quote from: Nich on 18:40, 13 July 14
The attached DSK file contains the corrected version of the program (SWTEXT.BAS) and a version that has been modified to work in BASIC 1.0 (SWTEX464.BAS). There's a really weird bug in BASIC 1.0 where if you want to run or open some files, it sometimes uses the wrong filename. ??? But in any case, the program doesn't work all that well in BASIC 1.0 even after being fixed, especially if you're working with large text files.
Thank you! It looks good and has the help. :)
Quote from: CraigsBar on 18:36, 13 July 14
Because the editing tools are better, You can jump up and down between lines of code without needing to edit <line number> etc. I just used to modify my code as I went along, nine times out of ten I'd change the values printed to a menu or similar as I went along.
Using VDE meant I could just cursor up to the line and change it. Much quicker and easier than using Amsdos directly - although I admit you had to save and test separately so reloading time was a pain when bug shooting.
Craig
My point was other. I want just to RUN"VDE ;)
Quote from: litwr on 19:43, 13 July 14
My point was other. I want just to RUN"VDE ;)
I had a modified cp/m + vde start of day disk. So |cpm brought me straight to vde.
Craig
@litwr (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1057): For making
RUN"VDE, basically you are going to need a minimal cpm emulator (converting the cpm bios functions used by VDE to make the firmware and handle the ram paging as cpm does), but it's faster launch cpm and even more faster if you use the CPM+ roms, jejeje.
Quote from: CraigsBar on 19:57, 13 July 14
I had a modified cp/m + vde start of day disk. So |cpm brought me straight to vde.
It's a shame you haven't it anymore; i tried to install it, but now i have not patience for making the terminal configuration ;D
Quote from: SyX on 23:50, 13 July 14
@litwr (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1057):
It's a shame you haven't it anymore; i tried to install it, but now i have not patience for making the terminal configuration ;D
Still got it... Definitely. Still working.... Possibly. Take some time to find... Indeed. But I'll take a look tomorrow.
Craig
Quote from: Nich on 18:40, 13 July 14
I've found another text editor from AA53 (February 1990) called Swift Text Editor, which Swift Software also included with their game creation package Pandora (http://www.cpc-power.com/index.php?page=detail&num=5286). I've even fixed a couple of bugs! :)
The attached DSK file contains the corrected version of the program (SWTEXT.BAS) and a version that has been modified to work in BASIC 1.0 (SWTEX464.BAS). There's a really weird bug in BASIC 1.0 where if you want to run or open some files, it sometimes uses the wrong filename. ??? But in any case, the program doesn't work all that well in BASIC 1.0 even after being fixed, especially if you're working with large text files.
That program was such a pain in the butt to type-in and both times I typed it in on the 464 and it didn't work at all, so there's no way I'm going to check it out now. >:(
I typed in Amstrad Word Processor (http://www.cpc-power.com/index.php?page=detail&num=6146) from Your Computer, though I found when I was testing it the program makes it's own custom files which would probably discourage people from using it to view ASCII files.
Quote from: CraigsBar on 23:54, 13 July 14
Still got it... Definitely. Still working.... Possibly. Take some time to find... Indeed. But I'll take a look tomorrow.
Craig
Found it, DSK'ed it, Attached it
The VDE Start Of Day disk will set up drive B to be 80 track Double sided with EXTDISC.COM I cannot remember what disc format this needs (Possibly MS800) as I think it was before I had Parados installed.
I am sure if i were to still be using this I would format all my discs as ELECTRO formats with parados and use SETB.com instead. However since (after removing all the personal files) there are only 2 left, and those amount to less than 10k I don't think a high capacity 800k disc is needed LOL
Have fun with it.
Craig
Thanks CraigsBar!!! :D :D :D
It works really great in CP/M+, i'll try to configure it for PCW using your terminal configuration as the basis (although runs ok in PCW, better if i can use all the columns and rows and the PCW cursor keys).
I was searching for a nice text editor for PCW and this is the answer, thanks again :D :D :D
Quote from: SyX on 01:14, 15 July 14
Thanks CraigsBar!!! :D :D :D
It works really great in CP/M+, i'll try to configure it for PCW using your terminal configuration as the basis (although runs ok in PCW, better if i can use all the columns and rows and the PCW cursor keys).
I was searching for a nice text editor for PCW and this is the answer, thanks again :D :D :D
my pcw (a 9512+) is in its box in the loft. I never really found a use for it.
Quote from: CraigsBar on 23:15, 14 July 14
Found it, DSK'ed it, Attached it
The VDE Start Of Day disk will set up drive B to be 80 track Double sided with EXTDISC.COM I cannot remember what disc format this needs (Possibly MS800) as I think it was before I had Parados installed.
I am sure if i were to still be using this I would format all my discs as ELECTRO formats with parados and use SETB.com instead. However since (after removing all the personal files) there are only 2 left, and those amount to less than 10k I don't think a high capacity 800k disc is needed LOL
Thank you. I tried it and found that VDE is very smart. ;) However, I can't use it due to the problems with the emulators. `ep128emu' cannot attach this non-standard disk image, `arnold' doesn't allow to use several keys, e.g. the question mark - ?, the division sign - /, ... :( I work with Linux. Is there other good emulator for Linux?
Quote from: litwr on 12:11, 15 July 14
Thank you. I tried it and found that VDE is very smart. ;) However, I can't use it due to the problems with the emulators. `ep128emu' cannot attach this non-standard disk image, `arnold' doesn't allow to use several keys, e.g. the question mark - ?, the division sign - /, ... :( I work with Linux. Is there other good emulator for Linux?
the dsk images attached are standard. The start-of-day is system (to be bootable) the docs is data. If you want to remove the extdisc.com from the start-up, remove it from the profile.sub config file (edit that with VDE).
Craig
Quote from: litwr on 12:11, 15 July 14Is there other good emulator for Linux?
I always use an old version of wine and winape, but because i hadn't luck with JavaCPC, maybe it works right in your configuration.
Swift Editor cuts lines longer than 79 symbols. :( So it can't be used. VDE splits lines longer than 255 symbols, is inconvenient with long lines and CP/M only. So I've just converted Notepad+4 (http://plus4world.powweb.com/software/NotepadPlus4) for CPC (see also screenshots at http://litwr2.atspace.eu/notepad+4.html (http://litwr2.atspace.eu/notepad+4.html)). Notepad+4 can handle text with any line length. :P ;D So may be it is the unique for CPC world... I plan to compile it and to make the official disk soon. I hope it may be useful.
The pre-release disk is attached. RUN"NOTEPAD4 then CONTROL-H for help or CONTROL-L for load. Try to work with README.txt it contains line with about 600 characters.
BTW I've found that Locomotive Basic EOF statement can't detect end of file correctly at the every case. :( So
10 openin "file":line input#9,a$:print a$:if not eof then 10 else closein
sometimes works wrong - it adds lines with the garbage. I tried CP/M TYPE - it always works right. So AMSDOS has a bug in the EOF code.
Nice Editor! :)
For people not using protext in his romboard can be a good alternative :)
I have tested a little and the only minor bug i have found is if you left the cursor down pressed in the last row, the screen is refreshed continuously.
It's strange the Basic fail in the EOF, but i'm not a basic expert, maybe somebody can give more information. For example, i would make a more structured version of that code (but if EOF fail then nothing is fixed):
10 OPENIN "file.txt"
20 WHILE NOT EOF
30 LINE INPUT#9,a$
40 PRINT a$
50 WEND
60 CLOSEIN
Thank you for the kind words. :)
Quote from: SyX on 16:18, 20 July 14
I have tested a little and the only minor bug i have found is if you left the cursor down pressed in the last row, the screen is refreshed continuously.
I can't repeat this bug. IMHO the screen update is too slow, just use CONTROL-D/U to scroll Page Up or Down. Please try to repeat bug, press CONTROL-E to reach the end of a document then press cursor down...
I've found the nature of EOF bug. AMSDOS can't detect control code 26 (the end of text). So if the last line of text misses CR+LF then Basic's EOF fails.
Does protext work with lines of unlimited length?
Quote from: litwr on 17:25, 21 July 14
Thank you for the kind words. :) I can't repeat this bug. IMHO the screen update is too slow, just use CONTROL-D/U to scroll Page Up or Down. Please try to repeat bug, press CONTROL-E to reach the end of a document then press cursor down...
And i can not repeat again, surely i was mistaken by the slow screen update. If you need any assembly functions to accelerate your code, only ask, everyone will be glad in help with it :)
Quote from: litwr on 17:25, 21 July 14
I've found the nature of EOF bug. AMSDOS can't detect control code 26 (the end of text). So if the last line of text misses CR+LF then Basic's EOF fails.
Really interesting, must be basic related, because i never found in my assembly programs, where i call directly to the firmware functions.
Quote from: litwr on 17:25, 21 July 14Does protext work with lines of unlimited length?
Yes, without problems... but of course, it's one of the best CPC commercial programs ever, a full word processor that you can get it in ROM or floppy format. These days i only use it for small sources, when i need to test something fast (nothing can beat protext + maxam in rom, |P and you are working), but in the old days it was amazing and when i got my Amiga, i got the Amiga version too.
But as i said your text editor is really nice and a very good alternative, even tape friendly.
An example to show a file using the firmware calls:
ORG #9000
type_file
LD HL,file
LD B,(HL) ; filename length in bytes
INC HL
LD DE,#9100 ; 2 KB buffer
CALL #BC77 ; CAS IN OPEN
RET NC
loop_print_file
CALL #BC80 ; CAS IN CHAR
JR NC,exit_loop
CALL #BB5A ; TXT OUTPUT
JR loop_print_file
exit_loop
CALL #BC7A ; CAS IN CLOSE
RET
file
DEFB 10 ; Lenght of the filename
DEFB "README.TXT" ; filename
A basic list for putting in ram this code:
10 MEMORY &8FFF
20 FOR X=&9000 to &9000 + 25
30 READ A$
40 POKE x,VAL("&"+A$)
50 NEXT
60 END
70 DATA 21,1A,90,46,23,11,00,91
80 DATA CD,77,BC,D0,CD,80,BC,30
90 DATA 05,CD,5A,BB,18,F6,CD,7A
100 DATA BC,C9
And for using it, first you need to poke in &901A the lenght of the filename and the filename from &901B. After that, a CALL &9000 will show the file.
Quote from: SyX on 20:15, 21 July 14
And i can not repeat again, surely i was mistaken by the slow screen update. If you need any assembly functions to accelerate your code, only ask, everyone will be glad in help with it :)
I've just made scrolling in ML. So it should be as fast as in protext.
Quote from: SyX on 20:15, 21 July 14
Really interesting, must be basic related, because i never found in my assembly programs, where i call directly to the firmware functions.
Thanks. :) You are right - it is a bug in Basic. It is easy to repeat this bug.
10 openout "abc":print#9,"text";:closeout
20 openin "abc"
30 line input#9,a$:print a$:if not eof then 30 else closeout
Quote from: SyX on 20:15, 21 July 14Yes, without problems... but of course, it's one of the best CPC commercial programs ever, a full word processor that you can get it in ROM or floppy format. These days i only use it for small sources, when i need to test something fast (nothing can beat protext + maxam in rom, |P and you are working), but in the old days it was amazing and when i got my Amiga, i got the Amiga version too.But as i said your text editor is really nice and a very good alternative, even tape friendly.
Thank you! :) I've just test protext - I missed it at 80s. It is really good. However it works with unwrapped long lines (like VDE) - this is a bit inconvenient for me. I wanted a simple plain text editor without the print function.
Quote from: SyX on 20:51, 21 July 14
An example to show a file using the firmware calls:
Thank you very much! I've just tried it - its EOF works without any problem. But it is difficult to replace LINE INPUT and EOF with ML code because it requires to work with the string array (memory allocation, ...).
Quote from: litwr on 12:16, 22 July 14
I've just made scrolling in ML. So it should be as fast as in protext.
Well done! It's faster, now :)
Only a pair of remarks:
1.- Memory &A5FF is too high and in the moment you have a few roms or one taking too much ram as protext, you will get the "memory full" error. And as you assembly code doesn't use absolute address, you can use HIMEM for reserve ram for it. Like this:
start.cm=HIMEM-lenght_your_assembly_code
MEMORY start.cm - 1
Then put your routines in start.cm and they will be called with CALL start.cm and CALL start.cm + 27.
Even it will be better if you use that moment to reserve statically the buffer for AMSDOS files operations, instead of letting the Basic dynamically ask for one, every time you are going to read or write a file. Like this:
OPENOUT "fakefile"
start.cm=HIMEM-lenght_your_assembly_code
MEMORY start.cm - 1
CLOSEOUTFrom this moment, after your assembly code will be the Amsdos buffer used by the Basic. And before of your assembly code is all the space for basic code and basic variables.
2.- Again related with people using ROM expansions (very normal those days), the active disk drive is only PEEK(&A700) if there is not ROMs initialized before the AMSDOS rom. The most correct way is PEEKing the address storaged in $BE7D and $BE7E, like this PEEK(PEEK(&BE7E) * 256 + PEEK(&BE7E)).
Quote from: litwr on 12:16, 22 July 14
Thanks. :) You are right - it is a bug in Basic. It is easy to repeat this bug.
10 openout "abc":print#9,"text";:closeout
20 openin "abc"
30 line input#9,a$:print a$:if not eof then 30 else closeout
AMAZING!!! :)
Now somebody will can fix this bug :)
Quote from: litwr on 12:16, 22 July 14
Thank you! :) I've just test protext - I missed it at 80s. It is really good. However it works with unwrapped long lines (like VDE) - this is a bit inconvenient for me. I wanted a simple plain text editor without the print function.
Well, as Protext is more word processor than text editor, you need to define TABs and margins (if you run protext, by default it's that first line with >----! symbols). After that you go to the paragraph and you can press CTRL + F to format the text to that configuration. You can test easily loading your readme using "m README.TXT" for not delete the default rules and then CTRL + F.
Quote from: litwr on 12:16, 22 July 14
Thank you very much! I've just tried it - its EOF works without any problem. But it is difficult to replace LINE INPUT and EOF with ML code because it requires to work with the string array (memory allocation, ...).
Yes and your workaround works perfectly (i always add the extra line in every file, because in my university years the c compiler we used in the DEC Alphas complained everytime for the lack of an extra blank line ;D ;D ;D ) and the end of the day, if you start to convert string functions to assembly (or c), better convert the full program.
Quote from: SyX on 14:21, 22 July 14
Well done! It's faster, now :)
Is it possible to be faster? ;) IMHO maybe but it will cost days of work and give less than 20% speed up.
Quote from: SyX on 14:21, 22 July 14
Only a pair of remarks:
1.- Memory &A5FF is too high and in the moment you have a few roms or one taking too much ram as protext, you will get the "memory full" error. And as you assembly code doesn't use absolute address, you can use HIMEM for reserve ram for it. Like this:
start.cm=HIMEM-lenght_your_assembly_code
MEMORY start.cm - 1
Then put your routines in start.cm and they will be called with CALL start.cm and CALL start.cm + 27.
Even it will be better if you use that moment to reserve statically the buffer for AMSDOS files operations, instead of letting the Basic dynamically ask for one, every time you are going to read or write a file. Like this:
OPENOUT "fakefile"
start.cm=HIMEM-lenght_your_assembly_code
MEMORY start.cm - 1
CLOSEOUT
From this moment, after your assembly code will be the Amsdos buffer used by the Basic. And before of your assembly code is all the space for basic code and basic variables.
2.- Again related with people using ROM expansions (very normal those days), the active disk drive is only PEEK(&A700) if there is not ROMs initialized before the AMSDOS rom. The most correct way is PEEKing the address storaged in $BE7D and $BE7E, like this PEEK(PEEK(&BE7E) * 256 + PEEK(&BE7E)).
Thank you very much for this advice. :)
I don't think about such tricks. I used all this information but without fakefile - it is a bit difficult to me. I have to make more tests with this idea.Quote from: SyX on 14:21, 22 July 14
Well, as Protext is more word processor than text editor, you need to define TABs and margins (if you run protext, by default it's that first line with >----! symbols). After that you go to the paragraph and you can press CTRL + F to format the text to that configuration. You can test easily loading your readme using "m README.TXT" for not delete the default rules and then CTRL + F.
Agreed. Protext can't even save the plain text after CTRL-F. :(
I need you opinion. ;)
Should I stop with Notepad+4? Is it ready?I've changed LINE INPUT to the byte based input via ML-routine. This removed all problems but became slower. PEEK and POKE are very slow. :(
Quote from: litwr on 19:50, 22 July 14
Is it possible to be faster? ;) IMHO maybe but it will cost days of work and give less than 20% speed up.
Agreed :)
Quote from: litwr on 19:50, 22 July 14
Thank you very much for this advice. :) I don't think about such tricks. I used all this information but without fakefile - it is a bit difficult to me. I have to make more tests with this idea.
GREAT WORK!!! :D Now your program works perfectly with expanded CPCs :)
With respect to the "fakefile", i'm going to try to explain me better. "fakefile" is a not existent file, we open and close it, but as we never write anything in it, the file is not created in the floppy. It's only a trick for forcing the BASIC to reserve in a fixed memory address the buffer used for its file manipulations functions. Without this, every time the BASIC is going to access floppy (or tape), it will reserve this RAM dinamically from the high memory address available (HIMEM).
If we set this buffer in a fixed place, then we don't need to worry about a long text file (over 42 KBs more or less) could be overwritten with this buffer and you would lose the end of the text. It's an extreme case and you don't need to control it, of course, jejeje.
If you add this trick, the memory map of your program will be:
1.- $0170 - start.cm = Basic program and variables
2.- start.cm - start.cm + lenght_of_your_assembly_routines_for_scroll = Your assembly scroll routine
3.- After your assembly routine is the BASIC file operations buffer (takes 4 KBs if i remember well)
4.- Here start all the extra roms variables and firmware.
With this fix, you only will get a memory full, if the CPC hasn't enough ram for the text that your editor is manipulating.
Quote from: litwr on 19:50, 22 July 14
Agreed. Protext can't even save the plain text after CTRL-F. :(
I need you opinion. ;) Should I stop with Notepad+4? Is it ready?
The program is useful and works perfectly with expansion ROMs that reserve RAM from the system, more people should test it and give feedback, but yes, it's ready to be released.
Quote from: litwr on 19:50, 22 July 14I've changed LINE INPUT to the byte based input via ML-routine. This removed all problems but became slower. PEEK and POKE are very slow. :(
I forget to comment this, possible solutions to recover the loading speed would be:
Easy one, it's returning to the LINE INPUT version and we could made a minitool for fixing "bad text files" for Basic. New texts created with your program are correct and only bad old files need to be corrected.
More complex, we could load a full text line directly in a temporary string variable (those are limited to 255 bytes) and then use the basic string functions to put in the destination without use peek & pokes. We can get the memory address of a string variable using @string_var, this memory address contains the next: string lenght (1 byte) and pointer to the string (2 bytes).
Quote from: SyX on 20:54, 22 July 14
With respect to the "fakefile", i'm going to try to explain me better. "fakefile" is a not existent file, we open and close it, but as we never write anything in it, the file is not created in the floppy. It's only a trick for forcing the BASIC to reserve in a fixed memory address the buffer used for its file manipulations functions. Without this, every time the BASIC is going to access floppy (or tape), it will reserve this RAM dinamically from the high memory address available (HIMEM).
It looks a bit excessively tricky but I am going to use it. Locomotive Basic gives so little memory, only 38K at computer with 128K RAM... :( Commodore +4 with 64K RAM gives 60K for Basic.
Quote from: SyX on 21:47, 22 July 14
I forget to comment this, possible solutions to recover the loading speed would be:
Easy one, it's returning to the LINE INPUT version and we could made a minitool for fixing "bad text files" for Basic. New texts created with your program are correct and only bad old files need to be corrected.
More complex, we could load a full text line directly in a temporary string variable (those are limited to 255 bytes) and then use the basic string functions to put in the destination without use peek & pokes. We can get the memory address of a string variable using @string_var, this memory address contains the next: string lenght (1 byte) and pointer to the string (2 bytes).
There are no bad text files - there is a bug at Basic. ;) I've just found another Basic's bug.
10 for i=1 to 31
20 print chr$(24)"text "chr$(24)"text"
30 next
To work with the string memory allocation is too difficult, sorry. :o
There is the third way - compilation. I tried Fast (FABACO) and Laser compilers. They failed with Notepad+4. :( CPC Basic cross-compiler uses a bit different Basic - this will require a special branch of development. :(
I've just found a utility BPC which packs BASIC program and makes it slightly faster...
Quote from: litwr on 17:58, 23 July 14
It looks a bit excessively tricky but I am going to use it.
But it's not really a trick, it was documented in the second basic manual that came with the CPC in Spain and was used in a lot of tape games using a basic loader before loading the binary block with the turbo loader, jejeje.
Quote from: litwr on 17:58, 23 July 14
Locomotive Basic gives so little memory, only 38K at computer with 128K RAM... :(
Commodore +4 with 64K RAM gives 60K for Basic.
The problem is the basic was designed for the 464 :( , you can use easily the expansion ram for datas in your programs, it was typical in magazines publish RSXs list for making a better use of the extra 64 KBs, but the basic itself doesn't support it. And of course, the 16 KBs of RAM stolen by the screen makes a big difference, too.
Quote from: litwr on 17:58, 23 July 14
There are no bad text files - there is a bug at Basic. ;) I've just found another Basic's bug.
10 for i=1 to 31
20 print chr$(24)"text "chr$(24)"text"
30 next
Jejeje, it looks the bug is related when a scroll is made, even i you define a window (that use software scroll), the bug remains.
Quote from: litwr on 17:58, 23 July 14
To work with the string memory allocation is too difficult, sorry. :o
There is the third way - compilation. I tried Fast (FABACO) and Laser compilers. They failed with Notepad+4. :( CPC Basic cross-compiler uses a bit different Basic - this will require a special branch of development. :(
I've just found a utility BPC which packs BASIC program and makes it slightly faster...
I hope you have more luck with those compilers, i have not used any of them.
But for me is more easy use assembly, i can promise you that i have used more basic in this thread than in the rest of my CPC life, i learnt Z80 very soon and then my basic use was reduced to memory, poke, peek, call, load, save, ... because that, i always has problems using it, because i try to use more in a C way and always destroy the gosub stack :D :D :D
One of my crazy ideas was making a python rom for replacing the basic one, jajaja.
Wow, I like this topic! I was always interested in text editors and word processors for the CPC the whole life :) . It's cool, that you just ported and developed this editor so quickly!
Quote from: litwr on 19:50, 22 July 14
Is it possible to be faster? ;) IMHO maybe but it will cost days of work and give less than 20% speed up.
You can increase the speed a lot, if you use hardware scrolling (like Swift Text Editor does). In this case you could remove the status line -only- during scrolling (or use hardware screen splitting, but that's probably too much for the beginning). You will not need to use some massive LDIR stuff anymore, only change two hardware registers and plot the new text line. This and an optimized textoutput routine (example (http://www.cpcwiki.eu/index.php/Programming:Fast_Textoutput)) makes it possible to scroll text with full 50hz (and even much faster).
Also the CPC os uses hardware scrolling, if the current "text window" has the full size of 20/40/80 x 25 chars.
Btw, this editor for the CPC can also handle lines of "unlimited" length with and without wrapping :P
SymbOS Notepad test (Amstrad CPC) - the new Multiline Textinput Control - (https://www.youtube.com/watch?v=JfeIJmwv7QM)
(a final version will be released soon)
Poka,
Prodatron
I've just rewritten LINE INPUT by two ML-routine (44 and 19 bytes). I asked Basic to give memory by SPACE$ and used the created string. So there is no speed loss now. :)
Quote from: SyX on 22:54, 23 July 14
But it's not really a trick, it was documented in the second basic manual that came with the CPC in Spain and was used in a lot of tape games using a basic loader before loading the binary block with the turbo loader, jejeje.
4KB is too much to lose. So I've preferred not to use fakefile technology. The save procedure got a trap which caught the low memory case and issued the error message and the recommendation "just to erase several lines". :D
Quote from: SyX on 22:54, 23 July 14The problem is the basic was designed for the 464 :( , you can use easily the expansion ram for datas in your programs, it was typical in magazines publish RSXs list for making a better use of the extra 64 KBs, but the basic itself doesn't support it. And of course, the 16 KBs of RAM stolen by the screen makes a big difference, too.
464 has Basic v1 at 1984, but 6128 - v1.1 at 1985 - they might make several more updates... However Commodore Basic was not updated since 70s. The commercial ways stopped the obvious development. They needed GNU these days. :D GNU C++ compiler may be faster than Intel's!
Quote from: SyX on 22:54, 23 July 14But for me is more easy use assembly, i can promise you that i have used more basic in this thread than in the rest of my CPC life, i learnt Z80 very soon and then my basic use was reduced to memory, poke, peek, call, load, save, ... because that, i always has problems using it, because i try to use more in a C way and always destroy the gosub stack. :D :D :D
I can tell a "big" secret. Notepad+4 is my first Basic program for CPC. ;D I choose Basic by 3 reasons:
1) the original program was also in Basic;
2) build-in Basic is easiest tool after 25 years;
3) I wanted to compare Amstrad and Commodore Basics.
IMHO z80 assembler has less beauty. IMHO 6502 *smells* better - it is easy to translate z80 to 6502 but the reverse direction is a big headache. It is sad that 6502 was stopped by Commodore. So 8088 has won.
Quote from: SyX on 22:54, 23 July 14One of my crazy ideas was making a python rom for replacing the basic one, jajaja.
I prefer Ruby, C++, Prolog. ;) I don't understand why the quotes do not work sometimes... :(
Quote from: Prodatron on 00:57, 24 July 14
Wow, I like this topic! I was always interested in text editors and word processors for the CPC the whole life :) . It's cool, that you just ported and developed this editor so quickly!
Thank you. :)
Quote from: Prodatron on 00:57, 24 July 14
You can increase the speed a lot, if you use hardware scrolling (like Swift Text Editor does). In this case you could remove the status line -only- during scrolling (or use hardware screen splitting, but that's probably too much for the beginning). You will not need to use some massive LDIR stuff anymore, only change two hardware registers and plot the new text line. This and an optimized textoutput routine (example (http://www.cpcwiki.eu/index.php/Programming:Fast_Textoutput)) makes it possible to scroll text with full 50hz (and even much faster).
Also the CPC os uses hardware scrolling, if the current "text window" has the full size of 20/40/80 x 25 chars.
Video hardware acceleration! It is interesting. I can't even imagine how it is working. The speed of scrolling is not the problem, it is fast enough. Maybe in the future... Anyway thank you very much for this information.
Quote from: Prodatron on 00:57, 24 July 14
Btw, this editor for the CPC can also handle lines of "unlimited" length with and without wrapping :P
SymbOS Notepad test (Amstrad CPC) - the new Multiline Textinput Control - (https://www.youtube.com/watch?v=JfeIJmwv7QM)
(a final version will be released soon)
It will be interesting to try it. I prefer wrapped long lines. Can SymbOS Notepad handle long lines in this way? Can it use the final line without EOL marks?
Quote from: litwr on 14:44, 25 July 14
I've just rewritten LINE INPUT by two ML-routine (44 and 19 bytes). I asked Basic to give memory by SPACE$ and used the created string. So there is no speed loss now. :)
FANTASTIC!!! :D :D :D
Quote from: litwr on 14:44, 25 July 14
4KB is too much to lose. So I've preferred not to use fakefile technology. The save procedure got a trap which caught the low memory case and issued the error message and the recommendation "just to erase several lines". :D
That is a really good idea, jejeje.
Quote from: litwr on 14:44, 25 July 14
464 has Basic v1 at 1984, but 6128 - v1.1 at 1985 - they might make several more updates... However Commodore Basic was not updated since 70s. The commercial ways stopped the obvious development. They needed GNU these days. :D GNU C++ compiler may be faster than Intel's!
Yes, the main problem was the 6128 never replaced the 464 in the market, both machines lived simultaneously (and the firmware/basic rom was soldered to the main board :P ) and that always means for compatibility reasons the smaller machine was going to be the base machine for developers (similar like happened to the Plus 4).
Lucky for us, @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) made nice disassemblies of the Firmware, Amsdos and Basic rom and the new expansion boards help a lot to replace those more easy than the old days... now we only need to fix those bugs, jejeje.
Quote from: litwr on 14:44, 25 July 14I can tell a "big" secret. Notepad+4 is my first Basic program for CPC. ;D I choose Basic by 3 reasons:
1) the original program was also in Basic;
2) build-in Basic is easiest tool after 25 years;
3) I wanted to compare Amstrad and Commodore Basics.
Jejeje, i hope you have reached your goals, CPC is a nice machine and with a little of love can do a lot :)
Those days we have nice c compilers for z80 (sdcc and z88dk) or people like @Dinoneno (http://www.cpcwiki.eu/forum/index.php?action=profile;u=236) with his ccz80++ (http://ccz80pp.webcindario.com/ccz80pp-en.html) and @Trebmint (http://www.cpcwiki.eu/forum/index.php?action=profile;u=238) with his project Unify (http://www.cpcwiki.eu/forum/programming/project-unify/) are bringing moderm languages to the CPC, making a better platform for retro developing :)
Quote from: litwr on 14:44, 25 July 14
IMHO z80 assembler has less beauty. IMHO 6502 *smells* better - it is easy to translate z80 to 6502 but the reverse direction is a big headache. It is sad that 6502 was stopped by Commodore. So 8088 has won.
Jejeje, in my case is at contrary, Z80 is so pretty in every detail, i love use the maximum of Z80 instructions, moving the stack for filling structures fast or abusing OUTI or RLD or all that instructions for shiftting and rotating or the bit manipulation instructions... while when i code for 6502, everything is so boring with too much LDA and STA or the lack of 16 bits operations, forcing to use page zero variables for silly things than a z80 can do with closed eyes :P
I'm a really strange guy, i know ;D , but i would buy a C128, if the Z80 was not so limited and only for using the C64 custom chips from the Z80 side ;D ;D ;D I don't like the MSX/Master System VDPs way, coding in Z80 for the VIC II and SID would be superfun... Lucky for me, i always have the Gameboy for those moments, jajaja.
My favourites CPUs are 68000, arm and z80, in that order. After that, of course x86 is in the last place and in the middle must be 6809 and after it the 6502, with a few more before and after, jajaja.
Quote from: litwr on 14:44, 25 July 14I don't understand why the quotes do not work sometimes... :(
You need to end the quoted paragraph with [ / quote ]
Quote from: litwr on 14:44, 25 July 14It will be interesting to try it. I prefer wrapped long lines. Can SymbOS Notepad handle long lines in this way?
Yes, you can switch word wrapping on and off. If switched on, word wrapping may happen at the window border or at any pixel position (proportional fonts are supported). See the settings on the right side:
(http://www.symbos.de/gfx/preview/notepad2.gif)
Quote from: litwr on 14:44, 25 July 14Can it use the final line without EOL marks?
Yes, that means, that the cursor will stop at the end of the last line. If there is a CR+LF behind the last line, the cursor will stop below the last line - like it is in todays' text editors.
Notepad for SymbOS detects the EOF by 0 or 26. The Amsdos and CP/M file system has the limitation, that it can't handle files with a byte-exact length. The length is always 128byte aligned. Because of this binary files always have an additional 128byte header (which stores the exact length), while ASCII files need this 26-terminator (EOF). FAT and other file systems don't have this limitation, here you don't need to take care about the EOF anymore.
Sorry for delays - I had Holidays. ;D
I've just made a new thread for official Notepad+4 for CPC release - A new text editor for AMSDOS (http://www.cpcwiki.eu/forum/applications/a-new-text-editor-for-amsdos/)
Quote from: SyX on 17:40, 25 July 14
Jejeje, i hope you have reached your goals, CPC is a nice machine and with a little of love can do a lot :)
I have to say that Locomotive Basic is better than Commodore: much faster, better structure, ... Only EDIT and less memory annoy. ;)
Quote from: SyX on 17:40, 25 July 14
Jejeje, in my case is at contrary, Z80 is so pretty in every detail, i love use the maximum of Z80 instructions, moving the stack for filling structures fast or abusing OUTI or RLD or all that instructions for shiftting and rotating or the bit manipulation instructions... while when i code for 6502, everything is so boring with too much LDA and STA or the lack of 16 bits operations, forcing to use page zero variables for silly things than a z80 can do with closed eyes :P
I'm a really strange guy, i know ;D , but i would buy a C128, if the Z80 was not so limited and only for using the C64 custom chips from the Z80 side ;D ;D ;D I don't like the MSX/Master System VDPs way, coding in Z80 for the VIC II and SID would be superfun... Lucky for me, i always have the Gameboy for those moments, jajaja.
My favourites CPUs are 68000, arm and z80, in that order. After that, of course x86 is in the last place and in the middle must be 6809 and after it the 6502, with a few more before and after, jajaja.
* 6502 vs z80
z80 has very odd instruction set. I can even to say the most odd instuction set. ;)
z80 has a lot of "registers" but only one true register - A. All others has the functionality the same as 6502 zero page memory. I don't know other CPU with the register hierarchy: 1) A; 2) HL; 3) BC, DE; 4) IX, IY - at least 4 levels!
z80 has SET and RES instruction which duplicates OR and AND instruction. They didn't affect A but may be used to set/reset only one bit. It has no equivalent to 6502 BIT instruction.
z80 has no equivalent to TSX instruction that does not allow to use stack relative addressing.
z80 16-bit instructions are incomplete, e.g. DEC BC doesn't set Zero flag.
These and similar things allow me to say that z80 has less beauty. However z80 (like 8088) has better "political" support. BBC Micro and CBM II were blocked at USA market. 6502 was only allowed for the game computers. Commodore+4 is very similar to CPC464 but was stopped. Commodore 128 is the oddest computer showing the crisis of CBM. I can compare "political" situation between 6502 and z80 with the situation between Pascal and Java programming languages. Java won mostly by the hidden "political" reasons. :(
* 68000 vs 8086
68000 is good but it has several archaic traits. 8086 is also good and had better "political" support. I had Amiga 500 and know 80x86 assembler too.
You place 8086 after z80 - it is really very odd. ;D
Quote from: SyX on 17:40, 25 July 14
You need to end the quoted paragraph with [ / quote ]
It is not enough! >:( I should toggle the plain text mode and correct the markup manually. The automatic markup may produce wrong tags sometimes like [ [ font ..] quote ..]
Quote from: Prodatron on 11:35, 28 July 14
Yes, you can switch word wrapping on and off. If switched on, word wrapping may happen at the window border or at any pixel position (proportional fonts are supported). See the settings on the right side:
Yes, that means, that the cursor will stop at the end of the last line. If there is a CR+LF behind the last line, the cursor will stop below the last line - like it is in todays' text editors.
Notepad for SymbOS detects the EOF by 0 or 26. The Amsdos and CP/M file system has the limitation, that it can't handle files with a byte-exact length. The length is always 128byte aligned. Because of this binary files always have an additional 128byte header (which stores the exact length), while ASCII files need this 26-terminator (EOF). FAT and other file systems don't have this limitation, here you don't need to take care about the EOF anymore.
It looks like the perfect and ultimate text editor forever! :) I can only think that it has slow scrolling at the maximized window mode. ;) Do you plan to write something bigger like GeoWrite? :D
Quote from: litwr on 19:24, 05 August 14
These and similar things allow me to say that z80 has less beauty.
I'm sure most Z80 users would totally disagree, myself included. Apart from the lack of stack based indexing, which is only really necessary for compiled languages, I find Z80 much more usable and beautiful than 6502.
Second your POV :)
I've just tested SymbOS's Notepad. It is fantastically fast! :) I can't believe that this program running at CPU 100000 slower than CPU of modern PC. If such application was available for AMSDOS then I might not create Notepad+4. ;)
Quote from: litwr on 12:46, 09 August 14
I've just tested SymbOS's Notepad. It is fantastically fast! :) I can't believe that this program running at CPU 100000 slower than CPU of modern PC. If such application was available for AMSDOS then I might not create Notepad+4. ;)
Well but that is because the firmware print char routine is really slow and symbos is using this (http://www.cpcwiki.eu/index.php/Programming:Fast_Textoutput) ;)
Quote from: SyX on 17:51, 09 August 14
Well but that is because the firmware print char routine is really slow and symbos is using this (http://www.cpcwiki.eu/index.php/Programming:Fast_Textoutput) ;)
Every char has its own output routine! Unbelievable! SymbOS Notepad supports several fonts... There is so much work. :o
Haha, no, the mentioned textoutput routine is only used in SymShell, when it's working in fullscreen mode.
Notepad just uses the GUI textoutput of SymbOS (which supports proportional fonts and pixel-based clipping and positioning).
Quote from: Prodatron on 13:23, 10 August 14
Haha, no, the mentioned textoutput routine is only used in SymShell, when it's working in fullscreen mode.
Notepad just uses the GUI textoutput of SymbOS (which supports proportional fonts and pixel-based clipping and positioning).
:D OFFTOPIC. May I make a suggestion about SymbOS minesweeper? It misses ability to open the surrounding squares. It is very convenient to press on a number and to open its surroundings. BTW I press on the number 2 with 2 mines and several unopened squares around...
Yes, that saves some time. Double-clicking on a number should open all remaining fields around it. I will put it on the to-do list :)