home *** CD-ROM | disk | FTP | other *** search
/ The CDPD Public Domain Collection for CDTV 3 / CDPDIII.bin / pd / programming / assembler / thesource / volume1 / source / system / bpd.lha / README < prev   
Encoding:
Text File  |  1991-03-15  |  2.0 KB  |  56 lines
  1.        Hi there.  Here's a little goodie I concocted to make my EuroTesting
  2. a bit easier.  It's called BPD, and it causes your system to come up in true
  3. PAL mode when you reboot.
  4.  
  5.        No, I am not trying to ape Nico Francois.  The fact that we happen
  6. to write substantially the same program at the same time is pure coincidence.
  7. Honest.  (I will confess that I added the NTSC option after having seen his
  8. program, and deciding that doing NTSC was a good idea, too.)
  9.  
  10.        I hope you like it.
  11.  
  12.                                        Schwab
  13.  
  14. ----------------
  15.                          Why BPD is better than:
  16.  
  17. PALBoot
  18. -------
  19.  
  20.        PALBoot writes a custom boot block to a floppy, which flips the PAL
  21. bit in the ECS Agnus chip.
  22.  
  23.        Boot blocks are executed by the system strap module, which is the
  24. last thing to happen in the system configuration cycle.  Thus, all PALBoot
  25. buys you is a 50Hz VBlank rate.  The rest of the system still reports it's in
  26. NTSC mode.
  27.  
  28. GoPAL
  29. -----
  30.  
  31.        GoPAL is a CLI command that flips the PAL bit in the ECS Agnus chip.
  32.  
  33.        GoPAL suffers from the same shortcomings as PALBoot:  The chip is the
  34. only thing touched.  None of the system variables are updated to tell
  35. software it's running under PAL rates.
  36.  
  37. BootPAL
  38. -------
  39.  
  40.        BootPAL installs a resident ROMTag which survives reboot and
  41. executes as part of the boot sequence.  Upon reboot, it flips the PAL bit in
  42. the ECS Agnus chip, and updates various system variables.
  43.  
  44.        This is much better than the previous two.  However, the ROMTag
  45. priority is set too low, which means that the boot code executes long after
  46. graphics has configured itself.  So the program resorts to poking system
  47. variables itself.  Apart from the fact that this is philosophically
  48. incorrect, it is impossible to know all the fields that need to be changed,
  49. or their correct values.
  50.  
  51.        It also appears to remove itself improperly, which could trash other
  52. resident ROMTag goodies (like RAD:) depending on the order in which you
  53. invoked things.
  54.  
  55.        It's also 100 bytes bigger than mine :-).
  56.