Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Vorticon

Members
 View Profile  See their activity

  • Content Count

    4,690

  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Vorticon

  1. Posted

    41 minutes ago, mizapf said:

    I managed to write some few TurboPasc'99 programs back in those days.

     

    If someone is interested in trying UCSD Pascal, remember that it is available in MAME, maybe just to get an idea (and for the sensation of having have saved several hundreds of DM/Dollars/FF/Pta/Lit (no Euro in that era)).

    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.

  2. Posted

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

  3. Posted

    59 minutes ago, wolhess said:

    There is a lot of work involved, for me it looks as if you have adapted Turbo Pascal to the Coleco Adam very well. Thank you for providing the videos.

    I find the possibility of supplementing Turbo Pascal with assembly routines very good. Would that also be possible on the TI Turbo Pascal?

     

     

    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.

    • Like 1

  4. Posted

    2 hours ago, wolhess said:

    that is very impressive! What kind of program did you develop in Turbo Pascal? With Turbo Pascal I wrote a few small programs on a Schneider CPC464 more than 30 years ago. On the TI-99, I want to look at that again.

     

    I am despite the mentioned drawbacks of the opinion that Fortran deserves a chance on the TI.

    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.

     

     

     

     

     

    • Like 1

  5. Posted

    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!

    • Like 2

  6. Posted

    13 hours ago, Asmusr said:

    In Extended Basic it takes about 10 secs.

     

    I believe programs that scroll the screen will spend most of their time in the scrolling routine, so it's not a good comparison of the actual languages.

     

    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 :)

    • Like 1

  7. Posted

    17 hours ago, Tursi said:

    Thank you, I wasn't calling for butt pats (always appreciated tho! ;) )... I'm just tired of fixing things for people all the time and never getting to do what I want to do. ;)

     

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

    • Like 2

  8. Posted

    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.

  11. Posted

    3 hours ago, Schmitzi said:

    Hi,

     

    many drives will work. See this list for more infos. (It is not complete, and no warranty of course) ;)

    Be sure NOT to use a twisted cable, it´s 1:1 (!)

     

    Legend for the last coloumn in the PDF:

     

    TI-99-4A-FLOPPY-DRIVES-PEB-short-1_10.JPG.84aec2422ccdef5e0291ca567a2b9bd4.JPG

     

    ("1 drive in PEB" is because 2 drives of this type would suck to much power)

     

     

    The list:

     

    TI-99-4A-FLOPPY-DRIVES-TI-99-v1.15-ALL.pdf 29.84 kB · 4 downloads

     

     

     

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

    • Like 2

  12. Posted

    On 7/21/2019 at 10:02 PM, matthew180 said:

    If you have never worked inside a TV or CRT monitor before, I want to stress that there are voltages in there that can kill you.

    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!

  13. Posted

    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 :lol:

    • Like 1
    • Thanks 1

  14. Posted

    2 hours ago, HOME AUTOMATION said:

    Looks like, you left out this reciprocal instruction...

      

    MOV  R11,@RETADR

    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.

  15. Posted

    7 hours ago, Tursi said:

    You can check in the Classic99 debugger what the CALL FILES(1) sets the top of VDP RAM to -- if it's lower than >3800 then the disk buffers are being corrupted by the image load. Normally 1 is enough, but maybe Fortran does things differently.

     

    Classic99 tries to complain about situations like the disk buffers being corrupted, so it may give you a clue if that's it.

     

    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

  16. Posted

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

    • Like 4

  20. Posted

    5 hours ago, matthew180 said:

    Would having a native Win/MAC/Unix executable be better for your workflow?  If I port it to C, this would be an option.

    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.

    • Like 2

  21. Posted

    3 hours ago, matthew180 said:

    I'm wondering if anyone is actively using TidBit on my website?  Due to the pandemic situation, I'm going to be shutting down my current server and moving to a smaller cheaper service, and I'm reluctant to keep the "online" TidBit page working.  The security risk has always made me uncomfortable too.  Anyway, since I don't run any stats on my website, I don't know how much that page actually gets used.

    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.

  22. Posted

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

     

    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.

    • Like 2

  23. Posted

    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

     

    • Like 4

  24. Posted

    Does anyone know how to read a binary file with Fortran 99? I keep getting a bad open attribute error any time I try to access a binary file despite using the internal option. Also the READ command assumes an ASCII input and there is nothing in the manual about this.

     

  25. Posted

    5 hours ago, dhe said:

    Compiler Complaint. Nope, Not a Warning, Not an Error.

    This was the first program that seemed to really want to use a scratch disk.

    I'm sure I've put something in the code the compiler, doesn't like, but it has me baffled.

    Can anyone else play spot the error?

     

     

      

    1                               Version 4.42                Page   0001                    
0      0001 C FI_S - FILE I/O SOURCE 04/02/2020
       0002 C2345678
       0003       CHARACTER NAME(8)
       0004
       0005       INTEGER FILEID(8),ERROR,GRADE
       0006       DATA FILEID / 10HDSK2.FI_D /
       0007       CALL OPEN ( 3, FILEID, 2, 0, 1, 0, 80, ERROR)
       0008
       0009     1 FORMAT ('+', C12, M1.1, 'GRADES:' )
       0010       WRITE (6,1)
       0011
       0012    10 FORMAT ( 8A1, 1X, I3)
       0013       READ (3, 10, END=99) NAME, GRADE
       0014
       0015    20 FORMAT ('+', M2.1, 8A1, 1X, I3)
       0016       WRITE (6,20) NAME, GRADE
       0017
       0018
       0019 C 3 - FILE NUMBER, NO EQ TO A FORTRAN UNIT NUMBER USED IN FORMAT
       0020 C 2 - INPUT MODE
       0021 C 0 - DISPLAY
       0022 C 1 - VARIABLE
       0023 C 0 - SEQ ACCESS
       0024 C 80 - MAX RECORD LENGTH
       0025 C ERROR - VARIABLE TO RETURN ERROR IN
       0026
       0027 C     SEE PAGE 07-11 - FILE I/O REF
       0028 C     SEE CALC1 FOR FILE I/O EXAMPLES
       0029
       0030 C  NAME = 8   HOL
       0031 C  SPACE = 1  HOL
       0032 C  GRADE = 3  INT
       0033
       0034
       0035    99 CALL CLOSE ( 3 )
       0036       STOP
 
1           Allocation          Version 4.42                Page   0002                    
0 Statement Labels:
 
    0001 0042         0010 006A         0020 0096         0099 00C6
0 Subprogram References:
 
         OPEN              CLOSE             STOP$             CALL$
0 Local Data Area:
 
  0004 i GRADE      0006 i ERROR      0008 k NAME       0010 i FILEID
0 Logic Size:   00D8
  Data Size:    0020
0 Module Size:  00F8
    0000  Warning(s)
    0000  Error(s)
1                               Version 4.42                Page   0001                    
0      0001       END
 
1           Allocation          Version 4.42                Page   0002                    
0 Subprogram References:
 
         STOP$
0 Logic Size:   002A
  Data Size:    0004
0 Module Size:  002E
    0000  Warning(s)
    0000  Error(s)
1                               Version 4.42                Page   0001                    
0      0001
    **Error-  Don't understand this statement
       0002
       0003
       0004
       0005
       0006
       0007
       0008
       0009
       0010
       0011
       0012
       0013
       0014
       0015
       0016
       0017
       0018
       0019
       0020
       0021
            >EOD
            >EOD
1           Allocation          Version 4.42                Page   0002                    
0 Subprogram References:
 
         STOP$
0 Logic Size:   002A
  Data Size:    0004
0 Module Size:  002E
    0000  Warning(s)
    0001  Error(s)

    You are trying to read Name using 8A1 in the FORMAT statement, and so the program is expecting 8 single character variables while you are only giving it 1 array. Try using A only and see if it works. 

    Unfortunately, string handling in Fortran 99 is practically non-existent...

     

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...