Re: [Freedos-devel] No simple cpu identification program returning an error code as an answer?

Hello Bret Johnson, That's why I referred to both "playing" and "listening" in my original statement -- I did that on purpose. The _purpose_ of music is to be heard, not to merely be played (e.g., when no one is listening). The musicians are in fact deciding who can and can't listen to their

Re: [Freedos-devel] MS-DOS compatibility issue

Hello Jerome, Generally, I would not include an attachment. However, this is a tiny zip and includes the test source, build scripts and the compiled version. Well... I found that your ansitest.com still works with the FreeDOS 1.3 kernel + nansi.sys 4.0d. (I.e. there was no regression between

Re: [Freedos-devel] MS-DOS compatibility issue

Hello Jerome, The test works correctly under at least the most recent versions of MS-DOS (6.x), PC-DOS and DR-DOS. Thanks. Well, I could not reproduce whatever failure you were getting with your routine under FreeDOS. Without more information, it seems there is no good way to tell what exac

Re: [Freedos-devel] MS-DOS compatibility issue

Hello Ralf Quint, Well, not having comments to understand what you are doing is pretty tough when you don't have the time to analyze the code line by line. But IIRC, the common way to check for the presence of an ANSI device driver was to check via an INT 2Fh (multiplexer) call (don't recall the

Re: [Freedos-devel] MS-DOS compatibility issue

Hello Jerome, Basically, one of the versions of my ancient (written back in the early 90’s) Turbo Pascal directory listing programs used ANSI escape sequences to provide color. Instead of blindly assuming ANSI support is present, it first probes DOS to verify the functionality. It performs th

Re: [Freedos-devel] Another implementation of GRAFTABL

Hello Steve Nickolas, I suppose I could step on zero page (PSP) but I don't know how safe that is.  The graphics table is written at CS:0100-04FF (this could be why Microsoft's version is incompatible with mine, while mine is compatible with Microsoft's). The command line buffer starting at PS

Re: [Freedos-devel] Another implementation of GRAFTABL

Hello Bret Johnson, [me:] GRAFTABL basically just needs to install a 1024-byte glyph table somewhere in conventional memory, and point the int 0x1f vector at it. (The glyph table can then be used to display "extended ASCII" characters in a CGA graphics mode.)  There is no need to even install a

Re: [Freedos-devel] Another implementation of GRAFTABL

Hello Bret Johnson, [Steve Nickolas:] Stack allocation could be implicit. Don't know how NASM is handling this, as I wouldn't touch that one with a barge pole... ;-) Check the list file when assembling this.. In TSR's, the stack is NEVER implicit. It is something you must explicitly handle

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

Hello Jerome, Second… I really haven’t looked into this one at all. But, I think it would be possible to use Core Boot, SeaBios or something else to provide Legacy BIOS support ourselves on UEFI only systems. This would be a good deal of work. It also still leaves the problem of sound drivers

Re: [Freedos-devel] Fwd: ACPI auto power ON

Hello Bret, My overall point was that you can't turn on the PSU (to boot the computer) with ACPI because ACPI only starts working after the computer (main part of the motherboard) already has power and has booted an OS. You can't turn the PSU on with software (like ACPI) that requires the PS

Re: [Freedos-devel] Simple Senet v 1.0

Hello Jim, Can you also share your command line to build with IA-16 GCC and Libi86? I'm planning to remove the Makefile and instead create a BUILD.BAT file that builds everything from source. It's a small project; it doesn't need a Makefile. A simple BAT file will do the job just fine and will b

Re: [Freedos-devel] Simple Senet v 1.0

Hello Jim, If I swap the comparisons, the gcc-ia16 compiled program works correctly. Thanks! I've fixed it in source and checked the change into svn on SourceForge: https://sourceforge.net/p/simple-senet/code/HEAD/tree/trunk/src/senet.c#l138 Thank you! Can you also share your command line

Re: [Freedos-devel] Simple Senet v 1.0

Hello Jim, Specifically, under gcc with optimization (e.g. -Os), the compiler determined that `board[sq]' with sq >= 30 would be "undefined behaviour". Because of this, it decided to elide out the entire "You have moved all your pieces off the board" check. (And unfortunately, it did not give

Re: [Freedos-devel] Simple Senet v 1.0

Hello Jim, I think yes. It's a complete game - and since I've been playing *a lot of it* in the last two weeks, I'm pretty sure it's bug-free. Let's include it in FreeDOS 1.3. While trying to get Senet to build with gcc-ia16 + libi86, I came across a bit of a gremlin in the Senet code: for (s

Re: [Freedos-devel] PvP Gem game

Hello Jim, Over the last few days, I decided to write a little game, and I wanted to share it. I call it "PvP Gem" ["Player vs Player Gem"] and it's a two-player match-3 game. Thank you for the news! (-: Incidentally, I am in the middle of adding more of Open Watcom's functionality in my lib

Re: [Freedos-devel] Testing FreeDOS 1.3 RC5 (Games)

Hello Daniel, hello Jim, Thanks for the tests! Both games use a combination of kbhit + getch (with the arrow keys taking an extra getch, if the first one yields either 0 or 224). [...] Right now I'm writing a new real mode game (actually, a demake of my WIP protected mode game, https://monty

Re: [Freedos-devel] The FreeDOS Orphanage

Good day Mark Olesen, A centralized location is very serious to me as a developer. Actually, I bought an MS-DOS 7.1 disk on ebay because things kept moving too much in FreeDOS. It's not stable at all. Well, I think this problem is not really specific to FreeDOS. In fact I expect that the main

Re: [Freedos-devel] freecom beep crash question

Hello Eric, I notice that FreeCOM 0.84pre2 hangs after beeping, probably because it uses some method for timing the beep which fails on certain hardware. Could somebody tell me whether newer FreeCOM versions fix this by using a foolproof timer, for example the 40:6c timer tick counter? Is there

Re: [Freedos-devel] Fwd: DOS extenders with 32-bit INT 21H

Hello Eric, Given that CWSDPMI uses a different API, that DPMI16BI with RTM are 16 bit, that DPMIONE provides mainly bare DPMI, that there are other extenders I do not know about, I would indeed be curious what the landscape of DOS extenders is now and has been in the 1990s :-) Actually it is

Re: [Freedos-devel] Which assembley syntax is this?

Hello Paul, Anyway, I copy the file here of helloworld.s: === [warning -number-overflow] cpu 8086 bits 16 segment code align=16 push ds pop es mov ax, dgroup mov ds, ax call f9___m

Re: [Freedos-devel] Numerous problems with games and reboot (1.3RC4) on real hardware too

Hello Eric, It is normal that older types of queries return simplified descriptions of the state of the world, compared to newer types. So you could say it is the "fault" of DOS to not use the full BIOS list of areas. But as you already know, the int 12 or 40:13 method has worked fine for 40 yea

Re: [Freedos-devel] Numerous problems with games and reboot (1.3RC4) on real hardware too

Hello Eric, hello Paul, I think we don't see things the same way on that point. I believe my BIOS is not very special (AMIBIOS), just relatively recent. So I believe others are likely to encounter reserved memory in the memory area DOS normally use. You are the first person who has reported a r

Re: [Freedos-devel] FreeDOS kernel distro and package repository update moments?

Hello Tom, even if anyone else could compile this: how exactly would you test this? [...] I am not able to *immediatly*, or even *after some thought* see the problem. that doesn't mean it doesn't exist. it only means it's not easy to understand or reproduce. I am not _totally_ sure, but An

Re: [Freedos-devel] VBE/AI SDK released on GitHub, to celebrate the Google vs. Oracle SCOTUS decision 🥳

Hello Tom, hello Volkert, By the way, we could use some help "porting" the C/C++ code in the VBE/AI SDK so that it can be compiled by Open Watcom. Right now, the code contains "far pascal" keywords, which unfortunately are specific to Borland (Turbo) C/C++. as the FreeDOS kernel uses "far pasc

Re: [Freedos-devel] FreeDOS as a unikernel?

Hello Pablo, Sorry, now I understand what you say. I also works on UML source code too. Yes, UML intercepts system calls through ptrace, but instead of calling the host kernel, it calls the UML kernel. Therefore, no host system call is excecuted by the application process running insid

Re: [Freedos-devel] FreeDOS as a unikernel?

Hello Pablo, User Mode Linux actually works more like dosemu than it may seem. UML runs as a normal application under a host Linux system, of course. But when you run, say, /bin/ls within a UML session, UML will indeed intercept the syscalls made by the /bin/ls and transform them into the corr

Re: [Freedos-devel] FreeDOS as a unikernel?

Good day Pablo, Unikernels: they are minimal Library operating systems embeded with the application code. They provide networking, filesystem and virtual devices support. I think that if Linux could be converted in a executable (User Mode Linux) or in a library (LKL), FreeDOS may also be conv

Re: [Freedos-devel] Announcement: lDebug release 1

Hello Masloch, 1. Is this the right amount of sources? The macro collection, ldosboot, instsect, and scanptab repos' contents are not included, but they are required to rebuild everything. The tellsize tool is another component not included. (As listed in the LSM, I crosscompile from a (Debian)

Re: [Freedos-devel] Bloček Update

Hello Jerome, I downloaded the latest version and attempted to use it in DOSBox. However, running its executable it simply hesitated and returned to the command prompt. As someone who doesn’t use the program, I don’t know if it was a compatibility, configuration issue or what was the problem.

Re: [Freedos-devel] freecom bugs and bugfixes in forks?

Hello Eric, Hi! In case anybody has a FreeCOM toolchain and write access to the FDOS github, here is a list of bugs and fixes stolen from the web ;-) https://github.com/FDOS/freecom/issues Well, for a GitHub repository that I do not have write access to, what I normally do to propose patches

Re: [Freedos-devel] DOS runtime library format

Hello Steve Nickolas, I've had ideas for bootstrapping a DOS using a separate IPL - and in fact FreeDOS did do this at one point.  This way, I'd be able to keep basic drivers out of the main kernel, enhancing portability - which wouldn't be a big deal with PC-compatibles, since the basic driver

Re: [Freedos-devel] protected mode DOS / running Windows apps

Hello 0x0d, hello Eric, It's probably not, much. Night and FreeDOS-32 are both spare-time projects done for fun with the ultimate goal of running DOS software in 32-bit Protected Mode. However, I would say that Night most likely has a much more long-term support cycle. This isn't a research

Re: [Freedos-devel] Buffer overflow in core int 21 functions via ParseDosName / ConvertNameSZToName83 bug

Hello Eric, However, NEITHER the file name length NOR the length of the extension are checked for allowed length! I believe you could tell function 3d to open "textfiletxt" and it would in reality open "textfile.txt" because the 11 character basename overflows into the memory reserved for max 3

Re: [Freedos-devel] Fw: FYI: FreeType going forward looses 8.3 naming conventions

Hello Mark Olesen, hello Samuel V., https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/doslfn.html > Just run DOSLFN.COM whenever you want to access with long file name paths.> DJGPP 2 seems to support LFN. This ties in with a problem which I have been

Re: [Freedos-devel] GW-BASIC random numbers

Hello Steve, (2) to also add features found in later versions of GW-BASIC --- support for subdirectories, EGA/VGA screen modes, etc. etc. etc. --- and possibly to extend it even further (maybe even have it run natively on Linux?). It is good that the behavior of GW-BASIC, or more precisely BASI

Re: [Freedos-devel] GW-BASIC random numbers

Hello Jim, hello Steve, hello Akaydin, DEF SEG is necessary for BLOAD and BSAVE to operate on screen memory - I'll add that you can also do the "old skool" thing and do like we did in my Fortran77 programming days: prompt the user for a seed value, and pass that to RANDOMIZE. 10 PRINT "Enter a

Re: [Freedos-devel] GW-BASIC random numbers

Hello Jim, hello Steve, I didn't know how to report a bug to the GW-BASIC folks, but TK Chia hangs out on this list, so I thought I'd mention it here. I do not think there is any official support for channel any more, either at Microsoft, or anywhere else. Microsoft also stated t

Re: [Freedos-devel] Simplifying FreeDOS

Hello Steve, hello Random Liegh, Development; your decisions work for me. I never use perl on dos and I try to avoid djgpp and GCC-IA16. I end up needing NASM, JWASM, OW, UPX and FreeBASIC. Would it be possible to replace bwbasic with gw-basic? Technology-wise, I would think that Open Watcom i

[Freedos-devel] gcc-ia16 toolchain, 21 March 2020 version

Hello all, I have made another release of FreeDOS packages for the (unofficial) gcc-ia16 toolchain. The packages and release notes are available at both GitHub and GitLab: * https://github.com/tkchia/build-ia16/releases/tag/20200321 * https://gitlab.com/tkchia/build-ia16/-/releases/20200321

Re: [Freedos-devel] Frotz upstream updated to 2.50

Hello Mr. Griffith, Yeah, it's not totally hard (nor totally simple, if you dot all your i's and cross all your t's). Lots of files to vet/verify/confirm as free/libre, make sure it's reasonable, etc. Thanks again to Jerome and Jim for their hard work! Should I repackage my DOS Frotz package

[Freedos-devel] gcc-ia16 toolchain, 10 Oct 2019 version

Hello all, There is now a new release of FreeDOS packages for gcc-ia16, at https://github.com/tkchia/build-ia16/releases/tag/20191010 . The release notes are also available. Thank you! -- https://github.com/tkchia ___ Freedos-devel mailing list Fre

Re: [Freedos-devel] Inexplicable ambiguous name flags error from TurboC

Hello David, #define SET_WORD(addr, v) do {\ _AX = (v); \ asm les bx,zmp;\ asm add bx,addr;\ asm xchg al,ah;\ asm mov es:[bx],ax; } while (0) This will allow `v' to be pretty much any arbitrary C expression.  It uses the magic _AX variable which is specific to Turbo C (it w

Re: [Freedos-devel] Inexplicable ambiguous name flags error from TurboC

Hello Steve, hello David, SET_WORD(H_FLAGS, z_header.(struct zcode_header_struct)flags); I am quite sure this change should fix the problem on Turbo C.  But it seems to me that it will also inadvertently break the non-DOS ports, which do not define SET_WORD in terms of an asm { ... }. #ifde

Re: [Freedos-devel] Inexplicable ambiguous name flags error from TurboC

Hello Joe, hello David, Actually, I think, the help page is wrong about the qualification syntax. You have to change line 160 like this: SET_WORD(H_FLAGS, z_header.(z_header_t)flags); or SET_WORD(H_FLAGS, z_header.(struct zcode_header_struct)flags); I am quite sure this change should fix th

Re: [Freedos-devel] Kernel.asm question

). This is why counting 16-byte paragraphs is something that figures quite a lot in 16-bit code. Thank you! On 9/21/19 16:38, TK Chia wrote: Hello Quinton, hello Mark, I am looking at (I believe) a slightly more recent version of the FreeDOS kernel source code (https://github.com/FDOS/kernel

Re: [Freedos-devel] Kernel.asm question

Hello Quinton, hello Mark, I am looking at (I believe) a slightly more recent version of the FreeDOS kernel source code (https://github.com/FDOS/kernel), but I think the same reasoning applies. Basically the kernel is trying at this point to move its IGROUP (initialization code), I_GROUP (initia

Re: [Freedos-devel] LibreSSL port to FreeDOS

Hello Mark Olesen, https://github.com/markjolesen/openbsd As a side note, does anybody know what happened to OpenWatcom? I noticed their site no longer exists. I am not sure what happened to the original openwatcom.org web site. However, there is the "V2 fork" (https://github.com/open-watcom/)

Re: [Freedos-devel] Application to check DOS API compatibility

Hello Rugxulo, hello Mercury 13, Of course, you could just always rather test the "big dogs" of the DOS world: Turbo C, Lotus 1-2-3, Doom, QBASIC, etc I don't know of a good list of tools off-hand, but obviously things like DJGPP or OpenWatcom or FASM (or maybe small *nix utils like sed) m

Re: [Freedos-devel] UTF-8 input and output

Hello Steve Nickolas, May I know what particular method(s) and data you use to do the conversions?  I was thinking that something like POSIX iconv( ) will come in useful, but Open Watcom does not seem to have such a function. I had some function that went through a byte at a time.  I think it c

[Freedos-devel] gcc-ia16 toolchain, 21 May 2019 version

Hello all, There is now a new release of FreeDOS packages for gcc-ia16, at https://github.com/tkchia/build-ia16/releases/tag/20190520 . The release notes are also available. Thank you! -- https://github.com/tkchia/ ___ Freedos-devel mailing list Fr

Re: [Freedos-devel] UTF-8 input and output

Hello Steve Nickolas, My IRC client (which runs fine on a 386/16 at least) internally translates from UTF-8 -> UCS-2 -> native codepage (usually CP437). May I know what particular method(s) and data you use to do the conversions? I was thinking that something like POSIX iconv( ) will come in

[Freedos-devel] gcc-ia16 toolchain, 10 Apr 2019 version

Hello all, There is now a new release of FreeDOS packages for gcc-ia16, at https://github.com/tkchia/build-ia16/releases/tag/20190310-update-20190410 . The release notes are also available. Thank you! -- https://github.com/tkchia/ ___ Freedos-devel

Re: [Freedos-devel] default (lack of) buffering in Turbo C 2.01 (e.g. Cheap Sed)

Hello Rugxulo, It wasn't clear what is not buffered. Is TurboC 2.0.1 itself (the compiler, linker, make, etc.)? Or TurboC 2.0.1's runtime? It's been a while since I've looked into it. I'm not quite a true standards expert (BUFSIZ ??), so my understanding is limited. But I meant runtime as in

Re: [Freedos-devel] gcc-ia16 toolchain, 10 Mar 2019 version (bug fix release)

Hello Tom, may I suggest the following trick (it was used (not necessarily invented by) by MSC in ~1990): the compiler knows when a module uses floating point; float x = 1.0; or someFunction(1.3); qualifies as 'uses floating point stuff' ... the floating point sprintf stuff was only lin

Re: [Freedos-devel] gcc-ia16 toolchain, 10 Mar 2019 version (bug fix release)

Hello Rugxulo, I wasn't linking it correctly. (Have to be careful about external symbols, link order, etc.) And even when I thought I got it working, it ended up crashing. Luckily I had my own replacement (simply for printf("%ld") only). So my old replacement itself saved me like 25 kb (down to

Re: [Freedos-devel] gcc-ia16 toolchain, 10 Mar 2019 version (bug fix release)

Hello Rugxulo, Have you seen this before? (Honestly, I tried but failed to use it correctly here. I'll have to try again later.) It seems intriguing for such "embedded" targets. (Not a deadly problem with multi-seg .EXE generation, but still ... bloat! Heh.) * https://github.com/DarkWishMaster/T

Re: [Freedos-devel] Centroid command.com license confirmed

whatever your plans with this GPL3 software: there will not be a place in freedos. PLEASE.GO.AWAY. (and stay there for the rest of my life) "Gentlemen, you can't fight in here! This Is the War Room!" -- https://github.com/tkchia ___ Freedos-

[Freedos-devel] gcc-ia16 toolchain, 10 Mar 2019 version (bug fix release)

Hello all, I have uploaded a new set of FreeDOS packages of the gcc-ia16 toolchain, at https://github.com/tkchia/build-ia16/releases/tag/20190310 . This release mainly fixes a bug which was causing GCC to output incorrect code for certain integer comparisons. Thank you! -- https://github.co

Re: [Freedos-devel] gcc-ia16 toolchain, 24 Feb 2019 version

Hello Rugxulo, I have put out a new release of FreeDOS packages for the gcc-ia16 toolchain, at https://github.com/tkchia/build-ia16/releases/tag/20190224 . Are you sure you set the prefix correctly? It seems to not find crtbegin.o (etc). But maybe I'm doing something wrong (probably). Argh!

[Freedos-devel] gcc-ia16 toolchain, 24 Feb 2019 version (was: Re: Do FreeDOS in the Cloud)

Hello all, Thank you!  I have uploaded new packages for the gcc-ia16 toolchain, at https://github.com/tkchia/build-ia16/releases/tag/20190101 . I have put out a new release of FreeDOS packages for the gcc-ia16 toolchain, at https://github.com/tkchia/build-ia16/releases/tag/20190224 . The re

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hello Bart, new (just changed by TK Chia) https://github.com/tkchia/newlib-ia16/blob/newlib-2_4_0-ia16-tkchia/libgloss/ia16/dos-sbrk.c malloc returns NULL when the end of the heap is reached but this is not always checked properly in freecom, but at least it does not grow into the stack any

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hello Bart, thanks for offering to help. I now pushed a GCC-portable version of Tom's stack check to freecom's git: https://github.com/FDOS/freecom However if you try to compile it you'll see once you run it that it says 0 stack left quite quickly. The reason is not the stack (there is plenty) b

Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease

Hello Bart Oldeman, The OW version looked reasonably stable, the GCC version still ran into some issues if I remember correctly. Hopefully I can get around uploading a new prerelease sometime this weekend, and make it the real release if it works ok. Do let me know if I might be of any help, e

Re: [Freedos-devel] Do FreeDOS in the Cloud

Hello Jim, Github pages aren't working for me at the moment, but maybe that's a network resolution problem on my end? I'm looking for release notes or similar that I could use to announce your updated gcc-ia16 toolchain on the FreeDOS website. Or should I just use the notes you included here:

Re: [Freedos-devel] Do FreeDOS in the Cloud

Hello all, On my end, I have tweaked my gcc-ia16 toolchain build files, to avoid multi-line descriptions in the .lsm's for now. I guess though that it is a bit late into the FreeDOS 1.3 release schedule to have this change included... The 1.3 release is a little behind schedule and RC1 hasn’

Re: [Freedos-devel] Do FreeDOS in the Cloud

Hello Jerome, The short answer is — At present, the online repo management tools do not support multi-line descriptors. Everything after the first line is ignored. So, stuff on additional lines is excluded from the automatically generated web pages, rss feed and listing.csv files. This is most

Re: [Freedos-devel] aefdisk/masterbooter open sourced

Hello Nils, also it is very small (your exe ~17k). What about having watcom producing a com file? This would save a few bytes for the exe header. As exe is not necessary (I assume) this would be nice. Is there are reason for having exe? No particular reason that I know of, but I have not rea

Re: [Freedos-devel] aefdisk/masterbooter open sourced

Hello all, But I opened a ticket for Nagy Daniel (https://github.com/nagydjol/aefdisk/issues/1) Asking his tasm/borland c compiler Maybe we could integrate it on freedos repository or even deprecate our fdisk in favor of aefdisk in future Thank you!  I am also curious to know which version(s) of

Re: [Freedos-devel] Do FreeDOS in the Cloud

Hello thraex, Looking at all this scrolling text (after the make clean translate all command), I noticed that some packages (edict, fdtui and others) didn't have their descriptions translated, so I updated the French and Turkish versions of listing.csv. You can download the archive containing th

Re: [Freedos-devel] aefdisk/masterbooter open sourced

Hello Geraldo, First of all, hope you all had a great christmas time! This is interesting. It seems the aefdisk sources are using some strange syntax extensions which I have not seen before --- perhaps these are supported by certain versions of tasm? Dunno :( But I opened a ticket for Nagy Dan

Re: [Freedos-devel] [Freedos-user] aefdisk/masterbooter open sourced

Hello Jerome, hello Geraldo, Seems to require borland c/tasm Unfortunately, aefdisk won’t compile under TASM 4.1. Tried. But, It throws a couple errors and warnings. This is interesting. It seems the aefdisk sources are using some strange syntax extensions which I have not seen before --- p

[Freedos-devel] 2 projects of mine of possible use to DOS coders (was: Re: gcc-ia16 packaging)

Good day all, I would just like to bring up two projects which I have been working on, and which I hope might be of use to others: (*) "DOSEmu on Travis CI" (https://github.com/tkchia/dosemu-on-travis-ci) is a small bit of code meant to ease automated testing of DOS programs: it gets Linux D

Re: [Freedos-devel] FreeDOS 1.3 list of packages

Hello Jim, hello Harald, > FYI: I've posted Harald's port of GNU Tail on our ibiblio archive. You > can find it at http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/tail/c/ > > Thanks! Apologies for the late note --- but can we confirm that the posted code is indeed from the G

Re: [Freedos-devel] FreeDOS 1.3 list of packages

Hello Mr. Jim Hall, I'd appreciate a discussion here about these programs and my evaluations of their licenses. Especially the ones in red ("no") or yellow ("maybe"). Do you agree with the decisions here? What are your thoughts on the ones I marked in yellow? Thank you for the work! I would j

Re: [Freedos-devel] gcc-ia16 packaging

Hello Eric, Please be more specific about the amount of space saved. Some quick figures: by using LZMA compression instead of Deflate compression (at the maximum compression level), I found that the gcc-ia16 package files' sizes were reduced thus: (*) i16budoc.zip: 765,363 -> 640,309 bytes (

Re: [Freedos-devel] gcc-ia16 packaging

Hello Mr. Jim Hall, I'm very excited to try this! I'm at a conference and won't be at my > regular computer for a week, but I'll try it then.> And yes, this is a great tool to include in the FreeDOS 1.3 distribution. Thank you very much! -- https://github.com/tkchia

Re: [Freedos-devel] gcc-ia16 packaging

Hello Mr. Andris, Please ensure that archives can be extracted using unzip: [andris@ap 1]$ unzip i16gcc.zip Archive:  i16gcc.zip    skipping: APPINFO/I16GCC.LSM  need PK compat. v6.3 (can do v4.6) ... It is perhaps not nice to require to use pkunzip Yes, Info-Zip does not yet support LZ

Re: [Freedos-devel] gcc-ia16 packaging

Hello all, Thank you!  I have uploaded an updated package set at > https://github.com/tkchia/build-ia16/releases/tag/20180728-redist-djgpp . I have uploaded a new, updated package set for the gcc-ia16 toolchain at https://github.com/tkchia/build-ia16/releases/tag/20181014 . The updated gc

Re: [Freedos-devel] UNIX fortune for DOS

Hello Rugxulo, In other words, you're saying only development of the operating system itself should be discussed here, not third-party userland stuff?? Somehow I disagree, and again, if this is so bothersome to you, set a filter on your email client. There's already too few developers, and we do

Re: [Freedos-devel] I have a quite small pong game to offer for including in FreeDOS

Hello all, No idea. Are you sure you didn't upload the wrong version? Try manually re-downloading it from GitHub, and see what that specific version does for you. I had only a cursory look at the source, but the BIOS calls are so trivial that it should work everywhere. These are functions that

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hello Bart, I fixed this issue now. There were issues with #pragma aux for OW and for GCC inline asm. The si parameter for XMScopy was not passed correctly for OW (likewise for DS for GCC), which meant that most XMScopy calls failed. However it would work by accident because the strings usually

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hello Bart, now if the size of command.com in memory ever changes, to little is saved/restored. I think it is related somewhere to MCB corruption but still not sure where. Somehow it happens after the strings are copied back in from XMS. I`ll still have to dig deeper. I have just checked in t

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hello Tom, unfortunately (thanks TK CHIA) sbreak() tries to increase the size for malloc'ed memory. if it succeeds (and needed memory is located behind SwapTransientSize: BAMM! Thank you! I did find a bug concerning the swapping of the transient portion to XMS, though it is of a diff

Re: [Freedos-devel] Does Digital Mars C/C++ compiler able to compile FreeDOS kernel, FreeCOM, and others?

Hello Mr. McMackins, Mr. Quint, Rugxulo, And the "one guy pays, everyone else plays" statement you made is totally bollocks, and you should know it. Bollocks in what sense? In a legal sense, you couldn't be more wrong. Now you do say that you're not an attorney, so perhaps you should talk to on

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hello all, I am still getting some very weird observations when look into why FreeCOM weirds out: When I recompiled FreeCOM on my end with GCC, and tried to run "fetch mem" inside the METADOS setup, the command.com grew the heap area very quickly when handling the complex batch files, and th

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hello Tom, hello Rugxulo, METADOS is a very advanced, very spaghetti BATCH project, which in the end connects you with TCP, downloads components (MEM.EXE below) from the internet and more interesting stuff. unfortunately, *very* spaghetti. .BAT doesn't have loops. It overuses "goto". It's not T

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hello all, Meanwhile, for some reason I am also getting this error when starting commandg.com under DOSBox (0.74-4.2 on Ubuntu):   [Out of memory loading STRINGS.]   Failed to load the strings resources into memory, the location   pointed to in %COMSPEC% seems to be invalid. Please specify a

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

Hello Ruxgulo, hello Bart, Thanks for your efforts, of course, but ... it's still got some bugs. The Watcom build runs faster (oddly), but my TESTS.BAT just silently fails. And the others (Turbo and GCC) seem to later on cause "Invalid Opcode". So I haven't weakly tried isolating that yet. I get

Re: [Freedos-devel] Larger buffers in Watcom

Hello Mr. McMackins, hello Mr. Viste, I found the bad code. While your example works, if I change it to use calloc (which is what my code is using at the particular failure point), then it fails. Looks like calloc is doing something funny. Actually, I just found that both malloc( ) and calloc(

Re: [Freedos-devel] Larger buffers in Watcom

Hello Mr. McMackins, Is there a way to allocate a buffer in OpenWatcom that is larger than 64k? I'm currently trying to stay within the compact memory model, but even if I compile for huge memory model, I'm getting an out of memory error for trying to allocate about 80k for a buffer. My machine

[Freedos-devel] gcc-ia16 packaging (was: Re: Starting FreeDOS 1.3)

Hello Rugxulo, hello Mr. Mateusz Viste, Actually, you should be able to use LZMA compression in the main .ZIP itself to squeeze some more space. I don't recall if any other packages used that (yet). I think Mateusz was vaguely worried about wasting dozens of MB of RAM just to unpack. Using LZMA

Re: [Freedos-devel] Starting FreeDOS 1.3

Hello Rugxulo, The dependencies needed to build GCC are GMP, GNU MPFR, GNU MPC, and the Integer Set Library (ISL) --- which fetch.sh also downloads. build.sh will build these twice, once for the Ubuntu platform (for stage1), and once for DJGPP (for stage2). I forgot to mention another depen

Re: [Freedos-devel] Starting FreeDOS 1.3

Hello Rugxulo, Please don't feel pressure from me about this, but "build-ia16-20180616-update-20180708.zip" (35 kb) is only some small files, not the full sources. Obviously the rest is on Github. But what exactly do you need to rebuild this? (I probably won't try, just curious anyways.) Ubuntu

Re: [Freedos-devel] VGA frame rates and mouse

Hello Mr. McMackins, Indeed. Do you use a fast way of writing the graphics memory, such as the "string and block processing" Assembly language commands or at least a library function in the programming language of your choice which internally uses them? No. In fact, my copying routine is extra

Re: [Freedos-devel] Starting FreeDOS 1.3

Hello all, I have uploaded updated packages at https://github.com/tkchia/build-ia16/releases/tag/20180616-update-20180708 . Thank you! On 07/17/2018 05:55 AM, Jim Hall wrote: I'd love to see these included in FreeDOS 1.3. I have had this on the Contribute

Re: [Freedos-devel] Starting FreeDOS 1.3

Hello all, Thank you. I have uploaded some packages for a gcc-ia16 toolchain, at https://github.com/tkchia/build-ia16/releases/tag/20180612-redist-djgpp . The toolchain requires a 32-bit machine to run, but the programs they output will be 16-bit. The current packages do not include some r

Re: [Freedos-devel] Good BASIC interpreter?

Hello Mr. McMackins, I guess I am a little late with this --- but I had recently been checking out some existing BASIC implementation projects, and I think there might be a few BASICs which can be ported, with some effort. For example there is the "Minimal BASIC Compiler" (http://buraphakit.

Re: [Freedos-devel] Watcom COM format directive

Hello Rugxulo, This is interesting --- thanks! For my part, I found that `wcl' with `-l=com' does indeed work on my machine. Apparently `wcl -l=com' will actually pass `system com' (instead of `format dos com') to `wlink'. I am not sure how `format dos com' works (if it is supposed to work

Re: [Freedos-devel] Decompressing the FreeDOS kernel

Hello Mercury 13, Yes, the FreeDOS kernel is compressed with UPX --- but there are some preprocessing and postprocessing steps done to the uncompressed kernel code, before and after it is passed through UPX. Bart Oldeman's utils/exeflat.c program in the kernel sources is responsible for doin

Re: [Freedos-devel] VGA/VESA vblank interrupt?

Hello Mr. Bertho, Thanks for the tips. However, I suspect that knowing when exactly vertical retraces occur is still relevant to modern monitors (and OSes), where one needs to prevent "screen tearing" and other nasty artefacts. So I would think it is still useful to know how to do it right.

  1   2   >