pedgarcia

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!

Thanks Rybags! I will give it a try Cheers

What is the theory behind soft sprites ? I would guess: 1 - save area where sprite will be placed 2 - Place sprite ORd with background When it moves: 3 - restore saved background done in #1 4 - Repeat Am I in the right track? Thanks

That makes totally sense. My intention was to illustrate the basic graphic capabilities, but maybe I should try something else instead. Or simplify it to the point where it makes sense to someone that knows nothing (almost like me:) ) Thanks again for all the input!

To answer the questions about the two functions. At first I was using the plot one calling twice, one with color 0, but then the results were not good, so I created the eraseShip plotting over the trail the ship would leave behind (therefore 5 points instead of 6). Again, this are just experiences and not suitable for a game, for example Based on all the comments, looks like the OS plot routines are very slow and it would be hard to get better results while using them. Is it possible using fast plot functions to plot everything in one single frame? Is the do until vcount&128 od making any difference there at all, or just make it run slower? Thanks again

Hi all, I've been playing with Action! and created this small program where a little ship travels from left to right on screen. The ship is made of 3x5 pixels with the following shape: X X XX X X And this is the program: byte WAIT_SYNC=$D40A, VCOUNT=$D40B proc plotShip(byte x,y,c) color=c plot(x+1,y) plot(x+1,y+1) plot(x+2,y) plot(x+1,y-1) plot(x,y-2) plot(x,y+2) return proc eraseShip(byte x,y,c) color=c plot(x-1,y-2) plot(x,y-1) plot(x-1,y+2) plot(x,y+1) plot(x,y) return proc main() card i,r,J graphics(7+16) setcolor(4,0,0) ;black background setcolor(0,4,8) ;pink setcolor(1,7,8) ;lt.blue for i=2 to 150 do plotShip(i,40,1) ;DRAW do until vcount&128 od eraseShip(i,40,0) ;ERASE od ; pause for i=0 to 32767 do od return What I noticed is that if I remove the line waiting for VCOUNT in the main loop, the ship travels with the correct shape but flickering a lot. I was expecting the flickering because I am drawing and erasing the ship in the same loop even considering my erase function is intended to erase the trace the ship would "leave" behind. Then I thought I would add the VCOUNT loop to wait for the vertical line would reach the end of the screen to then erase the ship. My assumption was that I'd draw in one frame, and erase in the other, and that would make the animation smoother. (As I write this I feel I am wrong ) . Anyways, what I see on screen is indeed less flickering but the animation is more "jittery" and leaving a small trace, as if the ship is twice as wide. What I am missing here? Is there a better way to do something similar (without using PMG) as my idea is to illustrate the basic built-in graphic functions in action. Thanks

After a hiatus due to moving to a new house and all what is happening, I am back with this project. I am currently writing an article showing the graphic functions using GR7 and came up with a very simple program is BASIC and the equivalent in Action! This is the Action! one: proc init() CARD I GRAPHICS(7+16) SETCOLOR(0,4,8) ;REM USE COLOR 1 (PINK) SETCOLOR(1,7,4) ;REM USE COLOR 2 (BLUE) SETCOLOR(2,0,14) ;REM USE COLOR 3 (WHITE) SETCOLOR(4,7,8) ;REM BCKGROUND (LIGHT BLUE) COLOR=1 PLOT(10,10) DRAWTO(149,10) COLOR=2 DRAWTO(10,85) COLOR(3) DRAWTO(149,85) FOR I=1 TO 60000 DO ; nothing inside this loop! OD GRAPHICS(0) RETURN Comparing with BASIC, you almost don't see any difference in the graphics plotting speed, which I am assuming is because the standard Action functions are calling the same built-in routines BASIC calls. Is that correct? Also, I see in the AtariWiki some fast graphics routine for GR8 and 15. Are you guys aware of something for GR7 ? THanks

Internet Archive also has them available to view online or the full PDFs. https://archive.org/details/newatariuserpage6 Cheers

You are right, @damosan. I am finishing the 3rd article, so I have a buffer and will start posting them probably this weekend.