• Please review our updated Terms and Rules here

Search results

  1. K

    Calling function in interrupt hander

    You need to use "wdis" to disassemble the object code. By default it isn't reassemblable, but there is an option to make it so if required.
  2. K

    Calling function in interrupt hander

    I think large is normally sufficient, right? You only need huge if you're accessing a single data structure bigger than 64k?
  3. K

    Calling function in interrupt hander

    I spent some time looking at your code, but couldn't see anything wrong with it. I then compared it to some code that someone else gave me (which is CC0 so you can do whatever you want with it): https://sourceforge.net/p/pdos/gitcode/ci/master/tree/util/mspop.c And the only thing I noticed...
  4. K

    PDOS now stable

    As of about a day ago, I fixed the last known reproducible integrity bug, and as a result, PDOS is now nominally stable, and able to reproduce both PDOS/386 itself, and the tools used to produce it, including GCC 3.2.3. Available from http://pdos.org
  5. K

    PDOS/86 now huge!

    Another thing to note is that now that I have made the code standard, removing from my source code the hardcoded 4-bit shifts, I'm planning on supporting the Turbo 186 with 8-bit shifts, and doing the equivalent with selectors for the 80286. I'm envisioning no change in the MZ executable format...
  6. K

    PDOS/86 now huge!

    This is an OS that I am writing, so the single data structure is the entire 640k. I need to manage that memory. And I already have C90-compliant memory management routines, but with size_t sitting at 64k, they weren't usable. Well, I refused to change my perfectly valid code and found a way to...
  7. K

    PDOS/86 now huge!

    Correct, and it also (well, I did in my (PDPCLIB) routines, because I thought it was a requirement, but I'm not totally sure it's a requirement) normalizes the pointers in that process, so that the offset is less than 16. I think that is so that comparisons can be done efficiently.
  8. K

    PDOS/86 now huge!

    Circa 1994 I didn't know what "huge" memory model was, and selected "large" to write PDOS/86 in. I then found that my already-written memory management routines didn't allow me to manage more than 64k of memory. Rather than change my routines, I hacked PDOS/86 to get more than 64k of memory...
  9. K

    1983 - coming ready or not

    It is something along those lines, but I would add some corrections/clarifications. There are two challenges - 8086 and 80386. This thread started on the 8086 (1983), rather than the 80386 (1986). It is my expectation that in 1983 you should be able to write in C for the 8086, but write in a...
  10. K

    1983 - coming ready or not

    Are you sure it is a lot of work? Each SubC target is about 300 lines of code. And it's not necessarily "pseudo 32-bit". Memory access already uses two 16-bit registers (that's the 8086 design) and 32-bit ints would be a different register pair (dx + ax or whatever). Having said that, I may...
  11. K

    1983 - coming ready or not

    Feel free to work off the back of my public domain work. That's why it exists. So you don't have to start your project from scratch and pass those costs on to the consumer. I don't currently, but someone else might. Or I might in the future. I don't consider people using my public domain code...
  12. K

    1983 - coming ready or not

    Not if I want to protect my changes/work by making it closed source. Or if I wish to violate any of the other 573 conditions of the GPL. Or even if my team of lawyers thinks I'm not violating any of them, but the copyright holder disagrees and then it comes down the whim of a random judge in a...
  13. K

    1983 - coming ready or not

    Yes, it matters, because I may wish to enhance it and produce a commercial product. Or someone else might. A better question is does it matter if DJGPP is released to the public domain?
  14. K

    1983 - coming ready or not

    DJGPP is copyrighted (owned by the authors, not the public), and will only be owned by the public (ie be public domain) 70 years after the death of the authors. SubC was released to the public domain by the author, so we don't need to wait for him to die, and then wait another 70 years.
  15. K

    1983 - coming ready or not

    Yep. After 50 years of C, that is the most advanced C compiler that the public owns. It *may* be *just* good enough that you can program in it instead of needing to resort to machine code, if you are restricted to a pure public domain environment.
  16. K

    1983 - coming ready or not

    I am not claiming that the C version would be better than the assembler version. But maybe the C version would still be adequate, depending on your needs. A normal price/performance tradeoff. However, the 640k RAM limitation will be lifted in 1984 with the PC AT, where it becomes 16 MB (and...
  17. K

    1983 - coming ready or not

    I agree that that should be the first thing done - bring SubC closer to C90. But rather than a VM, I was planning on getting it to generate huge memory model code. Isn't that a better option?
  18. K

    Is Turbo C available?

    Are you for example interested in playing with SubC? I can see that the included 8086 assembler started from 1993, so that's 29 years. I don't know when work started on the included C compiler. Or does it need to be the specific tools you personally used 20-30 years ago? I'm just curious as to...
  19. K

    1983 - coming ready or not

    Note that PDOS/86 ships with SubC, which is a pretty large subset of C90, and public domain. DeSmet is copyrighted. SubC includes an assembler/archiver/linker, also public domain.
  20. K

    1983 - coming ready or not

    I doubt that anyone starts with assembler. You can instead just use someone else's C compiler, even if it runs on a different processor. The very first C compiler would need to be (and was) written in a different language though, but not assembler. I guess if we were restarting the entire...
Top