Jump to content
globeron

UCSD-P code card, possible to run on FinalGrom or via TIPI ?

Recommended Posts

Hi all,

Just thinking out loud.

 

Is it possible to create a UCSD-P (Pascal) version on the FinalGrom (and then use the diskettes on a NanoPEB or normal attached floppy disk system?)

 

(or on a TIPI, but I do not have experience with it).

 

We can run UCSD-P already on all the main emulators (see my video channel on YouTube "TI99 Videos")

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

The pcode card is a separate environment entirely that merely uses the TI facilities (display, drives etc...). I'll let apersson elaborate on that one (I think it's been asked before somewhere...).

Share this post


Link to post
Share on other sites

I have seen a modified version of the p-System that ran out of cartridge space--it was made by one of the programmers out of Austria. I was allowed to load it to test on my Geneve at the Berlin TI Treff, but I was not allowed to keep a copy, as the person asking me to do the test was one of the software's beta testers and he wasn't allowed to distribute it further. Unfortunately, that was also the last time I ever heard of it. It worked flawlessly too. . .

 

Maybe the tester still has a copy today: it was in the hands of Alexander Hulpke, for those in Germany who might still be in contact with him.

  • Like 2

Share this post


Link to post
Share on other sites

I have seen a modified version of the p-System that ran out of cartridge space--it was made by one of the programmers out of Austria. I was allowed to load it to test on my Geneve at the Berlin TI Treff, but I was not allowed to keep a copy, as the person asking me to do the test was one of the software's beta testers and he wasn't allowed to distribute it further. Unfortunately, that was also the last time I ever heard of it. It worked flawlessly too. . .

 

Maybe the tester still has a copy today: it was in the hands of Alexander Hulpke, for those in Germany who might still be in contact with him.

 

Do you recall the difference between the cart version and the actual pcode card by any chance? I'm curious as to how this feat was pulled off.

Share this post


Link to post
Share on other sites

I've sent an email to an Alexander Hulpke that has a mathematics background that now resides at Colorado State University. Is this the same person for those that may have known his background?

Beery

Share this post


Link to post
Share on other sites

That is the same Alexander Hulpke. None of his equipment made the move to the US when he came here in 2001.

 

I have pointed him towards this thread, so maybe he will say hello, etc.

 

Beery

 

  • Like 2

Share this post


Link to post
Share on other sites

The p-code card contains 12 K of ROM and 48 K of GROM (8 chips).

CRU base address is 1F00H. The ROM is in DSR space, 4000-5FFFH. The last 4K (5000-5FFFH) are bank switched via CRU bit 1F80H.

The GROM address I don't remember without checking, but it down in the 5C00H-area. The address decoder for CPU address access decodes these addresses down to the specific words, so that normal code can use all other addresses.

 

The program on the p-code card includes instructions which transfer a large segment of startup code to 8 K RAM on startup, then more code and data to that area for operation. It also contains routines which move the inner part of the PME to RAM PAD (8300H) for faster execution. Parts of this code references data in DSR space.

 

To move it requires that either you can have it available in the same memory area, controlled by the same CRU bit, or you have to rewrite all code to respond to other addresses. Like if you want to run it in cartridge space instead. Note that there are several tables used to point to different code segments as well, so not only easily detected Branch instructions need to be changed.

You also have to allocate memory addresses for GROM access elsewhere than in DSR space, if you move it to cartridge space.

  • Like 4

Share this post


Link to post
Share on other sites

Dear all:

I try to map on TIPI one of the P-code card's system disk as DSK1.

However it's just not loading it.

The card is only seeking the physical drive.

No one try?

Any idea?

Thanks in advance.

 

  • Like 1

Share this post


Link to post
Share on other sites

When you created the map drive, using ti basic, call tipi, setting drive 1 to point to a tipi drive, don't forget to press W to make the change.

Share this post


Link to post
Share on other sites

I guess I should add error checking to the mapping code for TIPI so you get feedback that you've entered an invalid mapping. TIPI mapping cannot target a disk image, it can only target a directory on the TIPI drive. When you put a valid disk image of files for the 4A on the TIPI, it automatically converts it to a directory of TIFILES FIADs. I don't think this is possible for P-Code.

 

I highly doubt P-Code uses LVL3 or LVL2 IO routines for 'file' access. I recall hearing P-Code used it's own floppy format... so I assume it needs LVL1 (read-write any sector) access. TIPI doesn't have LVL1 access, there are no sectors on a TIPI.

TIPI does support LVL2 file block IO... but that's a different thing... 

 

I have it on good authority that the developer of TIPI doesn't own a P-Code system so he's not likely to ever support it.

  • Like 2

Share this post


Link to post
Share on other sites

The p-code card does indeed use the sector read/write subprogram in the disk controller's DSR. That's the only thing it ever uses. It imposes its own file handling on top of that procedure. Storage devices that don't provide sector access can't be used.

The p-system also applies a pre-scan of IO-devices, to reduce the access time each time they are called. At start-up, it will scan for the DSR units it needs, like the disk controller and RS-232 card. It will then remember the CRU base address and program entry address for the service it needs on the card. When these devices are later called, no full DSR search is done. It just turns on the CRU enable bit and jumps to the entry of the DSR.

 

This not only makes DSR calls faster, but it does imply that you can't have more than one disk memory controller and one RS-232 card used by the system. Thus you can't have a standard floppy controller and a RAM disk at the same time, even if you only have two physical disk drives. You have to patch the system to create a new IO-unit for the RAM disk.

Neither can you use a CorComp controller with four drives without patching the system's tables for IO-units. But that's easier, since it's still the same controller. Thus you only need to copy the values for any of the first three drives to the empty space for the fourth one. But a RAM disk can't copy the standard values, as a RAM disk isn't handled by the normal disk controller.

  • Thanks 2

Share this post


Link to post
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.

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...