Search the Community
Showing results for tags 'action'.
-
Hello. I created a new game : Mummy Maze An archaeologist explore many Egyptian pyramids. In order to open sarcophagus. He must find all anks dispersed in the maze. But beware: the tomb is stuffed with deadly spikes and lethal arrows. Bats and cursed mummies gonna give you a hard time; however, if you find the holy khopesh, you will can face them. When you open sarcophagus, a new exploration in a larger and harder tomb awaits you. Good luck. I had the idea about this game since I was a teen. I planned to create a game inspired by Atic Atac, a famous gamy for ZX Spectrum, with a nightmarish ambiance. Finally I decide to create a simple game with original idea. Specidications : - Mazes are generated randomly so you gonna not risk to encounter the same level. - Tombs become bigger during your progress. You gonna need your memory, else you gonna have trouble to find yourself. - You earn an extra life every 1000 points for a maximum of nine lives. mummy_maze.rom
- 22 replies
-
- 18
-
- colecovision
- homebrew
-
(and 8 more)
Tagged with:
-
The eBay seller shdurr0 posted his Milton Bradley edition of the Vectrex Action Figure. Euro theme. This one also comes with overlays. "custom action figures 3.75 Vectrex Man Glow In the Dark art toy. M.B. edition." https://www.ebay.com/itm/custom-action-figures-3.75-Vectrex-Man-Glow-In-the-Dark-art-toy.-M.B.-edition./175558436004
-
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.
-
Dear All! This is our "Atari 8-bit Programming" Discord server. It is a twin Discord server to the Fujinet Discord. Here is an invitation: https://discord.gg/GTapZjCsgp Best, Peter Kaczorowski
-
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 ptr=@(live.xy) PrintF("%H%E", ptr) ; Zero(ptr,ARRAY_SIZE-4) newLive.CAPACITY=(ARRAY_SIZE-4)/2 newLive.size=0 ptr=@(newLive.xy) PrintF("%H%E", ptr) ; Zero(ptr,ARRAY_SIZE-4) adjacent.CAPACITY=(ARRAY_SIZE-4)/2 adjacent.size=0 ptr=@(adjacent.xy) PrintF("%H%E", ptr) ; Zero(ptr,ARRAY_SIZE-4) RETURN PROC main() initLists() RETURN
-
SuperCharger SpaceInvaders New SuperCharger game! I'm writing a port of Space Invaders with enhanced SuperCharger graphics that will run on the Atari Flashback Portable There have been many awesome ports of SpaceInvaders with a lot of interesting variations in the genre. This version will utilize Display Lists like the A8, and a soft blitter rendering colorful semigraphics for arcade action and speed! Here's the concept and design on paper: Questions and feedback welcome! Anyone have ideas for a score that is different? Some examples: PIXELS has a score that is 40 feet high and an interactive part of the game - you can even traverse it at different times to get to another section of the board. WARPDRIVE has a rating system that displays full screen text messages from Starfleet. KC Munchkin Monster Maze has an educational score built from maze blocks to teach players to read binary. STARBLITZ and DEFENDER III have interactive score power-ups you must catch to extend the life of the City that can also damage the City if you miss during waves, and a levels completed score that is an interactive element on the end game screens.
- 21 replies
-
- 6
-
- SuperCharger Graphics
- Atari Portable
-
(and 3 more)
Tagged with:
-
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
-
Embarrassingly I am admitting I never 'really' gave this game a thorough try. Sure, I constantly tried it, basically walking around exploring areas trying to figure out what to do, but nothing even worthy of 'the old college try'. I did the same thing with Raiders of the Lost Ark back in '82-83 (But actually gave it 'the old college try'). If I recall correctly I just threw the manual out with the box and tried to figure out on my own what to do. It would not be until I spoke with a friend YEARS later in the later 80's that I would finally understand exactly what needed to be done. You thought I would learn....NOPE. 15 years later and finally obtaining a brand new box copy of Midnight Mutants (For 40 cents, thanks O'Shea's), I took the same "Raiders" approach. Can't believe what I have been missing. First thing to do - and actually do it constantly in the game, much like my favorite NES game Rygar, or the infamous Zelda, LISTEN TO THE OLD MAN. For Midnight Mutants it means regularly hitting the right button. He directs you excellently. ***SPOILERS - Do not read this part if you do not want hints/early part walkthrough*** -Obtained the knife from the house to be able to kill things. -Opened church door with knife and obtained the cross to ward off bats. -Obtained the ax from the south woods inside the cabin by the well of health restoration -Entered barn area through bush which casts no shadow -Fought huge Ram head boss and loss - Came so close to defeating it though - (1 health head left). ***SPOILERS OVER*** Thoughts: -Off the bat, cannot believe there have been no hacks for this game. Wishing this game received the love Atari 2600 Adventure has seen. -Bats are too many, too often, too annoying. The first thing I would love to see with this game is the reduction on most screens they appear, if not wiped from many sections entirely. They have to be the most unnecessary frustration in the game that for the most part provides no real challenge (Especially with the cross in hand) and just turn people off from playing the game, IMHO. I am actually really impressed though. I never knew how good or relatively diverse the game was and yet well directed if you LISTEN TO GRANDPA. Previously without grandpa, I found myself wandering through many boards filled with bats, just losing health without real understanding of what to do or where to go. I may have to read that manual though, one day.
-
I'm working on writing my first game in Action!. It's a two player game, and the players are identical except that they are mirrored. I'm storing the shape data in a BYTE ARRAY, is there a trick to flipping my player?
-
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...
- 6 replies
-
- Music Elevator
- Action
-
(and 1 more)
Tagged with:
-
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.
-
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.
-
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.