Jump to content

Search the Community

Showing results for tags 'Action'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • 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
  • 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
  • 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

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
  • ZeroPage Homebrew's Schedule

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 7 results

  1. Hey, I started this thread because I wanted to see what the prototype would look and sound like, if finished. Could someone please convert the arcade music into an Atari 2600's sounds? I wanna know what it would sound like. Could someone also fix the glitches? Personally, it is an impressive prototype. If Up 'N Down was possible, then...
  2. In my last post I showed how the Action! compiler produces some pretty optimized code for CARD math under certain circumstances. This time I will show the more general case which should be pretty familiar to anyone who has done 6502 programming. Here is the Action! program and it’s dis-assembly: CARD I PROC MAIN() I=2 I=I+2 RETURN 0E6C: .BYTE 00,00 0E6E: 4C 71 0E JMP $0E71 ;I=2 0E71: A0 00 LDY #$00 0E73: 8C 6D 0E STY $0E6D 0E76: A9 02 LDA #$02 0E78: 8D 6C 0E STA $0E6C ;I=I+2 0E7B: 18 CLC 0E7C: AD 6C 0E LDA $0E6C 0E7F: 69 02 ADC #$02 0E81: 8D 6C 0E STA $0E6C 0E84: AD 6D 0E LDA $0E6D 0E87: 69 00 ADC #$00 0E89: 8D 6D 0E STA $0E6D 0E8C: 60 RTS Most of what is here we have discussed before so I won’t go into great detail. As you can see since I is initialized to the value 2 the INY optimization can’t be used so two loads and stores are performed. It’s interesting to note that a different register is used for each byte. I am not sure why the compiler chooses to do this, although in the end it doesn’t affect program size or performance. The add part of the program is standard 6502 16-bit math, adding the lower byte, then adding the upper byte which also handles and carry from the lower byte.
  3. After years of programming in Borland Pascal and Lazarus (a Delphi-like RAD environment) under Windows, I recently went back to playing around with programming for the 8-bits, and realized a number of things that I missed when having to step "down" to the older platform. Being the type of person who tends to reinvent the wheel whenever I find something that doesn't do exactly what I want how I want, I came to the conclusion that a new language was called for that would fix these shortcomings. I dragged out an acronym I first came up with back in the very early 1980's that I promised I would use if I ever developed a language and retrofitted it onto this need. I started work on a parser in Lazarus under Windows, which will eventually lead to a compiler. I have the parser to the point where it can handle type definitions, procedure and function calls, variable definitions, and the major structure of a program. The next hurdle will be getting the parser to create pseudo-code, which can then be compiled into a functioning Atari program. A major goal of the project will be, once the Windows-based compiler is finished, to use it to bootstrap a compiler native to the 8-bits. That native compiler can then be modified as the language grows and evolves and bugs are identified. Since a language is a major undertaking, I don't want to develop it completely in a vacuum. The objective is to be useful, and the more ideas and input that can be brought into it the better. Plus, once I have a functioning Windows compiler capable of making at least functional Atari code, the task of writing the native compiler can be farmed out to a series of volunteers. That is why I am starting this thread, to share what I've already got worked out, solicit comment and suggestions, and hopefully involve others in the process. I will be releasing all language definitions and code I write into the public domain. With that out of the way, let me outline the basics of ACUSOL - Atari Computers Unified Symbolic Object-Oriented Language Based upon Action! - I am using the Action! language definitions and structure as a starting point, Action! is a fairly well-structured and easy to understand language, and the extensions I wanted to make to it are easily grafted on. Object-oriented - It will be an object-oriented language, with features similar to Object Pascal and Delphi Easy use of extended memory - It will be easy to use banked RAM in expanded 8-bits with this language. Extended memory can be easily addressed, the compiler will be designed to allow variables to be allocated in banked RAM, and portions of the actual program code can be stored in banked RAM and called from anywhere in the program. The following posts will outline major portions of the language.
  4. Let's take a break from looking at Action! math and take a look at procedure calls. We will start up with something that is trivially simple: Proc test() Return Proc main() Test() Return 0E61: 4C 64 0E JMP $0E64 0E64: 60 RTS 0E65: 4C 68 0E JMP $0E68 0E68: 20 61 0E JSR $0E61 0E6B: 60 RTS Our main procedure starts at 0E68 and it begins with a call to procedure Test using a JSR. The procedure Test starts at 0E61 which immediately jumps to the RTS since the procedure is empty. What I haven’t been able to figure out is why the JMP instruction is there since it doesn’t jump over anything. I have yet to find a case where it actually jumps over something. Next let’s look at how simple parameter passing is done: Proc test(byte I) Return Proc main() Test(1) Return 0E88: .BYTE #$00 0E89: 4C 8C 0E JMP $0E8C 0E8C: 8D 88 0E STA $0E88 0E8F: 60 RTS 0E90: 4C 93 0E JMP $0E93 0E93: A9 01 LDA #$01 0E95: 20 89 0E JSR $0E89 0E98: 60 RTS This is the same as the first example, but now we pass a single BYTE parameter to the procedure. Here is an area where Action! does a good job at optimizing. Since there is only a single BYTE being passed it uses the most efficient way possible, it just passes it in the accumulator. At 0E93 the value 1 is loaded into the accumulator then the procedure is called. At 0E8C that value passed is stored in the local variable I. You will notice that space for this variable is allocated before the start of the procedure code, so this doesn’t answer the mystery of the JMP instruction.
  5. I can’t believe it’s been over a year since my last blog post, time sure does fly! I thought it was about time to get back to some posts and continue my Action! language topic. Last time I talked about BYTE math, this time we will start looking at CARDinal math. In Action the CARD data type is a two byte unsigned value. Here is the first piece of Action! code: CARD I PROC MAIN() I=1 I=I+1 RETURN Here is the resulting disassembly: 0E6A: .BYTE #$00,#$00 0E6C: 4C 6F 0E JMP $0E6F 0E6F: A0 00 LDY #$00 0E71: 8C 6B 0E STY $0E6B 0E74: C8 INY 0E75: 8C 6A 0E STY $0E6A 0E78: EE 6A 0E INC $0E6A 0E7B: D0 03 BNE $0E80 0E7D: EE 6B 0E INC $0E6B We start at memory location $E6A where two bytes are set aside for variable I, and then as usual we have a JMP to that start of the code. The next four instructions assign the value 1 to I and you can see a nice little optimization here. First a 0 is put into the high byte of the variable. The low byte needs to have 1 in it and since the compiler knows that Y already contains 0 in can simply use the increment Y instruction to get a 1. This will save two bytes over using LDY #$01. The next three instructions handle the I=I+1. Just like in the BYTE math the compiler knows that +1 is just an increment so uses the INC instruction on the low byte of the variable instead of doing an ADC. The branch checks for an overflow and if there is one we then increment the high byte of the variable.
  6. I have some items up on ebay that may be of interest to Atari 8-bit enthusiasts. Auctions are ending today (sorry for late notice) Still "cleaning out the Attic"... OSS Action! programming language cartidge, + lightspeed C and MAC65 disks http://www.ebay.com/itm/301850710170 OSS BASIC XE cartridge + Atari BASIC cartridge: http://www.ebay.com/itm/301850721290 Original Atari 8-bit Visicalc disk and manual: http://www.ebay.com/itm/301850746506 Collection of various original Atari documents, manuals, catalog, including original Atari 1200XL manual: http://www.ebay.com/itm/301850746008 I am selling some Atari ST stuff as well. And I have some more stuff coming. You can check out all my ebay listings here: http://www.ebay.com/sch/chris82369/m.html
  7. Hi, I recently started using OSS's Action, but I've run into some problems. In short, is there a limit on the size of arrays? I find that when I try to create a BYTE ARRAY of >256 elements, the compiler starts each array only a few bytes apart (as if it is ignoring the MSB of the size.) To expand a bit... I was trying to do a Life simulation and wanted to create several linked lists. I've since concluded that can't be done since the language doesn't seem to be able to dynamically allocate memory. So I decided to do a sort of pseudo-linked-list, creating a record with CARDs for capacity and current size and a BYTE for the start of a virtual x,y coordinate array. Then I created a BYTE ARRAY to hold the record with the virtual array and declared the record and assigned it the address of the BYTE ARRAY. When I tried to Zero() the arrays, I ran into trouble, and when I investigated further I found the problem mentioned above. (I've appended the code below to clarify.) When I run this with a BYTE ARRAY size of 256, it creates three arrays and prints out the starting addresses: $2933 $2A33 $2B33 which is as expected. But if i increase the BYTE ARRAY size to 257, it prints: $2933 $2937 $293B with the arrays overlapping... I didn't see any mention of an array size limit in the manual (and they even show a 1000 byte array in the advanced record example.) I'm running this on the Atari800 emulator (3.1.0) in 800XL mode with the Action 3.5 cart on a Linux Mint 18.1 laptop. Thanks for any help you can offer. -- Jeff ; pseudo-linked-list DEFINE ARRAY_SIZE="256" TYPE LIST=[CARD CAPACITY, size BYTE xy] BYTE ARRAY _ba1(ARRAY_SIZE) BYTE ARRAY _ba2(ARRAY_SIZE) BYTE ARRAY _ba3(ARRAY_SIZE) LIST live=_ba1 LIST newLive=_ba2 LIST adjacent=_ba3 PROC initLists() BYTE i BYTE POINTER ptr live.CAPACITY=(ARRAY_SIZE-4)/2 live.size=0 [email protected](live.xy) PrintF("%H%E", ptr) ; Zero(ptr,ARRAY_SIZE-4) newLive.CAPACITY=(ARRAY_SIZE-4)/2 newLive.size=0 [email protected](newLive.xy) PrintF("%H%E", ptr) ; Zero(ptr,ARRAY_SIZE-4) adjacent.CAPACITY=(ARRAY_SIZE-4)/2 adjacent.size=0 [email protected](adjacent.xy) PrintF("%H%E", ptr) ; Zero(ptr,ARRAY_SIZE-4) RETURN PROC main() initLists() RETURN
×
×
  • Create New...