Re: [Freedos-devel] zoo just needs packaging
On 5/23/2024 11:29 AM, Bernd Böckmann via Freedos-devel wrote: I second that. No need to throw anything out if it gets fixed. Isn't it an aspect of FreeDOS to keep old software available? Throwing everything out that might not be of use to many would contradict that goal. +1 Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] zoo
On 5/22/2024 11:35 AM, tom ehlert via Freedos-devel wrote: it seems that no knowledgable person finds zoo interesting enough to fix it. and those who care about zoo have no clue. I regret that I have to say this. Tom Was zoo even popular in its heyday? I don't think so. Well, yes, it was quite popular, not only in Japan, but in Germany for example as well... ;-) I feel like when it comes to DOS, for the last 30 years it's been exclusively ZIP, except in Japan where it's been exclusively LHA... I don't know about Japan(where Freedos is probably not no popular due to characterset isseus), but everybody else should use ZIP. just remove ZOO and all other (ARC,...) archivers. It's ok to retain them somewhere on the internet (to be downloaded if needed for some reason) but not as part of FreeDOS distribution. One of the few cases where deleting the program actually 'solves' the problem. Different people have different needs. That's been the case, also for DOS, for a long time. I for one, work with a lot of old sources from old Simtel, Garbo, Walnut Creek, etc and there are a lot of files in a large variety of archiver formats. And more and more people are, even if it is just for playing retro games, into such old stuff and need ways to extract those old archive files. Chacun a son gout, as the British say. YMMV... As for the problem of the topic, I think this is just something that can be ignored if nobody fixes it, and it seems to me a bit blown out of proportions... :( Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] still can't find the source code
On 5/10/2024 6:45 AM, Green Fog via Freedos-devel wrote: There you go. The 2 requirements for free dos being a thing are just not there. not ease of use. I need to use an antique mail list for communication and wiki/documentation. It's absurd and very not efficient. I am very busy, and I can't afford the time to download each of these packages one by one. That is not how the source code should be distributed. Ease of use is none. Documentations are very bad. The sites linked to are web 0.1 material. Good documentation and know-hows are what drive further development, so I can say free dos is dead, and I will not invest more time on it. Bottom line is that you don't even tried to understand what "DOS" is. Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] still can't find the source code
On 5/10/2024 7:02 AM, Jim Hall via Freedos-devel wrote: I'm usually a very nice guy, but I have to call this out: If there was ever a prime example of how *not* to ask for help, this email thread was it. +1 Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Where is the source code?
On 5/9/2024 3:05 PM, Kirn Gill via Freedos-devel wrote: Listen, for developer documentation, we should be skipping YouTube entirely. There's absolutely no good developer documentation that's shipped in video form. In fact, the medium prevents it. +1 Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Where is the source code?
On 5/8/2024 1:22 AM, tom ehlert via Freedos-devel wrote: It's on the website, under the "developer" section. in my version of firefox, there is no "developer" section onwww.freedos.org Look again, in my Firefox (125.03, on Windows 10/64) it is right below and slightly to the right of the blue "Download FreeDOS 1.3" button, one of those three rather prominent boxes linking to "Playing Game", "Running applications" and, wait for it, "For Developers". Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Where is the source code?
On 5/8/2024 8:28 AM, Bernd Böckmann via Freedos-devel wrote: I like the following playlist. He uses Turbo C, PowerBasic, NASM. While he does it on DosBox, the skills are transferable. Be aware: heavy german accent :) That happens to the best of us... LOL Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Connection info for the virtual get-together
On 5/7/2024 8:57 PM, Jim Hall via Freedos-devel wrote: [...] Not a typo. :-) It just happens that the 30th anniversary is a Saturday. (June 20, 1994 - 2024.) Now you're trying to confuse me, aren't you... Wow, of all the places to have a typo, it's in an email where I claimed no typo. That should have been: June 2*9*, 1994-2024 We shall call this now "Jim's Law"... ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Connection info for the virtual get-together
On 5/7/2024 8:14 PM, Jim Hall via Freedos-devel wrote: On Tue, May 7, 2024, 9:23 PM Ralf Quint via Freedos-devel wrote: On 5/5/2024 10:15 AM, Jim Hall via Freedos-devel wrote: [..] > We talked about doing the next virtual get-together on Saturday, June > 29 (11am-noon, US/Central). That's the FreeDOS 30th anniversary, so it > seems like a great opportunity for a virtual get-together! We > alternate topics, and today was "technical" - so that conveniently > means June 29 will be "social." :-) I just checked my note that I quickly put in an online calendar the other day and wanted to add that to my paper/wall calendar, when I noticed that June 29th is a Saturday, not the usual Sunday. Don't know if this is just a typo or a more serious missed-take... Not a typo. :-) It just happens that the 30th anniversary is a Saturday. (June 20, 1994 - 2024.) Now you're trying to confuse me, aren't you... ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Connection info for the virtual get-together
On 5/5/2024 10:15 AM, Jim Hall via Freedos-devel wrote: Thanks to everyone who joined the virtual get-together today! We had 11 people on the call, and we did some virtual debugging, demo'd some programs, and talked about other technical topics. We talked about doing the next virtual get-together on Saturday, June 29 (11am-noon, US/Central). That's the FreeDOS 30th anniversary, so it seems like a great opportunity for a virtual get-together! We alternate topics, and today was "technical" - so that conveniently means June 29 will be "social." :-) I just checked my note that I quickly put in an online calendar the other day and wanted to add that to my paper/wall calendar, when I noticed that June 29th is a Saturday, not the usual Sunday. Don't know if this is just a typo or a more serious missed-take... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01
On 5/3/2024 8:54 PM, Steve Nickolas via Freedos-devel wrote: First big issue, and one I can only partially resolve. I'm taking a strict approach to the contents of the TOOLS folder - want to get rid of it and replace it with open-source equivalents. That means, most practically, OpenWatcom 1.9 (there's prolly other options but the more like MSC it is the less torturous porting is going to be). And the code's going to need to be dinked as far as possible to roll in Watcom instead of MSC - that's going to be a major pain in the neck. Sorry for being a bit late to this "party", but just some quick thoughts. I don't think there is really a point in trying to get the whole thing compiled with FOSS tools. This is just a Sisyphos task, for no or very little gain. There is a reason why they included the old, matching tools in the release. What could be however of value is to look at the source for some of the "trouble spots". For example, for me, the with FreeDOS supplied memory managers always give me a really hard time on real hardware. This release comes with the source of EMM/MEMM, which could help to glean some insights that could help to solve such memory issues. Or how EMM deals with DMA of various hardware, like sound cards, hard drive/floppy adapters or network adapters. Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Website has moved to new hosting
On 3/6/2024 12:08 PM, Bernd Böckmann via Freedos-devel wrote: On 06.03.2024 20:52, Ralf Quint via Freedos-devel wrote: Seems I am hitting the new server... Does anyone know what happened to bttr? Its down with http 500. Though error page is graphically nice! Nope. But it seems it is only the main web site, the "DOS ain't dead forum" (which I mostly visit, if I remember a working password... :( ) seems to be just fine. Might wanna try and post a message in there to see what's up... An http error 500 is exactly what it says in the error message, a(ny) internal server error, which can be anything from no RAM, no/bad drive space, bad update, etc... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Website has moved to new hosting
On 3/6/2024 7:37 AM, Jim Hall via Freedos-devel wrote: If you're curious if you're accessing the new server or the old one, I added this temporary file on the new server. It tells you if you are using the new server or the old one: https://www.freedos.org/new.txt Seems I am hitting the new server... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
On 2/9/2024 3:50 PM, Bernd Böckmann via Freedos-devel wrote: On 09.02.2024 22:30, Ralf Quint via Freedos-devel wrote: It always complains it can't find it and wants it to be put in the "roms" folder Under Windows I had success by creating a "roms" directory in the directory of 86box.exe, and then copying the rom images provided by [1] into that directory. That's what I tried, but no dice. Still have some (hopefully) paid work to do, will check this again later... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
On 2/9/2024 1:07 PM, Bernd Böckmann via Freedos-devel wrote: On 09.02.2024 21:17, Ralf Quint via Freedos-devel wrote: is one reason why I used to write my own asm routines for BIOS calls In this case it may be of interest how intr is actually implemented internally [1] :-). Yes, intr() is not the most efficient, but the most "portable" compiler-wise, if one can say that. The 86box machine type is Xi8088, this is not the 8088Book, but behaves the same. Well, how/where do you place the BIOS ROM for 86box? It always complains it can't find it and wants it to be put in the "roms" folder, but regardless what/where i try, I just get send around in circles. Takes far too much time than I have before the weekend... :( Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
On 2/9/2024 12:13 PM, Bernd Böckmann via Freedos-devel wrote:
Hi Ralf,
On 09.02.2024 20:02, Ralf Quint via Freedos-devel wrote:
I can't see any reason as to why a data segment on a BIOS call should
be set to any random value.
For example, take this code (copied from FDISK source):
static void Reset_Drive( int drive )
{
union REGPACK r;
memset( , 0, sizeof( union REGPACK ) );
r.h.dl = drive;
intr( 0x13, );
}
The REGPACK r contains variables for the (segment) registers. In the
above, these are initialized to zero by the memset function. If you
leave this out, variable r, and so DS, ES contain random values,
because r is on the stack. The values of the structure are loaded into
the registers before intr calls the requested interrupt, and the
original values are restored before it returns. You may of course
initialize the individual structure members explicitly. For example DS
with the current value stored in the register. But, like said, the
above is like the manual recommends.
Greetings, Bernd
Thanks Bernd, will check this in a bit. The above is one reason why I
used to write my own asm routines for BIOS calls. Will test this during
my lunch break, if I can get 86box emulating this X8088book to work... ;-)
Ralf
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
On 2/5/2024 3:04 PM, Bernd Böckmann via Freedos-devel wrote: On 05.02.2024 23:14, Ralf Quint via Freedos-devel wrote: Sorry, was just confused as to why all the sudden this was brought up. No one was harmed :-) I wanted to explain why I set DS to zero and probably went a bit off-topic by referring why the Watcom manual recommends it. The longer I think about it the more I wonder if not setting DS to zero, what a "good" value for it would be when calling the BIOS. Random values are probably not a good idea. I do not think that there should be a distinction between "good" and "bad" memory corruptions. A memory corruption is by definition bad. But if there were a way for example the kernel to mitigate such BIOS bugs by choosing a "better" segment register, it should be worth a consideration. But I do not know what would be the side effects of choosing F000, for example. Eric brought brought me closer to this idea. F000 should most often be read-only, but could impose other problems. I can't re-read the thread right now, but now I am even more confused. I can't see any reason as to why a data segment on a BIOS call should be set to any random value. The side effects for choosing F000 could be for example that you would create incompatibilities with "non-IBM PC" PCs. As far as DOS goes (as slim as the chances are that someone has such a machine in 2024 ), it should be possible to have it (and programs like FDISK) running on machine like an Tandy 1000, DEC Rainbow or Victor 9000/Sirius 1, and I know for sure that on the later, F000 is the video RAM segment on that machine... I will re-read that thread and see what the issue with the DS would be, but again, I can't see how it possibly could be a "random" segment. You either want to read a value at a specific offset (not much harm done beside not getting back the value you are looking for) or in worst case scenario, you are trying to write to that address and that could cause havoc depending on your random value for DS... l8r, Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
On 2/5/2024 2:09 PM, Bernd Böckmann via Freedos-devel wrote: On 05.02.2024 23:01, Ralf Quint via Freedos-devel wrote: Sorry, but if this is indeed an 8088/8086 (or even a V20) CPU, there is no protected mode I did not claim that!?! This is about invoking interrupts from a high level language, following the recommendations of the compiler vendor, and about the benefits of properly initializing the corresponding data structure, explaining why in this specific case DS was zero when calling the BIOS... Sorry, was just confused as to why all the sudden this was brought up. This was more of a general remark than anything specifically directed to you! Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
On 2/5/2024 11:15 AM, Bernd Böckmann via Freedos-devel wrote: On 05.02.2024 19:56, Bret Johnson wrote: That doesn't quite make sense, since 0 is just as much of a "garbage" segment as any other random selector It does! Because if you have a REGPACK as automatic object (on the stack), this likely contains random values for DS and ES. I am not that into protected mode, but I am very certain that it is a bad idea not to initialize them, because if the values are not within the limits of the GDT / LDT, this should throw a general protection fault, no matter if DS or ES are dealt with at all. But for real mode it should not matter that much. But it is not bad to have the program crash soon as the error occurred. So my common practice is to zero this union prior to using it... Sorry, but if this is indeed an 8088/8086 (or even a V20) CPU, there is no protected mode Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] NLS in Edlin
On 2/4/2024 11:32 AM, Jerome Shidel via Freedos-devel wrote: Hi, On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel wrote: On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote: I made recompiling Edlin easy for non-programmers, so that shouldn't be a problem. You don't have to know a lick of C to recompile it. Well, part of the problem is that in order to recompile, you need to have the compiler (toolchain) installed, which isn't necessarily easy for a non-programmer. Ralf I have occasionally compiled edlin to provide an updated version for FreeDOS. As compile from source goes, EDLIN is not that bad. If I recall correctly, It just needs our Watcom-C to compile. Plus a little knowledge on options and such things. In general, it is extremely cumbersome to acquire all the exact required pieces to accomplish. An fairly often after spending a few hours on trying to get a successful compile, I will end up giving up. Therefore, I do that very rarely anymore for almost anything. The problem with the whole NLS/i18n thing is that it is not only done with just translating some text extruded from the sources. And recompiling some programs which don't lend themselves well to the whole "kitten" shebang. It would require a lot of testing, which needs to be done by someone with those native language skills (plus some technical knowledge what it is all about). A lot of command line tools might be fairly easy to do, but for anything that is using a more formatted screen output, this also requires to check where things are "overflowing" (for lack of a better term right now)/misalignment... And we have a very limited number of people that would have ALL the required skills. IMHO, before getting too much wound up with everything that is involved, I think we need to make sure to have a proper English version, for everything, As discussed in the online meeting, it would be nice to include dependency requirements in the package metadata. This makes me think we could possibly include the build-dependency requirements as well. Plus a per package universal build batch. That would be a lot of work and probably require frequent updating when packages change. I see that there would be some effort initially to add that info, but seriously, how much are dependencies as such changing for any given program after that? But on the other hand, it would be very nice if all programs (excluding those made with commercial compilers like Turbo Pascal) could be built from source simply by installing the required build packages. This leads me to think, maybe we should go back to the old days when sources were in their own separate package and not included in the binaries package. That was a move that I have never understood in the first place, as the vast majority of people downloading FreeDOS are likely just interested in getting it running, rather than doing any development. Specially if things aren't as simple anymore as they (mostly) used to be in the days of DOS, too many Linuxisms have crept in, which makes it so much harder for people that are just trying to get back into DOS and haven't done anything programming wise for the last 20-30 years, and then in things like BASIC or Turbo Pascal, which are all "programma non grata" for a lot of OSS license minded folks... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Link for today's virtual meeting
On 2/4/2024 11:02 AM, Jim Hall via Freedos-devel wrote: On Sun, Feb 4, 2024 at 12:40 PM Jerome Shidel via Freedos-devel wrote: Hi Jim, Interestingly, when you left the online meeting, it kept going at least for a few seconds until I clicked end-call. I don’t know if it would have kept going indefinitely. We will have to try that next time. That is interesting! I wonder how long it would have kept going? (My guess: only another minute or two.) You should definitely stay on next time to see when (if?) it kicks you off. I think that is just an "artifact" of using a video conferencing in a web browser and possibly associated buffering. 1. Willi's HTML Help update. I sent another email to freedos-devel so everyone could see this announcement. I'll also post an announcement on the website. I might have missed this while trying to adjust the settings in Google Meet, but what exactly is the problem with AMB? 2. The Book8088 problem. This was an interesting one to me. Bernd reported that there's a bug in XT-IDE where if you check for LBA more than once, it hangs. Folks are working on it. It would be *great* to see follow-up discussion on this topic in freedos-devel. The general problem that I see here is to have an environment to actually test this, which I think might be a bit hard if one doesn't actually have one of those devices... 3. Kernel updates from Jeremy. There are a few updates coming, including Win311 compatibility. Jeremy had planned to make a release of some kind in December, but got delayed. We were all interested in trying out the new kernel in the next Monthly Test Build (T2403). Jeremy plans to share an update on freedos-devel - hopefully soon - even if it's just a "pre-release" version of the kernel. (^_^)b Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] NLS in Edlin
On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote: I made recompiling Edlin easy for non-programmers, so that shouldn't be a problem. You don't have to know a lick of C to recompile it. Well, part of the problem is that in order to recompile, you need to have the compiler (toolchain) installed, which isn't necessarily easy for a non-programmer. Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] MAD compiler for DOS?
On 1/30/2024 3:43 PM, Jim Hall via Freedos-devel wrote: [..] Jim Hall wrote: [..] I'm thinking about writing a book about the early history of document preparation systems, and RUNOFF seemed a good place to start. I want to faithfully recreate the MAD code in another programming language - not an automated translation like ESR's translator would do, but an [..] Ralf Quint wrote: You seem to be as predisposed as me in always finding new deep dark rabbit holes to decent into It is definitely a rabbit hole. :-) At first it was just curiosity of "what does this code *do*?" and then it turned into "I wonder if I can rewrite this in something that's easier to understand?" But I have a particular interest in the early history of document preparation systems, including troff (and nroff before that (and roff before that (and RUNOFF before that))). So this rabbit hole was kind of a tempting one to step into. Well, the Wikipedia page lists at least two MAD manuals (the compiler, not the magazine), I might just download these and have a look at this late tonight, Tuesdays I can't get to sleep until 2am anyway and always watching movies on YouTube gets boring after a while... ;-) That's where I found the MAD manual too. It's interesting reading. Especially so because they didn't write it for someone who had never seen MAD (programming language before). In the part about the "for-next" loop, rather than demonstrate it by saying "let's write a simple program that counts from 1 to 10" they demonstrated it by writing an algorithm to solve a polynomial. That's not a simple way to show something. :-P It takes a little skill to explain something, it takes great skill to explain it *simply* to someone who's never seen it before. Well, I skimmed over the manual and realized that I ran into this before, though that might be 2-3 decades ago, when I saw the conditional WHENEVER statement. I remember some not so serious discussions (might have been on a BBS) about extending the language to include the WHATEVER and MAYBE statements... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] MAD compiler for DOS?
On 1/30/2024 2:14 PM, Danilo Pecher wrote: I'm having real problems to read about MAD code written with FAP subroutines with a straight face. I'm such a child... Blame Alfred ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] MAD compiler for DOS?
On 1/30/2024 1:37 PM, Jim Hall via Freedos-devel wrote:
Jim Hall wrote:
On Mon, Jan 29, 2024 at 8:07 PM Jim Hall wrote:
I am working on an academic project that requires understanding the
MAD programming language so I can pick apart (and faithfully recreate)
an old MAD program. That's the Michigan Algorithm Decoder, from 1959
and the early 1960s.
[..]
Does anyone know of a MAD compiler for DOS?
Ralf Quint wrote:
Up to your email, I haven't even heard of a MAD compiler. Only the
magazine...
(and interesting seeing that mentioned in the Wikipedia article LOL)
Yes, I hadn't heard of it either until a few months ago when I started
researching the RUNOFF source code. It's written about half in MAD and
about half in FAP (FORTRAN Assembly Programming). The RUNOFF program
is written in MAD with some support functions in FAP.
I'm thinking about writing a book about the early history of document
preparation systems, and RUNOFF seemed a good place to start. I want
to faithfully recreate the MAD code in another programming language -
not an automated translation like ESR's translator would do, but an
understandable recreation by a human who understands what the original
code is doing and recreates it in a sensible way in another
programming language. Might do it in C or BASIC. BASIC might be
easier, since I'm seeing some similarities between MAD and BASIC. But
I'd prefer to do it in C.
You seem to be as predisposed as me in always finding new deep dark
rabbit holes to decent into
But step #1 is to understand what's going on in the code. MAD is
mostly readable, but the for-next loop equivalent is a little weird to
me. For example, to loop from 1 to 10 (inclusive) in C, you'd do this:
for (i = 1; i <= 10; i++) {
...
}
Just to compare: in FORTRAN77, it's like "DO label var = start, stop, step":
DO 10 I = 1, 10, 1
...
10 CONTINUE
But in MAD, I *think* it's like "THROUGH label, FOR var = start, step,
failcondition":
THROUGH LOOP, FOR I = 1, 1, I .GT. 10
...
LOOP CONTINUE
And from what I can see, I think "failcondition" gets tested at the
end of each iteration, so it's more like this weird 'while'
construction in C:
i = 1;
do {
...
i++;
} while ( !(i>10) );
That's why I wanted to write some sample code in a real MAD compiler,
to see if I'm correctly understanding that (and a few other odd things
in the language).
Well, the Wikipedia page lists at least two MAD manuals (the compiler,
not the magazine), I might just download these and have a look at this
late tonight, Tuesdays I can't get to sleep until 2am anyway and always
watching movies on YouTube gets boring after a while... ;-)
Ralf
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] MAD compiler for DOS?
On 1/30/2024 7:58 AM, Jim Hall via Freedos-devel wrote: On Mon, Jan 29, 2024 at 8:07 PM Jim Hall wrote: I am working on an academic project that requires understanding the MAD programming language so I can pick apart (and faithfully recreate) an old MAD program. That's the Michigan Algorithm Decoder, from 1959 and the early 1960s. [..] Does anyone know of a MAD compiler for DOS? It's not (specifically) for DOS, but someone pointed me to Raymond's MAD implementation. It translates MAD code to C, and you can compile from there: https://gitlab.com/esr/mad I think that will do what I need. But if anyone knows of a full-on MAD compiler for DOS, please let me know. Up to your email, I haven't even heard of a MAD compiler. Only the magazine... (and interesting seeing that mentioned in the Wikipedia article LOL) Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Next FreeDOS virtual get-together
On 1/19/2024 1:58 PM, Jim Hall via Freedos-devel wrote: Hi everyone! I promised to propose the next virtual get-together after the holiday break, so here it is. :-) How about Sunday, February 4 for the next get-together? That's three Sundays from now. Time is 11am to noon US/Central, same time as always. And we'll probably go over that, because we always do. :-) That should work for me, and I will put this on at least 3 calendars in order not to forget it this time... :P Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
On 11/8/2023 11:40 AM, Bernd Böckmann via Freedos-devel wrote: Hi all, has anyone recently played around with the FreePascal 8086 cross compiler to generate DOS executables? I try to convert a near pointer to a far pointer while working under the small memory model, but that is not as trivial as it should be, because I have not found a language / library feature for it. For example, a cast operation does not work. But the semantics should be well defined (for the small memory model): set the segment part of the far pointer to DS. I came up with the following solution, but I am wondering if I have overlooked something built-in? function ToFarPointer(nearP: NearPointer) : FarPointer; var p: packed record ofs: NearPointer; segm: Word; end; begin p.ofs := nearP; asm mov ax, seg @data mov [p.segm], ax end; ToFarPointer := FarPointer(p); end; (the above of course only works with the small / tiny / compact memory models) Greetings, Bernd How are you even working in the "small" memory model in FreePascal? One of the problems that I noticed when trying to use the 8086 version of FreePascal long time ago was that while someone went through the length of generating 8086 code, there was little compatibility with Turbo/Borland Pascal and actually DOS. "small" memory model means that you have a fixed code AND data segment, and all pointers are just offsets within those segments. Not having the definitions of NearPointer and FarPointer from the above snippet, one thing to consider is that when changing either CS or DS segments in a small memory model program, you need to make sure that you ALWAYS save and restore those segments when changing them temporarily... I am pretty sure that the actual compatibility with the DOS environment has not significantly improved since I tried. And as in Pascal, by default you should not be messing with any pointers directly, any such feature to do so would be a very specific implementation/library issue... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Phishing attack - warning!
On 11/3/2023 11:36 AM, Wilhelm Spiegl via Freedos-devel wrote: Hi Ralf, you never make a mistake? Then you never make a "backup"? Rarely. And I do. The thing that is more interesting for me is how the person really made it. I just found this very same email in my spam folder, Thunderbird (or GMail) just perfectly fine determined that this is spam, hence, I did not see this when it came in. I certainly won't make the mistake of reading/receiving email in a web browser. Email clients exist for a reason, and proper spam/virus scanning/filtering is one of the benefits that every email client worth it's salt provides. As for the way how this email is made, well, that is as stated before what makes me wonder on how someone can just click on such a link. "One way link" just doesn't make any sense in the overall "picture" of the email. So first thing I do before I would even attempt to hover over the link with the mouse, which in my email client will show me the actual address that link points to. At latest at this point, together with the overall indescriptive email (not counting the apparently badly copied contents of an half year old email thread), it should be obvious that this is a phishing attempt. Sorry Wilhelm, but it's the year 2023 and everyone should know by now that the Internet isn't the friendly place anymore it was +30 years ago and use common sense Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] i have a tech question about 286 and XMS
On 11/2/2023 1:25 PM, sparky4 insano via Freedos-devel wrote: i think i may of found a bug? there is stability issues with Wolfenstien 3D (specifically running the demo for random amounts of time) with this XMS driver. it will crash and lock up the entire pc. Which XMS driver? Microsoft's HIMEM? Sorry, but that is THE reference implementation for XMS, and as a matter of fact, came right from the beginning with the source code published (though copyrighted by M$ IIRC). It is more likely that your game in fact has a bug, like not properly releasing the XMS memory chunks when exiting... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Phishing attack - warning!
On 11/2/2023 2:38 AM, Wilhelm Spiegl via Freedos-devel wrote: Hi all, I only wanted to tell you that I had a "FreeDOS" phishing attack yesterday. The mail I got arrived at my n...@mnet-online.de account, with subject: *Re: [Freedos-devel] mode.com* sender:*m...@planet.com.pk* Text: *Hi There,* *Please see the documentation contained in the url followed below.* *Hyperlink: ONE WAY LINK* *Enjoy a great daytime!* Who would click on such a link? In an email from a random user that contains absolutely no information what this is about? Unfortunately, the random and possibly malicious nature of the sender is exaggerated that we for a while now don't really see the actual sender, but only the "Technical Discussion." from the mailing list... :( Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Interim Build T2310 - no free space on CD
On 10/5/2023 4:44 AM, tom ehlert via Freedos-devel wrote: Hallo Herr Ralf Quint via Freedos-devel, am Donnerstag, 5. Oktober 2023 um 02:50 schrieben Sie: On 10/3/2023 11:30 AM, Michael Brutman via Freedos-devel wrote: There is no point in punishing everybody by shipping tools that most > people don't use. You can probably count all of the active DOS > developers on your fingers and toes. All of the various tools and compilers remain available for download. > Not being on the CD image is not the barrier it used to be. But could you consider that there are so few people programming in and for DOS simply because there are no simple to use programming environments available and instead some folks keep pushing oversized Linux influenced behemoths of programming environment which need to be shoehorned to run and produce results within the basic limitations of DOS? i have said it before, but repeat it anyway: Well, no matter how many time you repeat that, that doesn't make it in MY opinion a valid argument. I joined some retro computing and BASIC groups and there are LOTS of people that would just for old times sake like to program in (Free)DOS, in something simple as a BASIC interpreter, like they did 30 years ago. Not everyone wants to run DOS to play games. Or develop multi-megabyte applications. And not everyone is running (Free)DOS in a VM. Beside that leaves you in general also with the problem on how to transfer your programs from your fancy Windows/Linux/macOS box to that VM. That's a problem that that you simply do not have when programming ON DOS. Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Interim Build T2310 - no free space on CD
On 10/4/2023 10:45 PM, Kirn Gill via Freedos-devel wrote: I think you're blinded by DJGPP. At no point did I argue for keeping THAT mess in... or gcc-ia16. For the record, my reply was in response to Michael Brutman, not to you Rlaf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Interim Build T2310 - no free space on CD
On 10/3/2023 11:30 AM, Michael Brutman via Freedos-devel wrote: There is no point in punishing everybody by shipping tools that most people don't use. You can probably count all of the active DOS developers on your fingers and toes. All of the various tools and compilers remain available for download. Not being on the CD image is not the barrier it used to be. But could you consider that there are so few people programming in and for DOS simply because there are no simple to use programming environments available and instead some folks keep pushing oversized Linux influenced behemoths of programming environment which need to be shoehorned to run and produce results within the basic limitations of DOS? Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Interim Build Delayed
On 9/1/2023 7:49 AM, Jerome Shidel via Freedos-devel wrote: Hi All, The FreeDOS Monthly Interim Build for September will be delayed. The latest version of FDISK includes a large language translation file. That file is preventing the 720k Floppy version from building. As I mentioned in the online meeting, just don't put any language files on the floppy version in the first place Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Virtual get-together?
On 8/6/2023 7:52 AM, Bernd Böckmann via Freedos-devel wrote: Am 30.07.2023 um 20:15 schrieb Jim Hall via Freedos-devel : Let's try again next month. Is this today or another Sunday? Jim had changed it from the original July 23 to July 30, due to being sick and then forgot about it last Sunday. So the next meeting will be on August 20, I guess... ;-) Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANSI for DOS
On 8/3/2023 11:54 AM, Jerome Shidel via Freedos-devel wrote: On Aug 3, 2023, at 12:37 PM, Bret Johnson via Freedos-devel wrote: Yeah, USB and CD/DVD makes only sense for a 386+ ... USB, yes. CD/DVD, no. USB requires PCI which in turn requires 386+. Actually, there were supposedly USB host controllers manufactured for the ISA bus instead of PCI, but I've never actually seen one. But USB protocols assume you're using a 32-bit (and in some cases 64-bit) CPU so USB really only makes sense on 386+, though you could probably make things work on a lesser CPU if you absolutely had to. But CD drivers existed back in the early days and they never required anything special of the CPU. They would sometimes take advantage of special features if they were available, but it wasn't required. AFAIK, there are no DOS DVD drivers anyway since I don't think anything has ever supported UDF. I don’t recall any sub-386 ever shipping with a CD-ROM drive. But, there may have been a couple very high end machines. The main problem why I consider a CD/DVD drive is that on pre-386 computers, you rarely have an IDE/ATAPI controller to connect a common CD-ROM drive. Yeah, theoretically, you could use a SCSI one, but that's a completely different kettle of fish... The first time I used CD-ROM drives was at least on a 486 machine. You could try to use and ATAPI controller on an AT class computer (80286, or lower), but then you are getting down into a deep dark rabbit hole where you need to know what you're doing anyway, so trying to adapt FreeDOS would be a manual option. Hence, from a general, default installation option POV, I stick with my assessment that it makes only sense for a 386+ machine... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANSI for DOS
On 8/2/2023 1:30 PM, Jerome Shidel via Freedos-devel wrote: My stuff for FreeDOS requires only an 8086. The exception being LOGGER which can run on an 8086. But, I have that functionality turned off at present. The CD and USB install media need a 386 do to the reliance on grep during installation. Which I feel is fine. Because USB is not present on 386 or less. Also, the CD drivers available to us require a 386+. Eventually, I will add the functionality that is provided by grep into V8Power tools. However, because the drivers still need a 386+, those media will still need one to use them directly. Why would grep require a 386 CPU? Yeah, USB and CD/DVD makes only sense for a 386+, but a version of grep should work just fine on an 8086. I am pretty sure that Borland's version that came with the various Turbo compilers did, and there should be source versions out there that can be compiled for 8086 just fine... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANSI for DOS
On 7/31/2023 6:37 PM, Paul Edwards via Freedos-devel wrote: > Trying to force decades > old operating systems to match is probably a dead end. Do you mean started decades ago or ended decades ago? Both Freedos and PDOS/86 are in active development. As far as FreeDOS goes, it's goal is to be basically MS-DOS 6.0 compatible. And its targeted hosts are (and forever will be) IBM compatible PCs. Any step you're trying to change that will lead you down a path where you end up no longer to be DOS compatible. You basically will end up with a new/different operating system that will have to compete with the likes of Linux, Windows or macOS. Windows is in active development too, and at a particular point in Windows 10 finally embraced ANSI X3.64, allowing the platform independence. In fact, I remember reading something on Microsoft's website with regard to the old methods that used a virtual screen buffer as being obsolete and not the direction Microsoft was taking. I am not sure what exactly you read, but I think it doesn't mean what you think it does. "Embracing" ANSI X3.64, an 43 year old standard (in 2023) certainly doesn't pertain to anything GUI oriented. The best that I can think of is that this could possibly to that abomination that they call "PowerShell", which simply is a spawn of evil, and certainly nothing that would effect current application development. This all sounds more like just another M$ marketing ploy. "Look, we got all new shiny icons! Alles so schön bunt hier!"... I'm not stating that Microsoft is embracing the exact same concept that I am (not saying they're not either), but I don't think it is so black and white that the microemacs that I just released as source and DOS binary is inherently useless. Friends don't let friend use EMACS! (sorry, just had to put in this personal note LOL ) Linus said that his Unix would never be as sophisticated as what was it? SCO? I've forgotten. Almost no-one else has even heard of it to even forget. He was using Unix and to some degree, Minix, at the university. And his intention was to create something that took advantage of the 80386 CPU (while Minix and in fact most Unix at that time were only using a 80286) Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANSI for DOS
On 7/31/2023 6:01 AM, Paul Edwards via Freedos-devel wrote: I never knew why DOS only had ANSI for output, not input. That is not co correct. And it wouldn't be as much a DOS issue, but an issue with the ANSI driver being loaded. Beside the very early days of DOS, with it originally being conceived (as DQOS/86-DOS) by SCP for their S100 based 8086 system, starting with DOS 2.0, ANSI would handle both input and output, as you have to use a serial terminal to communicate with your system. The IBM PC (and +99.99% of all clones) used direct hardware access in it's BIOS for keyboard handling and direct memory access ultimately for screen output. Though there were a handful of early, "not so IBM compatible" PCs, likethe Sirius 1/Victor 9000, the DEC Rainbow 100 and probably a couple more (early Zenith). And I used to use/write software for some "industrial" PC in 19" racks that were operated via serial connected terminals. Any software that uses just DOS calls should run on any other PC. If that machine is not "IBM compatible", than DOS will have to be adapted to that specific hardware, either by using appropriate BIOS calls (if available) or needs to have that DOS calls adapted to access the underlying hardware directly. Beside those early S100 computers (or Heathkit IIRC), ANSI was only necessary on PCs/DOS based systems when using terminals, for example things like IBM 3270 (where the connection was made via a special adapter card). Or BBS systems, in the days before the Internet existed, over slow dialup connections... The problem (and the competitive edge for software) is that DOS calls, even BIOS and also ANSI sequences are excruciating slow, compared to direct hardware access. That was a decisive factor as to why IBM prevailed, even though contemporary machines like the Sirius 1 or TI Professional had technological advantages (CPU was almost the same, 5MHz 8088, but max RAM under DOS were 896KB and 768KB respectively, the Sirius 1 had out of the box 800x400 monochrome graphics, the TI Pro had 720x300 in either mono or graphics, the Sirius 1 had 1MB floppy disks, while the first IBM PC had only 160KB). All clones, that wanted to get a piece of the PC market pie had to follow the IBM hardware layout, And 40 years later, this is still the norm, though things like BIOS support have already been deprecated, and that's also something where no ANSI is going to help you, specially when all "modern" systems are GUI based... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] dir issues
On 7/23/2023 9:35 AM, tom ehlert via Freedos-devel wrote: ISTM that all the other graphical shells in FreeDOS are even less useful than GEM, and it would be no loss to remove them... but adding GEOS would be a win. in what way is GEOS even related to FreeDOS which runs on PC's? unless wikipedia has it completely wrong GEOS needs 6502 (commodore c42, AppleII etc) computers. Tom Well, there is/was a PC version of GEOS, which for a while now is Open Source and available as PC/GEOS (to differentiate it from THAT GEOS you were thinking of) at https://github.com/bluewaysw/pcgeos Ralf PS: I don't think that GEM would be useless for use with FreeDOS, but just as with PC/GEOS, it needs people to actually do some work on it ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS virtual get-together (moved to next week)
On 7/22/2023 12:55 PM, Jim Hall via Freedos-devel wrote: Hi everyone I was traveling for a conference this week, and now I am sick. (My COVID test was negative, though.) I cannot host the get-together tomorrow. Let's move the virtual get-together to NEXT WEEK at the same time: Sunday July 30, 11am-noon (US/Central) Too bad, I might not be able to make that one... :( Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Happy 29th anniversary to FreeDOS!
On 6/29/2023 4:24 PM, Jim Hall via Freedos-devel wrote: I've been experimenting with an updated website, and I'm considering going back to the original 1990s logo. We can use Blinky elsewhere on the website, but maybe a "throwback" logo would be cool? Well, as I have never been a fan of that cross-eyed pregnant guppy, I would say go got it... >:) Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Annoying bounce messages (list admin stuff)
On 6/29/2023 9:12 AM, Jim Hall via Freedos-devel wrote: I think the options are: 1. annoying bounce messages from SPF checks 2. "From" address shows up as the list address If anyone knows of a third option using Mailman (what SourceForge uses for the listserv) then please let me know. I know, seems like a Catch22 situation. At least now Thunderbird is showing the real sender as a CC: address once you select a message, so you know who actually sent it, but it totally takes away the possibility to sort by sender, for example when you are looking for a conversation with a specific sender. But there has to be a way, I am subscribed to a bunch of mailing lists, and this is the only one that behaves that way. Makes me kind of wonder what the FreePascal folks are using, with all those lists, this doesn't happen... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Annoying bounce messages (list admin stuff)
On 6/27/2023 2:28 PM, Jim Hall via Freedos-devel wrote: On Fri, Jun 23, 2023 at 3:38 PM Jim Hall wrote: Thanks to Mateusz for pointing out a mail list setting that we think will stop the annoying bounce messages. When you send an email to the email list, you might get a bounce message. This is because of a change at Gmail where they are now more strict about SPF. I made the change on freedos-user. If it seems to solve the problem there, I'll make the same change on freedos-devel. FYI that I've made the same change on freedos-devel. Let me know if there are problems. The solution was the "Munge the From email address" setting. Without it, the list server fails on strict SPF checking. Well, now it seems all messages in here also just show up as coming from "Technical discussions..." instead of showing the sender in my email client (latest version of Thunderbird, on both Windows and Linux)... :( Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
