home *** CD-ROM | disk | FTP | other *** search
/ Commodore Free 36 / Commodore_Free_Issue_36_2010_Commodore_Computer_Club.d64 / work < prev    next >
Text File  |  2023-02-26  |  7KB  |  240 lines
  1. u
  2.  
  3.  
  4. *************************************
  5.         Commodore At Work
  6.          Daniele Redivo
  7. *************************************
  8.  
  9. Introduction
  10.  
  11. In my job I take care of software
  12. configuration for big engines. The
  13. software has to control the engine,
  14. ensuring safe operation and the
  15. correct engine performance. The
  16. software acts much like a human when
  17. driving a car : when the driver wants
  18. to go faster, he just pushes the
  19. pedal deeper feeding more fuel to the
  20. engine, or when the car encounters a
  21. steep ramp, the driver has to push
  22. the pedal deeper in order to keep a
  23. constant speed . Instead of a driver,
  24. a big engine is controlled by
  25. electronic modules, that reading the
  26. speed and the load produced by the
  27. engine shaft, generate an output
  28. signal proportional to the needed
  29. fuel amount.
  30.  
  31. The idea of an engine simulator came
  32. in summer 2008. At that time I wanted
  33. to develop a tool for testing the
  34. engine software before it would be
  35. actually used on a real engine.
  36. Basically I wanted to have the engine
  37. control modules (ECMs, where the
  38. engine software is downloaded) on my
  39. desk and connect them to something
  40. that would simulate the engine
  41. behaviour, in terms of electrical
  42. signals. I needed three main things:
  43. a hardware interface for signal
  44. exchange with the engine control
  45. modules, a controller for the
  46. hardware interface and a software for
  47. the controller.
  48.  
  49. I thought that the controller could
  50. be a Commodore 64, I would prepare
  51. the software for it and also built
  52. the hardware interface.
  53.  
  54. First attempts
  55.  
  56. In summer 2008 I began doing some
  57. experiments with a Commodore 64 whose
  58. SID was removed. In this way I had
  59. free access to part of the address
  60. bus and the whole data bus,
  61. furthermore I had the read/write and
  62. chip select (for $d400) signals
  63. available. I had one read address for
  64. reading an analogue signal and one
  65. write address for 8 digital outputs.
  66. The analogue input was used for
  67. reading the fuel amount, one digital
  68. output was used for speed simulation
  69. (a square wave) and the other digital
  70. outputs for other signals to the
  71. ECMs. I packed the hardware interface
  72. all inside the C64 and it had a real
  73. nice looking. Unfortunately, I soon
  74. realized that the all-inside solution
  75. was not expandable at all. The more I
  76. went on testing engine control
  77. software, the more signals and
  78. functionalities I needed to simulate.
  79. So I thought I needed something very
  80. flexible, something that would not
  81. require to be re-built in case I
  82. needed further expansion. It came
  83. obvious that the expansion port was
  84. the way to go and that the SID could
  85. be put in its place, producing the
  86. awesome music it had always produced.
  87. After all I hated to have a silent
  88. C64!
  89.  
  90. Towards an expandable system: the
  91. opto interface cards
  92.  
  93. In January 2009 I started studying
  94. the expansion port signals and
  95. various datasheets of the available
  96. components on the market. First of
  97. all I built two cards for opto
  98. isolation between the C64 and the
  99. interface hardware: one for signal
  100. from the C64 to the external hardware
  101. and one for the other way around.
  102. Each card is dedicated to reproduce
  103. the 8-bit data bus and part of the
  104. address bus across the opto couplers.
  105. Then the data bus and the address bus
  106. signals are routed through four (two
  107. for each read/write card) ribbon
  108. cables to the other cards of the
  109. interface hardware. In this way the
  110. opto isolators ensure a safe
  111. operation of the C64, any electrical
  112. trouble on the interface hardware
  113. will not affect the C64, also because
  114. the digital part of the C64 works at
  115. 0-5V, the interface hardware cards
  116. have several voltages (-5v, 0V, 5V,
  117. 15V and 24V). Since there are several
  118. opto isolators (and these draw a lot
  119. of current) I use a C128 power supply
  120. (but I am planning on building my own
  121. heavy duty PSU).
  122.  
  123. The input/output cards
  124.  
  125. The other cards I built are dedicated
  126. to:
  127.  
  128. - 3 channels of 4-20mA output with
  129. 8-bit resolution
  130. - 4 x 8 channels of digital outputs
  131. 0-24V
  132. - 2 frequency channels with square
  133. wave output 0-15V (range 0- < 4MHz),
  134. 16-bit resolution
  135. - 4 channels for 4-20mA reading with
  136. 8-bit resolution
  137.  
  138. The 4-20mA output channels are used
  139. for analogue signal generation, for
  140. example the load signal.
  141.  
  142. The digital outputs are used for
  143. enabling certain states inside the
  144. ECMs, for example the start and stop
  145. signals. The frequency outputs are
  146. used for speed generation. There is a
  147. big difference with the first attempt
  148. I made. There the speed was generated
  149. using a digital output controlled
  150. totally by the C64, using a NMI for
  151. toggling the digital output high/low
  152. state. Now the C64 sends a 16-bit (2
  153. bytes) value, which is the number of
  154. cycles the card has to count before
  155. it toggles the output. The card has a
  156. 4MHz crystal clock onboard and acts
  157. much like a CIA timer. I added a
  158. feature so that the 16-bit value is
  159. not sent to the card counters until
  160. the low byte is written. So a write
  161. to it would be:
  162.  
  163.   lda Hbyte
  164.   sta $de17 ;counters still have the
  165.             ;previous reference value
  166.   lda Lbyte
  167.   sta $de18 ;now the new 16-bit is
  168.             ;sent to the counters
  169.  
  170. This avoids overlapping between old
  171. and new bytes in frequency generation
  172. when writing a new value. Also, I
  173. built it so that in case the 16-bit
  174. value is zero the frequency is
  175. infinite (for simulating zero speed).
  176. The frequency cards are very useful
  177. for generating independent frequency
  178. signals and also for not keeping the
  179. C64 busy with the NMI when toggling
  180. the digital output. The 4-20mA
  181. reading card is used for reading
  182. analogue signals from the ECMs, for
  183. example the fuel amount signal. Each
  184. card has a custom burned EPROM (using
  185. the C64 EPROM burner, what a nice
  186. tool!) used for address bus decoding.
  187. I used the 27c512, which provides 8
  188. chip-select signals per card. Each
  189. chip-select goes to a channel output
  190. and enables its latches for either
  191. reading or writing, except for the
  192. frequency channels, which need two
  193. chip select signals per channel
  194. (16-bit resolution, thus 2 bytes).
  195.  
  196. The software part
  197.  
  198. The software has also gone under big
  199. changes and developments. I
  200. originally wrote the software in
  201. assembler for time critical parts and
  202. used BASIC for monitoring what was
  203. going on inside the assembler part,
  204. by PEEKing and POKEing. For this
  205. purpose, BASIC has proved to be
  206. excellent! With BASIC I could just
  207. write a line with a conversion
  208. formula between the 16-bit word sent
  209. to the frequency output and the
  210. engine speed in rpm and get an
  211. immediate result on the screen! But
  212. for time critical stuff BASIC is just
  213. too slow and cannot trigger routines
  214. at a given instant. At the moment the
  215. assembler part of software does a
  216. lot. There are several interrupts
  217. active:
  218.  
  219. - some $d012 raster interrupt for
  220.   splitting the screen for nice
  221.   visualization of the speeds
  222.  
  223. - a CIA 1 interrupt at 50Hz for
  224.   reading the keyboard and doing the
  225.   math calculations
  226.  
  227. - BASIC program running in the
  228.   background
  229.  
  230. The engine model implemented in the
  231. software, takes care not only of the
  232. engine itself but also of the
  233. electrical generator usually coupled
  234. with these big engines. Then the
  235. engine model can simulate two engines
  236. running in parallel and feeding the
  237. same electrical network.
  238.  
  239. =====================================
  240.