SavedByZero

Thanks! A lot of the credit goes to Luis Zuno’s art pack that he specifically made for Atlantis (he doesn’t take commissions, but I won a suggestion contest). I wrote the code and did two pieces of art — the saucer (which transforms into a third turret as a slight nod to the Atari 2600 version of the game) and the space backdrop.

Thanks for the link! I also threw in a Cosmic Ark nod in the game over sequence.

Never mind, figured it out! However: this means I can't fire discs diagonally with whichever x/y is mapped to the xpad configuration, since the diagonal directions don't seem to register. Unless there's a solve for this.

Actually, almost got it -- looks like the remapping worked, but somehow, event_diag is not reading any input from my right analog stick on my xbox controller. Or any of the buttons, for that matter. It's only reading it from the left analog and dpad, from that file in the link. Wonder if there's a way to fix that...

Finally getting around to this a year and a half late. Where do I put this file? I was able to change the PS3 controller name near the top to the name of the PC/Xbox controller I just hooked up, but I'm not sure where the actual .xboxdrv file belongs. Is it in opt/retrope/configs/intellivision, where I stored my other keyboard hack files, or elsewhere? Or is there just a long process for installing this kind of configuration that I need to brush up on?

Yeah, it's me, so it's got to be necro time, right? I'm up to this part and having trouble understanding what .POS means -- my mind parses anything to the far left of the editor as a label. Is .POS acting as some kind of "local variable"? I know it's shorthand for position, but I'm not sure how it's used since I see it both in the "label" column and being used as part of an instruction further to the right. Divide15 .POS SET 0 REPEAT 160 .byte .POS / 15 .POS SET .POS + 1 REPEND

Force of habit with the darn semicolons. Ah, okay -- I assumed that strobing meant any positive value over 0 would set wsync to true. Initial playfield values, above all that in the once-only initialization area: lda #%11111111 sta pattern_pf1 sta pattern_pf0 sta pattern_pf2 I will definitely play with the debugger -- thanks.

Onto the "Wall" exercise. Would anyone see immediately why, when I try to increase the y register or even load a value into it, it seems to be ignored? I would think this code would draw a solid pattern for a while (I initialized the playfields to 8, across the board, earlier in the code) and then only draw side walls. However, it draws only side walls for the entire frame, as if it's never branching to "Notyet". Why is it never branching to "Notyet"? ldx #192 ldy #0 ; start y at 0 Picture iny ;increase 1 cpy #50 ;compare y to 50 bne Notyet ; if not 50, skip this next part and don't change the playfield yet. ldy #49; ;once y hits 50, go here and use this to make sure it stays at 50 when it's increased next time. lda #%00010000 ; change playfield to be mostly empty, except for the sides (mirror flag is set) sta pattern_pf0; lda #%00000000 sta pattern_pf1 sta pattern_pf2 Notyet lda pattern_pf0; sta PF0; lda pattern_pf1 sta PF1; sta PF2 lda #1 sta WSYNC ; wait till end of scanline dex cpx #0 bne Picture ;loop until it's time for the blanking period

Ahh, now that would explain what I'm seeing. Thanks. Though oddly enough, rol pattern, followed by lda pattern and sta PF1 still has the same result. BTW, in session 13, you declare a ram variable named PATTERN and later call "inc PATTERN" (so I know it wasn't a constant, I don't think? I know PATTERN referenced an address, but that 'inc' call did change the value at said address. But maybe I'm confusing ram variables with a different kind of declaration) -- I was copying that format when I used it. EDIT^2: Okay, this finally worked: lda pattern; AND #%10000000 bne dontclear clc; dontclear rol pattern; notyet lda pattern So yay, I can now "scroll" the easiest part of the playfield. On to the harder stuff...

Further investigation: swapping the diagonals for the straights in the key map doesn’t change anything; I still have to drag the joystick to a diagonal position to break the key map. my theory is that it’s related to how none of the diagonal joystick movements ever signal an “up” response in event_diag — only the straight ones do. Maybe button presses weren’t designed to be tied to joystick movements that have no return signal? still would be nice if they accounted for this, though I’ve had trouble finding a working email for the jzintv author. Not that I have any proof it’s something they can access.

Oh yeah, I know I have way more work ahead of me than simply rotating left; this was mainly my introduction to those commands. I was trying to see if that command did what I expected it with PF1, since PF1 is the only playfield register that's remotely straightforward. I'll deal with the others once I know what I'm doing with the commands. Anyhow, I figured out the blacking out was because I had accidentally erased a line of code that stored a positive value in the accumulator for the first overscan line, sta WSYNC. HOWEVER...I don't have a blank byte after 8 bits, now that I see it working...I have a full one. It starts as 00000001 and ends as 11111111...slowly filling with 1s as it rotates left...which was not what I expected, carry bit or no carry bit. I would have expected the carry bit to remain 0 as all those initial 0s get rotated through it, no?

Ah okay, so there are some syntatic variations. Some examples above show people using rol directly on variable names (rol PATTERN_SF1), but when I do that, it looks like it starts to rotate, but the screen then goes dark permanently. I would think this would simply rotate PATTERN one bit to the left (a mod of an earlier example program from the website, only instead of increasing the value by 1, I'm trying to rotate the bits):. iny cpy TIMETOCHANGE ; has it reached our "change point"? bne notyet ; no, so branch past ldy #1 ; reset speed count rol PATTERN notyet lda PATTERN; sta PF1;

So after some research, my idea for the scrolling is to use ROL. However, ROL A is listed as a legitimate command, yet the assembler flags it as illegal? What am I missing? EDIT: looking at some of the older posts here, I see others also use ROL, but directly on the pattern variable. At this point I'm just wondering why the examples elsewhere (like ROL A) are so different and don't appear to work with dasm. --- Unresolved Symbol List A 0000 ???? (R ) Code here: iny cpy #TIMETOCHANGE ; has it reached our "change point"? bne notyet ; no, so branch past lda PATTERN ROL A

Yeah, was afraid of that. That must mean it’s tied to jzintv and we need to contact the authors...

You took my exact hackfile and ran it with Tron Deadly Discs, used two joysticks, slid the disc throwing joystick around in an arc before returning it to the center, and it worked? In that case, what is your overall joystick setup like? Did you only have two or did you also have a keyboard and game pad plugged in, or some other setup? What command did your emulator.cfg run? That may be most important .

No no. I’m saying that if I move the joystick one direction, then *without returning it to the center* slide it one way or another, the whole system breaks. Even if I return it to the center *after* doing that, it remains broken. Thanks for to help but at this point I’m thinking it’s probably a bug. If I run event_diag, I can see that when I slide any given joystick before returning it to the center, it’s missing an “Up” signal for every position but the final one, and I bet that has something to do with it. Changing the maps for joystick 3 didn’t do anything either. I’ll find a way to report it.

Like I said, it’s not intentional. I move and release to throw, but sometimes my hand might stick and slide sideways a little before releasing. I’ll try messing with the rels and push thresholds to see if I can make the rels automatic maybe.

I’ve already used event_diag.rom to identify my controllers and their outputs, or did you mean something else?

I use this: https://www.amazon.com/gp/aw/d/B07JFXQSM5 My command for this particular setup is: jzint-trondd="/opt/retropie/emulators/jzintv/bin/jzintv -v1 --kbdhackfile=/opt/retropie/configs/intellivision/hackfile_trondd.cfg -f1 -q -p /home/pi/RetroPie/BIOS %ROM%" I don’t have a controller 0 that I know of; js2 is actually controller 1, js3 is controller two, and the one listed as js1 is controller 3 (event_diag.rom has different ideas about what the controllers are named than my emulationstation config). You’re right though, I think this may be a bug in the emulator, or something to do with how there’s no “Up” signal called on the disc throwing if I don’t move the joystick back to the middle after throwing it.

Yes to Map 0 at the top, I just neglected to copy that part. And yes, when I exit to the list of games and restart, the controls work again (until I move the firing joystick in an arc again, it doesn’t matter which direction the arc goes). How do you mean, try mapping to right keypad buttons? That last set is only my way of making sure the right joystick movements aren’t assigned to the right joystick itself, since I use the right joystick for firing.

My entire map: ;** Side buttons and Numeric Keypad ** JS2_BTN_00 PD0L_A_T JS2_BTN_01 PD0L_A_L JS2_BTN_02 PD0L_A_R JS2_BTN_03 PD0L_KP5 ;*** left DISC (move tron) *** JS2_E PD0L_J_E JS2_NE PD0L_J_NE JS2_N PD0L_J_N JS2_NW PD0L_J_NW JS2_W PD0L_J_W JS2_SW PD0L_J_SW JS2_S PD0L_J_S JS2_SE PD0L_J_SE ;*** right DISC (throw disc) *** JS3_E PD0L_KP6 JS3_NE PD0L_KP3 JS3_N PD0L_KP2 JS3_NW PD0L_KP1 JS3_W PD0L_KP4 JS3_SW PD0L_KPC JS3_S PD0L_KP0 JS3_SE PD0L_KPE ;** offload standard second disc input, so signals don't get scrambled JS3_BTN_00 PD0R_J_E JS3_BTN_01 PD0R_J_NE JS3_BTN_02 PD0R_J_N JS3_BTN_03 PD0R_J_NW JS3_BTN_04 PD0R_J_W JS3_BTN_05 PD0R_J_SW JS3_BTN_06 PD0R_J_S JS3_BTN_07 PD0R_J_SE

Well, I added this, to no avail: ;** offload standard second disc input, so signals don't get scrambled JS3_BTN_00 PD0R_J_E JS3_BTN_01 PD0R_J_NE JS3_BTN_02 PD0R_J_N JS3_BTN_03 PD0R_J_NW JS3_BTN_04 PD0R_J_W JS3_BTN_05 PD0R_J_SW JS3_BTN_06 PD0R_J_S JS3_BTN_07 PD0R_J_SE

Update: I found the exact behavior causing this. Not a combo of joysticks as I originally thought. It happens when I hold the second joystick after I use it to toss the disc, then without releasing it, move it to another direction (East to northeast, for example, without releasing it). That, for reasons beyond my understanding, fubars the key and joystick mapping.

Actually, the disc throwing does seem connected to it. Never fails if I don’t throw the disc. It doesn’t *always* fail when I throw the disc — often it works as expected, but the more often I do it, the greater chance of all the controls getting screwed up. Joysticks switch tasks sometimes. Things generally go nuts. I ended up installing it through RetroPie but used some of the files from the GitHub repo because the launch commands weren’t finding anything in that whole opt/retropie structure, and it wasn’t working. Other than this game it has mostly worked as expected (with the exception of Jetsons Ways with Words, which seems to ignore my ecs mod of the keyboard hack and I can’t move George Jetson at all)

Hey all, so I have a keyboard hack file for Tron DD that attempts to use my player 1 RetroPie joystick to move Tron and my player 2 RetroPie joystick to throw the disc in whatever direction. I need to do it this way because using buttons to throw with my setup would be too awkward. anyhow, it works...for all of five seconds. Then the disc tossing joystick stops responding and Tron walks indefinitely in one direction. I have commands like this for moving: JS2A_E PD0L_J_E and commands like this for throwing using the second joystick: JS3A_E PD0L_KP6 ; throw disc east any idea what’s wrong with this format? Is it just not possible to map joystick input to Intellivision button input?