Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral
  1. Hey, no problem at all. I'm happy to help. In my 40 year career (thus far), about 25 years is in embedded systems, on many different CPU platforms (Z80, 8088, 6809, 6502, 80186, AVR, ARM, HC11, MicroBlaze, etc.) I have written many PC and cloud apps in various languages (and created several custom languages), but I like small-platform embedded stuff the best, because I like having control of the entire machine, and figuring out how to do things with limited resources. That's why this Commander X16 project interests me. It brings back good memories!
  2. Absolutely. I was just showing the generic way to do MOD when not having the operator available. I totally agree to using AND whenever possible. Thanks for highlighting that. I have always enjoyed doing bit-fiddling stuff, so I truly get into the AND, OR, NOT, XOR, etc. side of things. I once wrote the entire windowing system for a touch-screen based printer. After writing all of the window operations and window message handling in C++, including per-pixel transparency of overlapping windows, I decided that it was just too slow. So I rewrote the "blitter" operations in ARM assembly language, and (WOW) what a difference in speed!
  3. Greg, thanks for helping to clarify the point that I was making! Johan, I think you now understand that I know how BNE works (tests for zero, not for odd/even).
  4. Yeah, I was surprised by the comment, too, because I "grew up" on the Motorola 6809E in the Color Computer, which not only has a hardware multiply instruction, but also 4 index registers (X, Y, U, and S). The auto-incrementing made memory-to-memory copies a breeze.
  5. Back when I used to program an 8-bit home machine, I would use the following for MOD: a mod b === a - int(a/b) * b Example: 10 A = 111 20 B = 4 30 M = A - INT(A/B) * B 40 PRINT M This will print a value of 3.
  6. I realize that you determined a better way to do things (i.e., to use double buffering), but I was wondering whether you got a chance to see my comment about your sample code, and the "bne/inc" instruction pair. Do you agree with my evaluation?
  7. Just for kicks, I was reviewing the code snippet that you provided in your question, as a way to brush the cobwebs off of my ancient 6502 thinking. Please correct me if I am wrong, but if the location of the tile buffer is on an even memory address (lower bit is zero), then the first "bne +" instruction can be omitted, since it would always branch. Along with that, you would remove the "inc ZP1", because it would never be executed. Doing this would save 4 clock cycles in every inner loop (multiplied by 16 and then by 21). If I am correct, you can save 1344 clock cycles just by removing that "bne" instruction. Do you agree, or are my cobwebs still too thick?
  • Create New...

Important Information

Please review our Terms of Use