ggn

I've never seen this thread before, but better late than ever: There are a few 68k cross gcc packages out there, here's mine: https://github.com/ggnkua/bigbrownbuild-git. It works on Windows, Linux and Mac natively.

I added an issue about this (http://jlhconsulting.gotdns.com/bugs/show_bug.cgi?id=230), shouldn't be too hard to implement! And apologies for the derail, I'll let you guys move the discussion ahead in peace :).

No, of course not. It is, however, problematic if one wants to use code from one assembler to the other and hit upon such a problem. And I wouldn't want to force a change in Lyxass too either. The only compromise I can think of would be that the code author would write a warning note in the source code, or somehow detect one or the other assembler and fail if the wrong one is detetcted.

Maybe you'll have better luck if you place the files on a sd card on the Pi's slot?

Is this a code generation bug?

Sadly I have no experience with Java or Processing, but I'd like to post this message just to say that the project looks very cool!

Small update, since there have been outages at the official repo addresses, I have gone and set up a mirror here: http://tiddly.mooo.com:5000/explore/repos, so hopefully there will be some redundancy! (also announced in the official page)

Your warzone.prg is toast. It's either corrupt or truncated somehow, as it doesn't look like a valid TOS program. However, a few seconds of googling gave me a valid Serenade #27 download link (triggered by your video): https://demozoo.org/productions/75580/ ...however, this won't work on TOS 2.06 that your MSTE has (at least, I assume you have 2.06 - do you get the Atari logo while booting?). Luckily, both programs are in STOS and it so happens that I've written a program that attempts to patch STOS profixes.zipgrams for newer TOS versions. It worked here for Saddam, but Warzone was still not working. So I patched that by hand (as I did not fancy trying to debug my fixer). Attached are the results. To recap: - Run PATCH22.PRG before running SADDAM.PRG and everything should work - Run WARZONE.PRG and if you have TOS 2.06 it should run normally Hope this works for you, enjoy! (Or let me know if something is not working)

While we're at it: shout outs to the Intel Graphics command center that, still to this day, registers ctrl-alt-up/down/left/right to rotate the screen in 90 degree steps. (Common question from people back in the 2000s: "Hey I was playing some games on MAME and now all the letters are sideways. Halp!")

This is spot on! Well done @popmilo, @RafalDudek and the rest of the team. I always appreciate 50 FPS action, so this gets top marks from me :). I know from experience that making a full game takes a lot of time and effort, so I hope you keep up the momentum and make it to the finish line!

Greenious has a thread on ST cartdiges over at Atari-Forum (https://www.atari-forum.com/viewtopic.php?t=42989&sid=28d9e21bf95a4aa7b6e4901a181929cb), the DeskCart image is there. If you want to try it on a real machine, you could purchase a sidecart (https://sidecartridge.com) and flash it there.

The author seems to have posted about it in the ST section of the forum:

Literally the first result in Google search for "imhex": https://github.com/WerWolv/ImHex

Hey, thanks for the archives! I'll have a try at compiling them using Turbo C just to see what happens. It might be that any missing assembly bits could be extracted from the released binary and the rest would match. Anyway, thanks!

Hi, I've never written in C back in the day for ST (etc) machines, but here's a couple of links (with downloads) for you: - Shell: Gulam (https://www.atariuptodate.de/en/3504/gulam-shell) or TomShell (https://www.atariuptodate.de/en/461/tomshell) - Editor: QED (https://www.atariuptodate.de/en/212/qed), Luna (https://www.atariuptodate.de/en/208/luna), Everest (https://www.atariuptodate.de/en/205/everest), or just pick one! https://www.atariuptodate.de/en/office/edit However, if you're not hell bent on using H&S, there's many more (better) options for you, that feature IDEs and other niceties: - Laticce C http://www.atarimania.com/utility-atari-st-lattice-c_32706.html - Laser C http://www.atarimania.com/utility-atari-st-laser-c_30410.html - Pure C https://dhs.nu/files.php?t=single&ID=10 (featuring one of the most mature code generators, even by today's standards) Or if you want to cross compile, the most popular choice is http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/ Enjoy!

Also, I just remembered

From personal experience (not on this platform, but https://d-bug.me/patch.php) there are many ways such a project could go, a few of them are mentioned already: Extract the data from disk, place it into files (or as raw data really) into a large enough disk, then patch the game loader (or loaders) to load the requested data from the new locations Expanding on the above, pack the data so they'll consume less space so there's better chance of the game fitting into a conventional disk For systems with expanded memory, load all data in one go and then patch the game loader(s) to jump to a "sector emulator" that will feed the data into the game Why stop at floppies or carts? Store the data on a hard drive partition and then suddenly space stops being a hurdle For game saves, either use the original game routines (so, use a save disk) or patch them according to whatever fits the chosen scenario from the above list And before people start complaining about hard disk being too hard as the game might overwrite DOS/drivers, we have also solved this problem! https://d-bug.me/uls.php is a loading/saving system that swaps out the OS to other parts of RAM, enables you to run the game, and when it's time to do any disk access it swaps the system back in, performs the load, swaps the system out again, and feeds the data back to the game :). Anyway, all this is easier said than done, but depending on the amount of work someone is willing to put into such a project, all should be doable. And of course none of the above suggestions assumes a magical system that will do all this transparently - there will be manual work required.

If you're going to make a backrooms creepypasta inspired game, this is already spot on: (Happy new year!)

Nope, can't think of anything. My only guess would be TOS versions. Maybe the game is detecting the ST's TOS somehow and switches resolutions on its own.

Perhaps you have a DESKTOP.INF in your Mega that switches to medium resoltuion?

Well, that information came a few decades too late. I've since then solved the problem by using siosd, Fujinet, Avg/Subcart and many more. Moving on! (and sorry for the thread diversion)

I knew that, so I bought one of those things that punch holes on disks for the 2nd side. Aaaand it never worked. Oh well!

Also, https://docs.dev-docs.org contains a wealth of documents, books, and the official Atari SDKs. Finally, https://github.com/ggnkua/Atari_ST_Sources/tree/master/ASM/Atari Corp contains some example code for STE from Atari.

In your first screenshot it looks like you're running the game from medium resolution, and the game doesn't auto switch to low. This doesn't seem to be a timing problem.

When I got an XF551 with DOS 2.5 in the late 80s, without Internet or pretty much any other Atari resource apart from some Atari User issues, I knew no better. Heck, I didn't even know that the 551 could do double density up until a few years ago. So, all my disks were formatted ED.