Jump to content

apersson850

Members
  • Content Count

    660
  • Joined

  • Last visited

Community Reputation

443 Excellent

About apersson850

  • Rank
    Dragonstomper

Recent Profile Visitors

6,935 profile views
  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. He told you were to find a listing. Don't expect everybody else to do all the work for you.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...