Pascal on the 99/4A

[4Andy]

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?

[apersson850]

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.

[apersson850]

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 April 18, 2012 by apersson850

[Rod Van Orden]

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?

[+retroclouds]

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.

[CantStopClicking]

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

[+retroclouds]

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 September 25, 2012 by retroclouds

[CantStopClicking]

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

[lucien2]

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

[+retroclouds]

I already did that a few months ago:

http://www.atariage....s/#entry2477581

http://www.atariage....s/#entry2477957

 

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 September 25, 2012 by retroclouds

[lucien2]

I took it from Vorticon's post here: http://www.atariage.com/forums/topic/153704-ti-994a-development-resources/page__st__75?do=findComment&comment=2470216

[+retroclouds]

I took it from Vorticon's post here: http://www.atariage....75#entry2470216

 

ok. Thanks for pointing that out

[CantStopClicking]

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 October 13, 2012 by CantStopClicking

[apersson850]

I just wrote my own dformat program. Since I have a CorComp controller, there are also some other tricks, like variable interlacing, that can be used with that controller. Pascal runs better with a different disk interlacing than what the 99/4A standard OS uses.

[CantStopClicking]

Oh, cool. Good job! I have no clue on where one would start to write the code for that, would you mind sharing what you've written? And what did you write it in?

 

Thanks again!

 

-D

[Rod Van Orden]

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

[Rod Van Orden]

RE: UCSD p-System

OK. I have two, 8K binary image ROM files, and one, 64K binary image GROM file.

Any thoughts on what I should do with them? (Keep it clean!)

[RXB]

Send me the GROM I can disassemble it to see what is going on in them.

[apersson850]

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 January 6, 2013 by apersson850

[RXB]

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

[Lisias]

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.

[RXB]

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?

Edited January 2, 2015 by RXB

[+OLD CS1]

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.

[RXB]

LOL how the hell would they even know?

 

I mean do they have paid spies to watch for the use of 30 year old software and the $200.00 they might have lost?

 

It just sounds so completely asinine.

[+OLD CS1]

You would be surprised.