dressupgeekout

Just wanted to mention that this finally landed in the NetBSD source tree. It works as long as the partition type is GEM or BGM. "Extended" partitions (type "XGM") are not currently supported just yet, I'll try to add that later. https://mail-index.netbsd.org/source-changes/2024/04/02/msg150650.html

So I actually just went ahead and plugged the SD card into my Linux laptop (Debian/x86_64 "bullseye") and the 2 partitions showed up as /dev/mmcblk0p1 and /dev/mmcblk0p2, it Just Worked. That's Linux 5.10, though. Linux 6.8 is A Thing now so maybe something's happened in the meantime that broke support for it. I'd need to dig through the Git history. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/partitions/atari.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/partitions/atari.h/ I have a theory. There unfortunately aren't any unique magic numbers to be found inside the TOS partition scheme, AFAICT. This means when the kernel is trying to determine "does this block device represent a TOS-formatted hard disk?" you can't give a definitive y/n answer, you kinda have to guess. My NetBSD code does this, even. If TOS support is removed like you've mentioned, then my hunch is that the current code is prone to mis-identifying some non-Atari devices to be inappropriately identified as Atari, and the simplest fix is to just never consider TOS partitions altogether.

TL;DR I can transfer files to and from my UltraSatan's SD card even though the disk is NOT formatted with an ordinary MBR. Hey gang! So, I'm a NetBSD developer. The other day, I was able to extend NetBSD's dk(4) driver to be able to recognize the old, plain TOS hard disk partition map. This allows me to mount the SD card from my UltraSatan, which was formatted with the ICD Pro driver, on a modern PC. I made a video that explains it all, and you'll get to see a quick demo, too! The code is not committed to NetBSD just yet (pending some code review). If I stare at the code really hard then I *might* be able to get it working in Linux as well.

Thanks everyone. I actually have a Greaseweazel to step around the copy protection issues, I just need a little bit more hardware to make it actually work (need another floppy drive, primarily)... maybe I should get on that, heh.

I tracked down a boxed copy of The Sentry (1987) -- also known as The Sentinel, apparently. It's a color game, but I don't have a color monitor, so I use Hatari to provide a virtual one for me. Unfortunately it's one of those bootable games, so I can't just copy the files off the disk and put them into the emulator, I'll need to make an image so that Hatari knows it's supposed to be a floppy. The game's on a single-sided disk, but my 1040 STF has a double-sided drive in it, so that's no problem. The Magic Shadow Archiver doesn't like the disk, though -- it croaks while trying to read the same track of the disk every time. Seems like a bad sign. But I haven't been able to find a copy on the internet that doesn't crash within Hatari, either. Am I missing something here?

Wow, you have a copy of Elden Ring for the Atari ST? Just kidding, what a fun looking setup! I wish I had a proper Atari monitor.

Huh, fascinating. I gave it a quick spin on my Windows computer, it seems to work. Didn't do anything too interesting with it just yet. I do wish it was available for Unix-like systems, though.

Thanks @ParanoidLittleMan . Indeed, using an emulator to generate the RSC file and the C header is what I'm currently doing for development. But now I'm kinda motivated to make my own GUI RSC editor, hehe.

The only ways I know how to edit GEM resource files (*.RSC) are with programs that run on your Atari machine (or in an emulator, of course). But, is there any modern software out there which would let me edit them outside of the Atari environment? Combined with m68k-atari-mint-gcc, I'm hoping to be able to cross-compile an entire project and iterate upon the resource file entirely from, say, my Mac. Edit: I should specify I'm looking specifically for a graphical app.

Hatari already does not require you to use PortMidi if you're on Linux. But you might have to build from source with the correct parameters in order to make that happen.

Hey everyone, I mostly just wanted to share that I was able to successfully use Hatari on macOS to drive MIDI output. An emulated copy of Sweet 16 is able to talk to my MIDI keyboard! There's been a bunch of work within the last month or so in Hatari with regards to MIDI, especially on systems that are not Linux. Less buggy and slightly easier to use. I fixed a crash myself in the process. You can follow that discussion if you like: https://www.atari-forum.com/viewtopic.php?p=427386

Hey everyone. When I read that Classic99 had been ported over to Linux and macOS, I immediately tried to build and run it for myself. I confirm that it's super unstable on macOS, even on High Sierra (10.13). Now that I know about Classic99v4.git, I'm super motivated to play around with it in general, hehe. I'm just gonna go ahead and try building it on NetBSD, too (I maintain several packages for NetBSD) and just have some fun. Very cool stuff here.