dmsc

Hi! Just now I had a look at this. Confirmed the problem, I suspect that the reason it works in windows is that it depends on the order of initialization if the crash will occur or not. I did a pull request with the fix at https://github.com/ilmenit/RastaConverter/pull/7 , also attached is the fixes sources. Have Fun! RastaConverter-fix-segfault.tar.xz

Hi! I don't understand your point, there is a hole from $1070 up to $1BBF, that is 2896 bytes free. As the bootloader only needs 613 bytes, it has more than enough room. Also, the load ends at $1FE6, that is just 26 bytes short of 8K. I tested the ATR in an emulator and it works. Have Fun!

Hi! You can use my "MKATR" (at https://github.com/dmsc/mkatr/ ) tool to produce a bootable disk that will boot in an 8K Atari 400: mkatr -B 17 mazezam.atr -b mazezam.xex The "-B 17" option relocates the bootloader to page 17 ($1100), this area is not used in your XEX. The bootloader used by MKATR uses 613 bytes, and can be placed at any address from page 4 upwards. Attached is the ATR. Have Fun! mazezam.atr

Congrats to @The Car and to @vitoco, you both keep the Atari always at the top of the contest!!

Hi! The above circuit is a series-resonant crystal oscillator, it will operate at the "series resonant frequency" of the crystal. Most crystals you get today will be specified for the parallel resonant frequency, so the above will not oscillate at the correct frequency. The best source for the correct circuit to use for a given crystal is the manufacturer data sheet, for example, this is a random one from a part available on mouser https://www.iqdfrequencyproducts.com/media/pg/1861/1452506068/ic-crystal-oscillator-circuits-rakon-application-note.pdf gives the following circuit: Note that they use an un-buffered inverter, like the 74HCU04, the C1 and C2 capacitors are specified in the crystal part number, and Rlim also depends on the specific crystal. Have Fun!

Hi! Yes, seems people tend to forget that the IIgs was very late, at that time Atari had already released the ST line. IMHO at that time the only sane CPU choice was the Motorola 68000, the 80286 a complicated mess and the "saner" 80386 was a lot more expensive. Sadly, the 6502 was a dead end for productivity applications, I think that the only path forward would have been like the "apple-ii cards" for the Macintosh: a complete Atari 8-bit in a few integrated chips - a 65C02, a combination ANTIC-GTIA and perhaps an "extended" pokey. About adding 80 column support, one way would be to add a font ROM (or static RAM) inside an extended GTIA and take the input from two ANTIC mode-15 lines to index the font data and produce the 80 columns - so you could simply replace the GTIA with this "80 column version" and a little software driver. Obviously you would loose the hardware scrolling and other features - but you could even support some "extended" graphics modes using the line buffer, for example 160x92 GTIA modes, or 320x92 with 4 colors. Have Fun!

Hi! This is because the version you compiled uses the allegro library installed in your system, original one had it embedded in the binary (was statically linked). Have Fun!

Hi! Then, I think you could start with this simplified program, IMHO it is easier to understand: 100 MC=15 110 Z=0.05 120 T=0 130 CX=0 140 CY=0 150 D=64:D2=D*2:H=D-1 200 GRAPHICS 11 210 WHILE D>1 220 FOR Y=T TO 191 STEP D 230 B=CY+(Y-96)/4*Z 240 FOR X=0 TO 79 250 A=CX+(X-40)*Z 260 COLOR 1 270 PLOT X,Y 280 R=0:I=0:R2=0:I2=0 290 C=MC 300 WHILE (R2+I2<4) AND C 310 J=R2-I2+A 320 I=(2*R*I)+B 330 R=J:R2=R*R:I2=I*I 340 C=C-1 350 ENDWHILE 360 COLOR C 370 PLOT X,Y 380 DRAWTO X,Y+H 390 NEXT X 400 POKE 77,0 400 NEXT Y 410 D2=D2/2:D=D2:T=D/2:H=T-1 420 ENDWHILE 430 GOTO 430 The inner loop is the same as the original, but now it uses a WHILE loop instead of FOR, so the exit condition is clearer. Now, you could try to make it faster: - You could change the starting condition (R=0, I=0,R2=0,I2=0) with the condition after the first iteration: R=A,I=B,R2=R*R,I2=I*I, this will make the code faster because you are doing one less loop - You could lower MC and see if the mandelbrot has enough resolution still You could also rewrite it in TurboBasic XL, it should be faster, and TurboBasic has better structured programming so could be simplified a little. Have Fun!

Hi! It is needed if you want the cassette audio to go through the "DVI data islands" (HDMI) interface, that should be the main use case. Also, people would probably want to decode the two-tone data to SIO, so a little audio processing is necessary. Have Fun!

Hi! My question is: what are you trying to accomplish? Your program is still very hard to understand, you still have lines (like line 30 and line 70) that do not do anything, you are using variables instead of numbers in line 40 (I=R instead of I=0), the Q stores 6 different arrays of data, most of that not necessary, the color table is not appropriate for graphics 11, etc. ¿Do you want a faster mandelbrot program? There are faster languages for that. ¿Do you want to learn BASIC XE? Then, your code is not written using any BASIC XE special statements. Have Fun!

Hi! You did not rewrite the program, only rearranged it a little. Your program is an adaptation of an Atari BASIC 10-liner, from this post: https://workshop88.com/oldblog/index.php/2021/03/21/an-interactive-mandelbrot-set-explorer-in-10-lines-of-atari-basic/ Being a 10-liner, it is written to be as concise as possible, without much regard for speed - but the algorithm is a standard mandelbrot plotter. Try to understand the code and write it again without the NEXTs inside the IFs, and without all the unneeded gotos. Have Fun!

Hi! I think it is already merged there, so, it is also in my branch. Have Fun!

Hi! I have a branch that compiles in my Debian Linux, you need to install liballegro4-dev and libfreeimage-dev before compilation: https://github.com/dmsc/RastaConverter/tree/linux-compile # Install libraries sudo apt install liballegro4-dev libfreeimage-dev g++ make # Clone repo and checkout branch git clone https://github.com/dmsc/RastaConverter cd RastaConverter/ git checkout linux-compile # Compile cd src make Have Fun!

Hi! As @Irgendwer said, I went to that path once - started after adding procedure parameters and other optimizations to my basic parser tool (at https://github.com/dmsc/tbxl-parser ), and ended writing FastBasic instead. There is still a branch in the tbxl-parser repo with some work. FastBasic is designed to be easier to compile (no line numbers) and optimize (having native integer variables), and by having a version that runs in the Atari itself is a great tool for writing ten-liners or other simple games, you can see this years "Chaseme" by Vitoco https://bunsen.itch.io/chase-me-atari-8-bit-by-vitoco , "Tetris" and "Gunner" by Eric Car https://bunsen.itch.io/tetris-atari-8-bit-by-eric-carr https://bunsen.itch.io/gunner-atari-8-bit-by-eric-carr - all are incredible for 10 BASIC lines. Have Fun!

Hi! Here is my MAC/65 file conversion tool: https://github.com/dmsc/m65-lister Also, the attached ATASCII to ASCII converter could be useful - I use it all the time in the command line to list ATASCII files, with the '-e' option it will even use terminal codes to show inverse video. Have Fun! conv-atascii-utf8.c