The Fix for cc65
This was discussed in cc65 issue #946 and fixed by
cc65 PR #965. That was merged to the master branch on
2019-10-26, and should appear in V2.19 of cc65. (I don't know when
that release will happen, however; it's been five months since the
It is, however, quite easy to do your own build of cc65 if you want to
use the master ...
You seem to be proposing a custom HDD "driver" that would image the HDD block-by-block by sending those blocks across a serial port to some sort of process running on your modern computer that assembles the blocks into an image file. This could be error prone and time consuming to implement.
An alternative suggestion is to use a legacy DOS Utility, such as ...
These are OMF libraries; you can analyse them with Agner Fog’s object file converter.
It probably only makes sense to work with those libraries if you intend to build software with Microsoft C 5.1, in which case you’d use the tools provided with the compiler (LIB.EXE in particular).
The OMF format is described in detail in OMF: Relocatable Object Module ...
I don’t think there’s a surefire way to detect the memory model being used at run-time, or even adjust code post-build in an object during linking. Libraries were provided in multiple variants, one for each supported memory model.
It is however possible to write code which will adjust to different memory models at build time, so a single assembly file can ...
You’re correct, the goal of this code is to ensure that the allocated buffer is entirely contained within the same DMA segment (DMA operates on 64KiB segments, not to be confused with the 16-byte-aligned real-mode segments of the x86 addressing model).
The assumption that the allocator returns successive blocks is safe, at least before the heap gets ...
I am trying to find the source code for the earliest implementation of the stack data structure in C
There is no stack data structure in C. Look through the language specification and you won't find it there. If you were a programmer and you wanted a stack, you had to implement your own. If you go back to the beginnings of C and look at all the code that ...
SDCC "supports" the restrict keyword as a requirement of supporting C11. Supporting C11 allows it to compile code written for other modern compilers more easily. Programmers may also use restrict as a means of having the compiler check certain aspects of their work, reducing the number of difficult-to-diagnose bugs they introduce.
Due to the simplicity of ...
Given a function declaration like
void far copyAnywhere(void far *dest, void far *src, unsigned len);
it will be usable from within any memory model except huge. If called from within e.g. small model code, passing non-qualified pointers, the generated machine code would look something like (arguments are pushed right to left)
; Set up argument len
So bare metal, no OS?
On both systems, console terminal I/O is considerably easier than any other terminal interface.
On many VAXen, there's a couple of processor registers that are status and data registers for console I/O. Much easier than dealing with DZ-11 or similar.
Here's the important part of a VAX 'putchar' routine from a standalone libc I wrote in ...
void xms_move_xmb_internal(unsigned int ds, unsigned int si)
_AX = 0x0B00;
_DS = ds;
_SI = si;
looks like a bad idea. The compiler assumes DS to point to the global data segment of your program. In the large memory model, the stack segment can differ (I don't remember the default) from the data segment. ...
It's not really clear in what context the question is asked, so I'll try to go along.
Should C be regarded as an intermediate language on a virtual machine named PDP-11 Architecture (which have a plain memory space and stacks), like opcode to jvm, msil to dotnet, asm.js to v8, which has to be translated and optimized for real machines of different ...
The problem is that you're trying to access the function parameter data, but the compiler does not expose that as a symbol to the internal assembler, so it's looking in the public, global namespace for it -- and can't find it.
According to SDCC - Interfacing with Z80 assembler code, you do indeed need to access the parameters from the stack. I don't know if ...
You can't really detect the memory model the C code was compiled with at runtime. I suppose you check some sort of variable that indicates what model was used but you'd be constantly testing it in your assembly code making your code horribly inefficient. A much better way to handle multiple memory models with a library is to assemble a separate version of ...
Preface: I just commented in support of my close request, that the question is, in its current way, as well as in any simple rephrasing I could think, of off-topic for RC.SE due its recent nature of C11 as well as SDCC. Both of the questions voiced at the end are about the same non-RC.SE quality.
Following Stéphane's intend for rephrase I came to think that ...
With newlib it seems you have to explicitly state that you want to include the floating point formatter with a pragma, just add:
#pragma printf %f
to the source code. That way it will work with both sccz80 and zsdcc as the compiler. By default the integer converters are included.
sccz80 does format detection, but this is only picked up the classic library....
One of the complications with z88dk is that there are two libraries: classic and newlib. These days, a lot of the code is shared but there are two separate implementations of stdio and console drivers. The comment about "ROM driver" is referring to how classic scrolls the screen: it just calls address 3582 in ROM3 by default.
However, the compile line ...
I'm actually attempting to do this right now, so I figured I'd add what I found so far.
Looks like one attempt to do this was https://github.com/tschak909/disk-xfer. It supports a Xmodem-style CRC16 on each sector, but it doesn't appear to support working around bad sectors like ddrescue does. It also doesn't have much of a user interface on the DOS side, ...
Depending on the intent of the question, the requested TUI library that works on different platforms and compilers, and is similar to Turbo Vision might be Turbo Vision itself, or more specific, a port of Turbo Vision.
It seems Borland put the C++ sources of Turbo Vision into the public domain in one of the developments caused by this is a port that runs on ...
This is how I did it in an old program I wrote to exercise my knowledge of the DMA DSP of the Sound Blaster, back in 1996.
char *AllocDMABuffer (void)
unsigned int Segm;
while (Segm & 0x0FFF)
For this specific ...
The z88dk does not differentiate between float or double, at least with its own compiler; the SDCC backend is another beast.
Some years ago I played around with the z88dk, targetting the ZX81. I was kind of disappointed that its implementation of printf() does not support floating point data types. It might have changed in the meantime, but I'm afraid that ...
I actually wrote a program a while back to image a hard drive in DOS and send the result over serial. However, It uses "new" extended BIOS methods based on LBA adresses rather than traditional C/H/S sectors, so I doubt it will work with an MFM-era machine.
The data is sent using run length encoding on 0s to speed ...
As mentioned in the comments, data can’t be entirely hidden in C, there is no concept of “public” v. “private” members of data structures. Members can be hidden in practice using pointers to opaque data structures (see for example FILE), but that’s only a “gentleman’s agreement”.
When looking for early implementations in C, your best bet is to dig in the ...
My understanding is that the stack is provided at the architectural level, eg it is built in to the processor in the form of a stack pointer and relevant operators. It is not a language level concept, in the way that other data structures may be.
I know of the 13h interrupt, which would allow me to read raw data off of the drive, but I don't know how to get the parameters in order to call this function(sector, cylinder, head, drive).
INT 13h is actually a set of routines; which one is called is determined by AH. (That list on Wikipedia covers various extensions as well, you won't have all of those ...
This appears to be triggered by my answer to another question, in which I asserted that C was originally conceived as a "portable assembly language" with the PDP-11 in mind. This does not at all mean that C should be thought of as targetting a virtual PDP-11. Rather, the PDP-11 had a relatively complete feature set, which was used as a model for ...
Turbo Vision is probably your best bet.
Borland released the C++ port of it into the public domain and there's a GPLed descendant of that public domain release on SourceForge or a less advanced BSD-licensed one on Sergio Sigala's website.
The GPLed version is listed as compatible with "DOS, FreeBSD, Linux, QNX, Solaris and Win32" via the Borland C++, GCC, ...
To make the various steps in Michael's answer explicit:
To call indirectly to another segment, ES:BX needs to contain the address of xms_driver.
DS is invalid after inline asm/pseudo-variable assigment, so xms_driver has to be inspected first.
This is the result:
void xms_move_xmb_internal(moveparams *params_ptr)
asm push es
asm push ds
No, by definition an intermediate language would be just that -- intermediate; a step in translation. C was designed, and in practice, actually used, as a high-level systems programming language. Unix (and other operating systems), compilers, user applications and all other kinds of software were, and still are, written directly in C.
C only became a ...
The combination of functions to move the cursor, select text color, and read a key made most parts of a UI sufficiently easy to design and implement that there was far less need for automated tools than when designing a windowed application. About the only thing missing would have been a good function to accept an input line with cursor editing, but there ...