pedgarcia

That's cool, and you actually reminded me I was going to get my membership for the first time .. Done!

Hey @zbyti, it looks great! I've been using Action! editor (full immersion ) and I found it excellent, even for today's standards, but the Atari's 40 columns display doesn't help much to visualize the code. I will try to get going something similar you showed in your video using an external editor. Another point I wasn't thinking is the amount of memory the editor and the code would take. My current game is very small so that's ok, but at some point I can see things will start to get more complicated to manage. Thanks!

Hey @zbyti, thanks! That is a very organized code (compared to mine so far!) . I noticed that you have a module with low-level routines and some of them are part of Action! standard library (not sure if that is the correct term). Why did you do that? Was to have more efficient code, or simply to have only what you would need? I haven't had a chance to run it yet, but I will dig deeper tomorrow. That will be very useful. Cheers

This is getting better, good information. I've been quiet for all this time but I keep learning Action. I am currently writing a small game so I can learn more with a full application and be able to finish my tutorial series. Paulo

Oh, thanks! I did missed that! That's also interesting. Crazy how the Atari "scene" has so many options. I feel like it beats the ZX Spectrum and C= options out there in terms of options!

I am still slowly going through the list and I see a lot of mass storage devices (which is good!) but as far I could see only one option for video upgrade, the VBXE. Or I am missing something? The VBXE looks very cool, although I honestly don't care too much to make the A8 do more than it was capable to do back in the day (my personal preference, but I understand why some like that though! ) so the only thing there that attracts me is the ability to show better video for the regular atari screen and resolutions. Are there other options out there on that regard? The multicarts are also nice and I might go that route as well. I am already on the #Fujinet waiting list My plan now is to compile a list and add where to order it and if it is still available, things like that. Sites like lotharek makes that part easier for a lot of the options. Thanks!

Thanks for the great tips. I am checking them all! Also, glad to learn about the "Topic for Newbies" - Great source of information! Cheers

Hi all, I am doing a research (for my birthday but also for an article ) of modern hardware upgrades and peripherals I could buy for my Atari machines. I've found some around the Internet, but sometimes they are sold out batches, etc so it is hard to come up with things one could buy nowadays. I wonder if you all could mention what comes to your mind that is still current available for purchase and if possible the reference link (or person here on Atariage). Any help is greatly appreciated! Thanks

Hi all, I've posted on ViTNO, but copying here for Atariage readers' sake. A new version of Atari800MacX, the Atari XL/XE/5200 emulator for MacOS is available now. This new version contains an important internal change, replacing the deprecated OpenGL with Metal, which will ensure Atari800MacX will be ready for the future versions of MacOS. Besides replacing OpenGL, the Atari emulator also had hundreds of functions reviewed and any deprecated API was updated as well. Although the major changes happened under the hood, Atari800MacX 5.1.0 also includes UI enhancements, like bringing back the drag & drop of disks, rom, cassette and XEX files to the main program screen. Another small but welcome change was the addition of authentic Atari disk drive sounds when a new disk is inserted or removed from the drives! Here is the full release notes: New Features/Bug Fixes (in version 5.1.0): Added real sounds for opening and closing of disk drives when disks are inserted and removed from emulated Disk Drives. (A preference on the Atari tab of the Preferences pane controls this). Updated application to use Apple’s Metal API instead of OpenGL. MacOS has deprecated OpenGL, and this should help to future proof the program. Re-added Drag and Drop of disk, rom, cassette and XEX files to the main program screen. This feature was in 4.x versions, but had been removed in 5.x versions. Bugs Fixed: Fixed issues with keypresses still being issued along with joystick/trigger motions when using Keyboard joysticks. Fixed a keyboard issue when using a Ctrl+Shift combination, where the shift key state was stuck pressed after both keys were released. The shift will go back to unpressed only if another Ctrl key was pressed. Replaced deprecated MacOS API calls, to ease porting to future MacOS versions. Fixed issue with Disk Sector editor where after doing a Goto Disk sector, the up and down arrows used the old location. Download it here: https://github.com/atarimacosx/Atari800MacX/releases/tag/Release_5.1.0 Cheers

Excellent work. I just played for a few minutes and it looks so fresh. You've made a lot of right choices with the graphics! Congrats!

That's is nice. I think I will try for one year to see the benefits despite the language barrier. Looks like it is worth it based on this discussion!

Any chance we wil be able to play this game, since I don't have the magazine (nor I can read German)... THanks

Just a reminder that Atari800MacX got two updates this week and it is also working well on Catalina! Good to have options!

In the release tab, there is a ready-to-install DMG file of the new version as well. Cheers

Hi, ac.tomo I think I understand now. You are swapping the animation in two "pages". Is that so? Paulo

I have seen similar models, but the painting is superb! Very well done!

Well, I guess that is not a big deal since I can setup alternative ROMS elsewhere.

I've installed Wine devel using the brew command above and I can launch Altirra64. However, the wizard dialog that tries to open the file system dialog to select the ROM folder comes blank. Is anyone else seeing that? Thanks

Not sure if I understand what the pokes are doing. Can you explain please? Thanks

Interesting that makes it shorter indeed! Yesterday I was playing with the SCR pointer declaration and looking at the monitor. Now I can understand how it works. If I declare it as BYTE, I can increment by one since SCR is pointing to a 8-bit BYTE. If it is declared as a pointer to a CARD, then I need to assign a 16-bit value and increment by 2 to match the size of the data the pointer is pointing to. Thanks!

I've been using github for work and "hobby" for many years, so I am used to it. Out of curiosity, do you guys rely more on command line or some github GUI? What do you guys feel messy about it? Cheers

Great info! I think I am a bit far from be able to achieve that, but I am going to try something similar for the little ship in my sample. Cheers

Hey Alfred, I understand what you say, but when I tried incrementing the variable by two, the result in screen shows I am skipping one byte. When I go back to 1, it seem to work fine. Also, changing the declaration from CARD SCR to BYTE SCR doesn't make any visible difference (Please, see the attached video to demonstrate what I did). What do you think? Thanks! (if it is not working here, there is a copy at http://www.mediafire.com/file/tq7scjihxjd5ql8/action1.mov/file) action1.mov

Thanks Alfred. Both options worked like a charm. I like the PeekC option as it is very similar to BASIC, although I imagine dealing with pointers directly would be faster if in a loop for example. Cheers

Hi, I am trying now to write a simple GR7 sample to show Action! speed. For that I am reading the display list information to get the address of the graphics 7+16 mode. This is the program: PROC MAIN() CARD I CARD DL=560 CARD POINTER DLADDR CARD POINTER SCR GRAPHICS(7+16) DLADDR=DL DLADDR==+4 ;FIRST BYTE START GR7 SCR=DLADDR^ FOR I=1 TO 3840 DO SCR^=135 SCR==+1 OD FOR I=1 TO 33000 DO OD RETURN It does work as expected but I have to confess I don't understand why I had to set a variable DL=560 (addresses 560/561 which points to the start of the display list) and a DLADDR pointer and lastly, associate DL to DLADDR in order for the program to work. I've tried simple do something like DLADDR=560^ without using the variable DL. Action! compiler accepts it but the program crashes the computer. My (misled) understanding tells that DLADDR=560^ would give me the same result as DLADDR=DL^ since DL=560 (and it is not a pointer). What I am missing here? Thanks again!