pirx

there is a list here: https://fujinet.pl/#2

A mildly interesting tidbit - in this highest total resolution it is not possible to have a continuous screen memory because graphics memory must not cross 4KiB. Full screen in this resolution takes 240 * 48 = 11520 bytes which means two Antic address reloads are necessary. The first can be placed on the 4KiB barrier, but the second cannot.

Newton updated tnfs server and firmware code to support TCP/IP protocol and finally, fujinet is usable in places where the network is not stable enough for UDF transmission. The default tnfs servers have already been updated and usability reports are very encouraging, with several users mentioning the transition of fujinet from a drawer-dwelling gadget to a useful device. The updated firmware is available here https://atarionline.pl/forum/comments.php?DiscussionID=7476&page=2 (post 12). Hopefully, it will soon be released to the official flasher.

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