Pascal on the 99/4A

[+Vorticon]

Would this location have what you need? ftp://ftp.whtech.com/emulators/pc99/pcode_card_software/ The Disk 666b contains TI's P-Code utilities according to the text.

 

Got it from Shmitzi. Thanks

[+Vorticon]

 

wouldnt tiprint from fred kaal work great for this? serial cable + pc + printer

 

You know I totally forgot about that utility. I'll have to check it out when I get back home. That said, it still involves having a PC around and I would much rather remove the "middle man" from the printing process... I still haven't found what I needed in the USUS newsletters so far, but I haven't had a chance to view them all yet.

[+Vorticon]

I found the MODRS232 program on the utility disk and it allows the redefining of the PRINTER: and REMIN/REMOUT: ports. Simply redefining PRINTER: to PIO did the trick to be able to print to the parallel port. Turned out to be very simple afterall I did try Fred's ti99print utility, and while it captured the serial output, it failed to recognize the LF code so all the output occurred on the same line. The program does not have the option of manually adding a LF after each CR. I'll contact Fred and see if that is something he can add to the program.

[apersson850]

I see you found it. Good.

Me and a friend of mine wrote Pascal programs to read p-system text files and store them as Display/Variable 80 files on a TI disk. As well as the other way around. The good thing with doing it in Pascal is that you need no assembly at all.

[+Vorticon]

I see you found it. Good.

Me and a friend of mine wrote Pascal programs to read p-system text files and store them as Display/Variable 80 files on a TI disk. As well as the other way around. The good thing with doing it in Pascal is that you need no assembly at all.

 

Anders, can you outline how you achieved this?

[apersson850]

OK. I'm not really sure how detailed you want it, but let's go for "intermediate"...

 

Within the TI Extended BASIC environment, you can only access the floppies by using TI normal OS files. You can't read anything on the disk without using assembly language, since that's necessary to get access to the disk sector read/write subprograms on the disk controller. Thus you can only access information inside the files, using input and print commands.

 

Pascal on the p-system allows floppy access on three different levels.

• Typed file I/O is similar to what the normal operating system allows. You access data files with put and get and text files with write and read, normally.
• Untyped file access is done using the intrinsics blockread and blockwrite. They will stay within the constraints of a file, but will not care about the information itself. Thus the same logic can be used to copy any file, as no attention to the interpretation of file data is paid. But they still work within a file defined by the p-system.
• Direct unit I/O, in which case data is transferred between memory and the disk without any consideration of files at all. By using the commands unitwrite and unitread, you can access any physical sector on a drive and send data to/from any buffer you like in the Pascal program.

Text files are different in the two systems.

• The standard operating system doesn't really have any special text file, but by convention uses the format Display/Variable 80 for text files. Lines of text are placed within the files "as is".
• The p-system defines text files in a way that's different from normal typed files. Text files have a special header, which contains various setup information, which in turn is used by the p-system Editor when handling the files. The text itself comes after the header, and contains a special code to compress leading spaces. Since Pascal programs normally are written using indentation, compressing all these spaces is a good idea.

Knowing this, we can combine these features/facts:

• Pascal already knows how to handle p-system text files.
• Pascal can access the physical sectors of a disk directly.
• Pascal allows the definition of data structures which mimics the structure of the native operating system's directory and file formats.
• You can read a disk sector and feed the data directly into such a structure, thus getting automatic mapping of what's in a directory/file.

From there, it's easy to see that from Pascal, you can with reasonable ease implement an understanding for the normal TI files, so that you can both read and create them. As there's not much to gain in transferring code or specific data files, we implemented only the conversion between p-system text files and the native system's DIS/VAR 80 files. It was a lot easier to make Pascal understand native files than the other way around.

 

If you want to see code, then as far as I know, my 99/4A still works (it hasn't been running for a while), so I could probably print to a Hyper Terminal session and post.

Edited March 22, 2016 by apersson850

[+Vorticon]

Great overview. Thanks!

Is there a technical document out there that describes the structure of Pascal text files in detail like the contents of the header and the compression scheme for the leading spaces?

[apersson850]

Probably, but I don't know right away. This is a definition from the first version of the p-system, in this case I.5.

  HEADER=    (* Page Zero layout changed 13-Jan-78 *)
    RECORD CASE BOOLEAN OF
      TRUE: (BUF: PACKED ARRAY[0..MAXOFFSET] OF CHAR);
      FALSE:(DEFINED:    BOOLEAN; (* New file nulls => false *)
             COUNT:      INTEGER;  (* The count of valid markers *)
             NAME:       ARRAY [0..9] OF PACKED ARRAY [0..7] OF CHAR;
             PAGEN:      PACKED ARRAY [0..9] OF PAGE;
             POFFSET:    PACKED ARRAY [0..9] OF OFFSET;
             AUTOINDENT: BOOLEAN; (* Environment stuff follows *)
             FILLING:    BOOLEAN;
             TOKDEF:     BOOLEAN;
             LMARGIN:    0..MAXSW;
             RMARGIN:    0..MAXSW;
             PARAMARGIN: 0..MAXSW;
             RUNOFFCH:   CHAR;
             FILLER:     PACKED ARRAY [0..895] OF CHAR)
    END;

Leading spaces are encoded by ASCII code 16 (DLE) followed by a byte with the number of spaces.

But for the functionality I described you don't need it, as we used the p-systems ability to understand its own text files. We only needed to understand the DIS/VAR 80 files.

Edited March 22, 2016 by apersson850

[+Vorticon]

Thanks Anders.

What I'm looking to eventually do is write an assembly language routine to extract text files from a Pascal disk to a standard TI disk and convert them to DV80 files.

[apersson850]

That's of course doable. But it's a lot easier to do it from inside the p-system. Provided you have a p-code card, obviously.

[mister35mm]

Why? Are TI that hard up for cash?

[+Vorticon]

Why? Are TI that hard up for cash?

What do you mean?

[etownandy]

I have played with it a while back, but it's pretty cumbersome to use unfortunately. There is a much better product called Turbo Pasc' 99 which is a true compiler and does not require special hardware, and I have copies of the disks and manual courtesy of Retroclouds, but the docs are in German. I have laboriously tried to translate them using OCR and Google Translate and some creative editing, but so far I've managed to do only about a quarter of the manual at best. If someone here is willing to take up that task, I'll be happy to send you what I have.

I personally love Pascal, and it's unfortunate it has been pretty much abandoned in favor of C which is a monstrosity as far as I am concerned

 

I'd be willing. I did the OCR and typeset re-work on the MDOS and ABASIC manuals several years ago.

[+Vorticon]

I'd be willing. I did the OCR and typeset re-work on the MDOS and ABASIC manuals several years ago.

Thanks but apersons was able to take on that project and we now have a completely translated manual ☺

[apersson850]

While it's true that it doesn't take any special hardware to run the Turbo Pasc'99 (no p-code card needed), it's incorrect to say that it's a much better product. From a software development point of view, there has never been any more complete platform than Pascal with the p-code card on the 99/4A. All other systems are lacking one or, usually, several of the well thought out mechanisms inherent in USCD p-system IV.0.

[+Vorticon]

Having been using UCSD pascal consistently over the past couple of months while working on Phoenix Chess, I have to say that I really like the integrated OS environment, along with the impressively advanced features of UCSD pascal, something I have not seen in any other programming language on the TI. I did dabble with Turbo Pasc'99, but was quickly put off by its very limited feature set, particularly the glaring omission of pointers.

I wish there was a way to clone the p-code card somehow as they are rarer than hen's teeth nowadays. Thankfully, the p-code emulation in Classic99 and MESS is very faithful, so that helps tremendously. As a side anecdote, Harry Wilhelm sold me his p-code set up about 12-13 years ago on he condition that I will not resell it and that I will actually use it. Well, it only took a little over a decade but I am keeping my promise I have this odd habit of only buying hardware that I will actually use...

[+Ksarul]

If the Vienna users hunt around, they may find a set of GRAM files that put the entire p-Code card on a GRAM/GROM cartridge. . .I know it exists and was developed there around 1990 or so. I even tested it for Alexander Hulpke (one of the beta testers of the software) on my Geneve at the Berlin TI Treff back in the early nineties. I wasn't permitted to keep a copy of it, unfortunately, but it worked flawlessly. I mention Vienna as a place to look, as it was developed there, but if anyone is still in contact with Alexander, that is also a possible avenue towards locating a copy. I suspect we could easily load that onto an UberGROM if it ever turns up. . .

[apersson850]

That's of course doable, but notice that the p-code card, although it contains GROM and 12 Kbytes of ROM, just like Extended BASIC does, is completely different in how it's implemented.

• The p-code card uses a different set of GROM access addresses. This is necessary since the p-code card has eight GROM, not just five. Thus it can't use the standard addresses, or it would come in conflict with the three GROM in the console.
• The p-code card has the GROM access addresses mapped into DSR memory space. Since they overlap precious ROM space there, they are fully decoded. Console GROM access addresses aren't.
• The p-code card has 12 Kbytes of ROM, just like Extended BASIC, but this ROM is all in DSR space, not command module space. Also, bank switching is done with a CRU bit, not by writing to a ROM address, like Extended BASIC does.

All of this can of course be handled, but perhaps not by a device developed to allow normal command modules to run on the machine. A GRAM Kracker wouldn't do, for example.

[+Ksarul]

Actually, the version I saw ran perfectly out of any standard GRAM device available in Europe at the time. I saw it tested on a Mechatronics GRAM Karte, a Wiesbaden Supermodul II, and on a Geneve 9640 in TI mode. In all cases, the resulting software was running out of cartridge space. The author had modified the p-System interfaces to the rest of the TI to work that way--and it worked well. I still grumble to myself for not having spirited a copy of it onto my RAM Disk since the program never did get released (it was intended as an eventual commercial release), but then again, I promised not to do something like that, so I definitely made the correct decision.

[apersson850]

After modifications everything is possible, of course. What I referred to was that an unmodified dump of the contents of the p-code card would not run from a normal GRAM device, as all addressing will be wrong in such a case.

[+Vorticon]

Hi. Is there a way to set the system date from within a program rather than going through the D command in the Filer? Also, how does one access the current system date in a program?

[apersson850]

Use the unit screenops. Normally it's available in SYSTEM.LIBRARY, but if not, access from wherever, or include it there.

You can see the outline of how to set the system date below. In the small program below, I don't show how to write a poke procedure in Pascal. Neither do I show the details of how to get a date record into an integer, which usually is what you poke. If you don't know how to do this, neither with the variant record nor with the ord trick particular to UCSD Pascal, come back.

program datefix;

uses screenops;

const sysdate = 13840;

var info: sc_info_type;

begin
  (* Store date in system *)
  sc_use_info(sc_get,info);
  with info.sc_date do
  begin
    year := 16;
    month := 5;
    day := 6;
  end;
  sc_use_info(sc_give,info);

  (* The system keeps a copy in RAM for immediate access. *)
  poke(sysdate,date_as_an_integer);
end.

Edited May 6, 2016 by apersson850

[+Vorticon]

Anders, where did you find the info on the scrrenops unit? The compiler manual just mentions that it is used by some of the system intrinsics.

[apersson850]

Oh, you are asking about things done 30 years ago! I can hardly remember what I did yesterday...

 

But probably from some Internal architecture gudie for the UCSD p-system. As far as I can remember, the interface text section is intact in the system's compiled screenops unit, so you can read it there using decode.

The fact that you have to poke the date into the copy in RAM for everything to work I found out when I wrote startup programs that could read the current date from real time clocks and set it in the p-system automatically. Without poking into that RAM location, I had to re-initialize the system for the new date to be valid and used by all functions.

[+Vorticon]

It appears that the interface text is empty when I use Decode... In any case, I'll take your word for it unless I can lay my hands on a UCSD p-code technical manual

One issue: which unit has Poke in it?

I'm kind of surprised that the UCSD designers did not think of having a straightforward date setting function included in the system.