+atari2600land Posted July 28, 2020 Author Share Posted July 28, 2020 I finally did it. The problem was apparently using Lisu 6 Lisl 1 was bad. I changed it to Lisu 4 Lisl 1 and it worked. But I still have a task ahead I don't know how to do. How to get a number between 16-64. You'd think shifting bits left and/or right would do that, but no. What I want this for is Lisu 4 Lisl 1 now. This results in sometimes the snowflake falling off the screen: lisu 4 lisl 1 lr A, S sr 4 ; The byte is now: %0000xxxx lr S, A Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 28, 2020 Author Share Posted July 28, 2020 I think I have it just perfect now. quest36c.zip Quote Link to comment Share on other sites More sharing options...
carlsson Posted July 28, 2020 Share Posted July 28, 2020 (edited) Am I missing something? The code snippet you quoted in the previous post doesn't exist in the code you uploaded. I see that you have two LFSR routines now, one that gets its seed from scratchpad register U6 L0 = 48 if I understand correctly, and one that uses register U4 L1 = 33, but in neither case you store the seed back to that register. In LFSR2 you exit the routine by reading back the old seed into the accumulator, which would mean that you will get different values from the two routines, but the same value each time you call the routine. Both locations are read/used elsewhere in the program, I'm not sure if you really want that. Can't you use something like U5 L0 and U5 L1 for random seeds and then exclusively use these values in the two LFSR routines? Think of these as variables, you wouldn't want to scratch or reuse variables across the program. Or maybe I'm barking up the wrong tree here, and the code you posted indeed works exactly as intended, with proper random upon each call. I just don't understand how it would work then. Edit: Ok, those scratchpad registers are changed in main_game, get_last_4_numbers_of_password and level_2_loop so you would get different results each time you call the LFSR routines, but not necessarily any good random distribution since it will operate on whichever value was stored outside of the routine, not the previous seed. Edited July 28, 2020 by carlsson Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 28, 2020 Author Share Posted July 28, 2020 I can't use U5 variables since they're used for the BIOS pushk routine. Quote Link to comment Share on other sites More sharing options...
carlsson Posted July 28, 2020 Share Posted July 28, 2020 Fair enough, I didn't know that. But you have at least U6 L1, U6 L2, U6 L3, U6 L4 currently free. I think by allocating dedicated scratchpad registers for the LFSR's, you will get better random numbers. Quote Link to comment Share on other sites More sharing options...
e5frog Posted July 28, 2020 Share Posted July 28, 2020 I usually name the registers 'O'61, O61 or 061 (for octal 61). It's a bit annoying that they're named differently in MESSUI debugger. IIRC they're 0-63, if you want to set 062 to a value in the debugger a quick calculation is needed, it's R50 in debugger... Seems 0o62 would be a way of writing it, like 0x32 is for hex. That's why I usually make an initial table with octal and decimal numbers. ISAR can be loaded directly from A as well. LI $32 LR IS, A (and fetch the value with LR A, IS) If using that way of loading ISAR you can increase and decrease the ISAR number without thinking about the lack of carry on ISAR where octal 67 would change to 60 after an increase instead of 70. For the LFSR to work you need the previous number safely stored. Make sure you continue from the whole 8bit number and not your partial one. Seed one initial time by counting up a number while waiting for user interaction, when done place value in your LFSR memory position. If waiting for a keypress you can check that it's not pressed before allowing to stop counter - as it would otherwise be possible to get the same seed and then know the series of numbers that follows. When needing a random number you call the LFSR routine once. It's supposed to read from the reserved memory position and then write the new number there. Either you use it directly from A, store it in a temp position or read from reserved position. User actions in the game could generate a LFSR call to increase variation passing a position on screen, how many times a maneuver is done etc. I'd love to get involved but I need to get some other things done. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 28, 2020 Author Share Posted July 28, 2020 The crappiness of my random numbers was due to the way I was coding it. The random numbers should be better now since I fiddled with the LFSR to try and make it work better. O36 is now used as the random number table lookup number and added by 1 after each loop. If the numbers are too big or too small, I then shift the numbers as needed after they are looked up and put into O31 (rain/snow x position). Here's what my LFSR looks like: LFSR: ; Linear Feedback Shift Register ; save the return address clr lisu 3 lisl 6 lr A, S ;as 7 bz doEor lr 0, A ; Save original number in r0 sl 1 ; shift one step left lr 7, A bz noEor ; Do XOR if b7 was 1, workaround for missing carry on "sl" lr A, 0 ni %10000000 bz noEor doEor: lr A, 7 xi $2b ; Do the XOR thing lr 7, A noEor: lr A, 7 ai 10 lr 7, A pop ; return from the subroutine The only problem now is this: Sometimes (but not always) when the screen switches to level 2, a thick light green line appears at the top. I know it's probably due to a sprite being offscreen, but I don't have any offscreen sprites. quest37.zip Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 29, 2020 Author Share Posted July 29, 2020 I'm sorry but I won't pay $800 for a box of a game I don't have. Quote Link to comment Share on other sites More sharing options...
e5frog Posted July 29, 2020 Share Posted July 29, 2020 (edited) The "bz doEor" won't work as "lr A, S" doesn't set flags. As in my example code: http://channelf.se/veswiki/index.php?title=Snippet:Pseudorandom_numbers Where I use the combination of "clr" and "as 1" you should use "as S" to make "bz doEor" meaningful. Then you have "lr A, 7" where it should be "lr A, S". ... as well as everywhere else r7 is used - should say S. If you use r7 later, end with lr A, S lr 7, A. So: LFSR: ; Linear Feedback Shift Register ; save the return address ; r0 as temp reg ; 0o36 stored rnd no lisu 3 lisl 6 clr as S bz doEor lr 0, A ; Save original number in r0 sl 1 ; shift one step left lr S, A bz noEor ; Do XOR if b7 was 1, workaround for missing carry on "sl" lr A, 0 ni %10000000 bz noEor doEor: lr A, S xi $2b ; Do the XOR thing lr S, A noEor: lr A, S xi $2b ; VERY IMPORTANT lr S, A ; if needed: ; lr A, S ; lr 7, A ; Now you can handle your number, store in a temp register ; or fetch reg 0o36 in your code and then handle it locally. ; If wanting to check if valid number, repeat if it's not. ; (Can be done many many ways) ; ni %00111111 ; keeps only 0-63 ; ci 14 ; bp LFSR ; a number under 15 causes a loop for new number ; Possible numbers are [15,63] ; inc ; Now it's instead [16,64] in A ; lr 0, A ; Stores the edited pseudorandom number in ; register 0 for temporary (or other reg - not reg 0o36) ; keeping, if it can't be left in A ; You'll now keep getting a new pseusorandom number in reg 0o36 every time you call LFSR ; ...unless you write to it anywhere else in the code. pop ; return from the subroutine Edited July 29, 2020 by e5frog 1 Quote Link to comment Share on other sites More sharing options...
e5frog Posted July 29, 2020 Share Posted July 29, 2020 (edited) The green field means something is written in the palette column, either going too far left (decrease in x) and looping over or too far right. Several rows, do the appear at the same time or in a special order? Try and skip parts that are plotted and see if you can figure out which part causes it. A few times I've had problems with pixels ending up in the wrong places, it was enough to clear ports used before plotting. Maybe out or outs have been used on the wrong port. Edited July 29, 2020 by e5frog Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 29, 2020 Author Share Posted July 29, 2020 I chose to do this: ni %00111111 ai 10 lr 0, A pop ; return from the subroutine Which I think makes the number between 10-73. I didn't want to reloop LFSR for fear it may cause an unwanted split-second interruption in the cranberry's movement. And then I make it O31 by this: lr A, 0 lisu 3 lisl 1 lr S, A What I have now is OK, correct? By the way, I mentioned a few posts ago that a box for Checkers box has been put on eBay. If you want to part with $800, now's your chance. quest38.zip Quote Link to comment Share on other sites More sharing options...
carlsson Posted July 29, 2020 Share Posted July 29, 2020 So you're reading your random number seed from O36 (using e5frog's syntax) but storing the remaining seed at O31. I don't understand why you don't use the same register, so you can pick it up the next time you run the LFSR routine. Instead as you describe, in main_game you take the seed, increase it by one and store it back. That way, the shifting and EOR is more or less wasted, you only manipulate a sequence of numbers 0, 1, 2 ... according to the same pattern each time. Anything that works for you is fine, but you don't have a working LFSR as it sits. The code posted by e5frog does though, with this small but very important detail. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 29, 2020 Author Share Posted July 29, 2020 The reason I'm storing it in O31 is because that's where I want the x position to be. In other news, my Channel F seems to have died. I tried unscrewing it and opening it to look inside, but there's one corner that's stubborn and won't open up. So I tried to search for a YouTube video but couldn't find one. Quote Link to comment Share on other sites More sharing options...
carlsson Posted July 29, 2020 Share Posted July 29, 2020 That's sad about your console. ? Quote Link to comment Share on other sites More sharing options...
Mikebloke Posted July 29, 2020 Share Posted July 29, 2020 If it helps 36c had the same bar issue, I don't know about a and b. Also, that box is super bashed up too. But tryers is going to try. I'd pay £5 for it. I don't think I have a single box that bad, even in my old doubles that have now moved on. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 29, 2020 Author Share Posted July 29, 2020 My console is dead. I will have to spend an unholy fortune for another one off eBay. Quote Link to comment Share on other sites More sharing options...
carlsson Posted July 29, 2020 Share Posted July 29, 2020 Perhaps someone on this forum has the skills to repair it for less than a replacement console costs? Quote Link to comment Share on other sites More sharing options...
+stupus Posted July 29, 2020 Share Posted July 29, 2020 (edited) I think kyljoy was doing channel f repairs. https://atariage.com/forums/profile/42281-kyljoy/ Edited July 29, 2020 by stupus Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 29, 2020 Author Share Posted July 29, 2020 I think it's dead. It shot a spark at me. Quote Link to comment Share on other sites More sharing options...
masschamber Posted July 29, 2020 Share Posted July 29, 2020 47 minutes ago, atari2600land said: I think it's dead. It shot a spark at me. that doesn't mean it's hopeless, are there any obvious shorts? I mean the traces aren't exactly hard to follow on it, also, I don't think anything on the board is hard to find except the f8 chips and even then I think you can still find 3850s, they're not super cheap but they aren't super expensive either, so as long as those aren't fried you should be able to save it. Quote Link to comment Share on other sites More sharing options...
carlsson Posted July 29, 2020 Share Posted July 29, 2020 Hard to tell if there are shorts if he is unable to open up the console. But at best it would just be a power supply issue, perhaps a cable that has come loose and caused the spark. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 29, 2020 Author Share Posted July 29, 2020 Oh, I opened it up to take a look. That's when the spark shot at me. I think it was a loose cable that caused it. Quote Link to comment Share on other sites More sharing options...
e5frog Posted July 29, 2020 Share Posted July 29, 2020 6 hours ago, atari2600land said: I chose to do this: ni %00111111 ai 10 lr 0, A pop ; return from the subroutine That will indeed keep 0-63 and the add 10 but... noEor: lr A, S xi $2b ; VERY IMPORTANT lr S, A You CAN NOT remove xi $2b from noEor you can make your additions after that lr S, A. Else you'll ruin the pseudorandom chain and get stuck in a shorter, possibly repetetive number series. Spark might have come from discharging capacitor or DC on the antenna output. Depending on were discharge went it might have gotten damaged. Quote Link to comment Share on other sites More sharing options...
masschamber Posted July 29, 2020 Share Posted July 29, 2020 2 hours ago, atari2600land said: Oh, I opened it up to take a look. That's when the spark shot at me. I think it was a loose cable that caused it. as long as you didn't fry anything you might still be okay, how are the grommits on the ac adapter pass thru? Quote Link to comment Share on other sites More sharing options...
e5frog Posted July 29, 2020 Share Posted July 29, 2020 Sounds likely it was an electrostatic discharge in one or the other direction, was it assembled and/or hooked up? Seems impossible not to touch ground if disassembling... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.