Jump to content
dhe

tp99 Challenge

Recommended Posts

I really wanted to call this the tp2020 Challenge (as in finding toilet paper, but my wife advised me that it's still to early to joke about toilet paper).

 

So the challenge is the setup tp99 as found here in dev tools, write a program and share challenges, found and over came!

 

VorTICon write:

That's too bad. But then it's not really the best Pascal version to use anyway and UCSD Pascal already runs perfectly in MAME :)

Fortran 99 crammed so much in that package that it makes me wonder why WipoSoft was not able (or willing) to come up with a full Pascal implementation. No to mention that bone-headed memory protection scheme...

 

I think there was a version the Barry Boone broke, disassembled and make some minor tweaks.

 

I'll be trying in the next couple of days to get something working.

 

 

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

Hi,

Now I have made some tests with Turbo Pascal 99. Unfortunately I couldn't get the files from the development resources on atari age to work.

After some searching I found other image files and got them working on my real TI99 as well as in classic99.

 

Here are the working version:

 

Turbo-Pasc’99 v2 for the TI-99/4A Home Computer

The Disk Images contains the Turbo Pascal v2 version:
In classic99 map the image to DSK1.

 

TP99V2.dsk                        720 sectors DSSD 40 track image
TP99V2.dsk     new Version (04/29/20)

 

 

It contains the following files:

COMMANDS                     Helpfile how to use Turbo Pascal 99
TP99                               EA3 Loader for Turbo Pascal 99
LK99                               EA5 Linker Program
RUNLIB                           Turbo Pascal Library File must be in DSK1. for running linked programs
RUNLIBEQ                       Turbo Pascal EQU addresses must be in DSK1. for assembling a compiled file
                                    There are some short examples on this disk image too.

 

TPDEMO.dsk                  720 sectors DSSD 40 track image

TP99-DEMO.dsk     new Version (04/29/20)

 

 

The disk image contains a few simple demo programs
Map the DEMO program images to DSK3.

FAK-P                            Calculation of the factorial of n (Enter 0 to exit)
COUNT-P                       Counting from 1 to 32767
LISTER-P                       List a DIS/VAR file to device or to a file with line-numbers
                                    This is helpful if I have an error message e.g. Error 0 in line 25
MARGIN-P                     Add a left margin in any TI-Writer file for a better printout
SIEVE-P                        Sieve of Eratosthenes, size=8190, loops=10

 

A view screen shots about the demo examples:

 

image.png.76854a83918188793b7ba9c188cd35df.png   image.png.106f12ddec8434be85d3428afbfa52bb.png   image.png.0916d1917bdf40f1294d7fdde5f09adc.png 

 

image.png.03f352e6d4a225e1a2b339ec38292719.png   image.png.ccee79f13fce021de12cd2d79778cddb.png

    

If you run the linked program with LK99 and the program terminates without errors, you can press ENTER to load the E/A again. Then you can run your program with option 5 RUN PROGRAM FILE.
IF you choose a cold reset the program doesn’t run with E/A option 5 in classic99! It shows only a green screen!
You need to run the linker first, choose a warm reset and all is OK. That happens only in classic99.
On my real TI-99/4A I can have a cold restart and use the EA option 5 to run the program.
The only thing is I must have a disk with the RUNLIB file in my physical drive DSK1.

When working with TP99 in classic99 it can happen that a file cannot be saved or that the compiler stops. In these cases, it helps to quit and restart classic99.
 

I was able to edit and compile the DEMO programs on my PC in classic99 without any problems.
Classic99 only showed problems with longer programs (larger than 100 lines). So far, I was able to edit and compile programs with approx. 400 lines on my real TI99 without any problems.

 

Please use classic99 version 399.025.

 

If you want more, you can take a look at the expansion of Turbo Pascal with a window manager in Post # 52!

 

 

 

Edited by wolhess
Update TP99 / LK99
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Turbo Pascal has a copy protection, so the most versions I found on atari age or in the internet doesn't work!

 

For Turbo Pascal 99 to work on a real TI-99/4A, you need to make a sector copy of the TP99V2.dsk image.
A normal file copy from my tipi directory via DM2K to DSK1 did not work!

To copy the disk image to my TI99 I used the virtual disk manager VDM99.
 

http://www.unige.ch/medecine/nouspikel/ti99/vdm99.htm

 

I used the version with the HOOKRS1 for serial transfer via the first serial interface of the TI
The transfer of the HOOKRS1 file is quite tricky the first time, so I simply copied the file with DM2K from my
tipi directory to the DSK1 drive and started it with E/A option 5.

 

VDM99.zip

 

I'm sure there are other ways to make a sector copy of an image file on a real TI!
But for me it was a simple story.

Share this post


Link to post
Share on other sites
2 hours ago, wolhess said:

If you run the linked program with LK99 and the program terminates without errors, you can press ENTER to load the E/A again. Then you can run your program with option 5 RUN PROGRAM FILE.
IF you choose a cold reset the program doesn’t run with E/A option 5 in classic99! It shows only a green screen!
You need to run the linker first, choose a warm reset and all is OK. That happens only in classic99.

I would like more details on the Classic99 specific problems... which disk image, which program on that disk do I need to run that does not work from cold start, but does on hardware? (And, on your hardware, this is after you power off the 32k card as well as the console? That's the only difference between cold start and warm start in Classic99, whether RAM is erased ;) )

 

Share this post


Link to post
Share on other sites
35 minutes ago, Tursi said:

I would like more details on the Classic99 specific problems... which disk image

Hi Tursi, you are very fast!

 

I'm using the classic99 version 399.022.
DSK1. is mapped to the disk image TP99V2.dsk
DSK2. is mapped to the FIAD folder DSK. in the classic99 directory
DSK3. is mapped to the disk image TPDEMO1.dsk


The diskimage is in post #2: TP99V2.dsk; from this I need the program LK99 to start before I can run the demo programs from the disk image: TPDEMO1.dsk.

The programs are the files: COUNT1, FAK1, LISTER1, MARGIN1 and SIEVE1. You can run the programs as described after runing LK99 (you can press F9 after loading to get back to the EA) and a warm reset.

To run the programs after a cold reset, classic99 shows only a green screen.
On the real TI I see the green screen too, but also the drive DSK1. works (to access the RUNLIB file, I think) and then the programs are running.

In the manual for Turbo Pascal 2.0 it says that the program supports now the disk controllers from TI, Corcomp and Atronic, so I think it has to do with it.
Or maybe it's my PC configuration (a DELL Inspiron ONE2310 with Windows 10 updated from WIN7 with some problems) 

 

1868625350_TP9920_ControllerSupport.thumb.JPG.4e1cd7d6ab5e6103c067a7f6310f1743.JPG

 

In my real PEB I use a TI controller with the 80 track mod for DSK1=5,25" and DSK2=3,5". DSK3 is a SSSD 5,25" drive, but I use for TP99 a tipi mapping for DSK2 and DSK3.

 

 

Share this post


Link to post
Share on other sites
3 hours ago, wolhess said:

IF you choose a cold reset the program doesn’t run with E/A option 5 in classic99! It shows only a green screen!

 

You need to run the linker first, choose a warm reset and all is OK. That happens only in classic99.

I'm not sure, maybe this has to do with the fact that TP99 tries to find out whether the libraries are already loaded. This is at least what I found out in MAME and also back in the past where I used it on my real machine.

 

In MAME you'd have to use the external 32K memory expansion which shows the bytes in memory as FF00FF00FF00... on cold start. If the memory contains 0000...00, the libs are not loaded because it seems to check for FF00. Just a theory.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

Wolfgang, try this: In TI BASIC (with Editor/Assembler plugged in), type

 

CALL LOAD(12574,1)

 

and then try to run the compiled Pascal programs again. It seems as if TP99 programs check for the equality of the words at >2000 and >311E, and when entering Editor/Assembler, the word at >2000 is >0000. You have to write something different from 0 into the word at >311E.

Edited by mizapf

Share this post


Link to post
Share on other sites

Hi Michael,

 

yes, with the CALL LOAD(12574,1) and a warm reset of classic99 the programs are loading and working!

I think this is part of the copy protection the Turbo Pascal program is using or it checks if the EA cartridge is loaded.

 

I checked this on my real TI. I started the PEB and the TI with a real EA-Module plugged in from power down and select first TIBASIC.

Then I make a CALL PEEK(12574,A,B) and got A=60 and B=144.

 

I went back to classic99, made a cold reset with included the EA cartridge and then I selected first TIBASIC.

The CALL PEEK(12574,A,B) shows A=0 and B=0 too.

After the CALL LOAD(12574,1) and a warm reset the program loads and works fine.

  • Like 1

Share this post


Link to post
Share on other sites
9 minutes ago, Vorticon said:

Does version 2 support pointers?

Hi Walid,

 

I don't know. In the manual you sent to me is only one page about the version 2.0.

The only additional command was the GO XXXX command for the compiler.  And with this version Turbo Pascal
supports Disk Controller from ATRONIC, CORCOMP and TI. Thats all.

 

I told you about the Version 3.0, but for this version I didn't have any manual. It works identical to the version 2.0 (what I was tested until now).

With this version WoPoSoFt distributed a more complete manual for Turbo Pascal. I found two articels in a German magazine.

And I found the front cover of the manual but not the manual itself. The title is: "TURBO PASC'99" and  "Einführung in Turbo-Pasc'99"

 

TPV3_Manual_Cover.JPG.2d37e4057efe66589588cef119e1cc3b.JPG

  

Share this post


Link to post
Share on other sites

Hello everyone,

I would like to show a short video on how to use Turbo Pascal for the TI99.
I used classic99 and configured it as follows:
cartridge = Editor assembler
DSK1      = Disk Image TP99V2 from POST # 2
DSK2      = DISK2 directory from classic99
DSK3      = Disk Image TPDEMO1 from POST # 2

 

 

The process in the video is as follows:
- Load E/A in classic99
- Select EA3 LOAD AND RUN, FILE NAME: DSK1.TP99
  The Turbo Pascal Editor / Compiler is loading
- Use the command LO DSK3.COUNT-P
  The Pascal Source file COUNT is loading
- Use the command ED to edit the source file and change the
  number from 32767 to 2000
- Press F9 to exit the editor

- Use the command SA DSK2.TEST-P to save the changed source file to DSK2
- Use the command CO to test the source file
- Use the command CO DSK2.TEST-S to compile the program to DSK2
- Use the command Q! to exit to the TI title screen
- Load E/A again and select ASSEMBLER with
  the the source file: DSK2.TEST-S
  and the object file: DSK2-O
- Press ENTER for the E/A main menu
- Press 5 and RUN the left PROGRAM FILE: DSK1.LK99
   The Turbo Pascal Linker is loading
- Enter the Module name: DSK2.TEST-O and
  the Module library: DSK3.WI99 @ and two times ENTER
  answer the question Generate Program-File with "Y"
  and enter the program name DSK2.TEST1
- Answer the question RUN PROGRAM? with "Y"
  The program COUNT1 is running!

 

Now you can test the other DEMO programs in the disk image

  • Like 3

Share this post


Link to post
Share on other sites
3 hours ago, wolhess said:

yes, with the CALL LOAD(12574,1) and a warm reset of classic99 the programs are loading and working!

I think this is part of the copy protection the Turbo Pascal program is using or it checks if the EA cartridge is loaded.

Frankly, I don't understand what they were actually trying to achieve. If it was a copy protection, why did they make it depend on existing memory contents? The only effect it had was that people with a built-in SRAM expansion could not run their programs anymore. If they detected a copy attempt, I'd have expected something like "Kaboom! Another not so mighty hacker bytes the dust" (you know that one?) but not that they simply didn't load a support library and then let crash the program.

 

As it seems now, there is a compare of addresses >2000 and >311E. >2000 is zeroed when the Editor/Assembler cartridge has been selected. Then, only if address 311E contains something different than 0, they load RUNLIB. When it is loaded, there is something different at that location, but it is not 0. This means that every time you load a program, it will load RUNLIB again. If the memory was blank, they did not load it. I would have understood it if it checked whether RUNLIB was already loaded, and if so, don't load it again, but it does not work this way. Maybe this was intended to work as a "on-demand loader" for RUNLIB, but they messed it up. I could imagine that they falsely believed that clean memory meant 0000 (while it was FF00), then they tested their program, saw that it failed, and changed the compare instruction so that it worked ("ah, you need JEQ, not JNE"). Pure speculation, of course.

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

>I'm using the classic99 version 399.022.

Tursi did some fixes for me, so that on a disk image, I can now rename files and type them from dm2k, the current rev I have is .024 - the zip file on offer at Tursi's website has the latest build.

 

 

 

 

 

Edited by dhe

Share this post


Link to post
Share on other sites

it so stinks the source code to great programs like ti-base, fortran99, pasc99, preditor, 4a/dos aren't available. Have to give Beery a big ole' tip of the hat for saving mdos, that one was almost smoked.....

 

Share this post


Link to post
Share on other sites

The work flow for program development seems quite slow. On the other hand the execution speed is pretty good and certainly faster than UCSD Pascal. Choose your poison I guess :)

  • Like 2

Share this post


Link to post
Share on other sites
On 4/25/2020 at 1:06 AM, wolhess said:

When working with TP99 in classic99 it can happen that a file cannot be saved or that the compiler stops. In these cases, it helps to quit and restart classic99.

Are you sure you're on the latest? There was a bug with disk images that I fixed a couple weeks ago that caused handles to leak, which would eventually make file access just fail.

  • Like 1

Share this post


Link to post
Share on other sites

No, I think not. I used the version 399.022, I downloaded on April, 14.

 

Your web site shows the same version but dhe wrote in post #13 there is a new version 0024.

 

Right now I downloaded the current version 399.024 but the same is happening.

The short demos are running. But for larger programs Turbo pascal blocks in classic99.

 

I will make some more tests and post the used files with a  brief explanation.

Share this post


Link to post
Share on other sites

I might be able to help here!

When it locks up (the TI part) - check to see if the emulator menus are still running?

If they are - look for messages in the debugger (Edit > Debug)

Then also in the debugger Debug>Dump RAM.

 

  • Like 1

Share this post


Link to post
Share on other sites

Many thanks for your help,

 

I did some tests on real TI and on classic99:

 

The task is to load a pascal source file and compile it to an assembler source file.
If this is OK, assemble the assembler source file to an object file and link the object file to a program image file.

 

On the real TI99 system the process is done every time without errors or blocks.
 

The problem is:

On classic 99 sometimes the Turbo Pascal compiler stops compiling and classic99 is blocked.

To work with small pascal source files, it seems that the compiling process is fine.
With larger source files (about 300 lines) the compiling process mostly stops.

 

During the tests I detect a problem, when the pascal source file has blank lines after the end of the source code.

The real TI can load this file and works with it. Classic99 stops the loading and hangs.

 

 

I used the classic99 version 399.024

Cartridge  = Editor / Assembler
DSK1       = Disk image TP99V2.dsk

TP99V2.dsk
DSK2       = FIAD directory DSK2 in the classic 99 path
                  here I stored the testfiles (the results)

DSK2.zip
DSK3       = FIAD directory DSK3 in the classic 99 path
                  here I provided the sourcefiles

DSK3.zip

 

In the following PDF file I documented what I did

Turbo Pascal 99 Test protocol.pdf

 

As dhe advised, I used the debugger after the blockade and created a RAM dump:

The dump is from the last Test E.2

VDPDUMP.BIN

MEMDUMP.BIN

 

Test overview:

 

Test

HW/SW

Program

Try #1

Try #2

Try #3

Try #4

Try #5

Try #6

A

Real TI99

COUNT
WI99DE-P
WI99ME-P

OK
OK
OK

OK
OK
OK

OK
OK
OK

OK
OK
OK

 

 

B

Classic99

WI99DE-P

Faulty

OK

Faulty

 

 

 

C

Classic99

COUNT-P

3 x OK
1 x Faulty

10 x OK
1 x Faulty

 

 

 

 

D

Classic99

WI99ME-P

Load problem

Load problem

Faulty

Faulty

OK

Faulty

E

Classic99

WI99ME-P

OK

Faulty
RAM DUMP

 

 

 

 

 

 

Maybe you see what is going wrong during the compile and save file to the disk.

 

  • Like 1

Share this post


Link to post
Share on other sites
15 hours ago, Vorticon said:

The work flow for program development seems quite slow. On the other hand the execution speed is pretty good and certainly faster than UCSD Pascal. Choose your poison I guess :)

However, the workflow is simple and if I have an error in the source code, the compiler shows me the error code and it place the cursor in the edit window at the location where the error occurs.
I find it very convenient.
 

And I can check the source code before I compile it to a file with the command "CO" without a file name.

This in turn saves time.

 

 

Share this post


Link to post
Share on other sites

>During the tests I detect a problem, when the pascal source file has blank lines after the end of the source code.

I have a similar problem in FORTRAN99, sometimes, when I load the source file, DV80 - I get a few extra lines between the end of the code, and the end of file marker - that the fortran editors puts in. I have grown accustomed to making sure after the end statement I get Fortran's end of file marker...

I really need to setup a console with tipi, so I can easily try the stuff on a "real" TI, I don't like to cry wolf.

Share this post


Link to post
Share on other sites

Yes, I also found that in Fortran. Since then I have always checked the end of the file in the editor.
Now I'm going to check that in Turbopascal too.

 

But on the real TI it isn't a problem for the TP editor/compiler.

 

And yes with a tipi the TI-life is much easier!🙂

If you have a tipi, then please setup a system with it and we can have a tipichat!😉

Share this post


Link to post
Share on other sites

Hi Wolfgang,

 

I tried it in MAME, and I had an interesting finding. Lots of your TIFILES files on DSK3 are not readable in my TIImageTool (after importing on a disk image), which indicates there is some issue in the file header. I could not read WI99DE-P in TP99, but also not in Editor/Assembler; both editors continued to load sectors until the memory was full. This file could be opened in TIMT, though; I copied the contents into a new file on the disk image, and then it could be read. The difference was 1 in the EOF marker; that is, it seems as if the end-of-file marker was lost (is there, but the file length was one too small).

 

After that, I was able to compile the WI99DE-P file in TP99.

 

I cannot read COUNT-P either; still have to check why. My TIMT says the file is shorter than expected.

Share this post


Link to post
Share on other sites
Posted (edited)

OK, found it. I noted it in Ninerpedia: https://www.ninerpedia.org/wiki/File_systems#File_Descriptor_Records

 

Level-3 record count: In the case of variable length records, it contains the highest sector actually written to and should therefore be equal to the field "Total number of sectors". This can be validated with real-iron-written disks. (Also see e.g. the HFDC manual or Thierry's site: http://www.unige.ch/medecine/nouspikel/ti99/disks.htm)

 

So this is not correct in your FIAD files. Check this:

 

00000000: 0754 4946 494c 4553 0001 8003 0050 0e00  .TIFILES.....P..
00000010: ca53 ca53 ca53 ca53 ca53 ca53 ca53 ca53  .S.S.S.S.S.S.S.S
00000020: ca53 ca53 ca53 ca53 ca53 ca53 ca53 ca53  .S.S.S.S.S.S.S.S
00000030: ca53 ca53 ca53 ca53 ca53 ca53 ca53 ca53  .S.S.S.S.S.S.S.S
00000040: ca53 ca53 ca53 ca53 ca53 ca53 ca53 ca53  .S.S.S.S.S.S.S.S
00000050: ca53 ca53 ca53 ca53 ca53 ca53 ca53 ca53  .S.S.S.S.S.S.S.S
00000060: ca53 ca53 ca53 ca53 ca53 ca53 ca53 ca53  .S.S.S.S.S.S.S.S
00000070: ca53 ca53 ca53 ca53 ca53 ca53 ca53 ca53  .S.S.S.S.S.S.S.S
00000080: 0e50 524f 4752 414d 2043 4f55 4e54 3b01  .PROGRAM COUNT;.
00000090: 200e 5641 5220 693a 494e 5445 4745 523b   .VAR i:INTEGER;
000000a0: 0120 0542 4547 494e 0820 6920 3a3d 2030  . .BEGIN. i := 0
000000b0: 3b0d 2043 5552 534f 5228 322c 3229 3b24  ;. CURSOR(2,2);$
000000c0: 2057 5249 5445 2028 2243 6f75 6e74 696e   WRITE ("Countin
000000d0: 6720 6672 6f6d 2031 2074 6f20 3332 3736  g from 1 to 3276
000000e0: 3722 293b 0820 2052 4550 4541 540c 2020  7");.  REPEAT.  
000000f0: 2069 203a 3d20 692b 313b 1120 2020 6375   i := i+1;.   cu
00000100: 7273 6f72 2831 302c 3130 293b 0f20 2020  rsor(10,10);.   
00000110: 7772 6974 6520 2869 3a35 293b 1220 2055  write (i:5);.  U
00000120: 4e54 494c 2069 203d 2033 3237 3637 3b04  NTIL i = 32767;.
00000130: 454e 442e ff00 0000 0000 0000 0000 0000  END.............
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................

 

In the header (first line), the number of L3 records is given as 0e00 (14, little endian). This should be 0100.

 

This value may be ignored by the DSRs (hence they say "should be"), but I used it in TIImageTool, and thus I get this error message. It need not cause an issue with your compilation. I don't know how this file was created, but I think this should be fixed by the author of the converter.

 

[Edit: I just added this to the disk check feature in TIImageTool, will fix the L3 count if desired.]

 

Edited by mizapf

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