• Please review our updated Terms and Rules here

Turbo Pascal 3

alank2

Veteran Member
Joined
Aug 3, 2016
Messages
2,255
Location
USA
I've been messing around with the early Turbo Pascal compilers (V1/V2/V3) and find them quite a fascinating piece of history. There is something cool about them supporting multiple platforms the way they did:

CP/M, 8 bit CPU, CP/M OS, CP/M filesystem
CP/M-86, 16 bit CPU, CP/M OS, CP/M filesystem
DOS, 16 bit CPU, PC-DOS OS, FAT filesystem

I found a file that claimed to be 3.01A source code over at vetusware and it actually compiles byte for byte except for one jmp command into a real turbo.com. I'm not sure if it is original source or something someone disassembled that happens to compile to fit the binary, but it makes for a fascinating thing to study.

One thing I figured out with a little testing is that V1 and V2 work with DOS 1.x, but V3 requires the newer file i/o (no FCB) of DOS 2.x and above. Not sure if anyone would want to run DOS 1.x, but you could run Turbo Pascal V1/V2 with it if you did.

Another thing that always irritated me was Turbo Pascal's insistence on starting with a yellow font color. Not only when you run a compiled program, but after you exit it. Same with the compiler. It turns out that for many years, I've been blaming TP for this when part of is really the fault of the way the PC BIOS works. Apparently there is no function call to set the current attribute in the BIOS. This is why a cls command will revert back to an attribute of 0x07 or white (not bright white) on black. Oddly though if you exit TP or a compiled program by it, you'll end up in yellow and a dir will stay in yellow. It turns out that the BIOS doesn't keep track and uses the on screen attributes to decide what to do. If outputting with a BIOS function that doesn't specify the attribute, it just goes with whatever is on the screen at the time. So if the screen was cleared with the yellow attribute, writing characters to it will inherit them. The real trick is what happens when scrolling happens and a new line is made - it grabs the attribute from the first character of the previous line and uses it for the entire new line. This is why a dir will stay yellow, but a cls will go back to gray. That explains the BIOS part of things.

The TP side of things is a remnant of coming from its terminal based days. It had a lowvideo, normvideo, and highvideo commands. For DOS, normvideo and highvideo seem to be equivalen, but I wonder if they were unique at some point in their CP/M versions. TP begins a program in normvideo or highvideo, which if using the default PC mode of "Color 80x25" is yellow. One can easily just put a lowvideo; at the beginning of the program to get around this automatic thing it does for you. The source shows 4 attributes you can set for each mode:

attmono B $0F,$07,$07,$70 ;monochrome attributes
attbwgr B $0F,$07,$07,$70 ;mono graphic atts
attcolgrB $0E,$07,$07,$4F ;"color graphic atts

mono b&w color edit program
the first value white/black white/black yellow/black text normvideo/highvideo
the second value gray/black gray/black gray/black top line lowvideo
the third value gray/black gray/black gray/black selected text
the forth value black/gray black/gray white/red error text


Personally I think the selected text should be black/gray (inverse) for all of them as it shows selected text much nicer I think.

One other thing I discovered is that memavail is returning a number of paragraphs from the heap! I always though it was a bytes in a local smaller 64K type heap, which led me to thinking it was always limited to 64K code and 64K data, but it turns out that they actually made a real heap you can dynamically allocate and dispose from! Also fascinating as I didn't think TP had this functionality.
 
I found a file that claimed to be 3.01A source code over at vetusware and it actually compiles byte for byte except for one jmp command into a real turbo.com. I'm not sure if it is original source or something someone disassembled that happens to compile to fit the binary, but it makes for a fascinating thing to study.
Quite some time ago I found a file that would disassemble the original 3.01 executable and place the needed comments in the source file. It worked. But being a MASM source file I turned it into a NASM one. And when playing with the sources, I found an error and corrected it. The error was using a fixed value instead of using a label.
This enabled me to ommit the internal editor and turn the executable in nothing more than a compiler. As a fun project I'm trying to use the editor part as base to create one that works with my own OS.

If interested in the NASM sources, email me or mention it here and I will upload them here or on my site.

Edit: That was indeed this SCG.zip file found at pcengines.ch.
 
Last edited:
Thanks Twospruces - that looks like a CP/M disassembly too! So there is a DOS one and a CP/M one to look at. I did some searching and saw someone talk about wanting to convert the CP/M one to 8080 only, but I'm not sure if they ever completed it.
 
Now that we have a CP/M solution for Model 100, I would have loved to get Turbo Pascal running on 8085.

It was actually much easier to swap the 80C85 for an NSC800 processor which is a Z80.

So I got what I wanted in the end!
 
Now that we have a CP/M solution for Model 100, I would have loved to get Turbo Pascal running on 8085.

It was actually much easier to swap the 80C85 for an NSC800 processor which is a Z80.

So I got what I wanted in the end!
Similarly I'd find it also nice to get Turbo Pascal running on a plain 8080, though of course that would involve a heavy re-write of the runtime library and editor. I'd love to run it on the Altair without replacing the CPU board with a z80 one.

For running Turbo Pascal on a portable system, the Epson PX-8 is an option and works quite well. Turbo Pascal can be fit onto an EPROM for it and runs really well all considering the platform. Plus has the benefit of an 80 column screen (albeit with only 7 or 8 rows) which greatly improves software readibility that assumes at least 64 or 80 column widths.

I'm curious about that NSC800 though, is that pin compatible with the 8085 (including the serial port and such)? But with a z80 compatible instruction set? If so that seems like a pretty interesting mod/upgrade for the model 100, and makes me want to pick one up to play with. I can't imagine too many Model 100 programs making use of the aliased instructions of the 8080 that the z80 took over for its extended opcodes, so compatibility is probably quite good.
 
I'll note that I bought my tube of NSC800s with the goal of making an 8085 system more Z80-ish. After all, there had been mods to the CompuPro 85/88 CPU board to do just that. However, I gave up on the project--the subject system was heavily 8257 DMA and 8259 interrupt-driven and used the 8202 DRAM controller, as well as the SID/SOD pins--and there wasn't enough room for a piggyback between the boards. If that weren't enough, the configuration I/O register address was already in use by the memory manager.

Too many hurdles for too little gain. I'd have been better off allocating my time to a software emulator for a PC.
 
Back
Top