Assembly code Help! PIC16F57

[KL27x]

And previously KL27x said:
Quote from: KL27x on June 05, 2017, 11:27:50 am

Well, thanks Jpanhalt. This guy sounds like a fucking idiot!

but only if you are.
Well, I meant that this would be on you to take some initiate and break some eggs.

Example:

its this partial pattern2 on a win thing that i think really wrecks this.

To you this means something. You're the only one that knows what is supposed to happen. What this pattern2 thing manifests as? No one else even knows. Is it something displays on the 7 segments or the 8 LED thing or what?

If you wanted me to help, you have to describe what is supposed to happen, and what erroneously happens, how often, under what conditions, and you would have to describe it in super particular detail. Doe the pattern2 erroneously happen at the same time as what's normally supposed to happen. Does the regular function get put on hold and continue AFTER this half-pattern2 thing?

See, a video AND a schematic or pinout would perhaps be a good starting point. There's a ton of information that you have but no one else does. So either you need to learn to debug and write assembly, or you need to step up and start gathering and posting this information.

[Electrofinn]

OK allow me a little time to put this together and I will report back.

[Electrofinn]

Ok, I have here another video, this time from brett, the other dude that was involved in the project. His video illustrates perfectly what "pattern2" is doing.
"pattern2" and "pattern" for that matter are both for the 8 LED's only.

Firstly, a little about "pattern" and then "pattern2"...

0:31 into the video he switches the machine on and after approx 2 seconds "pattern" begins its LED sequence (you managed to sort this out already by getting it to run 32 values instead of 16) this is also the sequence that sometimes doesn't begin until 30-45sec after running out of credits. Its supposed to be approx 2 seconds after, as you can see at 0:58 into the video, it finishes paying out and he runs out of credits, then approx 2 seconds after, returns to its "pattern" sequence. Another interesting observation on my machine is that sometimes it doesn't always begin at the start of the "pattern" table. I took some video footage and slowed it down and managed to conclude that when it does begin in the wrong place, it begins on the 17th value (16th if counting from 0) which is 0DB. but if we never sort this out It wouldn't really bother me but it maybe that this and the next problem are somehow related. Now...

About pattern2...
         
0:50 into the video, watch what happens when he manages to get a win, which in this case he matches the first two reels (I provided a prize breakdown in an earlier post). As soon as the reels stop, it immediately begins it's "pattern2" LED sequence and is accompanied with a beeping sound, you see the LEDs start illuminating from the outside to the inside and from the inside to the outside, it does this twice (which is the complete "Pattern2" loop). Once the sequence is finished, the servo then begins to Payout the money.




As I've previously described, sometimes it does not do the full "pattern2" loop, we already know the complete loop is comprised of 16 hex values, which when converted to their binary equivalents, represents which of the 8 LEDs are lit and which aren't. the problem is that it sometimes will do just 1 frame (one value) of the sixteen, accompanied by 1 beep, or it'll sometimes do more of the loop accompanied by the same amount of beeping before stopping, in either case in does not complete the full loop. Note that the beeping is affected in the exactly the same way as the LED loop. Also note that after this partial loop is finished, the servo begins paying out as normal. An interesting observation is that it seems to be able to do a full loop more times than it fails to do it.


In the attached schematic, the LEDs are connected to RB0-RB7 of the Pic, pin numbers are also illustrated in the schematic. here is the two parts of the magazine article as it was published, which the attached schematic came from. I had to save the attached schematic at a lesser quality for it to allow me to upload but for a better quality version, download the following PDF files. schematic is in part 1.

Part 1

http://www.epemag.wimborne.co.uk/EPE_Fruit_Machine_part_1Dec94.pdf

part 2

http://www.epemag.wimborne.co.uk/EPE_Fruit_Machine_part_2Jan95.pdf
 
Note that I am currently using your last asm, Fruit machine v21 beta.

I think problem for me is that while I find programming interesting and I like to try and learn, I think my interests lay in classical electronics and project building and for me to complete this project in any meaningful amount of time it's obvious to me that I am going to need some help with this. I have tried hard to go away and work on this myself and I'm failing miserably and Not that I wanted to disclose this on here but I suffer with a mood disorder and I'm finding the concentration and patience needed for this a little beyond me, but at the same time I don't want be a failure and I don't want to just give up on this project, I have come so far.
 


         

[KL27x]

Another interesting observation on my machine is that sometimes it doesn't always begin at the start of the "pattern" table. I took some video footage and slowed it down and managed to conclude that when it does begin in the wrong place, it begins on the 17th value (16th if counting from 0) which is 0DB.

This is because of bit zero of new_byte. There is no provision in the program to clear this bit. So if you put a coin in while the pattern is in the second half of the pattern, it will remember this the next time pattern starts being called. If this is undesirable, you just have to put a  "bcf new_byte,0" in the program somewhere which won't happen while pattern is being called, like when a coin is detected.

The schematic and the video are going to be useful. When I get some free time I'll add the pinout to the header file and along with the video this will give me some frame of reference.

So it might be awhile, days, maybe weeks. I'm not retired. But the next time I post I suspect I will have either have some answers and/or I'll have some tasks for you to perform using a test code.

In the meantime:
Questions
1. What happens when you put in more than 1 coin? i don't see a display for how many coins you have put in.
    Is there any provision for this? Or are you supposed to only put in 1 coin for each spin? What happens when you drop another before hitting the spin button?

2. What is the maximum win? And do they all produce the same result other than number of servo/coin drops? Run pattern 2 on the LED a few times with the beeping, and then start dropping coins. Then after done, 2 seconds later, back to "state zero" with pattern running on the LEDs and waiting for user to insert a coin?

I imagine the most likely cause of this problem is that he has more than 2 subroutines going at the same time and messing with mode_byte,7 and using the same counter... the one that counts the number of times pattern2 is called before turning itself off. So I imagine the easy fix (if there is one) will be simply using a new register for this counter in the routine that calls pattern2, because we have at least one unused register available.

OR the routine that calls pattern2 is being turned off, prematurely, by something else. Via the pertinent mode_byte bit.

The super long delay that sometimes occurs before pattern comes on after a win/loss.. ... it might be a missed zero check, because some other subroutine has also inc/dec'd a counter, so that counter rolls over while the routine is not looking. But we have to find what is responsible for that delay, and label "timeout" is the obvious suspect, just from memory. If you had time to mess with this to verify, for instance, you could try to make the delay much much shorter by looking at and changing timeout and seeing if that makes the 2 second delay into a split second delay. The highest order counter is the one you would want to mess with... There would be two levels of counter. Again, just from memory. I don't know what counters are used in timeout, and this is just a verification/ruleout.

[Electrofinn]

1. What happens when you put in more than 1 coin? i don't see a display for how many coins you have put in.
    Is there any provision for this? Or are you supposed to only put in 1 coin for each spin? What happens when you drop another before hitting the spin button?

Here is another video of bretts that should clear this up even further, its only 1:40 long, but it shows him playing the machine. It looks like his first LED is broken in this vid so ignore that but you see as he puts coins in that the credits are registered and displayed with the same LEDs, even whilst he is playing.

 

What is the maximum win? And do they all produce the same result other than number of servo/coin drops? Run pattern 2 on the LED a few times with the beeping, and then start dropping coins.

Maxiumum win is £1.00 which is all bars "- - -" 20x 5p. he wins a jackpot in the video. The LED sequence and beeping is the same for all wins and yes it then starts dropping coins after the sequence.

Then after done, 2 seconds later, back to "state zero" with pattern running on the LEDs and waiting for user to insert a coin?

Yes that is correct.


   

[KL27x]

Ok, still haven't looked at the code.

So the machine counts how many coins you put in, but there's no display of this? Just a green light on the spin button as long as the count of coins is higher than zero?

Is there something special that happens when there are 8 or more coins in there? The code checks for this in one part, and I find it to be curious.

[Ian.M]

The articles said the max credit is £12.75 (255 x 5p), and the first eight 5p credits are displayed on the pattern LEDs when a pattern isn't running.

I was slightly surprised that a NE556 controlled by a logic level was used for the servo pulse generation.  Without searching through the code for that, I was expecting that to be interleaved with the display multiplexing code.   A modern reimplementation on any PIC with a 16 bit Timer 1 and a CCP module wouldn't need the NE556 as it could generate a stable servo pulse with hardware edge timing directly.

[Electrofinn]

it just lights up an led for each credit inserted, if more than 8 credits are put in they still get registered, you just can't tell how many are left unless you count in your head or the credit amount drops below 8, in which case the LEDs start to turn off one by one as each credit is played.

yes the green light is only displayed when credit count higher than zero and is an indicator the machine is ready to play as it is the start button. the green light does turn off when you press it to spin the reels and comes back on again when machine is ready to be spun again. a picture of sticker I re-designed may also help. its not finished yet but at least you can see what the buttons are for. I will end up using better quality fruit pictures than I used in picture.   

[Electrofinn]

on julians youtube video he explains a little on this and in the comment section, he says "The PIC16C57 didn't have non-volatile storage (EEPROM). So there was nowhere to store the calibrated servo endpoints. By using the 555s, the endpoints are effectively stored on the two trimmer pots."

i happen to like the simplicity of the trimmer pots as i am able to physically and easily calibrate where the servo travels to and stops.


here is julians video if you are interested.

[Ian.M]

on julians youtube video he explains a little on this and in the comment section, he says "The PIC16C57 didn't have non-volatile storage (EEPROM). So there was nowhere to store the calibrated servo endpoints. By using the 555s, the endpoints are effectively stored on the two trimmer pots."

i happen to like the simplicity of the trimmer pots as i am able to physically and easily calibrate where the servo travels to and stops.

Only the coin stack end position is critical.  It doesn't matter how far  the slide goes past the drop hole, so adjustment for a single position could have been entirely mechanical - put the horn on the servo splines turned to set the coarse position, and bend the linkage for fine adjustment.

I suspect that the NE556 ended up in there because at that date, Julyan's coding skills on a baseline PIC didn't extend to writing interleaved isochronous code so he was unable to get a stable servo pulse.   If the pulse is unstable, the servo would jitter, causing excessive battery consumption.

[Electrofinn]

Yes your're right, I still have the old mechanism me and my dad made. I remember a lot of the adjustment was mechanical and little was with the pots. The one I have is very crude in how its been cut and drilled but hey it worked very well for a long time. Will be making another but this time I am thinking of having some acrylic laser cut for me.

I will not be using a battery on this, going to power it with a power supply. but i remember battery consumption wasn't all that bad.

A few have wondered why he didn't do it the way you said and I think you're absolutely right about why he ended up doing it that way, I just thought it is was an excellent exercise of how a NE556 could be used and I think in the context of the magazine in which it was published 'Every Day Practical Electronics' or EPE for short and perhaps its target market it was probably very fitting. Not sure what part of the world you're in so not sure if you're familiar with the mag.

Lot of people have said this was one of the most memorable projects of the magazines history and for me it represents some of the happier moments of my childhood, it's a timeless classic, and yes it could be done a lot better but it has a charm about it, And watching my 7yr old's face playing this with it bare and out of its box just as I did when I was his age was special...yeah I gotta get this finished.

[Electrofinn]

This is because of bit zero of new_byte. There is no provision in the program to clear this bit. So if you put a coin in while the pattern is in the second half of the pattern, it will remember this the next time pattern starts being called.

Yep, you're absolutely correct, just tested this.

So it might be awhile, days, maybe weeks. I'm not retired. But the next time I post I suspect I will have either have some answers and/or I'll have some tasks for you to perform using a test code.

Yes no worries, fantastic, thank you.

[Ian.M]

The NE556 based servo control circuit is still over-complex.  Its fairly easy to use a single 555 to generate a Futaba servo signal - you just need a single diode across the discharge resistor to let it operate as an astable with a  discharge time of approx 18ms and vary the charging resistor to set the pulse width, as small variations in the pulse rate are non-critical.

It could also be done without the transistor - just  let the PIC output feed the short pulse charging resistor.   As  its a pain bit-banging the write-only TRIS register on baseline parts, put a diode in series with the PIC output so it can only source current.  On midrange or better PICs the TRIS registers are memory mapped, so one can easily toggle between Hi-Z input and outputting '1', so no extra diode is needed.

[KL27x]

New code revision.

Notice, I messed with timeout, so I hope there is no timeout, at all, now. Of course this might cause other issues, but the point is to see if this is what causes the 2 second (sometimes 30 second) pause. If this is it, then I'll see how best to fix it.

I cleared new_byte,0 in the spot where a coin is detected

and I changed win subroutine.

I believe the duration that pattern2 is displayed is dependent on mode_byte,4 being set. And it is only set when win is active. So it only stays on as long as win is in the middle of being executed. So I modified win so it uses a new register in place of counter_hi to see if this changes anything. (It could also be counter_lo;... but I only have one register left.)

Coped from my code history where I write revision notes. You can view the code changes by going to the labels "v22.x" which will pop up in your warnings when you assemble:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
V22    10/08/2018
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
v22.1    added a BCF new_byte,0 at were coin_counter is incremented

v22.2    locate subroutine responsible for the delay before
      pattern starts up after running out of credits.

x       put test code to bypass timeout to see what happens.

v22.3   win subroutine replaced

   the duration of pattern2 appears dependent on duration of win
   pattern2 is diplayed only as long as win is active.
   win uses counter_lo and counter_hi to determine duration
   
x   replaced busy flag MB,7 with new_byte,1 busy flag
x    replaced counter_hi with counter_higher
0    try replacing counter_lo
 

[Electrofinn]

Notice, I messed with timeout, so I hope there is no timeout, at all, now.

Yep, you're correct, there is absolutely no timeout delay now. Also the issue of it not starting at the beginning of "pattern" has happened a couple of times but now it seems it can't be deliberately reproduced, where as before, you knew that if you inserted a coin during second half of pattern that it would always start from 17th value (16th if counting from zero) but now it doesn't. My observation is that it begins at the start of "pattern" very nearly all of the time

I believe the duration that pattern2 is displayed is dependent on mode_byte,4 being set. And it is only set when win is active. So it only stays on as long as win is in the middle of being executed. So I modified win so it uses a new register in place of counter_hi to see if this changes anything. (It could also be counter_lo;... but I only have one register left.)

It appears to be behaving normally, although it's a little early in my testing to conclude. will thrash the hell of this thing tonight.

[KL27x]

Encouraging.

Here, I shuffled around new_byte so I could use the lower 5 bits as another completely separate timer for timeout subroutine.
Timeout should always end after about 2 seconds, now. What other consequences that will have, who knows?

I also made some small tweak to win/counter_higher, just to liberate the unused 3 bits at the top. This shoudn't change anything.... unless I made a human error.

Oh, and I found I was clearing what was formerly known as "new_byte,0" in the wrong spot, which was part of the code used for the max credit_count check.. So I added another bcf in the spot where it shoudl always be executed on insertion of a coin. So I think pattern will always start at the beginning, now.

So fingers crossed and hail to mary. And this might be pretty close



 

[KL27x]

New .asm
I realized that after a coin is put in, maybe sequence continues for a bit. I dunno.

I added another bcf pattern.bit5 (formerly known as mode_byte,0) to the exit of timeout. Timeout turns on sequence, which does the pattern. This should definitely handle the pattern start point thing, without digging into the code any further.

[Electrofinn]

So fingers crossed and hail to mary

^^this made me chuckle lol ^^

Well before you posted the newest code I had been bashing this for 2 and half hours straight and not once did the "pattern2" problem arise and I've had tons and tons of wins. so now I will try your newest code. will report back.   

[Electrofinn]

New .asm
I realized that after a coin is put in, maybe sequence continues for a bit. I dunno.

I added another bcf pattern.bit5 (formerly known as mode_byte,0) to the exit of timeout. Timeout turns on sequence, which does the pattern. This should definitely handle the pattern start point thing, without digging into the code any further.

Ok cool will try this one.

[Electrofinn]

something strange is now happening with "pattern" its only running and looping what looks like the first 16 values. shall I try the other one?

[Electrofinn]

already tried it and its the same.

[KL27x]

Ok probably a human error. Lemme see

Yeah, changed only part of my #define's for shuffling new_byte around.

Amended .asm attached.

[Electrofinn]

Nah, Still the same.

[KL27x]

Ok, no problem.

Just checked and I was clearing this bit in front of what I thought was a incf credit_counter, but it turned out to be credit_timer. That would do it. This is par for the course, and why this is a stupid undertaking from the start.

FWIW,
Source of some these errors (on top of manipulating the same registers in multiple subroutines that run simultaneously) lies in how the coder uses mode_byte,7 as a distinguisher for if a routine is being called for the first time or not.
The problem is he uses the same bit for every routine. And many of the routines get activated at the same time.

This would have been much clearer and more flexible/options if there were a unique bit for each subroutine as a busy flag. But now that it's all said and done, there are likely places where this mess produces the intended result. So leave sleeping dogs lie.

So if this produces unintended results right after the timeout is done, try putting

bcf mode_byte,7

right after timeout.end

[Electrofinn]

So if this produces unintended results right after the timeout is done, try putting

bcf mode_byte,7

right after timeout.end

Will do, however everything seems fine so far. Fingers crossed!