Jump to content

Code change to enable SAM LE driver board support


DJRobX

Recommended Posts

  • Replies 856
  • Created
  • Last Reply

Well, I isolated a value in memory that's the source of the delay getting the stream started.   So now I can start the stream immediately by fiddling one byte in memory.   It's in a rather strange block of code that seems to be following a linked list of objects.  If it encounters a "62" anywhere in the list, it stops and doesn't send the data.    That 62 is set early on, in an equally strange section of code.  

So far, there's no indication that it's actually trying to read anything from the port.   It doesn't set the flag to be notified when data comes in, and I don't see anything trying to read the channel status outside of the transmit handler.    

So the good news is I can now provide a solution that gets us the LED data we're after, even if it's not a perfect simulation of the hardware,   That location in memory is almost certainly ROM-version specific though, so it would likely need to be updated for each specific game code.   I'm still going to try and figure out what it's trying to do, to avoid the hack.   

I also need to figure out how to make this data available to VP.   This is a full byte per LED, probably different intensity levels and/or colors.    I can stuff it into the regular LED matrix (80+) as on/off values, but we would be missing out on the full light show.  

*Edit* Interestingly, Star trek LE doesn't need this hack.  It just starts sending data right away! 

 

 

 

Link to comment
Share on other sites

from my limited understanding of the lamp code, couldn't one just pimp the get_ChangedLamps() and get_ChangedLampsState() for example to return bytes instead of just 0 or 1?

then you would 'just' need to have a different struct in addition to the lampMatrix in core_tGlobals that has support for RGB or something.

if you need more help with the core, please let me know.

Link to comment
Share on other sites

Awesome, thank you Toxie!

I haven't gotten as far as to look into my VP communication options, so thank you for your support and the head start.   :)

With Star Trek, the output is more complex, but it's sensible:  The 3 byte header (85,41,80) that's the same on every Mustang light update, now rotates between 4 different "row" values (85-88).   I believe each one targets a different LED controller board.   So I'll just have to figure out a numbering scheme that makes sense .. probably (LED 80+((Row-85)*40)+Column, but just keep in mind that makes Star Trek a total of 160 LED targets on that one in addition to the standard ones.  

Looking at the activity when going through the diag menu, it looks like star trek typically lights up 3 lamps per "single lamp test"  (probably R,G,B values) but it's not necessarily an obvious 1:1 mapping. ("Light 1" is on row 85, columns 2,3,4.   "Light 2" is on row 85, columns 1,5 and 6.   That is something handleable at the table level though. 

I'll try to get an "Alpha" out soon so people can start playing with it.   

 

 

Link to comment
Share on other sites

Excellent.   Thanks!    Your change was extremely helpful.   

I changed the lamp type to UINT8 instead of UINT32.   SAM sends intensity levels for individual elements.  In the case of Mustang LE, each one only represents one monochromatic "lamp".    For Star Trek, it turns on 3 of them at a time.    So I only need an 8 bit value to store the intensity level of the lamp, and it will be up to the table to "blend" them into RGB values (as we do currently in Tron).  

I set the max to 260 - that's the count of elements sent by Star Trek.  :o

I've got a build now complete with everything wired up in theory.   The next step is build a table and script to test this in VP.   Anyone know a quick way to create a dummy table with 340 lamps (260+the SAM base of 80 regular bulbs)?!?  

Link to comment
Share on other sites

To quote Austin Powers: Yeah baby!!  Verrrrry good!!

Thanks GTXJoe and Toxie!    I'm so glad I asked, I think you both just saved me about a week or more of work. :)

Seems to be working quite well.   Very exciting to see it lighting up lights this way instead of looking at rolling hex numbers in logs.    

Screen Shot 2016-09-17 at 8.49.50 AM.png

Link to comment
Share on other sites

  • Content Provider

Totally willing to modify Star Trek for this when you're ready. It's a minor change, I already have clear inserts for the playfield I can switch to and get RGB playfield lighting working. Switching the ramps is easy enough as well and scripting the ship movement and anything else needed is only a minor change

Link to comment
Share on other sites

  • Administrators
2 hours ago, freneticamnesic said:

Totally willing to modify Star Trek for this when you're ready. It's a minor change, I already have clear inserts for the playfield I can switch to and get RGB playfield lighting working. Switching the ramps is easy enough as well and scripting the ship movement and anything else needed is only a minor change

Awesome, looking forward to seeing it.

Link to comment
Share on other sites

2 minutes ago, arngrim said:

great great, what about the solenoid that didn't work yet on the LE?

All 12 additional solenoids are working on all LE roms.    That was the first thing I fixed, you can check it out in the build CarnyPriest posted earlier in the thread.    Do note, however, the LE solenoids will be on higher numbers in the next build.    The original code I posted was kind of "sharing" the solenoid numbers with reserved IDs for WPC upper flippers.   I found the correct way to do additional solenoids in VPM, which puts them at ID 48+.   I confirmed they work correctly with GTXJoe's test table which nicely has indicators for that also. :)

 

 

 

Link to comment
Share on other sites

I'm attaching a VPM build here so Fren can get started if he wants to.    It includes a slightly modified version of GTXJoe's test table that's fully working with both solenoids and LEDs.      Star Trek and Mustang seem to work fine.    Walking Dead LE has the same need for a hack to get the flow of data started, and has a slightly different output format that I need to account for.    But this won't change the output of Star Trek, so it's safe to start building a table against this version. 

 

VPM LE Alpha Build.zip

Link to comment
Share on other sites

  • Content Provider

I feel pretty dumb. I spent a good 3-4 hours working on the lights and couldn't figure out how they worked. It wasn't making sense. I was reading lampstate(ii) as either a 1 or a 0.... til I figured out what the debug.print from the rom test table was telling me. THE god damn RGB values! It wasn't just on/off, it was intensity/off so you get 255 levels of intensity, which is how it blends the colors. Anyways, stupid. I would have made more progress if I figured that out earlier. I guess I'm not entirely observant.

From what I can tell, everything is working so I feel safe proceeding... MOST of the lamps when you go into maintenance and do a lamp test appear to show rgb in color. So for instance, left ramp emblem lights up 84-85-86 which appears to be r-g-b, but some lamps aren't in the r-g-b order

Here's the lamp list I sorted out, lamps in bold are the ones with the RGB out of order, and order corrected in brackets.

Quote

#1 left ramp emblem: 84 85 86
#2 red target 2: 81 87 88
#3 left ramp enterprise arrow: 82 83 89 (83 82 89)
#4 red target 3: 90 91 92 (92 91 90)
#5 center lane emblem: 93 94 95
#6 center lane enterprise arrow: 96 97 98
#7 red target 4: 99 100 101
#8 black hole arrow: 102 103 104
#9 right orbit emblem: 113 114 115
#10 right orbit enterprise arrow: 116 117 118
#11 red target 6: 119 120 121
#12 right ramp emblem: 122 123 124
#13 right ramp enterprise arrow: 125 126 127
#14 red target 5: 128 129 130
#15 special: 131 132 133 (131 133 132)
#16 away team: 134 135 136 (134 136 135)

#17 left eject lock: 146 147 148
#18 mission start: 149 150 151
#19 left 2 bank (top): 152 153 154
#20 left orbit emblem: 155 156 157
#21 red target 1: 158 159 160
#22 left orbit enterprise arrow: 161 162 163
#23 left 2 bank (bottom): 164 165 166
#24 left eject emblem: 167 168 169
#25 left eject enterprise arrow: 170 171 172
#26 kickback: 177 178 179
#27 (t)rek: 180 181 182 (182 180 181)
#28 t(r)ek: 183 184 185 (185 183 184)
#29 center 3 bank (bottom): 186 187 188
#30 center 3 bank (center): 189 190 191
#31 center 3 bank (top): 192 193 194
#32 center lane lock: 195 196 197 (195 197 196)
#33 extra ball: 198 199 200 (198 200 199)

#34 shoot again: 214 215 216
#35 the captain's chair: 211 217 218
#36 save the enterprise: 212 213 219 (213 212 219)
#37 nero: 220 221 222 (222 221 220)

#38 destroy the drill: 223 224 225
#39 space jump: 226 227 228
#40 prime directive: 229 230 231
#41 klingon battle: 232 233 234
#42 status 1 (bottom): 235 236 237
#43 status 2: 238 239 240
#44 status 3: 241 242 243
#45 status 4: 244 245 246
#46 status 5: 247 248 249
#47 status 6: 250 251 252
#48 status 7: 253 254 255
#49 status 8 (top): 256 257 258
#50 warp ramp red: 276
#51 enterprise: 277 (color???)
#52 warp ramp emblem: 278 279 280
#53 (beam) me up: 281 282 283
#54 beam (me) up: 284 285 286
#55 beam me (up): 287 288 289
#56 vengeance saucer: 290 (color???)
#57 veangeance nacelles: 291 (color???)
#58 right 3 bank (top): 308 309 310
#59 right 3 bank (center): 311 312 313
#60 right 3 bank (bottom): 314 315 316
#61 tr(e)k: 317 318 319 (317 319 318)
#62 tre(k): 320 321 322 (320 322 321)

#63 left apron: 300 301 302
#64 right apron: 303 304 305
#65 start button: 80
#66 fire (red): 78
#67 fire (green): 77
#68 fire (blue): 76
#69 tournament start button: 79
#70 warp chaser 1: 295
#71 warp chaser 2: 292
#72 warp chaser 3: 293
#73 warp chaser 4: 294
#74 warp chaser 5: 299
#75 warp chaser 6: 296
#76 warp chaser 7: 297
#77 warp chaser 8: 798
#78 cabinet side enterprise (x2): 50
#79 cabinet side phaser 1 (x2) (front): 51
#80 cabinet side phaser 2 (x2): 52
#81 cabinet side phaser 2 (x2): 53
#82 cabinet side phaser 2 (x2): 54
#82 cabinet side phaser 2 (x2): 55
#84 cabinet side phaser 2 (x2): 56
#85 cabinet side phaser 2 (x2): 57
#86 cabinet side phaser 2 (x2): 58
#87 cabinet side phaser 2 (x2): 59
#88 cabinet side phaser 2 (x2): 60
#89 cabinet side phaser 2 (x2): 61
#90 cabinet side phaser 2 (x2): 62
#91 cabinet side phaser 2 (x2): 63
#92 cabinet side phaser 2 (x2): 64
#93 cabinet side phaser 2 (x2): 65
#94 cabinet side phaser 2 (x2): 66
#95 cabinet side phaser 2 (x2): 67
#96 cabinet side phaser 2 (x2): 68
#97 cabinet side phaser 2 (x2): 69
#98 cabinet side phaser 2 (x2): 70
#99 cabinet side phaser 2 (x2): 71
#100 cabinet side phaser 2 (x2) (back): 72

Here's a quick attract mode video after I sorted the lamps out

Really amazing work DJRobX and everyone else who has contributed solutions - this is what we needed

Link to comment
Share on other sites

OMFG that looks amazing Fren!

Sorry if I didn't make the lamp intensity situation clearer.   The test table only has on/off lamps so it doesn't really exercise that aspect of things.  The test mode seems to mostly light up things white (7f,7f,7f).   But I knew the intensity levels were there in attract mode from my hex dumps.   And yes there's no clear "RGB" order.   The very first ones(#1, #2) has one set of RGB values wrapped inside the the other!

Making some progress on the whole "need to hack" front.   I've gotten a request to also enable the second serial port (the physical serial port you see on a SAM board).   This is to eventually enable color DMD support.      In futzing with that I've finally determined how to coax the ROM to assign a receive pointer, so it's able to receive response code from the LED array.    Star Trek doesn't seem to care about this, so it doesn't affect it.    

Next up: Implement receive handling (partially done), and determine the response the ROM is actually looking for. 

You can continue to use the build I posted for Star Trek and Mustang.    I've modified the code to support Walking Dead LE's output, but the hack isn't as simple, so I'd rather figure out how to eliminate the need for the hack altogether.

I haven't seen it output anything for Metallica.   ACDC LE behaves this way also .   I think in all cases once I close the receive loop things will start working smoother.  

Link to comment
Share on other sites

  • Content Provider

Hell yea. And you made it perfectly clear, I looked at the debug window twenty times before it clicked. Anyone else would have realized what was happening right away. Didn't get to work on it tonight since I had a concert. I'll get it up and running this week through and try to get a functional table up by the weekend. I'm not as familiar with mustang so I probably won't touch that. I also don't like mustang but that's beside the point

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...