Jump to content

Search the Community

Showing results for tags '6502'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari General
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Atari VCS
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Classic Consoles
  • Classic Computing
  • Modern Consoles
  • Gaming General
  • Marketplace
  • Community
  • Community
  • Game Programming
  • Site
  • PC Gaming
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Robin Gravel's new blog's Games released
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • PlusCart User's Bug reports
  • PlusCart User's Discussion
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion

Blogs

There are no results to display.

There are no results to display.

Calendars

  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 51 results

  1. Greetings and felicitations, children of technology! A few of you may know me from around three decades back. I have to congratulate you all on this cool forum, that has amazing activity. I am happy that the community is still there. I am contacting the community again, because I am doing some work on Atari again. I am making a new programming language, that will be general-purpose, but that I am targeting at 8-bit Atari first. Most new languages don't target the old machines. There are a few exceptions, but they target the vintage machines specifically, and are not meant as general-purpose languages for modern systems. I think this is feeble and probably wrong in terms of language design: there are many bad reasons, but no good reason to not support small systems. C is still used everywhere, and it can do it. I think any new language should improve on C; it should not be less capable. I always thought this should be possible, and it is turning out to be true. At first I thought it would be harder to support the old systems, but it actually turned out to be easier, and it helped get the project off the ground. Small systems are much easier to work for due to less complexity, they are more motivating, they provide meaningful results earlier, they keep you aware of performance and they prove you can target very small devices, such as for Internet of Things. Like how Contiki became an IoT operating system starting on C64. I have wanted to do this language for some three decades, but the industry became ever more complex faster than I could master it. Every time I thought I could improve some things, the platform I was using was already outdated. For a quarter century, I didn't really know how to improve languages on the newest platforms, so I tried to use the best ones I could find. Yet almost every time I wanted to do a project or a commercial assignment and needed the platform and language to just work, I ran into walls that debilitated my efforts. This was all the more frustrating because there once was a system that I could do anything on that I wanted: my trusty Atari 8-bit. Perhaps my projects are too ambitious, yet this was no problem on Atari. I desperately need that power and control back, and in the past years, the puzzle pieces started to come together. Now it's a matter of doing the enormous amount of work required from a modern language. I am half a year into the project, and am double as productive as I have ever been. The language is mostly inspired by REBOL, of Amiga heritage: https://en.m.wikipedia.org/wiki/Rebol REBOL has great clarity and conciseness of expression, and a great capacity for abstraction, which can be used to define cross-platform abstractions. It has been measured to be the most expressive general-purpose programming language: https://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/ Among others, I was further inspired, for their performance and support of native Atari functionality, by Action!: https://en.m.wikipedia.org/wiki/Action!_(programming_language) and by PL65: https://atariwiki.org/wiki/Wiki.jsp?page=PL65 The language is past the proof-of-concept stage, but it is still very incomplete. On the other hand, it will match features expected from an 8-bit language before it will be able to match expectations for a modern language. I am working on a sneak preview release to let people try it. I will post examples as I go, if you like. After the sneak preview I will be working further on a crowd-funding website, where you will be able to influence the development through donations.
  2. I am developing a new language that I have been introducing here: After the Atari 8-bit, I am now targeting it at the 2600. I just posted the first demo here: Here is the source code: unsafe!!! constant reference volatile byte! [ ; TIA VSYNC= ~0000 VBLANK WSYNC COLUBK= ~0009 PF0= ~000D PF1 PF2 GRP0= ~001B GRP1 ENAM0 ENAM1 ENABL ] vertical-sync-bit= %0000'0010 VBLANK: ; Set beam to on to use the entire vertical-blank overscan area ENABL: ; Ball off ENAM1: ENAM0: ; Missiles off GRP1: GRP0: ; Players off PF2: PF1: PF0: 0 ; Playfield off; we only use the background byte! [jiffies colour] forever [ VSYNC: WSYNC: vertical-sync-bit ; Wait for end of scanline, then start vertical sync ; Vertical sync pulse. ; This lasts 3 scanlines, where some small work can be done to set up the next screen. colour: jiffies ; Begin colour gradient, shifted by jiffy counter ; Wait three scanlines, then end vertical sync, continue vertical blank VSYNC: WSYNC: WSYNC: WSYNC: 0 ; Vertical blank area, followed by the visible display area, ; followed by another vertical-blank overscan area. ; PAL and SECAM officially have 45 + 228 + 36 scanlines here, NTSC has 37 + 192 + 30. ; We generate 283 scanlines (plus the 3 for vertical sync), for a display frequency of 55Hz, ; inbetween PAL/SECAM and NTSC. It will work on all, if you have a tolerant television set. ; The first scanline is used for the setup overhead of the LOOP, ; so it gets the last colour wrapped over from the last scanline of the previous screen. ; Being the first line of the vertical blank overscan area, it is normally not visible. loop 282 [COLUBK: WSYNC: overflow increment colour] ; Increment background colour for every scanline overflow increment jiffies ] Here are some artifacts of the compilation. The assembler listing: https://language.meta.frl/examples/platforms/Atari/2600/rainbow.list A VICE labels file, for debuggers: https://language.meta.frl/examples/platforms/Atari/2600/rainbow.labels The memory sections map: https://language.meta.frl/examples/platforms/Atari/2600/rainbow.map It's my second 2600 program; please be gentle. 😁 The language will be cross-platform on as many systems as possible. 2600 programs are developed by cross-compiling. In many cases, it is also needed to pre-compute data for a 2600 program. You will be able to write such tools in the same language, on your PC or Mac or other favourite system.
  3. Hello everyone I'm in the process of building a VCS based hardware clone from scratch and have a few queries; I am going to replace the 6507 with 6502 (to get full 64k addressing + hardware interrupts + phi 1 and phi2 clocks ) and adding 32k of extra ram like the super Atari project (site is down but thanks for the wayback machine http://bit.ly/2FHlAH7) But these "NEW" eBay 6502 cpus (http://ebay.to/2DzjYJC) should work, or are these new chips like 65c02 in that the silicon has been altered due to "modern manufacture reasons"? And what's the highest clock speed available on a 6502? Also can you place some asynchronous buffer sram [cy7c408 = 128byte sram fifo memory] (http://bit.ly/2HGAAlm) between the data lines on the tia and 6502/7, so that the when the TIA Is drawing the data is already in the buffer, and all the cpu needs to do is correctly send the corrects address locations relevant to data stored in the buffer? (i.e instead of cpu calculating the display every scan-line you simply write a few scan-lines of image data into the buffer before The TIA begins to draw, then just correctly address in the order of whats stored in the buffer and do program logic) Since the [cy7c408a] is dual ported with asynchronous R/W, means you can just clock the output data [DO0-DO7] bus with the 1.19MHz clock from the TIA, iirc the TIA doesn't tend to like bus speeds higher than 1.19MHz? Then this should allow one to overclock the 6502 with for simplicity of counting cycles a multiple of the [ntsc] color-burst [TIA] clock ( i.e being able to have 684 cpu cycles per scan-line {using a 6502 clocked @ 10.75MHz = ~3x the TIA clock } instead of just 76 cycles) in such cases also sacrificing [native 2600] compatibility for increased cpu speed and more time for crunching instructions. I would also assume having the TIA reading the buffer @ 1.19Mhz would present in situations a bottleneck as well (when "drawing" to the TIA)? Since you can write data faster to the buffer than its being read (if the CPU is overclocked)? Since it seems the cy7c408 operates similar to a giant shift register, once its written you have to wait until data to reach to the TIA before it you write new data?? Can you just fill the buffer with 128 bytes of scan-line/sound data for the TIA, then handle the TIA addressing, and just fill the buffer as its being emptied, and essentially have 128 bytes of "VRam" (well more like Video buffer)? Also Can NMI be used instead of RDY, so that when the tia begins a new frame, wsync simply have the TIA tell the 6502 to "Stop, Pause , Go and do Display routine and then come back here", instead of just halting the cpu? Aswell i have a few microchip and avr (atmega8515) mcu's laying around wanting to be used for something and with a both MCU's, it's instructions are pipelined so that it takes effectively 1 cycle to load and execute data or decode and execute an instruction, except iirc when changing the program counter which iirc takes 2 - 3 cycles, So you don't have wait states [i.e iirc if using a z80, thats takes 3+ cycles for most of its instructions which is why they have such high clocks]. Is it possible to use the atmega or 18f4550 as sort of display controller for the TIA having the MCU handle reads from the buffer instead, and handle writing the data to the TIA, and use the atmega8515 to emulate the RIOT? Is it possible to emulate the Riot but with 256 bytes of ram? iirc RIOT ram is in page 0 so is faster to access than the 32k of extra ram? Plus is it possible, using A12 and A15 with a 74hc138 and a logic gate or two as a way to partially decode address to swap between cartridge space and 32k ram, so one can simply keep some compatibility, simply if A12 is high and A15 low then cartridge ROM is accessed, and if A15 is high in any case 32k Ram is Accessed? just building it to just play 2600 games isn't really hard (it was done from 1977 to 1992 literally millions of times), and seems a little redundant to me, I just figured since you can build your own 2600 compatible hardware clone for less than $50 in parts shipped, why not beef it up for some shits and giggles like a dev kit, have 256k of rom space and 32k ram, 6502, if possible using an MCU or 2 as an "In Hardware display Kernel", as well as emulate the riot, And CO10444D. why you ask? Because i i'll have the only atari "super" VCS with full USB 2.0 support (upto 12Mbit/s if I do use the 18f4550 lol) and plus i can really push the hardware to the limit see what it can do with some actual "power" behind it
  4. DIS6502 is an interactive 6502 disassembler. It can disassemble handle plain binary files and support specific executable files of Atari 8-bit, C64 and Oric computers. This support also includes the labels and handling of the operating system vectors to make the disassembly better. It can output the assembly listing in different configurable formats and comes with preset profiles for popular assemblers like ASMED, CA64, LADS, MAC65, and MADS. There are currently two versions available: Latest 3.0 beta build: https://www.wudsn.com/productions/windows/dis6502/dis6502.zipwith resizable window and many new features Old but stable version 2.2 from 2006: https://sourceforge.net/projects/dis6502/files/latest/download Version 3.0 uses a new workspace format. You can open old workspaces in older formats but only save in the new format. Therefore you should make a backup of your old workspace, before using the new version. Version 3.0 is not yet officially released, but you are strongly encouraged to use it and send feedback.
  5. I am using this bit of code to decide if the velocity is going to be positive or negative when a new game is started. GetRandomByte lda Random asl eor Random asl eor Random asl asl eor Random asl rol Random ; performs a series of shifts and bit operations rts jsr GetRandomByte ; generate a random number lda #%10000000 ; 1 in most significant bit mean greater then 127 bit Random ; was it less then 127? bne RandomVX ; if it was then branch lda #$ff ; set the starting duck's x velocity to -1 jmp RandomVXDone ; and jump cause we're done RandomVX lda #$01 ; set the starting duck's x velocity to 1 RandomVXDone sta DuckVX ; store duck's initial x velocity jsr GetRandomByte ; generate a random number lda #%10000000 ; 1 in most significant bit mean greater then 127 bit Random ; was it less then 127? bne RandomVY ; if it was then branch lda #$ff ; set the starting duck's x velocity to -1 jmp RandomVYDone ; and jump cause we're done RandomVY lda #$01 ; set the starting duck's x velocity to 1 RandomVYDone sta DuckVY ; store duck's initial y velocity However no matter what the velocity always stays the same. Bin: https://www.dropbox.com/s/ikjnebg1moyn0k4/duckgame.bin?dl=1
  6. Hello there! I recently watched on YouTube a video from RetroManCave (Neil), titled "Inside the BBC Micro - Trash to Treasure (Part 2)" (https://www.youtube.com/watch?v=bQCgzIWZo0o) At 0:03:35, Neil explains that the BBC Micro's 6502 runs at 2 MHz, which makes it pretty fast, compared to other computers from the same period, for instance the Apple II that ran at 1 MHz (1.9 MHz in turbo mode). Of course, I regret that Neil didn't mention Atari's 1.79 (1.77) MHz at that point. Later at 0:08:00, Neil mentions the Rugg/Feldman benchmarks for BASIC, in which Atari BASIC (and the OS FPP) does not help to make the computer shine. To me, it's not really fair to compare the computers with merely their CPU speed (*) and Rugg/Feldman benchmarks for BASIC figures: - The Atari runs MUCH FASTER with other BASIC, such as Turbo BASIC XL, to name just one - The Atari 8-bit architecture, with dedicated additional chips, allows the CPU to focus on the main tasks, whilst the other chips deal with video, sound, P/M, etc. In lots of other computers from the same period, the CPU deals with everything, so a higher clock rate is not enough to make it faster! My question is: How to compare - with justice - the 800XL with the C64, the Apple IIe, the BBC Micro, etc in terms of performance? Any suggestion of bench marking method? (*) Same 6502 CPU for instance; We all know that a 6502 & a Z80 at 2 MHz are NOT equally powerful
  7. 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.
  8. 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...
  9. 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
  10. 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
  11. 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 [email protected] 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.
  12. http://skilldrick.github.com/easy6502/index.html
  13. If anyone is wanting to get started in Assembler the first part of my "How Not to Learn Assembler" column is in the new issue of Pro(c) Atari Magazine. It has a focus on game development and will cover beginner to intermediate topics, those more advanced may want to shout at the magazine as they read it but may get a laugh or two! If anyone wants to write anything covering anything at all, please send it to me for the next issue. Thanks, Jason
  14. 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?
  15. LucasFilm's Macross 6502 Assembler has been released to Github. https://github.com/Museum-of-Art-and-Digital-Entertainment/macross
  16. 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!
  17. Hello all, First, I should introduce myself. My name is Boisy Pitre and I've been involved with the Tandy Color Computer (CoCo) and its community for some 30 years now. I run Cloud-9 (www.cloud9tech.com) along with my friend, Mark Marlette, where we sell CoCo hardware and software, and lead several open source initiatives in the CoCo community, most notably the NitrOS-9 operating system. I've always been interested in Atari computers as a kid, having had an Atari VCS back in 1980.During my teen years, I never got into the home computer end of Atari, though I was keenly aware of the scene. Now that I'm a little older, I can indulge more than I could back then . One of my more recent desires has been to obtain a 6502 based Atari computer such as an Atari 400/800 or 130XE, and replace its 6502 microprocessor with a 6809 (the same processor that is in the CoCo), then get NitrOS-9 running on that hardware. An interesting amalgamation of technologies, if you will, but nevertheless something that has intrigued me. To that end, I've obtained an Atari XEGS from eBay, along with a keyboard and a few cartridge based games. I've taken the system apart and identified chips that will need to be replaced for this project (the SALLY (6502) and the 16K ROM) Both have been desoldered and replaced with 40 and 28 pin sockets, respectively, and both chips were salvageable during the desoldering process. They have been placed back in the freshly soldered sockets and the machine comes up just fine. Along with working towards mating the 6809E electrically into the board, I need some advice on how to bring up the board to a known state once the processor is working. My thought would be to make some interesting sounds through the sound chip and setup the video mode, but in order to do that, I need detailed information on the actual chips involved, their addresses, etc. In order to do this, I think it would be important to obtain a disassembly of the 16K ROM, as well as find any cross-assembler 6502 tools that are useful. Can anyone point me to a fully annotated disassembly of the contents of the XEGS ROM, as well as the tools of choice to do assembling? Thanks, and I"m looking forward to being part of the Atari community.
  18. 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
  19. 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 [email protected] 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
  20. 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?
  21. 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?
  22. It can be done in any coding language but i think assembly will be fastest. I'm looking for solution that is faster than ATARI basic which is 50-80 muls per sec and it have loss of precision :( How many times per second can 6502c multiply 10-digit number by 10-digit number without a loss of precision?
  23. 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.
  24. 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.
  25. Hey Guys, As some of you know I'm in the process of releasing my first homebrew game called Candy Catcher which I'm very excited about and have been extremely happy with the responses I have gotten from the game so far. However during the development of that game, i quickly realized not only the complexity of my statements I was making in batari Basic, but also the amount of ROM (Read Only Memory) space my code was taking, I had some statements that were easily pushing 50 ~ 75 bytes. That doesn't sound like much but when you only have 4096 bytes to work with, you only have ten of those statements, you have used a 1/5th of your available ROM space. I was limited to 4k, easiest way for my to make my game into a cartridge and release what I was considering a budget title. I had many more ideas for additional features in Candy Catcher that never saw the light of day because of ROM limitation issues. So for my next game that I'm keeping quite until I have a playable demo to present, I decided to learn assembly to reduce the amount of ROM space my code is taking and to give me great control of the number of objects that appear on the screen and to give me more flexibility with the speed and execution of my code as well as cutting down on the ROM space my code requires. I'm going through Atari 2600 Programming Tutorial posted on Random Terrain's site, getting my machine setup and learning the basics of Machine Langauge from the beginning. I also have Machine Language For Beginners by Richard Mansfield and 6502 Software Design by Leo J. Scanlon as references as I go. I'm going to be doing all my development on my Mac Mini Server as its my main desktop (Mirror Raid Harddrives are freaking awesome) and I'm not having to run a VM of Windows XP to do development of my game which is also nice which I did for Candy Catcher. My goal is to update this blog weekly with examples of what I have figured out and with tips to help others along as well. Thanks Disjaukifa
×
×
  • Create New...