+dhe Posted April 10, 2020 Share Posted April 10, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 25, 2020 Share Posted April 25, 2020 (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: 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 April 29, 2020 by wolhess Update TP99 / LK99 1 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 25, 2020 Share Posted April 25, 2020 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 25, 2020 Share Posted April 25, 2020 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 ) Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 25, 2020 Share Posted April 25, 2020 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) 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 25, 2020 Share Posted April 25, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 25, 2020 Share Posted April 25, 2020 (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 April 25, 2020 by mizapf Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 25, 2020 Share Posted April 25, 2020 Does version 2 support pointers? Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 25, 2020 Share Posted April 25, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 25, 2020 Share Posted April 25, 2020 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" Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 25, 2020 Share Posted April 25, 2020 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 TP99V2_COUNT.mp4 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 3 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 25, 2020 Share Posted April 25, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
+dhe Posted April 25, 2020 Author Share Posted April 25, 2020 (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 April 25, 2020 by dhe Quote Link to comment Share on other sites More sharing options...
+dhe Posted April 25, 2020 Author Share Posted April 25, 2020 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..... Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted April 26, 2020 Share Posted April 26, 2020 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 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 26, 2020 Share Posted April 26, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 26, 2020 Share Posted April 26, 2020 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. Quote Link to comment Share on other sites More sharing options...
+dhe Posted April 26, 2020 Author Share Posted April 26, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 26, 2020 Share Posted April 26, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 26, 2020 Share Posted April 26, 2020 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. Quote Link to comment Share on other sites More sharing options...
+dhe Posted April 26, 2020 Author Share Posted April 26, 2020 >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. Quote Link to comment Share on other sites More sharing options...
wolhess Posted April 26, 2020 Share Posted April 26, 2020 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!? Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 26, 2020 Share Posted April 26, 2020 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 26, 2020 Share Posted April 26, 2020 (edited) Wait ... need to check .. Edited April 26, 2020 by mizapf Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 26, 2020 Share Posted April 26, 2020 (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 April 26, 2020 by mizapf Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.