Jump to content

Photo

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


6 replies to this topic

#1 globeron OFFLINE  

globeron

    Dragonstomper

  • 737 posts

Posted Sun Sep 9, 2018 2:44 PM

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")

 

 

 

 



#2 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,245 posts
  • Location:Eagan, MN, USA

Posted Mon Sep 10, 2018 7:23 AM

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



#3 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,741 posts

Posted Mon Sep 10, 2018 2:21 PM

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.



#4 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,245 posts
  • Location:Eagan, MN, USA

Posted Tue Sep 11, 2018 6:11 AM

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.



#5 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • 574 posts
  • Location:Campbellsburg, KY

Posted Tue Sep 11, 2018 6:51 AM

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



#6 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • 574 posts
  • Location:Campbellsburg, KY

Posted Tue Sep 11, 2018 7:22 AM

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

 



#7 apersson850 OFFLINE  

apersson850

    Dragonstomper

  • 500 posts

Posted Tue Sep 11, 2018 7:44 AM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users