Pascal on the 99/4A

[apersson850]

I found the newsletter (Programbiten) from 1987, where I wrote a recommendation for how to distribute the files, if you were to use the UCSD p-system with two SS/SD diskettes. I can replicate that article here, if useful to anyone, but I'm not too convinced anyone is trying to run a system with that kind of configuration nowadays?

 

If you don't ask for that information, I'll not do the work of writing it here. But if somebody needs it, then I'll do it.

Edited December 22, 2018 by apersson850

[patrickmcmichael]

A lifetime ago, when I still had my original TI-99/4a, I had gotten my hands on a P-Code card, and if I recall, including all disks and manuals. Sadly, I let that go when my daughter was born and I was making room.

 

Two questions:

 

1) I've been rebuilding my TI-99/4a setup over the last year, and just snagged a p-code card on eBay, as well as the manuals for Editor, Filer, and Utilities. Those should arrive soon. However, I do not have the disks as this was card only, nor the manuals for assembler/linker, which I was told were originally sold separately from the p-code system...? (since we're talking p-code for running in the p-system, not machine code, I'm assuming we're not talking about some reuse of the assembler/linker from Editor/Assembler, are we? guessing this was something dedicated to the p-system)

 

2) Based on CRU/DSR for the P-Code card, any particular slots it should go into? I know some cards could go anywhere and some were particular about where and what order.

[+Vorticon]

3 hours ago, patrickmcmichael said:

A lifetime ago, when I still had my original TI-99/4a, I had gotten my hands on a P-Code card, and if I recall, including all disks and manuals. Sadly, I let that go when my daughter was born and I was making room.

 

Two questions:

 

1) I've been rebuilding my TI-99/4a setup over the last year, and just snagged a p-code card on eBay, as well as the manuals for Editor, Filer, and Utilities. Those should arrive soon. However, I do not have the disks as this was card only, nor the manuals for assembler/linker, which I was told were originally sold separately from the p-code system...? (since we're talking p-code for running in the p-system, not machine code, I'm assuming we're not talking about some reuse of the assembler/linker from Editor/Assembler, are we? guessing this was something dedicated to the p-system)

 

2) Based on CRU/DSR for the P-Code card, any particular slots it should go into? I know some cards could go anywhere and some were particular about where and what order.

All the pcode disks and manuals as well as a tutorial document are located here.

The card can go into any available slot.

 

[patrickmcmichael]

6 hours ago, Vorticon said:

All the pcode disks and manuals as well as a tutorial document are located here.

The card can go into any available slot.

 

Thank you! Where can I get the content for the disks that came w/ the p-code card? The zip file appeared to be PDF manuals only (super useful...just need the disks since my eBay purchase wasn't the full set, and I'll eventually put this on FD emulator anyhow).

[apersson850]

Although I've mainly stayed with the real 99/4A, or use a modern computer in the way that's intended, I'm aware that there are methods to transfer disk images (PC ecosystem) to real diskettes, that can be used by the 99/4A. But I've never used them. The other method is of course having somebody make copies of the original disks for you.

 

You're right in that the assembler and linker for the p-system have no relation to the Editor/Assembler package. Except for being able to assemble TMS 9900 code, of course.

[+Vorticon]

4 hours ago, patrickmcmichael said:

Thank you! Where can I get the content for the disks that came w/ the p-code card? The zip file appeared to be PDF manuals only (super useful...just need the disks since my eBay purchase wasn't the full set, and I'll eventually put this on FD emulator anyhow).

Hmmm... It looks like the link to the disks is dead.

Here are the images. I'm also including the Turtle Graphics disk and manual developed by apersson850. He's our UCSD Pascal guru for the TI

 

ASM-LNK.DSK

COMPILER.DSK

EDT-FIL.DSK

UCSD-UTI.DSK

turtle.dsk

UCSD Turtlegraphics manual.rtf

[+Vorticon]

And here's the tutorial text. Very helpful to get you started.

Introduction to UCSD Pascal System.pdf

[+Vorticon]

So I've got a TIPI in my PEB now at CRU 1000, which is lower than my disk controller living at 1100. Shouldn't I theoretically be able to use TIPI drives mapped to DSK1-DSK3 with my pcode card? I tried that and it did not work...

[apersson850]

No, you shouldn't, because if I've understood it correctly, TIPI doesn't implement sector access. Or simulated sector access, is probably the right expression. The p-system uses sector access at the bottom level, then implements its own file system on top of that. If the TIPI doesn't list the sector read/write subprogram in its DSR, then it will not be accessed.

[+Vorticon]

2 hours ago, apersson850 said:

No, you shouldn't, because if I've understood it correctly, TIPI doesn't implement sector access. Or simulated sector access, is probably the right expression. The p-system uses sector access at the bottom level, then implements its own file system on top of that. If the TIPI doesn't list the sector read/write subprogram in its DSR, then it will not be accessed.

Thanks for the explanation. Makes sense. Too bad though as it would have sped up compilation quite a bit compared to physical disk access.

[apersson850]

With some operating system patching, you can use a RAM-disk. Just beware of the current ROS software for the Horizon RAM-disk. It exploits a characteristic of the console's DSRLNK routine, but that fails when the subprogram is called from the p-system.

Or the TIPI thing could be modified to provide a storage area with simulated sector access.

Edited July 20, 2020 by apersson850

[+Vorticon]

1 hour ago, apersson850 said:

With some operating system patching, you can use a RAM-disk.

I sold my RAM disk when I got a TIPI. It just did not make sense to have both. Oh well...

[apersson850]

We are writing around each other. I just edited my previous post, to make it a bit more comprehensive.

I do use a Horizon RAM-disk with my p-system. Either I run an older DSR on the RAM-disk, or use one I wrote myself. My own only supports sector access, so it's useful only with the p-system. And could be used by some Forth-systems, I presume.

 

The reason for that the operating system (p-system) must be modified a bit to allow for a RAM-disk is that the BIOS, doing the lowest level disk access, presumes that only one disk controller exists. In other words, that all disks are accessed via a controller with one single CRU base address. So modifying it to allow the use of four disks, if you replace the TI controller with a CorComp, is as simple as filling in the existing tables for the fourth disk with the same values as for the first three. It's still the same controller. But a fifth disk will not do, if that disk has a different CRU base address.

 

By the way, if the compiler is on a RAM-disk, compile time is reduced to about half on a real TI 99/4A.

Edited July 20, 2020 by apersson850

[patrickmcmichael]

On 7/20/2020 at 5:05 AM, Vorticon said:

Hmmm... It looks like the link to the disks is dead.

Here are the images. I'm also including the Turtle Graphics disk and manual developed by apersson850. He's our UCSD Pascal guru for the TI

 

ASM-LNK.DSK 90 kB · 3 downloads

COMPILER.DSK 90 kB · 3 downloads

EDT-FIL.DSK 90 kB · 3 downloads

UCSD-UTI.DSK 90 kB · 3 downloads

turtle.dsk 536.88 kB · 3 downloads

UCSD Turtlegraphics manual.rtf 59.93 kB · 3 downloads

Thank you!

[patrickmcmichael]

20 hours ago, apersson850 said:

We are writing around each other. I just edited my previous post, to make it a bit more comprehensive.

I do use a Horizon RAM-disk with my p-system. Either I run an older DSR on the RAM-disk, or use one I wrote myself. My own only supports sector access, so it's useful only with the p-system. And could be used by some Forth-systems, I presume.

 

The reason for that the operating system (p-system) must be modified a bit to allow for a RAM-disk is that the BIOS, doing the lowest level disk access, presumes that only one disk controller exists. In other words, that all disks are accessed via a controller with one single CRU base address. So modifying it to allow the use of four disks, if you replace the TI controller with a CorComp, is as simple as filling in the existing tables for the fourth disk with the same values as for the first three. It's still the same controller. But a fifth disk will not do, if that disk has a different CRU base address.

 

By the way, if the compiler is on a RAM-disk, compile time is reduced to about half on a real TI 99/4A.

My original TI had a HRD, but not my new one. If TIPI is out due to sector access issue, what about HFE images saved on a Lotharek FD emulator? I bought one of those, but have yet to install it. That's on my list when time allows. Lotharek can act like a DSK1, but not sure whether HFE format it uses will look meet sector access p-code requirement or not.

 

[apersson850]

Subprogram 10 hex must be present. That's what it is using.

[+Vorticon]

So I've picked up again my chess program in UCSD Pascal and have been working on it over the past week under emulation in Classic 99. Previously, I had been able to transfer the program work disk to the TI using Fred Kaal's DSK2PC utility coupled with an HDX-modified RS232 card. This time however, when I tried that, some of the files transferred fine and some were truncated with the latter giving a disk error when attempting to edit them. The only change was that some of the files are now larger. The directory appears fine however with the correct entries and program size. This is really problematic as I need to test the program on real hardware and also need print the source listings for debugging purposes. 

Any suggestions? How do people transfer files to the pcode system from a PC? I do have the PC99 emulator as well, and I vaguely remember that it had some facility to access and extract pcode files, which would be helpful for the printout part at least...

 

Update:

On a hunch, I checked the disk image for bad blocks using the Filer and it had a bunch of bad blocks at the end. I used the Examine option to correct that then crunched the disk. With that done, the disk image transferred perfectly to the pcode system with no corrupted file and I was able to print my source files as well as run the program. Lesson learned

 

 

 

 

[ralphb]

Here is a DS/DD disk image with all individual P system disks combined.  If your controller can handle DS/DD, the disk makes it a lot easier to work with the P system.

 

Thanks to Anders for helping me create this disk!

pcode.dsk

[+Vorticon]

I unfortunately only have the standard TI controller, so I made a disk with the Editor/Filer and Compiler combined which frees up a disk drive for the Utilities or Assembler/Linker disks.

EDT-COMP.dsk

[+Vorticon]

I have a little puzzler I'd like perhaps some insight on. Can someone please tell me why the following code does not work 

if turn>2 then
  begin
	if ((i-11) in validloc) and
       (tmpboard[i-11]=6) then
      cscore:=cscore+30;
  end;	

whereas if I reformat it as below the error goes away? Makes little sense to me as the inner begin/end pair should not be needed....

if turn>2 then
  begin
    if ((i-11) in validloc) then
	  begin
		if (tmpboard[i-11]=6) then
		  cscore:=cscore+30;
	  end;
  end;	

As a background, the index of the tmpboard array has a range of 11 to 88 which is contained in the validloc set. So if i-11 goes out of range, then the second half of the if statement in the first code snippet should not get executed, and yet it does... 

[+TheBF]

2 hours ago, Vorticon said:

I have a little puzzler I'd like perhaps some insight on. Can someone please tell me why the following code does not work 

if turn>2 then
  begin
	if ((i-11) in validloc) and
       (tmpboard[i-11]=6) then
      cscore:=cscore+30;
  end;	

whereas if I reformat it as below the error goes away? Makes little sense to me as the inner begin/end pair should not be needed....

if turn>2 then
  begin
    if ((i-11) in validloc) then
	  begin
		if (tmpboard[i-11]=6) then
		  cscore:=cscore+30;
	  end;
  end;	

As a background, the index of the tmpboard array has a range of 11 to 88 which is contained in the validloc set. So if i-11 goes out of range, then the second half of the if statement in the first code snippet should not get executed, and yet it does... 

It's been 25 years since I used Turbo Pascal but I remember struggling with these constructs too and the magic semi-colon. It might be you have a semi-colon where you should not. (?)

 

There are some suitably cryptic examples here.

https://www.tutorialspoint.com/pascal/pascal_nested_if_statement.htm

 

It doesn't really explain why which makes low level guys (me) a little crazy.

 

Is this a chess game perhaps?

 

[BillG]

3 hours ago, Vorticon said:

I have a little puzzler I'd like perhaps some insight on. Can someone please tell me why the following code does not work 

if turn>2 then
  begin
	if ((i-11) in validloc) and
       (tmpboard[i-11]=6) then
      cscore:=cscore+30;
  end;	

whereas if I reformat it as below the error goes away? Makes little sense to me as the inner begin/end pair should not be needed....

if turn>2 then
  begin
    if ((i-11) in validloc) then
	  begin
		if (tmpboard[i-11]=6) then
		  cscore:=cscore+30;
	  end;
  end;	

As a background, the index of the tmpboard array has a range of 11 to 88 which is contained in the validloc set. So if i-11 goes out of range, then the second half of the if statement in the first code snippet should not get executed, and yet it does... 

Unlike some languages like C, standard Pascal does not specify the order in which components of an expression are evaluated within an if statement.

 

By separating the two, you are forcing the skipping of the second subexpression when the first is not true.  I cannot say why the result - whether 30 is added to cscore - is different depending on the order of evaluation.  The problem usually manifests itself in protected access environments when the out-of-bounds array access faults - the 99/4 is not.

 

Borland Turbo Pascal allows choosing short-circuit evaluation in which the second part is skipped if the first determines the result.

[apersson850]

10 hours ago, Vorticon said:

As a background, the index of the tmpboard array has a range of 11 to 88 which is contained in the validloc set. So if i-11 goes out of range, then the second half of the if statement in the first code snippet should not get executed, and yet it does... 

UCSD Pascal's compiler will generate code for the whole if statement, then evaluate the condition. So if some part of it is invalid, like the array subscript tmpboard[i-11], then you'll get a Value out of range error, even if the first part already figured out that i-11 isn't inside validloc.

The compiler isn't very clever. It's instead optimized to be able to compile meaningful programs within the constraints of 48 K RAM.

[+Vorticon]

Ah ok makes sense. The array tmpboard, while declared as [11..88] of integer, only has a subset of valid locations within that range specified in the validloc set. What threw me off was the fact that while I have multiple similar constructs throughout the code, I never previously had allowed the index i to go outside the 11..88 range, unlike this case, which is why I never got into trouble previously.

Thanks for the clarification.

PS: Execution error 1 (index out of range) has been the bane of my existence with this project. Absolutely a nightmare to debug in a large multi-unit project...

 

[apersson850]

You should also be aware of that if you declare variables as array[0..88] of integer, instead of array[11.88] of integer, then at the cost of 22 bytes, which may not be too heavy, if you don't have many of these arrays, you get a faster execution speed. The compiler will not have to generate code to offset the index.

Another thing to think about is to avoid variable declarations like these

var
  board: array[11..88] of integer;
  line: string;
  i,
  j,
  result,
  points: integer;

Instead you should do this

var
  i,
  j,
  result,
  points: integer;
  board: array[11..88] of integer;
  line: string;

The latter model allows the faster short-form addressing of the first variables to be used. But it only reaches 8 or 16 words down the activation record, depending upon what you are doing. It's different for reading the value vs. fetching the address of a variable.

Note that this also applies to global variables. Declare the most used ones first, provided they aren't large data types.

The compiler also doesn't know to simplify the statement i := i+1 to i := succ(i). There is an increment p-code, but it's not used unless you give the compiler a hint. In the first case, the compiler will generate code to add one, in the second just to increment.

 

Finally, if you are using an emulator, or have means to transfer this disk to a real machine, here's a character definition file which I like better than TI's upper-case and not so upper-case font. As long as the file is present as *SYSTEM.CHARAC, which is equivalent to #4:SYSTEM.CHARAC, the p-system will use this font.

Pascalchar.dsk

Edited August 26, 2020 by apersson850