Opry99er Posted August 23, 2015 Author Share Posted August 23, 2015 Next step on this one is to create enemy movement... Should be able to do that tonight... I want to create multiple types of waves. One type will be non-firing enemies that move toward the player... Another type will be enemies that move similarly to the player (left and right) and fire at the player... Once all that is done, and I work out difficulty levels and a player "death" sequence, I'll add sound and music and it will be ready for the presses. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted August 23, 2015 Share Posted August 23, 2015 Looking really good Owen! 1 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted August 23, 2015 Share Posted August 23, 2015 I like it, Owen. The biggest problem with a double-ender cartridge isn't the board (I actually have a template for that one that I made as a test to see if I could get a lower price on fabricated boards once), it is the case. I'd have to design a special case to use it with. . .but as an alternate answer, all you would have to do is assemble one of the 128K boards with a single switch that would give you the same effect. Even better would be to just use one of the multicart menu programs to allow you to select between which one you wanted right from the title screen. . . Quote Link to comment Share on other sites More sharing options...
Opry99er Posted August 23, 2015 Author Share Posted August 23, 2015 Thank you Vorticon and Jim... I noticed Bouncing Babies is on one of the multicarts... That gives me hope for Vector Hyperdrive. And on the double-ender side of things... I suppose a single switch on the cart would be acceptable. multicart menu would be cool too... Quick question for you... Are we maxed out at 8K banks? I was wondering because this game is likely to exceed that and I am not sure how to switch banks within the framework of compiler-outputted source code. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted August 23, 2015 Share Posted August 23, 2015 Each bank has a maximum size of 8K, Owen. That is a limitation of the OS and its memory map. A bank-switched cartridge can be larger than 8K--but you have to split the code in such a way that it does the necessary switching between banks as part of the code--and that no code is dependent on something that isn't in its bank to run. Note that you can use one bank as a trampoline to other banks by putting your main loop in bank 1 and then branch to routines in other cart banks before returning to the spot you left in bank 1 to continue. See the code the mole is setting up to do just that for his Alex Kidd port. Using that scheme, you could write a single program that was up to 2048K, all banked in 8K increments. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted August 23, 2015 Author Share Posted August 23, 2015 Thanks Ksarul. I will look at it now!!! Quote Link to comment Share on other sites More sharing options...
Opry99er Posted August 23, 2015 Author Share Posted August 23, 2015 Wow... That is pretty intense stuff there... Since Mole is using C and I am using XB256 plus compiler, it is likely we wouldn't have alot in common... I need to study the asm routine information in the XB256 docs and see what's what. My demo is somwthing like 6K compiled right now... Will likely be able to keep it under 8k, just need to keep working and keeping tabs on my size. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted August 23, 2015 Share Posted August 23, 2015 Note you also have the option of compiling a larger program and using a loader to lob it into the 32K space prior to execution. At that point the cartridge is just a program carrier. Rasmus does this with his cartridges, as do the Neverlander and Arcturus cartridge files. . .and all of Gazoo's 512k/1024K/2048K cartridge images. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted August 23, 2015 Author Share Posted August 23, 2015 Interesting... Now the question is (and this may have been answered elsewhere) "can an 8k compiled XB program run from cart space only?" Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted August 24, 2015 Share Posted August 24, 2015 Interesting... Now the question is (and this may have been answered elsewhere) "can an 8k compiled XB program run from cart space only?" No. It would require some changes in the loader to force it to load to cartridge space. In theory that's possible, but another problem is that it would have to be a RAM cartridge because all the strings and variables are part of the code. Best bet if you want to make a cartridge is to use it to store the program and just copy it into 32K ram as ksarul describes in post #33. 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted August 24, 2015 Author Share Posted August 24, 2015 Thanks for the info, falcon. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted August 24, 2015 Author Share Posted August 24, 2015 I was hoping to put it out there for those with unexpanded consoles, but I guess I'll need to learn assembly better to do that. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted August 24, 2015 Share Posted August 24, 2015 Note you also have the option of compiling a larger program and using a loader to lob it into the 32K space prior to execution. At that point the cartridge is just a program carrier. Rasmus does this with his cartridges, as do the Neverlander and Arcturus cartridge files. . .and all of Gazoo's 512k/1024K/2048K cartridge images. Perhaps a bit off topic. Sorry. The Miner 2049er, and a few other 3rd party game cartridges, plugs into the expansion port on the side of the computer. Did they show up in the 32K space as ROM only ? Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted August 24, 2015 Share Posted August 24, 2015 The side-port cartridges are each a bit unique, Sometimes99er. Each of the game cartridges fills some portion of the 32K space with ROM (usually starting at >A000), and Arcturus also puts some code in the DSR space (at >4000). I haven't looked at where the Hamsoft module places its code in the memory map, but I suspect it is the DSR space, as it does allow connection to the rest of the peripheral chain. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted August 24, 2015 Author Share Posted August 24, 2015 Not a ton of progress on the game... A couple of optimizations to the code have been implemented to shorten it and make it more compact, but it has not affected the gameplay... I have a strong suspicion that the optimizations will really be felt once the other elements are in place and cycles are tight. This week, I hope to implement enemy movement and torpedoes... I have a loose structure in my head of how I want to handle the waves of enemies, but that will likely change when I start hitting speed and efficiency walls. So far, it seems like the sky is the limit on features, but that is NEVER the case in reality. Stay tuned, hope to have something for you in the next day or two. 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted September 1, 2015 Author Share Posted September 1, 2015 Got the first enemy motion routine in place... I think you'll dig it. Let me put some finishing touches on it and I'll post up a new demo. Look for it tomorrow. Quote Link to comment Share on other sites More sharing options...
RXB Posted September 2, 2015 Share Posted September 2, 2015 (edited) No. It would require some changes in the loader to force it to load to cartridge space. In theory that's possible, but another problem is that it would have to be a RAM cartridge because all the strings and variables are part of the code. Best bet if you want to make a cartridge is to use it to store the program and just copy it into 32K ram as ksarul describes in post #33. The ROMs and GROM in the XB cartridge are pretty much hard coded for upper 24K or VDP RAM. It would realistically be impossible to run from RAM in CART as that is where XB ROMs are located. It would never work unless you rewrite XB GROMs and ROMs. Now a Compiler into Assembly would work but that would be one hell of a rewrite. Edited September 2, 2015 by RXB Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 2, 2015 Share Posted September 2, 2015 The ROMs and GROM in the XB cartridge are pretty much hard coded for upper 24K or VDP RAM. It would realistically be impossible to run from RAM in CART as that is where XB ROMs are located. It would never work unless you rewrite XB GROMs and ROMs. Harry's XB compiler does not use XB. Now a Compiler into Assembly would work but that would be one hell of a rewrite. Yup! It surely was “one hell of a rewrite”! There are limitations; but, it does, in fact, produce ALC you then must assemble to object code. ...lee Quote Link to comment Share on other sites More sharing options...
RXB Posted September 2, 2015 Share Posted September 2, 2015 Harry's XB compiler does not use XB. Yup! It surely was “one hell of a rewrite”! There are limitations; but, it does, in fact, produce ALC you then must assemble to object code. ...lee So it does not really emulated XB Code at all? (It kinda does.) Quote Link to comment Share on other sites More sharing options...
Opry99er Posted September 3, 2015 Author Share Posted September 3, 2015 It takes XB, compiles it into AL source code, which is asembled into an EA5 file... XB cart is not needed to run the EA5 program. Bouncing Babies (a compiled XB game) is on one of the compilation carts. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted September 3, 2015 Author Share Posted September 3, 2015 -k- Here's a little teaser video of the preliminary enemy movement. The alien's erratic movements are to avoid your torpedoes... It works. There is a strategy there, but I'll leave it for you all to figure out. Much optimization left to do, but here's a taste. http://www.youtube.com/watch?v=CKFi3w0aRkI&feature=youtu.be 5 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted September 3, 2015 Author Share Posted September 3, 2015 Tonight (time allowing) I will get enemy firing operational... COINC checks may get costly, but we shall see. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted September 3, 2015 Author Share Posted September 3, 2015 Did some optimizing tonight and REALLY sped things up... Enemy is almost TOO responsive to player movement now. I also have enemy firing done, but checks for screen borders and COINC with player vessel are still in development. I may need to reorder my loop and/or add some checks to reduce the size of the main code cycle. I will report back later tonight. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted September 3, 2015 Author Share Posted September 3, 2015 BTW, Harry's compiler is ridiculous. So cool to compile XB and watch my program FLY Quote Link to comment Share on other sites More sharing options...
Opry99er Posted September 4, 2015 Author Share Posted September 4, 2015 Moving right along. http://www.youtube.com/watch?v=mmmMDhuIIbs&feature=youtu.be This one is starting to get fun. Still a bit goofy on one or two of the collisions, but I'm narrowing it down. 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.