Re: [Freedos-devel] disk I/O performance, was: What are the blocking b ugs/issues for FreeDOS 1.3?

2021-07-28 Thread Bret Johnson
> there is no INT 13nwith a large (32 bit) address. INT 13 can actually handle > 64-bit addresses, both for LBA sector numbers and memory addresses. Refer to > INT 13.4x in RBIL. From DOS, though, you probably wouldn't want to use > 64-bit flat memory addresses, but 64-bit LBA numbers are fine

Re: [Freedos-devel] disk I/O performance, was: What are the blocking bugs/issues for FreeDOS 1.3?

2021-07-28 Thread tom ehlert
> Of course, with > modern systems, a kernel MIGHT allocate a large > I/O buffer in XMS and lock it to a linear addr, nonsense. there is no INT 13nwith a large (32 bit) address. UDMA can do that. KERNEL can't. Tom ___ Freedos-devel mailing list

Re: [Freedos-devel] disk I/O performance, was: What are the blocking bugs/issues for FreeDOS 1.3?

2021-07-28 Thread Eric Auer
Hi Tom, thank you for the I/O trace! Indeed FreeDOS XCOPY also suffers from using a non-aligned buffer. For COPY, the person to tune the code would be Jeremy at the moment. About your COPY C:\kernel.sys C:\BLA test: Let me summarize the LBA trace: Sectors 466 to 469 are read one by one, probab

Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

2021-07-28 Thread tom ehlert
> to quote a 2018 FAT16 speed test example by Jack, copying a > mix of files and directories of different sizes disk to disk: very scientific precise wording;) even COPY or XCOPY may make a huge difference > Plain FreeDOS 65s > With LBACACHE 61s adds a small cache > With UIDE 51s adds UDMA and l

Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]

2021-07-28 Thread Jerome Shidel
Hi Eric, > On Jul 28, 2021, at 8:15 AM, Eric Auer wrote: > > > Hi Jerome, > >> Just a thought on using “undocumented” function calls. > > COUNTRY=... and COUNTRY.SYS are not undocumented, Only referring to the INT call as “undocumented”. :-) > but your > choice of words hints at another ide

Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]

2021-07-28 Thread Wilhelm Spiegl
I think I will change YJN etc. back to english keyboard --> Y etc for one simple reason: It is absolutely confusing to get different options depending on the command you execute. Sometimes this one, sometimes that one. And I do not want to test all tools what they really support, as in most cases

Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]

2021-07-28 Thread Eric Auer
Hi Jerome, > Just a thought on using “undocumented” function calls. COUNTRY=... and COUNTRY.SYS are not undocumented, but your choice of words hints at another idea: Do you suggest to introduce a TSR to handle string and key translations, to be used by FreeDOS apps? I think this would not save e

[Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]

2021-07-28 Thread Jerome Shidel
Hi Eric, Just a thought on using “undocumented” function calls. > On Jul 28, 2021, at 6:40 AM, Eric Auer wrote: > > > Hi! > >> reserved to condition for example yes, no, quit > 0.0:Y> 0.1:N >> Space reserved to file diskcopy.c >> (...) >> 1.29:image fi

Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

2021-07-28 Thread Eric Auer
Hi! > reserved to condition for example yes, no, quit > 0.0:Y> 0.1:N > Space reserved to file diskcopy.c > (...) > 1.29:image file (Y/N)? > 1.30:disk (Y/N)? > 1.31:Copy another disk (Y/N)? Note that yes/no questions actually have kernel support. This wil

Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

2021-07-28 Thread thraex
On 28.07.2021 07:58, Bret Johnson wrote: > I saw Wilhelm's earlier comment and started thinking about some of its > implications: >   > i) NLS support: Is there anybody who can tell me if all DOS commands > support [J(a)|Nein] or [O(ui)|N(on)] etc. instead of [Y(es)|N(o)]? If > not, they should