Recent content by BloodyCactus

it was specific to the original post which was not built with large memory model, AFAIR. obviously far is not needed in a large memory model as all pointers are then far by default.

I took your dos call out and just used the library function farmalloc. I had it allocate 400KB and then the 64k.. no problems. is there a reason you want to use dos 48? I suspect there is an issue with turbo c's heap, i ran debugger over it and it was doing something weird in its internal call...

hmmm that does not sound correct at all. I do it all the time with watcomc. its been a long time since I used turboc, but should not make any difference. I just did a test (turboc 2.01), works perfectly fine for me; compile with "tcc -ml" #include <stdio.h> #include <stdlib.h> #include <dos.h>...

I think this is your problem, you need to declare it as a far pointer, regardless of the memory model your using. you will probably run into issues if you use things like memmove because they expect pointers in their native memory model, unless its smart enough to start doing conversions. byte...

ok heres an example of doing the cdecl calls from c<>asm<>c. C calls into our assembler, which calls printf back in C land. below is a build.bat file, x.asm and q.c that i knocked out --build.bat-- nasm x.asm -fobj -o x.obj wcc386 -oneatx -ecc -3 q.c wlink name test.exe debug all option...

i would guess, you need to shim the message as code (.text) and not a string (aka .data). because when you link it, it will link text/code, data, then bss. and if you have strings, they are data. watcom can compile strings into code, but it probably wont be positioned as you want. you need to...

well if your using watcom you need to know it has a dozen calling conventions and it depends on who is calling whom... -ec{c,d,f,p,r,s,w} c - __cdecl d - __stdcall f - __fastcall p - __pascal r - __fortran s -...

the problem with most of those modes is, they often use either B000 or A000 for memory instead of the more common b800, and tihs messes up most anything expecting to talk to the screen.. so other programins printing to stdout, most of it goes through int 0x29, which is a front end to going out...

I always use stdint.h + inttypes.h and size_t. it gets annoying when you dump say an ftell() into a uint32_t and its good on a few platforms then and one says noo i need size_t for that..

Ive tried 3com 3c905B-TX + 3c905C-TX PCI nic packet drivers are fine. no ndis, no odi, just packet driver loaded high!

extra size... so did you strip debug information off the executable?

if save_DS is a memory location, and your just a .COM, you probably want cs: mov ax, save_DS because you have no idea where DS is currently set.

I just wrote a test, and your correct, changing svga_s3 to mcga ... my 5 line test asm did nothing. thats not what I expected either. could probably log it as a bug on the DBX github.

that function 0x1100, absolutely does work under dosbox-x and dosbox.

I dont know about MCGA but I run fonts in VGA all the time. AX = 1100h ES:BP -> user table CX = count of patterns to store DX = character offset into map 2 block BL = block to load in map 2 BH = number of bytes per character pattern ;; es:bp -> text mode font mov ax,0x1100 mov bx,0x1000 mov...