kensu

I'm thinking of looking into developing a light-gun game, and want to see if there's a big enough audience to justify it. Edit: Dammit, I cut off the "I have both" option. Could a mod add "I have both" as option 1 and move everything else down?

In this case I really just need to determine the scanline so I can enable the DLI to change the PM color register. The one I'm trying at this moment is: (MYPMBASE+YPOS+512)/4, with those variable having their most common meanings. Doesn't seem to be working, though. There's plenty of reasons why that might be, though.

Has anyone come up with a good formula for translating PM screen coordinates to position in the character buffer array and vice-versa? Below are some notes I made on the subject for my breakout clone (this is in graphics mode 17), but it's still a little off. The top line of the topmost brick is y=16. The bottom of that brick is at y=20. The bottom line of the lowest brick is y=40 The left edge of the playfield is x=42 the left side is x=210 46 is the left edge of the brick, 61 is the right side. The right side of the last brick is 205 Each brick has a width of 15. (possibly 16? The bricks are two characters) Each row is 10 bricks or 20 characters long. There are 6 rows of bricks. So take all together: The four corners of the bricks: NW: 46,16 NE: 205,16 SW: 46,40 SE: 205,40 Width of bricks: 159 Height of bricks: 24 Each brick is 15 wide and 4 tall. 46 + (159/) 100,25: where am I? 100-46 = 54 -> 54/15 = 3 -> column 3 25-16 = 9 -> 9/4 = ~1: Row 2 (it's actually column 4, bottom of row 2) 49,15 is brick 0,0. 49-46 = 3 /0 = Column 0 18 - 16 = 2 / 0 = Row 0 Column is zero-indexed, but row is not?

Yep, worked like a charm, I pinned a Thanks trophy to the message with the code that fixed it. Thanks!

It might be Zero Page address zero, which I think is clear for variable use. I wonder why it always has a starting value of 3? This also explains a lot of weird issues I've been running into with Action!, and why I couldn't really understand how dereferncing of variables worked. Action appears to be much closer to the metal than I thought, and just using my knowledge of C wasn't enough.

That's very strange, if you remove the brackets it will loop through the colors in a different order (3,4,5,0,1,2). I think what's happening here is similar to what happens when you use something like "Byte x=$FF" where it sets up the variable as a direct reference to that spot in memory without having to do any dereferncing with the ^. In this case it seems to be using Action's memory allocation routine to find a free spot in memory and then assigning that variable as a reference to it. I still don't understand why it has a different result from just a normal assignment.... I wish we could ask the author of the original example, but this code is from 1984, if they were still around I doubt they'd remember why they did it that way.

Hmm, the Graphics 1 (for BASIC and Action!) display list is: 112 112 112 70 128 157 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 adr 0 1 2 3 4 5 6 7 8 9 1011121314151617181920 Bacially the first 6 of those 6s are turned into 134 (6 with bit 7 set). So if I wanted it to start on the first line, I would want to change offset 5, but that's actually the high component of the address of the beginning of the screen buffer. So what do I do in this case? Also, if it starts on offset 6, which would be the first line of the screen, why are the first two lines the original color, instead of just the first line? As I recall, aren't there two mode lines per row?

I incorporated a modified verison of the DLI routine from this Action! program into a character set redefiniton program I'd previously written, which draws six rows of Breakout-style bricks. This actually works, but it only changes the color of rows 3-6, no matter how I modify it, I can't get the first two rows to change. Those lines do have DLI enabled, but the Playfield Color 1 (0) is only changed starting with the third line. DEFINE RTI="$40", PHA="$48", PLA="$68", TXA="$8A", TAX="$AA", TYA="$98", TAY="$A8", JMP="$4C" BYTE CHBAS = $2F4, PMBASE = $D407, RAMTOP=$6A, NMIEN=$D40E, COLP0=$D016,WSYNC=$D40A, COUNT=[0] CARD SDLSTL=560, VDSLST=512 BYTE ARRAY COLTABLE(0) = [$42 $74 $C4 $18 $00 $0E] BYTE ARRAY DLIST PROC DLINT() BYTE DUM [PHA TXA PHA TYA PHA] DUM=COLTABLE(COUNT) WSYNC=1 COLP0=DUM COUNT ==+ 1 IF COUNT=6 THEN COUNT=0 FI [PLA TAY PLA TAX PLA RTI] PROC INIT_GR() GRAPHICS(1) SETCOLOR(0,2,10) SETCOLOR(1,5,12) SETCOLOR(2,0,0) RETURN PROC DLSETUP() BYTE I INIT_GR() NMIEN=$40 DLIST=SDLSTL VDSLST=DLINT FOR I = 6 TO 11 DO DLIST(I)=134 OD NMIEN=$C0 RETURN PROC CHANGE_CHARSET() BYTE ARRAY NC0 = [255 128 128 128 128 128 128 255 255 1 1 1 1 1 1 255 ] CARD MEMTOP MEMTOP = RAMTOP - 8 MEMTOP = MEMTOP * 256 ZERO(MEMTOP,512) MOVEBLOCK(MEMTOP,57344,512) MOVEBLOCK(MEMTOP+8,NC0,16) CHBAS = MEMTOP/256 RETURN PROC MAIN() CARD SAVMSC=$58 BYTE I CHANGE_CHARSET() DLSETUP() FOR I = 0 to 120 STEP 2 DO POKE(SAVMSC+I,1) POKE(SAVMSC+I+1,2) OD DO OD RETURN (for some reason I can't edit the code portion, Change_Charset() and DLsetp() are in the wrong order in the main procedure) A couple of additional questions for Action! experts. Why is count set to [0] instead of 0? I'm beginning to understand that anything in brackets is not actually an array, but some sort of machine code instruction, but I'm not clear on why it's done this way (if you remove the brackets there's a different result.) Also, why is Coltable dimensionalzed with a size of 0? This is the only example I've seen where an inline array declaration dimensionalizes the array, much less saying it's empty when it has a size of 6.

Finally figured this out, Mapping The Atari is your friend! RAMTOP is not a memory location, it's a page reference. Specifically where the Atari thinks the last page of memory is. Pages are 256 bytes long, so you multiply by it to the get the address. What does puzzle me is the RAMTOP-8 part, specifically the -8, I've seen other programs that use -16. I'm assuming this number can be larger depending on how much RAM you have installed?

A different game, but I heard somewhere that the code for Flappy Bird is insanely simple. I mean, like Breakout simple.

I wrote the following progam in Action! so that I could determine the exact coordinates of the screen in the Breakout-clone I'm writing to learn the system. Whenever the x or y coordinates are less than 100 the third digit switches between several different values, always in the same order. I'm not quite sure what causes this, but it reminds me of the energizers in Jawbreaker. Anyone have a clue on this? Also, does anyone have a better way of converting the byte values so they display correctly on the screen? BYTE PMBASE=$D407, RAMTOP=$6A, SDMCTL=$22F, GRACTL=$D01D, P0H=$D000, P0C=$2C0, P1C=$2C1, SP0=$D008, CHBAS = $2F4 CARD SAVMSC=$58 CARD POINTER MYPMBASE BYTE ARRAY CROSSHAIR = [56 16 56 16 56] BYTE XPOS, YPOS PROC SLEEP(BYTE ITS) BYTE I,J,K FOR I = 0 TO ITS DO FOR J=0 TO 10 DO K = 100/20 OD OD RETURN PROC init() ;variable declarations CARD PMTOP ;code PMTOP = RAMTOP - 8 PMBASE = PMTOP MYPMBASE = PMTOP * 256 GRAPHICS(1) SETCOLOR(0,5,7) SETCOLOR(1,1,10) SETCOLOR(2,10,5) SETCOLOR(3,13,2) SETCOLOR(4,0,0) SDMCTL = 46 GRACTL = 3 XPOS = 100 YPOS = 100 P0H = XPOS P0C=88 RETURN PROC SETUP_PMGRAPHICS() Zero(MYPMBASE+512,128) MoveBlock(MYPMBASE+512+YPOS,CROSSHAIR,5) RETURN PROC CHANGE_CHARSET() CARD MEMTOP = MYPMBASE BYTE ARRAY NC1 = [255 128 128 128 128 128 128 255] BYTE ARRAY NC2 = [255 1 1 1 1 1 1 255 ] ZERO(MEMTOP,512) MOVEBLOCK(MEMTOP,57344,512) MOVEBLOCK(MEMTOP+2*8,NC1,8) MOVEBLOCK(MEMTOP+3*8,NC2,8) CHBAS = MEMTOP/256 RETURN PROC DRAW_BRICKS() BYTE I FOR I = 0 to 119 STEP 2 DO POKE(SAVMSC+I,2) POKE(SAVMSC+I+1,3) OD RETURN PROC MAIN() BYTE STVAL,I CHAR ARRAY XCORD(4),YCORD(4) INIT() CHANGE_CHARSET() SETUP_PMGRAPHICS() DRAW_BRICKS() DO STVAL=STICK(0) IF STVAL=11 THEN XPOS = XPOS -1 FI IF STVAL=7 THEN XPOS = XPOS + 1 FI IF STVAL=14 THEN ZERO(MYPMBASE+512+YPOS,5) YPOS = YPOS - 1 MoveBlock(MYPMBASE+512+YPOS,CROSSHAIR,5) FI IF STVAL=13 THEN ZERO(MYPMBASE+512+YPOS,5) YPOS = YPOS + 1 MOVEBLOCK(MYPMBASE+512+YPOS,CROSSHAIR,5) FI P0H=XPOS STRB(XPOS,XCORD) STRB(YPOS,YCORD) FOR I=0 TO 3 DO XCORD(I) = XCORD(I) - $20 YCORD(I) = YCORD(I) - $20 OD MOVEBLOCK(SAVMSC+600,XCORD+1,3) MOVEBLOCK(SAVMSC+605,YCORD+1,3) SLEEP(5) OD RETURN

I was just re-reading the section of De Re Atari which disusses the way that scanlines and such work; I've been kind of annoyed how PM graphics can go beyond the visible side of the screen. But then I remembered something, the invisible area right beneath the screen is where Closed Captions are stored (at least in NTSC TVs). Has anyone played around with this? I know the screen buffer won't let you write to these areas, but you can move a player there. Has anyone played around with this? Sadly the VMU I have my 800XL connected to doesn't have CC capability.

Is there any way to detect collisions between the color in register 0 and a player object? Everything I've read so far says that only collisions with the colors from Registers 1-4 can be detected. However I ran across a message on this forum which suggested that in certian modes (17, I think) it's possible to detect these collisions. Alternatively, is there a way to change which registers the character set uses for color so I can detect a collision between a player object and a character? Otherwise I basically need to scrap all the code I've written and start over.

Here is the full code. It's kind of embarssig, but I've only been coding on the Atari for a couple of weeks now. BYTE PMBASE=$D407, RAMTOP=$6A, SDMCTL=$22F, GRACTL=$D01D, P0H=$D000, P1H=$D001, P0C=$2C0, P1C=$2C1, SP0=$D008, SP1=$D009, POKR=$D20A, CHBAS = $2F4, P0COL = $D005, IN_PLAY, HITCLR = $D01E CARD SAVMSC=$58 CARD POINTER MYPMBASE DEFINE TRUE="0" DEFINE FALSE="1" BYTE XPOS BYTE BALLX BYTE BALLY BYTE STUCK INT VECTORX INT VECTORY BYTE ARRAY GBAT = [255 129 255] BYTE ARRAY GBALL = [0 8 28 8 0] PROC SLEEP(BYTE ITS) BYTE I,J,K FOR I = 0 TO ITS DO FOR J=0 TO 10 DO K = 100/20 OD OD RETURN PROC init() ;variable declarations CARD PMTOP ;code XPOS = 228-PADDLE(0) BALLX=XPOS+4 BALLY=97 STUCK=TRUE VECTORX=1 VECTORY=-1 GRAPHICS(0) SETCOLOR(2,0,0) SETCOLOR(4,2,8) PMTOP = RAMTOP - 8 PMBASE = PMTOP MYPMBASE = PMTOP * 256 XPOS = 228-PADDLE(0) BALLX = XPOS+4 BALLY = 97 STUCK = TRUE VECTORX = 1 VECTORY = -1 SDMCTL = 46 GRACTL = 3 P0H = XPOS P1H = BALLX IN_PLAY=TRUE RETURN PROC setup_pmgraphics() SP0=1 Zero(MYPMBASE+512,128) MoveBlock(MYPMBASE+512+100,GBAT,3) Zero(MYPMBASE+640,128) MoveBlock(MYPMBASE+639+BALLY,GBALL,4) P0C = POKR P1C = POKR RETURN PROC CHANGE_CHARSET() BYTE ARRAY NC1 = [255 128 128 128 128 128 128 255] BYTE ARRAY NC2 = [255 1 1 1 1 1 1 255 ] BYTE ARRAY NC3 = [126 70 66 66 66 66 66 126] BYTE ARRAY NC4 = [66 66 66 126 98 98 98 98] BYTE ARRAY NC5 = [126 66 64 126 6 6 70 126] BYTE ARRAY NC6 = [16 16 16 24 24 24 24 24] BYTE ARRAY NC7 = [126 16 16 16 24 24 24 24] BYTE ARRAY NC8 = [16 16 16 24 24 24 0 24] BYTE I CARD POINTER J, OLD_START CARD MEMTOP MEMTOP = MYPMBASE ZERO(MEMTOP,512) FOR I = 0 TO 512 DO J = MEMTOP + I OLD_START = CHBAS + I J^ = OLD_START^ OD MOVEBLOCK(MEMTOP+8,NC1,8) MOVEBLOCK(MEMTOP+16,NC2,8) MOVEBLOCK(MEMTOP+24,NC3,8) MOVEBLOCK(MEMTOP+32,NC4,8) MOVEBLOCK(MEMTOP+40,NC5,8) MOVEBLOCK(MEMTOP+48,NC6,8) MOVEBLOCK(MEMTOP+56,NC7,8) MOVEBLOCK(MEMTOP+64,NC8,8) CHBAS = MEMTOP/256 RETURN PROC draw_bricks() BYTE I FOR I = 0 to 239 STEP 2 DO POKE(SAVMSC+I,1) POKE(SAVMSC+I+1,2) OD RETURN PROC display_message() BYTE ARRAY MSG = [3 4 0 5 4 6 7 8] MOVEBLOCK(SAVMSC+495,MSG,8) RETURN PROC DESTBRICK(BYTE COL, BYTE ROW) CARD SAVMSC=$58 CARD TARG TARG = ROW*40 + COL*2 ZERO(SAVMSC+TARG,2) RETURN PROC DBXY(BYTE X, BYTE Y) BYTE ADJX, ADJY, COL, ROW ADJX = X - 40 ADJY = Y - 10 COL = ADJX/8 ROW = ADJY/10 DESTBRICK(COL,ROW) RETURN PROC COLDEC() BYTE OCCUR BYTE ARRAY MSG = "Collision!" OCCUR = PEEK(P0COL) IF OCCUR > 0 THEN MOVEBLOCK(SAVMSC+495,MSG,10) ZERO(HITCLR,1) ELSE ZERO(SAVMSC+495,10) FI RETURN PROC main() init() ;Boilerplate CHANGE_CHARSET() draw_bricks() setup_pmgraphics() ;initalize player missile graphics ; main loop WHILE 1=1 DO XPOS = 228-PADDLE(0) P0H = XPOS ;Set the value of STUCK to false if the button is pressed. IF IN_PLAY=TRUE THEN IF PTRIG(0)=0 AND STUCK=TRUE THEN STUCK=FALSE FI IF STUCK=TRUE THEN BALLX = XPOS+4 ELSE SLEEP(5) BALLX = VECTORX + BALLX IF VECTORY = -1 THEN MoveBlock(MYPMBASE+639+BALLY,MYPMBASE+640+BALLY,3) ZERO(MYPMBASE+642+BALLY,1) ELSE MoveBlock(MYPMBASE+639+BALLY,GBALL,4) FI BALLY = VECTORY + BALLY FI P0C = POKR P1C = POKR P0H = XPOS P1H = BALLX IF BALLX > 200 THEN VECTORX = -1 FI IF BALLX < 40 THEN VECTORX = 1 FI IF BALLY > 110 THEN DISPLAY_MESSAGE() IN_PLAY=FALSE ZERO(MYPMBASE+639+BALLY,5) FI IF BALLY <= 10 THEN VECTORY = 1 FI COLDEC() FI OD RETURN

Not quite sure what I did wrong, but: BYTE OCCUR BYTE ARRAY MSG = "Collision!" OCCUR = PEEK(P0COL) IF OCCUR > 0 THEN MOVEBLOCK(SAVMSC+495,MSG,10) ZERO(HITCLR,1) ELSE ZERO(SAVMSC+495,10) FI Causes a minature version of everything (playfield, graphics, etc) to appear in the center of the screen. It stays in sync with the larger version as well. Has anyone ever seen anything like this? The only thing I can think of is that it might have something to do with graphic modes and interrupts, but I don't know much about how those work.

As I've been reading examples I've noticed that whenever a new block of memory is set aside for use, you always start writing at a point determined by the starting address multipled by 256. This is true for both PM and character sets. PM Example from Action! PMTOP = RAMTOP - 8 PMBASE = PMTOP MYPMBASE = PMTOP * 256 None of the books or tutorials I've been reading have ever explained why they do this. I'm figuring either it's supposed to be so obvious that they don't need to explain it, or they don't understand themselves. Does this have something to do with the memory block having to start on a kiltobyte boundary? Thank!

Thanks to everyone who replied, the issue was that it was overwriting itself. (I assumed MoveBlock moved it as a discrete block, but it must do it byte-by-byte like the De Re Atari exampl). I fixed the problem by zeroing out the player graphics at the current position and redrawing them (from the array where I originally defined it) in the final position. I also padded it with zeroes, an arcane practice I've been seeing in code examples but haven't understood until now. It appears the way I did it now is the way it's done in most examples. I'm beginning to realize that Action! is even closer to the metal then C is, never before have I found myself wondering how malloc works so I could write my own.

I have a simple ball-bouncing program which started out as a BASIC program, which was itself derived from the De Re Atari Player-Missile example (which can be found here) Here is the releveant snippet of code: BALLX = VECTORX + BALLX IF VECTORY = -1 THEN MoveBlock(MYPMBASE+639+BALLY,MYPMBASE+640+BALLY,3) ZERO(MYPMBASE+642+BALLY,1) ELSE MoveBlock(MYPMBASE+640+BALLY,MYPMBASE+639+BALLY,3) FI BALLY = VECTORY + BALLY (Ballx and BallY are the coordiantes of the ball, VectorX and VectorY are the direction it's moving (in this case -1 for up, 1 for down)). So this code works fine when the ball is moving upwards, but once it hits the top of the screen and starts moving downwards (the Else clause) it just vanishes from the screen. I suspect there's something I missed when I translated the FOR loop from the BASIC code. (see the De Re Atari example above) Note: there should be a zero command in the Else clause to keep the ball from leaving a trail on the screen, but that's irrelevant to this problem. If I change the else clause to: MoveBlock(MBASE+637+BALLY,MYPMBASE+636+BALLY,3) the ball will bounce and continue on for about 3 bytes, gradually disappearing.

I know it's been ten years, but I've been working on a similar project and found this thread. So basically the code I wrote did pretty much the same thing, but wasn't working because I was setting CHBAS to TOPMEM instead of TOPMEM/256. I'm afraid I still don't understand why I need to divide by 256. I would appreciate any help.

The 2600-daptor D9 says it has support for the Sega Paddle control, does anyone know if Fusion or any other emulator allows the paddle controller to work correctly with Woody Pop?

I just got an Action! Cartridge and it won't work with the Fujinet, which basically renders it next to useless. Fujinet will load instead of the cartridge, and booting with the option key just leads to a black screen. I have confirmed that Action! works with the Fujinet unplugged, and other cartridges work with the fujinet present. Is this a known issue? Anyone have any ideas?

I just got a Fujinet and can't figure out to load or save basic programs to the emulated disk drive. Here is what I tried: 1. Created a new disk image in FujiNet, it was the third-smallest type, like 100K or something like that. 2. I mounted the disk to slot 1. 3. I hit the Option key to boot the machine. Instead of going to BASIC I get a garbled screen. Figuring that it's trying to read from an empty disc, I switched the FujiNet off, restarted the computer and switched FujiNet back on when basic started. I tried to save it using a filename with both D: and D1: but nothing happened. I've searched this forum and the internet in general, but the only thing I've found close to this involves the N: device, and that is much more complicated than what I need. I don't want to open a socket up to another machine, I just want to be able to read and write to the emulated disk drive from BASIC. I also just bought an Action! cart on eBay, I assume I'm going to run into a similar problem? (For that matter, is there a FujiNet manual somewhere? I found nothing like that on the Brewing Academy website.)

In this video, at about the 7 or 8 minute mark John Harris mentions some sort of Atari 8-bit clone made in 1994. The company name he gives is Multiplex Technology, but I have been unable to find any references to anything like that in my google searches. Does anyone know what he's talking about? ,

Four things I've been pondering... 1. Is it possible to replace the CD Rom in a Duo with a faster version? (Nothing modern of course, but maybe a 2x or 4x one. How fast was the original?) I've never seen anyone do this, so I assume it's impossible. 2. How come no one has created a flash version of the Tennokoe Bank card? I've noticed that even the Everdrive doesn't have this functionality. (is there a Tennokoe Bank rom somewhere, would that work?) 3. It's also interesting that there are no mods for replacing the file cabinet with flash memory. 4. I've noticed that the Arcade Card has the 3.0 bios but more RAM. Does this have any noticeable effect on regular games (for instance, do they load faster, or does it make lag disappear in some cases?) Sorry if these questions seem a little naive, I'm a programmer who got his degree in 2008, and I am very aware that things were different back in the very early 90s when this system came out.

I recently got a BPS-Max for my recently acquired Twin Famicom (the BPS-Max is the third party controller that the NES Max was derived from.) It's weird, the roto-disc has this friction mesh on it, which makes it sort of uncomfortable to use... In any case, this got me thinking about the way that the controllers worked on the original Famicom and Twin Famicom, where it had wired controllers. Now, with the few games I've tried it with, the BPS-Max always acts as a Player One controller, and I'm kind of curious about how that works. Is there a hardwired switch in there which turns on whenever something is plugged into the controller expansion export, or is this something that is programmed into each game? I remember hearing that the expansion controller port was used to allow three players on some games (but of course the article I read this is in didn't list any games that did this, I also know that the Famicom also had the four player tap like we had in the States), so I would suspect that there would be a piece of code in the game telling it to read from wired controller 1 OR the expansion port. (but then remember the AV Famicom had pluggable controllers just like the NES! It would seem unlikely they would do that if a bunch of old Famicom games would stop working.) Anyone ever dig around in the Famicom's inner workings and know for sure?