OSDev.org

I am writing a new OS. I would like to know where i can find the latest version of TASM?

Thanx in advace

Casanova

http://info.borland.com/borlandcpp/cppc ... mfact.html

is the best i can find about TASM...

It's not cheap and i'm not aware of a TASM-only distribution ... so you might prefer NASM instead, if you don't need to import massive amount of TASM-written code ...

you could also try ebay to find eom disk sets.

(I mean this in a 100% completely legal meaning)

I just saw turbo c++ 3.0 for $19.00 brand new and full registerable.

Rich

You might also want to try "YASM", this is like NASM but capable of supporting TASM, MASM, GAS syntax.

TASM has problems with creating "flat" 32-bit code, so you'll probably still need NASM at some stage.

web address for YASM - http://www.tortall.net/projects/yasm/.

I started with Turbo Pascal + TASM back in the '80s. The platform was really aimed at DOS / REAL MODE. TASM can still be used to make PE/LE files but your OS will have to support these formats (plenty of tutes on the Goog). NASM generates ELF directly which might make your linking easier when you come to using C. (Unless you're attempting an all Assembler OS?)

oh, nasm is not limitted to ELves ...

valid output formats for -f are (`*' denotes default):
* bin flat-form binary files (e.g. DOS .COM, .SYS) multisection support test
aout Linux a.out object files
aoutb NetBSD/FreeBSD a.out object files
coff COFF (i386) object files (e.g. DJGPP for DOS)
elf ELF32 (i386) object files (e.g. Linux)
as86 Linux as86 (bin86 version 0.3) object files
obj MS-DOS 16-bit/32-bit OMF object files
win32 Microsoft Win32 (i386) object files
rdf Relocatable Dynamic Object File Format v2.0
ieee IEEE-695 (LADsoft variant) object file format

It works equally well in ancient-16-bits and nowadays-32-bits (dunno for x86-64)...

And it doesn't seem to support DWARF aswell

NASM does x86-64 and all those 'extras' Intel has added over the years since they don't like taking RISC's.

*All praise be to optimised compiler writers who shield us from the evil forces of microcode.*

I wonder if anyone still uses the 16-bit formats in for OSDEV? The only part I could think of would be a bootloader, possibly some VM86 code. Or someone stuck with an elderly *nix station who wants to port.

Hi,

Xardfir wrote: NASM does x86-64 and all those 'extras' Intel has added over the years since they don't like taking RISC's.

While NASM does handle everything else, it doesn't do AMD's 64 bit extensions (yet)...

There's YASM, which isn't complete, is compatible with NASM's syntax and does do AMD's 64 bit extensions.

Xardfir wrote: I wonder if anyone still uses the 16-bit formats in for OSDEV? The only part I could think of would be a bootloader, possibly some VM86 code. Or someone stuck with an elderly *nix station who wants to port.

I've written several boot loaders, a pile of setup/detection code (MP spec, APM, ACPI, VBE, BIOS fonts, capabilities & bugs of each CPU, determining which kernel to use, etc), a graphical boot configuration menu, a DOS utility to extract debugging markers and a DOS utility to copy binaries to floppy. It adds up over 64 Kb of 16 bit/real mode assembly, and is probably much more than most OS's..


Cheers,

Brendan

Aye, I definitely agree with the low level detection, +utilities. Black magic stuff most people ignore. I remember wondering why a 386 of mine wouldn't multiply right back in the '80s ....

It's probably a safe bet that your code runs on a lot more computers than mine as my code tends to have very loose 'sanity' checking.