Question about PABs in assembly.

[Question about PABs in assembly.]

Some DSRs already allow the use of CPU RAM buffers. But you can only use that feature in your own assembly programs, since no "normal" programs would expect data to end up in CPU RAM directly.

 

Yes, the UCSD p-system has an entirely own file handling structure. The directories are completely different, compared to the TI's normal files. The p-system uses only the sector read/write subprogram, to access the data its own file handling system needs.

 

If you need to read a normal file, sector by sector, but don't want to use the normal file based I/O, then you have to read the disk catalog (by reading the sectors it's in), find the file name, read the file catalog sector, find out where the file is stored and then read that file from these sectors. I've done that, when I wanted to read a DIS/VAR 80 text file on a disk with "normal" files from within the p-system, to convert these DIS/VAR 80 files to the p-system's text files.

 

The p-system, already on the normal Pascal language level, supports three different abstraction levels of disk access:

1. Reading files with a defined content, where a stored real becomes a real value in a real variable etc. Commands like put, get, seek, read and write are used.
2. Reading files block by block (the p-system uses 512 byte blocks, i.e. two sectors at a time), disregarding the content of the file. Blockread and blockwrite are used for this.
3. Reading disks block by block, disregarding the file structure on the disk. Unitread and unitwrite gives access to this functionality.

 

I've done a  program, in Pascal, which reads MS-DOS disks too. It works fine with the old 360 kbyte disks, as they can be read with my drives I use with the CorComp controller. I don't have the hardware to read the 1.2 Megabyte disks in the TI.

 

The normal operating system has these capabilities too, but you can't just like that access them from BASIC. But among the "hidden" subprograms on the disk controller are not only the physical sector read/write program, but also support for formatting a disk and accessing files by sector, not by content. This is used by disk manager software to copy files, for example. Then the content isn't interesting in itself.

[Question about PABs in assembly.]

There is a disc sector read/write subprogram in the disk controller card. That's in all of them. That's what the file system uses on its lowest level, since it reads a sector at a time, then converts these sectors to records.

[USES UCSD Pascal]

As I wrote above, if you have SYSTEM.LIBRARY on the root volume (#4:), then everything is automatic.

 

Here's a piece of code from one of my programs, a program which uses several units defined for this program only. It also uses one system unit, crt.

You can see that the uses-clause is given file location information to tell it in which file to look for the appropriate unit. These units are not consolidated into any SYSTEM.LIBRARY file.

This particular code section is actually from Turbo Pascal 4.0, but the same code runs under the UCSD p-system on the 99/4A as well.

 

In this example, the units contain global data definitions and then different sections of the program, like data entry, data display, data disk storage etc.

 

I included the complete main program, since it shows how you can create a fairly complex program, but still keep the main program small and easy to overview. The main program here only handles the main user's menu system and some minor housekeeping. By then doing the real work in the different units, I could work on one of them without caring about all other stuff in the program. This was especially important when working with the TI 99/4A, since the whole program is 4000 lines long. It doesn't fit in the editor and compiling everything takes a loooooong time, to say the least. That wasn't much of an issue with Turbo Pascal, but the same convenience of working with one piece at a time ruled.

program dust_buster;
 (* Dust evacuation dimensioning software system.
    Idea: Sven Lundgren, Process Ventilation.
    Program: Anders Persson. *)

 (* A-DATA 880705 *)

uses
   crt,
   (*$U dustglob *) dustglobal,
   (*$U dustent  *) dust_entry,
   (*$U dustshow *) dust_show,
   (*$U dustio *)   dust_io,
   (*$U dustchng *) dust_change,
   (*$U dustprin *) dust_print,
   (*$U dustback *) dust_back;

var
   i,
   choice: integer;
   stop: boolean;
   hmr: ^integer;

function menu: integer;
 (* Displays the main menu *)

var
   choice: integer;

begin (* menu *)
   clrscr;
   gotoxy(20,1);
   write('DAMMUTSUG  v4.2');
   gotoxy(20,2);
   write('===============');
   gotoxy(1,5);
   write('1 - Inmatning');
   gotoxy(1,7);
   write('2 - Visa data');
   gotoxy(1,9);
   write('3 - Žndra data');
   gotoxy(1,11);
   write('4 - Spara data p† skiva');
   gotoxy(1,13);
   write('5 - H„mta data fr†n skiva');
   gotoxy(1,15);
   write('6 - Utskrift av resultat');
   gotoxy(1,17);
   write('7 - Utskrift av material†tg†ng');
   gotoxy(1,19);
   write('8 - Avsluta');
   gotoxy(5,23);
   write('Process Ventilation   A-DATA 88');

   repeat
      choice := ord(readkey);
      if choice<>15 then
         choice := choice-48;
   until choice in [1..8,15];
   menu := choice;
end; (* menu *)


function ok_to_kill
 (* Checks if the current system is stored, and, if not, allows storage
    before continuing. *)
   (var stored: boolean;
    var plant: plant_type;
    var filename: string): boolean;


   function menu: integer;
    (* Shows the save or abandon option menu *)

   var
      choice: integer;

   begin (* menu *)
      clrscr;
      writeln('Det nuvarande systemet „r inte lagrat!');
      gotoxy(1,4);
      write('1 - Spara data p† skiva');
      gotoxy(1,6);
      write('2 - Forts„tt utan att spara');
      gotoxy(1,8);
      write('3 - Avbryt valt alternativ');
      write(bell);

      repeat
         choice := ord(readkey)-48;
      until choice in [1..3];
      menu := choice;
   end; (* menu *)

begin (* ok to kill *)
   if not stored then
      case menu of
         1: begin
               save_data(plant,filename);
               stored := true;
               ok_to_kill := true;
            end;
         2: ok_to_kill := true;
         3: ok_to_kill := false;
      end; (* case *)
end; (* ok to kill *)


begin (* dustbuster *)
   if data_files_ok then
   begin
      mark(hmr);       (* To allow swift release of heap space before a new
                          system is entered. *)
      stop := false;
      repeat
         choice := menu;
         case choice of
            1: if ok_to_kill(stored,plant,filename) then
               begin
                  release(hmr);
                  mark(hmr);
                  new_data(plant,stand_dim);
                  filename := filedefault;
                  calculate(plant,stand_dim);
                  (* If plant.next=nil at this point, there can't be any
                     system to preserve. Otherwise, prevent accidental
                     erasure. *)
                  stored := plant.next=nil;
               end;
            2: show_data(plant);
            3: if ok_to_kill(stored,plant,filename) then
               begin
                  change_data(plant,stand_dim);
                  calculate(plant,stand_dim);
                  stored := false;
               end;
            4: begin
                  save_data(plant,filename);
                  stored := true;
               end;
            5: if ok_to_kill(stored,plant,filename) then
               begin
                  release(hmr);
                  mark(hmr);
                  plant.next := nil;   (* Just in case nothing can be read *)
                  fetch_data(plant,filename);
                  stored := true;
               end;
            6: print_data(page_height,plant,prdevice,filename);
            7: cost_report(page_height,plant,stand_dim,cost_info,prdevice,filename);
            8: if ok_to_kill(stored,plant,filename) then
               begin
                  stop := true;
                  release(hmr);
                  clrscr;
               end;
           15: secret_service(show_change,page_height,prdevice,stand_dim);
         end; (* case *)
      until stop;
   end; (* if *)
end. (* dustbuster *)

 

[USES UCSD Pascal]

One thing I didn't mention in the post Rossman links to above, was the mapping of the libraries.

Separately compiled units, whether you made them yourself or they were provided by TI, have to be accessible at two different occasions.

The first occassion is when you compile the program using the units. The second occasion is when you run the program that uses the units.

 

The p-system can always find and access units, both at compile and run time, that are stored in the *SYSTEM.LIBRARY file. Note that the asterisk at the beginning of the file name is the shorthand root volume (#4:) prefix. The SYSTEM.LIBRARY file provided with the system when you get it contains the system extensions that TI developed to provide access to TI 99/4A specific things, like sprites and sound.

 

When you create your own units, you have two options. Either you include them in SYSTEM.LIBRARY or you keep them in a separate file. To include them in the system's library file makes sense if they are of general interest. A general input utility is a typical candidate for this. But if you develop a unit that's meaningful in one program only, where the reason for making it a unit could be that the program is too large to be edited as a single unit, and you can break out a section that has a specific and (preferably) separate task in your program (like printing a result), then it makes sense to place this unit in a file by itself. I've developed some program for my 99/4A, where one main program relied on the use of half a dozen units. These units were all specific for this program, so I included them in a separate library.

The supplied utility program LIBRARY.CODE is used to open a library file as well as add or remove single units from that library.

 

If you then compile a program, which references the system unit support, as well as your own unit printfix, and that unit is stored in the file printutil.code, then you need to write your program like this.

program unittest;

uses
  support,
  (*U mydisk:printutil.code *) printfix;

begin
  (* bla bla bla *)
end.

That's sufficient for compiling your program. The compiler will now know where to find the interface section of the unit.

When it's time to run the program, you need to tell the runtime system where to find the implementation section of the unit. When it's in a file outside the SYSTEM.LIBRARY, like in the example above, you have to create a file which tells the system where to look. This is the USERLIB.TEXT file. That file simply contains the line MYDISK.PRINTUTIL.CODE to tell the system where to look.

You can use an execution option to set the name for the library index file. Press X L=mydisk:unitfile.text to tell the system that you have your own unit index file on your work disk.

Such a unit index file can contain multiple lines, telling the system to scan through all of them, to located the proper units, if your program references many different units, spread over different files. Or you can use the LIBRARY.CODE program to consolidate all your units into different slots in your own library file, in which case your unit index file only need to point to that library.

[Help with running floppies.]

When I first acquired the p-code card, and tried to figure out an entirely new operating system on my TI 99/4A, I scratched my head quite a lot too...

[Just bought a TI with an internal 32k mod]

As far as I can see from the picture we do have here, this is a 32 K RAM addition, and that's it. Some who added 32 K did put in 64 K RAM, but only used half of it. Made it easier to handle the gap in the address range, where the 8 K and 24 K RAM banks aren't adjacent.

I did add 64 K RAM too, but more glue logic to make all of it useful.

[Any modern TMS9995 projects lately?]

The TMS 9995 also has internal 16-bit memory high up in the memory map. The TMS 9900 doesn't. In the TI 99/4A, this area is used for memory expansion. In a computer based on the 9995, the equivalence of the RAM PAD at 8300H would have been located in this internal memory.

[Better cpu]

The way I added 16-bit wide RAM to the machine not only speeds up memory access to the normal memory expansion. It also adds another 32 K RAM, which can be paged in, in 8 K chunks, across the rest of the address space as well. In addition, the fast 32 K RAM expansion can be paged out, to still allow access to the normal memory expansion in the box.

So this modification increased CPU-addressable RAM from 32 to 96 K. Today, when we large RAM-disks, and interfaces to SD-cards with Gigabytes of storage, this is nothing. But when I invented the design back in the mid 1980's, it was quite a large memory for a home computer. The first IBM PC could be bought with 16 K RAM in 1981...

 

As an example, I could page in RAM to get a contiguous RAM file in addresses 0000H-7FFFH. That means monitor ROM, DSR and command module ROM is paged out, but frequently you can do some meaningful actions without them. With this setup, you have access to a 16 K words array, which can be directly addressed by the CPU, to use for internal sorting or whatever. Then just page the RAM out again, and any normal activity in the computer can't touch your array.

[Better cpu]

Simply by installing 16-bit wide RAM inside the console, the speed of assembly programs where both the workspace and code is in expansion RAM is increased by about 110%.

Thus you don't have to consider where to put your workspace in RAM PAD to avoid disrupting something in the system, but still get full speed.

The difference when running programs in TI Extended BASIC is much smaller, but can still be noticed. Forth runs a bit faster, but just like the p-system (Pascal), it already has the workspace and the inner interpreter in fast RAM, so the difference isn't astonishing.

[Weird IF-THEN-ELSE issue]

Yes, it looks like if the interpreter has "no code to go to" after the GOSUB, it will in error go to the code after the ELSE, instead of the code after the whole IF statement, which is where it should be heading.

[Assembly on the 99/4A]

On 1/23/2020 at 2:44 PM, Airshack said:

   Anyway, it’s working now. I have a bridge key on my game map! 

 

   MOV    @MAPDAT, R6     * pointer to beginning of map

   LI        R7,>D900          * Character D9 = bridge key

   MOVB  R7,*R6               * Place key at map origin as a test

 

   My problem last night was I was using the following first line:

 

    LI        R6, @MAPDAT        * then basically corrupting MAPDAT                                         

 

   Caused all sorts of havoc onto my game screen.

Well, none of the above is 100% correct.

 

MOV @MAPDAT,R6 will not store a pointer to MAPDAT in R6, but the content of the memory word at MAPDAT. Thus your byte >D9 will end up at the address pointed to by the data at the first word of MAPDAT, not in the first word of MAPDAT. This will defnitely not be what you expect, and will perhaps lock up your computer. That's the least myserious thing that could occur.

 

On the other hand, LI R6,@MAPDAT isn't correct either. It's not even correct syntax, since such a construct doesn't exits for the TMS 9900. What you want to do is LI R6,MAPDAT, since it's the value of MAPDAT you want to use as a pointer to the first MAPDAT word.

 

To map an area in memory, that's not in line with your code, you can use a construct even TI's original assembler provides. You can use dummy segments, where the dummy origin, DORG, allows for generating entries in the symbol list, without generating any code.

 

DORG >8300

FIRST DATA 1234

SECOND DATA >35F2

THIRD BYTE 22

FOURTH TEXT 'X'

 

Will generate symbol table entries for the labels, like if they were assembled starting at address >8300. But no data is created in a dummy segment, nor loaded into memory at load time.

[Simple Console Modifications]

The best internal modification I've done to my console is adding 64 K 16-bit wide RAM. But you can't honestly call that a simple modification.

[TM990 / 189]

On ‎2‎/‎18‎/‎2019 at 10:49 AM, fabrizio said:

I'm sorry I did not understand the word "housing" !

I was referring to that the case for the "terminal" on the TM990/189 is the same case as was used by the TI 59 calculator.

[What was your #1 cartridge from the old days?]

TI Extended BASIC to begin with. Then came the Maximem, a module simulator (like Gram kracker), into which you could load more or less any module. One at a time, of course.

After getting the p-code card, my programming was mainly done without any particular cartride, as none is needed by the p-system. But I used the memory inside the Maximem as a RAM-disk.

[Question about the TI motherboard shield]

Well, if somebody reports to the FCC, or similar authorities over here, that they have noise preventing radio reception, then an on location investigation could take place, in which case your modified electronics could be found as the culprit, in which case you could be held responsible. But there are many "could" in that chain of events.

One of the main reason the FCC was so worried about this in the old days, compared to nobody caring back then in Europe, is the general state of everyday technology in the US being some 50 years behind Europe. Here, FM broadcasts took over from the much more sensitive AM radio broadcasts in the 1950s. Thus there wasn't much concern about electromagnetic noise until all the computers coming in everywhere put the first requirements for legislation similar to what you had in the US in place in 1995.

[A rather odd question for P-Box owners... (NO FDC)]

No, I've never used my TI expansion box without any floppy controller. When I bought the box, I got the flex interface, 32 K RAM expansion, RS-232 card, p-code card and TI disk controller from start. Put two Teac FD 55B drives in the PEB from start too.

I've since changed to a CorComp double density controller, added two more IBM DSDD drives, added a real-time clock card and added an IO-card, with digital and analog interface circuits. The last addition is a Horizon RAMdisk. Now the box is full, unless the RAMdisk card is modified to contain the memory expansion as well.

[Did you start out on a TI programmable calculator?]

On ‎12‎/‎7‎/‎2019 at 2:09 PM, lucien2 said:

 ...and PLC programming at technical school.

They are frequently programmed in C or the Pascal inspired Structured text languages today.

[Question about the TI motherboard shield]

Being a designer of electric systems for machines, where many of them are exported to the US, I can tell you that the FCC is concerned about interference just as they used to be.

Actually more than before, since they have now adopted some of the more modern European style rules to the concept as well.

[Did you start out on a TI programmable calculator?]

I still like physical calculators better than using a computer. For the simpler tasks. Not for large programs.

But I use my HP 32 SII, HP 15C and HP 16C quite often. On my phone, I use a simulated HP 48S.

[Did you start out on a TI programmable calculator?]

My first programmable device was also a TI-59, augmented by the PC 100C thermal printer.

Spent many hours doing a lot of software on that one.

I've sold the printer, but still have the calculator.

[Can RND ever produce a zero?]

Did you ever get a zero result?

[TI-Writer Poll]

I never converted my TI to any real 80-column thing. Just simulated by moving the screen sideways.

But when I did do word processing on the TI, it was mainly with TI Writer. Only texts intended for use on the p-system were written with the p-system's Editor program.

[I'm taking a pot shot (in the dark) by asking, but does anyone have a better copy of this article?]

That article was published in Sweden too. I still have the magazines. In Swedish, of course.

[Texas Instruments Dimension 4]

4 hours ago, globeron said:

It is not really inside the TI-99/4 or /4A console, but in the PEB (and think it runs on its own like the UCSD Pascal),

It's more like the Geneve. The UCSD p-code card is just a memory card, with 60 KBytes of ROM/GROM. It's still executed by the TMS 9900 in the console.

This card has its own CPU (Z80), just like the Geneve has its own TMS 9995.

 

Interesting to see their timing comparisons with the TMS 9900 and the Z80. The TI fails miserably, but a lot of that is due to the memory architecture in the 99/4A, not the CPU itself.

The TMS 9900 would do the first example in 7.3 us, when memory is at full speed, and has more "registers" available.

In the second example, they use the fact that the Z80 has a block move instruction. Still, with no wait states limiting the TMS 9900, and taking advantage of that it's a 16 bit CPU, thus moving a word at a time, the 9900 will still complete that sequence in 7 ms. So in this case the long time is both due to slow memory and inefficent programming.

[Texas Instruments Dimension 4]

Ah, sorry. And right now, we are parked at 0.1 years, I presume?