invisible kid

One area where Atari computers seemed more accessible than others that I tried at the time was BASIC and the editing capabilities. A new user could start writing BASIC programs with straight-forward access to the sound and graphics capabilities. Could also incorporate machine language subroutines. Editing programs was easier than on some of the other platforms, you would not need to re-enter lines, you could just edit existing lines and update. I'm not saying all other computers at the time had these issues, but definitely at least a couple did.

I took a quick look at cleaning them up. It looks like cr/lf's were replaced globally with tabs. So now, some tabs are supposed to be tabs, and some tabs are supposed to be line feeds. I hope I am wrong because it would be difficult/impossible for a script or command to be able to tell the difference and clean them up. Or maybe like someone else said, all cr/lfs were just stripped out, which would be equally hard to replace by script or command.

Thanks! I will play around with it more tomorrow.

I tried running M-COIL.XEX from atari800 emulator and got sound only. I was looking at the webpage, so I built and installed blink on linux, but was still unable to run it. It looks like there were some bootstrap instructions at https://language.metaproject.frl/#other but there was no executables created called run or compile. Not looking for help, just wanted to say I'm trying to get it going. I'll still keep hacking at it. Just throwing it out there in case someone has already overcame these difficulties.

Keep us updated if you can!

Nice sleuthing!

I wasn't familiar with this so did some googling. It looks like a MIDI expansion device. Very cool!

So if I remember correctly(don't have time to look at the code right now), the machine code only calculates and updates the screen data, and the BASIC portion just randomly places starting cells. If that's the case, you might improve it by creating an interface where you can enter the cells via joystick, then press START or something to start/stop the cell calculations. Maybe have SELECT only run one generation per press. Then the next BASIC type improvements you could make are saving/loading cell layouts. If you want to just mess around with the generation rules, like you said you would have to modify the machine language subroutine. The Wikipedia page(I think) would have rule variations and certain patterns that would work well under the new rules. Another improvement would let it run in different graphics mode, but that would also require messing with the machine code. You could also remove the machine language routine and perform the cell calculations in BASIC. It would run slower, but it would be much easier modify on the fly.

Nice work!

Hope it works out okay! Love the 8 bits, but if I'm gonna play Lunar Lander, it's going to be the arcade version! To be honest, wasn't even aware there was an 8 bit version.

Glad you're back and persevered through it all! I know it's not easy.

Best Electronics has a cable: https://www.best-electronics-ca.com/monadapt.htm#2nd I also got the adapter that is listed along with it. For redundancy I also ordered an adapter from Centurion. They were out of stock, so I put my name on the waiting list, and got one not too long after.

mydos.c:989 map[sec_bitmap/8] |= mask; // Set to one (free)

A segfault will generate a core dump file unless there is a configuration set to not produce one. Then you can open the core file with gdb and it will show a trace of what code it went through and the crashpoint. You can also command gdb to create a core file manually. This page is for a specific distro, but the information looks general. https://wiki.archlinux.org/title/Core_dump https://stackoverflow.com/questions/5115613/core-dump-file-analysis