Search the Community
Showing results for tags '6502'.
-
I am having a small issue with my code. I am trying to get the duck to stop when it reaches the top after hitting the flyaway state. However no matter what I try the code gets ignored. Source Code Relevant section Any of you experts have any ideas on what's going on?
-
I've been reading several threads regarding various hard reset schemes people are using or have recommended and every method seems to be convoluted and complicated to deploy when back in the mid-80's many of my friends with Ataris and myself would simply run a momentary push-button switch through a resistor to pin-40 of the 6502 (Sally) chip that would pull the reset pin low while pressing the button. This always seemed to me to be the most elegant solution and the simplest as well. Since pin-40 of the processor is the RESET pin, logically this would be the right path. Since the pin is pulled high through a resistor already, pulling it low (to ground) through a lower value resistor will cause the processor to reset, thus rebooting the computer. The Atari users in my group of friends never had any failures due to this method of choice for hard resetting the Atari. Does anyone know why other more intricate or complicated methods are the only ones talked about now (methods that use TTL chips and focus on various other chips and pins)??
-
This guy has tried to estimate MIPS on some CPUs from the seventies. http://drolez.com/retro/ That doesn't look too good for the 9900. And maybe performance was further crippled, when comparing computers, with the TI-99/4A shoehorn design including multiplexer, wait states and read before write stuff.
-
Hi, I'm new here. I am interested in creating a simple 2 player fighting game similar to Street Fighter or Mortal Kombat. I was wondering before I started coding, how feasible this would be due to the VCS's hardware limitations. I have been reading Andrew Davies tutorial series on the forum as well as have some knowledge of 6502 and M68000 assembly.
-
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 was trying to do something that my feeble memory thought worked 30 years ago in Mac/65 and not getting any joy in atasm. I'm making macros to act as wrappers to function calls in a library of routines. Then I'm conditionally assembling routines in the library, so if they are not referenced, they don't get included and waste space. I was figuring this would work.... (only important parts included) .macro mFunc ; other stuff happens jsr libFunc .endm ; Later in the main code.... mFunc ; Later.... .if .ref libFunc libFunc ; fun stuff ensues rts .endif This does not work. The .ref does not see the libFunc referenced, so it does not build libFunc. Should this work? Or am I insane? If the forward referenced label doesn't work, how about a declared value in the macro like this?... .macro mFunc DO_FUNC .= 1 ; other stuff happens jsr libFunc .endm ; Later in the main code.... mFunc ; Later.... .if .ref DO_FUNC ; and .def does not work either. libFunc ; fun stuff ensues rts .endif DO_FUNC set in the macro is also not seen. neither .ref or .def sees it. Next fallback plan... DO_FUNC .= 0 ; Later on.... .macro mFunc DO_FUNC .= 1 ; other stuff happens jsr libFunc .endm ; Later in the main code.... mFunc ; Later.... .if DO_FUNC>0 libFunc ; fun stuff ensues rts .endif This (annoyingly) does work. DO_FUNC defined outside the scope of a macro can have its value changed in a macro, and THAT value change is seen by the conditional assembly. Rather not have to throw in a bunch of flags in a header file separate from the library file which is included in the end of the assembly.
-
A post was recently made to the Commodore 8-bit forum regarding the game Icebox Plus. It's a slightly different take on Pengo with even easier controls (Joystick only in game). Nonetheless, it is a lot of fun including a nicely managed difficulty ramp. Reason for posting to this forum is the author has made available the entire 6502 assembly language source code for that port which I thought may be of interest to someone.
-
Reverse Engineering the 6502 (52-minute video presentation)
JeremiahK posted a blog entry in My Inner Geek
I stumbled across this video presentation about reverse engineering the MOS 6502, and of course I had to watch it. Quite an interesting watch! I always wondered about the LAX/SAX instructions, and why there aren't similar illegal opcodes for other register combinations. Turns out that the opcode's lower bits define which register is to be worked with, %00 for Y, %10 for A, and %01 for X. %11 is not intended to be used, but when it is used, it causes both A and X to be affected, explaining why we don't an opcode for, say, LAY. As stated in the video, visual6502.org has a lot of information about the 6502 line of processors, and many others, as well. The ultra-high-resolution images of the chip are there, and my nerd wants to print them up and frame them on a wall. I'm not really a hardware guy, more of a software guy, but for some reason I love learning how computers work (or trying to). I guess that's why I prefer the low-level programming languages. Assembly is about as low as you can get without getting into machine code, and it's a lot of fun for something like the Atari 2600. It brings you closer to the machine, and although it doesn't let you see the physical chip layout, it gives you an idea of how it must theoretically work. I would love to try programming for the other old 6502 systems like the NES after I have a 2600 game or two complete, but anything other than that is better suited to a higher-level language. C++ is my favorite language for programming, although Python is nice for simple tasks that you just want to write quickly without worrying about code efficiency. -
This next section is a big one. Wouldn't it be great if you could test code as you programmed it? Well that's where Code-As-You-Go comes into play. The mode can be accessed with a dedicated button on a keyboard. It's labeled "CAYG." Take a look at this: That's the code as you go screen. On the panel at the right, you can enter the data you want to test. On the upper right of the screen is the address that the code will assemble to. In this example, the written code will compile at address $001404. You could instead have it display which line of the source code the code will go in. First, give the subroutine a name. In this example, we have a routine called "TetrisLFSR." This will be a Motorola 68000 version of the NES Tetris RNG routine. The NES version of Tetris iterates its RNG (a 16-bit LFSR) in the following manner: Set the output bit to the XOR of bits 1 and 9, and right-shift that input into the RNG. We will replicate this routine as we enter the code. For this test, enter the input in d0. We need to enter a 16-bit value. Using a mouse, click on the fourth-to-last digit of the d0 register, then type "7259." The digit highlighted in green is the cursor. Note that the register values are displayed in hexadecimal. If you enter an invalid hexadecimal digit, nothing happens. When you enter the last digit, the cursor stays there. (If it were an A-register, the cursor would be red.) Now, time for the first instruction. Type "move.b", tab, then "d0,d2", and hit Enter (if you hit Space, it will tab for you). When you press Enter, the last line of code you wrote is automatically executed in the CAYG window, and its machine language code appears in the window as well. In M68K assembly, the instruction "move.b d0,d2" is represented by $1400. The screen looks like this: Note that after you typed the code line, that instruction automatically executed. The last byte of d0 is $59, so the last byte of d2 is now also $59. The next two instructions are "move.w d0,d1" and "lsr.w #8,d1". These are necessary to retrieve the upper byte of a 16-bit value in d1. After the second line was typed, d1 became $7259. After the third line, it became $0072. In the machine code box is E049, which is the code for "lsr.w #8,d1." Remember, only the compiled code for the last line you typed appears in the machine code box. Next, we want to take the XOR of bits 1 and 9 of the bytes in d1 and d2. Since 1 and 9 differ by exactly 8, no shifting of either byte is needed. Just XOR the bytes by typing "eor.b d2,d1", then pressing Enter. Register d1 is now equal to $2B, which is the XOR of $72 and $59. It is bit 1 from this value we need to extract and get into the X (extend) flag. To do this, type "lsr.b #2,d1", and press Enter. The value in d1 became $0A. But more importantly, look at the X and C flags. They lit up, so their value is 1. Any flag that is clear appears as white-on-black, while a set flag is indicated by the opposite color scheme. Since the XOR of bits 1 and 9 of our 16-bit value was 1, a 1 will be right-shifted in to get the new RNG value. Here is the last piece of the puzzle. Now that we have our output bit in X (and C), we can use a "roxr" instruction to shift it in. Type "roxr.w #1,d0", and hit Enter. And there you have it. The new RNG value is $B92C. With the ability to see the code execute as you type it, coding will become as easy as pie. You could also toggle register updating off/on, and you could also move your cursor to any line in the code, and press a certain button to step through the code and see the results. After finishing the code, press the CAYG button again. All the code you wrote in the CAYG screen will be placed at the place in the source code you were at when you went to this screen. You can then edit it, delete it, or change it as normal. All in all, the code-as-you-go feature could be a breakthrough for future assemblers. No matter whether it's 6502, M68K, Z80, or anything else, it's the next innovation in coding.
-
The interface for a good assembler is just like a text editor, with extra features added to make assembly easier. Take a look at this simulated screenshot, inspired by the Apple ][. This is a multiply routine for the Motorola 68000: There are several things that would make this more of an assembler than a word processor: Under the label "Multiply," there is a blue line stretching across the screen. You could toggle this on or off. Under this line can be shown information about the subroutine (e.g. input/output). Each line of code is indented automatically. The local labels have a period before them, and are not indented. There is a red "+" before the label. Clicking it changes it to a "-" and makes the code disappear. You could click the "-" to make the code reappear. Whether the code is folded or not, it's compiled when requested. When compiled, the branches with the ".s" extension will resolve to a ".b" (8-bit) or ".w" (16-bit) displacement, whichever is the shortest possible. If the extension is left off, assume it to be ".s". That way, you don't have to figure it out yourself. In this example, the screen is 480x360 pixels. Characters are 7 pixels across and 8 pixels down, just like on the Apple ][. In system RAM, this could be handled with one table telling which ASCII character to show (one byte per character), and another table to tell the background/foreground colors for each cell (in each byte, there are 4 bits for background color and 4 bits for background color). By default, the line under labels is enabled, tab width is 8 characters, lines after labels and code automatically indent, and code is not folded. When a mouse is used, the character that the mouse is pointing to is shown in a different color (for example, in the above screen, it would be shown as a white cell with a blue character). Characters would be stored as ASCII. The blue underline is toggled on/off with a control byte, and the tab width is also controlled using a certain byte. You could use any programming language you want, be it 6502, 68K, Z80, BASIC, etc. Regarding the keyboard, there could be additional keys based on what programming language you use. In addition to a regular ASCII keyboard, there could be attachments you could just snap on. For example, a 6502 keyboard attachment might have buttons labeled "LDA," "STA," "CLC," "SEC," "ADC," and "SBC." Next, I'll mention some enhancements you could make to the screen.
-
I have used a lot of assemblers to program games. I have used Learn to Program BASIC, BasiEgaXorz, and EASy68K. I have also used Apple ][ Basic, C++, and others. There are many different assemblers out there, but what if there was a computer (or maybe an application) with a really sophisticated assembler that could be used for programming games, and other things? The goal is to make programming easier, faster, and more enjoyable. First, I'd like to mention all the essential things that any good assembler needs. Fast interface, as well as fast assembling. The ability to cleanly divide a ROM into sections. Code/data folding. The ability to test code as you write it. Storing colors, but showing them visually, rather than as numbers. Storing graphics for a game as data, and making it show like it would in the program. Compress graphics if necessary. If it's for a system that uses tiles for graphics, computing the mappings for them. Compress data in some way. Test code for length. Being able to make short/long branches automatically according to smallest possible file size. Making sure VBlank code starts and ends properly. For any routine, sort the local labels alphabetically or numerically. Add a number of labels to a ROM that follow a certain character pattern. Add/manage data structures. Lets you pick labels/variables from a list. Calculates a ROM checksum and/or adds code. Pads a ROM to a number of bytes that is a power of 2. I might add more of these. Over time, I will be adding blog posts regarding one or more of these elements. Keep in mind that any images posted in this blog are simulated. The Apple ][ is my inspiration for their look, since it was one of the first computers I grew up with.
-
I must know. I also would like to know if other parts of the 2600 will use more time if I interact with them. Thanks! -
Hello, I recently got a 130XE off EBay as a way of getting back into Atari 8-bits. (I sold my original Atari 800, with a Happy 1050, in 1985 to upgrade to an Amiga 1000). I have an Assembler/Editor cartridge left over from my '90s retrogaming collector days. I think it would be fun for learning 6502 programming since it's on the actual hardware. When I get going with "real" projects, I would switch to a cross-assembler and I wondering which is best to use for a newbie. I definitely would use WUDSN IDE, since I'm already familiar with Eclipse. ATASM seems nice because it is compatible with MAC/65, but judging from this forum all the cool kids seem to be using MADS. My concern with MADS is that if you know only English, the documentation seems a bit like folklore. It also seems like a "power user" tool that might be overwhelming at first. Interested in hearing comments from people who are using these tools now. Thanks!
-
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 -
Hi! This is my first post here. I have created a new computer language, that makes 6502 code. Before I release it, it would like to test to make a Atari 2600 program. But as I don't have time to learn all about 2600 now, I wounder if there is a assembly program I can translate as a example. After that maybe someone would like to test it for writing their own programs. And I can provide the code for that program that i translate, as a programming example. Does anyone know of some suitable assembly code for this? I worst case I could take some machine code, and translate that. Any ideas? And where can I find info about the used fileformat for Atari 2600 emulators?
-
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
-
Anyone heard of INHOME Software? Anyone still programming for 8-bit atari? What is the best set-up. I'd like to use my Mac and a 65XE? Or should I go old-school with an old 800? Is there an interest in New games for the Atari 8-Bits?
-
Just stumbled into a bug with MADS' built-in ADW macro when used with (ZP),Y: LDY #$04 ADW (OBSPEC),Y PTR2 PTR4 A334: A0 04 LDY #$04 A336: 18 CLC A337: B1 C1 LIMITCLIP.OFFSCREEN LDA (OBSPEC),Y A339: 65 E2 LIMITCLIP.139@ ADC PTR2 A33B: 85 E6 STA PTR4 A33D: C8 INY A33E: B1 C1 LDA (OBSPEC),Y A340: 65 E3 ADC $E3 A342: 85 E6 STA PTR4 ; <<<<<<< should be $E7, not $E6 LDY #$04 MWA (OBSPEC),Y PTR4 A334: A0 04 LDY #$04 A336: B1 C1 LDA (OBSPEC),Y A338: 85 E6 STA PTR4 A33A: C8 INY A33B: B1 C1 LDA (OBSPEC),Y A33D: 85 E7 STA $E7 ; <<<<<<<<<<<<< $E7 = correct Using the latest build here, and I'm sure ADW used to store the MSB correctly in older versions. Haven't looked to see if the bug exists in SBW as well.
-
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?
-
LucasFilm's Macross 6502 Assembler has been released to Github. https://github.com/Museum-of-Art-and-Digital-Entertainment/macross -
6502 vs Z80: Which do you prefer programming?
BillyHW posted a topic in Classic Computing Discussion
. -
Hello- I am currently trying to convert some old 6502 source code to compile with DASM. One of the commands keeps getting a syntax error and I can't figure out what to change it to. The commands are currently: LDA #HIGH MYVEC LDA #LOW MYVEC MYVEC is the label of a subroutine. Anyone know the proper DASM conversion? -
My software needs to not only detect the presence of a 65C816 CPU (taken care of), but also compute and report the CPU speed. The way I've gone about this (assuming a 6502 for the moment) is to run a block of code which updates a counter while waiting for a full frame to elapse (with DMA off, of course). We know the cycle count of the code block, so armed with the final value of the counter, we can compute the number of cycles per frame. The first thing I ran into (Antic DMA being disabled) is RAM refresh, which I understand takes 9 cycles per scan line. Factoring this into the calculation seemed to yield a result closer to what's expected: i.e. ($9B * 2) * 9 added to the overall cycle count in PAL mode. The figures soon drift wildly off when the CPU is a 65C816, however. I'm not sure if this is down to my misunderstanding the cycle counts of 6502 instructions in emulation mode, or not properly accounting for RAM refresh cycles. I notice that SysInfo computes the CPU speed quite accurately, so are there any special compensations required when trying to work out the speed of a 65C816 CPU running in emulation mode on an A8? Or is there a better way of measuring speed entirely?
-
Why did the Game Boy use a Z80 instead of a 6502 like the NES (and the closely related 65816 of the SNES)? Were there any power advantages to the Z80 that would help with battery life? Wouldn't it have made more sense to use a 6502, than they could reuse code and make it easier to port NES games over.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord