Synthpopalooza Posted August 27, 2012 Share Posted August 27, 2012 Places you can store display lists and screens: Page 6 (256 bytes starting at 1536) Page 4 (The Casette Buffer) The Printer buffer on page 3 gives you a little space, and also there is some unused space at 1000 or so. Assuming you don't need the printer for anything. Lowering RAMTOP will also give you a bit of extra space. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted August 27, 2012 Share Posted August 27, 2012 (edited) Also, using the string offset method I discussed earlier, where you mess with the variable offset table, to set the location of S$ to the screen memory location: You could use this formula to calculate the string location in S$, based on screen position: LOC=Y*40+X (Assuming a Graphics 0 screen) S$(LOC+1,LOC+1)=CHAR$ Keeping in mind CHAR$ will be the screen code, not the ATASCII code (e.g. Space char is 0, not 32) Using String operations like S$(1,41)="#" will rapidly place any string on the screen instantaneously. This is useful if you want to do a character sprite that is more than one character wide. Big plus side: No ML needed, not a single USR call is used. Edited August 27, 2012 by Synthpopalooza 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 28, 2012 Share Posted August 28, 2012 where is the string stuff described? went through the thread but can not find the clue? Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 28, 2012 Share Posted August 28, 2012 http://www.atarimagazines.com/compute/issue54/178_1_Atari_Easy_Scroll.php Very nifty trick. Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 28, 2012 Share Posted August 28, 2012 Printing an entire screen worth of data each time a move is initiated, very slow. Much better would be reserve some Ram, use LMS. If manipulation of data is needed, a string could be repointed to the given area. Of course the problem of no Asm allowed crops up - the way to go would be to toggle between 2 display lists each time any change is needed so you don't get half-baked pointers. Give the DLists the same low-byte start address so only a single Poke is needed to change the DList pointer. 1 Quote Link to comment Share on other sites More sharing options...
Sikor Posted August 28, 2012 Share Posted August 28, 2012 wow, both games are great And probably has one fine thing - it is possible to run it with stock Atari 600XL (and A400/A800 with Basic Cartridge). Good job Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted August 28, 2012 Share Posted August 28, 2012 (edited) Here's the COMPUTE! article with the string offset stuff: http://www.atarimaga...k_peek_poke.php This formed the basis for my CONVERT.BAS program. Basically, you are messing with the Variable Name Table, setting your string to some memory location (say, CHBAS, the screen, etc.), then any operations on the string (as I described above) will affect the location the string is attached to (like the screen memory) ... you could easily do a softsprite routine with this method and not use ML. Edited August 28, 2012 by Synthpopalooza Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted August 28, 2012 Share Posted August 28, 2012 Both games are impressive I had this in Stellar Caverns... was I just unlucky? What's also cool is if you press break then list the program the code scrolls up the screen Should fire do something? I think I saw in a basic program somewhere location 713 was I used... Mapping the Atari has 713 to 735 as "spare bytes" and 736 to 767 for "miscellaneous use"! anyone know what is the difference is? p.s. Stick the emulator on full speed and have a go on Stellar Caverns Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted August 28, 2012 Share Posted August 28, 2012 713 to 735 were reserved, as far as I know, for extra color registers which never came about (e.g. a possible 16-color Graphics 10). These locations are free to use for your own programs. Quote Link to comment Share on other sites More sharing options...
TMR Posted August 28, 2012 Share Posted August 28, 2012 I had this in Stellar Caverns...was I just unlucky? Yeah, it's all randomly generated so, although i tried to put in some caveats, it does once in a while throw up something impossible. i'm not a fan of using randomly generated landscapes to be honest but it ticked enough boxes during what i'll laughingly call "the design phase" to go in. The biggest tick was against "doesn't need much RAM". =-) Should fire do something? No, it's just the classic "dodge the PRINTed background" game with a few tricks really. Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 28, 2012 Share Posted August 28, 2012 Those mentioned Ram locations aren't free - XL OS uses them and also plenty of other previously "free" locations. Best not to trust early memory maps, only use ones which include XL revisions and additions. Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted August 28, 2012 Share Posted August 28, 2012 I had this in Stellar Caverns...was I just unlucky? Yeah, it's all randomly generated so, although i tried to put in some caveats, it does once in a while throw up something impossible. i'm not a fan of using randomly generated landscapes to be honest but it ticked enough boxes during what i'll laughingly call "the design phase" to go in. The biggest tick was against "doesn't need much RAM". =-) Should fire do something? No, it's just the classic "dodge the PRINTed background" game with a few tricks really. I think I had a the occasional 'impossible' level due to random placements sneak through testing in Gwobby's Adventure : I hoped the player didn't notice and just thought they made a mistake Those mentioned Ram locations aren't free - XL OS uses them and also plenty of other previously "free" locations. Best not to trust early memory maps, only use ones which include XL revisions and additions. I have all the latest stuff here... The Revised Mapping the Atari thanks guys Quote Link to comment Share on other sites More sharing options...
TMR Posted September 2, 2012 Share Posted September 2, 2012 Quick bit of thread bumpage so it doesn't get forgotten... speaking of forgotten, where's SIO99 got to? Considering his amazing prowess with BASIC dialects i expected him to be first out of the gate with this one! =-) 2 Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted September 2, 2012 Share Posted September 2, 2012 I'm trying to encourage my friend to write her 1st atari program will enroll her neice to help next weekend hopefully they have an idea for a maze game... I'm hoping another idea springs into my head as I'd like to write another one too Quote Link to comment Share on other sites More sharing options...
fibrewire Posted September 2, 2012 Share Posted September 2, 2012 Lots of ideas from old BASIC books from the 70's Quote Link to comment Share on other sites More sharing options...
wesmond Posted September 3, 2012 Share Posted September 3, 2012 Has anyone ever written something nice with the XL fine-vertical scroll mode? POKE 622,255:GRAPHICS 0 (then list a long-ish program) ? It looks at a glance like you lose processing control while the scroll happens, but it's still an interesting feature. Maybe covering up the last 3 lines or so with very wide black players or something might help a little... Quote Link to comment Share on other sites More sharing options...
IronWorks Posted September 3, 2012 Share Posted September 3, 2012 I tried this to start with. But as you say it locks you out during the fine scroll plus the character scroll and makes moving a player slow and jerky. Also Nuy if you load the character set data from disk does this have to be included in the 4k Quote Link to comment Share on other sites More sharing options...
Rybags Posted September 3, 2012 Share Posted September 3, 2012 I believe it has to be a self-contained program, so embedded data only. There's tricks to save space. Character set data can be kept in data or assigned to strings. The EOL ($9B) character presents a problem, you can't embed that in strings, best way around is to weed them out and assign seperately. Quote Link to comment Share on other sites More sharing options...
NuY Posted September 3, 2012 Author Share Posted September 3, 2012 I tried this to start with. But as you say it locks you out during the fine scroll plus the character scroll and makes moving a player slow and jerky. Also Nuy if you load the character set data from disk does this have to be included in the 4k I would suggest limit to Atari Basic and limit to single file and no hacks to embed data. Yep, good plan - no data files, no compression, the final file must be a tokenised Basic file. Quote Link to comment Share on other sites More sharing options...
NuY Posted September 3, 2012 Author Share Posted September 3, 2012 I feel a little bit of a traitor but my 4K game 4K " Keep on Koastin' " has turned out much better than I expected, so I've decided to enter it into the abbuc software contest as there's still a few days to go before the deadline (may as well go for the hat-trick of last places after Gorilla Warfare and Gwobby Strikes Back!)... I can release here it once the voting has finished It's a simple idea but seems to play quite well... once you get an idea in your head then it's much easier to create something. Thanks for the inspiration from this thread NuY now I really must make more effort to do something with the assembler Late reply, but that's fine if you want to get it in the Abbuc contest, I think I set the deadline for this to the end of September. But seeing as you've finished it, code something else up for this Quote Link to comment Share on other sites More sharing options...
+Philsan Posted September 3, 2012 Share Posted September 3, 2012 Okay, that's me done then. The game is called Stellar Caverns, the .BAS file is 3,209 bytes long and it's one of those "use PRINT to scroll" games where the player has to dodge the landscape. It uses PMGs (well, one player at least), a custom display list with split screen, has a little in-game sound... and it scrolls downwards!! That was a giggle... although i was supposed to be working today and spent far too long on this. =-) It reminds me this very nice GBA game: http://www.youtube.com/watch?v=bnL8tJMbc4I Quote Link to comment Share on other sites More sharing options...
NuY Posted September 3, 2012 Author Share Posted September 3, 2012 Here's my (first) effort - old fashioned slider puzzle, with "authentic" Windows progress bar while it initialises... FRE(0) works out at 3693 bytes. Controls: 4-way joystick. My 4-year old boy loves it... sort of. I'd also note that while this is well under 4k, it is not nice! To SIO99 - from our earlier thread, I'm afraid you'd despise my code here... it's full of pokes to screen memory to keep it fast, rather than locate...position...print, which would work, but rather too sluggishly (and memory costly as well). Some lines are VERY long to save bytes, the variables are quite short, lots of constants/reuse, and the DATA for the graphics is as ASCII data, with code "155" manually fixed (as you can't type it). Even strings of 2-byte hex values took me over the limit by some 80 bytes that I just couldn't optimise out... so I converted the data to ASCII, saved 1k, and got lazy after that. So, there's no machine code, but that doesn't make it pleasant to code! (in fact, I suggest, machine code would be rather easier - and a thing of beauty compared to this!) Anyhow... it's been a fun challenge - I might try an action game like TMR did when I've recovered my sanity. Hope you enjoy it (for maybe a few seconds til maybe you get fed up with it!) W. That's pretty nice, and probably far beyond the standards I was expecting for anything done in Basic. I'll need to get my copy of Mapping out to work out what you're doing with all those POKEs though, I fear Quote Link to comment Share on other sites More sharing options...
NuY Posted September 3, 2012 Author Share Posted September 3, 2012 Quick bit of thread bumpage so it doesn't get forgotten... speaking of forgotten, where's SIO99 got to? Considering his amazing prowess with BASIC dialects i expected him to be first out of the gate with this one! =-) He's trying to decipher the sea of POKEs from wesmond's prod Quote Link to comment Share on other sites More sharing options...
sack-c0s Posted September 4, 2012 Share Posted September 4, 2012 on a related note (taken from a thread on Lemon64, although not exclusively about the c64) more info at http://rsp.retrocomputacion.com/ Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 4, 2012 Share Posted September 4, 2012 cool... hopefully assembler allowed? 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.