Pascal on the 99/4A

[+Ksarul]

There are references to 99/4 TIBUG in there, so these files would likely be for the /4A system.

[Rossman]

I don't know what this is for exactly or where it came from...

 

UCSD Pascal Development System (198x)(Texas Instruments)(proto)(Part 1 of 2).zip

 

UCSD Pascal Development System (198x)(Texas Instruments)(proto)(Part 2 of 2).zip

 

 

These are interesting. I loaded these as user carts in Classic99 and got the following menu options:

 

1 FOR TI BASIC

2 FOR PASCAL TIBUG

3 FOR PASCAL DOWNLOADER

4 FOR PASCAL BOOT LOADER

 

(Sorry for not posting an image, Atariage and my browser are not cooperating just now.)

 

No idea what these are, or what the system requirements are to run them, or what the right configuration is for them. But they are certainly something fun to investigate as they appear to be UCSD Pascal goodies on a cartridge.

 

I know that over the years, there have been posts in Atariage about p-code implemented as a cart. Perhaps this is it? Or what somebody suspected it might be?

 

Best regards,

 

 

R.

[HOME AUTOMATION]

I had tried these on FG99 and got the same menu as you described, just blue screen on each selection though... I am not at all familiar with the P-SYSTEM. Anything with TIBUG looks interesting.

 

Good luck.

[+Ksarul]

These are definitely interesting. They aren't the UCSD P-System on a cartridge though. That was produced by a programmer in Vienna, Austria in 1991 or so. It was never released to anyone but the two or three people who beta tested it for him. I let one of those beta testers (Alexander Hulpke) test it on my Geneve at the TI Treff in Berlin, but I was not permitted to keep a copy of it. It worked perfectly.

 

These files look more to be some of the rumored prototype cartridges from TI that ran p-System programs. They are a bit different than the special cartridges that went with the p-System versions of a word processor and a spreadsheet program. The cartridge for those two programs acted more as a license key dongle. I have one of those.

[apersson850]

No, there's no compiler for the UCSD p-system that produces assembly code. The SYSTEM.COMPILER in the system produces p-code. That's the whole point with the p-system, as it makes it easier to port to different computers and it makes the code more compact. The tradeoff is execution speed.

There was a native code generator for the p-system, but I've never seen any for the TI. The native code converter takes simple p-codes and convert them to assembly code, inline with the p-codes. Complex p-codes, like segment calls, aren't translated. There's no benefit, as they have much more instructions than overhead executed.

For simple p-codes, like ADD (which adds the two values at top of stack and return them to the stack), there are a single TMS 9900 instruction which does the same thing (A *SP+,*SP). In such cases you get rid of the 7-8 instructions used by the PME to fetch, decode and execute the p-code.

 

Pascal programs, compiled to p-code, will run with the p-code card and 32 K RAM only. No p-system disks needed.

But if your program requires assembly support, the code file must be linked with the assembled code. If it uses library routines,they must be available in the *SYSTEM.LIBRARY file, or in one or more user defined libraries.

 

I've never seen the development files linked to here before. Can't comment on them.

[+videofx]

Thanks!

 

Once the P-code card comes what the easiest way to set it up for 2 DSDD drives so I can test the P-Code card and make sure everything works?

[+Vorticon]

You probably want the Editor/Filer and compiler files on DSK1 and the Utilities and Linker files on DSK2. DSK1 is drive #4 in Pascal and DSK2 is #5.

[apersson850]

No, for more "normal" Pascal development, you don't need the SYSTEM.LINKER or SYSTEM.ASSMBLER files. Leave them on a disk you insert when you really need them.

It's correct that DSK1 is p-system blocked unit #4, and the next one is #5. The next drives are #9, #10, #11 and #12. Note that in the TI, only three drives are enabled. If you add more in your system, then you have to patch the operating system's tables to enable them.

Also, you'll not frequently need the files on the Utilities disk either. At least not until you are an advanced p-system user.

 

The root disk (normally #4) also has the shortcut symbol *. If the name of your p-code system disk is PASSYS, then you can refer to it as either PASSYS:, #4: or *. The file SYSTEM.COMPILER on that disk thus has any of the three names PASSYS:SYSTEM.COMPILER, #4:SYSTEM.COMPILER or *SYSTEM.COMPILER.

 

I've once written an article about the best distribution of files for different number of drives, but from memory, I can say that on the disk in drive 1 (#4:), you would like at least these files:

 

SYSTEM.STARTUP

SYSTEM.CHARAC

SYSTEM.PASCAL

SYSTEM.FILER

SYSTEM.EDITOR

SYSTEM.COMPILER

SYSTEM.LIBRARY

SYSTEM.MISCINFO

9900.OPCODES

9900.ERRORS

 

I hope I remembered the file names correctly. Should be close enough to understand what I mean.

 

Then use the second disk as a disk for your own source and code files. You can use the p-system command p=#5 to set #5: as the prefix to file names. Then file names without volume names are automatically prefixed to point to whatever disk is in physical drive #5 (DSK2).

Edited December 12, 2018 by apersson850

[+videofx]

No, for more "normal" Pascal development, you don't need the SYSTEM.LINKER or SYSTEM.ASSMBLER files. Leave them on a disk you insert when you really need them.

It's correct that DSK1 is p-system blocked unit #4, and the next one is #5. The next drives are #9, #10, #11 and #12. Note that in the TI, only three drives are enabled. If you add more in your system, then you have to patch the operating system's tables to enable them.

Also, you'll not frequently need the files on the Utilities disk either. At least not until you are an advanced p-system user.

 

The root disk (normally #4) also has the shortcut symbol *. If the name of your p-code system disk is PASSYS, then you can refer to it as either PASSYS:, #4: or *. The file SYSTEM.COMPILER on that disk thus has any of the three names PASSYS:SYSTEM.COMPILER, #4:SYSTEM.COMPILER or *SYSTEM.COMPILER.

 

I've once written an article about the best distribution of files for different number of drives, but from memory, I can say that on the disk in drive 1 (#4:), you would like at least these files:

 

SYSTEM.STARTUP

SYSTEM.CHARAC

SYSTEM.PASCAL

SYSTEM.FILER

SYSTEM.EDITOR

SYSTEM.COMPILER

SYSTEM.LIBRARY

SYSTEM.MISCINFO

9900.OPCODES

9900.ERRORS

 

I hope I remembered the file names correctly. Should be close enough to understand what I mean.

 

Then use the second disk as a disk for your own source and code files. You can use the p-system command p=#5 to set #5: as the prefix to file names. Then file names without volume names are automatically prefixed to point to whatever disk is in physical drive #5 (DSK2).

 

 

 

My Tipi is coming soon. Can I copy all the files to just one drive on the TIPI and use one big disc?

 

Thanks for the help!

[apersson850]

You can. In theory. With some limitations. Maybe.

 

Just to make sure you understand what you are asking for, let me give you some background.

Pascal on the TI 99/4A isn't just another language. Now I'm talking about UCSD Pascal, not TurboPasc99, which is too limited to be worth playing with. Pascal comes with the UCSD p-system, which is an entire operating system on its own. When you use BASIC, you use a language that runs on top of the internal operating system. It's designed to live in the limited environment of 16 K video memory, 256 bytes of RAM and 18 K GROM. Pascal, on the other hand, requires that the computer also has the 32 K RAM expansion, as well as the p-code card, which hosts 12 K ROM and 48 K GROM. With access to these additional resources, it's not too surprising the p-system uses the computer's hardware in a different way.

 

The p-system is built around the PME, P-Machine Emulator. This is like a stack-based CPU which executes p-code. The Pascal compiler produces p-code as its output. This code is then executed by the PME.

 

The PME is a program, running on the TMS 9900 CPU, which reads op-codes, decodes and executes them, by branching to code which implements the function of the p-code. P-code execution can be done with code in CPU RAM, VDP RAM or from GROM. The inner part of the PME should of course be as fast as possible, to minimize the speed penalty of interpretation. Hence it's located in the scratch pad RAM, as that's the fastest RAM in a standard machine. Due to the complexity of running code from different memory, as well as the need to handle not only simple operations like ADD, but also more complex, like accessing local or global variables, call routines in the same or other code segments etc., the inner part of the PME is big enough to occupy half of scratch pad RAM.

 

The tables necessary to run the operating system are instead located in the 8 K RAM expansion memory. The 12 K ROM on the p-code card contains startup code, as well as the implementation of all operations the p-codes implement. It also contains the p-system's BIOS. VDP RAM is used for the screen data, disk buffer and one code pool. The 24 K RAM expansion has the heap on top, stack at bottom and another code pool in between.

I/O in the p-system is done in a different way, compared to how the ordinary operating system executes it. The totally different memory use means that the normal DSRLNK procedure, used to call the RS232 card, disk controller etc., can't be use. Instead, the p-system implements it's own I/O devices. They are mapped to doing calls to the machine's DSR's, where applicable.

 

When accessing files on disks, the p-system doesn't use the normal file system. Instead, the disks are only accessed via sector read/write calls. In these sectors, the p-system creates its own file directory and file structures. To make this work faster, the p-system does pre-calls during startup. It follows the call path long enough to find the routine to branch to when actually accessing it, and stores that address in a table. When it then does read a sector, it already knows where to branch. This works fine when the DSR is designed literally as TI outlines it in the specifications. I've noticed that the ROS 8.14 for the Horizon RAMdisk makes a clever trick, where all subprograms have the same entry address, and then figures out which one is actually searched for by looking into the internal memory use of the console's DSRLNK routine. As the p-system doesn't use that DSRLNK, this trick fails and the drive can't be accessed by the p-system, not without changing the DSR.

 

So assuming the drive emulation inside the Tipi doesn't do anything like that, it may work.

 

You should also know that the directory structure of the p-system allows for a maximum of 77 files in a directory. This was no issue when the p-system was originally designed, as disks were small and rarely had room for 77 files anyway. The IV.0 version of the p-system, which is the one implemented on the TI, stops there. Version IV.1 introduced subsidiary volumes, which was simply a one-level folder structure. That is, one or more of the 77 files on the main drive could be a virtual drive, which could hold another 77 files.

 

The p-system handles two different types of I/O devices. These are character and blocked devices. Character devices are things like printers and the screen. Blocked devices are typically disks, since you access them one block at a time. The p-system implementation on the TI 99/4A isn't designed to handle blocked devices serviced by multiple DSR programs. They are all assumed to be located in memory enabled by turning on the same CRU address. This can be changed, but requires that you patch the operating system's I/O device tables with new values. This can't be done until the system has started, and the values that ends up there on startup are those for the first disk drive it can find. During that process, the system disk is also assigned, and normally ends up being the diskette in the DSK1 (#4:) drive.

 

This was a lot of info, but I think necessary to understand why it could be somewhat of a project to do exactly what you are asking for.

 

Myself, I do like this:
Starts the system normally, with a system disk in drive 1.

Run a program which inserts the necessary values in the system's table to access my fourth physical disk (simple) and my RAMdisks (a bit more tricky). It also executes the system call UNITCLEAR on each drive, to make them ready to use.

Then I execute the Filer's command to install file directories on the RAMdisks.

Finally, I copy the files with the compiler, editor, filer, linker and assembler to the RAMdisk, for faster access. I also update the system's tables pointing to where these files are located, so it finds them there. Having the compiler on a RAMdisk cuts compile times to half the normal time.

Edited December 13, 2018 by apersson850

[+arcadeshopper]

it will not work with TIPI.. TIPI is file access only, no direct sector access

 

Greg

[apersson850]

There you go. Then normal Forth can't use it either, I presume?

[+mizapf]

I used to write some smaller programs in TurboPasc'99 when it became available; one of them used a Quicksort. But I switched to c99 later.

 

As you said, UCSD Pascal is actually a completely new platform. That means one could say that TurboPasc'99 is in fact the only Pascal for the TI-99/4A, because the UCSD system turns it into something different. To some extent this reminds me of this CP/M card that carried a Z80 onboard, but which actually only shared the power with the PEB.

[+Vorticon]

There you go. Then normal Forth can't use it either, I presume?

No, but FbForth and TurboForth should be fine.

[+Lee Stewart]

No, but FbForth and TurboForth should be fine.

 

Except for the TI Forth utilities, of course.

 

...lee

[apersson850]

Well, I'd say it's still a TI 99/4A, even if the operating system is different. Running TI Forth changes quite drastically how the computer behaves too, but we still call it the TI 99/4A.

 

The reason I wrote my little essay was to point out that you must understand that almost everything that can be done differently, is done differently with the p-code card, compared to the native computer. A few examples:

 

The screen simulates 80 characters wide, for example, by storing the "large" screen in the 8 K RAM, then copying the 40 column window currently displayed to the VDP RAM.

They keyboard uses the keypress queue, which allows type-ahead when the computer is busy doing other things.

The system allows a library system, where you can store additional functionality, which you can reference and use in your programs if you like to. Things not used aren't loaded into memory. Things used are automatically loaded, but can be removed from memory and replaced with a different library routine, provided both aren't used simultaneously. All this is automatic.

[+arcadeshopper]

There you go. Then normal Forth can't use it either, I presume?

 

nope but turboforth works great

 

Greg

[apersson850]

Does TurboForth also use regular files?

[+Lee Stewart]

Does TurboForth also use regular files?

 

It does, indeed.

 

...lee

[+videofx]

Thanks for the explanation! I appreciate it.

 

OK I got this today

 

My Drive 1 is a DSDD 5.25 and my drive 3 is DSDD 3.5" drive.

 

Whats the best way to set this up so I can test the P-Code card and make sure everything works?

 

Thanks

 

[+videofx]

I plugged the P-Code card into my PEB. This is what appears on the Screen:

 

 

Does this mean the card is working?

 

 

[+9640News]

Yes

[+Ksarul]

Your card is very much alive. It booted to the standard startup screen. You can prevent it from taking total control of your system by moving the slide switch to the other position, then the p-Code card will not take over the boot-up process.

[+videofx]

Your card is very much alive. It booted to the standard startup screen. You can prevent it from taking total control of your system by moving the slide switch to the other position, then the p-Code card will not take over the boot-up process.

 

 

Thanks! Now how do I setup my disks so I can write a simple program and test it?

[Rossman]

 

 

Thanks! Now how do I setup my disks so I can write a simple program and test it?

 

Welcome to the small but dedicated p-code community.

 

There is a collection of useful p-code disk images on whtech. This directory contains Pascal programming disk images as well as TI-Pilot and the Freeform spreadsheet. There is another directory on whtech with some other Pascal related resources.

 

And don't forget to look at the TI Development Resources page in Atariage. If you didn't get the manuals, you can get them in PDF format here.

 

I use a combination of 705.dsk and 712a.dsk as my boot disk. It has both the Filer and Editor on it, as well as some other useful utilities such as a character set mapping for true lower case characters, and a utility for changing the default screen colors. These are modest but nice touches for customizing your programming environment.

 

If you have just the standard disk drives from TI, boot the Filer disk.

 

I do most of my development using Classic 99. I use a modified version of 712a in drive 1 (#4:), the standard Pascal compiler disk in drive 2 (#5:), and my work disk in drive 3 (#9:). This works very efficiently.

 

Again, welcome to the p-code community.