Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About OxC0FFEE

  • Rank
    Space Invader
  1. What happens at 4K boundaries? Would that simply make a flicker or visual disturbance? When I page past 4K I don't notice anything different? should I? I added a shotgun debugging statement to print the current value of SCREENHIGH*256+SCREENLOW and it works all the way up to ~65536 (and down to 0, when I get an error 3 poking into the LMS when it overflows below or above available memory. I get no problems at 4K boundaries?
  2. Hi all, I'm working on a proof of concept to scroll through memory with the joystick by incrementing and decrementing the pointer to screen memory. As a basis, I used listing two from chapter 6 (scrolling) in De Re Atari. I modified it to use the joystick as input and allow for two-way scrolling rather than just incrementing the pointer. DX is currently unused. 10 REM GR.0 20 DLIST=PEEK(560)+256*PEEK(561) 30 LMSLOW=DLIST+4 40 LMSHIGH=DLIST+5 50 SCREENLOW=PEEK(LMSLOW) 60 SCREENHIGH=PEEK(LMSHIGH) 65 S=STICK(0):IF S>0:DX=(S=7)-(S=11):DY=(S=13)-(S=14):ENDIF 70 SCREENLOW=SCREENLOW+DY*40 80 IF SCREENLOW>255:SCREENHIGH=SCREENHIGH+1:SCREENLOW=SCREENLOW-256:ENDIF 85 IF SCREENLOW<0:SCREENHIGH=SCREENHIGH-1:SCREENLOW=256+SCREENLOW:ENDIF 120 POKE LMSLOW,SCREENLOW 130 POKE LMSHIGH,SCREENHIGH 140 GOTO 65 This works fine going one line up or down at a time. My goal is to go up and down arbitrary amounts, instead of just one line (40 characters) at a time. Instead of this concept of maniputlating the MSB and LSB independently when SCREENLOW overflows positively or negatively, I'd prefer to say "move up or down in memory this amount and calculate LMSLOW and LMSHIGH appropriately" because I'm trying to add the concept of acceleration (pushing for longer on the stick one way or the other) rather than just velocity (up or down a constant amount). I'm using TBXL for this, and I know there are double-byte instructions, but I haven't used them, so let me know if this is pertinent and could make this easier. It seems that somehow modulo or integer division could make this simpler, but I can't quite wrap my head around it. It's been a while since I worked with the A8, so apologies if I'm a bit rusty! CORERUN.BAS
  3. I'm running High Sierra. The 3.1 link above says 404. Is it still kicking around? I'd love it if it still works on High Sierra!
  4. I like that too. It's simple and minimal, and possibly something I could bite off in TBXL
  5. I want to let you know I appreciate your gentle nudges in the right direction. My sincere apologies for any newbie-level questions here. I'm doing my best to come back to A8 coding after 30 years and trying to do something interesting for a Basic competition. Trying to fit something profound in 10 lines of Basic is harder than it sounds
  6. Gorgeous. I envision the Star Wars title crawl I don't imagine that's in basic/tbxl though? (i can hope)
  7. Yes! Very nice work. That's the fine-tuned effect I'm after, sort of a mix of the split of axelay5 with the flying-over-land perspective effect of axelay2. Hoping to use the copying memory idea as a shortcut for terrain/feature generation. I'm unsure if it can be done in Turbo-Basic XL in a smallish program (competition constraint). TBXL does have a COPY command, so, perhaps. It might be hard in pure TBXL though. If the core copy is small and fast enough, maybe...
  8. And this is a (badly copy and pasted in Photoshop) example of what I mean by 1-d video feedback. Here the start of video memory has been shifted by 3 scan lines. I'm sorry I can't better explain the phenomenon but I hope this jogs someone's synapses.
  9. To clarify, this is what I mean by "video feedback". In the case of moving screen memory around though, it was limited to one dimension since the screen buffer is inherently 1D.
  10. Been a while since I attempted this, and perhaps I'm getting Atari 8 and 16 bit machines a bit confused, but I remember writing a utility back in the day that moved the screen around memory. One interesting thing was that if the pointer to screen memory was placed just before or just after the start of actual screen memory, there would be a neat artifact like 1-dimensional video feeback, where one line would get duplicated, then that would get duplicated, etc. It looked like a faux 3d perspective effect where the "closer" objects would be taller. I found From Compute's Second Book of Atari Graphics, Program two, here: http://www.atariarchives.org/c2bag/page185.php to move screen memory around, but it's not behaving how I'd like. I have a feeling it's limited to a specific region of memory. I started with it, modified to use graphics 9. It does move the screen through memory using the arrow keys, but does not exhibit the powers-of-two one-dimensional video feedback I remember. Perhaps it's not crossing the screen boundaries in the way I remember? Modified listing using basic mode 9: 5 GRAPHICS 9 10 REM COARSE VERTICAL SCROLLING DEMO 15 REM PRESS UP/DOWN ARROWS TO MOVE DISPLAY THRU MEMORY 20 DLIST=PEEK(560)+PEEK(561)*256:REM GET START OF DISPLAY LIST 30 LMSL=DLIST+4:REM POINTER TO DISPLAY MEMORY 40 LMSH=DLIST+5 50 DISPLAYL=0:REM INITIALIZE ADDRESS OF DISPLAY MEMORY 55 REM READ KEYBOARD 60 IF PEEK(764)=255 THEN GOTO 60:REM WAIT FOR KEY 70 IF PEEK(764)=14 THEN POKE 764,255:GOTO 110:REM UP ARROW / 80 IF PEEK(764)=15 THEN POKE 764,255:GOTO 140:REM DOWN ARROW ? 90 GOTO 60 100 REM MOVE DISPLAY WINDOW INTO LOWER MEMORY 110 DISPLAYL=DISPLAYL-40 120 IF DISPLAYL>=0 THEN GOTO 170:REM CAN'T DISPLAY NEGATIVE MEMORY 122 DISPLAYH=DISPLAYH-1:DISPLAYL=0 124 IF DISPLAYH<0 THEN DISPLAYH=0 126 GOTO 170 130 REM MOVE DISPLAY WINDOW INTO HIGHER MEMORY 140 DISPLAYL=DISPLAYL+40 150 IF DISPLAYL>240 THEN DISPLAYH=DISPLAYH+1:DISPLAYL=0 160 REM CHANGE DISPLAY MEMORY POINTER 170 POKE LMSL,DISPLAYL:REM PUT NEW DIPLAY ADDR IN DISPLAY LIST 180 POKE LMSH,DISPLAYH 200 GOTO 60:REM GO WAIT FOR KEYBOARD ENTRY The eventual goal is to have a split screen using display lists, having a static mode 11 top—rainbow sky—and a "scrolling" (by changing memory that then propagates down the feedback loop) bottom section in mode 9—ground. The features on the ground should ideally be bits from memory (to simplify my landscape drawing code P189L2.bas.txt
  11. I wish I had that! I remember using it back in the day and it did indeed make display list creation simple. Dispute over whether it's AP117 or AP118, but regardless, I haven't yet found it online
  12. Looking to execute the appropriate part of the keyboard handler that makes the click. Reading the following resources I've gotten more understanding of the keyboard handler. http://www.atariarchives.org/mapping/appendix18.phpand http://www.atarimania.com/documents/Complete_and_Essential_Map_For_the_XL_XE_Part_I.pdfand http://atariage.com/forums/topic/241272-how-do-i-use-the-keyboard-handler-the-proper-way/ They are tantalizing but don't tell me much (but the statement "SHIFT + CONTROL + key (which generate keyclick but don't return anything)" indicates that there is a way to do this, but it eludes me). I wonder if it's possible to pass a "null" key and still generate the click, or alternately simply call the routine that generates the click sound.
  13. Agreed. Any idea if I can call the OS's keyclick code directly from basic? I'm using Turbo Basic XL if that matters.
  14. I know you can turn on or off the key click (POKE 731,0 or POKE 731,255), but I'm wondering if it's possible to generate the key click sound on command? Is there a bit of code to call from basic, or possibly a way in basic to generate the same or very similar noise? I don't remember my sound coding from back in the day or I'd probably be able to figure it out myself. I don't mind cheating by calling the existing key click routine
  15. ! thank you! And I know what you mean about long-disused latent memories. Does anyone know if there's a general-purpose escaping method for all non-printing characters into strings, not just 127?
  • Create New...