apersson850

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.

Now I don't know what kind of game you are planning to convert, but if it's something that has some kind of action, then you should be aware of that if you put such a function as @Vorticon provided above in a pre-compiled unit, then you have a very convenient way of handling it. But you also have the absolutely slowest possible call command to use it. A global external inter-segment call is by far the most complex way there is to invoke a procedure. So if you intend to call this gchar equivalent frequently I recommend you include it in your main program instead.

The whole thing is further complicated by the fact that the p-system really is an 80 column screen system. All printout is on the 80 column screen, and then you select which part of that you want to show on your physical screen. So you have to decide if you want to read things from the physical or logical screen. The operating system also has a data area with a pointer to the 80 column screen and the physical screen's height and width. You can also see which is the current window shown on the screen. Here's an extract of some system data. The simplest way to see if you are in text or graphics mode is to check the value at 2CC6H. If it's 40 you are in text mode. If it's 32 it's graphics mode. 2CAC AA00 DATA DSR validation code 2CAE 0080 2CB0 81F0 DATA VDP copy R1 2CB2 8202 DATA VDP copy R2 2CB4 832F / DATA VDP copy R3 2CB6 8400 DATA VDP copy R4 2CB8 8518 DATA VDP copy R5 2CBA 8600 DATA VDP copy R6 2CBC 001F DATA VDP copy R7 2CBE 2000 DATA Pointer 80 column screen 2CC0 0017 DATA Current line 2CC2 0000 DATA Current column 2CC4 2730 '0 DATA Current 80 column address 2CC6 0028 ( DATA Screen width 2CC8 0018 DATA Screen height 2CCA 0000 DATA Current screen window 2CCC 0730 0 DATA Number of bytes in 23 lines (for scroll)

Exactly. Which is why I wrote hardly in a general manner. It doesn't work well on a standard machine, since the memory is too small.

Thinking a bit further about the procedure to enter and leave bitmap mode, I can see that there is one thing which I do not save, and that is character definitions in the range 128..255. The reason for that is of course that I would have had to save them in a file, as there's no room without some kind of memory expansion. My decision was that it was not worth it, since if you actually do use these character definitons, then it's probably because you want to do some minor graphic thing, in which case you don't use bitmap. If you do use bitmap, on the other hand, it's not too likely that you also in the same program want to use special definitions of characters 128..255. Since I have no definitions for them I don't print them on the screen with the wchar function unit turtlegraphics supports anyway. The next step in a possible further development of unit turtlegraphics is probably to allow a copy/paste functionality of the screen. I envision that to work like this: Define a viewport on the screen. Copy the graphics inside the viewport and store in a file (because that's the only way if it's the full screen). Define a new viewport. Paste the copied file into that viewport. Steps 3-4 can of course be repeated to create multiple copies of the graphics on the screen. If the viewport is defined to cover the whole screen you'll effectively create screen images, which you can restore by reading in the files. Pasting a graphic object can be done in several ways, just like when drawing lines. Just overwrite what's there is simplest, but you can also imagine adding it to the existing graphics, subtract it and so on. The current functions in unit turtlegraphics can also handle just the image or the image and color as a unit. Some systems do allow you do manipulate graphics as a separate non-visible object, then copy that to the screen when it's ready. Doable on the 99/4A too, but hardly in a general manner, since the largest images will be troublesome to have in memory together with the bitmap mode and a meaningful software handling them, all at the same time. Anyway, storing these graphic objects as files has the advantage that it works on all systems but can also work almost at RAM speed if there is a RAMdisk defined in the system. If you want to make a program that rolls through a number of screens you can predefine those as files on a disk, copy these files to the RAMdisk when starting the program and then run them from the RAMdisk to reduce delays.