Vorticon

I would say save it for now as we're not out of the woods yet. Hopefully in a few months you can spend it all and do your part in reviving the economy

I don't actually own the original package. I just used the disk images in the pinned Development Resources thread on this forum...

It's definitely usable, but without pointers, linked lists etc..., certainly crippled. I think the problem with the compiler is a bad disk image. If you happen to still have the disks, would you mind posting them? As for UCSD Pascal, it's Achilles heel was the very high cost of entry (3 disk drives, 32K, pcode card), so yes using an emulator is definitely the cheaper option I should mention that it is also fully implemented in Classic 99 as well.

dhe, would it be possible for you to post the program listings without line numbers and use the code functionality of the forum (</> icon in the message bar)? As they are, it is difficult to copy and paste the programs without significant editing...

Turbo Pasc 99 is an incomplete implementation of Pascal, and is missing pointers among other things. Also I don't think we ever got the compiler to fully work. Anders Persson translated the docs from German (not an issue for you though!), and I'll have dig them out to see if there is access to assembly subroutines with it. UCSD Pascal is a far better implementation, but the environment is clunky. Anders is the resident guru on it and has done some amazing extensions to it.

I agree. It's just not the easiest of environments to work with, although UCSD Pascal comes close Here are my Turbo Pascal projects, all done on the Coleco Adam computer under CP/M. The ADAM computer uses the same 9918 VDP chip as the TI incidentally.

So I've been playing with this Fortran package for a couple of weeks. Impression? It's definitely a clunky language with very limited file I/O and no support for string functions, but with superior math functions and numerical representations. It has its limited uses, but it's certainly not a good general purpose language, although the addition of the TI specific graphic extensions helped getting it closer in that direction. As TheBF mentioned, it likely does not optimize code very well, so performance has much to be improved upon. Of course the latest version of Fortran (Fortran 2018) has since brought the language pretty much on par with modern languages with all the associated facilities such as OOP for example. Nonetheless, it's still an impressive achievement given the limitations of the TI, and had it come out earlier in the prime of the TI market window (early 80's), it would have been a runaway hit particularly among the engineering types. So what to do with it? I'd really like to come up with a project using it as a personal challenge and I have a couple of ideas. Developing in Fortran 99 is rather painful for complex programs, so that will be interesting, but since I've put in the effort to learn it, I should at least have something to show for it I have a simple rule: if I learn a new language, I should create at least one meaningful program using it. This has been true for TI BASIC, XB, TurboForth, C99, Turbo Pascal, TMS9900 assembly, Intel 8080 assembly, and Python, so I'm going to try not to break with that tradition!

Indeed! Rewriting the Fortran program to avoid scrolling, it took it 2.63 seconds to complete the loop. It would have been even faster without the CALL CLEAR at the beginning. It took TI BASIC 13.18 seconds for something similar, so about 5x slower. PROGRAM LOOP CALL CLEAR DO 10 I = 1, 100 10 WRITE(6, 20) I 20 FORMAT('+', I3) STOP END Now taking the CALL CLEAR and PRINT out of the programs, TI BASIC clocked at 0.93 seconds! I couldn't time the Fortran equivalent as it was way too fast for my reflexes. The lesson? Don't print anything to screen unless you absolutely have to

Support requests reflect the huge (Trumpism right there ) level of interest and use of Classic 99. I think it's one of the best forms of flattery!

Very interesting idea. The problem is that the events and order execution are not sequential but are all occurring simultaneously, not to mention that they are inter-dependent meaning that an event/task might interfere with one or more other events/tasks. Dealing with this is definitely possible but likely very slow. One way I can think of is time-slicing. Set up a master counter, and with each increment check the status of each event or task. Assign a unique integer identifier to each possible event or task and create a 2 dimensional array consisting of (ID, ID) where each cell indicates whether an event has no effect on another event (0), a negative effect (-1) or a positive effect (1). Another single dimension array of ID will keep track of the status of each task/order. Adjust affected events accordingly, update the game, increment the master counter and so on and so forth... Obviously this is all very high level and coding it will be a bit hairy Would love to see how you progress.

I think concentrating on the F18A and the SAMS is wise since it already needs upgrade hardware anyway (the F18A) and the SAMS are now available new. Nice progress!

Yeah file I/O in Fortran 99 is not for the faint of heart I feel it would be better and much faster to do all file access from assembly except for the simplest of tasks...

Oh wow! Nice compilation! You really need to put out a complete PDF of all your Excel spreadsheets on the system.

I recently worked on a Heathkit H19 terminal with a bad keyboard decoder chip, and it scared the shit out of me as I had to work in very close proximity to the coils and power supply to get to the chip. I'm still vertical, so that's good, but I have a very healthy respect for the kind of voltages floating around in there. Incidentally, in case I have to get back inside the terminal again (shudder...), what' the best and safest way to discharge the capacitors? I hope it's not shorting them with a screwdriver!

OK I figured out how to properly restore the Fortran 99 environment after accessing files in bitmap mode with assembly subroutines. Apparently the CRT has to be reopened as FILE 6 using something called the File Open Processor routine located at >2070 and I have no clue as what that routine does exactly. I got this straight out from the CALL FILES subroutine by sheer trial and error. Here's the revised bitmap image display routine: DEF IMGSHW VMBW EQU >2048 DSRLNK EQU >2058 OPFILE EQU >2070 FILE OPEN PROCESSOR PABADR EQU >3A12 PAB ADDRESS IN VDP BASEAD BSS 2 SUBROUTINE RETURN POINTER RETADR BSS 2 SUBROUTINE RETURN POINTER IMGSHW DATA 0 NUMBER OF PASSED ARGUMENTS DATA BASEAD PABP DATA >0500,>0000,>0000,>1800,>000D TEXT 'DSK3.VIGER4_P' EVEN PABC DATA >0500,>2000,>0000,>1800,>000D TEXT 'DSK3.VIGER4_C' EVEN CRTPAB DATA >0003,>0000,>5000,>0000,>0003 TEXT 'CRT' EVEN * LOAD PATTERN FILE LI R0,PABADR LI R1,PABP LI R2,23 BLWP @VMBW LI R6,PABADR+9 MOV R6,@>8356 BLWP @DSRLNK DATA 8 * LOAD COLOR FILE LI R0,PABADR LI R1,PABC LI R2,23 BLWP @VMBW LI R6,PABADR+9 MOV R6,@>8356 BLWP @DSRLNK DATA 8 * RETURN TO MAIN PROGRAM LI R0,6 LI R1,CRTPAB BL @OPFILE MOV @BASEAD,R3 MOV @RETADR,R11 B *R11 END The 3 lines below the RETURN TO MAIN PROGRAM comment is where the magic occurs. Don't ask me why but would love to hear an explanation if somebody has one

Fortean 99 handles that automatically. All I have to do is reserve 4 bytes in BASEAD and RETADR. I should clarify that the subprogram returns normally to the main program and the main issue is when that main program terminates.

Conveniently, the CALL FILES routine is actually listed in the manual as an example of a machine language subroutine, but I'm not too clear on it. It appears that the PAB area is set at >1000, and the disk buffer is at >31B6 for a CALL FILES(1). Not sure how that would work since >1000 is smack in the PDT area in bitmap mode, and yet I have been able to do file I/O previously without issues within the Fortran environment. Furthermore, when setting up the PAB, it's loading >832C (which it calls pointer to file descriptor) with the PAB base - 7, i.e >0FF9 and I have no clue what that does. It also supplies DSRLNK with >000A instead of the usual >0008 for file I/O. And by the way there is no disk buffer corruption error with the debugger. The CALL FILES routine is listed on page 0A-12 of the attached Fortran manual for reference. 99-9640 FORTRAN Version 4 by LGMA Products.pdf

And here's the same bitmap image loaded using a simple assembly language subroutine with Fortran 99. The video speaks for itself The actual Fortran code is minimal: PROGRAM IMGSHOW CALL FILES(1) CALL SETMOD(4) CALL SCREEN(2, 1) CALL IMGSHW 10 CALL KEY(0, KEYC, ISTATUS) IF (ISTATUS .EQ. 0) GOTO 10 CALL SETMOD(1) CALL EXIT END Here's the short assembly routine. It takes advantage of the LOAD opcode in the file I/O to block load the image into the VDP. DEF IMGSHW VMBW EQU >2048 DSRLNK EQU >2058 PABADR EQU >1B02 PAB ADDRESS IN VDP BASEAD BSS 2 SUBROUTINE RETURN POINTER RETADR BSS 2 SUBROUTINE RETURN POINTER IMGSHW EQU $ DATA -0 NUMBER OF PASSED ARGUMENTS DATA BASEAD PABP DATA >0500,>0000,>0000,>1800,>000D TEXT 'DSK3.VIGER4_P' EVEN PABC DATA >0500,>2000,>0000,>1800,>000D TEXT 'DSK3.VIGER4_C' EVEN * LOAD PATTERN FILE LI R0,PABADR LI R1,PABP LI R2,23 BLWP @VMBW LI R6,PABADR+9 MOV R6,@>8356 BLWP @DSRLNK DATA 8 * LOAD COLOR FILE LI R0,PABADR LI R1,PABC LI R2,23 BLWP @VMBW LI R6,PABADR+9 MOV R6,@>8356 BLWP @DSRLNK DATA 8 * RETURN TO MAIN PROGRAM MOV @BASEAD,R3 MOV @RETADR,R11 B *R11 END The one issue is that the program locks up the computer upon exit. I don't think it likes me playing with file I/O outside of the Fortran environment...

Indeed... Is the game available as a DSK image as well? I'd like to add it to the TI Gameshelf site which needs an update anyway.

I thought TEX TURBO was strictly commercial. Did Marc release it into the public domain?

Yup... Now I'm going to try using assembly support with Fortran 99 to speed things up a bit. More to come

Yes that would work great. For the record, I really think no one should code in Basic or XB without using TIdBiT unless working on real iron exclusively.

I definitely use it any time I work on an XB program. I can always install php on my computer and use it that way as well.

On the main page of the TI Gameshelf is the following. I hope it clarifies things This whole .bin scheme was done because back in 2007 it was the only way I could reliably get a browser to download TI binary files as binaries and not try to display them... Things might have changed a bit since... 1- TIFILES format which is native to the TI 99/4A computer, which means that they will run directly on a real TI 99/4A machine as well as on the Classic 99 emulator. These files are appended with the .bin extension, and you will need to remove that extension prior to using the files. In addition, some of these files are archived, and those will have a filename ending with arc. You will need to use Barry Boone's Archiver to expand them.

So I found a way to read binary data, but it involved having Display Fixed records of length 1 byte, which is incredibly inefficient. Unfortunately, Fortran 99's file I/O is strictly ASCII based because it's primarily modeled after Fortran 66, so the only way I could get it to read a binary file was to break the file into 1 byte records, read each record as a character, and transfer it to an integer variable where it's ASCII value is stored then processed. There is unfortunately no block read or write facility. This makes binary file access dreadfully slow, as demonstrated in the video below where I load a bitmap image created with Tursi's Convert9918 utility program. The TIFILES header of the images was sector edited to convert the files to a DF 1 type under guidance from Tursi. Did I mention he was a very versatile and brilliant guy? On the upside, this whole exercise was a great way to practice file access and VDP RAM writing. Here's the disk image with all the needed files if you want to try it out. It should reside in DSK3. IMGSHOW.dsk And here's the program listing: PROGRAM IMGTEST INTEGER CT, PDT, ERR, DATABYTE CHARACTER IMGP(14), IMGC(14) DATA IMGP / 14HDSK3.VIGER4_P / DATA IMGC / 14HDSK3.VIGER4_C / CALL CLEAR CALL FILES(1) CALL SETMOD(4) CALL SCREEN(2, 16) PDT = 0 CT = 8192 CALL OPEN(1, IMGP, 2, 0, 0, 0, 1, ERR) IF (ERR .NE. 0) THEN PRINT , 'FILE ERROR!', ERR STOP ENDIF 10 FORMAT(A) DO 20 I = 1, 6144 READ(1, 10) DATABYTE CALL VMBW(PDT, DATABYTE, 1) PDT = PDT + 1 20 CONTINUE CALL CLOSE(1) CALL OPEN(1, IMGC, 2, 0, 0, 0, 1, ERR) IF (ERR .NE. 0) THEN PRINT , 'FILE ERROR!' STOP ENDIF DO 30 I = 1, 6144 READ(1, 10) DATABYTE CALL VMBW(CT, DATABYTE, 1) CT = CT + 1 30 CONTINUE CALL CLOSE(1) 40 CALL KEY(0, KEYC, ISTATUS) IF (ISTATUS .EQ. 0) GOTO 40 CALL EXIT END