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 50 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 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
  3. 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
  4. 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
  5. Hi, I wanted to try out using the S: CIO screen editor in Assembler, but I'm not sure I am going about it in the right way. When I do an OPEN, PRINT "Hello World", CLOSE, I get the attached screen, but it has 2 cursors in column 0, and a cursor after the "Hello World". The code is quite simple, and uses the OPEN, PRINT and CLOSE macros from Mac65. *= $5000 JMP PROGRAM_INIT ; ; MAC65 Macro files. Mainly used for I/O Macros ; .INCLUDE "SYSEQU.M65" .INCLUDE "IOMAC.LIB" .INCLUDE "OS.asm" PROGRAM_INIT LDA #<END_OF_PROGRAM_MEMORY STA APPMHI LDA #>END_OF_PROGRAM_MEMORY STA APPMHI+1 LDA #1 STA CRSINH LDA #0 STA LMARGN OPEN 1,12,0,"S:" ; PRINT 1," " LDA #20 STA COLCRS LDA #0 STA COLCRS+1 STA ROWCRS PRINT 1,"Hello World " CLOSE 1 LOOP1 JMP LOOP1 RTS END_OF_PROGRAM_MEMORY *=$2E0 .WORD PROGRAM_INIT I've also attached the ATR containing the executable (T1SET.EXE). Is there any way of getting rid of the extra cursor characters (actually all 3 of them)? I thought they would not be present as I set CRSINH to 1 right at the start of the program. At the moment I am working from Chapter 8 of the Atari System Reference manual by Bob Duhamel - if anyone can point me to any other info on using the S: device from Assembler, that would also be appreciated. The reason I'm looking at this is that I saw this post: and started to wonder about using the S: driver, which I haven't used before (I'm planning on converting the screen I/O in ATR Maker Deluxe - and other programs - to use the S: device, but I want to write some test programs first to make sure it works OK). Also, I'm not sure if I am setting APPMHI correctly, this is required according to the Reference Manual, but not something I can recall using before. Any help would be appreciated! t1set.atr
  6. 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
  7. 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?
  8. 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?
  9. 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)??
  10. 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.
  11. 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.
  12. 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
  13. The Wikipedia page about the 1292 Advanced Programmable Video System claims it was particularly difficult to program: It made me curious. Did nearly every other processor and microcontroller back in the 1970's default to opcode $00 equals NOP? So far I have found the following: Zilog Z80 and Intel 8080: $00 = NOP (No Operation) Intel 8048 : $00 = NOP (No Operation) RCA 1802: $00 = IDL (Idle) So far, so good. But how about the others? MOS 6502: $00 = BRK (Break, causes an interrupt) GI CP-1610: $0000 = HLT (Halt, not sure what it does but likely not NOP) Motorola 6809: $00 = NEG $nn (not entirely sure about this syntax, but at least NEG) Signetics 2650: $00 = Branch to address in immediate register B (per the Wikipedia article) I failed to look up what the TMS-9900 and the Fairchild F8 do with opcode $00 or $0000. It seems that Motorola 6801/03 doesn't define $00 at all. Likely I have missed some relevant processors and microcontrollers of the time, but it seems like the article describes how a programmer used to Intel or Zilog would be confused about the Signetics. Programmers used to MOS, GI or Motorola may have been confused too, but at least not expecting NOP. Now machine code programming has far more interesting challenges than which instruction equals which value when encoded as binary/hex/decimal data, I would think that works out rather quickly, in particular if you were able to have a cross assembler on some mini computer or similar when developing software for the 1292 APVS series.
  14. 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.
  15. 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
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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!
  22. 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? ​ ​ ​
  23. 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
  24. 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
×
×
  • Create New...