Jump to content
IGNORED

Pascal on the 99/4A


apersson850

Recommended Posts

Hi, I am also getting into my p-System again on TI-99/4a and SNUG SGCPU. It'd be great to discuss ideas with others enthusiastic about this card. I tried getting the OS disks to run from my RAM Disk (Horizon clone), but after looking at the ROS DSR, I think it arbitrarily writes to CPU RAM locations and corrupts the p-Systems memory space, so will need some modification. It'd also be great to get it working with the SNUG SCSI2 interface.

 

Maybe it's possible to make the p-System ROMS/GROMS run from the SNUG HSGPL card, so I can save a slot in my PEB.

 

Dragonstomper, how was the book?

Link to comment
Share on other sites

Doesn't sound too likely that the RAMdisk writes to random locations in the computer's memory, since that would most likely ruin not only the p-system, but other software too.

I made my own RAMdisk for my p-system, so of course I made a driver which would behave. But a friend had a RAMdisk from a commercial vendor, and we got that running too. I'm not sure about the brand, though. Maybe Horizon. Did CorComp sell RAMdisks too?

 

The p-system in general is prepared for six drives, but TI only enabled their version for three, since their drive controller card didn't support any more than that. So you have to modify some system tables to make additional drives work. I run my system with four physical 5 1/4" drives and one RAMdisk, so that's doable, for sure.

Link to comment
Share on other sites

I should perhaps add that my RAM-disk driver supports only the subprogram to read and write sectors on the disk. That works fine, so that prooves that nothing else is needed by the disk system to support the p-system. Just ship data to and from the normal sector buffer in the machine.

The p-system accesses disks in chunks of blocks, which are 512 bytes long, but the BIOS part in the PME translates that to two 256 byte sector accesses, so that's nothing the disk memory system needs to account for.

Formatting I do separately, using an assembly program I linked into my own dformat.code.

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

  • 4 months later...

UCSD PASCAL and the p-SYSTEM

 

Well, that goes back a ways. I have two PEBs and complete TI-99/4A systems.

One of the PEBs contains an actual p-code card...... and they have always been

as rare as hen's teeth.

 

I used UCSD Pascal during 1983 through 1986. While I was working at Sperry Corporation here

in San Diego, I actually went over to UCSD and took three Pascal programming courses. The computer

labs where you were supposed to do your assignments, etc., were more crowded than a sports bar during

the SuperBowl!!!

 

My solution was to get a p-code card for my TI, and work at home. The instructors wanted a listing and a floppy

with the source code for each assignment. No problem. I had a great time. I was able to program UCSD Pascal

AND drink beer......!

 

I sure would like to run the UCSD p-System on the emulator / simulator environments we have now........

Win994a, TI994W, Classic-99 and MESS.......

 

Is anyone working on something like that?

Link to comment
Share on other sites

Hi Rod,

 

at this time you unfortunately can't run UCSD Pascal on classic99.

But as far as I know you should already be able to run UCSD Pascal on MESS.

 

I suppose you'll need an image of the p-code card ROM and GROM (which I can't provide) but the disk images

and scanned version of UCSD Pascal reference manuals are available in the Development Resources Thread.

Link to comment
Share on other sites

  • 3 weeks later...

Here's the latest status update on Turbo Pasc'99:

 

I have been unable to create a working image of the main compiler disk I have. It will run on a real machine, but compilation and file saving operations crash the system. If anybody here has any ideas on how to create mirror image dsk images of these disks, please let me know.

 

I realize this may be a little late for this, but I DO have the ability to make mirror copies of real floppies, regardless of content or protection scheme. If that is what you were after? If so, let me know. I'd more than happy to help if so.

 

-D

 

"Long Live the TI-99/4a!"

Link to comment
Share on other sites

I realize this may be a little late for this, but I DO have the ability to make mirror copies of real floppies, regardless of content or protection scheme. If that is what you were after? If so, let me know. I'd more than happy to help if so.

 

-D

 

"Long Live the TI-99/4a!"

 

The issue with Turbo Pascal'99 is the copy protection. I don't know if its possible to make a perfect image that is runnable on emulators (writing in-between sectors or something like that).

My problem is that I can't convert physical disks to images. Perhaps Walid can send you a copy of the disk (track-copy)

Would be interesting to see what happens if we run this baby through the classic99 debugger. If we see where it goes wrong it could be patched.

 

Perhaps it's also possible to work with a memory dump from the program.

 

Could imagine doing the following:

1) Write a small assembly language program that runs from the cartridge space >6000 and that dumps memory to disk

2) Setup the load interrupt vector to point to (1)

3) Start Turbo Pascal'99 from the original disk

4) Press the load-interrupt switch to trigger (1), it will dump all memory to disk.

5) Add a header to the memory dump files to make it runable as #EA5

 

The question is if they also reset (2) when Turbo Pascal'99 starts.

 

It's too bad they didn't deliver updates on Turbo Pascal'99 because it was a nice integrated environment.

As it stands, it is lacking many features though.

Edited by retroclouds
Link to comment
Share on other sites

Yeah, so far that seems to be the bigger issue; Getting copy protected disk/images to work under emulators.

 

I'm using an Option Board to make my images (for a crude form of permanent archival). The kicker is.. the image format is proprietary to the Option Board (Central Point) and I haven't even begun to study its makeup. I've just started to get back into my TI system so I'm re-learning everything I've forgotten from 20 some years ago.

 

For non-protected disks I just simply use TI99-PC, works great and is quick. Finding a system that it'll work on is the tricky part but, I have that now.

 

I second your idea for dumping memory and use a loader for a EA5 file. I just don't know how. LOL But I'm willing to learn and experiment. I'm going to rip apart a 4a and install a load interrupt switch so I can start doing a little more hacking. I'm trying to also learn assembly so this will be a good experiment.

 

I don't know if my image process will help in this particular situation but, if anyone needs images made from real floppies (or visa-versa) I've got the setup.

 

Cheers!

 

-D

 

"Long Live the TI-99/4a!"

Link to comment
Share on other sites

Would be interesting to see what happens if we run this baby through the classic99 debugger. If we see where it goes wrong it could be patched.

 

I already did that a few months ago:

http://www.atariage.com/forums/topic/194675-turbopascal99-questions/?do=findComment&comment=2477581

http://www.atariage.com/forums/topic/194675-turbopascal99-questions/?do=findComment&comment=2477957

Link to comment
Share on other sites

 

That's cool what you did! Have to take a close look at that.

 

Another idea that just caught me, is that if a "save state" of a working and non-working version could be compared it would drop any clues.

Guess that the save state should be captured on a real TI-99/4A. Shouldn't forget about VDP memory either. Wonder if they have something in there.

If I'm not mistaking Barry Boone had worked on the copy protection or had the assembly source code at the time, I vagely recall him mentioning it in a yahoo thread a long time ago.

 

Don't think I've seen him on atariage before, otherwise he could share some words of wisdom on this topic ;)

 

Would you mind sending/sharing the (non-working) disk image? I have the disk but failed to create an image. Would be greatly appreciated. Thx.

Edited by retroclouds
Link to comment
Share on other sites

  • 3 weeks later...
I should perhaps add that my RAM-disk driver supports only the subprogram to read and write sectors on the disk. That works fine, so that prooves that nothing else is needed by the disk system to support the p-system. Just ship data to and from the normal sector buffer in the machine.The p-system accesses disks in chunks of blocks, which are 512 bytes long, but the BIOS part in the PME translates that to two 256 byte sector accesses, so that's nothing the disk memory system needs to account for.Formatting I do separately, using an assembly program I linked into my own dformat.code.

 

Out of curiosity, how does one get or update the dformat.code to format double-sided correctly? Or manually do it for that matter? I'd like to take advantage of DSDD since I have that capability.

 

TIA,

 

-D

 

"Long Live the TI-99/4a!"

Edited by CantStopClicking
Link to comment
Share on other sites

  • 4 weeks later...

Howdy, All!

Many thanks to the folks who worked on getting Turbo-Pasc'99 in shape. I downloaded the files from

the resources here, and then proceeded to try out TP99 with emulator / simulators environments. As mentioned

before, it doesn't operate with Ti994w. However, it performs like a champ with Classic99 and Win994a.

 

I did something stooooopid and accidently trashed my Win994a simulator environment. But since I am a "backup"

fanatic, I just whipped out all my CDs and restored every file, etc. That gave me an opportunity to redo the file

layout and how I use Win994a. That simulator has a hard drive simulation, as well. I installed every Turbo-Pasc'99

file on HDK2, and everthing seems to work fairly well. I placed all my work with TurboForth on HDK1, and TMS-9900

assembly language files on HDK3. Any TI-Forth, or anything else, is still on the simulated "floppies".

 

I must admit, it seems like a "throw back" to actually look at old pascal stuff again. I feel "spoiled" by doing things

now in TurboForth. I am actually preferring TF to any other........

 

It looks like the WiPoSoFt folks put together a pretty basic system to support some, but not all, of the V9918 capabilities.

In version 2.0, they delivered Text-1 and Graphics-1 modes, and no delivered support for bitmap or multicolor modes.

I don't see sound, sprites and a few other things (pointers, etc). It does support arrays and a whole host of basic

routines..... If we can do some in-line code within a procedure, we should be able to make up all the rest of it. But it

does seem a little hard to do with only about 14K left. At least they provided a couple of peek and poke routines. That

would be a start......

 

Good job on reviving some software from 1986.......!

 

 

ROD VAN ORDEN

San Diego, California

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

The p-code card has 12 K ROM. It's all in the DSR space, of course, but the last 4 K is switchable. Depending upon CRU bit 1F80H you get either the start image, or you get the secondary image, where the content at addresses 5000H to 5FFFH has changed.

This ROM contains startup code and various I/O support (BIOS for the p-system).

Then there are eight GROMs, for a total of 48 K GROM, since they are all 6 K each. These GROM contain 9900 code, which is copied to RAM on startup. The p-system installs quite a bit of assembly code in the 8 K part of expansion RAM. It also installs some in RAM PAD (the inner p-code interpreter runs there). Then the main part of the GROMs contain the volume which makes up OS: (#14:) in the p-system. Here we have some support files and the main SYSTEM.PASCAL file, which contains the major part of the p-system. Thus if you look at this part of the GROMs, you'll find data which makes no sense, unless you interpret it as the p-system's normal disk directory, and then inside the files you'll find code organized according to how code files are laid out in the p-system. It's a rather elaborate scheme, so you need to read the Internal Architecture Guide for the p-system to understand them.

But there's really no point. The main things to know, or at least those I can think of right now, to emulate the p-system are these:

  1. It has CRU base address 1F00H. Once it's enabled, it will never return to the caller. That's how the p-system takes over and runs instead of the normal operating system in the machine.
     
  2. The p-system runs code at 4000H-5FFFH.
     
  3. The range 5000H-5FFFH is bank-switched with CRU bit 1F80H.
     
  4. The GROMWA, GROMRA and GROMRD addresses are fully decoded, so they only occupy their specific words in the address range. The addresses are listed in post #43 in this thread.
  5. The I/O routines in the p-code card sometimes branches to code loaded in the 8 K RAM expansion memory. In order to access for example the disk controller, the p-code card has to switch itself off, and thus must be able to run code elsewhere during these operations.

Edited by apersson850
Link to comment
Share on other sites

  • 1 year later...

Odd when I look for Pcode GROM in Classic99 there is none?

Unfortunately, the classic99's maintainer took them off the distribution file. He didn't liked the Classic99 source file being used to redistributed the ROMs (as he states on the .txt file on the src/roms directory). Sad. :-(

 

The current version is 274. If I understood correctly, V273 and previous still had the rom files. At least an old package I found here (v365) had them.

 

On the bright side, it appears that I already had the PCode GROMs (, and since I downloaded the 365's package at that time, I think I'm still entitled to had them.

 

However, since the current version don't had it anymore, and since the maintainer doesn't provides old versions, I'm unsure if I can send them to you. The maintainer got a formal authorization to redistribute that ROM binaries, and I'm guessing that is the reason he took them off the source package : to protect that authorization.

 

Well, reverse engineering is protected by law and if you have an UCSD Pascal Card, you're entitled to have a backup copy from it's ROM for personal uses - so you can extract the binary from the executable. It's awkward, but it's easy to do it once you know how. And probably easier than extracting from the GROMs.

Link to comment
Share on other sites

Wait the GROMs for a 30 year old card are still being protected as special code?

 

You have to be kidding right? How much money would they lose vs the cost of a suit?

 

Better yet, how much money could one of us lose in defending or settling a copyright violation lawsuit.

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