Jump to content

damosan

Members
  • Posts

    142
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

2,448 profile views

damosan's Achievements

Chopper Commander

Chopper Commander (4/9)

69

Reputation

  1. Unsigned chars to be specific - same applies to words (or unsigned ints). Sign extension is spendy from a time/space perspective.
  2. I believe -O optimizes for space while the other options are for speed via inlining.
  3. I've been working on getting Mini-Scheme to compile using CC65 - it is a traditional not-8bit program in that is leverages a rather complex union and many getter/setter/istrue/isfalse/etc. macros. On any 16bit processor this wouldn't be a problem. On the 6502 on the other hand... A few CC65 observations when trying to cram code into the Atari - they are, of course, variations on previous themes. The difference in this case is an leveraging existing code vs. building something from scratch. Replace getter/setter/pseudo-function macros with traditional functions where possible. Focus on the getter/setting/pseudo-function macros that are used throughout the code base first. In one case I shaved ~2k from the binary by replacing a widely used macro with a function. Average savings was ~200 bytes for each macro. Replace *s++ = *c; with *s = *c; ++s; - requires less assembly to do the work. It's not idiomatic C by any stretch but when you're trying to shave bytes from the binary... Don't forget to move critical globals to Page 0 - for performance. Doing so will shave a byte each time the variable is accessed and increase performance. Disable select features. In the case of Mini-Scheme it was was neat to see basic threading with call/cc work on an 8bit it was so slow that removal was the real answer.
  4. A fun experiment is to copy the OS to RAM and then overlay your stuff in areas of the OS you don't plan on using. I have a cc65 program somewhere that loads some code overlapping the international character set. Not exactly what you want to do but you get the idea. It's kind of fun saying "I won't be needing any of the cassette driver stuff so....gone."
  5. Unless you copy relevant VBI/DLI stuff to each page right? That would work right?
  6. I like the second approach - you can also shave off the JSR/RTS if you do a JMP and in your routine you simply JMP process_next_function at the end of each routine. That would save you 6 cycles per function call (two JMP immediates = 6 cycles vs. JSR/RTS = 12 cycles). Depends on how your code is structured... fntable_lo: .BYTE <fn1 .BYTE <fn2 .BYTE <fn3 .fntable_hi: .BYTE >fn1 .BYTE >fn2 .BYTE >fn3 TAX LDA fntable_lo,X STA modjsr+1 LDA fntable_hi,X STA modjsr+2 modjsr: jmp $0000 ; never gets here... fn1: JMP process_next_function fn2: JMP process_next_function fn3: JMP process_next_function
  7. It doesn't seem that large for a loop that sets 960 bytes to zero. You can learn a lot from the cc65 library code. https://github.com/cc65/cc65/blob/master/libsrc/atari/clrscr.s
  8. How large is your library compared to the standard fopen/fclose/fread/fwrite?
  9. I'd be a great idea to write a modern Atari assembly language book. It would, of course, cover the basics of assembly language. From there it can begin to cover the hardware and how to exploit it with commented examples. Player/missile graphics, software sprites, multiplexing players, sound, DLIs, VBIs, double buffering, what you can do when you move the OS to RAM, etc. Sort of a modern De Re Atari...
  10. It's been years since I used Action so perhaps this is off base a bit. Action, I believe, is more efficient by default - the features of the language are geared towards 8bit programming. With most C compilers on the 8bit you have to deliberately avoid using certain language features to write efficient code. Going so far as writing your C code as if it were a verbose assembler.
  11. In basic you'd have something like this: 200 A = PEEK (106) - 8 : POKE 54279, A : PMBASE = 256*A PM space aligns on a 1k block - this serves as an optimization of sorts. You'll find this often on the Atari. For example font tables have to align on a 1k block. Your example reserves 2k of ram for single line resolution player/missile graphics. A neat hack is that you can use the first 768 bytes of this block for other reasons.
  12. The better way is to use page zero (or some other unused memory area) to set parameters. In the assembly file you'll define equates pointing to that memory area. This will result in smaller/faster code -- CC65 is great but passing parameters the conventional way will generate slower code. For setting Atari specific registers check out atari.h. You can set ROWCRS / COLCRS directly from C vs. calling a routine to do so.
  13. I have fond memories of Megamax C - I used that compiler to learn K&R C back in '86 or '87(?). The limitations didn't really affect a newbie hacker that much and it compiled pretty quickly. When I mess with C on the ST today I tend to use Lattice or Pure C. If you really want to know how the platform works you'll use assembly.
×
×
  • Create New...