witchspace

Yes I think it's great that they're working on that. After all, the game was supposed to be a trilogy. 33 years late is better than not. But indeed, my project's goal is different, it is about nostalgia and history and making the original game more accessible. I very likely won't be adding any new missions

Just found the code responsible. It is exactly as you say. Track 3, sector 7 is read then the data is discarded, that read is just to (mis)direct the drive. Then Track 3, sector 4,5,6 are read. Sector 4 is check-summed and compared, and if it fails a state word is set which eventually leads to the Red screen of Death. This is in addition to the per-track integrity check I posted about above. FTL was certainly paranoid In my port I just pull down the state word involved in these checks. Too lazy to implement a more accurate implementation of the floppy controller just to make this weird code happy.

The way you word it, it sounds almost like they had a deep philosophical issue with using GPUs? (for anything but rendering/scaling the final image?) I guess because in the early days of GPU computing it all was proprietary and unstable and limited to a few vendors. Today, OpenCL and OpenGL compute shaders are mature open standards and supported by any GPU vendor worth it's salt, even embedded ones. Integer arithmetic is now available, which relieves the precision concerns with floating point handling on some GPUs. Depending on the algorithm it is usually more work to write certain code for GPU, though, that still limits their use in open source projects. Having to implement things twice, once for CPU and once for parallelized GPU doesn't really help either.

I fully realize that. My interest is historical. I don't intend to use it for safety critical production use. That's what I use DosBox for Simulating a computer that never really existed, from just prototypes, is fantastic. Keep up the great work!

The open source reverse engineering framework Radare ( https://radare.org/r/). It is interactive and you can define labels and other metadata. It can also handle huge files. I personally like it lot, though I'm not sure about the state of its windows support because I use Ubuntu. There are however windows binaries available. Alternatively, the non-free version of IDA Pro can handle 68000 just fine.

Proabably currently only builds and works on Linux/Ubuntu, but I've cleaned up and uploaded my code for the Sundog port: https://github.com/laanwj/sundog

To be precies: I tried using all the possible floppy controllers with the TI99/8, with the TI99/4 Pascal floppy images and with none of them, the P-system detected a disk in the drive at all. The images work fine with TI99/4. But I suppose this is the way things are supposed to be, and TI99/8 needs different floppies for the development environment. Or maybe I did something wrong, I'm not very experienced with MESS. I don't have a TI99/8 nor ever had one but I'm interested in UCSD Pascal for various platforms. TI99/8 is especially interesting because the system had native support in BIOS for it. (another computer I'm very interested in is SAGE, but emulation for that isn't nearly as far progressed).

The only cartridge I had back in the day for the Atari ST was something for sound sampling and playback of sampled sound. I don't know the name or specifics anymore.

Not too crazy. I'm working on a port of Sundog: Frozen Legacy to modern platforms. This uses the same principle as the SCUMM engine and ScummVM, or the Inform games and Frotz. This can work because Sundog was written, with the exception of a few small bits of 68k assembly, in UCSD/Softech Pascal. This compiled to a platform-independent p-code. So it was "just" a matter of writing an interpreter for the appropriate p-code dialect and I have most of the game running. With most other games, which tend to be written for the native platform this is going to be much harder. But I'm certain there are other cases where a game vendor used a single engine for a series of games and much of the game logic is scripted in the data files.

So I recently played around with GEM on Atari ST a bit, and palette setting, and (re-) discovered this weird mapping between GEM/VDI and hardware color mappings: unsigned vdi_color_map[16] = { 0, 15, 1, 2, 4, 6, 3, 5, 7, 8, 9, 10, 12, 14, 4, 13 }; Asking GEM VDI to draw a line, v_line with vsl_color 15 would give you a line in... color 13! I don't understand why they would do this. I really don't. Besides being confusing (it took me a while to figure out what was happening). It seems like a waste of resources, which was even more important on old, slow hardware. Why not just remap the palette? There may be some really interesting reason I'm missing. In any case I found this a curious old bit of computing history Edit: sorry@moderator this probably belongs better here: https://atariage.com/forums/forum/175-atari-stttfalcon-programming/

Yes I can confirm Sundog only reads per sector. I would have missed any tricks with regard to ordering of reads, though, as I never realized that could be a concern. Thanks for learning me new things about 80's copy protection schemes

code.google.com went out of business. New link that it redirects to is: https://github.com/simhacker/micropolis

Oh yes this game is neat, played it all the way to the end. The parallel architecture with communicating, very limited nodes is quite interesting, and decidedly different from run-of-the-mill assembly programming.

These would be extremely useful to me. Already found out the hard way in MESS that the TI-99/4 P-system disks won't work :-)

Unfortunately not - Microsoft's "p-code" is a completely different thing from UCSD's or Softech's. At some point it was the fashionable term for what we call "bytecode" today.