Jump to content

M12

Members
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

1 Neutral

About M12

  • Rank
    Space Invader
  • Birthday 04/11/1994

Profile Information

  • Gender
    Male
  1. Thanks! And thanks again for letting me know about the 16-bit shift, cause I needed that too.
  2. Ah yup. I see. I read that x.y notation within the last few days and already forgot about it. Thanks! And your extra precision makes sense, but then I'd have to interpret the numbers in an odd way. I am getting around to not using fixed numbers at all in my program. Take 1.23 for instance. I just store that as the whole number as 123 and interpret it as 1.23. In other words, forget about precision. Instead, I'm focused on making large numbers!
  3. Yup, I am attempting to write my special-case code. It's rather tedious. Thanks. And this is definitely helpful. I was using an algorithm known as CORDIC to implement some trigonometry functions. ... But as long as I have the space, I ought to just make a large lookup table for my sine, cosine, and cotangent functions.
  4. Does 7800basic have bit shift operators? I can't find them in the documentation here: http://www.randomterrain.com/7800basic.html And if it doesn't, then how would I use the 7800basic "asm" command to write the 6502 assembly code to perform the operation, say, num1 << num2 (logical shift left)? Thanks!
  5. Can images be drawn without the use of sprites in 7800basic? I'm guessing one has to use the asm command to use some assembly. The main reason to draw pixel by pixel is because I currently have a wonky implementation of drawing a line by lining up sprites. I was wondering if there was a method (probably in assembly) that draws a pixel-based line. My sprite based implementation is in 7800basic, and it calculates slope and whatnot. Then it chooses certain sprites based off of the slope and then draws them from one end of the line to the other end. But this is probably a really bad way of drawing a line. The implementation I'm hoping for is one that takes an x0, y0, x1, y1, and draws pixels from (x0,y0) up until (x1,y1). I'm looking through the following thread from atari-forum.com: "http://www.atari-forum.com/viewtopic.php?t=9549," but I'm not sure how helpful it is for me. Edit: One attempt is to use the code: * INPUT: d0.w: X1 * d1.w: Y1 * d2.w: X2 * d3.w: Y2 * d6.w: highcolor word (color of line) * a0: start of screenaddress DRAW_TRUELINE move.l d2,d4 move.l d3,d5 sub.w d0,d2 ; / calculate the absolute bpl.s .ok ; | value of the difference neg.w d2 ; \ between X1 and X2 .ok sub.w d1,d3 ; / calculate the absolute bpl.s .ok2 ; | value of the difference neg.w d3 ; \ between Y1 and Y2 .ok2 cmp.w d2,d3 bhi.s .ver * Part for dX > dY cmp.w d0,d4 ; / Get the bhs.s .do2 ; | heighest exg d0,d4 ; | X and Y exg d1,d5 ; \ in d4.w and d5.w .do2 moveq #10,d2 ; \put #640 lsl.l #6,d2 ; /in d2.l (bytes in scanline) sub.w d0,d4 sub.w d1,d5 add.l d0,d0 adda.l d0,a0 mulu.w d2,d1 adda.l d1,a0 tst.w d5 bpl.s .poo neg.w d5 ; / make the neg.l d2 ; | dX absolute .poo swap d5 ; | and negate the scanline- addq.w #1,d4 ; \ offset if needed divu.w d4,d5 ; d5.w: steepness moveq #0,d0 subq.w #1,d4 ; d4.w: number of times to loop .lp2 add.w d5,d0 ; / check if you need to jump to bcc.s .mov ; \ the next scanline adda.l d2,a0 ; jump to the next scanline .mov move.w d6,(a0)+ ; plot and go to next pixel dbra d4,.lp2 rts * Part for dX =< dY .ver cmp.w d0,d4 bhs.s .do exg d0,d4 exg d1,d5 .do moveq #10,d2 ; \put #640 lsl.l #6,d2 ; /in d2.l (bytes in scanline) sub.w d0,d4 sub.w d1,d5 add.l d0,d0 adda.l d0,a0 mulu.w d2,d1 adda.l d1,a0 ; a0: address of first pixel tst.w d5 ; / make the bpl.s .shitt ; | dY absolute neg.w d5 ; | and negate the scanline- neg.l d2 ; \ offset if needed .shitt swap d4 addq.w #1,d5 divu.w d5,d4 ; d4.w: steepness moveq #0,d0 subq.w #1,d5 ; d5.w: number of times to loop .lp add.w d4,d0 ; / check if you need to jump to bcc.s .movie ; \ the next pixel in the scanline addq.l #2,a0 ; go to next pixel in scanline .movie move.w d6,(a0) ; plot the pixel adda.l d2,a0 ; go to next scanline dbra d5,.lp rts which I got from the linked thread. But I am unsure of a lot of things. Such as: What is the starting address of the screen? How do I call this subroutine? I see that it ends in an rts statement, so should it be called in 7800 basic as a function call? Or should I just use goto and labels for this?
  6. Does 7800basic have any built-in mechanic to support numbers larger than 255? And does it have support for fixed numbers with greater precision? I've implemented my own multiplication function for fixed numbers, but the division function relies on iterations of the multiplication function, which leads to errors, so I believe I need to be more precise with my calculations and then round at the end. Thanks
  7. Another thing I just noticed was that even a simple function such as function foo return 0 does not let the game play. It just displays the familiar Atari screen, then it goes to a black screen. I did not even call the function yet. Is there a certain area I should be writing my function declarations?
  8. Ahhh, I see now. And now I also see that you explained this in the earlier post, but I didn't realize. Sorry I didn't catch it then. Thanks a bunch!
  9. Cool. I'll just leave 'end' out then. Thanks. And as for the fixed point. The integer part is represented correctly. I understand BCD as well. But yeah, the fractional parts aren't a representation I'm familiar with. A thing I mentioned previously is that when you do take the fractional parts and add them together, it gets what you'd expect anyway. ... 1.5 (0180) + 7.7 (07B3) = 9.2 (0933) ... note that 80 + B3 = 34 and 34 - 1 = 33 (since 1 is carried), which is the arithmetic for the fractional parts.
  10. Well they are hexadecimal numbers, but I am good with normal hex conversions. If you do the conversion, it is not what you'd expect though. Thanks anyways
  11. Thanks RevEng and ErikM. That cleared up a lot. Mord, your solution worked. I'm not too sure how to deal with functions in 7800 basic. function multiply temp1 = temp1 - 1 temp4 = temp2 for temp3 = 1 to temp1 : temp2 = temp2 + temp4 return temp2 end Whenever I try to compile my code that includes this, it says that 'end' is an "unknown keyword". But this is a keyword according to the 7800basic guide. I also tried making 'end' not have any indentation, but then this resulted in "extraneous end statement found". I also have a question about fixed point numbers. fp1 = 3.5 is for some reason represented as 0380 when I try to display it using the following: plotvalue scoredigits_8_wide 0 fp1 4 x y I am not sure why the decimal part of the number is represented as 80. Whenever I have say the numbers 1.5 and 7.7 (0180 and 07B3), adding them together results in 9.2 (0933). So the representation of the decimal part has some meaning because 80 + B3 = 133 - FF = 34 (not 33 because we carried the 1 over to the integer part). Why are the decimal parts represented like this and how do I convert it to a more familiar representation?
  12. Here's another question. I'm going through the source code for BASE78 because it includes the Asteroids code, which I am going to look through further. I had thought that the ".O" files were the machine code files, but when I tried to run the emulator (MESS) on the ".O" files by itself, it didn't work. How do I output the file used by the Atari or emulator from the source code?
  13. Hi all, I'm new to 7800 programming. I'll let you know some of the things I know (and maybe you can correct me). And I also have some questions. .a78 files are the machine language files that run directly in an Atari or an emulator such as Mess. How does one assemble such files? Is there an assembler I can download that can convert a ".S" or a ".a" into the machine code file that I can run on an Atari or emulator? What is the difference between a ".S" file and a ".a" file? I downloaded source code from atarimuseum.com for a game such as Dig Dug, and all of the files are ".S" files, which seem to just be assembly files. I also downloaded a game called INV+ (http://www.dos486.com/atari/index.shtml), which came in the form of a ".a" file, which seems to be an assembly file with some other assignments such as "BombDelay = $C6" at the beginning of the file; are these assignments just defining things so that the code is easier to read? INV+ also had a ".bin" file, which seemed to just be machine code (so a ".bin" file can also be run on an emulator or an Atari?). Now, when it comes to BASIC files, the extension is ".bas". The games that came in the 7800basic download such as simple and adventurer had ".bas" files. The 7800basic is a compiler that takes in a ".bas" file as input and produces a ".a78" machine code file. Whenever I run 7800basic on a file such as "adventurer.bas", it outputs a 7800.asm file (which is an assembly file) and a "a78info.cfg" file. But there is no adventurer.bas.a78. Am I just not waiting long enough for the compiler? How long should it take? Finally, are interpreters useful to use on a BASIC file rather than a compiler? Thanks if you answer any of these questions!
×
×
  • Create New...