77 replies to this topic

[Willsy]

Hmmm.... I thought he had it running... The GROMS at least... Is there something up with the disk format that prevents it from working?

[Tursi]

Vorticon, on Thu Feb 9, 2012 8:30 AM, said:

OK that's it. I'm re-installing my p-code card in my PEB and I'm dusting off the manuals and disks Maybe we can revive Pascal, at least on this forum! I wish UCSD pascal works on Classic 99. Tursi, any chance of this happening in the near future?

I suppose I should take another look at why it doesn't start up, it should now but doesn't. I probably screwed up the order of the GROMs or something silly.

[retroclouds]

Vorticon, on Thu Feb 9, 2012 8:30 AM, said:

OK that's it. I'm re-installing my p-code card in my PEB and I'm dusting off the manuals and disks Maybe we can revive Pascal, at least on this forum! I wish UCSD pascal works on Classic 99. Tursi, any chance of this happening in the near future?

Yeah, woul like to see some Pascal action here! I wonder why they made a PEB card instead of a cartridge. I mean TI could have pulled this of with a cartridge as well right?
Has it something to do with the bank-switching? The cartridges that come to mind that are similar would be Extended Basic and Microsoft Multiplan (bank-switching / GROMS).

Would be mighty cool if we could run Pascal in classic99.

Edited by retroclouds, Thu Feb 9, 2012 1:49 PM.

[Tursi]

Nah... in theory, the hardware interface to the pCode card is pretty simple. It does access the GROMs at a different port, though, off the top of my head I can't remember but my guess is that this alternate port address might not be available at the cartridge port.

I'll try to take a peek sometime in the near future. Work just asked me to start working weekends (as well) for the next couple of months, so time is tight.

[apersson850]

Would it fit in a cartridge? Not taking Maximem och GRAM-kracker cartridge sizes into account, since I don't think they were on the plan for TI. The p-code card has 12 K ROM and eight GROM chips (48 K), as far as I can remember.
Also, it must be able to let all other startup routines execute, and then it should take over before the normal operating system does. The p-code card accomplishes this by having CRU-address 1F00H, so it's the last card polled in the box.
The p-code GROM read address is somewhere near 5FFFH (don't remember exactly without checking the documents), but the PME is designed to run code out of VDP RAM, ordinary RAM and GROM just as well, so that's just a question about chainging a pointer.

[apersson850]

After having brought the translation of the Turbo Pasc 99 user's manual almost to the end (some appendix and example programs remaining), I can confirm that this is a pretty useless Pascal implementation. The list of reserved words lack essential things like type, record, new and dispose. No support for pointers either.
Not many Pascal programs I've written without using them, and not a single such program that performs any slightly more complex task.

[Vorticon]

It sounds like the Pascal version for the CC40 computer The latter was really not too bad given the hardware limitations, but it is almost unforgivable for a full fledged compiler like Turbo Pasc 99. Could it possibly be an omission in the manual? Stranger things have happened...

[apersson850]

At first I thought so (when the manual listed the different declarations available as being const, label, var, procedure and function. No type. But when words like type and record are also missing from the reserved words list, well...
Maybe I'll have to fire my system up to find out.

[apersson850]

Coming back to UCSD Pascal again, I thought I'd list the reasons for why that was the system and language I used most, when the 99/4A was my main computer (now that's a while ago, but still).

• Well equipped compiler for a pre-object oriented era (no classes).
  
• Compiler extended with features which makes Pascal work well in an interactive environment, as well as allows access to system devices (direct file/disk sector access, direct memory accesss) from Pascal.
  
• Dynamic memory management that works.
  
• Code segments relocatable on the fly, if they need to get out of the way from a growing stack.
  
• Separate compilation of units with interface and implementation parts, as well as both entry and exit code. Thus for example having Swedish character definitions in the program took only the line uses swedish;
  
• Units load into memory on demand only.
  
• The implementation part of units as well as the main program can further be split up by declaring SEGMENT procedures, which then are loaded into memory on demand only.
  
• Execution speed not the fastest possible, by far, but addressed both by specialized intrinsics (like SCAN and MOVELEFT) as well as a simple and easy assembly interface. Algorithms could often be tested in Pascal, then just translated to assembly when they were debugged.
  
• Better assembler than the one provided by the E/A package.
  
• Automatic linking of separately compiled modules, manual linking of external routines (assembly).
  
• Operating system reasonably easy to understand. I managed to convert it to handle four DS/DD drives, a RAM-disk, run a clock in the display all the time, implement graphics mode 2 (bit map mode) and eventually convert the system to true pre-emptive multitasking (almost - dynamic memory support in the OS has some bugs here).
  
• Operating system's character definitions can easily be changed by creating a new SYSTEM.CHARAC file.

Overall the best development environment on the 99/4A, when considering not only execution speed of the finished program, but also the road to that accomplishment. The main drawback is the demand of hardware. That's also an advantage, since it allows any cartridge to be inserted at the same time as the p-system runs. Something I used to make a RAM-disk out of a GRAM-module, for example. Or when using Mini Memory to have a place to store the software for supporting true concurrency.

[retroclouds]

I heard that the compilation phase was rather slow, because parts of the compiler had to be swapped-in from disk. Can you confirm that?
Last year I got mysef a p-code card but my system isn't currently up and running. Really wanna give it a shot in the near future.

A cool nerd project would be to write a new p-code interpreter that runs froms the cartridge space
Is it true that the existing interpreter on the p-code card can run p-code code from both RAM, GROM and VDP-RAM ?

Edited by retroclouds, Thu Feb 16, 2012 12:09 AM.

[apersson850]

Yes, it's true that the compiler took quite a while to compile anything, due to the time spent for startup, first pass, second pass and wrap up. The advantage is of course that you have a pretty useful Pascal version (with useful extensions for real-world programs) and was able to compile pretty long programs, in spite of the comparatively small memory in the 99/4A.
If you had a substantial program, more than one thousand source code lines, it took several minutes to compile. Especially if these lines also involved references to half a dozen pre-compiled units, which was often the case for a large program.

But it ran by itself and at the end you had a ready-to-run code file. Have a coffee in between.

Disk swapping was a substantial part of the time consumed. The compiler consists of about 15 segments or so (don't remember exactly), and each segment is called in from disk when needed, and swapped out if it doesn't fit any longer. By storing the compiler on a RAM-disk you cut off 30-50% of the time, depending upon the number of source lines to compile.
Code file memory management is handled by splitting the code into segments. A program needs the main segment and the segment where a called procedure is residing loaded at the same time. If the main program calls a segment procedure which in turn call a procedure in another segment, then both the called and calling segments must be loaded. But there may be other code, handling other issues, that aren't loaded at that time.

Say you have some data structure you manipulate. You may have a complex support for manipulations (handling intelligent defaults, i.e. defaults depending upon what you entered at another place), copying, pasting, checks - whatever. Then you have a multi-level sorting routine, to sort the data according to complex relations. Finally, a printout processor, which can format the data in fancy ways for printout. Then you can segment entry, sorting and printing, since they aren't done at the same time, have them all in the same program and not have to care at all about when to load, where to load, what to swap etc. The p-system does that for you.

The UCSD Pascal compiler produces dynamically relocateable code, i.e. even an executing program can be interrupted by the operating system, moved in memory and then continue from the new location like nothing happened, if for example the stach threatens to grow into the code.

On the 99/4A, there are two code pools. The primary one is in VDP RAM. All segments are loaded there, if they fit. If they are too large, or the main code pool is full, or they contain assembly code, then the secondary code pool, which resides in high memory expansion, is used.
Thus the PME (p-machine emulator) must be able to run code in VDP RAM as well as in CPU RAM. And finally, the PME can run p-code on the p-code card. Actually, the PME has a memory source pointer, which points to the read address (VDP read address or p-code GROM read address), to tell it where to run from. If that pointer is zero, it runs from CPU memory, not memory mapped memory. So executing the code from a memory bank that's read via some auto-incrementing port is easy. The trick is to convince the system to load the code there.

Low memory expansion is used to hold the 80-column screen and various routines needed for I/O, for example, since the p-code card must be turned off to allow access to things like serial ports and the diskettes.
The RAM at 8300H holds the core of the PME, p-system WS (8380H) etc.

There are some files on some locations on the internet where I list things I've found out about the system.

[apersson850]

Found this I've posted in a Yahoo group once.

After some information exchange with Thierry about bit-map graphics
and the p-system, I took my 99 off the shelf, turned it on, found
that it didn't work, repaired it and looked into the old files I
created in 1987.
I had forgotten how I did it, but it turned out that the memory
expansion of my console isn't necessary to run bit-map graphics under
Pascal. It can be done on a standard 99/4A.

These graphic procedures were written with the intention of providing
compatibility with the (integer) turtlegraphics unit that was
provided with UCSD Pascal II.1, for the Apple II+.
My unit turtlegraphics wasn't completed (probably because this was at
about the time when I started working with programming every day, and
didn't want to do that in the evenings too). But it works, and I have
all the source code.

Is anyone interested in taking this project "home", if I take the
trouble to transfer all the source code (I found out that I've even
written a manual for it!) to PC text files?
As far as I can remember, I've implemented colored line drawing, text
output and a printout of the current screen (on an FX-80 compatible
matrix printer). I think implementation of colored text on the screen
was the next thing to do, when I stopped working on this system.
I also implemented the viewport concept, which means that any
rectangle on the screen can be defined as active. Any drawing
directed elsewhere will not be performed. A line can have both
endpoints outside the viewport, but will only be drawn inside this
rectangle.

To use this feature with the p-system, I made a utility (bitreserve)
which can allocate and de-allocate the required memory in VDP RAM.
Once this is done, programs are executed just as always.
Of course, it's necessary to change mode to graphics (and back!) in
the user program, but the turtlegraphics unit takes care of saving
the necessary areas of VDP RAM.

There are also some drawbacks of minor importance, like forgetting to
de-allocate VDP RAM before loading a program like the Filer... well,
you don't forget that more than a few times.
Also, screen left and screen right accesses VDP RAM where they think
the screen is, which results in garbage on the screen.

I have Pascal and assembly files which make up the turtlegraphics
unit, and twelve different test programs, to check various functions.
Several of these test programs require my real-time clock and my I/O
card, but that can easily be changed.

Since I now have the system running, but don't intend to keep it up
(I don't have any good space for it right now), please respond within
a week or so, if someone wants me to go through the process of
transferring the files to my PC.

Best regards
Anders Persson

Then here I found a link to a summary of my attempts to make the p-system truly multitasking.
ftp://ftp.whtech.com...ultisupport.TXT

Note that the e-mail address ending with @rixtele.com is no longer current.

Edited by apersson850, Thu Feb 16, 2012 3:29 AM.

[Vorticon]

Do you think you could put in a short document the high level principles involved in accessing the bitmap mode from within Pascal? While I am extremely lousy at following someone else's code (and frequently mine as a matter of fact ), I can probably, at some point, recreate your processes from scratch and tailor them to my future needs.

Edited by Vorticon, Thu Feb 16, 2012 7:30 AM.

[Vorticon]

apersson850, on Wed Feb 15, 2012 4:43 PM, said:

Coming back to UCSD Pascal again, I thought I'd list the reasons for why that was the system and language I used most, when the 99/4A was my main computer (now that's a while ago, but still).

• Well equipped compiler for a pre-object oriented era (no classes).
  
• Compiler extended with features which makes Pascal work well in an interactive environment, as well as allows access to system devices (direct file/disk sector access, direct memory accesss) from Pascal.
  
• Dynamic memory management that works.
  
• Code segments relocatable on the fly, if they need to get out of the way from a growing stack.
  
• Separate compilation of units with interface and implementation parts, as well as both entry and exit code. Thus for example having Swedish character definitions in the program took only the line uses swedish;
  
• Units load into memory on demand only.
  
• The implementation part of units as well as the main program can further be split up by declaring SEGMENT procedures, which then are loaded into memory on demand only.
  
• Execution speed not the fastest possible, by far, but addressed both by specialized intrinsics (like SCAN and MOVELEFT) as well as a simple and easy assembly interface. Algorithms could often be tested in Pascal, then just translated to assembly when they were debugged.
  
• Better assembler than the one provided by the E/A package.
  
• Automatic linking of separately compiled modules, manual linking of external routines (assembly).
  
• Operating system reasonably easy to understand. I managed to convert it to handle four DS/DD drives, a RAM-disk, run a clock in the display all the time, implement graphics mode 2 (bit map mode) and eventually convert the system to true pre-emptive multitasking (almost - dynamic memory support in the OS has some bugs here).
  
• Operating system's character definitions can easily be changed by creating a new SYSTEM.CHARAC file.

Overall the best development environment on the 99/4A, when considering not only execution speed of the finished program, but also the road to that accomplishment. The main drawback is the demand of hardware. That's also an advantage, since it allows any cartridge to be inserted at the same time as the p-system runs. Something I used to make a RAM-disk out of a GRAM-module, for example. Or when using Mini Memory to have a place to store the software for supporting true concurrency.

It's really a shame it did not gain wider acceptance among TIers. However, now that we have excellent emulators available, it should become easier to program in UCSD Pascal. I picked up the manual last night and started reading it, and the first thing that struck me was how clunky the editor seemed, although quite functional once one gets used to it. This will take some getting used to again...

[apersson850]

The editor is different but works well once you learn all the features it has. Basically you have a command mode where you can move around things, until you give the insert command. Then you type in text until you exit with Ctrl-C.

I've made the turtlegraphics support I played with available too, so I think it should be on the net as well. Let me look around.

ftp://ftp.whtech.com...scal/turtle.TXT

Available as a word file as well, and also as a dsk image, I think.

There are programs, units, assembly support, some instructions - the works.

Basically, you have to tell the p-system that the main code pool, in VDP RAM, is much smaller than normally, to reserve space for bit map mode.
Then you switch to bit map mode. After that, you can't use normal write/writeln commands, but have to use the commands provided by the unit turtlegraphics.
You'll see what you can do in the documentation that's also in the file linked above. There is an ability to write text too, and not only on the normal screen rows, but at any pixel row.

The turtlegraphics unit more or less is operational. There are some intricate options for modifying colors when drawing more graphics on the screen, where there already is some, that aren't fully implemented. Also, I haven't implemented any sprite support on top of bitmap graphics. But as it is you can use it to draw charts and stuff. Line drawing is implemented in assembly and is reasonably fast. There are no fill commands or such, so painting large areas is tedious.

Edited by apersson850, Thu Feb 16, 2012 9:03 AM.

[apersson850]

In a joint effort, me and Vorticon have now translated the manual for Turbo Pasc 99 from German to English. Vorticon has taken on the task to upload it somewhere where you can reach it.
I took the liberty to include some translator's comments about differences and limitations compared to UCSD Pascal for the 99/4A.

[Willsy]

Feel free to upload it to planet99.net or send to me in a private message via this site and I will upload it.

Id like to experiment with UCSD but I'm afraid I'll have to wait for classic99 to catch up as I don't have the card.

[apersson850]

Well, it shouldn't be too difficult, really, to emulate the p-code card as well.
The p-system has a different file format, but it accesses disks using the sector read and write subprograms, that are supposed to be on the disk controller in all cases, so that shouldn't be any problem.
The card itself is just another PEB card. CRU base address is 1F00H.
The card has 12 K ROM. The first half (4000H - 4FFFH) is always the same. The second half (5000H - 5FFFH) is bank switched with CRU bit 1F80H.

The GROM chips are handled just like any other GROMs, but at different addresses. Note that the CRU bit 1F00H must be set to access these GROMs.

PGRMRD 5BFC Read data
PGRMRA 5BFE Read address
PGRMWD 5FFC Write data (Not used, since there's no GRAM here).
PGRMWA 5FFE Write address

Note that TI selected to keep the 400H spacing between read and write as they have for other GROMs, probably to be able to use the same routines for accessing them. Unlike the other cases, the p-code card decodes these addresses fully. Hence it's only these four words that don't access ROM on the p-code card. The assembly routines in the ROM simply jumps over these addresses.

The GROMs on the p-code card contain various data and assembly code, which is transferred to RAM (primarily low memory expansion) when the system starts up. The GROMs also contain the OS: volume. There are 8 GROM chips on the card, each with 6 K bytes of data. So it uses the full GROM address space as defined by these chips, which don't fill their entire 8 K slot. GRAM devices like Maximem or GRAMcracker can do that, but not this card.
The PME can execute code from RAM, VDP RAM or these GROMs alternatively. R13 and R15 in the PascalWS (at 8380H) are used to keep track of where the currently executing code is located. But that's handled by the system itself.

So what's new for an emulator here is to bank switch half the card by CRU bit 1F80H and allow special handling of addresses inside that higher ROM space to instead access the GROM chips on the card. Apart from that it's just dumping of ROM and GROM data from the card.

[Willsy]

That's a great break-down of the pascal card - thanks. Hopefully tursi can use that when he gets a chance to implement the emulation. I'm guessing the UI in classic99 will have change a little - an option will be required to "insert" the card into the "PEB" since it takes control of the machine on startup.

[apersson850]

The real card protrudes a bit on the rear side of the PEB. There's a switch, with which the card can be disabled, so it doesn't reply to being turned on by CRU bit 1F00H. Thus you don't have to wait through the p-system startup to be able to press Halt, and then come to the normal operating system.
If you still do that, the p-code card stores the letters 'NO' at 38FAH in low memory expansion when it exists properly after a Halt command. As long as that word hasn't been overwritten, it will not take over on a re-boot of the 99/4A. It will just run a small part of its power up routine, then exit. When the system is running, this location contains 'GO' instead. The p-system does the same kind of restart after a run-time error, so by looking at this word in memory, it will no if the user stopped it (remain stopped) or if it halted due to an error (restart again).

So it should be possible to select if the p-code card should run or not by simply let the emulator store 'NO' or 'GO' at memory location 38FAH. Then all the rest that's needed is already on the card.

Edited by apersson850, Sat Feb 18, 2012 5:19 AM.

[Lee Stewart]

apersson850, on Sat Feb 18, 2012 3:45 AM, said:

Well, it shouldn't be too difficult, really, to emulate the p-code card as well.
The p-system has a different file format, but it accesses disks using the sector read and write subprograms, that are supposed to be on the disk controller in all cases, so that shouldn't be any problem.
...

Willsy, on Sat Feb 18, 2012 4:48 AM, said:

That's a great break-down of the pascal card - thanks. Hopefully tursi can use that when he gets a chance to implement the emulation. I'm guessing the UI in classic99 will have change a little - an option will be required to "insert" the card into the "PEB" since it takes control of the machine on startup.

Classic99 does not currently allow sector writes, so that is another change we will have to await.

...lee

[apersson850]

Oh, I see. Well, the p-system accesses disks through its own procedures unitwrite and unitread, but they in turn call the BIOS to actually have this happen. In this case, that implies using the sector read and write subprograms, which are supported by the disk controllers (at least those I've used, i.e. TI's and CorComp's). I've not at all looked into how a program like Classic99 handles file access, but that's perhaps only through reading and writing the normal TI files? The p-system does create a file which seemingly works like a normal file, but this file (called PASCAL) spans the entire disk. It has no purpose except making it possible to copy the whole disk with the Disk Manager module and marking the disk as fully used. The p-system has it's own, completely different file system, where the directory and everything is inside this large PASCAL file.

When emulating the system it doesn't matter, but on a real TI you can format disks for the p-system with a different interlacing than is used by the normal OS. The p-system is faster when reading files on the disk, so the interlace skip can be one less than what the normal OS uses. This can be changed if you for example have the CorComp controller, which does support different interlacing as long as you call the formatting from assembly language, or if you write your own disk formatting program.

[Lee Stewart]

apersson850, on Sat Feb 18, 2012 11:19 AM, said:

Oh, I see. Well, the p-system accesses disks through its own procedures unitwrite and unitread, but they in turn call the BIOS to actually have this happen. In this case, that implies using the sector read and write subprograms, which are supported by the disk controllers (at least those I've used, i.e. TI's and CorComp's). I've not at all looked into how a program like Classic99 handles file access, but that's perhaps only through reading and writing the normal TI files? The p-system does create a file which seemingly works like a normal file, but this file (called PASCAL) spans the entire disk. It has no purpose except making it possible to copy the whole disk with the Disk Manager module and marking the disk as fully used. The p-system has it's own, completely different file system, where the directory and everything is inside this large PASCAL file.

When emulating the system it doesn't matter, but on a real TI you can format disks for the p-system with a different interlacing than is used by the normal OS. The p-system is faster when reading files on the disk, so the interlace skip can be one less than what the normal OS uses. This can be changed if you for example have the CorComp controller, which does support different interlacing as long as you call the formatting from assembly language, or if you write your own disk formatting program.

You can, indeed, use TI disk images with Classic99, which, it would appear, is what the p-system requires. TI Forth is the same way with Forth screens. They are all handled by sector reads and writes. Sector reads work just fine with Classic99. Sector writes are understood by Classic99---it's just that Tursi has not yet allowed the sector writes to do anything but throw a disk error. I think he plans eventually to fully implement sector writes when he has the time and inclination to do adequate testing; but, he is being super careful in that regard.

...lee

[Vorticon]

apersson850, on Fri Feb 17, 2012 12:50 PM, said:

In a joint effort, me and Vorticon have now translated the manual for Turbo Pasc 99 from German to English. Vorticon has taken on the task to upload it somewhere where you can reach it.
I took the liberty to include some translator's comments about differences and limitations compared to UCSD Pascal for the 99/4A.

I'll post it the document under the pinned Development thread here and on Planet 99 as well. I'll also create disk images of the disks I have for posting as well.

[Tursi]

Thanks, apersson850, I'll save these notes off to test against my code. All the hardware is fully implemented, I suspect I just have the wrong roms in there. It actually already has a way to enable it (in that it loads as a cartridge), properly takes over and even makes it two beeps into the initialization. ISTR that while examining VDP, I found evidence that it was actually running, just not displaying a picture. But I've had a folder set aside with fresh roms and notes for a bit over a year now, waiting for that to become priority. I guess that's nudging its way up now!

And Lee is right on the sector write issue. I suppose I will eventually have to turn that on, I'll just feel bad if it messes up anyone's disks. Everyone keeps backups, right? (Maybe I'll create backups myself...)