Anyone knows what commands can i use in turbo Pascal to control serial and LPT port?

Thanks.

 

Change to Delphi (Visual Pascal), it will be easier.

 

Do you know how can do it with matlab?

 

Are you using them as serial port and printer port or for more general purpose I/O?

I used Turbo Pascal EXTENSIVELY in a prior life, down to the hardware level. But some of that may be in my personal bit-bucket.

Rufus

 

As I recall, my beloved Turbo Pascal 1.0 did these sorts of things with inline assembler and or BIOS calls. I too might have some of this stashed away on 5.25" floppies. I truly liked TP, as much for the language as for it being the first affordable compiler for po folks. I switched to C when Mix C then GCC became available. But I would still
produce elegant, readable, code in Pascal if a decent, affordable or better still, free compiler were available for Linux. There is a pascal to C compiler but it lacks in several areas. And TP 4 when they trashed the language to make it OO kinda broke my heart. They have released source for the original and if I were younger and could make do with less sleep I'd try a port to Linux just for old times sake. There once was a time when small and fast were beautiful.

Regards

cww

 

Free - Free Pascal and GNU Pascal. There are others as well but these are the main two.

No charge - Kylix (Delphi) provided your application is GPL. I don't know if Borland (Inprise) is still maintaining the Linux port though. There was a lot of publicity when the Linux port was announced, but it didn't seem to get any real acceptance in the Linux market. I have a copy, but after looking it over, I decided I didn't want to put my eggs in a proprietary language basket.

If you feel nostalgic for Turbo Pascal, get a copy of 3.0 and run it under Bochs or DOSEMU. I wouldn't waste any time doing anything serious with Pascal though. Outside of the Delphi proprietary dialect, Pascal is no longer a mainstream language.

 

When last I looked, these suffered from one of the inherent difficulties with Pascal. It was orignally without IO libraries or builtin capability to _do_ anything. The magic of TP was the graphics, IO, etc. that turned a teaching language into a practical language. These things, being platform specific don't seem to really get the attention to really take advantage of a given platform. C handles this by simply being at a lower level. You can write what you need. A good *nix specific version of Pascal with a nod at TP would be a fine thing for applications if it could access the real power and all the resources and easy to use graphics.

Regards

cww

 

Both Free Pascal and GNU Pascal state they offer compatability with Borland Pascal 7.0. If the graphics and I/O libraries are lacking, this is a function of the fact that Pascal (except for Delphi) is no longer a main stream
language. Few people if any are developing library bindings for a language that no one uses anymore. If you want Gnome, KDE, or other popular library integration, someone needs to write the library interfaces.

Delphi does well on the Windows OS for use in developing custom applications because it is a continuation from an established product (Turbo Pascal), and because the main competitor for market share (Visual Basic) is technically
weak. Turbo Pascal did so well originally because it was one of the first reasonably priced compilers for PCs using CP/M or MS-DOS. If Delphi (Pascal) were introduced for the first time today, it would not generate much interest.

Sticking with a mainstream language is important, as that is what there will be extensive library support for. Library support is important, as libraries are at least as important as (if not more important than) the language
features.

Avoiding proprietary languages is important too. I believe that neither Dephi nor Visual Basic have a long term future. In Delphi's case, the owner has precarious finances. In Visual Basic's case, the owner has no interest in maintaining it over the long run (they want to push C# instead). It is reasons like these that many people avoid proprietary languages or language dialects.

 

Hi Michael

On March 7, 2005, Michael Griffin wrote:
> Both Free Pascal and GNU Pascal state they offer compatability with Borland
> Pascal 7.0. If the graphics and I/O libraries are lacking, this is a function
> of the fact that Pascal (except for Delphi) is no longer a main stream
> language. Few people if any are developing library bindings for a language
> that no one uses anymore. If you want Gnome, KDE, or other popular library
> integration, someone needs to write the library interfaces. <

I think rather that the problem is, that applications today consist of a few lines of actual application code and vast quantities of bloat required to provide that look and feel that users must have lest they be exposed to anything new and/or outside their comfort zone. And that does include Gnome and KDE to a smaller but significant extent as they aspire to produce that same mediocre experience. A solitaire game and our tools probably share a great deal of common code, the vast majority, I should
think.

> Delphi does well on the Windows OS for use in developing custom applications
> because it is a continuation from an established product (Turbo Pascal), and
> because the main competitor for market share (Visual Basic) is technically
> weak. Turbo Pascal did so well originally because it was one of the first
> reasonably priced compilers for PCs using CP/M or MS-DOS. If Delphi (Pascal)
> were introduced for the first time today, it would not generate much
> interest. <

We don't need many more ways to produce similar drek, so I agree. But TP was a breakthrough product in accessability at the time. Given the above requirement for ridgid blandness, what would it take to create a breakthrough today? Until the cookie cutter mold is broken, I don't
think we'll see anything exciting. A language not shackled to conformity won't ever be a commercial success in the desktop arena, fortunately there are other venues.

> Sticking with a mainstream language is important, as that is what there will
> be extensive library support for. Library support is important, as libraries
> are at least as important as (if not more important than) the language
> features. <

See above. But by that thinking I should be using nothing but C flat or dot net something. I'd rather fix cars than have a predatory monopoly dictate my means of expression by declaring what the mainstream shall be. And I would fix cars if the only alternative is a Microsoft shop.

> Avoiding proprietary languages is important too. I believe that neither Dephi
> nor Visual Basic have a long term future. In Delphi's case, the owner has
> precarious finances. In Visual Basic's case, the owner has no interest in
> maintaining it over the long run (they want to push C# instead). It is
> reasons like these that many people avoid proprietary languages or language
> dialects. <

Yes, programmers can often see what escapes the public at large. And the theatre of new languages goes on even as we speak. All in the hope of using software that doesn't suck. It's a shame so many bright minds are mired in the production of monopolyware. The money is a prison that few
escape. And pretty soon they all begin to talk alike. A pity. But there is hope on the horizon.

Regards

cww

 

Port[$378]:=0; {switch off all pins of LPT1}
Port[$378]:=255; {switch on all pins of LPT1}

 

In reply to Mr. Wuollet - This reply is a bit late, but I will emphasize again the importance of staying with a mainstream non-proprietary language wherever possible. Some good examples for the reasons for this can be found in the problems being faced by many software developers now that Visual Basic is being terminated by Microsoft at the end of this month.

"Classic" VB is being terminated and "VB.net" is not a direct upgrade path (it is a new language, not a further development of the old one). The business software development forums are full of comments (and a good deal of profanity) by furious developers who are finding that their existing code base won't work with "dot net", the porting "wizard" isn't much help for non-trivial programs, and their remaining choices are to re-write their existing code base (hundreds of thousands of lines in some cases) or go out of business (or perhaps do both together).

There are people who consider themselves to be software developers who have built their career around knowing VB6 and nothing else. They are now faced with either learning a new programming language have spent years knowing only
one, or else pursuing a career change. They are now learning how COBOL programmers felt when mainframes started disappearing.

According to the news reports I have read, a significant percentage of the developers who have already started their transition away from VB "classic" are switching to alternatives like Java or PHP, not "dot net". Having been
burnt once, they don't want to do through the same thing again in 5 years time.

So, I would conclude that yes, the original Turbo Pascal was a good language and development environment - in its day. Its day however is long past. As a proprietary language dialect Turbo Pascal would carry the same risk of being terminated for business reasons that VB does. An open language is a much safer choice.

 

That's why I code in C using GCC whenever possible. But, it would be nice if there were an elegant alternative. I have little sympathy for the MS slaves, they knew going in they would be one trick ponies. And as one who read thousands of job ads where no one but devout MS worshippers need apply, it seems doing the right thing is harder than learning a new language. But that's OK, they won't be offended, they'll mostly crawl right back to the monopoly. Maybe study C flat or something.

Regards

cww

 

Re: Curt Wuollet's comments on languages. As for your comments on MS C#, that raises an interesting question.

VB "classic" is facing termination at the end of this month. The compiler and run-time won't suddenly stop working, but the upcoming deadline are both a psychological barrier and a practical problem. How does someone justify writing new software in a language for which the development tools are unsupported and for which there will be no future upgrades?

The statistics that I have seen seem to indicate that the use of VB has been dropping for about a year, with the rate of decline accelerating in the past few months (no doubt driven by the impending deadline).

"VB dot NET" isn't an upgrade path for "VB classic" (it's not actually the same language). It doesn't seem to be good enough to be able to attract people to it for its own sake and in fact doesn't appear to be generating enough interest for it to survive in the long run. C# doesn't seem to be taking over from "VB classic" either though. Some people are switching to it from VB, but it is still a third tier language with no sign that it is heading for second tier status.

So this raises an interesting question. There seem to be a number of people in our business still using "VB classic" for custom applications. What do they intend to do in future? Do they intend to use an obsolete and unsupported language for new development, or to switch to another language? If they intend to switch, then to what language?

What should a customer do if the consultant bidding on a project proposes to write the program in VB? The customer is the one who is going to get stuck with a white elephant. Should they insist on another language?

 

Hi Michael

The obvious solution, and the one I've been subtly hinting at for a while, is to unbundle the tools from the OS and the whole works from market forces outside automation. Automation has it's own timeline based on the comparative life of automation solutions vs shrinkwrap games. A great majority of the problems with forced obsolecense and orphaned solutions are because vendors have hitched themselves to the Windows Wild Weasel ride and there is a fundimental mismatch between what is needed, ie backwards compatibility, investment protection, stability, etc. and what is offered ie floobydust, whizbang bells and whistles, no value upgrades and a relentless investment destruction cycle. It's a completely artificial and synthetic problem with it's only purpose the transfer of your assets to the monopoly. And bundling everything together insures the maximum inconvenience and expense.

Contrast the Windows roller coaster with say, the Debian version of Linux. Changes in one are revenue driven and in the other carefully considered and brought out when they are ready and proven stable. And there is no such thing as an obsolete version of Debian. It can serve until there is a compelling and rational reason for change or forever. And it's routine to backport great features in Linux to earlier kernel versions to have the best of both worlds. When you have something that has demonstrated fantastic stability and uptime and does everything that you need, it's totally irrational to allow some entity to force you back to square one with a x.00 release whenever their stock needs pumping up. With Linux you can update the GUI or other components independently of the kernel and vice versa to a large extent. And if there's no business or technical advantage to change, you don't have to. An Automation Linux would be more than feasible, it is abundantly clear that anyone wanting a distribution of Linux that meets a particular need can do so as literally hundreds of groups have. And the tools live on, I haven't been forced to change in 20 years.

The end to this sorry state of affairs and the key to rational progress is now, for the first time, practical and available and 95% done already. All it takes is the will to end the chaos and unpredictability and take control of the infrastructure and manage it for _our_ business needs. The roller coaster is at a low and slow point. A perfect opportunity to step off.

Regards

cww

 

"I believe that neither Dephi nor Visual Basic have a long term future"

Hey man. Delphi is at the 9th edition and still counting.
Instead your C was replaced by 'dot Net' stuff.

 

I'd be interested in the ports thing too, for homebrew CNC, and such. Pascal seems to benevolently fence you in, unlike C++. I want to spend more time getting stuff done, and less time chasing down stupid brain-fart mistakes.