Looking for 2 unused cells in CMOS
ZXNet echo conference «real.speccy»
So what’s the matter, I want to make Real Commander remember
the position of the cursor in the directory, sometimes you dig through your software archives
and after each reset again look for the program you stopped on,
and there are 50-70 of them on the disk. And so a wild thought came to mind ;),
why not devour two more cells from CMOS to save the position?
Anyway, most people don’t use CMOS memory (with the exception
perhaps of the Scorpion computer), and the convenience of such a feature would be considerable.
So the subject! One cell is needed for the actual position in the directory, and the second for the checksum of the directory of the current disk. Also a question -
is it necessary to add an item to SetUp for this purpose, which will consume
additional memory, do not forget that the commander must have
the minimum size to fit in a rom with 2-3 useful modules.
If there is no answer, cells with numbers #16, #17 will be used.
At the same time, other proposals for improving the commander will be considered.
* Crossposted in ZX.SPECTRUM
Bye!
void Real_Software (pa...@nm.ru, www.realsoft.hotbox.ru)
Hello, Pawel!
12 Apr 03 14:00, Pawel Kislyak -> All:
PK> So the subject!
Indicate their addresses in the setup.
Or in the doc describe at what offset in the file they can be corrected...
With respect, Evgeniy.
April 12, 2003 (and it was then 2:00 pm)
Pawel Kislyak in his letter to All wrote:
PK> So what’s the matter, I want to make Real Commander remember
PK> the cursor position in the directory, sometimes you dig through your software archives
PK> and after each When resetting, again look for the program you stopped on,
PK> and there are 50-70 of them on the disk.
In Vega Commander, I did this by writing information to disk. But it was easier for me: the commander only works with the propeller. Nevertheless, I advise this option
(disabled) - not everyone has CMOS. And for people with a screw, such saving
will pass unnoticed over time.
Vega/ex-Style Group.
FIDO: 2:5030/1243.18 ZXNET: 500:812/19 E-mail: veg...@mail.ru
PK>> remembered the position of the cursor in the directory, sometimes you dig through your
PK>> software archives and after each reset again look for the program on the
PK>> that stopped, and there are 50-70 of them on the disk.
VS> In Vega Commander I did this by recording information on disk.
I thought about this option, but there is a danger of spoiling
in this way some information in the system sector in a log
or game on an entire disk, although in general they can be physically protected from writing.
VS> But for me
VS> it was simpler: the commander works only with the screw. Nevertheless, I advise
VS> this option (disabled) - not everyone has CMOS. And for people with a
VS> screw, such a save will go unnoticed over time.
For Fdd, in principle, this will also be practically unnoticeable, I’ll probably do that
and you saved at what offset in your commander? How many
bytes and their purpose?
PK> For Fdd, in principle, this will also be practically invisible, I’ll probably do that
PK>, and what offset did you save in your commander? How many
PK> bytes and their purpose?
IN THE FILE.
--
[ZX]
PK> I thought about this option, but there is a danger of spoiling
PK> in this way any information in the system sector in the log
PK> or the game on the whole disk, although in general they can be physically protected from
PK> writing.
Yes, with disks it is more difficult... But you see what the focus on floppy disks led to: you ended up with a cumbersome modular system when modules cannot be unloaded from memory. Wildly inconvenient. But an overlay system would allow
to insert an unlimited number of tasks into the commander...
P.S. Yes, the purpose of the bytes: as I remember - the current subpartition and disk for each of the two panels, the position of the cursor in the panel, the position of the mouse arrow. The ideology
was this: to make an “instant snapshot” of the program at the moment of exiting it. I gave up the resident system, and wanted to do the following on Skorpa: the user starts the program, then presses reset - autoload, and he sees the commander in front of him in exactly the same form as at the moment the program was launched. A la Windows. Eh! Dreams, dreams... I never fully realized all my ideas...
It’s good, at least partially. And now Vega Commander is outdated. If you do, then do
everything, everything else...
each of
> two panels, the position of the cursor in the panel, the position of the mouse arrow.
The idea
> was this: to make an “instant snapshot” of the program at the moment of exiting it.
I
> refused the resident system, and wanted to do it on Most likely the following:
> the user launches the program, then presses reset - autoload, and he
sees
> the commander in front of him in exactly the same form as at the moment of launch
the program. A
> for Windows. Eh! Dreams, dreams... I never fully realized all my
ideas...
PK>> thus spoil any information in the system
PK>> sector in a magazine or a game on an entire disk, although in general they can be
PK>> physically protected from writing.
VS> Yes, with disks it’s more difficult... But you see what this has led to
VS> focus on floppy disks: you ended up with a cumbersome modular
VS> system when modules cannot be unloaded from memory. Wildly inconvenient.
At least I didn’t experience any inconvenience from this, so why
unload them? This is not an OS after all; after launching the program, the commander is still overloaded. Yes, right now there aren’t enough modules
to fill at least 128 memory.
VS> But the overlay system would allow you to insert an unlimited number of tasks into the commander
VS>...
Well, modules that are most often needed one-time can
be written non-resident.