Re: [Freedos-devel] Minor problems FreeDOS 1.3 (Spanish translation)
Hi Aitor, Hi Wilhelm, Can you check if the package in FreeDOS 1.3 has the current translation from fd-nls? The reason I updated in fd-nls was that the Spanish was garbled. At this time I also added the UTF-8 in the hope that that would be considered the master and the cp850/858 could be converted from it as necessary. Andrew On Thu, 6 Apr 2023 22:05:16 +0200 Wilhelm Spiegl wrote: > Hi Aitor, > I do not know who made the spanish translation, maybe Andrew Bird as I just > noticed on the site, it is only one year old, creating a cp xxx and the > unicode version was an idea of Berki, he started in about 3 years ago with > this. > I assume the translator started with Win cp 1252 or overtook it from Google > translate or something like this, overtook the cp of Google translate and > forgot to change to 858 first. this can happen in win or linux as you handle > with two cp and unicode. > > https://github.com/shidel/fd-nls/blob/master/mem/nls/mem.es.UTF-8 > > Could you please check the utf-8 version and tell me if it is okay? Then I > could try to fix this and maybe other commands. > Which characters are bad? Only T or others too? > One more question, you meant "grande 606K" or "grande 606 KB" or a different > version? in gr there is a space between value and KB too. > > Willi > -- > Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.com Mail > gesendet. > Am 06.04.23, 21:18 schrieb "Aitor Santamaría" : > > Hello, > > > > I've been trying FreeDOS 1.3, and found a couple of minor problems running > > it in Spanish: > > > > > > > > the non-standar-ASCII characters appear as preceded by a strange symbol for > > MEM, I wonder if they are really saved as 850/858 or are saved as Unicode > > or something else. > > > > Besides, I've always missed a space before the size of the largest > > executable > > "Tamaño de programa ejecutable más grande_606K" (the _ should be a blank > > but is not there). > > > > I assume these two have to do with the Spanish strings for MEM, should I > > fill in a bug report for that, or is anyone taking care of translations? > > > > I also have a suggestion, applying to Spanish and probably to other western > > European configurations: 850 is used as default codepage. I suggest > > changing to 858, which is the SAME except that it has the euro sign, that > > you can neatly see in the screenshot above. This would apply to any > > configuration where 850 is used as default codepage. > > > > Thanks in advance, > > Aitor > > > > > > ___ Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Minor problems FreeDOS 1.3 (Spanish translation)
Hi Aitor,I do not know who made the spanish translation, maybe Andrew Bird as I just noticed on the site, it is only one year old, creating a cp xxx and the unicode version was an idea of Berki, he started in about 3 years ago with this.I assume the translator started with Win cp 1252 or overtook it from Google translate or something like this, overtook the cp of Google translate and forgot to change to 858 first. this can happen in win or linux as you handle with two cp and unicode.https://github.com/shidel/fd-nls/blob/master/mem/nls/mem.es.UTF-8Could you please check the utf-8 version and tell me if it is okay? Then I could try to fix this and maybe other commands.Which characters are bad? Only T or others too?One more question, you meant "grande 606K" or "grande 606 KB" or a different version? in gr there is a space between value and KB too.Willi--Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.com Mail gesendet.Am 06.04.23, 21:18 schrieb "Aitor Santamaría" : Hello, I've been trying FreeDOS 1.3, and found a couple of minor problems running it in Spanish: the non-standar-ASCII characters appear as preceded by a strange symbol for MEM, I wonder if they are really saved as 850/858 or are saved as Unicode or something else. Besides, I've always missed a space before the size of the largest executable "Tamaño de programa ejecutable más grande_606K" (the _ should be a blank but is not there). I assume these two have to do with the Spanish strings for MEM, should I fill in a bug report for that, or is anyone taking care of translations? I also have a suggestion, applying to Spanish and probably to other western European configurations: 850 is used as default codepage. I suggest changing to 858, which is the SAME except that it has the euro sign, that you can neatly see in the screenshot above. This would apply to any configuration where 850 is used as default codepage. Thanks in advance, Aitor ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Minor problems FreeDOS 1.3 (Spanish translation)
Hello, I've been trying FreeDOS 1.3, and found a couple of minor problems running it in Spanish: [image: image.png] the non-standar-ASCII characters appear as preceded by a strange symbol for MEM, I wonder if they are really saved as 850/858 or are saved as Unicode or something else. Besides, I've always missed a space before the size of the largest executable "Tamaño de programa ejecutable más grande_606K" (the _ should be a blank but is not there). I assume these two have to do with the Spanish strings for MEM, should I fill in a bug report for that, or is anyone taking care of translations? I also have a suggestion, applying to Spanish and probably to other western European configurations: 850 is used as default codepage. I suggest changing to 858, which is the SAME except that it has the euro sign, that you can neatly see in the screenshot above. This would apply to any configuration where 850 is used as default codepage. Thanks in advance, Aitor ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Slowdown-Units ratings and a CPU-bound depacker be nchmark
>> I tried posting a much longer response to this, but it was >> apparently rejected by the moderators. Here's a shorter one. > As I already mentioned in the other reply to this thread, feel free > to send me more specific replies to that article. I'm not sure why it didn't get posted -- it got "lost in the Ether" somehow and that maybe had nothing to do with the moderation. It was in part a response to your specific article, but also a much longer response to the overall thread which has taken a lot of circuitous tangents. I know it will piss off some people and will spur an even longer thread, so am unsure that I should try to post it again. But I also think it says some things that need to be said. If you're willing, I'll send it to you privately and see if you think I should try posting it again. > I/O has also vastly speedup (we have SSD speeds of up to 6 > GB/sec). Just not by doing IN/OUT, but by using memory mapped > PCI devices. I think you're confusing two different things -- MMIO and DMA/Bus-Mastering. >>> >>> He is NOT. >> >> I wasn't talking about ecm being confused, I was talking about you. >> AFAIK, ecm never tested either MMIO or bus-mastering so never said >> anything about them. > > Yes, the only tests I did involved running Slowdown with and without > the one port I/O instruction patched out in the waste loop. However, > Tom is correct that this specific *port* I/O access to that > particular port is not representative of all possible ways of doing > I/O. That is correct, but when I pointed out there really is not any difference in speed between MMIO and PMIO (the two general categories of doing I/O), Tom accused me of spewing BS. I gave him the opportunity to defend himself with some data, and he so far hasn't done that. Let me explain why I said what I did. In the Intel architecture, there is only one address bus and one data bus (in some of the older CPUs the address and data bus were the same physical pins on the CPU, but that is a peripheral discussion). The exact same address and data bus(ses) are used for access to both ports (PMIO) and memory (RAM or MMIO). There is a pin (I've seen it referred to both as IO/M and M/IO) on the CPU that is also part of the bus that tells the external devices whether the address on the bus is a port address or a memory address. The device (or RAM) with both the correct address _and_ address type is the only one allowed to respond. For PMIO, of course, only the first 16 address lines are valid and the rest are ignored (there are only 64k possible PMIO addresses). Also, instead of single pin on the CPU, some of them have a set of pins where some combination of highs and lows on the pins designate ports vs. memory addresses, but the concept is the same. The point is that there is only one bus. When the CPU wants to send or receive data from a device (whether it is RAM or I/O) it sets the pins on the address bus appropriately (the address, address type, direction of transfer, and some others as well) and waits for the device to respond. The fact that the IO/M pin is set or not has nothing to do with the transfer speed -- it all uses the same bus. The CPU must simply wait however long it takes for the device to respond. The simple fact that a device responds to port address(es) versus memory address(es) has nothing to do with the speed of transfer. However, there is a little more "flexibility" in the CPU instructions that can be used with MMIO vs. PMIO. With PMIO the only way you can transfer data is with IN, INS, OUT, or OUTS. With MMIO you can use (at least theoretically) all the CPU instructions that have memory pointers (which a lot of them do). But some devices have limitations on that, too (e.g., with some devices you can only modify an entire Word or DWord at once and not individual Bits or Bytes, and on some devices reading data from a port can actually change some configuration parameter and you don't even need to write to it). In theory, MMIO can make the code a little faster (or at least more efficient) if it is done properly, but if done improperly can actually make things slower. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
