Pascal on the 99/4A

[+mizapf]

Is it legitimate to complain a bit about too much sunshine?

 

Last Thursday we had above 30°C here (let me calculate this for you ... 86°F), and I'm usually going to office by bike (50 min round trip). Well, and on the evening, my old friend Sunburn showed up again. Type I skin.

 

Actually, people do start to complain about the heat when there are more than 3 days above 30°C.

 

OK, here's another photograph from my last summer vacation ... Typical thought at this instant: What am I doing here outside of the air-conditioned building?

[Tursi]

We've had quite a few days of 115F and up here (46C)... I'm not a fan of heat either. I miss my (western) Canadian climate.

[Stuart]

Heard a great quote from an Israeli colleague the other day - "It's so hot here, two hobbits have just thrown a ring into my back yard."

[+Vorticon]

I think it's time to move the weather talk to the OT thread

[apersson850]

program feel_good;

 

uses {$U colder.place} nice_weather;

 

begin

enjoy(beer);

end.

[Tursi]

Personally, I was done with the weather talk. I think if Vorticon wants to keep talking about the weather, he needs to carry the conversation.

 

(running and ducking...)

[+Vorticon]

Personally, I was done with the weather talk. I think if Vorticon wants to keep talking about the weather, he needs to carry the conversation.

 

(running and ducking...)

 

Can't duck fast enough!

[apersson850]

Around post 75 in this thread, we talked about adding a RAMdisk to use with the p-system. In post 117, I referred to a document about how to do that, which I once prepared. However, some who actually tried couldn't get it to work.

A while ago, when I got inspired by a benchmark thread here, I attempted to actually run my p-system again. By mistake I erased the diskette where I had my RAMdisk software. As I couldn't find a copy, I've now searched my archives and did at least find a printout of everything related to creating a RAMdisk within the p-system. The p-system is designed to improve speed by pre-building tables to faster access various devices. But it's only prepared to have three disks when used on the 99/4A, as no more could be controlled by the TI controller. When adding a fourth, as you can do with a CorComp controller, you have to copy some disk drive values in a table entry for DSK1 to where DSK4 should have been. That's enough, as a diskette is a diskette. But when adding a RAMdisk, some values aren't identical to those used by normal disks. In the document referred to in post 117, I forgot that part. That's why people couldn't get it to work. But now I found that program too, so I can see how to fix that as well.

 

Is anybody at all interested? I mean really would do this? I'm asking because I can prepare a document that covers the whole thing, but I'm not going to go through that work just for fun. It takes that somebody actually wants it, or I'll do other things.

 

I've by coincidence acquired an old Horizon RAMdisk. Since my own runs as the fifth drive in my p-system, I could perhaps add this one as the sixth, as an exercise. It's broken from a hardware point of view, so I need to fix that first. I'll see...

[+Vorticon]

There is so much potential to the p-system, but unfortunatly it seems that there is very little interest in it primarily because the p-code card is so scarce these days, but also because Pascal is not exactly mainstream anymore. As a matter of fact, I seem to be the only one using it, and sporadically at that.

So, if you want to create that document, it will have to be for your own edification and enjoyment, as with anything related to a grossly obsolete system. I do have a Horizon Ram disk which has replaced my flaky IDE card, and I would be very interested in reading about the process of setting it up with the p-system given the likelihood of speeding up access to files and compilation as that would be very helpful for my chess program development. That said, this project is currently on the back burner as I got side tracked by other projects, so I cannot make any promises as to any action on my part...

I say do it nonetheless

[digdugnate]

i am younger than most, but i learned Pascal in high school and took it as part of my Computer Science associate degree- this has been a neat read.

 

How does this flavor of Pascal compare with the Borland Pascal from the mid 90s?

[+Vorticon]

It's definitely slower than Borland Pascal given that it compiles to pcode and not straight machine language, but actually had more advanced features such as units which did not show up until version 4 in Borland's. I learned Pascal in college in the early 80's and have loved that language ever since. I would have killed to have the p-system at home at the time, but it was prohibitively expensive and required a PEB as well as preferably 2-3 disk drives. This is likely why it never garnered broad support among TI users most of whom, like myself, had just a console and a cassette drive

What people may not realize is that the p-system on the TI is actually a full fledged OS and not just a language compiler, and as such takes over the TI entirely when powered on.

[apersson850]

The main objective of UCSD Pascal is to be able to provide a full Pascal implementation, and then some, within the constraints of a 32 K RAM + 16 K video RAM computer. And it does. But that implies that when there's a tradeoff between speed and code size, small code size has to win most of the time.

 

The p-system for the 99/4A is improved in such a way that it supports one entire system disk in GROM, on the p-code card. Thus it's "better" from that point of view than most of the p-code implementations on contemporary machines, since the system disk is fast as a RAMdisk and means that (large) files like SYSTEM.PASCAL and SYSTEM.MISCINFO don't have to occupy your 90 K system disk. Remember that 90 K disks was the only thing that existed when the p-code card was born.

 

Interestingly, and perhaps because of this intense disk activity, the p-system does take some moves to make I/O more efficient. It does this by doing a pre-scan of I/O units when the system boots. Thus, when for example a disk access occurs, it already knows the CRU address of the card and the entry address of the sector read/write subprogram. It's the same with the RS232 device. It's pre-scanned and data is stored in the system. Thus, for each I/O request, there's not the normal scanning of all cards in the machine to find the correct card and the correct functionality, as it already knows where it is. But this is also why a RAMdisk doesn't work by itself in the p-system. Although the p-system itself is designed to allow for at least six disk drives (it can be expanded, but that's the default), the 99/4A implementation only fills in three of the disk unit data structures with the required information. Hence it's never looking for the any other drives.

To make a fourth disk drive working (like if you add a CorComp disk controller), you only need to copy the data for one of the first three drives to the fourth location. The disk drives are identical, in that the controller uses the same read/write code for all of them, regardless of whether they are three or four. So copy the basic data and then do a UNITCLEAR command on that drive, and it's ready to use.

But for a RAMdisk you need to prepare by first having the RAMdisk DSR in place (some drives have that in RAM, like my own design). Then you need to not only copy the normal disk data, but modify it, as you can't use the same CRU base nor sector read/write entry address for the RAMdisk. Third, and here we are in line with normal disks, you need to fill in the data that indeed is identical for all disks, just for yet another unit and fourth, you can now execute the UNITCLEAR command and the p-system will see the RAMdisk as just any other drive. If you add two physically different RAMdisks, then you have to do it again for the second one, as it will also have a different CRU base and probably a different entry address for the code.

 

Since the p-system was designed to be flexible about this, it's doable, but since the TI implementation is a bit short ended, it takes some extra steps to make it work. And due to this pre-scanning for efficiency optimization, you need to do that same thing after the fact, as the short ended implementation prevents the system from doing it by itself. Normally, the p-system allows you to change the whole operating system by providing updates to the SYSTEM.PASCAL file on the p-code card. If you have such a file on your root volume (normally DSK1, or unit #4: as it's called in the p-system world), it will take over from the SYSTEM.PASCAL file on the card. You don't have to replace the whole file, but just the segment you want to update.

But this device pre-scan is done by code in ROM on the p-code card itself, and runs before the system has really started, when the BIOS and input/output system's data structures are built, so you can't wedge anything into that sequence. Your modifications don't start running until this is already completed. That's why this data has to be inserted after the system has bootstrapped.

Still, you can write a program that does it automatically, and even chain that to the startup code, so it's not too much of a deal, once you've figured out what and how to do. But that took me quite a while once...

 

Regarding the other question: I once wrote a 4000 line program in Pascal on the 99/4A. I later ported it to a PC, using Turbo Pascal 4.0. The only real change was including uses dos to handle some operating system specific things (like getting the current date from the system) and modifying the key codes returned by system keys (F1-F12) on the DOS keyboard. The remaining parts of the code ran unaltered.

The program used text only. If there were graphics, it would have been different. But apart from that, it kind of had everything you can expect, like file and printer I/O, configuration file handling, dynamic memory allocation, floating point arithmetic etc.

Edited June 22, 2017 by apersson850

[digdugnate]

that is super cool. thanks for the insights!

[+mizapf]

UCSD Pascal was always far out of reach in my "hardware times". The first thing I added to MAME (back then, MESS) was the P-Code card, but I never really tried to work with it. Maybe I'll do that some time - or possibly with the 99/8 Pascal.

[apersson850]

From a functional point of view, it took Borland to get to Turbo Pascal 4 before they were on par with UCSD Pascal. But performancewise they were far ahead. The Turbo Pascal compiler was capable of compiling large source files much quicker than most other options. Execution speed was also a lot faster, especially compared to what the TI 99/4A is capable of doing. The program I mentioned above did a "benchmark" calculation in two minutes. When the same benchmark was running on a PC AT, which implies 12 MHz 80286 with 80287 floating point co-processor (which the program utilized, since it executed thousands of floating point operations), it took the PC three seconds to do the same job. The OS was DOS 3, I think, or maybe even earlier. AutoCAD was at version 2 at least, at this time.

 

But before this program was developed, the same calculation took a half to a full week to do manually. Thus waiting for two minutes or three seconds didn't really matter. Both were so much faster than the manual procedure that it was a revolution anyway. It made it possible to return a commercial offer for an install in half a day after the request for a quotation, instead of after a week. Customers actually complained about the quotations, as they thought it could not reasonably have been processed properly in such a short time.

[+chue]

Customers actually complained about the quotations, as they thought it could not reasonably have been processed properly in such a short time.

 

Now THAT is funny!

[+Vorticon]

Once the GCC port is finished: http://www.atariage.com/forums/topic/164295-gcc-for-the-ti/page__view__findpost__p__2028632, you could have a Pascal cross-compiler: http://en.wikipedia.org/wiki/GNU_Pascal.

 

There was no updates since september: http://insomnialabs.blogspot.com/, I hope Insomnia has not abandonned it...

 

Still waiting for that Pascal cross-compiler...

[4Andy]

Speeding up the p-System would definitely make me use it more. I like the editor and convenience of the OS, but probably only you can determine if it would be worthwhile typing in the code again. OCR software is a lot more reliable these days, than it used to be.

[+chue]

 

Still waiting for that Pascal cross-compiler...

 

I think you might be waiting a while... What I gather from reading the Wikipedia link in Lucien2's quote, is that GNU Pascal is a separate front end that needs a specific version of GCC:

 

 

The major advantage of piggybacking GNU Pascal on the GCC compiler is that it is instantly portable to any platform the GCC compiler supports. However since GPC is a frontend, it does have to adapt if major changes are done to GCC (like a major new version). Typically, new major versions are adopted only slowly (still mostly at 3.x, with 4.x experimental builds).

 

This would not be a problem except that work seems to have ceased on GNU Pascal - that is, it doesn't support newer versions of GCC. From the GNU Pascal site (http://www.gnu-pascal.de/gpc/Compiling-GPC.html#Compiling-GPC):

 

 

GPC is based on the GNU Compiler Collection, GNU CC or GCC. You will need the GCC sources to build it. It must be the same version as the one GPC is implemented with – 2.8.1, 2.95.x, 3.2.x, 3.3.x or 3.4.x as of this writing.

 

 

Insomnia's TI Port of GCC is based on GCC 4.4. (Bleeding edge GCC is at version 6.x)

Edited June 22, 2017 by chue

[apersson850]

Typing in the code I do intend to do. I'm almost done with it. But the question was if I should spend the effort to explain the details about how to add a RAMdisk, when chances are that perhaps not a single one of you will ever use it, or maybe even bother to read it.

The only thing I didn't have documented on paper was the memory loader, which loads the DSR from a code file, produced by the p-system assembler, into the memory of my own RAMdisk. You can't do that with a normal loader, since you have to activate the RAMdisk DSR, using the appropriate CRU bit, to be able to load the code. But it's fairly simple to do a basic such loader.

 

Using a RAMdisk with the p-system makes the compiler run about twice as fast, as it's heavily segmented. The floppies are running constantly as long as the compiler is running, but if you have the compiler on RAMdisk and the code on a floppy, the floppy will actually stop once in a while.

[+Ksarul]

I'd actually be interested in it too, as I sometimes dabble a bit with my USCD p-System--and a speedup by using a RAM Disk would be nice.

[apersson850]

Well, the file uploaded in post #117 tells you most of it. ​​I just forgot one piece of setup code, that must be loaded first. I'll come back with that. Once that's in place too, it will work, provided there's a card with the given CRU address that implements at least the sector read/write subprogram. The p-system has its own file system, so it uses only direct sector access from the normal TI system.

 

My own RAMdisk is large enough to host the compiler, editor and filer. It can also take a text and code file for a Pascal program. It makes a big difference, in cutting the compile time in half.

Edited June 22, 2017 by apersson850

[+Ksarul]

Thank you much--it looks like I need to set my dedicated p-System machine up again. . .

[apersson850]

I hope I'll have that missing part here within a week. But maybe not, since I may have to go to Poland for some work next week. This work thing just consumes too much time...

[apersson850]

OK, so Poland took away one week for me. But now I've checked it carefully, and found that the additional code was not additional. It was just a shortcut that works with Horizon RAMdisk only. My code, the one already posted, was a bit more general. The reason for me suspecting that my code wasn't all that was needed came from that it didn't work as expected. But that turned out to be due to some mistakes in re-creating it from the listing, not in the listing itself.

I'll see if I can get my Horizon card to work at all, and if so it I can get a DSR in there. Without having to write one myself.

Edited July 1, 2017 by apersson850