Jump to content

apersson850

Members
  • Content Count

    1,013
  • Joined

  • Last visited

Community Reputation

818 Excellent

1 Follower

About apersson850

  • Rank
    Stargunner

Recent Profile Visitors

7,346 profile views
  1. Speed isn't the major benefit from TI Extended BASIC. But very rarely did you see anybody complaining about that other contemporary BASIC versions didn't have the named subprograms TI supported. Probably because most of the testers grew up with a massive amount of PEEK and POKE, so they didn't even know what a program should look like.
  2. No, they would not disappear. The system reserves space in RAM for whatever it needs prior to allowing you to enter BASIC commands. Once you have filled up your part of video RAM, you get the MEMORY FULL error. TI BASIC and TI Extended BASIC uses video RAM differently, so your available memory will be of different size. If you add a disk controller, it uses some of video RAM for buffers. It has to, since there isn't CPU RAM available for that if your machine doesn't have the expansion. Thus your BASIC program has less memory available. TI Extended BASIC uses different memory areas for different purposes. The video RAM is used for strings and stacks. The 24 K RAM is used for code and numeric variables. The 8 K RAM is availalbe for assembly language support to TI Extended BASIC. If you use TI BASIC, then you can use the entire 32 K memory expanison for assembly support, provided you have something to support loading the programs there. The first solutions were the Editor/Assembler and Mini Memory modules. The Mini Memory module added 4 K RAM inside itself, so you could get CPU RAM of any significant size in the bare console. Other environments use memory differently. The P-code system uses the video RAM for video, primary code pool and disk controller buffers. 8 K RAM is used for the 80 column screen, interrupt service and various system functions that can't be on the p-code card, since the p-code card shares address space with all other peripheral cards. The 24 K RAM is used for the heap, stack and as a secondary code pool. Regarding the advertisements for the TI 99/4A, and the amount of memory they claimed, that was the combined memory of the largest things they had all put into the machine at the same time. They counted all RAM (video, expansion and Mini Memory). They also counted all ROM and GROM, in the console and in the modules. Max 8 GROM gave 48 K, bank switched ROM in modules 12 K, for a total of 60 K. If they then counted the separate 60 K on the p-code card too, then that's 120 K already. Not that you can run Extended BASIC and p-code at the same time, but the hardware can be in the machine at the same time. They don't seem to get that far in the ad in this thread. Perhaps they didn't count the p-code and Extended BASIC at the same time, then. Yes, the built-in BASIC and Extended BASIC only supports the SIZE command in immediate mode. With knowledge about where some memory pointers are located in memory, you can calculate something similar. Now you can use RXB, as pointed out above.
  3. It's even more complicated than that, since the 32 K RAM expansion shows up in two different areas in the TI 99/4A design. The CPU memory space is split in eight 8 K pages. 0: Monitor ROM and GPL interpreter. 1: 8 K RAM when the memory expansion is attached. 2: Space for device drivers. 3: Space for ROM in software modules plugged into the console. 4: Built in 256 bytes RAM and ports for access to VDP (and its 16 K RAM), sound, speech, GROM and such stuff. 5,6 and 7: 24 K RAM when the memory expansion is attached. With the expansion attached there are three different RAM pools, for different purposes.
  4. That's good, since code can't run from VDP ram. Not assembly code, that is.
  5. Yes, these two/one instruction(s) are what I typically use for PUSH and POP. I prefer letting the stack grow towards lower addresses, since there is auto-increment, but not decrement, in the repertoire. It also means you can copy the value at TOS by just accessing *SP, since the stack pointer always points at top of stack. If you write an operating system, or utilities for others to use, then you may want to check for stack overflow. If you write a specific program for yourself, and just push return links, not large data structures, to the stack, then it's not worth the overhead. If you do get a stack overflow in such a case, you have either severely underestimated the stack space you need, or you have created some bug which causes values to just PUSH, not POP. Writing macros for the PUSH and POP functions reduce the risk you forget a "+", like in the example above. I frequently used macros for Branch with Link to Stack and ReTurn with Link from Stack, i.e. instructions including the push and branch for a call and pop and branch for a return.
  6. OK, I'll have to look at the link. But I read the exponent is in least significant byte of R7, and you do CB with R7, which looks at most significant byte. Also I don't see the value of the exponent influencing the magnitude of the mantissa. Like if you calculate 1E20-9E0, then it doesn't matter that 9 is much bigger than one. In this case, the exponent will make the result of 1E20-9E0=1E20. The subtraction isn't even noticed. Or do you use the exponent in some other way? After looking at the data in the link, I see it discusses floating point BCD math. Is it something similar to TI's own floating point math you try to use? Just that they use radix 100, since there are no specific radix 10 instructions in the TMS 9900 anyway.
  7. I presume PUSH and POP are defined like DECT SP MOV %1,*SP and MOV *SP+,%1 But I don't get the logic of R2, R3 being the mantissa and the lower part of R7 being the exponent, combined with the code above? Or is this two different cases?
  8. That's because the > says "here comes a hex number" but the - isn't a valid hex digit. -256 or >FF00 are examples of other valid values.
  9. Yes, I imagined that would be possible for you. Way to go.
  10. Just be careful so that you don't assume characteristics in the caller, which will spoil your driver if it's called in a different way. There are examples of when such assumptions failed.
  11. It can be. Maybe I should have written "redesigning" instead. When you build an application where you have to learn along the way, you tend to end up pretty far from optimal. When you think you're ready is frequently the best time to start over, since then you know what you need to know to do it well.
  12. I'm sure refactoring your code could save you a thousand bytes. If you want to add more features.
  13. That's the wrong approach, I'd say. Focus on being able to save an arbitrary screen to begin with. Create a subroutine which, given a screen number and a pointer to the PAB, can save a single screen. Then develop a routine which can put together a few adjacent screens in the same buffer. Call the saving routine to save them. Then develop a routine which can handle a large range of screens, sectioning them to fit in 8 K files, and manage their file names. Call the rotine above to save them. Now you are ready. By this approach, you have structured your program to build routines which can call each other in a meaningful manner. You have also developed all the functionality you need, with all of it in mind to begin with. No need to go back and change things, just because you didn't think of something needed for the next step. By embedding information about which screen(s) are saved in each file you save, and if there are linked files, you only need one type of file loading procedure. It will know by looking in the file what to do with it.
  14. Does this involve saving all pages you have available for the "notes"? Is it a good idea to save all of them each time? Is it not reasonable to consider a user's selection of which pages to save, and/or an automatic save of dirty pages only?
  15. When creating such files, it's common to include a word at the beginning of the file which indicates if it's the last one or not. So if you create three files, FILEA, FILEB and FILEC, at the beginning of the files you have a word that's TRUE in the first two, then FALSE in the last one. Thus you can check the files and see if you need to load another one or not. The file headers should also include some information about where the data should be placed. Like page numbers in your Supernotes program, or whatever is appropriate.
×
×
  • Create New...