Search the Community
Showing results for tags 'assembly'.
-
One thing that has always bothered me about Super Breakout on the 2600 was the colors & sounds. I like the original game's much better and would love to be able to hack Super to use those. I know nothing about programming the 2600 (but I know the very basics of 6250 assembly). I have been playing around with running code at 8bitworkshop and was wondering if anyone had a disassembly of breakout and super breakout or could lend a hand in modding the game?
- 2 replies
-
- breakout
- superbreakout
-
(and 3 more)
Tagged with:
-
Anyone feel like writing a MegaDemo? Well now you can! Here are two versions of an assembler that was used extensively for demo coding back in the day: http://www.pouet.net/prod.php?which=47999 http://www.pouet.net/prod.php?which=62372 (apparently this one includes a manual) If anyone knows of other assemblers that are good for this sort of thing, feel free to post links in this thread.
-
Hey everyone, I'm very new to programming with assembly. Anyways, from the tutorial in this section of the forums I played around with the first kernel that is presented in Session 8. I made the lines alternate their colors with it. I ran it with SECAM60 after being satisfied, and wow is it an eyesore. I attached an image of the screen when I ran it. Challenge: look at the SECAM60 screenshot for 30 seconds and then turn away. pantomchap_test_game_5-17-2017-2.27PM.bin
-
- secam60
- programming
-
(and 3 more)
Tagged with:
-
Hi, I think I'm doing something dumb but... I cannot see it. I have the address of a sub routine in a variable (System Ram location). I can branch on this address using @@loop CALL WAITVBL ; wait for VBlank ; jump to the current main routine MVI SUBROUT, R1 JR R1 B @@loop ; loop forever But in this case the return address is not set in R5 so within my sub routine, JR R5 won't come back to the @@loop So currently my sub routine ends with B @@loop but that's ugly. Is there a way to do something JSR R1 ? Note, as SUBROUT points to different subroutines along the time, I cannot do B @@ASUBROUT. Thanks....
-
I'm looking for a couple of utility disks that don't seem to be in any of the archives. QuickCode is a set of macros for use with Mac/65: QuickCode - Atarimania FlashBack is a backup program for use with SpartaDOS: FlashBack - Atarimania Info for both can also be found here: Antic Reviews - Power Tools If anybody has an ATR of either of these to share, or has a real copy and would be so kind as to make an image, it would be greatly appreciated. Thanks, MF
-
Hey all, Here is a question... so the TI disk system reserves space at the top of VDP memory for file buffers. You can reduce this by from 3 file support to 1 by calling the FILES subprogram, but it still takes up space from about >3B00 onwards. My question is... can you safely wipe out this section, say if you wanted to put the sprite pattern table at >3800 onwards? Obviously it would trash the sprite pattern table if you had to do a file load later on, but if you could restore the data from CPU memory afterwards it seems alright. Obviously it would be stupid to try and do a memory image load INTO this section...
-
Ok Assembler fans... As you may be aware I've been adding levels to the Snowplow game (NYD2017) from analog mag #64. Please can someone take a look at the assembly code (MAC/65 & commented, listed in the mag also) and see why the game only loads two extra levels before returning to the inbuilt first level which is hard coded. As far as I read it should support multiple level files. Comments say it will load files in disk order. Looks like it does a directory using CIO. I noticed on line 8530 in the GETDIR routine it has a CMP #'F which I thought was a typo, but it's in the magazine listing too. " ' F " looks like it assembles as $46/#70 which is "ZDRVA" in mapping the atari - if this is any help. It's checking something in the buffer against this and then going to the inbuilt level or not. Was this a typo or something clever? SNOWPLOW-TESTING.ATR On the DOS disk attached is code: SNOW.PT1 AND .PT2 game: snowplow.com test levels: SMAP.A-F, which have 1 blob of scenery to represent the level # and a short road so you can complete them quickly You need to complete the first screen to reach these. The game returns to the title screen after each level and you need to press start to load the next one (providing you have a man left) The first (inbuilt) level starts with 180 fuel and this drops by 10 on each subsequent level. Thanks Jason
- 18 replies
-
I'm having a lot of trouble getting started with assembly. Any tips? Example programs? Anything of the sort would be nice.
-
Nox Archaist is a new role playing game in development by 6502 Workshop exclusively for the Apple II platform and emulators, with floppy and hard disk support. We are excited to announce the first in a series of mini stories using the Nox Archaist engine to demo the newest features in the game. The Nox Archaist story line is still under development. Any names or characters used in these mini stories are not intended to depict real or imagined NPCs, events, or bovines in the actual game. Any similarities are coincidental. ----Nox Archaist S1E1: Shattered Sword---- In this episode our hero travels to town and faces an epic struggle to get his sword repaired after breaking it over an ogre's head. http://www.6502workshop.com/2016/11/nox-archaist-s1e1-shattered-sword.html New game play elements to look for in this video include: *Conversation with NPCs *NPCs moving between locations on the map based on their daily schedule *New interactive tiles ----About Nox Archaist---- Nox Archaist, by 6502 Workshop, is a 2D tile based fantasy RPG with a classic Apple II look and feel. Our mission is to develop a modern evolution of the Apple II RPG genre, while exploring how gameplay might have advanced in tile-based RPGs if large scale development had continued on the Apple II platform after the 1980s. http://www.noxarchaist.com
-
What is the standard practice when configuring memory for programs written in assembly on the Atari 8bit? I can think of three ways to do it: Static definition, macro driven and allocation at run time. -The first two are akin to hardcoding and would still have to be compiled for a specific memory size. For example, if you had a game that could fit in 16k, you would just set your RAMTOP, Screen Memory, Player memory, etc accordingly and it should run on any Atari 400, 800, XL, XE that had 16k or more memory. Is this correct? -Would there be any advantage, in terms of compatibility, to using the third (runtime allocation)? In assembly, I see this as a slight disadvantage because references to screen memory, player location, etc. become more difficult or add cycles using indirect indexing.
-
We are excited to introduce Nox Archaist, a new role playing game we are developing exclusively for the Apple II platform and emulators. Currently we are targeting a release date late this year. Nox Archaist will be available 100% free and the complete assembly source code will be posted on our blog. One area that we have been kind of winging is tile graphics art. We would like to offer a chance for members of the retro gaming community to participate in the design of Nox Archaist while hopefully improving the final result and getting the game into your hands more quickly. We are running a tile graphics contest! The top three submitted tiles will be determined on 7-31-2016 and the winners will receive the benefits below: *One custom in-game NPC named and based on input from the winner *Copy of the initial release of Nox Archaist on 5.25” floppy disks *Pre-release digital copy of Nox Archaist *Printed manual *Name mentioned in Nox Archaist game credits *Announcement of winners on our blog and in this forum *Any other goodies we can come up with To participate, just send us one or more tile designs using the criteria provided at the link below. Submissions can be sent via email to contest@6502workshop.com. Here is a link with contest details: http://www.6502workshop.com/p/graphics-contest-rules.html =====ABOUT NOX ARCHAIST===== Nox Archaist is a 2D tile based fantasy RPG with a classic Apple II look and feel. We are taking advantage of the full 128k available on the IIe and later models which will help us create features and effects that may not have been seen in vintage 1980s Apple games. Our goal is to explore how gameplay might have advanced in tile-based RPGs if substantial development had continued on the Apple II platform past the late 1980s. Game play videos and screenshots showing the current evolution of the Nox Archaist game engine are available below. http://www.6502workshop.com- Nox Archaist website with our blog, current gameplay videos, screenshots, and gifs. - Demo gameplay video featuring the current game engine. - Demo gameplay video featuring sunrise/sunset and in-game clock features
-
I am confused with certain tutorials on whether to make certain routines part of the main file or start a new one for that routine? (The tutorials on SuperFamicom.org and SMS Power don't clarify this, which is why I asked.)
- 4 replies
-
- Assembly
- Commodore 64
-
(and 1 more)
Tagged with:
-
Hey all, I've posted about this before and got positive reception, so I'm trying to bring more attention to it. Any feedback is appreciated, although there's not much space left in the ROM for new features. This is an Atari 2600 homebrew game that's been in development for a while, and I believe it's finished now. It's a 4K, single player paddle game with SaveKey/AtariVox support. Plot: In this game, you must use the paddle controllers to steer your car left and right, avoiding obstacles in your path while collecting treasures. When you touch a treasure, you will get 1500 points and it will be added to your collection (the yellow dots on the left side of the status bar). You can have up to 5 treasures in your collection at a time. At any point, you can press the paddle controller's trigger to "burn" a treasure, giving you the energy to jump a short distance over any obstacles in your path. Any treasures you have left when your game ends will grant you an extra 1500 points. The game is won upon reaching 99,999 points. There are different kinds of treasures. Some of them will grant you unique powers: Gold coin: Does not grant any powers, is only worth points. Necklace: Gives you an extra life (the red dots on the right side of the status bar). You can have up to four lives at a time. Jar: Lets you pass through all barriers for a few seconds. Statuette: Lets you jump as much as you want with no penalties for a few seconds. The game will speed up when you get enough points. There will be a transition period where the game stops generating obstacles briefly, and the speed-up will occur while there are no obstacles on the screen. The difficulty switches toggle certain features. I highly recommend setting both to A for the full experience (Note: Stella sets both to B by default): - The left difficulty switch will make obstacles farther apart (B) or closer together (A). - The right difficulty switch turns moving obstacles off (B) or on (A). If the game feels too easy for you, enable Speed Freak mode! Simply press the game select switch at any point. When the title screen's background is red, this mode is enabled. Finally, the most important feature: if you press the paddle trigger while you have no treasures in your collection, you can honk the horn! Wow! As previously mentioned, the SaveKey and AtariVox are fully compatible for saving high scores (although there are no AtariVox speech functions). It saves unique high scores for Normal and Speed Freak modes. If you want to clear your high scores, press the game select and game reset switches at the same time. Drive! v1.4 NTSC.bin Drive! v1.4 PAL.bin Additionaly, here's a possible label I have for now:
-
This question is specifically about cartridge development using assembly language. I have noticed with all of the assemblers that I've used, it is necessary to set AORG >6000 at the begining of the file to produce any output (otherwise the resulting binary file is filled with zeros). If I set the origin to >6000 at the begining of the file, then copy some code (say to >2000) and attempt to set AORG >2000 later, the subsequent symbols have the proper values, but the output past the second AORG is all zeros! Does anyone know why this is, or how I can achieve what I am attempting to achieve? If it helps, I'm currently using xa99 for assembling and l99 for linking. Thanks! Edit: I have also tried RORG and DORG, though I admittedly don't really understand what these are supposed to do
-
Just a quick question regarding illegal opcodes. Have there ever been any cases where such opcodes work on one machine but act erratically on another? Not sure if there are different revisions of 6502s in different 7800s or not. I'm not going crazy with them so far, and have found LAX #$00 ( #$A7 #$00 ) to be handy in a few places, but I'd like a bit of peace of mind they'll work across the board. Thanks in advance!
-
Hello! Based on user input, I took my game, Jet!, and turned it into a new game: Drive! I decided to make this a new topic to avoid confusion. Story: This is a 4K, single player paddle game, made entirely in assembly, in which you must move your car left and right to dodge obstacles as you drive down the bridge. As you drive, you will encounter treasures (dots on the ground). When you collect a treasure, you will gain 1500 points and it will be added to your collection (the gold dots on the left side of the status bar). You can have up to five treasures in your collection at a time. You can press the paddle's trigger to "burn" a treasure, which gives you the energy to jump a short distance. Any treasures you have when your game ends will grant you an extra 1000 points. The game is won upon reaching 99999 points. In addition, certain treasures will grant you extra powers: - Red: Gives you an extra life (the pink dots on the right side of the status bar). You can have up to 4 lives at a time. - Green: Makes you invincible for a few seconds. - Purple: Allows you to jump as much as you want for a few seconds with no penalties. Oh yeah, and if you press the paddle trigger when you have no treasures in your collection, you can honk the horn. So there's that. At certain points, the game will speed up. The game will stop generating obstacles for a few seconds, and the speed-up will occur while there are no obstacles on the screen. Finally, the difficulty switches toggle certain functions: - The left difficulty switch will make obstacles farther apart (B) or closer together (A). - The right difficulty switch turns moving platforms off (B) or on (A). Set both to A for the ultimate experience! (Note: Stella sets both to B by default.) I'm very interested to see what everyone thinks of the new direction this game has taken! === UPDATE: v1.1 === What's new: - Introducing speed freak mode! Press the game select switch on the title screen to access this. This makes the game run at hyper speed, so good luck! Combine with both difficulty switches on A for a real challenge! - Better sound and colours for both NTSC and PAL. - Purple powerup has been changed to blue to make it more distinct. - Each treasure in your collection now adds 1500 points instead of 1000 when your game ends. - A few bug fixes. === UPDATE: v1.2 === What's new: - Full SaveKey/AtariVox support! It will save two different high scores depending on which difficulty you have selected on the title screen. Press the game select and game reset switches together to delete your high scores. - You can now switch difficulty modes without going back to the title screen. Simply press the game select switch at any point. - Jerky scrolling is finally fixed. - Treasures now have defined graphics: Gold coin: Takes the place of the gold treasure (no powerup other than the default). Necklace: Takes the place of the red treasure (adds an extra life). Jar: Takes the place of the green treasure (makes you invincible for a few seconds). Statuette: Takes the place of the purple/blue treasure (allows you to jump with no penalty for a few seconds). - You accumulate points faster when you have below 50000 points, meaning it takes about half as long to reach full speed. - Other graphical improvements. === UPDATE: v1.3 === - Fixed a few bugs. - Now has a standard PAL version. === UPDATE: v1.4 === - PAL version should work perfectly. - Updates to Speed Freak mode. Drive! v1.4 NTSC.bin Drive! v1.4 PAL.bin
-
I was wondering if someone has already done a commented disassembly of Breakout. There are still some mysteries to me, for example how the paddle reflects the ball. I found this in the manual: "The paddle is divided into five sections. Note that the ball bounces off each section at progressively smaller angles after the third, seventh, and eleventh hit. After the twelfth hit, the angle returns to its original size." This makes it sound like it's tracking the number of times the ball has hit one of the paddle sections, and depending on how many hits that section has taken, it'll reflect at a different angle... Anyway, if nobody's disassembled and commented Breakout I may be up to the task!
-
I've been playing around with user ISRs, and I'm somewhat puzzled by the result of this program: . main: lwpi ws li r0, handler mov r0, @>83c4 ; set user ISR limi 2 jmp $ position: data 0 handler: mov r11, r10 mov @position, r0 li r1, '# ' bl @vsbw ; standard implementation inc r0 andi r0, >1ff mov r0, @position b *r10 . This does not fill 2/3 of the screen, but simply displays two chars. Even more bizarely, the second char only appears after a couple of seconds. Now I realize that you probably wouldn't want to write to the VDP in the handler itself. In fact, I wouldn't enable interrupts in the first place but use vsync polling in my game instead. But can someone explain to me what is happening here? Is access to the VDP triggering another interrupt?! And what is causing the delay? (This is all in MESS, BTW.)
-
Has anyone thought of using some of the unused opcodes for debugger output instructions? For instance, you could have an instruction PRINT R0 that you insert in the program which would print the current value of R0 to the debugger's console. This would only work on a combination of an assembler and an emulator that understood the new instructions, of course. I assume a real TI would ignore illegal instructions if you left them in (wasting some clock cycles), but usually you would remove them first by setting a switch in the assembler. The instruction set could include instructions for printing registers/PC/ST/CPU/VDP/GROM memory, strings, VDP registers, statuses, etc. The point is that in many cases this would be faster and easier than traditional debugging using single stepping and breakpoints because the debugger output would be resistant to program changes that shifts the memory addresses around.
-
I want to read disk sectors using PAB >0110 and DSRLNK >A. This kind of worked, after I moved my workspace out of harms way. And yet, it wouldn't read beyond sector 0 for my sample disk. No matter which sector I put into >8350, I always got sector 0. After much hair pulling, I discovered that the read routine won't work for disks with random data on them, i.e., for disks without a (partially) valid TI file system. After I fudged a plausible sector 0 it works like a charm. So what's the magic ingredient -- the sector allocation table, disk geometry, number of AUs? And if reading sectors depends on sector 0, how is sector 0 read?
-
I understand that it would be good practice to "restore" the previous VBI routine address when "unhooking" a VBI routine that is no longer used. But where would I get the address to restore to from? Can I simply read it from VVBLKI? Do I assume correctly that if VBI program A is installed first and saves the correct address to restore to, and VBI program B is installed thereafter, uninstalling A would kill B as well as A knows nothing of B. Or ist there a defined way to tell a "previous" VBI routine about another one installed later? Thanks!
-
Probably lots of people had this idea already, and I've been reading about TMS9900 assembly only sporadically. Let CALLEE be the address of a subroutine like this: CALLEE (instruction) (instruction) (instruction) ... RTWP And my idea for a "reentrant call": STWP R8 S 36,R8 MOV R8, @32(R8) MOV CALLEE, @34(R8) BLWP @32(R8) Could be turned into a macro, and the trashed register cound be any one that doesn't have a special use (R12-R15). I did this on paper only, so it may have a few holes. Also, this is NOT for hardware interrupts! And, of course, for machines with a respectable amount of RAM -- definitely not a base 99/4A! So, makes sense? Is it horribly slow and wasteful and a much better method exists? EDIT: No, wait, wait. I don't need that additional space for the transfer vector. It can be located in the middle of the new workspace. STWP R8 S 32,R8 MOV R8, @8(R8) MOV CALLEE, @10(R8) BLWP @8(R8) EDIT II, THE SEQUEL: And if I didn't mind trashing the first few registers of my current WP I could even make them overlap! What do you think?
-
Hi, everyone. I finally decided to start really learning how to program the VCS. I already have a general idea of how the VCS builds a picture line by line and sets up the appropriate blanking and syncronization inbetween frames, so I wrote a little assembly file to confirm if I actually know what I'm doing (all it's supposed to do is increment X and set PF1 and COLUPF to that value once every frame). However, every time I've tried assembling it with DASM the past few days, DASM trips up on something in the file and can't resolve any of the labels I've set up. What's more, the list file DASM produced reports "Unknown Mnemonic" errors on every single line of the assembly file. I'm using DASM v2.20.11 for Windows with v1.05 of vcs.h and v1.06 of macro.h. The command line I used is "dasm bartest2.asm -f3 -v4 -Lbars-l.txt -sbars-s.txt -obartest2.bin". Below is the assembly and DASM's output, and I've attached the list file. Is there some boneheaded fundamental mistake I'm making? Assembly: PROCESSOR 6502 INCLUDE "vcs.h" INCLUDE "macro.h" ORG $f800 init: CLEAN_START lda #2 sta VBLANK startFrame: VERTICAL_SYNC lda #44 sta TIM64T vertBlank: sta WSYNC lda INTIM bne vertBlank stx PF1 stx COLUPF lda #0 sta VBLANK ldy #191 sta WSYNC kernel: sta WSYNC dey bne kernel inx lda #2 sta VBLANK lda #35 sta TIM64T overscan: sta WSYNC lda INTIM bne overscan jmp startFrame ORG $fffa .word init ; NMI .word init ; Reset .word init ; IRQ DASM output: START OF PASS: 1 Including file "bartest2.asm" ---------------------------------------------------------------------- SEGMENT NAME INIT PC INIT RPC FINAL PC FINAL RPC INITIAL CODE SEGMENT 0000 ???? 0000 ???? ---------------------------------------------------------------------- 0 references to unknown symbols. 0 events requiring another assembler pass. --- Symbol List (sorted by symbol) init 0000 ???? kernel 0000 ???? overscan 0000 ???? startFrame 0000 ???? vertBlank 0000 ???? --- End of Symbol List. --- Unresolved Symbol List overscan 0000 ???? startFrame 0000 ???? init 0000 ???? kernel 0000 ???? vertBlank 0000 ???? --- 5 Unresolved Symbols Thanks in advance for any help! bars-l.txt
-
Operating from a Windows PC development environment, I would like to be able to test my 6502 Assembly code. So, for example: I might have this code: org $0600 CLC LDA #5 ADC #3 STA 203 <end of code> I would like to be able to execute a command from the PC which will check that the above code puts the value of '8' into memory location 203. It may run Altirra or a 6502 emulator in the background, but I need to be able to extract that memory location and then report it back to the calling program. At the end I want "Test passed" or "Test failed" or something similar displaying. This way I can build up an automated test suite for all of my procedures / sections of code / macros. I have no problem with it bringing up windows whilst testing is going on, but I want all of the windows closed at the end of the tests. Any ideas of the best way of implementing this? I guess I'd need to automatically dump the memory contents and then extract the memory values that I require...
-
All, I'm trying to write some simple (I would have thought) code to pause for a little while using the real time clock. Here it is: .proc pause LDA #0 STA 20 ;CLOCK_C LDA #200 WAIT_A_BIT: CMP 20 ;CLOCK_C BCC WAIT_A_BIT RTS .endp So I am setting the jiffy count to 0 and then waiting until 200 jiffies have passed. What I don't understand is that the code runs through immediately, but I would have thought that it would have required about 4 seconds on a PAL system. What am I doing wrong? Probably something simple. Is it my use of BCC?