apersson850

Then I have the news for you that the plotting challenge is already resolved. Just look at the posts in the thread. But I can remind you about that you also asked for a way to input the functions to plot, and that it should be more than one function. Which is what I discussed above. If you need that explained more times, just read this post again. Once you are done with that, some constructive input to how to define the functions would be more fruitful.

Why this distinction between 8-bit and 16-bit machines? An 8-bit CPU can do anything a 16-bit can. It will usually take a longer time, but it can do it. Comparing with the TMS 9900 even implies that you compare processors with the same address space, since the TMS 9900 has a 16-bit address bus, something many 8-bit CPU designs also supports. When it comes to advanced function analysis, memory had more to do with it. Looking at plotting, the video processor implies certain limits. We've already seen that you can plot a function with a TI 99/4A, in several ways. There's been no decision about which language to use. Making a general plotter, you have to make some kind of provision for getting the function in there. In BASIC, it's frequently so that the user is supposed to make one or more program lines to calculate the function. In traditional compiled languages, like Pascal, that's not equally easy. One way is to access the user defined function in a separate unit, so the user only has to compile that. In Forth, you can define words that evaluate the function. But the plot package has to access a function that's not yet defined. And can later be redefined any number of times. I've not used Forth enough to know the best way to do that. Can you have a pointer to a word, and run it like that? As you define words, they are packed in memory, one after another. Can you redefine a word, when more other words have been defined after it? How does it fit, if the new definition is longer? In assembly you can do whatever you like, but that's a bit awkward for a plotter. An other approach is to write a general math statement parser, so you can key in your function as a text string. But already there, the main task of the plotter is no longer plotting on the screen, but parsing and evaluating that function. Plotting on the screen is impossible in BASIC, at least on the full screen, without assembly support. It can't be done in Pascal either, not without expanding the functionality like I did with the turtlegraphics unit. But there too you need at least a little assembly support to set up the system. I've written line drawing procedures in Pascal, and they work, but are far too slow for practical use. At least the unit concept conceals the assembly part, so as a user of the library, you don't have to worry. You just include the statement uses turtlegraphics in your program. I just quickly read the manual you linked to. It confirmed my suspicion that the main part of such a program isn't drawing on the screen, it's the management of the mathematical functions.

There's Matlab for things like that. Recreating parts of that on an old computer isn't within my interest.

There's much more information to get by looking at the referred data at whtech, rather than posting one single example here. Serveral samples of plotting data too.

Yes, but I don't intend to. You can find a summary of everything I did to implement bitmap graphics in Pascal at the whtech server. Look for programming/pascal/turtlegraphics. Here's the interface part of the turtlegraphics unit, as far as I brought it. You can go to and from bitmap mode, you can move the turtle, and while doing that, you can set the pen mode so that the turtle just moves invisibly, or draws a line behind it. You can also write characters and strings, as well as create a hardcopy of the screen for Epson-compatible dot matrix printers. unit turtlegraphics; (* Test of turtle graphic routines *) (* A-DATA 870408 *) interface type screen_color = (transparent,black,green2,green3,blue1,blue3,red1,cyan,red2, red3,yellow1,yellow3,green1,magenta,gray,white); screen_mode = (invisible,substitute,overwrite,underwrite,complement, none,draw,erase,reverse); procedure grafmode; procedure initturtle; procedure textmode; procedure viewport(left,right,bottom,top:integer); procedure pen_color(newcolor :screen_color); procedure pen_mode(newmode :screen_mode); procedure move(distance :integer); procedure moveto(x,y :integer); procedure turn(newangle :integer); procedure turnto(newangle :integer); function turtle_x :integer; function turtle_y :integer; function turtle_ang :integer; procedure w_char(ch :char); procedure w_string(line :string); procedure hardcopy; implementation

Is there a specific point in making the label digits smaller than normal? Do you think they occupy too much screen real estate? There have been function plotters for the TI, in different languages, for more than 35 years now. Many years ago, I did one in TI Extended BASIC, which had the same resolution as multicolor mode. By defining a number of characters, with two by two "blocks", not more characters were needed than that I could define all of them. If I needed the two top blocks on in a specific position on the screen, I printed that character on that location. If then a new curve (the program could plot multiple functions in the same screen) needed the two blocks at the bottom of that position on, I replaced the character with two top blocks for one with two top and two bottom blocks. This allowed plotting any combinations of curve across the whole screen, but with the resolution limited to four by four pixel blocks. It wasn't until I implemented bitmap mode in Pascal, a few years later, that I could plot multiple functions, with lines in different colors, and add text labels, with the resolution of one pixel.

That's one part of the challenge in a forum. Not everybody dances to your tune. The major whining you've done yourself here. But never mind, back to the regular program in this thread.

Sorry man, but this is a forum. You don't set the rules. If you want to make challenges, fine. If somebody solves them in a different way than you thought, face it.

Indeed it is. And it's not any easier when you consider that there's an assembly code repositiory in GROM, code which should be transferred to RAM, and run there, and have the correct references to the p-code card when needed.

He told you were to find a listing. Don't expect everybody else to do all the work for you.

The issue with the memory consumption of the bitmap mode is of course the same when using Pascal. The p-system has two code pools on the TI 99/4A. It can run user programs from either VDP RAM or from the 24 K RAM. When using bitmap, I set a pointer which will inform the system about where the available memory starts in VDP RAM. This means that the p-system will load more code in 24 K RAM instead. Fortunately, the p-system has a very good support for segmenting programs, so you don't need all of them in memory at the same time. Thus, with some planning when designing your program, you can still run large programs, without having to handle the memory swapping yourself. It was many years ago now, but if I remember correctly, I save the character patterns as they are in VDP RAM, prior to entering bitmap mode. Then I use these patterns when the special print routine in the graphics package is called. I think I saved characters in the range 32..127, but not outside that. It's at least all normal characters. When I restore to the normal text mode again, I reload these saved characters, but set those in the ranges 0..31 and 128..255 to blank. What's left to do in my turtlegraphics unit is some variations of how to write text. Now it only supports overwrite, i.e. writing by turning pixels on, so the foreground color is used. I did plan to allow underwriting too, i.e. write with the background color, so you can create a text also in a filled field. Plus some other variations. I've also not implemented the ability to store graphics in files, for later retrieval/reload. I haven't implemented the viewport concept either. It's a concept where you can limit the impacted part of a screen to a specific box, like from 100,100 to 150,150. Any graphics sent outside this box isn't printed on the screen. Handy to make a plot window at a part of a screen, without risking plotting into other areas by mistake.

When I created the unit turtlegraphics for the p-system, I made it possible to use bit-map mode (or Graphics mode II, as it's also known) in Pascal. Normally, Pascal supports Graphics I (same as BASIC), text mode (like E/A editor) and multicolor (which almost nothing else uses). Although I never fully completed that unit, it does support drawing lines in different colors, as well as writing text. You can define a position, using any pixel number, and a text string in a call to the printout procedure. It will then print text there, according to the character definitions that were present, when the bit map mode was invoked. So by including uses turtlegraphics in the Pascal program, the task to do such a plot is fairly straightforward. But the implementation of the unit is pretty complex. As an example, since it allows using the standard character definitions to print text placed anywhere on the screen, not just in the normal character positions, a single character can occupy parts of the space normally used by four characters. The algorithm to transpose the definitions from one block to one, two or four, depending on where the character is placed, is quite complex.

I'm aware that there once was a sidecar p-code card for the TI 99/4A. When I asked for a reincarnation of the p-code card, I didn't really consider whether it would be for the box or a sidecar. Today, a sidecar can be quite a bit more compact than the original one, though.

Because there's a difference between 24 K in high memory expansion plus some 12 K in VDP RAM, which Extended BASIC also uses, for strings and some other stuff, compared to 14 K available for applications in Cortex BASIC. So for Extended BASIC it's a total of some 36 K available, for Cortex 14 K. Thus Extended BASIC has about 2.5 times the memory at its disposal, compared to Cortex. Then, if that implies that Extended BASIC can run large, and Cortex small, programs, or if Cortex can run large and Extended BASIC gigantic programs, that's a question about semantics. Compared to today's memory requirements, Extended BASIC can run minimal and Cortex virtually non-existing programs, but the memory requirements in the 99/4A environment isn't like what we see today... As far as I know, Cortex BASIC is dead. There's obviously a port to the 99/4A, but the Cortex, to which it was originally ported, is dead since way back.

Genau! Besides, since I now understand that the purpose of this BASIC improvement isn't to use it, but to impress owners of various Commodore computers, the problem is already solved. Just use the ported Cortex BASIC. The fact that it's quite a bit less useful, due to limited space for application programs, doesn't matter, if the purpose is to demonstrate performance. That's invariably done with a program less than a page long, if you print it. For useful things, it would be better to make some p-code card clone, and focus on getting a native code generator running on the 99/4A.

Nothing is impossible. The question is instead if it's worth the effort required. My opinion in this case is a definite no. There are better things to spend efforts on, giving more ROI.

Not that I'm doing RXB, but I'd say it's clear that there's not space in normal Extended BASIC to do that, as it would affect almost every function that uses a numeric argument. Or maybe not even almost, but actually every single one of them. Such a thing is something you should plan in the original design. It's nothing you add with a good result after the fact. It will also add some penalty to everything else, as the check for argument type has to be added. If I've understood RXB correctly, it adds some features and stuff to Extended BASIC, by using a few unused spaces in the original memory map. Rich will correct me if I'm wrong.

Look on your console how they spell Texas Instruments, and you get an idea about where this thing with large and small capitals came from.

Yes. The DSR code simply jumps over these four addresses.

As I see it, the main issue if trying to add integers to BASIC is that handling numeric arguments is done by each function itself. So everywhere you check that the argument is numeric, and treat it accordingly, you now have to check if it's a floating point or integer value, and treat them differently. I still see the "value for money" factor to be too little for this project to be interesting. There are routes that are more beneficiary, if you simply want to speed up design and execution of your programs.

Yes, this feature comes from the TI 990. So it's not unique. I was rather referring to that in computers at the same ambition level as the TI 99/4A, it's rare.

Here's another example of something that's (comparatively) easy to do in Pascal, as the TI implementation allows for concurrency. Thus you declare the coincidence handler as a process, which hangs on a semaphore. When that semaphore is cleared, the handler will run. The trick you have to do is write something which can clear the sempaphore on the interrupt, but then going to the right place in the high level language is pretty simple.

That's always something you need to do, if you want to port a program from one language to another. You have to take into account the limitations and capabilities of the language you are going to. Otherwise you may get completely misleading results, when you don't use the good features of the new language. This also makes comparing languages more difficult. I'm of the opinion you have to look at the entire development environment when you evaluate them, not just a few isolated features, that are proven by some small test program. To return to some questions asked before, Cortex BASIC doesn't use GPL as far as I know. Why would they? The main reasons for using an intermediate language is compactness and/or portability. The UCSD p-system does use p-code as an intermediate language. This was done to provide portability at a time when a program on one computer never would run on another. By compiling Pascal programs to p-code, which then was executed by a comparatively simple interpreter on the target machine, they could make compiled code portable between completely different machines. This was an amazing feat in the 1970's. Today, when "everybody" uses computers with the same architecture, there's no advantage to this. It's the default. When it comes to GPL, I do imagine that it was developed to make the programs smaller, in the limited memories of the time. I've seen some reference somewhere to that TI had some thoughts about developing a CPU, which would run GPL as its native language. It never happened, as far as I know. TI Extended BASIC is pretty feature-rich. Named subprograms, for example, are very rare in BASIC dialects. The Cortex also implements quite a lot of hardware. That was the design philosophy behind it. I've never used any, but I read a lot about it, and stole some ideas for the computerised instruments I designed and built many years ago. When it comes to the different CPU models TI manufactured, they have different performance. The TMS 9900 has it's heritage in the TI 990 mini computer line. The first in that series, the TI 990/9, implemented a memory-to-memory architecture in a CPU, built by several TTL components across several circuit boards. TI used it's top notch IC knowledge (at least at that time) to integrate the whole TI 990/9 architecture on a single chip, the TMS 9900. It was used in several lower-end TI 990 minicomputers, like the TI 990/4 and TI 990/5. The much more advanced successor TMS 99000 was used in the TI 990/10A. Another successor to the TMS 9900, the TMS 9995, was designed to be easier to implement. It's equipped with an 8-bit wide data bus, compared to the 16 bits in the TMS 9900. This made it possible to use a 40 pin package, instead of the huge 64 pin DIL used by the TMS 9900. Internally it was still a 16 bit CPU, implementing the same instructions as the TMS 9900, and a few more. It also has a few more hardware features, and doesn't require a separate clock chip (TIM 9904). To compensate for the narrower data bus, the TMS 9995 has about 256 bytes of on-chip memory, much like the whole TI 99/4A computer has 256 bytes of fast RAM in the computer, but outside the CPU. The on-chip memory in the TMS 9995 is 16 bits wide, of course. TMS 9995 is a more efficient design. This is partly due to being able to do more in one clock cycle and partly due to that it implements a single-level pipeline. Where the TMS 9900 typically accesses memory in a cycle, does internal processing in the next, accesses memory again, does more internal processing and so on, the TMS 9995 accesses memory in almost every single CPU cycle. Except for when executing more advanced instructions, like MPY or DIV, the TMS 9995 is fast enough to either read a new operand or write an obtained result all the time. This means that if the TI 99/4A would have been designed around the TMS 9995 instead, that alone would have given it a higher capacity. You can compare with the Myarc Geneve, which does use the TMS 9995. But that chip didn't exist yet, when the TI 99/4 was designed. This means that if you want to, there is no difference between TMS 9900 and TMS 9995 software. But to make the most of the TMS 9995, you have to make sure you put your workspace, frequently addressed data and, sometimes, frequently executed code, in the internal memory on the chip. And no, it's not in the same place as the fast memory in the TI 99/4A. Also, if you do math, you may need to rewrite the code to use the DIVS and MPYS instructions in the TMS 9995, instead of just using DIV and MPY (the instructions the TMS 9900 supports), and then handle the sign separately, with a multiple of other instructions. The TMS 9995 was the CPU I used in the instruments I built, a long time ago. I still have some vintage TMS 9995 chips in a box. That's why I know it so well. TMS 9995

There are several reasons. While the TI 99/4A hardware architecture is about trying to adapt something that shouldn't be there to do something it wasn't intended to do, at the lowest possible cost, the Cortex is designed around the philosophy why do a half measure, when you can go all in? There is no intermediate interpretation level in the Cortex, i.e. no GPL. Since the space effective GPL is missing, Cortex BASIC also don't have all features TI Extended BASIC has. Cortex uses the TMS 9995 CPU, which is 2-3 times as fast as the TMS 9900 (depending on the memory usage). But due to the complicated and inefficient memory usage in the 99/4A, the difference is frequently even larger than that.

The console's basic arithmetic functions (add, subtract, multiply and divide) are in assembly language and stored in the system ROM in the console. TI BASIC uses them, and so do Pascal. Not all Forth dialects, though, if they support floating point math at all. If Extended BASIC, for some reason, is running its floating point math in the module, not in the console, then it's slower in spite of being identical. But that's due to the computer's hardware architecture, not the language's interpreter.