I looked at Kerm's code and it appears that bcalls are mostly the same, too.

I did some other calculations in class and I have some good news The current LCDs are very slow and cause a big speed bottleneck for ASM games. At 6MHz, it takes about 55 t-states between LCD writes and at 15MHz it takes about 135. On the new LCDs, in a discussion with calc84maniac, I learned that every output/input to the LCD costs an extra 3 cycles. Even so, using the new screen is faster for most sprites at 15MHz. Before I learned about the 3-cycle cost, the routine was faster for every sprite that was 89-pixels wide or less (even faster as it got smaller, compared to doing it on an 84+). I think 16x16 sprites will be pretty popular to deal with the larger screen and because it gets a pretty decent speed boost.

What does this mean? Combined with the ability to shift the screen left/right with z-addressing, we could make some pretty fast side scrollers and having enemies on the screen shouldn't be too bad.

Also, people were talking about CaDan last night on IRC and the question of bullets was brought up. However, remember that with the old LCDs, we typically copied data to a buffer in RAM (the graph buffer) and then copied to the LCD. Then for bullets, we would use another buffer to store their locations. With the new calc, we will be copying directly to the LCD and we won't need to worry about LCD delays (except the 3-cycle thingy). So we could probably easily manage an average of 100 cycles  per bullet. That is less time than it would require to draw a byte to our current LCDs o.O This is great news for things like Grammer's particle engine because this means that it could handle the movement of 150000 particles per second. 150 000 ! Now I am starting to get excited

EDIT: Although, with each of the particles, it would probably take about 150 t-states to also compute collisions and choosing a direction to move, so that would actually be more like 60 000 particles per second. So 1000 particles could be handled at 60FPS with multiple colors

You mean applying monsters' decisiveness to guys of your team ? That effectively can be a good idea for total newbies.

Yes, precisely It shouldn't be that difficult if we already have the AI made.

Yeah, and if we have the monster AI created, we can give the user the option of setting some players to AI. This way new players who don't know what they are doing don't get destroyed early on.

If you know the width and height of the rectangle, you can see if W*H:=Line(X,Y,H,W,14

Well, on the one hand, I would estimate that drawing a 16x16 sprite will probably be at minimum 30x256 (256 pixels in all for a 16x16 sprite) t-states compared to about 2000 on the current calcs which is about 3.5 times slower on the new screen. Although, since it will be at 15MHz, it will probably be more like 1.5 times slower to draw to the screen.

However, now that I think about it, a 16x16 tile is 2000 cycles, but that doesn't account for byte-boundaries. Since we don't need to worry about that anymore, it might actually turn out to be a bit faster for sprite drawing. Plus, a lot of games that use grayscale will not need to have the LCD updated constantly since the screen supports gray and we can use double-buffering to get the most out of scrolling tilemaps (so we only update what we need to update).

Thanks for that information, this could be painful for decent graphics, but at least we know what we are. Too bad they are still clocked at 15MHz max Using an eZ80 would probably have been a better idea to at least take away the sluggish-ness. Did they at least allow key responses while updating the LCD, that way you don't have to wait for the whole screen to update to go to different menus? I mean, I type faster than 5FPS so being able to perform the computations faster than a calculator just because of a slow UI is kind of a turn-off.