[1/3] RC_2_22B.ZIP
ZXNet echo conference «real.speccy»
CMOS is not buggy - the settings are saved and the CRC is calculated.
PK> if the
PK> addresses of windows and text messages have changed, then the old version of DOCTOR
PK> 2.2
PK> will not work correctly. I plan to release the full version
PK>
PK> only together with RC AMP.
If things continue like this, then I’ll have to drag myself to the post office :)
[REAL ZX]
Wednesday March 27, 2002 22:39:54 Nikolaj Amosov -> Pawel Kislyak:
PK>> Beta version of Real Commander. Please test on
PK>> Scorpion
PK>> with SMUC CMOS and GMX, as well as on other computers on
PK>> subject
PK>> glitches with memory detection. Because in commander
NA> Tested on GMX + SMUC. No glitches with memory detection
NA> were detected - it was identified as Scorp and kicked the 8th jar.
NA> CMOS is not glitchy - the settings are saved and the CRC is calculated.
Please also add disabling file name checking
when copying, so that you can copy files with
the same names. Or even skip this check - imho
it is absolutely unnecessary.
[REAL ZX]
NA> Just add, please, disabling file name checking
NA> when copying, so that you can copy files with
NA> the same names. Or even stop this check - imho
NA> it is absolutely not needed.
This problem was solved back in versions 9x; earlier, when copying
a group of identical files, the commander (depending on whether they were the same size) either wrote them on top of each other, or
deleted and wrote another one. Now the search for existing files
on the receiving disk during the copying process is carried out only
to the area where new files begin, so identical files
are copied without problems.
In version 2.3, due to popular demand, it will also be possible
to add files
with the names of existing ones on
the receiving disk when copying.
Nikolaj Amosov ==========> Pawel Kislyak:
PK>> the addresses of windows and text messages have changed, then the old version
PK>> DOCTOR 2.2 will not work correctly. I plan to release the full version
PK>> only together with RC AMP.
NA> If this continues, then you will have to drag yourself to the post office :)
Well, if everyone trudges to the post office together, then in version 2.4
there will be a system of subdirectories, the structure has already been developed, RCDIR
unlike DirSys (Stanislav Yudin) there will be no use
additional disk space and, accordingly, will not have to
allocate another 5k of RAM to store information about directories.
RCDIR will use free space in the system
sector, directory names will be stored in the directory, so
the number of directories is limited to the maximum number
of files on one floppy disk - 128. Similarly, DirSys can
work with files using conventional TR-DOS tools, run Basic, etc.
Bye!
Pa...@nm.ru www.realsoft.hotbox.ru [RC 2.0] [Real Software]
PK>
PK> Well, if everyone trudges to the post office, then in version 2.4
PK> there will be a system of subdirectories, the structure has already been developed, RCDIR
PK>, unlike DirSys (Stanislav Yudin), will not use
PK> additional disk space and accordingly will not have to
PK> allocate another 5k of RAM to store information about directories.
PK> RCDIR will use free space in the system
PK> sector, directory names will be stored in the directory, so
PK> that the number of directories is limited to the maximum number of
PK> files on one floppy disk - 128. Similarly to DirSys, you can
PK> work with files using the usual TR-DOS tools, run Basic, etc.
And DirSys will supported?
WBR, Pawel.
30 Mar 02 00:36, Pawel Kislyak -> Nikolaj Amosov:
PK> Well, if everyone trudges to the post office, then in version 2.4
PK> there will be a system of subdirectories, the structure has already been developed, RCDIR
PK> unlike DirSys (Stanislav Yudin) will not use
PK> additional disk space
So I do not use additional space...
PK> and accordingly you will not have to
PK> allocate another 5k of RAM to store information about directories.
PK> RCDIR will use free space in the system
PK> sector, the names of the directories will be stored in the directory,
I don’t quite understand the idea. Where will the names be stored?
PK> so
PK> that the number of directories is limited by the maximum number
PK> of files on one floppy disk - 128. Similarly to DirSys, you can
PK> work with files using the usual TR-DOS tools, run Basic, etc.
Document just so that I can It would be nice to provide support for your
system or, at worst, a converter back and forth.
Stanislav
PK> This problem was solved back in versions 9x, earlier when
PK> copying
[ cut dick ]
PK> are copied without problems.
PK> In version 2.3 there will also be, by popular demand,
PK> the ability
PK> when copying to add files with the names of existing
PK> on the
PK> receiving disk.
That's what I meant. Again I didn’t put it that way :(
[REAL ZX]
PK> RCDIR
[cut dick]
That's it - I'm going to the post office. I'll just get a scholarship.
[REAL ZX]
30 Mar 02 00:36, Pawel Kislyak wrote to Nikolaj Amosov:
PK> Well, if everyone trudges to the post office, then in version 2.4
PK> there will be a system of subdirectories, the structure has already been developed, RCDIR
PK>, unlike DirSys (Stanislav Yudina) will not use
PK> additional disk space and, accordingly, will not have to
PK> allocate another 5k of RAM to store information about directories.
PK> RCDIR will use free space in the system
PK> sector, directory names will be stored in the directory, so
PK> that the number of directories is limited to the maximum number of
PK> files on one floppy disk - 128. Similar to DirSys You can
PK> work with files using the usual TR-DOS tools, run Basic, etc.
Will the file have time? Other attributes?
31 Mar 02 16:51, Stanislav Udin wrote to Pawel Kislyak:
SU> So I don’t use additional space...
How to transfer DirSys to another computer via MMD, EMS, MELON?
PK>> etc.
PS> Will DirSys be supported?
Yes, DirSys needs to be supported too. And then they created standards
you see...
[REAL ZX]
KF> Will the file have time? Other attributes?
yes, yes, what the hell are these directories needed on a disk with 128 files, time wouldn’t hurt at all (oh, I wish ACM would insert time into the source code...)
JTN/4D
KF> How to transfer DirSys to another computer via MMD, EMS, MELON
KF> ?
I think that this problem will affect not only DirSys, but also any other directory system attached to TR-DOS. And what about the offtopic, is it somehow
possible to transfer the structure of directories without packing? And if we are talking about packaging, then in this case you can transfer the cut TRD-shnik with DirSys...
Stanislav
PK>>> work using the usual TR-DOS tools, run Basic and
PK>>> etc.
PS>> Will DirSys be supported?
NA> Yes, DirSys needs to be supported too. And then they spawned standards
NA> you know...
At the moment, besides DirSys, I personally don’t know any other standards. Pavel
only plans to create standards. And IMHO he won’t support DirSys - he doesn’t have enough memory, that’s the only way I can explain the desire to create my own standard. On the other hand, DirSys, at a minimum, occupies only 2 sectors, that is, 512 bytes, and in this case can store information about the names of 22 directories, which is more than enough for a floppy disk. In RC, it would be possible to make an artificial
restriction on 22 directories per entry, and when reading the 23rd and subsequent
directories, assign generated names like Dir.001, Dir.002,..., Dir.nnn -
all information about sorting into 128 directories is included in these two sector.
The system is fully debugged and works in practice, this can be seen in the example of TRDN.
My system is already at least somehow widespread, in any case, local
spectrumists (including me) use it with pleasure.
It is not an unimportant fact that it exists offtopic plug-in to FAR. What does this give?
You can unpack an archive (RAR, for example) with directories on the PC and write its entire structure to the TRD image. You can enter the FDI image on one panelwith the
iS-DOS system, and on the other panel in the TRD image and copy the iS-DOS directories to TR-DOS.
I just transferred Open Letters by (C) Nemo from iS-DOS to TR-DOS.
Consider this propaganda for my system and not because it is ideal (and for me
it is), but because she is the only one so far and at least somehow supported. And, indeed, it is not good to create standards...
Stanislav
02 Apr 02 02:40, Vassili Klimov -> Kirill Frolov:
KF>> Will there be time for the file? Other attributes?
VK> yes, yes, why are these directories needed on a disk with 128 files,
Let me disagree with you. 128 files is not enough either! By catalogues
you can sort music, pictures, texts, sources, etc.
VK> that's time
VK> it wouldn't hurt at all (oh, if only ASM would insert time into the source codes...)
If you can manually stuff everything into catalogs or copy it from someone, then
who will set the file time for you? Is there at least one program that does this? Everything here should be at the operating system level. For TR-DOS it doesn't make any sense. You can, of course, set the time when copying a file,
but who needs it?
Stanislav
Bye!
Pa...@nm.ru www.realsoft.hotbox.ru [RC 2.0] [Real Software]
Bye!
Pa...@nm.ru www.realsoft.hotbox.ru [RC 2.0] [Real Software]
Bye!
Pa...@nm.ru www.realsoft.hotbox.ru [RC 2.0] [Real Software]
Bye!
Pa...@nm.ru www.realsoft.hotbox.ru [RC 2.0] [Real Software]
KF>> MELON ?
SU> I think that this problem will affect not only DirSys, but also any
SU> other directory system attached to TR-DOS. And what about the offtopic
SU> is it somehow possible to transfer the directory structure without packing?
Well, via FTP you can. The only thing here is that on PC directories are implied
initially,
but in tr-dos they are not there. For compatibility, all that remains is to store information about the directory
inside the file.
Otherwise, without your commander, nothing can be done with the directories. Even
COPY B (command
TR-DOS) most likely does not work as it should.
SU> And if we are talking about packaging, then in this case you can transfer the cut TRD-shnik
SU> with DirSys...
And if I need to transfer not the entire disk, but only one directory?
Would you suggest copying to another disk? Blank disks are in short supply, and the ramdisk
can’t fit...
02 Apr 02 09:50, Stanislav Udin wrote to Vassili Klimov:
SU> Everything here should be at the operating system level. For TR-DOS, not
SU> makes any sense. You can, of course, set the time when
SU> copying a file, but who needs it?
Communication software.
PK> Is it really necessary?
It should have been... 5 years ago.
PK> This certainly cannot be done without using additional
PK> disk space.
What are these directories for anyway? The existing software does not work with them, but there is no point in writing new
and no one will do it. The hardware must first
be upgraded, but it’s not clear in which direction.
PK>>> that the number of directories is limited to the maximum number
PK>>> of files on one floppy disk - 128. Similarly to DirSys, you can
PK>>> work with files using conventional TR-DOS tools, run Basic, etc.
PS>> Will DirSys be supported?
SU> At the moment, besides DirSys, I personally do not know any other standards
SU>. Pavel only plans to create standards. And IMHO it won’t support
SU> DirSys - it doesn’t have enough memory, that’s the only way I can explain
SU> the desire to come up with my own standard.
Personally, I have enough memory, I can set at least 1024k in the emulator ;), but
who has 128? Or even 48? But the commander almost fully
works on 48k, but you can’t open the RamDisk and you can’t load the modules.
Can your TRDN work on 48k?
SU> On the other hand, DirSys in my
SU> minimum takes up only 2 sectors,
For two directories there are already 4 ;)
SU> that is, 512 bytes and maybe store in
SU> in this case information about the names of 22 directories, which is more
SU> than enough for a floppy disk. In RC, it would be possible to make an artificial limit
SU> to 22 directories per write, and when reading the 23rd and subsequent directories
SU>, assign generated names like Dir.001, Dir.002,..., Dir.nnn -
SU> all information about sorting into 128 directories is included into these two sectors.
I don’t really like this idea.
It’s better to create more standards ;).
SU> The system is fully debugged and works in practice, this can be seen in the
SU> example of TRDN. My system is already at least somehow widespread, in any
SU> case, local spectromists (including me) with
SU> enjoy using it.
SU> It is not unimportant that there is a plug-in for FAR on the offtopic. What
SU> does this give? You can unpack an archive (RAR, for example) with directories on the PC and
SU> write its entire structure to the TRD image. You can enter
SU> into the FDI image with the iS-DOS system on one panel, and on the other panel into the TRD image and
SU> copy the iS-DOS directories to TR-DOS. I just transferred Open
SU> Letters by (C) Nemo from iS-DOS to TR-DOS.
This is of course a plus for your system. RCDIR is still only an
abstract idea, and its implementation will depend on the opinion
of registered users ;), so when sending a translation
you can write RCDIR or DIRSYS in the written message column.
Just think carefully about what you need - a more progressive
system that doesn’t consume additional resources or compatibility?
And you can write a system converter.
SU> Consider this agitation for my system and not because it is ideal
SU> (and for me it is), but because it is so far
SU> the only one and at least somehow supported. And, indeed, it is not good to produce
SU> standards...
Still, in my opinion, it was a mistake to use additional
disk space for directories. After all, directories are rarely needed,
mostly only on some system drives. Amemory and disk
space will always be reserved for them.
VK> yes, yes, why the hell are these directories needed on a disk with 128 files, now is the time
VK> it wouldn’t hurt at all (oh, I wish I’d inserted time into the source code...)
LET’S KICK CAPRY FRIENDLY ;))))))))))))))))))))))))))))))))))))))))))))
- Alone Coder [ZX-Guide] [AC Edit]
PK> I have a Stealth boot in this extra space on most disks
PK>.
It turns out that you don’t accept my system because of your boot... Of course, your
boot was written before my system. But if you think about it, it could be written to any other place, but DirSys is, as it were, part of TR-DOS and it would be more fair to give it to it locally. But even if you just can’t
give up the boot that you wrote, all the same, DirSys on all
disks without exception, most likely on those drives where DirSys will live (with music,
graphics, texts, etc.) no boot is needed at all.
05 Apr 02 08:09, Kirill Frolov -> Pawel Kislyak:
KF> What are these directories for anyway?
In other systems they are needed, but in TR-DOS “what for”? Let me disagree with you,
but directories are needed in TR-DOS too!
KF> The existing software does not work with them,
What in your opinion does not work? Any program for reading sees all files from directories, and in one of the next versions of TRDN it will be possible to make a choice of where to ship files from a running program:
1. To the directory from which the program was launched.
2. In a directory specified by the user (root by default).
Isn’t this the way all software supports directories?
KF> but there is no point in writing a new one and no one will do it.
You know, last week I had to explain to one person what to do
support directories in the map editor for a new game.
KF> Hardware
KF> must first be upgraded, but it’s not clear in what direction.
But this is absolutely not necessary... Everything works fine at 3.5 MHz
with 128 KB of memory.
Stanislav
SU>> is more than enough. In RC, it would be possible to make an artificial
SU>> limit on 22 directories per entry, and when reading the 23rd and
SU>> subsequent directories, give generated names like
SU>> Dir.001, Dir.002,..., Dir.nnn - all the information about sorting by
SU>> 128 catalogs are included in these two sectors.
PK> I don’t really like this idea.
Why so?
PK> It’s better to create more standards ;).
Or maybe it’s not worth it?
PK> This is of course a plus for your system. RCDIR is still only
PK> an abstract idea,
Please tell us in more detail about your idea. And by the way, from idea to concrete implementation is a big step. I, too, initially thought of everything in theory, but when it came to implementation, some inconsistencies became clear and I had to redo some things :)
PK> and its implementation will depend on the opinion
PK> of registered users ;), so sending a translation
PK> you can write in the written message column RCDIR or DIRSYS.
PK> Just think carefully about what you need - a more progressive
PK> system that does not consume additional resources
Let's argue on the topic of progressiveness! For the life of me, I cannot understand what is progressive about what you propose in comparison with my system. Give
reasons, and I'll give youtheir. In any case, DirSys does not take away a single file or sector from TR-DOS, and does not impose virtually any restrictions on the operation of standard programs, except for the MOVE command.
PK> or compatibility?
This is not an unimportant fact!!!
PK> Yes, and a system converter after all, you can write.
The converter, of course, is not a problem, but only the users
will suffer from the converter, in the sense that it will cause additional inconvenience. For example, they copied something there on the PC, taking into account the directories, and then before working with it on your commander (to be honest, most people use it)
you will have to go through the disk converter distill...
SU>> doesn't make any sense. You can, of course, set the time
SU>> when copying a file, but who needs it?
KF> Communication software.
For what?
Stanislav
VK>> yes, yes, what the hell are these directories needed on a disk with 128 files, so
VK>> time would not hurt at all (oh, I wish I had inserted time into the source codes
VK>>...)
I fully support it.
PK> Still, in my opinion, it was a mistake to use additional
PK> disk space for the
PK> directories. After all, directories are rarely needed
PK>,
PK> mostly only on some system drives. A
PK> memory and disk
PK> space will always be reserved for them.
For most disks, 22 directories are more than enough, while the system
uses only 2 sectors on the disk and does not impose restrictions on the number
of files.
Alexandr
[ZX]
KF>> side.
SU> But there is absolutely no need to do this... Everything is fine
SU> works at 3.5 MHz with 128 KB of memory.
TRDN also works at 48 KB.
Alexandr
[ZX]
VK>> yes, yes, what the hell are these directories needed on a disk with 128 files, time
VK>> wouldn’t hurt at all (oh, if only ASM would insert time into the sources...)
SU> It turns out that you don’t accept my system because of your boot...
What does mine have to do with it, not mine (but the author of this boot is actually Cyberex/RS),
it’s just convenient to use.
SU> Of course, your boot was written before my system.
Yes, there were a lot of boot files installed on the zero track, we used to
for example, we used the boot by Rezon Soft, then its slowness and lack of a mouse got in the way, they wrote their own.
SU> But if you think about it, you can write it in any other place,
SU> and DirSys is, as it were, part of TR-DOS and it would be more fair
SU> to give it to it locally. But even if you can’t refuse
SU> the boot that you wrote,
This is only a secondary reason, if I boot now, if I write
to disk, it’s only out of habit, since I have RC hanging in the ROM.
SU> still DirSys on all
SU> disks without exception, most likely on those disks where it will live DirSys (with
SU> music, graphics, texts, etc.) does not require any
SU> at all.
PK>> DIRSYS. Just think carefully about what you need - a more
PK>> progressive system without consuming additional resources
SU> Let's argue on the topic of progressiveness! For the life of me, I cannot understand
SU> what is progressive about what you propose in comparison with my
SU> system. Give your reasons, and I’ll give you mine.
Okay, okay, I’ve probably gone overboard with progressiveness ;)
SU> In any case, DirSys does not take away from TR-DOS a single file, nor a single sector, and does not impose practically any restrictions on the work of standard programs, except for the MOVE command.
Yes, the principles are the same in both systems, only in yours
an additional
7 unused TR-DOS sectors are used for directories and correspondence tables (except perhaps only when you press Magic;),
and in mine directories are created as empty files, which accordingly
reduces the maximum number of files stored on the disk.
PK>> or compatibility?
SU> This is not an unimportant fact!!!
The path of compatibility is not always the right path.
AK> If I understand correctly, then this progressive system allows you to have
AK> only 128 files and directories on disk, i.e. standard restrictions
AK> TR-DOS are being tightened. This imho is not good. I have a lot of disks with
AK> ~120 files and a bunch of directories.
But in most cases, you may need to create
only 3-4 directories. And for these 3-4 directories, I think it is better to
sacrifice 3-4 files than to use another 7 (2) sectors.
VK> what do I need? will you order us to go to rst??
It’s enough to simply decompile TASM with Inozemtsev’s disassembler...
Where do you think Capry got the ALASM source code? ;))
VK> what do I need? will you order to go to rst??
Do you think you will find him?:)
C uv.Maxony latyshm(at)mail.ru
PK>>> I’ll document it, of course, if I do.
SU>> Or maybe DirSys? Huh?
SU>> users will suffer, in the sense it will cause additional
SU>> inconvenience. For example, they copied something there on the PC with
SU>> taking into account the directories, and then before working with it on your
SU>> commander (to be honest, most people use it)
SU>> you will have to drive the disk through a converter...
PK> At first you will have to, of course, but in the end one of the
PK> systems will take a dominant position.
As soon as the corresponding software appears on the PS, for now it is not available on your system,
in fact, like the system itself.
PK> Due to the fact that you would create 3-4 directories on the disk and scatter some stuff across
PK> them music, texts and pictures need to be used
PK> as many as 7 sectors. Isn't it better to sacrifice the number of
PK> files?
Error! Not seven, but only two sectors!!! The system grows from bottom to top; it does not need all seven sectors. Up to 22 directories, for full-fledged work, 2 sectors are quite
enough!
PK> I understand that users are confused, how am I going to get out of
PK> with this memory, as long as it works as it should, but even if the free buffer in the
PK> command is small, then most users
PK> do not have PK> in their computers memory over 128k will not use this
PK> commander. I think that with the RC 2.0 ideologyso some percentage
PK> of users remained on RC 1.96. In principle, I can make DirSys,
PK> y I have a place in the 0th bank, so the system will work on
PK> 48k.
Oh! See the positive notes :)))
PK> Then the buffer will be about 70 sectors.
Hey, God be with him, no one copies anything in 48K anyway!
Stanislav
ML> Do you think you will find him?:)
where is he right now?
Sincerely, Vadim.
... [ silence ]
VC> where is he right now?
Yes, he drinks from time to time while working :) You can catch him at home if you call at 6.00
in the morning, otherwise there’s no other way :)
C uv.Maxony latyshm(at)mail.ru
DB>>> LET’S KICK CAPRY FRIENDLY ;)))))))))))
VK>> what about me? will you order me to go to rst??
PK> of users remained on RC 1.96.
it’s difficult to relearn space<>M, can you still change it?;) So I’m used to using Graph
to select, and using the space bar to switch masks...
JTN/4D
PK>> Let's see what users say.
PS> RC + DirSys + 512x192 !
Our man! :)
Stanislav
VK> is breaking to relearn space<>M, can you still change it?;)
VK> I’m so used to highlighting with Graph
VK> and using the space bar to switch masks...
Exactly, exactly...
[REAL ZX]
PS>> RC + DirSys + 512x192 !
SU> Our man! :)
Yeah, and also make sure that when identifying SMUC and the screw connected to it,
work with partitions and disk images as with directories.
Then it will be really cool!
All the best, Pawel!
With best wishes *** Sergey ***
VK> I won’t go for anyone, but if you go for cbspeccy, then maybe for
VK> company and grab the source codes ;-) ?
So we’ll also have to give him another case of beer :) That’s how much the rst
sorts cost :) But we can grab it :)
C uv.Maxony latyshm(at)mail.ru
PK>>>>> I’ll document it, of course, if I do.
SU>>>> Or maybe DirSys? Eh?
PK>>> Let's see what users say.
PS>> RC + DirSys + 512x192 !
PS> RC + DirSys + 512x192 !
I remember three years ago there was such a project - File manager. Something like a DOS
navigator for 512x192. I liked it. (Dreamy) if only RC looked like this.
By the way, I can throw some software here for 512x192.
ACEdit58 - text editor. Unambiguous rulez.
FM_1_0 - file shell. There is a text reader in different encodings and
FM_1_0 formats and something else. Wants 512 KB of RAM. There are bugs in the questionnaire
FM_1_0 keyboard, due to which half of the functions do not work. I tinkered with
FM_1_0 - Hobeta and UUE worked, then I got tired of it.
VIEWER85 - a very old, but good reader.
ANSI0.2 - ANSI player. Supports a bunch of video modes.
gif_src pkunZIP - shows comments to the archive in 512x192. Cool. LC 4.5 - well, it's a classic. Fidosh editor/tosser. Something like a bundle Melon1.80 - terminal and mailer in one bottle. Why so little? Well, send it. * Original written in REAL.SPECCY WBR, Jason. _[Team Death metal] [Team Obituary] [Team Friday 13th] [Team Huge Axes]_ /np:/*silence*
LC 4.5 GoldED + FastEcho + UUWizard on the PC.
* also sent to ZX.SPECTRUM
* also sent to KHARKOV.SPECTRUM
PK>> to get away with this memory, as long as it works as it should, but also
PK>> if the free buffer in the commander is small, then the majority of
PK>> users who do not have memory in their computers over 128k will not
PK>> use such a commander. I think that with the ideology of RC 2.0
PK>> some percentage of users remained on RC 1.96. In
PK>> I can, in principle, make DirSys, I have a place in the 0th bank, so
PK>> the system will work at 48k.
SU> Oh! See the positive notes :)))
Okay, okay, I think users will still vote for DirSys :)
VK> is breaking to relearn space<>M, can you still change it?;) I’m so used to
VK> Using a graph to highlight and using a space bar to switch masks...
I think there’s no point in twitching and changing something back.
I can only make additional markings with a graph,
and the on/off switch for the information panel will remain on the combination
SS+i (in RC 2.3 it was changed to SS+l). What will the public say about this?
Yes, by the way, regarding 32k ROMs for Profi, I can do
without any problems so that in the first 16k only the
commander is stored (from there it starts and the bank will no longer be needed)
and in the second 16k modules are stored (this bank will be flashed
in place of 128 BASIC).
Bye!
Pa...@nm.ru www.realsoft.hotbox.ru [RC 2.0] [Real Software]
PK>>>>>> I’ll document it, of course, if I do.
SU>>>>> Or maybe DirSys? Eh?
PK>>>> Let's see what users say.
PS>>> RC + DirSys + 512x192 !
SU>> Our man! :)
SU>> Our man! :)
SC> Yeah, and also make sure that when identifying the SMUC and the screw connected to it
SC>, it works with partitions and disk images as with directories. Then
SC> it will be really cool!
TRDN plans to make such a mode, although it is unknown when I will get around to
this...
Stanislav
VK>>>> time
VK>>>> it wouldn’t hurt at all (oh, I wish I had inserted time into the source code
VK>>>>...)
DB>>> LET’S KICK CAPRY FRIENDLY ;)))))))))))
VK>> what do I need? will you order me to go to rst??
VK> ACEdit58 - text editor. Unambiguous rulez.
there is already a much newer version;)
VK> FM_1_0 - file shell. There is a text reader in different encodings
VK> FM_1_0 and
VK> formats and something else. Wants 512 KB of RAM. There are
VK> bugs in the keyboard questionnaire, due to which half of the functions do not work. I dug into it -
VK> Hobeta and UUE started working, then I got tired of it.
oh! necessary, let's go straight to the echo
JTN/4D
SU> Alas, on 512x192 we have no memory, and secondly, none of us have
SU> such a mode, and the program is written exclusively in real...
put it on a 48k computer and make the 2nd screen work - a lot of space will be freed up in the main memory
you can insert all sorts of useful features there. It is hardly advisable to use
the first screen, and even with 512*192 - there is very little main
memory left.
JTN/4D
SC>> Yeah, and also make sure that when identifying the SMUC and the screw connected to it
SC>>, it works with partitions and disk images as with directories. Then
SC>> it will be really cool!
SU> Alas, we have no memory on 512x192, and secondly, none of us have any
Everyone says so, but they write here exclusively from goldeds and the software is launched in
emulators...
It is impossible to exit from TRDN to DOS.
SU> Alas, we don’t have memory at 512x192,
We have to look! ;)
SU> and secondly, none of us
SU> has such a mode,
Well, go ahead.. Soldering iron in hand, and getting a circuit is not a problem.
SU> and the program is written exclusively in real...
Well, at worst, if everything is so hopeless and 512x192 does not shine on the spec, then
it’s possible do something like select modes (normal or advanced)..
Write advanced under the emulator.. (well, or write a module to support this
mode).. It will be cool....
WBR, Pawel.
PK> In the commander itself, 512x192 does not make sense,
Why is that??? More files and directories will fit in.. And in general, you can
make just 2 modes - normal (which already exists) and 512x192, which
doesn’t exist yet.. You can do this in the form of drivers for the commander (in case
another video mode appears, just write/connect another driver). In my opinion, it would
be great...
PK> especially since this is a b/w mode,
Whoever doesn’t like the black/white mode can work in normal, color mode.
PK> unless you can
PK> viewer be made for this resolution...
And the viewer can be made as a separate program loaded into memory from
disk\hdd when the user wants to view something.
PK> P.S: don’t forget to duplicate your choice on the receipt of the postal
PK> transfer ;)
Let’s see which will be cooler (you may have to take both) :)))
WBR, Pawel.
PK> Let's see what users say.
DirSys with 22 directories or nothing
Although, first you need to familiarize yourself with the docks according to your format ;)
How is the problem of Move and adding a file solved?
2SU: CRC in vain :(
- Alone Coder [ZX-Guide] [AC Edit] [PT3.53m]
NA> Exactly, exactly...
It’s strange, but I prefer to mark with a space and switch the M-mask...
Only selecting the drive in the sub with letters rather than numbers is unfortunate :(
In general, I would like controls similar to Perfect, Monster and all that :)
ML>> Do you think you’ll catch him? :)
VK> I won’t go anyway, but if you go for cbspeccy, then maybe for
VK> company and grab the source code ;-) ?
SU>>> Or maybe DirSys? Eh?
PK>> Let's see what users say.
PK> I think there’s no point in fussing and changing something back.
But there’s probably nothing complicated (changing two bytes of
button codes), so why not do what has been customary for a long time?
PK> I can only make additional markings with a graph,
PK> and turning on/off the information panel will remain on the combination
PK> SS+i (in RC 2.3 moved to SS+l). What will
PK> the public say about this?
I somehow don’t care what button it will be on, because... I have never used this panel yet. And if I need to use it, I will press any button offered. The only bad thing is that these same buttons often change and you need
to relearn.
[REAL ZX]
SU>> us
KF> Everyone says so, but they write here exclusively from Goldeds
I’m really writing from GoldEd because firstly, I’m writing mostly from work,
secondly, whatever one may say, but it’s easier to do it offtopic, and thirdly, I don’t have a modem for
Spec subbed.
KF> and software
KF> run in emylators...
But I run the software exactly in real life!
KF> You can’t exit from TRDN to DOS.
There is such a bug. Will be corrected.
Stanislav
PS> Well, at worst, if everything is so hopeless and 512x192 on the spec
PS> does not shine, then you can do something like select modes (normal or
PS> advanced)..
See. above.
PS> Extended write under emylem..
I don’t know how to write under emylem: the keyboard is not comfortable, it’s inconvenient to work with a “floppy disk”, the image is crap, etc.
PS> (ny, or a module
PS> write to support this mode)..
C I can hardly imagine how such a module can be implemented...
PS> It would be cool....
Yes, if it were, it would be cool.
Stanislav
PK> I think there is no need to twitch and change anything back.
PK> I can only make an additional marking with a graph,
PK> and the on/off switch of the information panel will remain on the combination
PK> SS+i (in RC 2.3 it was changed to SS+l). What will the public say about this? will be needed)
PK> and secondly 16k modules were stored (this bank will be flashed
PK> in place of 128 basic).
it seems to me that the commander should still be located instead of basic 128 because many
progs come out in 128basic. Let the public argue in favor of your
option or support mine;). By the way, I have 8 ROM cans of 16k each and
you can connect any one.
JTN/4D
VK> it seems to me that the commander should still be located instead of the basic128 because
VK> many programs come out in 128basic.
You can patch the basic so that when you turn on the computer it
loads boot from tr-dos, and when you press reset it launches the commander from the
shadow bank. And in the commander, provide access to BASIC-128. Still
in BASIC-128 there is a human editor for BASIC files.
PK>> Let's see what users say.
DB> DirSys with 22 directories or nothing
DB> Although, first you need to familiarize yourself with the docks in your format ;)
DB> How is the problem of Move and adding a file solved?
DB> 2SU: CRC in vain :(
You about non-standard CRC? I agree. I used the CRC calculation program, taken from ZX-Review. At that time I did not know that this procedure was non-standard.
You can, of course, do, for example, DirSys v1.01, where you can calculate CRC-16 or
CRC-32, However, in this case, compatibility will suffer (FAR plug-in)... I already thought about this. It seems to me that it is better to leave everything as it is. The CRC calculation subroutine is not so big.
Stanislav
SU> We have already used all our reserves. There is just enough memory left to fix all the glitches and bring the viewer and work with the hard drive to perfection. Everything else only detracts from the commander’s performance in
SU> 48th mode.
Why do you need the commander to work on 48k specs??? Even if there are people like this now, then IMHO they don’t need this commander there. You need
focus on more serious cars.
SU> Besides, in order to make the 512x192 mode, you need
SU> to shovel half of the commander.
Well, in order to make the RC two-panel, PK shoveled it.. And it didn't
break :)
SU> Much It would be easier to write
SU> all over again.
Well... If nothing comes of it now and then you have free time and the desire
to do something, then maybe write.. :)
SU> Of course, from the user's point of view it would be great
SU> to be able to switch between standard and extended
SU> mode. But from a programmer's point of view, the game is not worth the candle... For the same
SU> reason, I cannot support the mouse.
The mouse is not the main thing..
DB> and what should be output in 512x192? (note: b/w, at best
DB> backlighting of entire lines!)
And I’m not saying that this mode is ONLY... It must be done so that you can select.
WBR, Pawel.