CuloMajia

No way can you do DLIs and VBIs with higher languages. If you just want to change GTIA or ANTIC registers, some will compile into LDA + LDX, just to store to an 8-bit memory location. Most of the Basic's compile and store the line number where something is coming from for debugging purposes.

That is really useful. I spent a few hours today getting a game over 35K down to 30K. I had several X = X + 1 and replaced them with X += 1. Sorry about hijacking this thread, however information like this does benefit everyone. Sometimes it is very time consuming to port a whole game from one language to another or replace the whole program with assembly. I started using more tables to set up different enemy types instead of a big IF-BLOCK. ML code comes in handy if after all your optimizations, a program still doesn't run on a 64K machine the way you work like. From what I can see, CC65 runs faster than Fast Basic or Mad Pascal, but pure optimized assembly is the way to go if you need a task to do the job in less memory and/or time. This is a common clear screen routine for me. I don't exactly unroll code, but write to several base locations + index within a loop. LDA #0 TAY Clear_Screen_Loop: STA SCREENMEM + $0000,Y STA SCREENMEM + $0100,Y STA SCREENMEM + $0200,Y STA SCREENMEM + $0300,Y DEY BNE Clear_Screen_Loop:

I have been messing around with CC65 for about a year now. I am discovering the compiled program does take up more room than I originally expected. May be able to do a simple game. But to do anything extraordinary, it will need machine language calls are required to help make things fit into RAM. Assembly routines compile down to much smaller code. Gem Drop, I believe is the first game that uses two character sets switching in alternating frames to generate more colors. Not many games been made that uses this or many programmers / graphics arts mastered it.

Fast Basic has bought something amazing to the Atari Community. Old TurboBasic XL, Basic XL / XE games, may be able to be ported to Fast Basic and bring a whole new life to them. I am digging up some old games and see what I can do with them. I figured out how to use external data like for fonts, sprites, ML routines, music. Inside a separate assembly file do: .segment "ALIGNDATA" CHARSET_GAME: .incbin "GAMEFONT.FNT" CHARSET_GAME_HI = >CHARSET_GAME .export CHARSET_GAME .export CHARSET_GAME_HI Inside the program: POKE 756,@CHARSET_GAME_HI ML routines. If you still have the original assembly. You need to eliminate the first PLA that grabs the # of bytes pushed onto the 6502 stack. I believe the parameters are in reverse order.

This drove me crazy for awhile until someone in another forum pointed out. If you need to send arguments to a subroutine, they are stored in a custom stack upper ram, (The sp Pointer) not the 6502 stack. What you need to do is .... _my_custom_routine: .export _my_custom_routine ldy #0 lda (sp),y sta parameter01 ldy #2 lda (sp),y sta parameter02 ... processes .... lda sp adc #4 sta sp bcc no_sp_hi_inc_r0 inc sp+1 no_sp_hi_inc_r0:

Can make screen vertical variable a multiple of 40 and avoid the ' *40 ' in the program. Can make a table for delta x and delta y for the joystick. JoyDeltaX 00 00 00 00 00 -1 -1 -1 00 01 01 01 00 00 00 00 JoyDeltaY 00 00 00 00 00 -40 40 00 00 -40 40 00 00 -40 40 00 If you cut down the multiplies and divides inside your program, things move faster.

Need to build an interface for that Apple 2 circuit. http://retro64.altervista.org/blog/assembly-math-6502-8-bit-fast-multiply-routine-16-bit-multiply-without-bit-shifting/ Another work around for fast integer multiple and divide is use table driven routines. Seen on an Commodore 64 website. If your program still has space remaining, sound not be difficult to use. Programmers even have fast ways to do trigonomentry functions.

Finally figured out the ML call routine. Need to .export the routine name and either need fastcall or cdecl in with the name in the C program source. Cannot use an ___underscores___ or else it throughs a duplicate definition error. Reason why I am hard pressed to figure C is that I want to also port to NES, Commodore 64, and other platforms. Let's say I already ported some stuff over to Fast Basic and they work very well. What is great a compiled Fast Basic program does not need a Run Time and can run from SpartaDOS. C and Fast Basic, you guys have something very valuable here.

I will try it. Does the parameters get pushed as 2 byte integer values on the stack like Basic does? I have old Turbo Basic, Atari Basic, Commodore Basic game program around for years that I like to port into something faster and put up on the internet. Some decent quality stuff if I can make stuff run faster. For graphics modes. I find it easier to just create a custom display list with the desired graphics mode. Have the option of placing the text window at the top or bottom also.

It will be nice to see this game completed for Atari XL and 5200. Need to find programmer to assist or advise.

Ports of Tempest on XL are bigger than 32K. Not many 5200 cartridge boards around support larger sizes. Plus makers elected not to port to 5200 because of game already sold by someone else. Did not want to get involved with any conflict.

Ships with tracking by US Postal Service.

I am trying to figure out how to do something like a V = USR( routine , parameter 1 , parameter 2, ... ) in cc65. The documentation for cc65 is poor and lacks samples of how to use.

Great to have C programs for 5200. Not hard program for C. Programming is good.

The controller is great. I have to get then build.