Jump to content

Search the Community

Showing results for tags 'optimization'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
    • Classic Gaming General
    • Classic Computing
    • Modern Gaming
    • Prototypes
    • Arcade and Pinball
    • Emulation
    • Hardware
    • Gaming Publications and Websites
    • International
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • DMGD Club's Incoming!
  • DASM's General

Blogs

There are no results to display.

There are no results to display.

Calendars

  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 2 results

  1. Hello everyone, I'm a beginner on Atari programming and I'm creating an IDE to allow people to create Atari games without having to write a single line of code. I'm learning Assembly as I go through the IDE and add more stuff, it's helping me a lot. This is what I've got so far: A simple IDE that lets you draw the playfield and change the color of both playfield (COLUPF) and background (COLUBK). If you hit the "Play" button, it will produce the following result on an emulator: This also generates an assembly code file, please take a look at this file to help me with the questions: atarix_result.asm So, considering I've read a few articles about programming, I've come to a conclusion that every single line of code matters when you're programming for Atari. So I would like to ask a few questions: 1. Looking at the file (atarix_result.asm), is the generated code bad? What optimizations should I look forward? How can I optimize this code? 2. What kind of things should I avoid when drawing to the playfield? 3. Also, is there a way to get rid of the parts showed on the second screenshot? (Where the arrows point at). Or is this an expected behavior? Thanks!
  2. I finally got around to implementing a table-driven CRC-16 routine. Table-driven is usually touted as faster, so I wanted to test that claim. With it I have been able to drop overall CRC validation of the Geneve operating system from 8.5s to just under 3.0s. The following code takes advantage of the 9995 internal RAM. The 128K data file is loaded from disk and stored in RAM (not internal 9995 ram!) for the CRC loop. I'm looking for any ideas that might further optimize the loop at label NEXTBYTE. I suspect it's about as tight as possible but would appreciate an outside opinion or two ******************************************************************************** * CRC16s 2013 March 31 * * Approximate execution speed under emulation, 128K file: * 1. 8.5s CRC calculated 'old faithful' way one byte at a time * 2. 4.5s CRC calculated with table; primary loop in local SRAM page * 3. 3.0s CRC calculated with table; primary loop in 9995 scratchpad * WS EQU >F000 9995 workspace * MAIN3 LWPI WS LET'S LOAD OUR WORKSPACE LIMI 0 turn off those interrupts! * * Copy CRC calculation code to u9995 for fastest execution * Called @>F020 after file is loaded into RAM * LI R1,STARTCHIPCODE LI R2,>F020 LI R7,SAVE9995 CLR R8 CHIPLP MOV *R2,*R7+ ultra-conservative - save scratchpad MOV *R1+,*R2+ then move code INC R8 # of words are we overwriting CI R1,ENDCHIPCODE end of code? JNE CHIPLP not yet MOV R8,@CT9995 yes. save the word count for exit[/font] *----------------------------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= * Create 16-bit CRC table in memory * GENERATECRC16 LI R7,CRCTABLE512 point to start of table LI R8,0 0 to 255 LOOPI MOV R8,R10 get next CRC value into RESULT (R10) SLA R10,8 RESult shifted LEFT 8 bits CLR R1 for table, always start as if cleared XOR R1,R10 R1^R10->r10 bug, earlier reversed operands ):- *inner loop starts: LI R9,8 now for our inner loop LOOPJ MOV R10,R2 R2=temp ANDI R2,>8000 SLA R10,1 CI R2,>8000 temp have msbit set? JNE SKIP no LI R3,>1021 XOR R3,R10 yes, XOR it SKIP DEC R9 any left? JNE LOOPJ yes *end inner loop MOV R10,*R7+ move crc value into table INC R8 +1 CI R7,CRCTABLE512+512 last entry? JNE LOOPI * * Set up registers to loop through the 128K MDOS file * GOODFILE2 LI R3,16 number of 8k pages LI R4,PGETBL+8 Using memory starting at >10000 (first page above 64K) LI R5,CRCLIST location to store CRC bytes LI R9,MDOSCRC location to put the MDOS embedded CRC (from memory) * BL @>F020 ** call into on-board RAM - calculate CRC from 128K byte file * EXIT LI R1,SAVE9995 restore 9995 scratchpad saved earlier LI R2,>F020 REST1 MOV *R1+,*R2+ DEC @CT9995 JNE REST1 BLWP @0 Thank MDOS for working so well, then exit *------------------------------------------------------------------------------- * CRC Calculation - Table driven * approx 66 bytes (0xF020-F062) - careful of internal WS's at 0xF080+ * Destroys: R0,R1,R3,R4,R7,R8 * * STARTCHIPCODE MOVB *R4+,@>F111 get a page of data LI R0,>2000 CLR R8 clear the CRC * * COMPUTE THE CRC using our CRC table (generated earlier) * NEXTBYTE NOSKIP MOVB *R0+,R1 GET character from buffer XOR R8,R1 XOR the MSByte! SRL R1,7 we want a word index. [Can we ignore the Lsbit, one less bit shift?] * ANDI R1,>FFFE for now lets mask it [Yes! uP doesnt care] MOV @CRCTABLE512(R1),R1 get the table value (16-bit) SLA R8,8 Shift the old result 8 bits XOR R1,R8 and xor with table entry. R8 is the new value SKIPIT CI R0,>4000 end of this page? JL NEXTBYTE no, get another[/font] MOV R8,*R5+ yes,add CRC to the list DEC R3 any pages left? JNE STARTCHIPCODE RT *** remove if we don't move to on-chip! ENDCHIPCODE ****************************************************** * end of code, data follows * H1021 DATA >1021 crc polynomial (16-bit) CRCTABLE512 BSS 520 CRC table buffer. Pad a few bytes for stupid programmer errors SAVE9995 BSS 256 scratchpad storage for u9995 CT9995 DATA 0 number of words used *--------------------------------------------------------- END
×
×
  • Create New...