pirx

it is just a tool. for me it is super useful, saving me 100's of hours and producing shite better than I ever could. my goal is to use it as much as possible to save time for my atari 8-bit hobby :))))))

I do not think so @jhusak? the best tetris clone with sources is of course tetryx: need sources?

i learned german to read this article.

turbo-basic_xl -English.txt turbo-basic_xl -German.txt

Oh no.... He was living rather close to my place and we were talking about meeting sometime, but he was not feeling good and we have never met :((((((((((( I am devastated......

possibly the best tetris implementation in Action! is "Warsaw Tetris". Very old, but still pretty schmick.

it works better than expected > write a small program in atari basic drawing a circle. please use high resolution (GRAPHICS 10 GRAPHICS 8 15 COLOR 1 20 REM SET CENTER OF THE SCREEN 30 CX=159: CY=95 40 REM RADIUS OF THE CIRCLE 50 R=40 60 REM INITIALIZE VARIABLES 70 X=0: Y=R 80 D=3-2*R 90 REM DRAW THE CIRCLE USING BRESENHAM'S ALGORITHM 100 PLOT CX+X, CY+Y 110 PLOT CX-X, CY+Y 120 PLOT CX+X, CY-Y 130 PLOT CX-X, CY-Y 140 PLOT CX+Y, CY+X 150 PLOT CX-Y, CY+X 160 PLOT CX+Y, CY-X 170 PLOT CX-Y, CY-X 180 IF D < 0 THEN D = D + 4 * X + 6: GOTO 200 190 D = D + 4 * (X - Y) + 10: Y = Y - 1 200 X = X + 1 210 IF X <= Y THEN GOTO 100 220 GOTO 220

it works ok in my 800. i do have incognito.

just like us, just like us...

TBXL is indeed fantastic, even more fantastic with @dmsc parser: https://github.com/dmsc/tbxl-parser FLAPPY.TBS

no, this is a much simpler idea, not a console replacement, but a programmable cartridge replacement using super cheap parts. like poor's man atarimax cart.

I see, I did not know about this difference. I think even something simpler would work - it would suffice to poll a single byte in the cart area, maybe the copyright date as it is read only once. or the start vector. I suppose text search is not that necessary, just some numeric selection and/or cursor moves. As far as I understand this can be done entirely in software, so no additional hardware in the cart is needed, just pipico hooked up to the 5200 cart. As a first step, the pipico software could start just a single cart (e.g.: file with a certain extension). It would be a useful cart already.

this is the basic idea - you upload cart files to the cart (pipico) via USB (PCs see it as an external disk) and then run them from a small menu on 5200. pipico has 16MiB "disk", so a bunch of carts will fit. the cart is then loaded to pipico RAM and served to 5200 from there. RAM is not large (<256KiB), so really big cartridges will not work, but I am not sure if there are many (any?) of such huge games for 5200.

@electrotrains devised a very cheap and surprisingly good cartridge emulator based on super cheap (we are speaking under $2) clones of PiPico like https://www.aliexpress.us/item/3256804090698520.html?gatewayAdapt=glo2usa4itemAdapt I have such a device and it works like a charm. I asked the author if it would be possible to modify the project to work for 5200 and it seems to be doable - there are more address lines required, but there are some signals missing in 5200 like Phi2, R/W, CCTL (?), so it should be OK. I know nothing (practically) about electronics and designing PCBs, but I know a bit about programming on 5200, so maybe someone could make a PCB, I'd modify/write the A8 firmware to run 5200 carts and we'd have a beautiful and super inexpensive cart emulator. This is a call for the hardware specialist to look at this small but mighty project.

i think it is because they printed the case with the case lying flat on the bed where the text is. it ain't not easy for a printer to do an overhang like this. printing upside down would require supports and longer print time, but the letters would look nicer I guess.

XL. Porting to 5200 was extremely difficult because we wanted all functionalities as in the XL game. We were carving byte by byte. Right now the 5200 version has got exactly ZERO free-to-use bytes in ROM. One NOP and the game would not compile. It also required a rewrite of RMT player. The side effect is that the game works also on atari 400/800 with 48KiB. Overall it took us about 6 months to have a version running on 5200.

POT is too slow for sampling (almost the whole screen worth of scanlines), but could be good enough for beat detection or something like this. When you switch to the fast POT mode the resolution is very poor, still maybe good enough for VLM

possibly the cheapest and still good drive emulator: https://allegro.pl/oferta/atari-sdrive-micro-rev-2-0-10511691306

KOZA FIGHTER https://demozoo.org/productions/81613/

used MMG back in the day and it does have the option to compile without floating point (2 byte words only), so it can be very fast. It was a bit cumbersome to use, but the results were always as I intended. You just need to remember that things like GOTO X*10+1000 will not work.

a bit different concept but equally silly - for 10 liners competition a few years ago I was fighting to cram sprite data into the basic program and came up with this ingenious idea - 27367 REM OIiHiiHiug97et77wtgf8x*Fifxwghgigsi___SPRITE_DATA___ keeping data after REM statement is not that innovative, but the line number and REM token were also part of the data itself. It did not work out as good as I envisioned, some unwanted artifacts were visible and I optimized the rest so I could save the data in a text variable, but I just wanted to say that using line numbers as meaningful data is somewhat possible ;]

If anyone finds it interesting here are sources of our similar software: https://github.com/pkali/omc65/blob/master/test/MK720.S65 It detects various PORTB-based memory expansions and can copy disks up to 720KiB and sectors up to 512 bytes. I doubt it'd see 1MiB of RAM, possibly the largest memory we heard of in 1992 was 256KiB. Oh yes, I just checked the code, 256 KiB is the max, but as far as I can see adding detection of additional memory sizes is easy. It can also work with VTOC for SD, ED (1040 sectors) DD, DOS 2.5 / DOS XL, and derivatives, and work with different skews. @AGiambra I was driving yesterday via Largo, who could guess a crazy 1050 stack is living there

WOW!!! It is simply great!!!

Real-world scenario: - text mode, each line is a different charset, say 20 lines = 20 fonts. - I need 54 different characters in each line, which means 432 bytes used in each charset. It means 592 bytes are left unused in each charset. so the definition would look like this (typing from memory, the syntax might be incorrect): align $400 charset01 ins 'chset01.fnt',,432 align $400 charset02 ins 'chset02.fnt',,432 ... align $400 charset20 ins 'chset20.fnt',,432 And in RAM I have 20KiB taken and 19 holes 592 bytes each. Now, imagine you could tell MADS that these holes are free to use... It could fill it up with procedures, tables, and such. It is definitely not an easy task, maybe even impossible for a cross-assembler - a very simple approach would add jumps around reserved areas. A more sophisticated approach would be to reorganize procs and data chunks to best fit the holes. But it smells like a higher-level language, not an assembler really.

exactly! It'd be fantastic to have an option in MADS to reserve portions of memory and fill the rest with the code as it goes. I mentioned it to @tebe some time ago, but I understand it would be challenging to implement.