SavedByZero

Same problem. I set it up and after the initial WiFi selection, updates and boot, all I got was a black screen, even after multiple times turning it on and off. I had to plug a keyboard into the rightmost usb port once, set everything up again, wait for the bios to do its thing, register my account when it worked.

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...