Search the Community
Showing results for tags '6502'.
-
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! -
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?
-
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 -
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?
-
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.
-
While I think that the Lynx is just fine with its 6502 CPU, and understand why it didn't get a Motorola 680, I still wonder: What made Atari and Epyx make the final decision to use the MOS 6502 rather than, say, the Zilog Z80b, Intel 8088, or one from Hudsonsoft? What, other than cost possibly, made the 6502 their pick?
-
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.
-
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... -
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!
-
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, I have been tracking down an issue in a game I am creating where the my scanline count was going wrong and it was because somehow the decimal flag was being set so a 'sbc' was not as I expected. Currently my work around is doing a 'cld' just before this bit of code but I don't know how it gets set in the first place. I have looked for the obvious and I am not doing a 'sed' anywhere in my code. Does anyone know more about this to advise me how this flag can get set in another way that might help me find the answer? It would be good to set some kind of cognitional breakpoint in stella so I can just find the code that way but I don't know if its possible. Thanks, Mike
-
Has anyone ever tried to run some of the modern CPU benchmarks (like SPECint and SPECfp) on the classic 8-bit (6502, Z80) and 16-bit (68000, 65816) CPUs? My googling has found nothing. (Only thing I could find was a rating for the 68060.) How hard would it be to set something like that up?
-
Let me introduce myself: I am the original creator and Copyright owner of ULTIMON! I have decided to make this old version (along with its new PDF Manual) available for anyone to download and use completely free of charge. Although it will still remain subject to my Copyright. You may download the original ROM and the new Manual from: https://www.box.com/...jd2zs8pce0saeae The ROM should work for: 600XL (64K), 800XL, 800XLE, 130XE & 65XE. Enjoy! In the near future a MyBIOS compatible version of ULTIMON will be released.
-
Linky only http://www.cast-inc.com/ip-cores/processors/index.html And it lists 6502, Z80 and 68000, perhaps they should also get into making 6502/z80 and 68000 Custom IC's like vic2/3, sid or pokey/antic/c or gtia and ofcourse paula/agnes and denise, glue and shifter/shifter 2 Could be interesting-
- 1
-
-
- ancient cpu cores
- 6502
- (and 2 more)
-
http://skilldrick.github.com/easy6502/index.html
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord