Pascal on the 99/4A

[apersson850]

Poke is not in any unit. I defined it myself, but thought that perhaps you knew how to write one.

If not, I can give you an example.

 

The code I showed comes from a startup program that reads the current date from a real-time clock and sets it in the system, if it's different from the current one. It's not a theoretical design, but actually works.

 

And, as you can see, there is a way to set the date. It's just not documented in TI's manuals, but is a standard UCSD p-system way of reading and setting the date.

Edited May 7, 2016 by apersson850

[+Ksarul]

Here'a a PDF of the Internal Architecture Guide, along with a couple of other important source books.

Internal_Architecture.pdf

p-System Program Development.pdf

p-System_OS.pdf

[+Vorticon]

Poke is not in any unit. I defined it myself, but thought that perhaps you knew how to write one.

If not, I can give you an example.

 

The code I showed comes from a startup program that reads the current date from a real-time clock and sets it in the system, if it's different from the current one. It's not a theoretical design, but actually works.

 

And, as you can see, there is a way to set the date. It's just not documented in TI's manuals, but is a standard UCSD p-system way of reading and setting the date.

 

I suppose I could write one using assembly language, but I have yet to read and get familiar with the UCSD assembler environment although I am familiar with the standard TI assembler. I have been told that the former is a better assembler. Unless of course there is an easier way to do it from within UCSD p-code

[+Vorticon]

Here'a a PDF of the Internal Architecture Guide, along with a couple of other important source books.

 

Thanks! Lots of bedtime reading

[apersson850]

Yes, poke could of course be implemented in assembly language, but there's no need to. You can use a variant record to accomplish the same thing without leaving Pascal.

program demo;

uses screenops;

const sysdate = 13840;

(* A data type to allow poking *)
type
  window = record
    case boolean of
      true: (int: integer);
      false: (ptr: ^integer);
  end;

(* And one to allow assigning a date record to an integer.
  sc_date_rec occupies the same space as one integer in memory. *)

  convdate = record
    case boolean of
      true: (int: integer);
      false: (dat: sc_date_rec);
  end;

var
  today: sc_date_rec;
  buffer: convdate;

(* Now we can write poke *)
procedure poke(addr,value:integer);

var memaddr: window;

begin
  memaddr.int := addr;
  memaddr.ptr^ := value;
end; (* poke *)

begin (* demo *)
  with today do
    year := 16;
    month := 5;
    date := 8;
  end; (* with *)
  buffer.dat := today;
  poke(sysdate,buffer.int);
end.

The trick with a variant record with only a type definition is famous for this kind of operations.

You can access VDP RAM in a similar way, from Pascal, but since the p-system frequently executes code from VDP RAM, and in such cases assumes that the VDP address isn't changed between instructions, you have to set your program to M_9900 language type, to force it into CPU RAM.

When you do want to go to assembly, you'll notice that the interface between the two languages is more straightforward than it is between BASIC and assembly. The p-system's assembler is better than the 99/4A version of TI's own assembler as well. You must link explicitly, though, as no linking with separate assembly language object code is taking place at runtime.

 

By the way, in the file p-system program development linked to above, you can on page 3-8 find the interface text of the screenops unit. There you can see where I got these data types from.

Edited May 8, 2016 by apersson850

[+Vorticon]

Ah yes. Thank you! There is a lot to learn yet from that system. Too bad I seem to be the only one currently doing anything with it... While the p-code card is rarer than hen's teeth, the p-code system is now fully implemented in both Mess and Classic99.

[apersson850]

Yes, back in those days when we used the real hardware only, I was fortunate enough to have a couple of friends who also had the p-code card in their computers. We exchanged a lot of ideas and work. The p-system is rather easy to use, but since it has quite a lot of features, it takes a while to become comfortable with them all.

 

Here's a corresponding poke procedure in assembly language.

SP      .EQU  10       ;Stack pointer in Pascal workspace is R10. Workspace at 8380H
        .PROC POKE,2   ;A procedure with two parameters
        MOV  *SP+,R0
        MOV  *SP+,*R0
        B    *R11
        .END

This then requires the following declaration in your Pascal program.

procedure poke(addr,value:integer); external;

Compile the Pascal program, assemble the assembly program, run the linker to unite the two into one object code file and you're ready to run.​

[+Schmitzi]

Hi, I found 2 more DOCs on my pile, maybe interesting, I don´t know:

 

 

p-System Assembler.pdf

 

p-System SAGE-Debugging-Tool-SDT.pdf

 

 

 

xXx

[apersson850]

As the SAGE is a completely different computer, with a 68000 processor, it's perhaps of limited value when using the TI 99/4A. But the other documents are good.

[+Vorticon]

So I'm having an issue with compiling with units.

My project has 2 units, MOVEGEN and SCOREVAL both of which compile just fine. MOVEGEN uses SCOREVAL. The main program is PHOENIX, and uses MOVEGEN. I am getting error 188 for SCOREVAL (unit not declared in previous uses declaration) when I try to compile PHOENIX and I'm not clear as to why this is the case since MOVEGEN compiles without errors...

MOVEGEN and SCOREVAL are in a user library called CHESSLIB, and I'm using {$U CHESSLIB.CODE} SCOREVAL in the interface section of MOVEGEN, and {$U CHESSLIB.CODE} MOVEGEN in PHOENIX to specify the units needed.

Any insight here would be greatly appreciated.

[apersson850]

Inside unit movegen, do you have the uses scoreval declaration in the interface or implementation part?

Do you need access to anything inside scoreval from phoenix?

Edited June 12, 2016 by apersson850

[+Vorticon]

Inside unit movegen, do you have the uses scoreval declaration in the interface or implementation part?

Do you need access to anything inside scoreval from phoenix?

 

Yes, movegen uses scoreval in the interface section. Phoenix does not use scoreval directly, but does use movegen. Puzzling...

[apersson850]

Well, then that's why. Since scoreval is referred to in the interface section of movegen, it will be seen when phoenix is compiled. But since phoenix doesn't contain any uses scoreval declaration, this comes as a surprise to the compiler when phoenix is compiled.

 

If you let phoenix explicitly use scoreval before it uses movegen, it will work. But that's unnecessary, actually even a bad choice, since phoenix doesn't need any direct access to scoreval. In movegen, place the uses scoreval declaration in the implementation section instead, and you'll get rid of the unnecessary direct link between phoenix and scoreval. At the same time, the compiler will not see the uses scoreval declaration when compiling phoenix, and thus will not care about where it's defined.

[+Vorticon]

I unfortunately have to use scoreval in the interface section of movegen because it contains some global declarations needed by the procedures in movegen whose headings are listed in the interface section.

Adding a use scoreval to phoenix before movegen allowed phoenix to compile normally. However, when I try to execute phoenix, I now get the runtime error that unit scoreval was not found! What gives?

[apersson850]

Scoreval must be located either in *SYSTEM.LIBRARY or in a library which is listed in the current userlib file.

[+Vorticon]

Scoreval must be located either in *SYSTEM.LIBRARY or in a library which is listed in the current userlib file.

 

So I'm not too clear on this, and frankly the manuals are not either.

I have a library which I created using the LIBRARY utility called CHESSLIB.CODE which includes the units movegen and scoreval, and there are no errors at compilation. Do I need yet another library for run time?

What do you mean by the "the current userlib file"?

Sorry if I'm pestering you with questions, but the UCSD manuals are not exactly beacons of clarity

[apersson850]

No, you don't need another library. But you need to tell the system where your library is. It's by default aware of the *SYSTEM.LIBRARY file, but that's all.

You need to create a text file, which lists all other libraries you are using, so that the operating system can find them during runtime. If you create a file called *USERLIB.TEXT, and the content of that file is chesslib.code, then the index file is ready. *USERLIB.TEXT is the system's default user library index file. When you've done this, the system will know where to find the file which contains the library which holds the units your program needs.

The *USERLIB.TEXT file may contain several lines, each referencing a different user library.

 

It's also possible to create a user library index file with a different name, like sweden.text. Inside the file sweden.text you enter the same as in *USERLIB.TEXT above. But now your data isn't in the default library index file, so you need to tell the system where to look. The easiest way to do this is to type X (for eXecute) at the system prompt, then key in L=sweden.text. Now you've defined which index file to use, instead of *USERLIB.TEXT.

 

Note that you must specify both the drive and the file name. *USERLIB.TEXT means that this file is on the system drive, normally the first one (#4: in the p-system, or DSK1 in the normal operating system). If that diskette's name is PSYS, then the names *USERLIB.TEXT, PSYS:USERLIB.TEXT and #4:USERLIB.TEXT are equivalent.

You also have a default prefix drive, indicated by a colon. If you set the second drive to be the prefixed one, by typing X and then P=#5, and the diskette in the second drive is named PROJECT, then the file names HELLO.TEXT, #5:HELLO.TEXT, PROJECT:HELLO.TEXT and :HELLO.TEXT are equivalent.

 

Page 105 in the Pascal compiler manual gives details about this.

 

Feel free to ask questions. by all means! It's nice that somebody else discovers the p-system.

Edited June 16, 2016 by apersson850

[apersson850]

So, did this help?

[+Vorticon]

So, did this help?

 

It did! Thank you. I just got to test it out today. Summer is a very active month for me and I haven't done any programming in over 3 weeks...

Moving forward with the project

[+Lee Stewart]

... Summer is a very active month for me ...

 

Oh,dear! Summer is only one month? No wonder it seems to be flying by too fast!

 

...lee

[+Schmitzi]

in Germany we are lucky here, this year we have summer on a sunday.

[+Vorticon]

 

Oh,dear! Summer is only one month? No wonder it seems to be flying by too fast!

 

...lee

 

It certainly can be in MN!

[+OLD CS1]

 

It certainly can be in MN!

 

Like North Dakota where there are two seasons: winter and road construction.

[apersson850]

Sweden is different. We have the white winter and then the green winter.

[+Ksarul]

That sounds like my kind of place, @apersson