Example 8 Rebound

Introduction

If you are the author, please get in contact with me so that I may properly credit you.

It seemed, to me, to be a perfect project for conversion to assembler for several reasons:

• It is a 'whole' application in it's own right, and it isn't too large.
   
  
• It allows us to branch out into floating point mathematics instructions.
   
  
• And, it is totally frivolous!

I won't detail the internal workings, as it is commented to distraction. :-)

Improvements

• Seeds the randomiser (always useful!)
   
  
• Restores the original state of the redefined character, upon exit.
   
  
• Better (ie, controlled) exit handler
   
  
• Contrains the length of the high score name, so user can't output a long name and really mess up the layout.
   
  
• Floating point now done natively on the floating point co-processor.
  As Angel once said, "Works in theory!" - most of you will be using the FPEmulator. :-)
  Uses IEEE single precision floating point so should not be that slow.
  Still, faster than BASIC.
   
  
• Timed delay loop, so game should work at roughly the same speed on ALL RISC OS machines, irrespective of processor or memory speed, refresh rate, or cache.
   
  
• Doesn't do anything 'funny', so should work on any RISC OS machine with FPEmulator loaded - RISC OS 2 to RISC OS 4, any processor.
   
  
• Provides a default name if user doesn't bother to enter anything.
   
  
• At the "SPACE for another game" prompt, it will take anything not Space as a request to exit.
   
  
• Switches the cursor back on when awaiting name input, to indicate that something is supposed to happen.
   
  
• Calls "Wimp_CommandWindow", so you don't get that "Press Space or click mouse to continue" prompt...

Comments

• Shift blocks to make better use of fall-through.
  For example:
  In .game_loop, BL to .draw_screen.
  After .draw_screen, move .border_commands elsewhere, then let it just fall into .game. Don't forget to fiddle the LDMFD/STMFD's to account for this.
   
  
• Turn all that "OS_BinaryToDecimal" stuff to a routine which can be called when needed.
  While you're at it, change it to use "OS_ConvertInteger4" and you should be able to use "OS_Write0" for the string, should save you another instruction there (no need to tell it how LONG the string is!).
   
  
• The character definition code. Push it all into .buffer, then use a looping LDRB to pass it to "OS_WriteC". It'll have the same effect, but look tidier. And, as .buffer is essentially workspace, it doesn't matter if it later gets overwritten...

The 1K challenge

Why 1K? Because it represents an amount of memory that was typical in early machines. Look in a computer book written in the late sixties. Mainframes did their work with tape drives and 4K of memory. It is a 'throwaway' amount these days, yet still a good challenge to code something useful, yet squeeze it into a mere 256 instructions (or less, if you have output to describe).

Last, but not least...