apersson850

Speed control by a couple of resistors and relays. The relays shorted the resistors as needed. This assembly was plugged in just like the ordinary speed control handle, so no modification to the race track itself necessary. Car location read out by a photo cell in a "building" along the track. When a computer controlled car passed a photo cell, a timed sequence was started, with different speeds during different times. Then the car passed a new photo cell, which triggered the next table of speeds/times. There are som images here.

When I did my slot car racing controller some years ago, I had a speed control consisting of a few outputs, driving relays which bridged a resistor each in a resistor ladder. This kind of gave me a functionality corresponding to different gears in a car. I also had a photo cell at the start of each track segment, after which I first ran one "gear" for a certain time, then another "gear" forever. The last gear was slow enough to allow the car to run around the track without de-railing. This allowed putting the car back on track anywhere. It would just run at medium speed until it was picked up by some photo cell, then continued at optimized speed from there.

I made a slot car racing control once, but used a Mitsubishi Melsec PLC together with a Beijer's MAC 90 HMI. This was a demo used at an "Open house" event at the company where I worked at that time. One car controlled by the PLC, the other manually. You could compete with the computer controlled car. The use of a PLC was simply because we did use such things in that company, but it would have worked just as well with a TI 99/4A, if that had been the point.

Even if internet wasn't available to share all human knowledge, there were still information sent around. Samples from the E/A manual were of course used first and foremost. Then somebody came up with better code, and you started using that, as soon as you knew about it. Myself, for example, started with the normal DSRLNK, as suggested in the E/A manual, then went with a better one, which could also handle cassette access within the same routine.

Many of us have more manuals than those that came with the computer. Some came with accessories, like the Editor/Assembler or Pascal compiler manuals. But then there are also those extra manuals, like the TI 99/4A Technical manual. It contains some info about the machine and circuit diagrams for the boards in the console and the expansion box. Now I happened to come across a couple of manuals I've never seen before myself. One is the 99/4A repair manual. It's quite interesting. It does of course contain several flow charts for how to troubleshoot certain problems, but it also contains not only wiring diagrams and IC descriptions, but also theory of oepration for various designs in the computer. Like the 16/8 bit memory conversion circuits, etc. I also got an Expansion box theory of operation and training manual. It contains a detailed description of the expansion box (referred to as the "Johnny box") and descriptions of design considerations for the peripheral cards. That does include the PAL equations, something I've never seen anywhere else. Frequent references to the TI 99/4B in this manual, without any description of exactly what that is. What do you think, you TI users out there? Is this something rare, or do you already have this stuff on some server or in a drawer?

Yes, I kept it a bit short, so I didn't go into the implict conversion between real and integer when the logical operators are used. Floating point multiply is for sure more complex than AND, but using AND suffers from the conversion real -> integer before and integer -> real after the operation. This is more efficient in for example Pascal, where you can use integers as variables. Hence the conversions aren't needed.

Not at all. Zero is zero, regardless of the system. If we look at 16 bits only, then not(0000H) = FFFFH. But in two complement notation, FFFFH = -1. Thus inverting all bits in zero returns minus one. This is true regardless of the number of bits, as long as we look at integers. It would not be true in the radix 100 floating point format used in the 99/4A, though.

program feel_good; uses {$U colder.place} nice_weather; begin enjoy(beer); end.

Sweden is different. We have the white winter and then the green winter.

So, did this help?

No, you don't need another library. But you need to tell the system where your library is. It's by default aware of the *SYSTEM.LIBRARY file, but that's all. You need to create a text file, which lists all other libraries you are using, so that the operating system can find them during runtime. If you create a file called *USERLIB.TEXT, and the content of that file is chesslib.code, then the index file is ready. *USERLIB.TEXT is the system's default user library index file. When you've done this, the system will know where to find the file which contains the library which holds the units your program needs. The *USERLIB.TEXT file may contain several lines, each referencing a different user library. It's also possible to create a user library index file with a different name, like sweden.text. Inside the file sweden.text you enter the same as in *USERLIB.TEXT above. But now your data isn't in the default library index file, so you need to tell the system where to look. The easiest way to do this is to type X (for eXecute) at the system prompt, then key in L=sweden.text. Now you've defined which index file to use, instead of *USERLIB.TEXT. Note that you must specify both the drive and the file name. *USERLIB.TEXT means that this file is on the system drive, normally the first one (#4: in the p-system, or DSK1 in the normal operating system). If that diskette's name is PSYS, then the names *USERLIB.TEXT, PSYS:USERLIB.TEXT and #4:USERLIB.TEXT are equivalent. You also have a default prefix drive, indicated by a colon. If you set the second drive to be the prefixed one, by typing X and then P=#5, and the diskette in the second drive is named PROJECT, then the file names HELLO.TEXT, #5:HELLO.TEXT, PROJECT:HELLO.TEXT and :HELLO.TEXT are equivalent. Page 105 in the Pascal compiler manual gives details about this. Feel free to ask questions. by all means! It's nice that somebody else discovers the p-system.

Scoreval must be located either in *SYSTEM.LIBRARY or in a library which is listed in the current userlib file.

Well, then that's why. Since scoreval is referred to in the interface section of movegen, it will be seen when phoenix is compiled. But since phoenix doesn't contain any uses scoreval declaration, this comes as a surprise to the compiler when phoenix is compiled. If you let phoenix explicitly use scoreval before it uses movegen, it will work. But that's unnecessary, actually even a bad choice, since phoenix doesn't need any direct access to scoreval. In movegen, place the uses scoreval declaration in the implementation section instead, and you'll get rid of the unnecessary direct link between phoenix and scoreval. At the same time, the compiler will not see the uses scoreval declaration when compiling phoenix, and thus will not care about where it's defined.

Inside unit movegen, do you have the uses scoreval declaration in the interface or implementation part? Do you need access to anything inside scoreval from phoenix?

As the SAGE is a completely different computer, with a 68000 processor, it's perhaps of limited value when using the TI 99/4A. But the other documents are good.

Yes, back in those days when we used the real hardware only, I was fortunate enough to have a couple of friends who also had the p-code card in their computers. We exchanged a lot of ideas and work. The p-system is rather easy to use, but since it has quite a lot of features, it takes a while to become comfortable with them all. Here's a corresponding poke procedure in assembly language. SP .EQU 10 ;Stack pointer in Pascal workspace is R10. Workspace at 8380H .PROC POKE,2 ;A procedure with two parameters MOV *SP+,R0 MOV *SP+,*R0 B *R11 .END This then requires the following declaration in your Pascal program. procedure poke(addr,value:integer); external; Compile the Pascal program, assemble the assembly program, run the linker to unite the two into one object code file and you're ready to run.​

Yes, poke could of course be implemented in assembly language, but there's no need to. You can use a variant record to accomplish the same thing without leaving Pascal. program demo; uses screenops; const sysdate = 13840; (* A data type to allow poking *) type window = record case boolean of true: (int: integer); false: (ptr: ^integer); end; (* And one to allow assigning a date record to an integer. sc_date_rec occupies the same space as one integer in memory. *) convdate = record case boolean of true: (int: integer); false: (dat: sc_date_rec); end; var today: sc_date_rec; buffer: convdate; (* Now we can write poke *) procedure poke(addr,value:integer); var memaddr: window; begin memaddr.int := addr; memaddr.ptr^ := value; end; (* poke *) begin (* demo *) with today do year := 16; month := 5; date := 8; end; (* with *) buffer.dat := today; poke(sysdate,buffer.int); end. The trick with a variant record with only a type definition is famous for this kind of operations. You can access VDP RAM in a similar way, from Pascal, but since the p-system frequently executes code from VDP RAM, and in such cases assumes that the VDP address isn't changed between instructions, you have to set your program to M_9900 language type, to force it into CPU RAM. When you do want to go to assembly, you'll notice that the interface between the two languages is more straightforward than it is between BASIC and assembly. The p-system's assembler is better than the 99/4A version of TI's own assembler as well. You must link explicitly, though, as no linking with separate assembly language object code is taking place at runtime. By the way, in the file p-system program development linked to above, you can on page 3-8 find the interface text of the screenops unit. There you can see where I got these data types from.

Poke is not in any unit. I defined it myself, but thought that perhaps you knew how to write one. If not, I can give you an example. The code I showed comes from a startup program that reads the current date from a real-time clock and sets it in the system, if it's different from the current one. It's not a theoretical design, but actually works. And, as you can see, there is a way to set the date. It's just not documented in TI's manuals, but is a standard UCSD p-system way of reading and setting the date.

Oh, you are asking about things done 30 years ago! I can hardly remember what I did yesterday... But probably from some Internal architecture gudie for the UCSD p-system. As far as I can remember, the interface text section is intact in the system's compiled screenops unit, so you can read it there using decode. The fact that you have to poke the date into the copy in RAM for everything to work I found out when I wrote startup programs that could read the current date from real time clocks and set it in the p-system automatically. Without poking into that RAM location, I had to re-initialize the system for the new date to be valid and used by all functions.

Use the unit screenops. Normally it's available in SYSTEM.LIBRARY, but if not, access from wherever, or include it there. You can see the outline of how to set the system date below. In the small program below, I don't show how to write a poke procedure in Pascal. Neither do I show the details of how to get a date record into an integer, which usually is what you poke. If you don't know how to do this, neither with the variant record nor with the ord trick particular to UCSD Pascal, come back. program datefix; uses screenops; const sysdate = 13840; var info: sc_info_type; begin (* Store date in system *) sc_use_info(sc_get,info); with info.sc_date do begin year := 16; month := 5; day := 6; end; sc_use_info(sc_give,info); (* The system keeps a copy in RAM for immediate access. *) poke(sysdate,date_as_an_integer); end.

Installing 16 bit wide memory all over increases the speed by about 110%, compared to running code with everything in 8-bit wide expansion box RAM. Without changing the clock frequency. But it's more work, of course.

After modifications everything is possible, of course. What I referred to was that an unmodified dump of the contents of the p-code card would not run from a normal GRAM device, as all addressing will be wrong in such a case.

That's of course doable, but notice that the p-code card, although it contains GROM and 12 Kbytes of ROM, just like Extended BASIC does, is completely different in how it's implemented. The p-code card uses a different set of GROM access addresses. This is necessary since the p-code card has eight GROM, not just five. Thus it can't use the standard addresses, or it would come in conflict with the three GROM in the console. The p-code card has the GROM access addresses mapped into DSR memory space. Since they overlap precious ROM space there, they are fully decoded. Console GROM access addresses aren't. The p-code card has 12 Kbytes of ROM, just like Extended BASIC, but this ROM is all in DSR space, not command module space. Also, bank switching is done with a CRU bit, not by writing to a ROM address, like Extended BASIC does. All of this can of course be handled, but perhaps not by a device developed to allow normal command modules to run on the machine. A GRAM Kracker wouldn't do, for example.

While it's true that it doesn't take any special hardware to run the Turbo Pasc'99 (no p-code card needed), it's incorrect to say that it's a much better product. From a software development point of view, there has never been any more complete platform than Pascal with the p-code card on the 99/4A. All other systems are lacking one or, usually, several of the well thought out mechanisms inherent in USCD p-system IV.0.

It could have been something they planned as an option, but never manufactured.