What is a page boundary?

[+Random Terrain]

I need a "for dummies" definition that I can put on the batari Basic page. The title for it will either be "What Is a Page Boundary?" or "What Are Page Boundaries?" (whatever you think is best). If you can use words that the average 6th grader can understand, that would be great.


Thanks.



Update

It's on the bB page now:

What is a page boundary?

[RevEng]

Here's my attempt. The first 2 sentences lay down what a page boundary is. The third explains why a page boundary is a notable thing...

 

The 6502 CPU groups memory together into 256 byte pages. Where one page begins and the other ends is commonly referred to as a page boundary.

 

When accessing memory tables spread across a page boundary, the 6502 will use an extra cycle to reach over the boundary, so routines that must use a constant amount of time (like 2600 display kernels) need to ensure any memory tables they use don't cross a page boundary.

[+Random Terrain]

Here's my attempt. The first 2 sentences lay down what a page boundary is. The third explains why a page boundary is a notable thing...

 

The 6502 CPU groups memory together into 256 byte pages. Where one page begins and the other ends is commonly referred to as a page boundary.

 

When accessing memory tables spread across a page boundary, the 6502 will use an extra cycle to reach over the boundary, so routines that must use a constant amount of time (like 2600 display kernels) need to ensure any memory tables they use don't cross a page boundary.

Thanks. Since the Atari 2600 uses the 6507, should I try to fit that in there somewhere?

[RevEng]

No problem, and good point. Feel free to sub "6507" or "6502/6507" for "6502", whichever works better for you.

[+Random Terrain]

No problem, and good point. Feel free to sub "6507" or "6502/6507" for "6502", whichever works better for you.

Thanks. It's on the bB page now:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#bq_what_is_a_page_boundary

 

 

I'm going to make a new thread about cycles. Don't feel like you have to reply, but it will be great if you do.

[+SpiceWare]

It's easier to understand pages if you use hexadecimal addresses. In this blog entry I have this footnote:

 

items are on the same page when the high-byte of their addresses have the same value, so addresses $F100 and $F1FF are both on the same page while $F1FF and $F200 are on different pages.

[SeaGtGruff]

If you're going to talk about page boundaries-- which I think is a great idea-- then you should try to explain why programmers need to know about them and pay attention to them.

 

One importance is that when an indexed instruction or branch instruction crosses a page boundary, it adds 1 machine cycle to the instruction's execution time, which can interfere with the careful timing of a scan line display or other routine. Sometimes this could be used to advantage, such as if for some reason you need the instruction to take an extra cycle during a particular iteration of a loop. However, that is probably so rare and so difficult to manage (what with revising the program and so forth) that it's probably best to forget about entertaining such thoughts. ("This way lies madness!") More often you either try to position your data tables in memory such that they can be read via an indexed instruction without ever having to cross a page boundary, or-- if for some reason you can't or don't want to do that-- be very careful to compensate for the fact that the instruction will sometimes take an extra cycle. I seem to remember dealing with page-boundary crossings in my old "bitmap display" program for the 2600, although my memory is very hazy about that.

 

Another important fact related to page boundaries is that the 6502 processor and its kin (6507, etc.) had a famous bug in which an indirect JMP would end up jumping to the wrong address if the address in the instruction crossed a page boundary-- e.g., JMP ($10FF) is supposed to load the address that's stored at $10FF (lo byte) and $1100 (hi byte), but due to the bug it would actually read the hi byte of the JMP address from $1000 (i.e., in the same page as the lo byte of the address), with the result that the JMP jumps to the wrong place. To avoid this bug, 2-byte JMP addresses should always begin on even-numbered bytes so they don't cross a page boundary.

 

EDIT: I see RevEng already mentioned the extra instruction cycle; sorry for the repetition!

Edited March 24, 2016 by SeaGtGruff

[Nukey Shay]

Taking advantage of the added cycle is not so rare when you need to decide whether to branch over a 2-cycle instruction. That leaves either case at 4 cycles. Handy for display kernels when cycle time must be precise. And the indirect jump glitch really does not apply to the 2600 unless the program is calling it from some kind of extended ram. Easily avoidable in any case. IMO page boundries can be thought of just how it sounds...like reading from pages in a book. A sentence which begins on one page and ends on the next is crossing the pages...interrupting the reader. Just as it takes you a little extra time to physically turn the page to see the rest, the processor takes a little extra time to do it in memory.

[Mr SQL]

Pages are interesting and important with kernel design, but pages in general - boundries/direct/relocatable can all be rendered transparent in high level programming.

 

High level Assembly language programming is a streamlined approach to learning Assembly where it is not necessary or desirable to initially learn low level concepts like pages and cycle counting.

 

The Atariage e-book Learn Assembly in 8 Hours can help bB programmers master Assembly concepts more quickly by focusing first on high level programming like Batari BASIC, with examples showing how to use the Batari BASIC compiler to generate the Abstract Assembly.

There are many valid approaches to learning asm, this one just uses bB to accelerate the learning curve; instead of counting cycles you learn asm on the game grid, racing the beam on a lightcycle

 

It's been my experience that advanced programmers can benefit the most from an improved understanding of load balancing and optimizing program design and less focus on counting cycles/etc (at least anywhere else but in a kernel routine).

 

A good programming foundation is important and can't be overemphasized enough - more than 99% of the bottlenecks are always in less than 1% of the code and written by expert programmers for exactly this reason.