ggn

Hi, here are a few links to online shops (and projects) so you can choose and pick what suits you better. Or, come back with questions if something is unclear: https://lotharek.pl/products.php?id=15 https://centuriontech.eu/product-category/atari/ https://thebrewingacademy.com/collections/atari-st-ste-mega https://shop.inventronik.de/index.php https://www.van-radecke.de/STUFF/tfhh_HW_info.pdf https://www.eltradec.eu/index.php/en/w/acsi2sd https://www.arananet.net/pedidos/product-category/atari https://github.com/agranlund/STRam In general there are many options for storage these days, both for hard disk and floppy drives. RAM upgrades are tricky and will most definitely require soldering. a PS/2 to ST mouse adapter is, as expected, just plug and play. I'll end by mentioning two products which are currently out of stock but are fantastic if you can get hold of them (especially CosmosEx is way better than a Fujinet) http://joo.kie.sk/?page_id=384 http://ultradev.ultrafex.de

Duplicate, please ignore

Duplicate, please ignore

@Heaven/TQA actually allowed the modification of the binary file (see https://www.pouet.net/topic.php?which=11559&page=2#c549103), but of course you can have your own fun by following the rules you want :).

Okay, this took a little longer than anticipated, but: rmac v2.2.15 is now out! http://rmac.is-slick.com/#rmac-2-2-15 This is mainly a bugfix release, which addresses changes introduced in v2.2.14. More specifically, the code against exporting fixups that are used as a part of an expression was too strict and produced an error on symbols that could actually be fixed up by the linker. Happy coding!

Ahhh, if only I had so much desk space! I'm forced to have pretty much the same machines (MSTE/TT/MST/Falcon) in roughly half the size of that desk!

If nothing else, it sure looks like an awesome monitor stand (I also keep forgetting what it does, so I had a look at https://www.atarimagazines.com/v3n4/ATR8000.html)

What @Keops said, don't assume things you haven't measured and know nothing about.

An answer to my question above has been found, so I'll quote the list again with the extra steps needed for future reference to myself and everyone who wants to try this: Many thanks to the person who gave me the suggestion! (you know who you are)

@macsonny I'd be down for one if there's a surplus. Also, re: getting paid for your work etc, I can only relate to myself: I've been releasing software for ST (and others) for free for more than 20 years now. A lot of personal time has been invested in learning the machine, CPU, peripherals, esoteric stuff, trivia etc. With a few minor exceptions (commercial/physical products) I've never charged anything for anything I've released. Not that I wouldn't mind the money and that I don't value my work. It's just that I do it for the community and for the fun of it. In our times nobody would hire someone to write Atari code professionally, and if that thing ever happened, the hourly rates would have been insane! On the other hand, I do know how much more of a hassle a physical release is compared to plain software. So again, not bad to charge some extra for your efforts and expertise, but still I'm not in it for the money and I wouldn't want to charge what I think is worth my time. tl;dr do what you want and don't worry about it, just have fun!

Hi @flashjazzcat, thanks for all your hard work! I have an open question: Did anyone try to update the firmware using an AVG cart? I tried the following: Memory config set to 1088K RAMBO AVGcart plugged in + SIO cable installed SDX disabled PBI disabled Boot to AVG menu, mount FIRMWARE.ATR and reboot Go to U1MB menu, enable SDX, reboot SDX comes up, I can DIR and see the files of the mounted disk I try to run UFLASH.XEX At this point I see the AVG's led flashing for a few seconds, then everything apparently freezes. I tried a couple of things like holding OPTION while booting, but same result. I thought I've managed to do this in the past but I'm not sure. In the end I just loaded the ATR from a SIOSD and upgraded the BIOS with no problems. So it's not a biggie, I'm just curious to see if this is possible or not.

For anyone interested (and in case @cubanismo didn't receive an email notification): there is now a tentative patch for this. Let me know if this fixes your problems!

That's exactly what we do: for large projects we just assemble all the things we want to test, and keep reference binaries to check against the newer built files. This way we don't drop compatibility (or at least try to!) Anyway, sorry for making you waste more time with this update :(. And really you shouldn't waste even more time trying to fix things, just shout at us and we'll fix it (since we broke it in the first place!)

Thanks for the heads up. I shall look into this soon (and I really ought to make a note of adding the 3D library in the regression tests).

And for the people who want to try out more things on their MT32/MT32-pis, we released a small intro near Christmas: https://www.pouet.net/prod.php?which=93111 Apologies for not mentioning this sooner here, I simply forgot!

I think that the assembler reporting of long jumps that could be short is the best solution. Can be ignored at will (or it could even be a switch so it isn't shown during assembly) during main development, then taken care of during the final stages of the project, or when the cycle budget gets tight. But the worst part with adding extra directives is tool lock-in. Suddenly your source isn't portable (for example if others want to use your code it won't be as straightforward), and not straightforward to read for someone who isn't accustomed to the tool. Just my 2 cents, and full disclosure: I do work on an assembler myself.

Here's some source code from Dave Small: https://github.com/ggnkua/Atari_ST_Sources/tree/master/ASM/Various/David Small And here's an excerpt from the comments that caught my eye and always gives me giggles: ;PASS ME THIS STUFF DAN! Then SHAVE! For God's sakes! What ; are you trying to do, look like Fidel Castro? ; ; And get SOME BEER in here okay? Sheesh!

Hardware kaleidoscope mode: ON

Sure, it's all appreciated. Even further, if you would share some of the source of your previous porting efforts, then perhaps someone would be inspired to do ST ports of them as well!

Happy new year everyone! Yesterday I tried to use the Windows install .exe but got pretty much the same issues as @dukdukgoos got. So I downloaded the original .bat file from https://github.com/peterdell/wudsn-ide-install (I assume @JAC! uses a .bat->.exe converter on this) and modified it slightly so it can download the eclipse zip from another source. Then (with some other minor modifications) everything worked fine. I've attached my version of the .bat file, but please note that this is just an emergency fix until Peter sorts out his server to host the eclipse .zip. Now, the reason I attempted to install it yesterday was to see how hard it would be to add support for rmac to the IDE. It's probably nothing too difficult, but I'd need a working java SDK installation first (I assume!). Then I'll probably send a patch or pull request :). wudsn.bat

Okay, since this thread was super necrobumped anyway... @ijor can you remember which games from Mastertronic had this? Would be fun to check them out!

This doesn't ring a bell, but here's a list of racing games on ST you could go through: http://www.atarimania.com/list_games_atari-st-racing-cars_genre_99_S_G.html Good luck!

Ok, thanks for the reply. It seems that switch h- is useful for creating a single blob of code assembled at a fixed address, so: all good! (rmac does this using the -fr switch: http://rmac.is-slick.com/manual/rmac.html#the-command-line but it disallows using more than one contiguous segment)

Thanks. I'm just wondering what happens in the case of creating a .xex (.com) file. In order for what you and @DjayBee to happen is for the assembler to force a new segment when encountering .ds statements, some bytes would have to be written. I guess I should just stop being lazy and try it out for myself! The reason I'm asking is that I do maintain an assembler with XEX support (http://rmac.is-slick.com), so at the off chance someone wants to use it I should make sure that its behaviour is what the standard is for Atari 800 assemblers

If I may ask: What does happen if you add a .ds statement in the middle of your source? Does the assembler force a new segment there and skips the area you .ds?