@Pin: udało mi się to odtworzyć, nie wiem tylko, czy się coś z tym sensownego zrobi, bo tak na oko przyczyną może być za długa ścieżka dostępu. Popatrzę, może da się to jakoś obejść.

@w1k: SDX has ARC archiver built-in, so I can't see how such an archive may be difficult to unpack.

Zobacz zatem, czy to działa (bo SOA#1). Z nowości tylko aktualizacja "KB free" podczas kopiowania.

EDIT: archiwum uaktualnione (wymieniłem SC.COM).

Z tego, co widzę, nieprawdą jest, jakoby :P Żeby tak było, jak piszesz, uruchomiony program musi zrobić reset - to wyłącza 80-kolumnową konsolę.

Albo może powiedz bliżej, jakie czynności mam wykonać, żeby odtworzyć ten efekt u mnie.

SC stara się utrzymać ustawienia konsoli takie, jakie były przy pierwszym uruchomieniu.

Powinno wystarczyć, jeśli dorzucisz do niego CON.SYS.

A ty myślisz, że różne rodzaje ramek, jakie były wpisane w dystrybucyjny SC.INI, czym innym zrobiłem, jak nie ED-em? :P

Sprawdziłem na szybko, u mnie działa. Upewnij się, że plików źródłowych nie ma aby w katalogu docelowym - jeśli są, zostaną pominięte.

To chyba nie spowoduje dużej straty czasu, zobaczę.

No to już nie jest takie trywialne, bo oznacza rekursywny skan katalogu. Pomyślę.

Wszystko w swoim czasie :P

In fact, the screen redraws are nearly 2,5 times faster with S_VBXE than with RC_GR8.

Let's assume that "256" looks vaguely familiar and I can imagine where it was picked from :P The question was different: if already such a number of files per directory is to be handled, why not one more? There is no such limit in SpartaDOS, so why the user has to keep a cautious eye on not copying certain numberof files to a directory, especially if a much greater number is allowed? And if he does copy a 257th file, what then?

A file manager's purpose is to facilitate maintaining of the file system. Large directories are most difficult to handle, yet I have to deprive an user of this assistance just to amuse him with sorted directories? Well, I don't think so.

So let's assume that. But this is a scroll, so one place must be filled with new entry. This involves reading it from the disk - and not necessarily the one, which physically is immediately following the last displayed entry - then formatting it, then displaying. So, it of course will always consume more CPU time than simple cursor movement, without a scroll.

As for the scrolling speed, for starters I would suggest to compare not with the NC running on a 486, but with ICD's MENU - which, by the way, has only 10 lines to scroll, not 20.

When writing such a file manager for 8-bit compromises must be done between speed, limits imposed on the file system, and the amount of remaining free memory for operations such as copy. I choose not to impose arbitrary limits on directory length (256 files? Ok, why not 257?) and make as much memory free for copying buffer as possible. And I am not so sure that I've done this at speed compromise. Of course, with VBXE the blitter can be used to copy the screen contents (and this is planned), which will probably add some speed to the scrolling, but I suspect that it won't add as much as some of you  (Candle) might expect, because scrolling up/down the actual screen contents is not the only thing involved in the process.

5888 bytes * 2 panels = 11776 bytes. That's waste of RAM. Current code requires slightly less than 2k in memory to handle directories without any additional limit.

Zaczynam rozumieć miłośników MagiC-a - co prawda miał kupę błędów i wywalał się co 10 minut, ale za to szybko rysował okienka :P

Poprawka do błędu zgłoszonego przez Pinokia plus drobiazgi.

EDIT: p. niżej

Ad szybkie wyszukiwanie: widzę, że jest to w TC, ale nie bardzo wiem, co ma robić. Z uwagi Candle wnoszę, że ta funkcja, żeby działała zgodnie z oczekiwaniami, wymaga posortowanego katalogu. Opisz, co ma robić, zastanowimy się.

Ad wbudowana obsługa ARC: listowanie archiwum i ekstrakcję plików powinno się dać w miarę bezboleśnie zrobić, z pakowaniem może być gorzej, ale jeśli nie masz na myśli dorzucana plików do istniejącego archiwum (otwieramy archiwum i wkopiowujemy pliki), a tylko takie pakowanie jakie jest np. w TC (wjeżdżamy na katalog i dajemy archiwize), to powinno się dać w miarę prosto zrobić. W pakowanie wybiórcze zaznaczonych plików mocno powątpiewam :)

All of them in either directory. Even one directory would require 32k of RAM to be sorted, whereas with SC loaded there's only about 25 KB left.

Pin: no tak... błąd poprawię, kiedy wrócę do domu.

Uhm. Ale przynajmniej jedną sprawę powinno być łatwo załatwić: wpisujesz SORTDIR : i masz posortowane.

SC póki co nie będzie sortował katalogów, bo do tego trzeba takowy w całości do pamięci wczytać. A 2x32752 bajty = za dużo, trzeba byłoby do dodatkowego RAM-u je ładować (może kiedyś).

Dzięki, sam tego nie zbuduję, ale może uda mi się kogoś namówić.