Programming languages

[CP/M User]

krebizfan wrote:

There were several implementations of Smalltalk that worked on a Z-80; I think there was one that ran on CP/M-80. Object Oriented languages don't have to be big. Languages with kitchen sink libraries will be large.

Okay, SmallTalk might have been an exception. Could be wrong though I thought C++ required at least 128k. It's been so long since I've used anything Object-Orientated, it's all really a haze to me now in terms of what you can and can't do!

Languages with Kitchen Sink Libraries seems to be a feature in the early CP/M (and DOS) versions of Turbo Pascal. It's hideous that one writes some program, generates a (.COM, .COM or .CMD) file and instantely you've got yourself yourself a 7k or 8k file with Library. I tried breaking it apart piece by piece years ago, though it's Huge. What's extra annoying is versions like TP5.5 only use elements of code which relates to the program you've writen so you get an .EXE under 3k! Of course I think the downside to that is a Complicated piece of programming which ain't gonna fit into 64k of memory no matter how much you squeezing into that amount of memory. Unsure I've ever seen any 8bit Compiler being able to have the Intelligence to simply use whatever it needs from study the source code. The best way seems to be make the terms yourself and take the code your program needs from the Library and remove what's not required.

 

[CP/M User]

carlsson wrote:

The book I referred to is this one:

"Den dresserade datorn - konsten att utveckla datasystem på användarnas villkor" (*)
(c) Gian Medri, Margareta Medri 1984
Studentlitteratur, Lund, Sweden
ISBN 91-44-21541-X

(*) The trained computer - the art of developing computer systems on the users' terms

Since it is a book oriented at socio-computing aspects, I suppose the authors for illustrative purposes just picked a few programming languages they had heard about and put them into a graph. The question is how important C was compared to most other programming languages in the early 1980's, considering both mainframes/time-share and personal/micro/home computers.

Oops, nearly missed your post again! From that I think I can say that 'C' was perhaps starting to make a move. The Personal Computer Handbook I've got from 1984 has someone stressing out the Importance of 'C' and favouring it over languages like Pascal. What's interesting though is I was using Pascal and Delphi til 1996 and when I went to do a Higher level course it was only at that point when 'C' was brought in only just as well cause simular texts were available for Pascal. There perhaps are some legitimate arguments to suggest that 'C' should be used at Higher Levels given it's got advantages over Pascal.

I have another Book from 1985 called "From Pascal To C" (the title states it all!) and within that quite a few 'C' compilers are mentioned, from the Public Domain "Small-C" by Ron Cain to a $750 "Whitesmith's C" - two examples of "C" compilers you could have obtained or purchased for CP/M-80! Quite a number of 'C' compilers were made for CP/M and I suspect this is how 'C' entered the world into the Microcomputer market, even Digital Research had their own blend of 'C'. I guess the main fallback at the time is a cheap 'C' compiler wouldn't be as complete as something you'd pay a bit extra for, at the time though it appears some good quality 'C' compilers were coming out like C-Ware C (de Smet C Development Package) for $100, C86 for $395, Aztec C would set you back $199 and BDS C for $150.

Though having said all that, I reckon anyone can easily overlook 'C'. I didn't really know anything about it til the late 90s and I guess if I knew I was going to be up against it, I would have studied it long before hand.

 

[commodorejohn]

BDS C is pretty good for a Small-C compiler - and as a bonus, the author's made it public domain!

 

[Chuck(G)]

Okay, SmallTalk might have been an exception. Could be wrong though I thought C++ required at least 128k. It's been so long since I've used anything Object-Orientated, it's all really a haze to me now in terms of what you can and can't do!

It depends on which C++ you're talking about. The first C++ was just a preprocessor-type of package that took C++ source and generate (generally unintelligible) C from it. I suspect that it'd run on a lot less than 128K. 8-bit C was fairly inefficient in 8080/85-based implementations, better in Z80 owing to the problems of having to address stack-resident variables.

On the other hand, FORTRAN generated pretty good code on an 8080.

 

[CP/M User]

Yes sadly I forgot to mention the good news the CP/M Community had when BDS C became Free from it's Creator! :D Thanks for the link cause it looks like it's made some progress since I last looked at the site, interesting to see they have a Forum there! From the sounds of it, it performs well in 8080 platforms! :D

Well I guess that if you had a C++ compiler which took your C++ program and converted it into 8080 or Z80 Assembly, there would be some benefical aspects to that over a Object File or another Language.

C seems to have got into the programming enthusiests for systems like mine (Amstrad CPC), which allows them to make games for that system (as well as a number of other systems), the games themselves are interesting, though they seem to present certain limitations in them as well, though I guess that's going to be expected when anything is compared to Assembly.

 

[scorelessmusic]

Just chipping in here to say that I am an active Turbo Pascal programmer / developer. My current project is a polyphonic, sample-based piano app that you can play with just using the computer keyboard (a DOS exec). I hope to find people here who may be keen on such a thing and be my first users... I'm hoping to get valuable feedback.

I wasn't sure if I could find a community such as this so it was heartening when my google search led me here!

 

[CP/M User]

scorelessmusic wrote:

Just chipping in here to say that I am an active Turbo Pascal programmer / developer. My current project is a polyphonic, sample-based piano app that you can play with just using the computer keyboard (a DOS exec). I hope to find people here who may be keen on such a thing and be my first users... I'm hoping to get valuable feedback.

I wasn't sure if I could find a community such as this so it was heartening when my google search led me here!


Sounds like you could be onto something brillant there, an application like this could be expanded on so one could have other electronic keyboards like Organs and Mellotrons would be fantastic and amazing if Acoustic Instruments could be recreated through the PCs Soundblaster with Harpsichords and Xylophones! Hope it all works out well! :D

 

[scorelessmusic]

I've released the public alpha 1 version! Will start a tread for it. You can check out the project and download the latest build at:

http://about.me/scorelessmusic

 

[CP/M User]

scorelessmusic wrote:

I've released the public alpha 1 version! Will start a tread for it. You can check out the project and download the latest build at:

http://about.me/scorelessmusic


Oh no! Unfortunately it's doing the Run-time Error 200 thingy. Are you using TP7? With that version of TP there's a patch which fixes that - which becomes evident the faster the machine is!

 

[scorelessmusic]

Ah, yes I was afraid of that. The CRT module. Let me try to get a patch on that. So far, all my testing has been done in emulation (Mac using DosBox, iPad using DOSpad which is based on DosBox).

 

[scorelessmusic]

Just out of curiosity, could you try this solution (PatchCRT) to see if it works? It would be a handy tip for other similarly released binaries where we do not have access to the source for recompiling.

http://www.kennedysoftware.ie/patchcrt.htm

 

[scorelessmusic]

Started a new thread for CHORDiUM for DOS so that I don't hijack this one

http://www.vintage-computer.com/vcforum/showthread.php?23235-CHORDiUM-for-DOS

 

[deathshadow]

Pascal is a bondage-and-discipline language, and I hate those on principle.

Statements like that always remind me of the people who still sleaze out HTML 3.2 and slap a tranny doctype on it to call it HTML 4, as they tend to say much the same thing about HTML 4 STRICT or worse, XHTML 1.0 STRICT (which they REALLY bash on)... you know the same people who say there's no need to validate your markup.

It's like the concept of clearcut rules that can prevent you from making mistakes in the first place is a bad thing -- it isn't. Though my period of military service could be coloring my opinion :D drop and give me twenty maggot! :lol:

Add to that that it's a toy language that has to be awkwardly extended before it's useful for real programming, and that's twice the reason to not use it.

I've never found it to be a toy language, nor would I call the extensions awkward -- Object pascal feels like a natural extension to the langauge since objects are just overglorified records. Were that C and C family implementations of objects were as clearcut and functional!

Great example of this is the horribly crippled train wreck that objects are in PHP -- because objects are SO useful when you can't point at a sibling element. Good luck implementing something like a btree with that.

... and do I really need to say anything about C++ and objects?

(And then there's Java! Wonder Twins, activate! Form of C++! Spirit of Pascal!)

If that was intended as a insult, I'll agree with you on that -- except the spirit of pascal part (given it's even more loosely typed and loosly structured than C, I don't get where you got that).

Java sucks - really pisses me off they have the giant brass monkey balls to call it a VM... since it's nothing more than a glorified bytecode interpreter and under the hood has more in common with Microsoft ROM Basic than it does a REAL VM.

For me C is needlessly cryptic, I can work with it and C dialect offshoot languages like javascript and PHP, but it always makes me want to backhand someone. I realize that back in the 70's when people were typing their code over a 150 baud connection on a DEC 2112 modem the short cryptic abbreviations served a purpose, but after about 1980 onward that should have been kicked to the curb.

Hence the old joke about C and *nix being a hoax...

I particularly like the part about:

We stopped when we got a clean compile on the following syntax:

for(;P("n"),R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

At one time, we joked about selling this to the Soviets to set their computer science progress back 20 or more years.

But I sort of know what you mean, in TP for instance later versions (in TP5.5 for example) they have this wonderful "INC(<variable>,1);" and "DEC(<variable>,1)" which is the equivalent of <variable>:=<variable>+1; and <variable>:=<variable>-1; in something like TP3 (TP3 does have another Function which returns the next number in a series, though operates just about as fast as what I had prior - maybe slightly faster but not significantly faster compared to INC(); or DEC() Nobody can give me a definitive answer as to how this is possible! :shocked: The only answer I've had given back to me is this is a Special Instruction! :sad:

One of the fun things people miss about inc and dec is how they operate on pointers. It works much like how setting a value when resetting/rewriting a file works. For example: (pulling this from my retrochallenge entry)

type
	pVidModeTable=^vidModeTable;
	vidModeTable=record
		columns,
		rows,
		points:byte;
		length:word;
		sequencer:array[0..3] of byte;
		misc:byte;
		crtc:array[0..$18] of byte;
		attr:array[0..$13] of byte;
		gcr:array[0..8] of byte;
	end;

var
	biosDataPointer:pointer absolute $0040:$00A8;
	modeTable:pVidModeTable;	
	t:word;
	
begin
	modeTable:=pVidModeTable(biosDataPointer^);
	for t:=0 to $13 do begin
		write('mode ',byte2hex(t),' - ');
		with modeTable^ do begin
			write(columns:4,' x',rows:4,' - ');
			write('PPL:',points:3,' ');
			writeln('Len:',length:6,' ');
		end;
		inc(modeTable);
	end;		
end.

Reads in the video parameter table from the EGA/VGA BIOS. notice how I only increment the modeTable pointer by the 'default' of 1. The pointer ends up incremented the entire size of the record (64 bytes) instead of by one byte. That's the true power of increment/dec. If i wasn't outputting the mode number I could even do this for the loop:

	endTable:=modeTable;
	inc(endTable,$13);
	while (modeTable<endTable) do begin
		with modeTable^ do begin
			write(columns:4,' x',rows:4,' - ');
			write('PPL:',points:3,' ');
			writeln('Len:',length:6,' ');
		end;
		inc(modeTable);
	end;

Of course if you are just incrementing by one on a word sized variable, most pascal compilers are smart enough to use the ASM inc command instead. For example:

inc(myVariable);

mov ax,[bp+{myVariable offset}]
inc ax
mov [bp+{myVariable offset}],ax

Which takes 7 bytes and runs in 21 clock cycles on a 8088. (remember, no EA penalty for using the accumulator!)

Whereas:

myVariable:=myVariable+1

is typically compiled as an actual addition (I think TP7 added a flag to have it autodetect add by ones and use inc instead, but don't quote me on that) which ends up either:

add [bp+{myVariable offset+2}],1

Which is 6 bytes and 17+EA clocks on the 8088. Given we're talking BP+offset that ends up 9 more clocks, so that's 26 clock cycles.

Sometimes it's also handled thus:

mov ax,[bp+{myVariable offset+2}]
add ax,1
mov [bp+{myVariable offset+2}],ax

Which takes 10 bytes and 24 clocks.

It's worth noting that if you inc a pointer by an amount the size of the type a pointer is stored in a memory location and loaded to ax thus:

inc(endTable,$13);

From the example code above usually ends up something like:

mov ax,[bp+{record size}]
mov bx,$13
mul bx
add [bp+{endTable offset+2}],ax

Mind you, the clock cycle and byte counts above may not be entirely accurate -- I'm pretty much pulling numbers out of my backside as it's been a few decades since I've done ASM.

Though it's cute, I can do x86 ASM in my sleep and I still find C needlessly complex -- to the point I end up asking "why the devil aren't we just writing in ASM? Portability can't be THAT important!"

But to put this in perspective, I'm the guy who cannot grasp the concepts behind visual programming -- it makes NO sense to me. I write something with the VCL in Delphi or the LCL on FPC I edit the code in Crimson and call the compiler manually from the command line.

But there are people out there who think Ruby is a simple and effective language -- everyone's definition of simple, clear and easy to use is different. (let's face it, if it wasn't for Rails ruby would be just as stillborn as Prolog!)

 

[CP/M User]

deathshadow wrote:

One of the fun things people miss about inc and dec is how they operate on pointers. It works much like how setting a value when resetting/rewriting a file works. For example: (pulling this from my retrochallenge entry)

type
pVidModeTable=^vidModeTable;
vidModeTable=record
columns,
rows,
points:byte;
length:word;
sequencer:array[0..3] of byte;
misc:byte;
crtc:array[0..$18] of byte;
attr:array[0..$13] of byte;
gcr:array[0..8] of byte;
end;

var
biosDataPointer:pointer absolute $0040:$00A8;
modeTable:pVidModeTable; 
t:word;

begin
modeTable:=pVidModeTable(biosDataPointer^);
for t:=0 to $13 do begin
write('mode ',byte2hex(t),' - ');
with modeTable^ do begin
write(columns:4,' x',rows:4,' - ');
write('PPL:',points:3,' ');
writeln('Len:',length:6,' ');
end;
inc(modeTable);
end; 
end.

Reads in the video parameter table from the EGA/VGA BIOS. notice how I only increment the modeTable pointer by the 'default' of 1. The pointer ends up incremented the entire size of the record (64 bytes) instead of by one byte. That's the true power of increment/dec. If i wasn't outputting the mode number I could even do this for the loop:

endTable:=modeTable;
inc(endTable,$13);
while (modeTable<endTable) do begin
with modeTable^ do begin
write(columns:4,' x',rows:4,' - ');
write('PPL:',points:3,' ');
writeln('Len:',length:6,' ');
end;
inc(modeTable);
end;

Of course if you are just incrementing by one on a word sized variable, most pascal compilers are smart enough to use the ASM inc command instead. For example:

inc(myVariable);

mov ax,[bp+{myVariable offset}]
inc ax
mov [bp+{myVariable offset}],ax

Which takes 7 bytes and runs in 21 clock cycles on a 8088. (remember, no EA penalty for using the accumulator!)

Whereas:

myVariable:=myVariable+1

is typically compiled as an actual addition (I think TP7 added a flag to have it autodetect add by ones and use inc instead, but don't quote me on that) which ends up either:

add [bp+{myVariable offset+2}],1

Which is 6 bytes and 17+EA clocks on the 8088. Given we're talking BP+offset that ends up 9 more clocks, so that's 26 clock cycles.

Sometimes it's also handled thus:

mov ax,[bp+{myVariable offset+2}]
add ax,1
mov [bp+{myVariable offset+2}],ax

Which takes 10 bytes and 24 clocks.

It's worth noting that if you inc a pointer by an amount the size of the type a pointer is stored in a memory location and loaded to ax thus:

inc(endTable,$13);

From the example code above usually ends up something like:

mov ax,[bp+{record size}]
mov bx,$13
mul bx
add [bp+{endTable offset+2}],ax

Mind you, the clock cycle and byte counts above may not be entirely accurate -- I'm pretty much pulling numbers out of my backside as it's been a few decades since I've done ASM.

Though it's cute, I can do x86 ASM in my sleep and I still find C needlessly complex -- to the point I end up asking "why the devil aren't we just writing in ASM? Portability can't be THAT important!"

But to put this in perspective, I'm the guy who cannot grasp the concepts behind visual programming -- it makes NO sense to me. I write something with the VCL in Delphi or the LCL on FPC I edit the code in Crimson and call the compiler manually from the command line.

But there are people out there who think Ruby is a simple and effective language -- everyone's definition of simple, clear and easy to use is different. (let's face it, if it wasn't for Rails ruby would be just as stillborn as Prolog!)

That's quite interesting, never thought about using Pointers before, so I knocked up this example:

Program Pointer_Example;
const value : array[0..99] of byte =(0,1,2,3,4,5,6,7,8,9,
                                     10,11,12,13,14,15,16,17,18,19,20,
                                     21,22,23,24,25,26,27,28,29,30,31,
                                     32,33,34,35,36,37,38,39,40,41,42,
                                     43,44,45,46,47,48,49,50,51,52,53,
                                     54,55,56,57,58,59,60,61,62,63,64,
                                     65,66,67,68,69,70,71,72,73,74,75,
                                     76,77,78,79,80,81,82,83,84,85,86,
                                     87,88,89,90,91,92,93,94,95,96,97,
                                     98,99);
type myptr = ^ptrvalue;
     ptrvalue = record
                 value2 : array[0..99] of byte;
                end;
 var dummy : myptr;
     count : byte;
BEGIN
 new(dummy);
 for count:=0 to 99 do
  begin
   dummy^.value2[count]:=value[count];
   writeln(dummy^.value2[count]);
  end;
END.

But of course it's nothing fancy, the result I got from this program didn't appear significantly faster or any slower compared to if I was incrementing a variable such as count (defined as a Byte) by 1. I did something simular program (I'm using Z80 Assembly) which I posted here to increment the value and return it into one of my variables at a specified memory location. In that case though I'm using other registers the Accumulator and the HL register, though again I'm using small Byte Sized values from 00 to ff and speed wise there's not a lot of noticible difference. What I did find years ago was if I was graphically drawing something like a Circle and was using things like COS and SIN in my routine, the program would slow down significant as opposed to having values stored into an array and feeding it through the program that way. The Mandelbrot on my website applies a simular approach - though of course it needs a setup program which sets up a series of 4 files (16 bytes each) for the coloured co-ordinates which takes ages, though once it's setup the main program will take those files and draw it to screen in 9 minutes.

 

[deathshadow]

But of course it's nothing fancy, the result I got from this program didn't appear significantly faster or any slower compared to if I was incrementing a variable such as count (defined as a Byte) by 1. I did something simular program (I'm using Z80 Assembly) which I posted here to increment the value and return it into one of my variables at a specified memory location.

Your methodology over on that PCEngines page is flawed -- "inc" under TP4/newer is not a function, but a language/compiler psuedo-function applied at compile time. Your "INC" function has the full overhead of a real procedure, which is to say it saves any registers that need to be preserved, builds the new stack allocation for function variables, and then performs a far CALL -- Then you have the far RET, release of stack space and restoration of registers -- OF COURSE that's going to be slower than just saying "val:=val+1;" or "val:=succ(val);"

It's part of why when coding for older systems it often helps to NOT wrap common routines in procedures/functions -- procedures and functions add execution time overhead which is why inside loops they should be kept to a minimum... ESPECIALLY on the Z80 where there's a REAL difference between a NEAR and FAR call. (as opposed to x86 where there really isn't)

So making that INC procedure for TP3 which lacks it -- completely pointless and a waste of time.

Though as someone else pointed out, having gotoXY and WRITE inside the loop should be slowing it down to the point where it shouldn't matter... and repeat until keypressed without actually intercepting the key -- the first one would fire and then it should drop through all the other ones as it's left in the buffer...

You kind-of missed my point about using pointers INSTEAD of arrays though -- as you are still typing the pointer as an array instead of by data type. When you are going to flat iterate through values pointers can be WAY more efficient than array indexes -- it's WHY Pascal had pointers in the first place.

To rewrite what you posted here to use pointers the way I'm talking -- and I'll try to make this work on 8 bit...

program pointerExample;

const
	value:array[0..99] of byte=(
		0, 1, 2, 3, 4 ,5, 6, 7, 8, 9,
		10,11,12,13,14,15,16,17,18,19,
		20,21,22,23,24,25,26,27,28,29,
		30,31,32,33,34,35,36,37,38,39,
		40,41,42,43,44,45,46,47,48,49,
		50,51,52,53,54,55,56,57,58,59,
		60,61,62,63,64,65,66,67,68,69,
		70,71,72,73,74,75,76,77,78,79,
		80,81,82,83,84,85,86,87,88,89,
		90,91,92,93,94,95,96,97,98,99
	);
	
var
	dummy,
	workOffset,
	workEnd,
	sourceOffset:^byte;
	dummySize:word;
	
begin
	dummySize:=sizeof(value);
	getmem(dummy,dummySize);
	workOffset:=dummy;
	workEnd:=ptr(ord(dummy)+dummySize);
	{ 
		TP3's @ is a bit retarded about what 
		it lets you target so use ADDR instead
	}
	sourceOffset:=addr(value);
	repeat
		workOffset^:=sourceOffset^;
		writeln(workOffset^);
		workOffset:=ptr(ord(workOffset)+1);
		sourceOffset:=ptr(ord(sourceOffset)+1);
	until workOffset=workEnd;
	freemem(dummy,dummySize);
end.

I THINK that would be functionally identical (or at least similar) in TP3 on 8 bit, though I've not done a lot of Turbo on 8 bit processors as I never had CP/M back then - TRS-DOS, RS-DOS, OS/9 -- sure! CP/M, not so much... at least not on a 8 bit processor. First time I ever dealt with CP/M was actually CP/M 86 on a DEC Rainbow.

Of course that's also 16 bit thinking because it puts it on the heap -- when your code/stack total is limited to 64k you usually do everything you can to get values onto the heap with pointers since the 500+K of free memory is available. There's a lot less reason to use the heap when dealing with a 8 bit processor, and it can in fact really bloat out your memory footprint with all those extra pointers.

16 bit TP3 is actually tougher because of the segmentffset memory model and 32 bit pointers -- no typecasting those to integer... That becomes a royal pain in the ass as you have to divide out the offset and rebuild the pointer on each one.

workOffset:=ptr(seg(workOffset),ofs(workOffset)+1);
sourceOffset:=ptr(seg(workOffset),ofs(sourceOffset)+1);

Which ends up really slow -- TP3 wasn't written to handle 16 bit pointers in a particularly efficient fashion, it was really at heart still an 8 bit compiler.

Which is where the 'improvements' of Turbo 4 and later comes in - those two lines becoming:

	inc(workOffset);
	inc(sourceOffset);

Most of the 'improvements' in TP4 -- like INC -- were made possible BECAUSE they dropped 8 bit support.

Which is why on x86 TP3 can be grossly inefficient... but in a way those problems can't be blamed on Pascal so much as nobody in the 70's was thinking on supporting segment : offset memory model, particularly with a 12 bit overlap; Microsoft C 1.0 was similarly flawed as nobody had quite worked out the best way to handle the 8086 memory model at that point. By the time of TP4/Turbo C/MS C 2.0 such issues had been ironed out.

BTW -- PC Engines? Why was I thinking that was a Turbographx 16 website?

 

[CP/M User]

Hmm interesting, and yes I'm somewhat hopeful that there were something which could be accomplished in TP3! It's merely been an experiment to see how many ways to skin a cat! :D Your example looks interesting, though it's one of those do not run while Turbo Pascal 3 is running - make a COM file. Unfortunately I couldn't get it to work properly from the COM file - it would execute though send through these seemingly random number through - 0 to 99 (well outside the values from the Array). I had to change some aspects of it so it would work in TP3 - there is no variable type "word" - "Integer" can work in simular fashion and one of the pointers was missing it's arrow. However trialing it out and timing it between your version and my version (posted earlier), shows simular execution timing.

Though it's definitely conclusive that feeding TP3 known results as opposed to calculating them will produce faster results. The compromise is the use of memory, particularly if large amounts had to be used. "FOR" seems to be handly for some things and seems to suggest that anything which needs to be calculated with it can be handy, unfortunately it doesn't support any sort of steping - "e.g. 0,2,4,6,8,10" and in those cases either "WHILE" or "REPEAT...UNTIL" can only be used. Some clever processes can be adopted in TP3 though - in BASIC for example programs which demonstrate graphics and insist on using variables with Decimal placings at the end can be redefined as Integer values since my old computer has a small video screen suitable for handling whole values - just needs to be closest whole number, truncating instead of rounding a number to the nearest whole value will produce a different result and in the case of truncating an incorrect one. Video memory is only 16k and there seems to be two ways of drawing to it using it's extensive Screen and Graphics routines available for anyone who wants to use it.

Initally I had this problem while I was translating programs for CP/M-86, and sadly those boys at Borland didn't to my knowledge make any Turbo Pascal 4 compiler for CP/M-86! Disappointing since it has it's own file format - ".CMD" and would reckonise 640k!


I haven't heard anything about PC Engines having anything to do with Turbographx 16 website, in the past I was under the impression that PC Engines were a group of problem solvers which would have programming solutions for those who wanted useful programming tips, though they might have had some involvement in producing free software - I thought a small Text editor called "TED" had something to do with them, or am I thinking of somebody else with a simular name?

 

[carlsson]

To clear up the confusion, there was an early 8/16-bit video game by Hudson Soft and NEC called PC Engine in Japan. In the rest of the world, it was known as Turbografx 16. Actually it is powered by a derivate of the 6502, namely the HuC6280A running at up to 7.16 MHz.

 

[CP/M User]

carlsson wrote:

To clear up the confusion, there was an early 8/16-bit video game by Hudson Soft and NEC called PC Engine in Japan. In the rest of the world, it was known as Turbografx 16. Actually it is powered by a derivate of the 6502, namely the HuC6280A running at up to 7.16 MHz.

I'm presuming that's the games console your referring too? I've got a magazine from the UK which refers to it as the PC Engine. You wouldn't want to Turbografx 16 with Turbo Graphix toolbox which Borland made for their stuff like Turbo Pascal! :blush:

 

[CP/M User]

Pascal was created as an instructional language, not intended for implementation or general use. When implemented, it had to be extended for practical use. This was in the day where many CS students didn't actually get to use a computer until their second year. Pascal was written to be an introductory desk language, like pseudo code but with more structure.

Strangely enough I agree, having moved from Turbo Pascal 3 / CP/M to using an earlier Pascal compiler which compiles programs more direct to the Computer (rather than rely on CP/M), I've found that Compiler (even though if only came out a year or two before TP3) to be a bit simpler, even though it has some of the System Specific stuff included in it, the rest of the time that Pascal compiler relies on the user to include their own routines. Fortunately for the system I've always been using (Amstrad CPC), it has a vast range of Firmware, which can easily be incorporated as extras into programs.

Turbo Pascal in it's early days is similar to the Pascal compiler, although Turbo Pascal 3 seems to have more flexibility and perhaps larger library, by comparison, though the break through which probably made Turbo Pascal popular came from the use of Library Unit files and the ability to write your own, or use the ones which came with the software. True in a sense it's still a language designed for the aid of learning, but in the case with TP, you've got stuff that could be studied and perhaps even improved.

As to C, the C of the 1970's was not the C of 1986. C was a simple language with simple libraries well suited for system software development when I first did real work with it in '79. (I had actively avoided it before then, I thought it was a limited "toy" language like B and had no interest.) The general purpose libraries were effective but very minimal. It was the later development of the libraries and tools that resulted in C's success as a general purpose language. The language itself was still quite minimal.

I'm not up to scratch with how C evolved from it's early days, I have a rough guide to languages in a flow-chart from 1957 to 2007, which links C (from 1970-71) to C (K&R) from 1979 which links to C++ (1986), though it appears the earlier C has no direct Connection with C++ which seems to get it's connections from Simula 67, Algol 68 & C (K&R). All I really know about the earlier C is it was made for programming Operating Systems, which is interesting cause that's what I've read about BCPL as well. I've seen some interesting programs done in BCPL though which ranged from a Space Invaders game to a Word Processor. The game though I noticed, made numerous links to M/C subroutines though. :D

Pascal was many programmers' first exposure to structured programming in the microcomputer world. They tended to like it. Most implementations supported some form of modularity that assisted group development, too. Early on, Pascal is definitely a higher level language and more suited to application development than C. But the implementations of C kept getting more powerful libraries, while the Pascal language itself was fairly inert, without a simple, standard language extension facility. This was before ANSI C existed (which emerged quite late, thanks to the debates within the C standardization community.)

As unusual as this looks there appears to be 2 kinds of ANSI C, ANSI C which was the influence from K&R C, and C (ANSI) which had influences from C++ & C (K&R). Both came out in 1989.

In fact, the real battle was between Modula-2 and C. But the license holders of Modula-2 handled their property foolishly until after C had won the war. :wallbang: Modula-2 was intended to be a real language, unlike Pascal. Most Pascal implementations borrowed heavily from it, so far as they could without falling afoul of the owners of Modula-2. Modula-2 provided most of the features we later got implemented in the Object Oriented languages, but without the idealogical slavishness (or purity, if you prefer :D ) of those languages.

Haven't had a lot to do with Modula-2, though this is an unusual language because there are people who love it and there are people who hate it, which I think resulted in Oberon, which is more simplified.


Originally I was thinking about making a thread about all these different language, though I came across this thread which seems to have people taking about the languages they have used. Personally I've used Pascal as an alternative to using BASIC, though oddly enough still use BASIC, but use it sometimes just to see how it handles it, though haven't really taken it to the stage where I write entire programs and compile them. I've made numerous routines in Turbo Pascal, though moved to another Pascal compiler when people didn't want to see machine specific programs in CP/M (which is where TP shoots back at you), though using a simpler & earlier Pascal compiler has had me thinking about some of the limitations and using Assembly to improve those routines though. In some ways it's really good in how it allows some of the Lower level routines into it's standard code. :D