• Please review our updated Terms and Rules here

Does Turbo Assembler or MASM come with an IDE?

N

NicolasF

Experienced Member
Joined
Jun 28, 2006
Messages
255
Location
Argentina
Hi,

What type of integrated development environment do you guys use when coding assembler in DOS for a PC-XT? it seems like neither TASM nor MASM comes with an IDE.
Are there any good IDEs I could use or am I stuck using MS-DOS edit?

Thanks!
 
Doesn't MASM include Programmer's Workbench? At least version 6 does IIRC.

Back when I did a lot of TASM I used MED. Really any IDE that lets you configure an external build program should work.
 
Years ago I've used DOS Navigator's built-in editor (F4) which was surprisingly capable. Later I've switched to MED, like @Plasma suggests above (it had an "error" pane, so it was an improvement). Now for such tasks I'm exclusively using Vim or Emacs. For all workflows, using Makefiles always helps :)
 
MS Programmer's Workbench was slow on a 286; it will be painful on a 4.77 MHz XT. Note that extended memory is listed as being required for debugging large DOS programs. If your program will use more than 128K, PWB on the XT will be a poor choice.
 
NicolasF said:
MED is for Win 9x and I'm using a PC-XT. I think I'm going to try Programmer's Workbench.
Click to expand...
Ok, when you said "for a PC-XT" I didn't realize you also meant "on a PC-XT."

Doing any kind of serious development directly in DOS on an XT is going to be a chore. Especially assembly, where one small error can force you to restart the computer. It can be done, but I much prefer emulation or at least Windows.
 
Plasma said:
Ok, when you said "for a PC-XT" I didn't realize you also meant "on a PC-XT."

Doing any kind of serious development directly in DOS on an XT is going to be a chore. Especially assembly, where one small error can force you to restart the computer. It can be done, but I much prefer emulation or at least Windows.
Click to expand...

Do you have any comment about Tim Paterson developing QDOS/86DOS on an 8086 computer using a "monitor"?

I believe that was unusual and that normally people used an emulator to develop for a new platform.
 
Not really. Go back to the other S100 stuff, such as the Godbout/Compupro x88/x86 stuff. No emulators there; maybe cross-assemblers.
You sell us old guys far too short.
 
Last edited:
Chuck(G) said:
Not really. Go back to the other S100 stuff, such as the Godbout/Compupro x88/x86 stuff. No emulators there; maybe cross-assemblers.
You sell us old guys far too short.
Click to expand...

ME selling old guys short? No. On the contrary I go to a lot of effort to make sure I debug using techniques that I could use on real hardware - even when I'm using an emulator. I don't use the debugger that comes with Bochs etc - I use printf (that's one change - I don't use a monitor, I use C and recompilation). And I recently added something similar to a monitor (single-stepping and register display/alteration within PDOS/386 itself).

But again - Bill Gates used an emulator (on the computer at his university) to do his BASIC stuff for some micro (can't remember the details), and I believe that was the norm (regardless if you can name some exceptions). Alternatively - maybe I was given misinformation and emulators weren't the norm for OS development after all.
 
Well, we developed a lot of programs for our 8085 PC using an MDS-800 under ISIS-II (8080 CPU) and then wrote a lot of our 80186 code using the ISIS-II cross-assembler--on pre-release silicon. Oh, and on the target system, we wrote our own assembler and utilities.
Seriously, what do you think was used for, say, the CDC 6600? No emulators anywhere--not even an assembler or OS. I suspect that perhaps a rude cross-assembler was written on the 1604. You bootstrap, writing machine code (not assembly) and work from there. It's a painfully slow process, but it can be done. It always starts with an assembler and rudimentary I/O.
 
Chuck(G) said:
Well, we developed a lot of programs for our 8085 PC using an MDS-800 under ISIS-II (8080 CPU) and then wrote a lot of our 80186 code using the ISIS-II cross-assembler--on pre-release silicon. Oh, and on the target system, we wrote our own assembler and utilities.
Seriously, what do you think was used for, say, the CDC 6600? No emulators anywhere--not even an assembler or OS. I suspect that perhaps a rude cross-assembler was written on the 1604. You bootstrap, writing machine code (not assembly) and work from there. It's a painfully slow process, but it can be done. It always starts with an assembler and rudimentary I/O.
Click to expand...

Again - that's naming specifics. Were 90% of new systems developed using emulators or 10%? I was under the impression it was the former (but 86DOS was one of the exceptions - to be added to the exceptions you know of), but I could have been misinformed.

As to always starting with an assembler - recently "Sector C" was created.

I am very interested to know whether all that prior development (the subset that was done without an emulator) could have been done in (a subset of) C instead of assembler.

github.com

GitHub - xorvoid/sectorc: A C Compiler that fits in the 512 byte boot sector of an x86 machine

A C Compiler that fits in the 512 byte boot sector of an x86 machine - GitHub - xorvoid/sectorc: A C Compiler that fits in the 512 byte boot sector of an x86 machine
github.com github.com

Including using Sector C to build a better version of C.

Note that SubC becomes viable at 4000 lines of code (at which point it can be used to produce more sophisticated versions of SubC - you can see those stepping stones on the latest PDOS/386 distribution). But so far I don't have stepping stones from Sector C to that initial SubC. Nor from the most sophisticated SubC to full C90 compliance.
 
Sorry, my exposure to C wasn't until the 1980s when I acquired my copy of K&R and started to work with UNIX. Before that, you used what you had.
For me, C is just another language. Almost all of my programming on the x80 and x86 was initially in assembly. I didn't start to use C for x86 much until the latter half of the 80s. Pre-microprocessor was customarily in C or a dialect of FORTRAN. I'm a systems guy, not an application writer.

Did I mention that I was old?

I use C almost exclusively nowt now with MCUs because all of the libraries offered by vendors are C. But initially, all of my MCU work was--assembly. Early MS x86 C used the Lattice compiler and it was pretty crude; mostly strict K&R--but you could run it on a 5160. I like MCU programming--you're pretty much back to the bare iron. Read the 1000+ page hardware manual and Bob's your uncle.
 
It has been a very long time, but I think my memory tells me that the MASM came without anything like a IDE, but TASM had some kind of simple IDE. Or was that the TurbuC IDE?
 
Turbo Assembler by itself shipped without an IDE but Turbo Pascal and Turbo C had an IDE. TP and TC had professional versions that included Turbo Assembler and the IDE would happily work with TASM.
 
Chuck(G) said:
Sorry, my exposure to C wasn't until the 1980s when I acquired my copy of K&R and started to work with UNIX. Before that, you used what you had.
For me, C is just another language. Almost all of my programming on the x80 and x86 was initially in assembly. I didn't start to use C for x86 much until the latter half of the 80s. Pre-microprocessor was customarily in C or a dialect of FORTRAN. I'm a systems guy, not an application writer.

Did I mention that I was old?

I use C almost exclusively nowt now with MCUs because all of the libraries offered by vendors are C. But initially, all of my MCU work was--assembly. Early MS x86 C used the Lattice compiler and it was pretty crude; mostly strict K&R--but you could run it on a 5160. I like MCU programming--you're pretty much back to the bare iron. Read the 1000+ page hardware manual and Bob's your uncle.
Click to expand...

Your response appears to outline what was possible/available at the time - which I am not disputing.

My interest is going back in time, keeping the hardware constant, but changing the software.

CP/M was written in PL/M, cross-compiled, and I don't remember if an emulator was used or not. It's still unclear to me whether a C compiler (or a flavor of C) could have been used instead of PL/M - especially if we introduce a constraint of a C compiler having no more work put into it than PL/M had put into it rather than relying on a C compiler available in 2023 with decades of effort.

But my main interest is following what Tim Paterson (and yourself) did - which is not using an emulator - and as you said - starting from scratch with an assembler - and "just" switching the assembler to (a subset of) C. It is only when Sector C came out that I realized that this was even theoretically possibly possible. I had previously believed there was no alternative to assembler (although I have heard Forth mentioned before).

With Sector C you can go from machine code to (a subset of) C - no assembler is ever required. That's basically a conceptual game-changer (assuming the 1980s or whatever game (ie hardware) was rerun - ie the "game" that you personally played).

But at this stage it is still unclear to me whether you can build upon Sector C (using Sector C) or whether you will hit some roadblock/dead end.

It doesn't need to be exactly Sector C - it could be 2 sectors of machine code instead of 1, to get the ball rolling. I would like advice on this, but I'm not sure anyone knows.
 
If you can do all necessary I/O with Sector C then you can get just about anywhere, however painful that might be. Is there a facility for adding inline machine code (e.g. the asm{} directive)?
 
Chuck(G) said:
If you can do all necessary I/O with Sector C then you can get just about anywhere, however painful that might be. Is there a facility for adding inline machine code (e.g. the asm{} directive)?
Click to expand...

Yep - exactly that.

Here's an INT 21H:

asm 205; asm 33;

But too much of this would mean substituting assembler with machine code. Rather than the goal of substituting assembler with C.

I'm only wanting some minimal machine-code-in-C to do I/O, not application logic.

So it's more a question of "if you only have int variables, and only have functions that take no parameters and return nothing - can you fight your way out? The answer may well be "no" - I don't know. I'm not claiming to be a language expert either. Nor experienced in bootstrapping a dead machine. I wrote PDOS - but not the way Tim Paterson and yourself did it. I guess that's what I'm really trying to do. I needed PDOS just to define the end goal. Now I'm trying to get there from scratch instead of "cheating" (I started PDOS development using Turbo or Borland C - can't remember which - but can probably find out if necessary).
 
Chuck(G) said:
If you can do all necessary I/O with Sector C then you can get just about anywhere, however painful that might be. Is there a facility for adding inline machine code (e.g. the asm{} directive)?
Click to expand...

Also - painful compared to what? The competition is the pain you and (possibly) Tim Paterson experienced in writing an assembler from scratch on a near-dead machine. I'm not sure if you step through multiple versions of the assembler as the first steps, but that is what I envision doing with Sector C - I want to use Sector C to write a better C compiler, and then use that C compiler to write an even better C compiler. I know that once I hit the most primitive version of SubC (about 4000 lines of code) shipped with PDOS/386 that I will be in a position to make 2 more steps to get a better SubC (about 6000 lines of code).

I'm not claiming to be a compiler expert either. :)

But I am far more productive using standard C90 (ie very little experience with Sector C or even SubC) than I am in standard masm-compatible assembler (I have minimal experience in writing assembler using debug too - and minimal experience in entering machine code too).
 
If you had a macro assembler based on an x80 (say, DRI MAC), you could easily bootstrap your own x86 code. As a matter of fact, if you look at DRI's 8086 assembler, the conventions follow the 8080 ones and not the Intel ones. The Intel ASM86 ISIS-II cross assembler was a real CPU hog, as it didn't know much of anything and had to read a file of OPDEFs to do anything. Unless you're stuck on the strongly-typed Intel syntax, writing assemblers are easy.

Writing a debugger is similarly easy. Plug breakpoints with a one-byte interrupt instruction, then it's mostly a matter of displaying registers, memory and allowing for modification of both. Easy enough to stick in an EPROM. I had to write one to handle code executed outside of DOS myself. It wasn't hard.
 
You must log in or register to reply here.
Back
Top