Jump to content

Search the Community

Showing results for tags 'speed'.



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
  • 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
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena

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 5 results

  1. So I have a few lines of code I want to optimize for speed. Have some ideas what I can do, but I'm also very interested seeing what the community comes up with... The code is used for reorganizing my TiVi editor index when I delete a line in the editor. Note that when I reorganize the index, I make sure that the index pages form a continuous memory region, so I don't have to worry about mapping pages or anything. That's already been taken care of. The index can grow up to 5 SAMS pages mapped to (>b000 to >ffff) for 10240 lines of text. ok, Here's what I would do: Copy code to scratchpad and work from there for reducing wait states Reduce loop counter overhead by putting multiple mov instructions in a single loop, say 8 Look at the fastest mov instructions (only use registers?) What else could be done for faster access? Note that in the code fragment tmp0=R4, tmp1=R5, tmp2=R6 and so on. *************************************************************** * _idx.entry.delete.reorg * Reorganize index slot entries *************************************************************** * bl @_idx.entry.delete.reorg *-------------------------------------------------------------- * Remarks * Private, only to be called from idx_entry_delete *-------------------------------------------------------------- _idx.entry.delete.reorg: ;------------------------------------------------------ ; Reorganize index entries ;------------------------------------------------------ ! mov @idx.top+2(tmp0),@idx.top+0(tmp0) inct tmp0 ; Next index entry dec tmp2 ; tmp2-- jne -! ; Loop unless completed b *r11 ; Return to caller *////////////////////////////////////////////////////////////// * TiVi Editor - Index Management *////////////////////////////////////////////////////////////// *************************************************************** * Size of index page is 4K and allows indexing of 2048 lines * per page. * * Each index slot (word) has the format: * +-----+-----+ * | MSB | LSB | * +-----|-----+ LSB = Pointer offset 00-ff. * * MSB = SAMS Page 00-ff * Allows addressing of up to 256 4K SAMS pages (1024 KB) * * LSB = Pointer offset in range 00-ff * * To calculate pointer to line in Editor buffer: * Pointer address = edb.top + (LSB * 16) * * Note that the editor buffer itself resides in own 4K memory range * starting at edb.top * * All support routines must assure that length-prefixed string in * Editor buffer always start on a 16 byte boundary for being * accessible via index. ***************************************************************
  2. Your personal Whiz-Bang moments in Apple II computing, what were they? What made you stand up and go ohhh wowwww! What totally amazed you about the Apple II in its day & age? One of my moments was plugging in setting up my a Sider HDD. A whopping 10Meg jobber too! I was quite taken with how fast all my single-file "brun" games loaded. And I didn't have to swap floppies to do it either! I could put millions of these games on it and have room to spare!! I swear I was entering into the realm of mainframe computing back then. After the gaming stint, and less "oh wow" but equally impressive was transferring BBS operations to a fixed disk. This opened up enormous speed improvements in log processing and program editing. I'm one to make 20 changes to program then save it. And repeat. So the savings in load/save times were great. Another magic moment in Apple II computing was adding in a clock card. After hours and hours (no pun intended) of fussing and mussing I decided on the Applied Engineering TimeMaster II H.O. I felt (however stupid it might seem) that I increased the intelligence factor of my rig. It was now aware of the passage of time. And incorporating it into BBS activities was a real hoot! I had time and date stamps everywhere it seemed. And a user could now only spend X amount of time in this or that section unless they upload to gain more time. Great stuff! But I mostly let that slide when I tallied up the logs. I always wondered where the H.O. (high-output) designation came from. I understand it was a generic marketing term used by General Motors to trump up anemic V6 or V8 engines in the Camaro lineup. The Ford Taurus IIRC went beyond that with S.H.O. So what were your magic moments?
  3. I always knew that TI BASIC used the VDP RAM for most things. I also believed that the VDP RAM was a big contributor to the slow performance of TI BASIC. So I decided to create some code for CAMEL99 Forth that would let me create variables and strings in VDP RAM using the same kind of code that is used by Forth for this purpose. Here is the code that creates the memory allocation commands. The actual words are the like the Forth equivalent but they have 'V' prefix. HEX 1000 CONSTANT VBASE 37D7 CONSTANT VENDS ( this allows 10k of VDP RAM for data) VARIABLE VP ( VDP memory pointer) : VHERE ( -- addr) VBASE VP @ + ; ( returns next available VDP addr) : VALLOT ( n --) DUP VHERE + VENDS > ABORT" VDP MEM FULL" ​ VP +! ; I needed a way to create a variable and a buffer to hold a string. I also made a buffer creator for CPU RAM while I was at it. : VDPVAR: ( -- Vaddr) VHERE CONSTANT 2 VALLOT ; : VBUFFER: ( n -- Vaddr) VHERE CONSTANT VALLOT ; : BUFFER: ( n -- addr) CREATE ALLOT ; ( CPU ram buffer creator) CAMEL99 already has ASM code that is equivalent of fetch and store for integers that operate in the VDP RAM. ( [email protected] and V!) but I needed routines to move a string from Forth into VDP ram with the count byte included. I also needed a way to GET it back into Forth. While I was at it I made a PRINT for both kinds of strings. ( PLACE a string from CPU ram into VDP ram as a counted string) : VPLACE ( adr len vdp-addr -- ) 2DUP VC! 1+ SWAP VWRITE ; ( GET a counted string from VDP ram and return address and count on stack) : VGET ( V$ -- addr cnt ) DUP [email protected] PAD SWAP 1+ VREAD PAD COUNT ; ( syntax candy) : VPRINT ( VDP$ -- ) VGET TYPE ; ( print a VDP string ) : PRINT ( cpu$ -- ) COUNT TYPE ; ( print a CPU string) Then I created variables and buffers in each memory space. DECIMAL VARIABLE X VARIABLE Y 50 BUFFER: B$ VDPVAR: Q VDPVAR: W 50 VBUFFER: A$ Below is the test code which completely blew away my assumptions about the speed of VDP RAM. For integers there is a pretty big hit as you can see. 50 to 75% slower in VDP ram. BUT there is only about a 9% slowdown when using VDP RAM for string storage! I am really surprised. This ran on CLASSIC99. Maybe somebody can tell me if real hardware would show the same kind of results. BF NOTE: Both Forth routines PLACE and VPLACE use ASM code to do the actual byte-by-byte movement of data. Forth only massages the parameters on the stack for the Assembly code to pick them up. DECIMAL ( integer store and fetch test) : CPU_R/W ( n -- ) 10000 0 DO I X ! X @ DROP LOOP ; ( 4 SECS) : VDP_R/W ( n -- ) 10000 0 DO I Q V! Q [email protected] DROP LOOP ; ( 6 SECS) ( test integer to integer transfer speed) : CPU_A->B ( n -- ) 10000 0 DO I X ! X @ Y ! LOOP ; ( 4.5 SECS) : VDP_A->B ( n -- ) 10000 0 DO I Q V! Q [email protected] W V! LOOP ; ( 7.9 SECS) ( test write a string to VDP RAM) : VDP$ ( -- ) CR S" Initial A$ string." A$ VPLACE CR A$ VPRINT 5000 0 DO S" This string was placed into VDP RAM 5000 times." A$ VPLACE LOOP CR A$ VPRINT ; ( 11.4 SECS) : CPU$ ( -- ) CR S" Initial B$ string." B$ PLACE CR B$ PRINT 5000 0 DO S" This string was placed into CPU RAM 5000 times." B$ PLACE LOOP CR B$ PRINT ; ( 10.6 SECS)
  4. So, I know that the main CPU runs at 1.19 Mhz, and I also know that the TIA is 3 times as fast as the 6507, so it runs at 3.57 Mhz. How would I figure out how long a single color clock takes to execute?
  5. Here is a quick, speed metal demo, coloring-book style from 40 pounds ago. I'm thinking I'd like to use it in a Sega CD game I'm working on. https://www.youtube.com/watch?v=4XwIxZ6V984&feature=youtu.be Please, for the love of Pete, comment, link, subscribe, talk to me out of the ceaseless ether.
×
×
  • Create New...