I was just going to say what @lindertim said. The Tandy manuals are very wrong on this, and it wastes a *lot* of RAM using their method for allocating. Since Extended BASIC only has REAL numbers... every element in an array takes 5 bytes. That is enough room for 40 pixels wide in a 2 color mode - (PMODE 0,2,4) or 20 pixels wide in a 4 color mode (PMODE 1,3). Using Allen Huffman's program that Tim linked to in his comment (it is listed under the heading "How much array memory do I need?"), you can calculate the exact DIM size you need. You literally have enough room to GET an entire screen (or 2, even) - using the BASIC manual calculation you don't have enough room for 1. The DIM you did (following the manual) is actually reserving enough space to fit an entire PMODE 1 screen ... and almost 75% on an entire second PMODE 1 screen. Regarding PUTing a different size - this thanks to Microsoft choosing to scale all coordinates (no matter what screen resolution that you are *really* using) to 256x192. So you have to "scale" it up on lower resolution modes (like PMODE's 0 to 3). I really hate that they did that... it makes a lot of these calculations harder than they needed to be. (Thankfully the Coco 3 HGET/HPUT don't have this problem, and BASIC09 lets you turn scaling on and off, depending on what type of graphics calculations that you are doing). Have you joined our Discord yet? If not - send me an email (on my games site in multiple spots) - RUclips will eat any weblinks I give here, and sometimes eat the entire message so you don't see it at all.
Your DIMensioning is too large and it is wasting space. A "DIM A(20,50)" is 1,000 elements of storage. A 42x100 GET under PMODE 1 only needs 53 elements for storage. So DIM A(53) will use the smallest amount of storage and still work. See this webpage for the algorithm to calculate the proper storage: subethasoftware.com/2024/01/03/extended-color-basic-put-from-data/
Nice video. This brought me back to the 80s. Thanks for the memories!
I'm glad to hear it! Thanks for subscribing. Enjoy the channel.
I was just going to say what @lindertim said. The Tandy manuals are very wrong on this, and it wastes a *lot* of RAM using their method for allocating. Since Extended BASIC only has REAL numbers... every element in an array takes 5 bytes. That is enough room for 40 pixels wide in a 2 color mode - (PMODE 0,2,4) or 20 pixels wide in a 4 color mode (PMODE 1,3). Using Allen Huffman's program that Tim linked to in his comment (it is listed under the heading "How much array memory do I need?"), you can calculate the exact DIM size you need. You literally have enough room to GET an entire screen (or 2, even) - using the BASIC manual calculation you don't have enough room for 1. The DIM you did (following the manual) is actually reserving enough space to fit an entire PMODE 1 screen ... and almost 75% on an entire second PMODE 1 screen.
Regarding PUTing a different size - this thanks to Microsoft choosing to scale all coordinates (no matter what screen resolution that you are *really* using) to 256x192. So you have to "scale" it up on lower resolution modes (like PMODE's 0 to 3). I really hate that they did that... it makes a lot of these calculations harder than they needed to be. (Thankfully the Coco 3 HGET/HPUT don't have this problem, and BASIC09 lets you turn scaling on and off, depending on what type of graphics calculations that you are doing).
Have you joined our Discord yet? If not - send me an email (on my games site in multiple spots) - RUclips will eat any weblinks I give here, and sometimes eat the entire message so you don't see it at all.
Your DIMensioning is too large and it is wasting space. A "DIM A(20,50)" is 1,000 elements of storage. A 42x100 GET under PMODE 1 only needs 53 elements for storage. So DIM A(53) will use the smallest amount of storage and still work. See this webpage for the algorithm to calculate the proper storage: subethasoftware.com/2024/01/03/extended-color-basic-put-from-data/