| Electronics > Beginners |
| Assembly code Help! PIC16F57 |
| << < (13/32) > >> |
| Electrofinn:
Excellent, will try your code and do the things you suggested as well. Don't know if you have any idea about the hold problem? no worries if not, you have already done a truck load and I thank you so, so much for all the time and effort you've put in. You have been awesome thank you. Got to go sleep now, got to get up early and get my son to school but will test later today. |
| KL27x:
^ I have a few major obstacles, Finn. I have no clue how indirect addressing works on the baseline PICs, and the datasheet doesn't help. I used midrange FSR/INDF incorrectly for like 2 years before finally figuring that out. I have very little understanding of how to use software debugging/simulation. And I don't have the device. Not even a bare PIC 16F57, and frankly, I don't really want to learn any more about these obsolete devices. :) So in many ways, you could debug this better than I, IF you had just a few basic skills and learned just a little bit of assembly programming. --- Quote ---Don't know if you have any idea about the hold problem? --- End quote --- So... I have super little understanding of how this code actually works, partly because of this INDF/FSR indirect addressing mystery (to me). I have no schematic or hardware. So whatever actual physical manifestation occurs in your device, I have no idea how that relates to the code. Something as simple as a bit of test code to blink a LED and just stopping/looping is super helpful. By moving this test code around and seeing where it breaks/stops the code, one might get an idea of where this "hold problem" actually relates to the code. In the code, the headers and hints left by the creator may be very abstract and far removed from what you think it to be. There are simply no good words to describe half the issues that assembly coders solve, and you might as well have names of race horses in there. Curiously missing from the programming header information is a pinout or pin designation. There must be some inputs and outputs, and none of that info seems to be included in this asm file. If you have the schematic/device, you would have some more options for testing. Especially if there are any free pins for hooking up to LEDs or a scope or whatnot. |
| Electrofinn:
Yeah no problem I understand, the assembly language all seems very nonintuitive to me and find the comments in creators code quite vague or don't properly explain what it's doing, at least to me anyway. One thing that baffled me is why he called the table for the servo actuations "odds" :-// why not call it "servo"... A little odd! Lol. With the problem you solved with the light sequence, I was really surprised and had no idea that what you did was required to get that to work, I felt that there was no chance I would have been able to come up with that, thought It was going to be a simple case of changing a value or range somewhere. Lol though I don't know why I was surprised because when I tried following along with a tutorial to flash a simple led, It seemed like a rediculous number of steps to get that to work, it felt like repeatedly smashing my head against a brick wall would of felt better! Lol I'm not even sure the flow chart included in the magazine article would be much help to me as that could be based on the finished code. In the flow chart it seems to be asking itself, when in idle mode, is there is any credits? and if yes, is the hold feature active. What this is personally telling me is that the hold feature is suppose to be driven by a random generator, and the literature in the article does say something like this but it seems to be pointing straight to the hold feature when you put that first credit in, yet if during the game you run out of credits and decide to put a credit in, it doesn't always give you a hold but sometimes it does, that's when it seems like it's working correctly... Strange, and I don't quite know how I am going to solve this issue. |
| Electrofinn:
Wow, KL27x you have been busy, your changes to the main program loop looks awesome and so neat and tidy, it's thing of beauty. still early in my testing but everything appears to be working ok, will update you though. Sometimes I wish it was as easy as that thing in the matrix movie where they upload to their brains what they need to know or learn In a few moments. need the assembly language program uploaded to mine lol again thank you for everything you have done. :-+ |
| KL27x:
--- Quote ---Wow you have been busy, your changes to the main program loop looks awesome and so neat and tidy, it's thing of beauty --- End quote --- This was mostly changing the tabbing to make it more readable. I've spent countless hours doing this to my own code. It's something that feels productive while you are trying to figure out what you should be thinking about. I think there's a word for this in the movie prop industry, but I forget what it is. It's also useful to leave these marks so you know where you've been and what you haven't really looked at before. --- Quote ---the comments in creators code quite vague or don't properly explain what it's doing --- End quote --- Probably 60-75% of my own code comments are useless to even myself, 1 week removed from the project. Some, not all, will have a meaning if/when I dig back into it. So I totally forgive the authors for that. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; So, I did not intend to think about this code today. I was not thinking about it last night. But here it is. I just woke up and was thinking about how I was going to start my day. And a connection just popped into my head out of nowhere. this observation of yours --- Quote ---**update** ok just had instance where a win did part of the "pattern" table, am switching back to new_byte equ 0E for now. although if it were someone else other than me playing the machine you probably wouldn't of noticed it to be honest. --- End quote --- Table and odds are the other addwf pc lookup tables I referred to earlier. Next, notice how there are only 7 outcomes in "odds". This is an odd choice for an assembly programmer when adding one more would make life easier. Also, notice how the last two values are the same, 0x08. This is also curious. You see the same redundancy in "pattern," where the last two values (as he originally wrote it) were redundant. But at least in pattern, his redundant retlw finished a nibble. In "odds" this redundant value still leaves the table one line shy of "filling the 3rd bit". Also notice how odds is physically located in front of "pattern". Notice if w reg were loaded with b'0000111" when "odds" were called, it would jump to pattern. And it would add another 7 to the PC. And it would : retlw 0b6 So when you said --- Quote --- ok just had instance where a win did part of the "pattern" table, --- End quote --- Do you suppose this "part of the pattern table" has any relationship to 0xb6 by any chance? Was it exactly this "frame?" I'm assuming "display" subroutine turns that into something up there on your display... a 3x 7 segment deal, is it? ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; odds addwf pc,f retlw 28 ;0 retlw 14 ;1 retlw 10 ;2 retlw 0C ;3 retlw 00 ;4 retlw 08 ;5 retlw 08 ;6 pattern addwf pc,f retlw 07f ;0 retlw 0bf retlw 0df retlw 06f ;3 retlw 0b7 retlw 0db retlw 06d retlw 0b6 ;7 retlw 0db retlw 0ed retlw 0f6 retlw 0fb ;11 retlw 0fd retlw 0fe retlw 0ff retlw 0ff ;15 retlw 0ff retlw 0ff retlw 0ff retlw 0ff ; retlw 0ff retlw 0ff retlw 0ff retlw 0ff ; retlw 0ff retlw 0ff retlw 0ff retlw 0ff ; retlw 0ff retlw 0ff retlw 0ff retlw 0ff ; pattern2 addwf pc,f retlw 00 retlw 81 retlw 0C3 retlw 0E7 retlw 0FF retlw 0E7 retlw 0C3 retlw 81 retlw 00 retlw 81 retlw 0C3 retlw 0E7 retlw 0FF retlw 0E7 retlw 0C3 retlw 81 |
| Navigation |
| Message Index |
| Next page |
| Previous page |