Jump to content
IGNORED

UCSD Pascal disk/file format


retroclouds

Recommended Posts

I’d like to read (and eventually write) UCSD Pascal files from an assembly language program on the TI-99/4a.
What’s a good place to check for the disk and file format? Did they pull this of with level 3 file I/O or does the P-card do sector I/O?
 
Thanks
It does sector io

Sent from my Pixel 6 Pro using Tapatalk

Link to comment
Share on other sites

I've done this on the real 99/4A back in the 1980's. But it's easier the other way around, i.e. read and write standard TI files from Pascal on the p-system. That's because Pascal can do sector access in high level language, so you don't need to resort to assembly to handle the task. The ability to create records that maps the disk directory in Pascal is also very handy in cases like this.

What I and my friends did was that we could transfer p-system text files to standard DIS/VAR 80 files, and the opposite. Code files in one system has no meaning in the other, so they are pointless to transfer.

 

The intrinsics unitread and unitwrite can be used in Pascal to access disks on sector level.

Edited by apersson850
  • Like 1
Link to comment
Share on other sites

3 hours ago, apersson850 said:

I've done this on the real 99/4A back in the 1980's. But it's easier the other way around, i.e. read and write standard TI files from Pascal on the p-system. That's because Pascal can do sector access in high level language, so you don't need to resort to assembly to handle the task.

What I and my friends did was that we could transfer p-system text files to standard DIS/VAR 80 files, and the opposite. Code files in one system has no meaning in the other, so they are pointless to transfer.

 

The intrinsics unitread and unitwrite can be used in Pascal to access disks on sector level.

Thanks. Any chance you still have the assembly language available? I have a particular use case in mind and it’s more about the challenge as the practical use on short term. (What I have in mind is the integration of my Stevie editor with other languages, e.g. UCSD Pascal). I know there’s no immediate use. But what I envision is using Stevie as the IDE also for e.g. doing Pascal programming. Obviously that would also take hacking into the p-code card, hence mid-term/long-term project.

 

UCSD Pascal seems like a very powerful programming language/OS, but it’s severly handicapped by its unfriendly GUI (well if you can call it that). Having said that, I do have a p-code card now and want to get to know the system better. So please ignore my comment on usability. 

Edited by retroclouds
  • Like 1
Link to comment
Share on other sites

1 hour ago, retroclouds said:

Any chance you still have the assembly language available?

Maybe you misunderstood what I tried to say. Although I most likely have some code samples from this still on my real TI disks, there is no assembly involved. The Pascal language is powerful and flexible enough to do this without the need for any assembly. You can do disk sector access directly from Pascal level.

So we ran the p-system to do these transfers. Either the p-system read a DIS/VAR 80 file from a "standard" diskette, and stored the content on a p-system disk in a text file, or it created a D/V 80 file on a standard disk, and filled that with the text content from a p-system text file.

One more reason for doing it that way was that the p-system's text file format is more complex than the D/V 80 format. If you create a p-system text file from Pascal, you get that for free, by the operating system. If we had done it in assembly "from the other side", we would have had to handle the text file header creation in the assembly program as well.

 

There is of course no graphical user interface (GUI) with the UCSD p-system. It was invented before Smalltalk was spread. It's instead a MUI (Menu-driven User Interface). Which makes it easy to overview, since all available commands are listed in the menu. But less flexible, since you can't really add commands in any other way as normal user programs, invoked by eXecute command.

Edited by apersson850
  • Like 4
Link to comment
Share on other sites

Yes I misunderstood. I thought that the conversion from DV80 to p-system disk was done in assembly.

No reason to go low-level if the high-level Pascal can handle it. Which is impressive if you ask me.

 

Can you elaborate or give a pointer to where I can find more information on the p-system’s text file format?

Is it safe to assume that the same format is used on other UCSD Pascal systems having the same version number?

Link to comment
Share on other sites

The UCSD pascal editor is very clunky and limited to a 32 column window, which makes program development in it rather difficult, particularly when doing a lot of indentations. So Stevie would come in quite handy here, and it looks like no conversion would be needed as long as the file is saved in DV80 format. 

 

Link to comment
Share on other sites

I can't recall I've seen a detailed description of the text file format.

The general description is like this (one block is 512 bytes):

  • First two blocks are header information to be used by the text editor. There are settings for things like tab stops, automatic indentation, marker flags in the file etc.
  • Then you have pages (two blocks each) of text. The text is stored line by line, ending with CR. No line ever wraps a page.
  • A text line may have indentation. This is very common in Pascal, or programming in general, so to save space these can be encoded as a DLE character at the beginning of a line, followed by the number of spaces + 32. A line can have indentation by multiple spaces; that's allowed too.

If you ask the system to output a text file to a serial port, you'll only get the text. It's just when you transfer it between disks the header is copied too. The header is created automatically by the system, when you make a text file.

 

Here is some information at the end of the file, but it's basically the same as I wrote above.

 

On page 286 of this book there's some more information. It's obvious that the specific information in the header block is dependent on the editor program itself.

 

Edited by apersson850
  • Thanks 1
Link to comment
Share on other sites

8 minutes ago, Vorticon said:

The UCSD pascal editor is very clunky and limited to a 32 column window, which makes program development in it rather difficult, particularly when doing a lot of indentations. So Stevie would come in quite handy here, and it looks like no conversion would be needed as long as the file is saved in DV80 format. 

The p-system uses text mode, so you can see 40 columns at the same time. Then the p-system itself can handle 80 column lines, but can of course only show you 40 at a time. This has nothing to do with the editor itself, but is a limitation of the system and the hardware.

I always used two spaces for indentations on the 99/4A, not to waste screen columns. On larger terminals three spaces was common.

Link to comment
Share on other sites

2 hours ago, apersson850 said:

The p-system uses text mode, so you can see 40 columns at the same time. Then the p-system itself can handle 80 column lines, but can of course only show you 40 at a time. This has nothing to do with the editor itself, but is a limitation of the system and the hardware.

I always used two spaces for indentations on the 99/4A, not to waste screen columns. On larger terminals three spaces was common.

Thanks for the correction. Pascal is not a compact language, and I frequently end up exceeding the screen width even with parsimonious indentations. As you said, more of a hardware issue. But even the editor itself is not very intuitive although one does get used to it. Heck most of my Phoenix Chess project was written with it, but I had to frequently print the source code so I could get a good global picture given the screen limitations...

  • Like 1
Link to comment
Share on other sites

As I wrote above, I've always let the p-system create the text file. But to do it externally, you can probably just make an empty header and just set the type to text.

 

However, reading about Stevie, you declared that you intended to use level 3 file access. That kind of files aren't recognized by the p-system at all.

Link to comment
Share on other sites

On 1/21/2022 at 11:23 AM, retroclouds said:

... what I envision is using Stevie as the IDE also for e.g. doing Pascal programming. Obviously that would also take hacking into the p-code card...

This sounds interesting. How do you intend this to work? Have you done any detailed plan for this yet?

I understand that you intend to run Stevie in cartridge space. That's fine with the p-system. Since it's hosted on a card in the box, it doesn't touch the cartridge space. I used RAM there to add some functions to the p-system.

But the p-system uses everything else. Due to the complexity of the p-system, it's not enough having 60 Kbytes of ROM/GROM on the card itself. It also uses all RAM of all kinds available in the machine for its own purposes. It has quite a complex boot process, where the end result depends on the disks available at startup. Thus it's pretty difficult to launch the p-system in any other way than letting it start by itself. Which then erases everything in memory.

It's a bit more realistic to jump out of the p-system (there are points in low RAM expansion the p-system will pass on interrupt, so they are solid positions to insert a wedge in the system, if you want to branch out to other code), store everything in VDP RAM, CPU RAM and scratch pad RAM somewhere, then restore before going back again. You have to be careful about which workspace you use. Best is if that can be in cartridge space too, when you do this, so you can transfer all other memory content without messing that up too. Then you could do your text editing, as much as you like, and eventually return to the p-system.

 

You have to be careful if you end your editing with saving a text file in p-system format on one of the disks. The p-system will read the entire disk directory into memory when messing with a disk, but only on demand. So you can't know if the directory of the disk you are storing your file on is also in the RAM you saved, or if it's not. Not without inspecting memory. But the p-system's memory manager will allocate space for that directory when needed, and where there is any, so that directory copy has no fixed memory location.

 

By far the simplest method will be to save the text file as DV80, then let the p-system read and convert that file into its own text format. But it will not classify as an IDE, of course.

  • Like 6
Link to comment
Share on other sites

I have to say that I keep being impressed by how comprehensive your understanding of the p-system on the TI is. Back in the day you could have written a "Compute! Programmer's Reference Guide for UCSD Pascal on the TI 99/4A" :) 

I don't believe there are a lot of active p-system users on TI out there anymore primarily because of the scarcity of the p-code card, but I am hoping that Ralph's SD99 project which incorporates a p-system will change that. 

Full disclosure, I have been saving most of your posts in a file for future reference. 

  • Like 6
Link to comment
Share on other sites

No detailed plan yet. The way I would approach it is kinda the same as how I did it with TI Basic. Key for this to work, is that I'm using SAMS memory for running Stevie. 
When I start Stevie in the cartridge space, first thing it does is change SAMS pages before it allocates anything. Upon exit in Stevie the original SAMS page layout is restored.

 

So basically calling anything in the pcode card from Stevie would mean to move back to standard SAMS page layout or activate an own layout for the p-code card and making sure that scratchpad and VDP memory are setup in such way that it's compatible with the p-code card.

Moving out of the p-code card back to Stevie would then be a similar process. As said, that's the same approach I took for running TI Basic from Stevie with up to 5 parallel TI Basic sessions.

 

What I would have in mind for UCSD Pascal would be the SDD99 if it's available (because of the rarity of the p-code card).

 

 

 

  • Like 3
Link to comment
Share on other sites

OK. Then probably the p-code system has to start first, and come to the menu. From there, you need to fix some way of entering Stevie, where you begin by saving everything in the memory as the p-system left it. This includes VDP RAM, scratch pad RAM and the 8+24 K RAM expansion.

Now you can do whatever you like. Before you return to the p-system, you have to restore all those memory areas. If done correctly, you should be able to hand over to the p-system without it knowing that you ever halted it. Again, I think the best escape way is using the interrupt service routine, since then Stevie's actions will just look like an interrupt that took a very long time to service.

  • Like 3
  • Haha 1
Link to comment
Share on other sites

14 hours ago, retroclouds said:

What I would have in mind for UCSD Pascal would be the SDD99 if it's available (because of the rarity of the p-code card).

Sounds reasonable.

You can compare Ralph's video with this one. Mine is shot on a simulator, but the task is the same. He has less knowledge of the p-system and Pascal, though, so a few things are done more efficiently in my video.

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

Yes. I use it with a CorComp controller, having four disk drives.

There are a few caveats.

  • The dformat program supplied on the Utilities disk can't format double sided disks, although it claims it can. Solution is either to format outside the p-system, or use the replacement dformat program I once wrote. My program works with TI and CorComp controller. If used with CorComp, it also optimizes the sector interleave pattern to make best use of the p-system. It reads disks faster than the standard system, so it needs a tighter interlace to work fastest.
  • When you Zero the disk using the Filer program you have to key in the correct number of blocks, of course.
  • To use the fourth drive, the p-systems blocked device data structure must be modified. The p-system IV.0 allows for up to six drives, but the table is loaded with correct values for the three drives the TI controller can handle. This is a simple operation, as the fourth drive is controlled by the same controller as the other three. You simply copy the data from any of the existing drives to the fourth location.

 

The p-system does require that the storage device supports sector access. Since it has its own file system, FIAD systems will not work.

Another requirement is that the same controller is used for all disks. It's possible to use both floppy disks and RAM disks, for example, but to do that, you need to create a different IO device descriptor for the second controller. The existing tables in the system have space for one disk controller only. I typically store the second (and third, when using two RAM disks) in the sprite motion table, since I rarely use that with the p-system.

It also takes that the DSR doesn't make assumptions about where the DSRLNK routine stores internal values. That's why the p-system doesn't work with the latest DSR for the Horizon card. To save space in the DSR, that program peeks into the internal data for the console's DSRLNK. But the p-system uses a different DSRLNK, which searches for the DSR in the same way, but stores internal data in other places. Then the trick in the Horizon DSR blows up. I made my own DSR for the Horizon, and then you can use it as a RAM disk with the p-system.

 

Edited by apersson850
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

Yes, you can format the disk with any disk manager, that supports DSDD. The only drawback is that the CorComp disk controller, for example, by default use a sector interlacing of three. That is, you read every third sector to get them in sequence. This is fine with the normal file access method used by the standard 99/4A, as it needs to skip two sectors to handle the next one coming in. But the p-system reads the disk faster, so it will load a file faster if you have a sector interlace of two, i.e. read every second sector to get them in sequence. The dformat program I wrote will detect if it's a CorComp controller and then adjust the interlace pattern.

 

Before you can use that disk in the p-system, you use the Filer's Zero command to write an empty p-system directory to the disk. It will create a dummy file called PASCAL, a file which occupies the entire disk. It's never used for anything, but is there to prevent the standard operating system from storing a BASIC program or whatever on that disk. It just looks full to the standard operating system. The standard disk directory and the header for that file occupies the first four sectors on the disk. After that is the p-system's disk directory stored. There is also an option to have a dual directory. This is to have a copy of the directory on the disk, should you for example lose power when updating a file or something. Then you can perhaps recover by running a special program (on the Utility disk) to make the redundant directory the primary one.

 

The p-system always works with disk blocks. They are the same size, disregarding the native size of the disk sectors on the machine it's running. Then the block is mapped to the required number of sectors. A block is 512 bytes, so a DSDD disk has 720 blocks. The Filer will subtract the space used for the directories and calculate the useful part of the disk automatically. So when you use Zero, you enter 720 blocks as the space you want to use. The standard disk directory is limited to 400 kbytes (1600 sectors) due to the size of the bitmap of used sectors, but the p-system can really have disks with 32767 blocks (if I remember correctly). So if you map some larger memory device as a drive in the p-system, you can go way beyond what the standard operating system can handle on one disk. You are still limited to 77 files on a volume (in IV.0), so it doesn't make sense to make it too large. Then it's better to partition a large device into several smaller ones. Max six blocked devices, though, in IV.0.

Edited by apersson850
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

If the p-system does its own formatting, does it assume WD17xx-like disk controllers? The HDC9234 on the HFDC differs noticeably in that respect because it expects kind of a sector list and parameters in registers when you start the formatting process, which runs autonomously.

 

I could try it in MAME, in fact, but I'm not really familiar with the p-system.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...