Show HN: 8086/8088 assembler that runs over 8088 hardware with modern syntax | Hacker News Reader

Show HN: 8086/8088 assembler that runs over 8088 hardware with modern syntax

github.com

132 pointsnanochess19 comments

For those who are unfamiliar, Óscar Toledo G. (and his family) are all world-class hackers (and teachers) when it comes to low-level computing[1]. I learned about his family's work (as well as his own) on this website[2].

1 = http://www.biyubi.com/tecnologia.html#resumen

2 = https://news.ycombinator.com/item?id=20570154

I'm a little surprised that it wasn't itself written in Asm (and thus has the possibility to be self-assembling), and the binary is almost 30KB. That may seem tiny today, but in the 8086/8088 era, it's huge; the first IBM PC in its minimum configuration had only 16K RAM.

For a more "authentic" 8088 experience, you could use the assembler that came with MS-DOS 1.25, written by Tim Paterson:

https://github.com/microsoft/MS-DOS/blob/master/v1.25/source...

> I'm a little surprised that it wasn't itself written in Asm

I'm not, it's just not worth the effort.

> in the 8086/8088 era, it's huge; the first IBM PC in its minimum configuration had only 16K RAM.

It's really not needed today.

> For a more "authentic" 8088 experience, you could use the assembler that came with MS-DOS 1.25, written by Tim Paterson

The author here wanted just his own .asm sources to assemble natively, and not using nasm, and if I understand correctly they indeed depend on the features not present in the old assembler, he writes:

"nasm doesn't run over 8086/8088 processors, and I couldn't find a compatible assembler!"

It's not that he couldn't find any assembler, but that he couldn't find one that understands the features from nasm he used.

The minimum config for the IBM PC might have been 16K but this was not a common configuration and was an extremely low amount of memory even for the 8086/8088 era of PCs.

That's true but nobody bought a PC with 16K of RAM. The smallest I ever saw on a PC was 256k, and I think I might have encountered a near-clone with 128k.

64K was a pretty common configuration in the first couple of years.

IIRC 16k IBM PC could not boot DOS. You were pretty much stuck in ROM cassette BASIC.

You're right:

http://www.os2museum.com/wp/dos/dos-1-0-and-1-1/

It should be noted that DOS would theoretically be able to run on the base PC model with 16KB RAM. However, this was not an option in practice: The PC’s BIOS loaded the boot sector (from a floppy) at address 7C00h, which is 31KB, meaning that it was not possible to boot DOS on a PC with less than 32KB memory.

You got me wondering if an actual 16k IBM PC BIOS would load the boot sector into the rolled over address 0x3c00 instead of 0x7c00. Has anyone (recently) tried to actually boot PC-DOS 1.0 on an actual 16k machine?

> That may seem tiny today, but in the 8086/8088 era, it's huge; the first IBM PC in its minimum configuration had only 16K RAM.

The minimum configuration of the first IBM PC isn't really a guide to a anything about the 8088/8086 era except the low end at the very beginning. Maxing out the 640K limit was common for 8088/8086 PC clones by the end of the era, and 30KB binaries for programming tools wouldn't be outlandish.

Very, very cool! I love the fact that you used an 8086 C compiler to make the whole toolchain work.

Digital Mars C and C++ compilers still support 16 bit 8086 code generation and are free:

https://www.digitalmars.com/download/freecompiler.html

Source code to the compiler/libraries is also free:

https://github.com/DigitalMars/dmc

https://github.com/DigitalMars/Compiler

There is also GCC 6.2/6.3 for IA16 targets:

https://blogs.mentor.com/embedded/blog/2017/04/01/announcing...

https://github.com/tkchia/build-ia16

https://slideslive.com/38902413/gcc-ia16-backend

> The toolchain can be used on either a GNU/Linux® or Microsoft® Windows® host.

Bingo. I love programming for early DOS systems (86, 286, 386) but it's difficult to find a tool-chain that runs on Linux and is able to produce DOS compatible binaries. I think OpenWatcom might but I could not get it to work correctly.

Definitely going to give this a try.

If you have not yet done so, may I suggest you investigate 'Dessqview/X'. Lovely stunts there.

"The compiler has many bugs and limitations, but it works for tinyasm purposes, and it's freely available. Supposedly it should support ANSI C, but I couldn't fit a standard ANSI C function definition"

I've tried

   25.07.1988  15:39            54,272 C88.EXE

from c88v31_1.zip (disk 1 on http://www.desmet-c.com/ver_31h.shtml ) with

    int f( int x, int y ) { return x * y; }
    int main( void ) {  return f( 3, 4 ); }

and it didn't complain? What's then that that didn't work?

(Also, I used Borland's C compiler for these platforms, and there is an official version now available for free, but it's a little annoying to download).

Just try changing the first function definition in my source for tinyasm code to "struct label define_label(char name, int value)" and it will complain of error. Same with all my functions. I didn't had time for further dive looking for the error cause, so I just resorted to K&R.

I haven't tried to use the whole setup (with all headers etc) but if I put in my .c file the definition of struct and the ANSI C version of the definition of define_label,

   struct label *define_label(char* name, int value)
   {  ..

then C88 compiles without errors. On the page about the compiler the author of the page writes that he had to fix the standard libraries, but the compiler (C88) is definitely made to work with ANSI C "draft" which matches my experiment.

And I surely understand it was "good enough" a solution for you to do what you did.

Awesome project, congrats!

Reply on news.ycombinator.com