Differences betweeen UCSD Pascal on the TI-99/4a compared to TI-99/8

[+retroclouds]

I Apologize if this has been asked before. Do any of the Pascal experts have details on the differences between UCSD Pascal on the TI-99/4a compared to the unreleased TI-99/8.

 

I am interested in differences between language features, capabilities but also the technical setup.

It seems that on the 99/8 UCSD Pascal is better integrated as on the TI-99/4a. Don’t really like how the p-code card takes control when starting the TI-99/4a.

I know of the p-code card switch, but that’s kinda cumbersome. Is it correct it can also be temporary disabled by writing “NO” to a certain memory location.

 

Reason for asking is, if it’s perhaps easier to integrate the 99/8 UCSD Pascal in the TI-99/4a.

[apersson850]

If you quit the p-system by typing H(alt as the system prompt, then it exits to the standard operating system and stores NO at a memory location in 8 K RAM. If it finds NO there at startup, it will not start running.

Reason for it "taking over" is that it's a completely different operating system. If you want it, you keep it on, otherwise you use the switch to disable it.

 

The p-system version in the 99/4A is IV.0. I found a reference (Wikepedia) stating that the 99/8 was supposed to have version IV.12.

 

The problem with implementing a different p-system (on real hardware) is that you need somewhere to put it. 48 K GROM and 12 K ROM, and newer versions have more functions, so they need even more space.

Edited December 15, 2022 by apersson850

[+Ksarul]

I will have to dig out my pSytem disks for the 99/8 and verify which version is on them. Memory says it is V4.11, but I will have to verify to be sure.

[+retroclouds]

Just came accross this 99/8 video

 

 

 

[+retroclouds]

How I wished this would be available for purchase

 

 

[apersson850]

Yes, that would be nice. For many, it's the hardware that's the thing to get hold of, not the programming and handling. But there are some small details that aren't optimal in his video, or somewhat wrong.

• No space needed after writeln.
• Ctrl-C is actually ETX (End of Text), so nothing surprising there.
• You can use disk prefixes to make the file name handling simpler.

You can compare with this one, if you like.

 

 

Edited December 17, 2022 by apersson850

[+retroclouds]

I came across this document that describes the bootstrapping of UCSD Pascal on a new platform.

http://pascal.hansotten.com/uploads/ucsd/softech/Adaptable pSystem 4.pdf

 

And as a reference to myself, the place to look for lots of cool information on UCSD Pascal by Hans Otten:

http://pascal.hansotten.com/

 

If I understand correctly UCSD Pascal IV on the TI-99/4a must have originated from the "Adaptable System"
Wonder if Texas Instruments employees implemented the p-code interpreter themselves or if it was a task delegated to university students.

Guess that some fiddling was involved to get it to work with 32K of RAM.

 

And if it has been done once, it can be done twice.

With the Finalgrom around I don't see a reason why a new bootstrapping, a new p-code interpreter couldn't be implemented.

Sure, not for the faint of heart. But there is a lot of documentation and reference material out there.

 

**EDIT** Interesting to add is that the 9900 is referenced in the bootstrapping document, e.g. for byte order configuration.

On the PDP-11, LSI-11, 8080, 9900, 6502, 6809, and Z-80 systems HAS WORD ORIENTED MACHINE is always FALSE.

HAS BYTE FLIPPED MACHINE is FALSE for all IV.0 systems except the 9900.

[apersson850]

The PME (P-Machine Emulator, i.e. the p-code interpreter) is not that difficult to get in there. Most of the instructions are pretty simple. Some can be executed by one single instruction by the TMS 9900, due to its memory-to-memory architecture. There are a few instructions that are very complex, like the CXG (Call eXternal Global procedure). They are interpreted not by a few assembly instructions, but by full scale programs, doing calls to various operating system functions too, depending on the situation.

In the 99/4A implementation, the brunt of the PME is running from the p-code card. Some parts are moved to 8 K RAM, since they have to run outside of DSR space, or they need to be possible to modify. The op-code jump table, for example, is in RAM, which makes it easy to change the PME one instruction at a time. You can simply change the jump table to point to some new interpreter code somewhere.

 

The next level above the p-machine, the BIOS, also resides on the p-code card. Quite a lot of it is in the second ROM page. Parts are in 8 K RAM, since to access some peripherals (RS232, disks), you need to turn the p-code card off.

 

It's rather fitting the operating system in 32 K RAM, and still have space for the user's code, that's tricky. Now the p-system does use the VDP RAM too, so it's really 48 K RAM that's used. To give a sensible space for the user's code, the PME has been modified to be able to run p-code directly from CPU RAM, VDP RAM or GROM. Thus the parts of the operating system that's stored in GROM on the p-code card can be executed from there, without the need to first move it to RAM, as would be the case with p-systems that are stored on diskettes only. This improves both memory management and execution speed.

 

Normally a IV.x p-system has only one code pool. This is then located in a RAM segment, where you have the stack at the high end, the heap at the low end and the code in between. Some systems with more memory than 64 K also implemented a separate stack/heap space, to allow both data and programs to occupy 64 K each, not having to compete for space in the same 64 K RAM. They had the code pool in one RAM segment and stack/heap in a different one.

The 99/4A is the only one I've come across that has more than one code pool. It actually has three, where the 24 K RAM is the one that also holds the heap and stack. Code is primarily loaded in the VDP RAM, though, as long as it fits. The third pool is the GROM on the p-code card, which is fixed. It can only run code stored there from the beginning.

P-systems prior to IV.0 stored code on the stack.

Edited December 19, 2022 by apersson850

[+retroclouds]

Just a marker to myself, so I don’t forget about this great document:

http://www.thebattles.net/sage/img/Internal Architecture.pdf

 

[apersson850]

One obstacle is that we don't have any source code for the p-system IV.0, with PME, BIOS and the other stuff, for the TI 99/4A. None I've ever seen, at least. Which implies quite a bit of work in understanding what's going on, before you can start modifying it to launch from a different platform than the p-code card. Or implement another edition of it, like IV.12 or whatever. At least the PME should be identical for all IV.x systems.

[TIm Htown]

Are the TI-99/8 pascal disks up on the WHT site or somewhere else?

[+Ksarul]

On 6/3/2023 at 11:58 AM, TIm Htown said:

Are the TI-99/8 pascal disks up on the WHT site or somewhere else?

Not sure if anyone has ever extracted them, as the originals are all 320K DSDD disks which can generally only be read by a TI DSDD controller, the TI 5.25 HexBus Floppy, or either of the Myarc controllers in a standard 99/4A. Any DSDD controller can read them on a Geneve though, as its Master DSR supports that format.

[apersson850]

I just looked at the YouTube video of an emulated 99/8 running the p-system. There's an attempt to read volume #1, assuming it's a disk. But unit #1 is CONSOLE:, i.e. the keyboard and screen. The first disk unit is #4, followed by #5, #9 and up to #12.

We can also see that the version is reported as IV.12.