apersson850

What I usually see here used instead of small capitals are italics. For the same reason as the Wikipedia article mentions as a use case for small capitals. When I do see small capitals here it's in that case as the first few words in a new paragraph. Instead of indentations or just one large leading letter. But then they aren't small capitals in the font used, but a totally separate font used for the leading words. Sometimes even in a different color.

No it's not, because it was in the logotype from day one, in 1951, when it changed name from Geophysical Service Incorporated. There were no calculators around back then. Regarding the external video, as far as I remember it's only in the NTSC version, TMS 9918, not in the other versions 9928 and 9929.

I'm talking about the reason for why they used that font also in the TMS 9918A manual. The origin of it. And that's pretty clear. They didn't know any better since they already had it in their logotype. The logotype has changed, but seems to have been all caps all the time.

Here's the font I use.

In case anyone didn't get where they got the idea with small capital letters from: I've used a character set with true lower case letters, descenders included, for years, and it works fine. Much better than the original. It's only if a "g" happens to be right above an "A" or similar that they touch. Happens rarely enough for the advantages to be more important.

I assume you're joking. It's very easy to figure out where the idea with larger and smaller capital letters came from.

He probably has some AI-inspired BASIC interpreter according to the "Do what I mean, not what I say" principle. To be (slightly) serious, cosine is a periodic function, so with some luck you get something similar, regardless of what kind of data you put in.

That's correct. I tried to stay as close to the implementation of turtlegraphics in Apple Pascal for Apple ][ as I could, to make it as easy as possible to run programs originally designed for that computer. It wasn't possible to match it completely, since the Apple has a different way of handling colors than the TI. Not the same video processor.

The turtlegraphics unit is in a "proof of concept" phase, and has been like that for 35+ years. There are some functions in the different write modes that don't work and some other stuff that's not implemented. But if you include uses support and then set the screen color the normal way, I think that's compatible with the turtlegraphics unit too, since it only changes a VDP register. Update: I checked in one of my test programs. It does uses support and then starts with this sequence. (* Gives a darker background *) set_scr_color(ord(black),ord(red2)); grafmode; The color change is done prior to entering bitmap mode. Not sure what happens if you do it with bitmap mode active. But the default background color for screen items is transparent, so the backdrop should be visible.

The best thing I see with it is that you more or less took the original code, changed the syntax from BASIC to Pascal and it ran!

Looks like it's some preferred way at TI (if you don't have a TI 990 mini computer) to write assembly language subroutines before the Editor/Assembler package was introduced.

It may make sense anyway, since the JEQ will test the last thing that happened in the subroutine. As stated before, CLR doesn't change any status bits since the result is obvious anyway.

Yes, but using Setltype (Set Language Type) is easier than doing the linking. As always (?) with the p-system, there are more to it than that. Let's recap how units work. Separate compilation One of the advantages of the unit concept in UCSD Pascal is that you can compile parts of your program separately. If the program is very large that's a necessity, since our little computer doesn't have memory enough to compile too large programs. By compiling a unit instead of a program, you create a support file for your program. The unit comtains an interface part which defines to the main program the data and procedures available and an implementation part which contains the code to execute. The user of a unit doesn't need to know how the procedures are implemented, only how to call them. You can even change the implementation without having to re-compile the programs using the unit, as long as the interface is the same. Compiling the unit This is as easy as compiling a program. Just run the compiler and it creates the code file for you. The basic structure of a unit is as below. unit example; interface type extype = record this, that: integer; end; procedure doexample(handle: extype); implementation procedure doexample; begin (* Code *) end; end. Compiling the program When a program uses a unit, it must know where to find the unit's code file. Easiest is if it's included in the *SYSTEM.LIBRARY file. Then it's all automatic. (Note that the * in the filename represents the system volume, i.e. the boot disk that was in #4: when starting the system. It's not part of the file name, but equivalent to passys: if the system disk is called passys. In such a case, *SYSTEM.LIBRARY is equivalent to PASSYS:SYSTEM.LIBRARY or #4:SYSTEM.LIBRARY, provided pasys is actually mounted in drive #4:.) In the case the unit is in a separate code file you need to tell the compiler where to find it. In the example below the first unit is in *SYSTEM.LIBRARY but the second is not. program unittest; uses support; (*$U develop:exfile.code *) example; Running the program When you run the program the same is true: If the unit is in *SYSTEM.LIBRARY everything works automatically. The build_env procedure in the operating system will locate the units referred to by your program and build the run-time environment records and vectors so the system can locate the files needed when they are needed. However, if the unit is still in a separate file, you need to tell the build_env where to locate it. This can be done by a text file listing the library files to search, just as @Vorticon showed above. In this example the content of the text file would simply be this: develop:exfile.code If you do store this in the text file called *USERLIB.TEXT (note that it must be on the system disk), then the program will find your unit. However, when you are designing your program you may not want to mess with a perhaps already existing *USERLIB.TEXT file. You can create a separate library reference file for your experiments. The content would still be like above, but you can store it in DEVELOP:EXLIBS.TEXT. But that's not where the run-time system will look by default. To make this work at runtime you have to use an execution option. You set it up by pressing X (for eXectue) at the top system level. But instead of entering a file name of a program to execute, you type in L=develop:exlibs.text. Now you've told the system you have a user-defined library reference file, so it can find it and through the information in it find your unit. You can list more than one unit in such a file, if you have your units spread all over the place.

You already know how to do poke and peek in Pascal, with the dual data type. Poke the VDP read address port to the VDP, then peek the VDP read data port from the VDP. If you want to write to VDP RAM or to VDP registers, you need to set the second or first bit in the address. Remember that UCSD Pascal can do bitwise logic functions by using the odd and ord functions. So you can do VDP_address := ord(odd(16384) or odd(your_address)); where both VDP_address and your_address are integers. That will set the VDP address for a write (which you don't need for GCHAR, of course). Also note that you'll need to create a swapbyte function, but there you can do a dual data type with an integer and a packed array[0..1] of byte, where byte is 0..255, to handle that. A word of caution! In the example above the constant 4000H is represented by the 2's complement decimal number 16384. If you want to get the equivalent of 8000H into a decimal number, you can not use the constant -32768! Since that number can't be negated without an overflow (there is no +32768 in the range of 2's complement 16-bit numbers) it will be handled like a long integer constant, occupying two words, not one. But you can use 32767+1, as UCSD Pascal does no overflow detection on integer arithmetic. As long as you don't divide by zero, that is. Note that for this direct VDP access to work you need to manually set the code type to M_9900, since if it's M_PSEUDO then the code usually will be loaded in VDP RAM. If you then change the read address the PME will get lost about where the code is. The PME will only set the VDP read address when performing a jump. If you link in an assembly procedure into your Pascal program the linker will set the code type automatically, since assembly can't run from VDP RAM. But the compiler can't know which memory you'll access in a Pascal program, so there it's not automatic.

If you aren't going to use it too frequently you can write the whole thing in Pascal. Then you don't need the linking. But otherwise you're correct.