Search the Community
Showing results for tags 'assembly language'.
Found 25 results
-
Youtuber 8 bits in the basement has decided to learn 6809 assembly and port his atari basic game to the Coco ! Here is his progress so far..
-
Hello there, I'm trying to learn the 6502 assembly language by writing a very simple shoot game for the C64. Nothing complicated : a couple of moving sprites, a player, a weapon.😄 For now, I'm looking for a way to move a sprite back and forth horizontally on the screen. $d000 is the X coordinate of my sprite. So I want this register to move from 0 to $FF, then back from $FF to 0. But not in a simple loop, so I tried something like this inside my main game loop : "ennemyState" is a register. set it to 0 Main game loop: check if "ennemyState" is > 1 or not if > 1, increment $d000 if < 1, decrement $d000 if $d000 ==0 : check ennemyState ==0, set it to 2. Else, set it to 0 instead. (to swap the increment) ... do other things jump to main game loop. And, in assembly (I removed some additional code for clarity) : incrementEnnemi = $0003 ; dummy memory address jsr $e544 ; clear screen routine lda #$03 ; set color sta $d020 ; border color lda #$00 ; black color sta $d021 ; main central screen lda #$80 sta $07f8 ; adress pointer sprite 1 lda #$03 sta $d027 ; color sprite 1 lda #$80 ; 128 to start sta $d000 ; x position sprite 1 lda #$80 sta $d001 ; y position sprite 1 lda #%0000001 ; show sprite 1 sta $d015 lda #$010 sta incrementEnnemi mainLoop: ; main loop jsr loopNop ;wait a bit lda #$02 ; check if ennemy must go left to right or right to left cmp incrementEnnemi ; http://6502.org/tutorials/compare_instructions.html bcc move_ennemy_right ;comparison move_ennemy_left: ldx $d000 ;move sprite dex stx $d000 jmp checkEnnemyPosition move_ennemy_right: ldx $d000 ;move sprite inx stx $d000 jmp checkEnnemyPosition checkEnnemyPosition: ;check if position ==0 lda $d000 ; if zero set flag bne ennemyDone ; sortie car pas a zero Branch on EQual (zero Z flag set) ; Branch on Not Equal (zero Z flag clear) ;we are =0, so we must change the register value lda #$02 cmp incrementEnnemi bcc ennemy_switchNegative ennemy_switchPositive: lda #$010 sta incrementEnnemi jmp ennemyDone ennemy_switchNegative: lda #$01 sta incrementEnnemi jmp ennemyDone ennemyDone: jmp mainLoop And it works, but as a beginner I wanted to know if there could be a better way to achieve the same result ? I'm using a full byte to check is I must increment or decrement the sprite position, I'm not sure to know how to do the same thing with a single bit. (maybe an AND ?). Or if there is a very easiest way to do this ? And other difficulty, the sprite position can be not only from 0 to 255, but from 0 to 320. To put the sprite coordinate from 255 to 320, I need to set a bit from $d010 to add 256 to my sprite coordinate. Is there a simple way to achieve this, and not using tons of jump and compare operations ? Maybe I'm not familiar yet with the good instructions... Thanks in advance !
-
Here is a video showing how i import sprites to the coco3 and some 6809 code to move / display them.
- 6 replies
-
- 2
-
-
- sprites
- color computer
- (and 5 more)
-
I’ve been working on my own MusicXml parser (https://github.com/bkrug/envelope-demo#readme). As stated in the Readme the parser supports: Storing a separate stream of data for each tone generator Repeats and volta brackets compressing rests to save space storing notes as 7-bit values instead of 10-bit values An accompanying cartridge program plays the output, and also demonstrates adding envelopes to music auto-detection of a 60hz vs 50hz environment playing music at different tempos as specified in a song header I'm not the first person to create a MusicXml parser for TI-99 development, but I think existing parsers are geared towards sound lists. The reason I prefer to have a separate stream of data for each generator, is because that way I can support, for example, a half note played simultaneously with two consecutive quarter notes. My parser is shared as source code, because while another developer could use the compiled parser as is, it's also likely that one would want to add features I didn’t add. For example, the parser doesn't currently support dynamics. The existing repo has high test coverage, so you should be able to add functionality without breaking something you didn’t mean to. MusicEffects.rpk musiceffectsC.bin MusicXmlParser.exe -
Hi All, I had intended on learning assy for drawing on the 8-bits but I need to focus elsewhere. Sorry but I am not interested in trades. EDIT: I had asked for offers but I didn't receive any, so I will do some research and come up with a price. Since I don't have a price I feel like I should remove (or ask to have removed) this post. I will ask Al to do so. Cheers, thank you for your interest. KB
-
I'd like to jump into the TI Basic interpreter coming from an assembly language program running from cartridge space. It's not that I want to run a specific call or so, just start the TI Basic interpreter like selecting option 1 "TI Basic" on the selection screen. Is there any sample code to show how that works? Guess that I basically need to get the GPL interpreter running TI Basic at >216F (?) Was hoping for a vector address in the console ROM that triggers the TI Basic interpreter, but couldn't find it.
-
I recently dug out my Atari 7800 7800 Monitor Cartridge that I bought from Video 61 in August 2000. It's been quite a few years since I've messed around with it. I was showing a friend of mine how it worked. We looked at the three demo programs that are on it (Bumper Tanks, Hex Demo and Color Display), plus we typed in a couple of the very short demonstration programs and tried those too. I suppose that after nearly 20 years the battery in the cartridge that saves the RAM is dead, but I'd still like to play around with this rare cartridge and maybe make a video of it in use since I can't even find video of anyone using it (not even pictures or screenshots of the three demo programs on it). I know that the manual for the 7800 Monitor Cart isn't freely available. This is a shame, as this certainly would get more people interested in the program. I wonder if Video 61 would allow, at least, the manual to be released as a pdf? Did anyone ever write any short subroutines that I could type into this machine language monitor using those trusty keyboard controllers? Are there any generic 7800 programs that I could use with the Monitor carts? Adam
- 4 replies
-
- 1
-
-
- atari 7800
- monitor cart
- (and 2 more)
-
Since the low-byte data lines are not connected to the VDP port, could a word access (MOV R1,@VDPWD) be used instead of a byte access (MOVB R1,@VDPWD)? Just curious, since I thought a word-access is faster than a byte-access. Especially a write operation, since the CPU has to read the word, plug the new byte into it, then write the word out. K-R.
-
While trying to load object files with EA3, I found that an object file larger than 5254 (>1486) bytes will fail with "Error 3." An file of 5254 bytes will load normally. After disassembling the TI LOADER code, I did not find any indication of a file-size limitation. I found this using TI994w, most recent version. Have not tried it in a real TI, yet. K-R.
-
I'm thinking of using these routines I wrote to read/write VDP RAM. Are there any obvious errors? I was thinking of using them to avoid the BLWP that the TI routines use, along with the lack of zero-byte-count checking. These can also sit in the 16-bit workspace that C99 uses. Forgot to mention that these routines are called with BL @VSPEEK, BL @VSPOKE, BL @VMPEEK, BL @VMPOKE. I used these names to avoid conflicts with the Ed-Assem loader. K-R. * vdp.i (TI-name "VDP;I") */ * C'99 Rev#5.1.CC (C)1994 Clint Pulley & Winfried Winkler ***** VDP RAM read/write routines. ***** * File-name pointer is in R8. * External REFerences for TI linker. REF VDPWA,VDPWD,VDPDD * Address definitions to allow these * routines to function without the * TI linker. * * Read VDP data from this address. *VDPRD EQU >8800 * * Read VDP status from this address. *VDPSTA EQU >8802 * * Write VDP data to this address. *VDPWD EQU >8C00 * * Write VDP command or RAM-address * to this address. *VDPWA EQU >8C02 VMPEEK * Get multiple bytes from VDP RAM and * place them in CPU RAM. * R0 = VDP RAM start address. * R1 = CPU RAM start address. * R2 = Byte count. * Save caller's return address on stack. DECT R14 MOV R11,*R14 * Check count for zero. The TI routine * does not check for this. MOV R2,R2 JEQ VMEXIT * If zero, exit. * Save caller's registers. DECT R14 MOV R2,*R14 DECT R14 MOV R1,*R14 DECT R14 MOV R0,*R14 * Set VDP read-address. ANDI R0,>3FFF BL @VMADDR VMLOOP * Get VDP data and place in * caller's buffer. MOVB @VDPRD,*R1+ * Done? If not, get another byte. DEC R2 JNE VMLOOP * Restore caller's registers. MOV *R14+,R0 MOV *R14+,R1 MOV *R14+,R2 VREXIT * Restore caller's return address, * then exit. MOV *R14+,R11 B *R11 VMPOKE * Send multiple bytes from CPU RAM * and place them in VDP RAM. * R0 = VDP RAM start address. * R1 = CPU RAM start address. * R2 = Byte count. * Save caller's return address on stack. DECT R14 MOV R11,*R14 * Check count for zero. The TI routine * does not check for this. MOV R2,R2 JEQ VMEXIT * If zero, exit. * Save caller's registers. DECT R14 MOV R2,*R14 DECT R14 MOV R1,*R14 DECT R14 MOV R0,*R14 * Set VDP read-address. ANDI R0,>3FFF ORI R0,>4000 BL @VMADDR VMLOOP * Get VDP data and place in * caller's buffer. MOVB *R1+,@VDPWD * Done? If not, get another byte. DEC R2 JNE VMLOOP * Restore caller's registers. MOV *R14+,R0 MOV *R14+,R1 MOV *R14+,R2 VWEXIT * Restore caller's return address, * then exit. MOV *R14+,R11 B *R11 VSPEEK * Get a byte from VDP RAM and place * in R1 MS byte. * * R0 = VDP RAM address. * R1 (MS Byte) = Data byte. * Save caller's return address on stack. DECT R14 MOV R11,*R14 * Save caller's registers. DECT R14 MOV R1,*R14 DECT R14 MOV R0,*R14 * Set VDP read-address. ANDI R0,>3FFF BL @VMADDR * Get VDP data and place in * caller's R1 MS byte. MOVB @VDPRD,R1 * Restore caller's registers. MOV *R14+,R0 MOV *R14+,R1 * Restore caller's return address, * then exit. MOV *R14+,R11 B *R11 VSPOKE * Send byte in R1 MS byte to VDP RAM. * R0 = VDP RAM address. * R1 (MS Byte) = Data byte. * Save caller's return address on stack. DECT R14 MOV R11,*R14 * Save caller's registers. DECT R14 MOV R1,*R14 DECT R14 MOV R0,*R14 * Set VDP read-address. ANDI R0,>3FFF ORI R0,>4000 BL @VMADDR * Get VDP data and place in * caller's buffer. MOVB R1,@VDPWD * Restore caller's registers. MOV *R14+,R0 MOV *R14+,R1 * Restore caller's return address, * then exit. MOV *R14+,R11 B *R11 VMADDR * Send address to VDP. * This routine expects address in R0. * Send LS byte of address. SWPB R0 MOVB R0,@VDPWA * Send MS byte of address. SWPB R0 MOVB R0,@VDPWA * Return to caller. B *R11 EVEN K-R. VDP.i
-
Please reference Chapter 4 of https://ia800307.us.archive.org/10/items/9900MicroprocessorSeriesFamilySystemsDesignDataBook/TexasInstruments9900MicroprocessorSeriesFamilySystemsDesign_text.pdf Starting with page 4-89 and particularly pages 4-91, 4-92, 4-95 and 4-100 The following code sequence appears to take 29 machine cycles: mov @Var,R0 ; 11 cycles ai R0,2 ; 7 cycles mov R0,@Var ; 11 cycles While this only takes 9: inct @Var ; 9 cycles Am I correct? If so, there would appear to be plenty of opportunities for a compiler to optimize code like this.
-
For use in my raycaster project, I present this challenge: write the fastest possible routine to copy any number of bytes (even or odd) from any address in CPU memory (even or odd) to any other address in CPU memory (even or odd). The ability to handle both odd and even addresses is essential, and exactly the specified number of bytes must be copied. There is no need to support overlapping memory regions. Self-modifying code is acceptable. Here is what I'm after, only faster: * r0: source, r1: destination, r2: count copy: movb *r0+,*r1+ dec r2 jne copy rt
-
As mentioned in another thread, the following code to add a small constant to a variable: 00037 * W0 := W0 + 2; 00038 00039 * * 0 := v W0 -> 1 00040 * * 1 L r 2 00041 00042 * * 2 L v W0 -> 3 00043 * * 3 + c 2 00044 00045 00046 * 1 L r 2 00047 * 2 L v W0 -> 3 00048 * 3 + c 2 0052 C020 002E 00049 mov @W0,R0 0056 05C0 00050 inct R0 00051 * 0 := v W0 -> 1 0058 C800 002E 00052 mov R0,@W0 can be optimized to this: 00037 * W0 := W0 + 2; 00038 00039 * * 0 := v W0 -> 1 00040 * * 1 L r 2 00041 00042 * * 2 L v W0 -> 3 00043 * * 3 + c 2 00044 00045 00046 * 1 L r 2 00047 * 2 L v W0 -> 3 00048 * 3 + c 2 0052 05E0 002E 00049 inct @W0 00050 * 0 := v W0 -> 1 This is the code to add two signed bytes resulting in a 16-bit number. Is there a better way to do sign extension? 00037 * W0 := S1 + S2; 00038 00039 * * 0 := v W0 -> 1 00040 * * 1 L r 2 00041 00042 * * 2 L v S1 -> 3 00043 * * 3 + v S2 00044 00045 00046 * 1 L r 2 00047 * 2 L v S1 -> 3 00048 * 3 + v S2 0052 04C0 00049 clr R0 0054 D020 0037 00050 movb @S1,R0 0058 1502 (005E) 00051 jgt 2f 005A 0260 00FF 00052 ori R0,>FF 005E 00053 2 005E 06C0 00054 swpb R0 0060 04C1 00055 clr R1 0062 D060 0038 00056 movb @S2,R1 0066 1502 (006C) 00057 jgt 2f 0068 0261 00FF 00058 ori R1,>FF 006C 00059 2 006C 06C1 00060 swpb R1 006E A001 00061 a R1,R0 00062 * 0 := v W0 -> 1 0070 C800 002E 00063 mov R0,@W0
-
Does anyone here write unit tests for your Assembly Language projects? What is your preferred coding format for doing so? The below is my approach. ARYINS is the routine being tested. AEQ and ANEQ stand for "Assert Equal" and "Assert Not Equal", respectively. They are comparing the contents of R0 and R1. * * Insert an element at the middle of * an array. * Grow array and move it. * No empty block follows the original. INS5 * Arrange LI R0,INS5Y MOV R0,@BUFADR LI R0,INS5Z MOV R0,@BUFEND * Act LI R0,INS5X+2 LI R1,3 BLWP @ARYINS MOV R0,R9 MOV R1,R10 * Assert LI R0,INS5X+2 MOV R9,R1 BLWP @ANEQ TEXT 'Array should have moved.' BYTE 0 EVEN * MOV R9,R0 AI R0,4+12 MOV R10,R1 BLWP @AEQ TEXT 'Element address should be ' TEXT 'directly after the third ' TEXT 'element.' BYTE 0 EVEN . . . RT
-
I just posted my latest project that provides a BASIC XL program for interacting directly with the 6502 processor registers through a simple point-and-click interface controlled by the joystick. I have been working on this program for my planned exhibit at VCF East in April, but that has been postponed until October. I am pretty happy with how this turned out. Note that this is not a simulation. Each click calls an assembly language program that runs the op code. Comments welcome! http://atariprojects.org/2020/03/14/interact-with-ataris-6502-processor-in-basic-10-15-mins/ i6502.txt i6502.atr
-
I rolled up a quick-n-dirty simple retro birthday card for a friend. (No music. Maybe for next year's card.) (And, No, FillInTheBlank is not their actual name. ) Assembly code. Redefined character sets do the animated flames. Display kernel updating colors on every scan line. lots of laziness in evidence. Too lazy to actually do a VBI or DLI. Assembly code is here if anyone is interested: https://github.com/kenjennings/WIP-HBFITB Video is on youTube: https://youtu.be/WLELDFDT3uM
-
- 7
-
-
- atari 800
- assembly language
- (and 2 more)
-
I need to add two 16-bit integers (let's call them A and B; A is signed, B isn't) and get the result, less 1. Sure I can do a 16-bit decrement on the result of the addition, but 16-bit DECs require a branch instruction (for MSB roll-over) and I'm trying to save cycles. I considered using a 256 byte look up table of the index value less 1, but this comes unstuck when then LSB is zero, since element 0 is $FF: ldx a lda Less1Tab,x clc adc b sta c lda a+1 adc b+1 sta c+1 rts Less1Tab .byte $FF ?Value = $0 .rept 255 .byte ?Value ?Value = ?Value+1 .endr Making the first element of the LUT $FF seemed like a great idea until I realized it sets the carry flag when subtracting 1 from 0, messing up the MSB. Any more complex and it'll be easier to DEC the result. Any ingenious ideas?
-
Hey everybody, I apologize if anyone has asked these question before -- I tried searching with limited success. I am working on writing a roguelike for the INTV, now using IntyBASIC ideally to be part of the contest. The problem is that the program I want to write, including its art assets, is kind of huge and unwieldy and I have genuine worries that I'm not going to be able to cram everything I'd like into the address space. The IntyBASIC manual has this to say about the subject: The memory_map.txt file in the SDK, however, has what appears to be a much larger selection of addresses: So, the questions I have: Does IntyBASIC attach to the areas listed in the memory map but not listed in its documentation ($4000-$4FFF, $7000-$7FFF, $8040-$9FFF) in order to store variables? What about its prologue/epilogue routines? Clearly those routines have to go somewhere, but I'm a little confused about what determines where they show up. The prologue looks like it starts at $5000 and it looks like the epilogue is using some of the address space in the $4000 block to store some routines, but is there any extra space that can be squeezed out of these areas? There is no ORG directive at the beginning of the epilogue. Do those routines just go wherever the compiler's location counter happens to be pointing when it goes to include this? Will I need to worry about the epilogue writing itself to bizarre or inappropriate places if my code stops near one of the memory boundaries, or will the BASIC compiler make sure that doesn't happen? Where is the entry point for IntyBASIC programs? I'd like to make a custom title screen if possible. If I start my program with ASM ORG $7000, will it begin execution there and bypass the EXEC? (Does IntyBASIC need the EXEC?) I noticed that there's some code at $4800 in the epilogue pertaining to the Intellivoice, but it looks like it may not be present if the Intellivoice isn't used. (I realize half the reason for using BASIC instead of assembly language is to not have to worry about fiddly details like this, but I want to make good, appropriate decisions about how to organize my program and figure out what all I will be able to include as far as assets go before I begin any major coding.) Thanks a bunch! -
I could probably work this out with enough time, but I guess that enough of you clever people know how to do something like this.... I have an integer stored as a byte which can be a value of between 0 and 99 inclusive. I then want to create a filename, so I need this number as text. If the integer is between 0 and 9 inclusive, I would like to print it as "07" (i.e. a zero at the start). If the integer is greater than 9 and will always be less than 100, I just want the number as the 1st 2 bytes of the filename. I want some compact code to do this, could I use CIOV somehow? Or can I do better with your code? -
.thumb.png.ded02932a275f1b65822894720661bc4.png)
Assembly Language Programming for the Atari Computers
MrFish posted a topic in Atari 8-Bit Computers
Bookmarked this puppy. Thanks to ThumpNugget -- who I believe did the original scan. Bon appétit! Assembly Language Programming for the Atari Computers
- 33 replies
-
- 4
-
-
- Byte Magazine
- Assembler
- (and 4 more)
-
My son recently expressed interest in learning programming. Instead of fumbling my way through it I decided to make a series of lessons on programming. This is the first one. I hope you guys enjoy it. https://www.youtube.com/watch?v=gEj3NbChJx8
- 2 replies
-
- 2
-
-
- 6502
- Assembly Language
- (and 1 more)
-
Hi guys, New to the site but, a longtime vcs fanatic. I also play OSU! on my spare time as i love elite beat agents. I was wondering how difficult it would be to create a simple port of Osu!. Here is a small video of it in action. I have been reading andrews assembly language tutorials and know some assembly language. I also own a an Atari 2600 and Harmonary cart. From read the technical specs, it looks like i will have to simplify it quite a bit. Can someone please tell me the feasibility of this? Any assistance in this matter would be greatly appreciated. Sincerely, Vcsu!
-
Folks: Hi ho, Apple users. I have a few Apple programming guidebooks which I am putting up on Ebay. Some are already up, some more are going up today/this week. I play around with TI and Commodore, but not Apple, so I don't have a whole lot of use for them, though they are great books. Putting most of them up for around $10. Not really trying to make bank on these, just picking up a little cash for a few toys Santa seemingly forgot to bring. ^_^ I also have a random Tandy 1400HD power supply and a Vtech LCD Talking Baseball game up. Tandy PS is tested and working, but having no Tandy 1400HD, etc etc. Talking Baseball is ubercheese but the voice cracks me up. Auctions: Beginners guide to Apple II assembly language eBay Auction -- Item Number: 201013141026 Nibble Expresses -collected snippets and code for Apple from Nibble Magazine, 150-200 pages each eBay Auction -- Item Number: 201013138578 eBay Auction -- Item Number: 201013136901 eBay Auction -- Item Number: 201013074044 eBay Auction -- Item Number: 201013308513 eBay Auction -- Item Number: 201013307938 More Apple Secrets from nibble eBay Auction -- Item Number: 201013311895 (Edit - More added) Applesoft BASIC Toolbox eBay Auction -- Item Number: 201013314361 Basic Apple BASIC (Integer & Applesoft FP) eBay Auction -- Item Number: 201013312998 I'll be adding a few more books to the above in the near future. Tandy 1400HD power supply eBay Auction -- Item Number: 201006101600 Vtech talking baseball eBay Auction -- Item Number: 201011770776 -
I know this is very elementary, but I have a couple simple questions for you guys. LOOP BLWP @VSBW INC R0 DEC R2 JNE LOOP How does JNE know to look at R2 here... is it the fact that R2 was the last register referred to in the source? For instance, if the code was written: DEC R2 INC R0 JNE LOOP Then would JNE look at R0? I don't have any reference material on me right now, and my slow-ass tethered internet is not allowing me to DL anything to help me out. Sorry. =) **I have a couple more questions as well, but I'm going to read through the assembly threads on here before I start asking questions which have already been answered. This forum is amazing for knowledge. =)
-
Here's a funny little perl script I made that tries to find the offset in the OS ROM of all values between 0-FFFF, generating the required equates. It expects that a binary file with the TI-99/4A OS ROM (not GROM!) is available in the current directory. NOTE: Due to lincense issues, I can't share the TI-99/4A ROM image. However if you are using MESS for emulating the TI-99/4A you already have it. Click on the spoiler button for viewing the source code. EDIT: Somehow the formatting gets screwed when copying it into atariage, stange. Oh well, you get the idea. I tried it using activestate perl on windows, but suppose it should run the same with plain vanilla perl on linux. So what is this good for? It can save you a few data statements in your assembly language program, if the value you want to access is already present in the OS ROM. Also due to the fact that the OS ROM is 16bit, there is no speed penalty. The main reason for me implementing this is to make the spectra2 library a bit smaller by removing unnecessary data statements, squeezing the most out of the 8K cartridge ROM space. The below equates files were produced by the script. The first one is the hex version and the second one is the decimal version. In the value range 0-FFFF, 1632 mathing values were found. Not bad considering this is only a 8K ROM. tiromequh.asm tiromequd.asm Note that the Asm994a assembler chokes with a "Out of symbol table space" when both files are included, but works fine if only using one of both. As far as I know all TI-99/4A revisions used the same OS ROM, this was already discussed here on Atariage about a year ago.
.thumb.png.ded02932a275f1b65822894720661bc4.png)
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord