Jump to content
matthew180

Assembly on the 99/4A

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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
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!

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I always thought there was some unfathomable magic inside the 9901 - until I implemented it in MAME.

  • Like 2

Share this post


Link to post
Share on other sites

Magic is in the smoke 😂 and pixel dust left behind if it worked like WE expect.

Share this post


Link to post
Share on other sites

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

Share this post


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

Share this post


Link to post
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.

Share this post


Link to post
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. 

Share this post


Link to post
Share on other sites
34 minutes ago, Airshack said:

Thanks! I’ll be back to ask more after reading that thread. 

Yes please do.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
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?

Share this post


Link to post
Share on other sites

How about writing a GPL to machine code compiler, and compile the XB GROMs into ROM banks? 🙂

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
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.

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