Asmusr Posted May 1, 2021 Share Posted May 1, 2021 45 minutes ago, Airshack said: With this arrangement plus VR2 set to >06, the 768-byte screen image table may safely reside from >1800 to >1AFF. So the overhead for this hybrid mode looks like this: >0000 to >07FF, pattern table 1 (2K) >0800 to >0FFF, pattern table 2 (2K) >1000 to >17FF, pattern table 3 (2K) >1800 to 1AFF, screen image table >1B00 to >1FFF, unused (1.25K) >2000 to >27FF, color table (2K) @rasmus I another thread you mentioned how this type of arrangement slowed down your scrolling routine. Why? For that kind of scrolling you need to update the pattern and color tables on the fly. Updating three pattern tables (with identical patterns) and one color table takes twice as long as updating one pattern table and one color table. But it's required if you want to use more than 8 sprites. BTW, I would usually place the sprite pattern table from >1800 to >1FFF so I don't end up with unused space, and place the name table (which the E/A manual calls the screen image table) after the color table at >2800 instead. 1 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted May 1, 2021 Share Posted May 1, 2021 8 hours ago, Asmusr said: BTW, I would usually place the sprite pattern table from >1800 to >1FFF so I don't end up with unused space, and place the name table (which the E/A manual calls the screen image table) after the color table at >2800 instead. A very helpful answer. Much appreciated as always. This looks like a best practice to me. The “name table” label always confused me as it’s not as descriptive as it could be. That and “Early Clock,” terms I see as adding complexity where there is none. I view the early-clock setting as the Sprite Origin setting. Thanks again! On my next project I may be asking for assistance with the one-the-fly pattern/color table updating methodology. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 1, 2021 Share Posted May 1, 2021 5 hours ago, Airshack said: That and “Early Clock,” terms I see as adding complexity where there is none. I view the early-clock setting as the Sprite Origin setting. Well, "early clock" is what's happening in the hardware, it makes the pixels start to clock out earlier. 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted May 1, 2021 Share Posted May 1, 2021 1 hour ago, Tursi said: Well, "early clock" is what's happening in the hardware, it makes the pixels start to clock out earlier. When pixels clock out early do they still get paid? Just pointing out how the EA manual often assumes reader awareness of jargon and technical concepts which are not explained elsewhere in the manual. Thankfully, we in the future have websites filled with additional information. Better yet, we have real-life experts sharing knowledge on forums like AtariAge. Never a better time to learn. Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 2, 2021 Share Posted May 2, 2021 13 hours ago, Airshack said: When pixels clock out early do they still get paid? Just pointing out how the EA manual often assumes reader awareness of jargon and technical concepts which are not explained elsewhere in the manual. Thankfully, we in the future have websites filled with additional information. Better yet, we have real-life experts sharing knowledge on forums like AtariAge. Never a better time to learn. Of course they do, they get paid before everyone else in fact! The E/A manual was written during a time when programmers were expected to understand what the hardware is doing at the transistor level, so yeah, it expects that. That, and it was clearly written as a reference manual, not instruction manual -- yet was the only documentation at the time. I think it managed to confuse everyone trying to learn the hardware of the machine in at least one section. 1 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 2, 2021 Share Posted May 2, 2021 Indeed, it confused me at the point where it describes the PAD usage and the current row/column and character buffer bytes. This is only meaningful for GPL, however. I do remember, however, that I did not really believe them. Before I found some useful books later, I also learned assembly language by this binder. 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 2, 2021 Share Posted May 2, 2021 (edited) 9 hours ago, mizapf said: Indeed, it confused me at the point where it describes the PAD usage and the current row/column and character buffer bytes. This is only meaningful for GPL, however. I do remember, however, that I did not really believe them. Before I found some useful books later, I also learned assembly language by this binder. Yeah, I was particularly baffled by the description (or lack thereof) of "direct SOUND loading", particularly since it's one of the few sections of the manual that does not describe the hardware (or at least, it mixes hardware and software interfaces as sound lists as if they were one and the same), and by the CRU overall. Those row/column/character buffer bytes baffled me for years until I realized they were meant for GPL. It was all quite confusing to me until I found Compute's book... that made it all slide into place. Of course, I think it's been praised repeatedly in this thread. Conversely, I think it does a pretty good job at describing how to use the VDP, even though it completely omits some features. I actually transcribed large portions of it into a text file and gave to a friend in the ColecoVision community at the time, I still see that text floating around some FAQs... (for instance, here: http://colecoboxart.com/faq/FAQ05.htm) Edited May 2, 2021 by Tursi 1 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted May 3, 2021 Share Posted May 3, 2021 (edited) During my contacts with other TI users back in the 80's, I found that the CRU concept was one of the most magical to most beginners. The hardware dependencies, where you could output a bit at one offset and read it back at the same, but a bit at another offset you couldn't read back at the same offset, or not even at all, since that was all dependent on the circuitry it was connected to, that was difficult for many to graps. They were stuck in thinking about memory, where what you put in at one address reads back at the same address (or something is very wrong). Edited May 3, 2021 by apersson850 1 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 3, 2021 Share Posted May 3, 2021 1 hour ago, apersson850 said: During my contacts with other TI users back in the 80's, I found that the CRU concept was one of the most magical to most beginners. It still is to me! 1 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 3, 2021 Share Posted May 3, 2021 I always thought there was some unfathomable magic inside the 9901 - until I implemented it in MAME. 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted May 4, 2021 Share Posted May 4, 2021 Magic is in the smoke ? and pixel dust left behind if it worked like WE expect. Quote Link to comment Share on other sites More sharing options...
Airshack Posted May 20, 2021 Share Posted May 20, 2021 TOPIC: Smooth vs Coarse Scrolling Through this thread I have learned a methodology for “coarse” screen scrolling, both horizontal and vertical, by simply moving my pointer to my viewport origin in screen memory, and then clipping the viewport tiled display as necessary. Of course this produces fast and suitable scrolling for most games. Scrolling where objects move up or down at a rate of eight pixel positions at a time. Perfectly simple in the TI-99/4A since its character tiles are eight pixels/bits wide by eight pixels/bits tall. Recently, I’ve been reading about scrolling register’s on Atari’s famous ANTIC graphics chip. These vertical scroll and horizontal scrolling registers permit easy horizontal and vertical “smooth” scrolling. Scrolling screen contents at a rate of one pixel position at a time. Question: How on earth is smooth scrolling accomplished on the TI-99/4A with no scrolling registers in the 9918A VDP? I’m looking for a very high level explanation from you guys because this seems like wizardry to me. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 21, 2021 Share Posted May 21, 2021 (edited) 18 hours ago, Airshack said: TOPIC: Smooth vs Coarse Scrolling Through this thread I have learned a methodology for “coarse” screen scrolling, both horizontal and vertical, by simply moving my pointer to my viewport origin in screen memory, and then clipping the viewport tiled display as necessary. Of course this produces fast and suitable scrolling for most games. Scrolling where objects move up or down at a rate of eight pixel positions at a time. Perfectly simple in the TI-99/4A since its character tiles are eight pixels/bits wide by eight pixels/bits tall. Recently, I’ve been reading about scrolling register’s on Atari’s famous ANTIC graphics chip. These vertical scroll and horizontal scrolling registers permit easy horizontal and vertical “smooth” scrolling. Scrolling screen contents at a rate of one pixel position at a time. Question: How on earth is smooth scrolling accomplished on the TI-99/4A with no scrolling registers in the 9918A VDP? I’m looking for a very high level explanation from you guys because this seems like wizardry to me. Eight years ago I asked the same question ? There are some notes in post #17 or the Smooth scrolling thread that you should read first. Edited May 21, 2021 by Asmusr 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 21, 2021 Share Posted May 21, 2021 It's all about changing patterns. In it's simplest form, if you fill the screen with the same pattern, and shift that pattern in a cyclic way, the whole screen will scroll smoothly. Magallen contains tools and also some sample code for scroll scrolling. Quote Link to comment Share on other sites More sharing options...
Airshack Posted May 21, 2021 Share Posted May 21, 2021 13 hours ago, Asmusr said: It's all about changing patterns. In it's simplest form, if you fill the screen with the same pattern, and shift that pattern in a cyclic way, the whole screen will scroll smoothly. Thanks! I’ll be back to ask more after reading that thread. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 21, 2021 Share Posted May 21, 2021 34 minutes ago, Airshack said: Thanks! I’ll be back to ask more after reading that thread. Yes please do. Quote Link to comment Share on other sites More sharing options...
RXB Posted May 21, 2021 Share Posted May 21, 2021 CHALLENGE for the Assembly Experts on TI99/4A: Want to add a token to XB to allow for Integer math built into XB ROMs to considerably speed up XB execution speed. XBROMS.zip 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted May 22, 2021 Share Posted May 22, 2021 15 hours ago, RXB said: CHALLENGE for the Assembly Experts on TI99/4A: Want to add a token to XB to allow for Integer math built into XB ROMs to considerably speed up XB execution speed. XBROMS.zip 684.2 kB · 5 downloads Slightly off topic but a while back you mentioned that you want to maintain compatibility with XB. Is it a crazy idea to make a new RXBFast that uses only integer math? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 22, 2021 Share Posted May 22, 2021 How about writing a GPL to machine code compiler, and compile the XB GROMs into ROM banks? ? Quote Link to comment Share on other sites More sharing options...
RXB Posted May 22, 2021 Share Posted May 22, 2021 3 hours ago, TheBF said: Slightly off topic but a while back you mentioned that you want to maintain compatibility with XB. Is it a crazy idea to make a new RXBFast that uses only integer math? What is crazy about it? I provided the source and the source code is documented better then almost anything you ever see in Assembly! From GPL I can implement the Floating Point or Integer value before it is entered as XB code, what would work best is to have both in ROMs. As editor outputs the code (tokens and code) before it is saved with SAVE in XB this makes most sense. P.S. since when is ROM assembly off topic? 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 22, 2021 Share Posted May 22, 2021 2 hours ago, Asmusr said: How about writing a GPL to machine code compiler, and compile the XB GROMs into ROM banks? ? Do you mean convert GPL into Assembly? There are others that have attempted it and all of them are buggy as hell and are completely non backwards compatible with XB. A much better approach is mine that maintains 100% backward compatibility and adds a new feature of Integer math. I could add this same thing to 110 XB without much trouble. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 22, 2021 Share Posted May 22, 2021 1 hour ago, RXB said: Do you mean convert GPL into Assembly? There are others that have attempted it and all of them are buggy as hell and are completely non backwards compatible with XB. There is no inherent reason why this should be incompatible with XB. With enough memory and programming skill this would be possible. Quote Link to comment Share on other sites More sharing options...
RXB Posted May 22, 2021 Share Posted May 22, 2021 30 minutes ago, senior_falcon said: There is no inherent reason why this should be incompatible with XB. With enough memory and programming skill this would be possible. You offering to help me do this? GPL is my main talent though I can do Assembly I am not that talented at it. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 22, 2021 Share Posted May 22, 2021 The key to doing this is "programming skill". I don't have enough of it. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 23, 2021 Share Posted May 23, 2021 18 hours ago, RXB said: There are others that have attempted it and all of them are buggy as hell and are completely non backwards compatible with XB. Which ones are those? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.