Started by OffseT, 15:51, 24 January 21
0 Members and 1 Guest are viewing this topic.
Quote from: m_dr_m on 15:46, 28 April 21It's quite disturbing to see the X-Mass active for each floppy access. Makes you wonder if the right drive is selected.
Quote from: m_dr_m on 15:46, 28 April 21@Offset Fair enough! What about doing the switch gymnastic only at drive change?E.g.:|A <- Backup Unidos, put Amsdoscat <- No NVRAM accesscat <- No NVRAM access|B <- Restore Unidos.
Quote from: m_dr_m on 12:36, 02 May 21Request:* |MKDIR alias for save"toto/" which would give back control (if I try to create a directory via save in BASIC, it stops the program)* |CD alias for load"dir" (same reason + uniformity with other DOS)
Quote from: m_dr_m on 13:53, 01 May 21E.g.: automatically do |disc before, |dos after?
Quote from: m_dr_m on 12:36, 02 May 21On the other hand, |PATH doesn't do any access? That's sweet, but that indicates you store it in RAM? Isn't that wasted space? Also, limits max length of path. Candy (and maybe others) did a nice thing: keep a pointer (32 bits) to the current dir, and reconstruct the path recursively from here. Since we don't need to display the path often (actually, only if it changes), the extra accesses aren't bothering.
Quote from: m_dr_m on 12:36, 02 May 21Request: * |MKDIR alias for save"toto/" which would give back control (if I try to create a directory via save in BASIC, it stops the program) * |CD alias for load"dir" (same reason + uniformity with other DOS) * Access to parent dir (e.g. load"../dump") * A list of current known issue and current requests + status !
Quote from: m_dr_m on 12:57, 02 May 21Good point, I like uniformity too. Yet I also enjoy Morse entropy principle: * Frequent commands should be short * Less frequent commands can be long Plus: * Modifying commands should be explicit
Quote from: OffseT on 23:34, 02 May 21The fact that SAVE/LOAD on directories stops the program is a feature.
Quote from: m_dr_m on 08:19, 03 May 21Wat? It also stops the program on success, which is not consistent with load/save for binaries.
Quote from: OffseT on 23:34, 02 May 21This is actually equivalent to what's done everytime a CAS_* that needs to be redirected to the AMSDOS/ParaDOS call is done.
Quote from: OffseT on 23:34, 02 May 21Keep in mind that two devices can be accessed at the same time (one input and one output) by now
Quote from: OffseT on 23:34, 02 May 21At the end, the best solution will be to actually create a full featured "Floppy DOS Node" that will override the internal DFA/DFB drives (btw, overriding is already working).
Quote from: m_dr_m on 11:27, 03 May 21Yep that exactly the problem! For Orgams that's every 2kb, for Starkos it would be every byte (one hour to load?).I though about that, but that's very rare. Even copiers bufferize.That brings us back to the general principle: common use cases shouldn't be penalised to deal with rare cases.You still have the control over CAS_ routines, no?So 'sitting' in |DISC mode while just one file is opened wouldn't be so complex, would it?
Quote from: m_dr_m on 11:29, 03 May 21Wouldn't this node need the same buffers than AMSDOS, so we would RUN into the same issue?
Quote from: OffseT on 12:13, 03 May 21... correct with X-Mass NVRAM and ...
Quote from: GUNHED on 17:01, 03 May 21Where do you have nvRAM in the X-MASS?How to access it?
Quote from: m_dr_m on 12:27, 04 May 21To each its own, I'm used to reactivity on CPC! Also, I use it extensively for coding. Anyway, why not both? Reliable and fast.
Quote from: OffseT on 13:27, 04 May 21UniDOS is actually focussed on compatiliby and reliability, but also, it proposes a unique solution so that all existing hardwares could be used all together in the same manner.
Page created in 0.108 seconds with 26 queries.