pirx

I've attempted a python port with some modern compiler helpers, but C++ is obviously more performant and stuff. In case you need help with Polish names/comments let me know. @tebe is actively developing mads so the rewritten version might diverge from the original. Not really important for small projects, but large codebases might suffer somewhat. Not a blocker though, because you could stick to the concrete assembler and its version for the dev't process. In other words, this is a worthy endeavor, please do not give up as myself.

the algo is flawed, it needs a rewrite. maybe this hacky way of jumping inside FOR and skipping NEXT is OK for a small program, but it will definitely fail in the long run (return stack gets clobbered). smol opty: D*2 is slower than D+D. divide very bad. floating point generally extremely bad, especially such a smol number as .00000003. at the end everything is integers, so maybe some kind of a rethink with integers would help. some kind of a precalced data maybe

it is a little bit complicated. if you are inclined, you can look at these sources: https://github.com/pkali/scorch_src/blob/master/Atari/lib/5200SYS.ASM <-- definitions https://github.com/pkali/scorch_src/blob/12eebaedecce6cd993163298bfd17cb41523b6a6/Atari/interrupts.asm#L245 <-- VBL routine to read controllers https://github.com/pkali/scorch_src/blob/12eebaedecce6cd993163298bfd17cb41523b6a6/Atari/interrupts.asm#L318 <-- keyboard interrupt continuation I am sure there is a simpler example out there.

Frens, the new version, still hot from the press: https://github.com/pkali/scorch_src/releases/tag/v1.50 Readme has got a smol guide on how to flash the cart: https://github.com/pkali/scorch_src Version 1.50 2024-03-15 Atari 8-bit cart flasher and bug fixes! @RB5200 provided us with very good bug reports so the new version was inevitable. Additionally, we have used a cart flasher from @jhusak to prepare the .atr with the flasher. Fixes and changes: - Napalm and Hot Napalm animations were not playing. - Wind of force 0 and left direction was wrapping arithmetic and caused very strong left shoots. - Now the 0-force wind has got no direction (no negative zeroes anymore!) - CTRL+Tab was non-functional for some time and returned - Much nicer easter egg visualization.

@jhusak prepared a flasher https://github.com/jhusak/jataricart/tree/master/various_flashers/1MBscorch Thank you Kuba!!!!!

ahoy hoy soldiers, The new updated version, good for the physical cart. I heard @Mq. still had a few copies left should you desire to run the game from the official storage. https://github.com/pkali/scorch_src/releases/tag/v1.48 "scorch.car" is a file good for updating the cartridge ###### Version 1.48 2024-03-11 New cart image, bugfixes and easter eggs. In preparation for the festive season we have squeezed the code a bit more, fixed some buggies and added an easter egg or two Most important changes: - Cyborgs prefer attacking human players again! Due to unforeseen circumstances Cyborgs were a bit shy and not as vicious as planned. Fixed. - A new weapon "Propaganda". In the spirit of a ["Phoney War"](https://en.wikipedia.org/wiki/Phoney_War) instead of dropping bombs we drop a bunch of leaflets. This will show them! - Robotanks were making suboptimal purchase decisions. Fixed. - Updated binary manuals. - ... _redacted_ - ... _redacted for egg season_ - A new physical cart image - you can update carts and have even more fun now!

exactly!

00000000 00111100 01100110 01100110 01111110 01100110 01100110 00000000 this is rather simple, I wanted to be concise, but the gist is that when it is time to display a new letter, say "A" as in the example above, you get a column of 8 bits from the character set, so first you'd get 0 0 0 0 0 0 0 0 then 0 0 1 1 1 1 1 0 and so on, and place it on the right end of the screen to be ROLled in in the next frame.

if you need to skip the OS entirely (happens sometimes) you can use this a bit wasteful technique: https://github.com/pkali/scorch_src/blob/7f21748f9fbbacefe3a20de3649ced4c031fbd8b/constants.asm#L587 in this source you've got 2 tables - one with kbcodes, the other one with resulting data. in this example these are INTERNAL codes, not ATASCII, but the idea is the same. You get value from CH, look it up in `keycodes` table and grab the corresponding value from the other table. cons - uses more memory pros - OS independent, somewhat faster clever rearranging the kbcodes table to be monotonic could get O(logN) complexity instead of naïve O(N). if you are not memory constrained you could just drop 2 pages of memory for these tables and get O(1) speed. Of course 1 page is enough - ATASCII / INTERNAL codes in the corresponding places indexed by CH value And the code to retrieve is trivial: ldx CH lda ch_to_atascii_conversion_table,x you can't get easier and faster than this.

i think such an effect was in my demo "Equation of Time". SO the technique is rather simple - for horizontal scaling in a scroller what you do is each frame you get a 1-bit wide vector from a character set and ROL A the whole scroll area. So if you repeat the same bit vector several times, you get wider characters on screen. If you skip some vectors, you get narrower characters. For horizontal scaling of bitmap mode, the most cost-effective are display list modifications - you can repeat a given line or skip it - this effect is also present in the same demo in the upper "barrel", it is much more prominent in "Five2Five" demo (the "carpet" effect).

I had this crazy idea to use pipico RAM as a cache for cart banks. so cart manager populates RAM with banks that will be used now and _soon_ and then in the second thread replaces the unused with new ones. which banks to replace? which load next? I do not know... possibly a generous dose of gameplay would help create some timeline for banks to be copied to RAM. As far as I can see it'd work for space harrier, but it is conceivable to create a cart that would fail miserably, e.g. by reading a single byte, switching to another bank, reading the next byte, and so on. pipico would be unable to keep up with copying banks, I reckon.

Trilogy: - a fistful of bytes - for a few bytes more - the good, the bad and the commodore

@popmilo you can do fake stereło by saving previous frame pokey values and pushing them to +$10 pokey registers in the next frame. it'll cost you a fistful of bytes and sounds surprisingly OK-ish ;))) btw - "A Fistful of Bytes" <--- nice name for a little prod :]

pokey plugin for gpt4 did not understand the question. Not surprisingly, I see "extended mode" in this context for the very first time in my ~40y atari 8-bit programmer career:)))) >show me a program example that uses antic extended mode for Atari 130xe To demonstrate a program that uses ANTIC extended mode on the Atari 130XE, it's crucial to understand what ANTIC is and its role in the Atari 8-bit family of computers. ANTIC (Alpha-Numeric Television Interface Controller) is a custom chip responsible for generating video display. It interprets display lists and fetches character or map data from memory, enabling a wide range of graphics modes and capabilities, including several "extended modes" not directly accessible through the standard Graphics commands in Atari BASIC. Extended modes leverage ANTIC's ability to combine different graphics modes on the same screen, offering more colors or higher resolutions in specific screen regions. These capabilities are particularly powerful for creating complex visual effects or detailed game environments. Here is an example of how you might set up a display list to use an extended graphics mode on an Atari 130XE. This example assumes familiarity with Atari assembly language and direct manipulation of the ANTIC chip: ```assembly ; Example Program: ANTIC Extended Mode on Atari 130XE ORG $4000 ; Start of program *= $4000 ; Assembly directive for program start address ; Set up Display List DLIST .BYTE $70,$70 ; Three blank lines for top border (ANTIC mode 0) .BYTE $70,$70 ; Extended mode often combines text and graphics modes .BYTE $70,$70 ; This part sets up a simple top border .BYTE $4E ; LMS instruction (Load Memory Scan) for ANTIC mode 14 (Graphics 0 equivalent) .WORD SCREEN ; Address of screen memory .BYTE $D,$D,$D,$D,$D,$D,$D,$D ; ANTIC mode 4 (Graphics mode 2 equivalent) lines .BYTE $D,$D,$D,$D,$D,$D,$D,$D ; Repeat for desired length .BYTE $41 ; Jump instruction (JVB - Jump and wait for Vertical Blank) .WORD DLIST ; Loop back to start of display list SCREEN .DS 40*24 ; Allocate space for screen memory (for ANTIC mode 4 lines) ; Set up Display List Interrupts (DLIs) and Vertical Blank Interrupts (VBIs) if needed ; Set up registers LDA #$3E ; Enable DMA for display list & ANTIC modes STA $D400 LDA #<DLIST ; Set Display List base address (low byte) STA $230 LDA #>DLIST ; Set Display List base address (high byte) STA $231 ; Main program loop (or subroutine) MAIN JMP MAIN ; Infinite loop for demonstration .END ; End of program ``` This program demonstrates setting up a display list for an extended graphics mode. It starts with a top border (using ANTIC mode 0 for blank lines), then defines a section in ANTIC mode 14 (a text mode equivalent to Graphics 0), followed by several lines in ANTIC mode 4 (equivalent to Graphics mode 2, which allows for more detailed graphics). Remember, this is a simplified example. Practical use of extended modes often involves setting up display list interrupts (DLIs) for changing colors or modes mid-screen and vertical blank interrupts (VBIs) for timing-sensitive operations like game logic or sound playback. Manipulating these features requires detailed knowledge of the Atari's hardware and its interaction with ANTIC, as well as proficiency in assembly language programming. For a more detailed and interactive example, especially if you want to manipulate colors, mix different graphics modes, or include custom character sets, you would need to expand this framework significantly, incorporating DLIs and possibly changing the display list or character data on the fly based on user input or game logic. -------------------------------------------------------------------------- A side note - I am not getting the hate for LLMs. Look, it is just a tool. It is even useful for some mundane tasks like writing test cases or regexes (it is what I use it for). It is also getting pretty good at searching for shite, much better than googling where you are swamped with SEOed crap. I have this hypothesis that we are in the moment when LLMs are not as good as people in most tasks and it is so easy to find examples of utter silliness, so it is like cars 100 years ago. Your faithful horse could drag your wasted drunk ass from a pub to your hut while cars still cannot do it after all these years (although they are finally getting there slowly). Obviously horse better.

v2.2 ->link<- * much faster config reading * small bugfixes, incl. no dangling ESC after quitting to DOS * new games: ALIENHUN(t), BINDING( of Cosmac), B(lack)RAINBOW CHIPCROS(s) CODEGRID DVN8 FIELD