home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / m6809 / 382 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  3.8 KB
  1. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!rpi!uwm.edu!psuvax1!rutgers!bobsbox.rent.com!s4mjs!kc2wz!bob
  2. From: bob@kc2wz.bubble.org (Bob Billson)
  3. Newsgroups: comp.sys.m6809
  4. Subject: Re: Weird problem with OS-9 ASM -- help
  5. Message-ID: <121@kc2wz.bubble.org>
  6. Date: 24 Aug 92 18:49:17 GMT
  7. References: <1992Aug22.151632.29645@kocrsv01.delcoelect.com> <116@kc2wz.bubble.org>
  8. Distribution: na
  9. Organization: Color Computer 3: Tandy's 'game' machine
  10. Lines: 84
  11.  
  12. c23vgs@kocrsv01.delcoelect.com (Victor Sperry) says:
  13. >
  14. >In article <116@kc2wz.bubble.org>, bob@kc2wz.bubble.org (Bob Billson) writes:
  15. >> Question for the net.  I am using the OS-9 Level I assember ASM in the Motorola
  16. >> compatible mode.  The code will eventually be burned into an EPROM to run on a
  17. >> single board 6809 computer.
  18. >> 
  19. >> For some reason the RMB pseudo-op is not reserving a block of empty bytes
  20. >> at the end of the code.  Here is the editted output of ASM.  The deleted
  21. >> code is unimportant as far as the problem goes.
  22. >> 
  23. >
  24. >[stuff deleted]
  25. >
  26. >> 
  27. >> 00579        *
  28. >> 00580        * last 16 bytes in EPROM have to be $E000
  29. >> 00581        *
  30. >> 00582        
  31. >> 00583   0440                     rmb   epromsiz-(endprgm-start)-16 
  32. >> 00584        
  33. >> 
  34. >
  35. >Try this instead of using RMB.
  36. >
  37. >      org  $1ff0
  38.  
  39. I tried this with the same result.  Actually I tried this originally and when
  40. it didn't work I tried the above.
  41.  
  42. >> Notice bytes seem to have been reserved as the address counter is incremented
  43. >> properly.  However, dump the resulting file shows this is not the case.
  44. >> 
  45. >> 00585   1FF0 E000                fdb   $e000 
  46. >> 00586   1FF2 E000                fdb   $e000 
  47. >> 00587   1FF4 E000                fdb   $e000 
  48. >> 00588   1FF6 E000                fdb   $e000 
  49. >> 00589   1FF8 E000                fdb   $e000 
  50. >> 00590   1FFA E000                fdb   $e000 
  51. >> 00591   1FFC E000                fdb   $e000 
  52. >> 00592   1FFE E000                fdb   $e000 
  53. >> 00593                            end
  54. >> 
  55. >
  56. >[stuff deleted]
  57. >
  58. >> 
  59. >> Starting at $043E, there should be a large chuck of reserved bytes.  Instead
  60. >> there are two bytes immediately followed by the $E000 bytes.  Why isn't the 
  61. >> assembler reserved the block of bytes?
  62. >> 
  63. >> Anyone point out what I am doing wrong?  Thanks for the help.
  64. >
  65. >
  66. >Since your listing showed the vectors being placed at $1ff0 but the raw byte
  67. >dump program showed them at $0440, you have a problem with one of the two
  68. >tools (assembler or dump tool). I assume you got into this detail because the
  69. >code didn't work, hence the assembler is probably wrong, not the dumper.
  70.  
  71. No the dump utility is okay.  The assembler lines at the end say that slightly
  72. over 1K of code was generated, which should not be the case.  The dump merely
  73. confirmed this.
  74.  
  75. >The only thing I can point out is that the "RMB" instruction is intended to
  76. >reserve RAM, not EPROM, so you should probably use an "ORG" anyway (see above),
  77. >but the inconsistency between the listing and the generated code does look
  78. >like an assembler problem.
  79. >
  80. >Alternatively, many assemblers have some sort of "form constant BLOCK" (as
  81. >opposed to "form constant BYTE") pseudo instruction which can be used to
  82. >form a large block of constant-valued ROM. So you might be able to use:
  83. >
  84. > 00583   0440                     blk   $ff,epromsiz-(endprgm-start)-16
  85. >
  86. >to stick $ff's in EPROM. This will probably make your output file (.PTP is
  87. >what mine would be) much larger, though.
  88.  
  89. Hmm...I'm not sure if the OS-9 assembler I have will support this, but
  90. I'll investigate it.  Thanks.
  91. -- 
  92.   Bob Billson, KC2WZ                          | internet: bob@kc2wz.bubble.org
  93.                                               |           kc2wz@amsat.org
  94.   $nail:  21 Bates Way,  Westfield, NJ 07090  | uucp:     ...!uunet!kc2wz!bob
  95.                   C code.  C code run.  Run code run...<please!>
  96.