Jump to content
IGNORED

Assembly on the 99/4A


matthew180

Recommended Posts

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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. ;)

 

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. ;)

 

  • Like 1
  • Haha 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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 by Tursi
  • Like 1
Link to comment
Share on other sites

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 by apersson850
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 3 weeks later...

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.

  • Like 1
Link to comment
Share on other sites

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 by Asmusr
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...