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

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