Search the Community

The TNFS is working fine, but I would like to move files (not just whole disk images) around (upload and download) my Atari LAN and between the Altirra on my PC and other machines on the network. The following is my solution, but if there is a better way to transfer files across I'd be eager to hear it... As I previously described, I have my wife's old computer "defenestrated" to LINUX MINT. I created a DOS 2.5 disk image (TNFS_transfer.atr) and put it in my PC's /TNFS directory with full access (chmod 777 ...) and owner set to tnfs (chown ...). It attaches easily from host 8 as drive slot (disk) 2: To get files to move between TNFS and my LINUX/WINE Altirra installation I need to keep both a TNFS and an Altirra disk image, in my TNFS directory and my Altirra user's directory, respectively: I can then copy the most recent TNFS_transfer.atr between the Altirra and TNFS directories (adjusting permissions and ownership for each location) when I want to move files between the emulator and other machines on the network. Networked machines can just use the TNFS version without further intervention. I have also made some bash shell scripts to simplify the LINUX side of things. If anyone has a different way, I'd love to hear about it. Otherwise, thanks again for dropping by.

I recently "received" an old computer from my wife (a Dell 2-in-1 with Windows) which I have repurposed as my home Linux learning machine. I installed Linux Mint and decided to try to set up an Atari LAN in my home. Following the Wiki instructions (https://github.com/FujiNetWIFI/fujinet-firmware/wiki/Setting-up-a-TNFS-Server#setting-up-tnfs-on-raspberry-pi-or-linux) was a bit difficult because 1) I am new to Linux, and 2) it is definitely targeted to Raspberry-Pi installations. However, with a little cross-referencing with Atari Age entries and a lot of trial and error, I got it to work! A small victory. I've attached a pdf with my procedure, adapted from the Wiki entry, in case it helps anyone. I am new, so if you see anything that looks wrong please let me know. Otherwise - thanks for dropping by the blog! Setup TNFS.pdf

This thread aims to document the process of building fujinet-pc in a Linux environment. As usual, there will be many ways of accomplishing this, so comments, questions, and suggestions are welcome. There is an assumption being made that the person seeking to build fujinet-pc is comfortable with working in a Linux shell (commandline) environment. It's not necessary to be the best in the world at it by any means, but being familiar with package management tools, sudo, running shell scripts, etc. is necessary. It's also worth mentioning that the environment I'm primarily building this in is Raspberry Pi OS on a Raspberry Pi 3B. Depending on the architecture and Linux distribution in use, some parts of the process may be different to how it has been detailed below. If you run into any issues, by all means ask for assistance - just make sure to detail the Linux distribution in use, the architecture you're building under (x86, x64, ARM, etc.) and we'll help with figuring it out. MacOS is not covered by these instructions. With that said, open a terminal and start by making sure that three requirements are satisfied first: Python3 Python3 may already be installed on your system. To test if it is, type `python3 --version' at a shell prompt and hit Return. If you see output along the lines of 'Python 3.x.x', you're good to go. If not, check if it's available from your distribution's package manager (which it almost certainly will be). Platformio Unless you're doing python development, chances are that this one isn't installed. Check your package manager to see if it's available; if it is, go ahead and install it. If the package manager doesn't include it, see https://platformio.org/install/cli for information on how to obtain and install it. jinja2 Also not likely to have been installed unless doing Python development. It can be installed using either the system's package manager or pip. See https://pypi.org/project/Jinja2/ for details. git If git isn't installed, the system's package manager will again come to the rescue. For a quick check, type 'git --version' at a shell prompt; if you don't see a line similar to 'git version 2.39.3 (Apple Git-145)', this would be a good time to install it. Build tools such as g++, cmake, libraries, etc. will also need to be present. These are typically installed by default on most distributions, but not always. Pro-tip: missing packages can cause the build process to fail, so if a build error refers to something missing or not found, install the necessary packages (where appropriate) and try again. Having got that out of the way, it's time to set up a directory to build out of. From the terminal, issue the following command: mkdir ~/build && cd ~/build Next, clone the fujinet-firmware git repo and change directory into it: git clone https://github.com/FujiNetWIFI/fujinet-firmware && cd fujinet-firmware Running the 'build.sh' script in that directory will start the build process, but the target 8-bit platform needs to be specified first: For Atari: ./build.sh -p ATARI For Apple: ./build.sh -p APPLE The capital letters are intentional. There are no other target platforms at this time; simply choose the one that sounds more appealing if yours isn't covered. At this point, the build process should have started. Go grab a snack. If any errors occur, copy and paste them into this thread and we'll try to help you figure out what went wrong. Now that the software is built, we can move on to installing, configuring, and running it. There are a few housekeeping tasks that need to take place first. The first step is to create a user and group for fujinet to run as: sudo adduser --system --no-create-home --shell /sbin/nologin --group fujinet Next, the fujinet binary needs to be copied to a suitable location for it to run from. This example uses /usr/local/bin, but anywhere appropriate on your system can be used: sudo mv build/dist/fujinet /usr/local/bin Third, the support files used by the fujinet binary need to be put somewhere convenient. Again, /usr/local/etc is used for this but can be changed to suit: sudo mkdir /usr/local/etc/fujinet-pc && sudo cp -rp build/dist/* /usr/local/etc/fujinet-pc Moving on, ownership of the support file directory needs to be changed: chown -R fujinet: /usr/local/etc/fujinet-pc Edit the fnconfig.ini file to reflect the environment fujinet-pc is being run in: sudo <name of your favourite editor here> /usr/local/etc/fujinet-pc/fnconfig.ini fujinet-pc is now essentially installed and ready to go. To test it, issue the following command, changing pathnames as needed: /usr/local/bin/fujinet -c /usr/local/etc/fujinet-pc/fnconfig.ini -s /usr/local/etc/fujinet-pc/SD A bunch of text should go scrolling up the terminal window, and if you point a browser to http://<your IP address>:8000, you should see the fujinet-pc web interface. To return to the shell prompt, hit CTRL-C. If the test run was successful, congratulations! You now have a working fujinet-pc installation. But what if you want to start and stop it a bit more conveniently in the future? This is where creating a unit file comes in. Without going too far off into the weeds, if your machine uses systemd to control the starting and stopping of services, it uses unit files to manage those processes. There are other ways of doing this, but as most distributions currently use systemd, this is the one that we'll focus on here. The first order of business is to create a unit file. Again, adjust the pathname as needed to reflect your system: sudo touch /lib/systemd/system/fujinet-pc.service Open the file that was just created for editing, and copy and paste the following into it. Be sure to once again change pathnames as necessary before saving the file: [Unit] Description=Start fujinet-pc as a service After=syslog.target network-online.target remote-fs.target [Service] User=fujinet ExecStart=/usr/local/bin/fujinet -c /usr/local/etc/fujinet-pc/fnconfig.ini -s /usr/local/etc/fujinet-pc/SD WorkingDirectory=/usr/local/etc/fujinet-pc ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID PrivateTmp=true [Install] WantedBy=multi-user.target systemd needs to be made aware of the new unit file. Issue the following command: sudo systemd daemon-reload Now go ahead and try starting fujinet-pc: sudo systemctl start fujinet-pc If this returns you straight back to a shell prompt, that's expected. Now issue the following: sudo systemctl status fujinet-pc Check the output for a line similar to the following: Active: active (running) since Sat 2024-03-23 11:23:45 CDT; 6h ago That indicates that fujinet-pc is running, and should again be reachable through a browser at http://<your IP address>:8000 . To stop fujinet-pc, issue the following: sudo systemctl stop fujinet-pc If changes are made to fnconfig.ini while fujinet-pc is running, it can be restarted in order to pick up the changes: sudo systemctl restart fujinet-pc Note that the above commands will only allow fujinet-pc to run while you are logged in. To make it start at boot: sudo systemctl enable fujinet-pc And, predictably, if you don't want it to start at boot, the following will take care of that: sudo systemctl disable fujinet-pc Hopefully this has been useful to anyone looking to build fujinet-pc. Again, comments, questions, and suggestions are most welcome.

Inspired by the release of the lost prototype arcade game Akka Arrh coupled with the disappointment of seeing Minter's "extreme" version of it, I have decided that now might finally be the time to put MAME on my computer to play that game. But I immediately run into enough confusion that I feel I should ask for some guidance from experienced MAME users before proceeding. I'm using a computer that is running Ubuntu 22.04 along with an NVidia 1070 graphics card. Ok, the Ubuntu repositories show a version of MAME that I can install, but it's version 0.242 for all the related packages except for mame-extra which says it's version 0.206-1 and is described as additional files. Looking online at the ROMset file for Akka Arrh I see that there are two versions of it already, a first release "Mame 0.209 released on apr-24 2019" and a last release "Mame 0.260 released on oct-24 2003". From what little I have understood about MAME I've read that you should get the same ROM set version as the MAME version you are running. I also see here in this subforum that new versions of MAME are released pretty frequently. I assume that most of the changes affect newer consoles and obscure games, that most of the classic arcade games are pretty stable? Maybe not, if MAME itself is improved. I'm not in the mood to download and compile the latest/greatest MAME since there will always be an even newer one to deal with. I assume that when there is a new version of MAME for Ubuntu 22.04 that it will show an update. So my questions boil down to these - 1 ) Assuming that 0.242 is pretty recent and solid, which ROM set for Akka Arrh would be better to run, the 0.209 version or the 0.260 version? 2 ) For the other classic '70s/'80s games that I'd want to play (Tempest, Missile Command, Moon Cresta, Space Firebird, etc.) which ROM set versions would be the best to grab, versions specifically for 0.242 or is there a range of older/newer that would still work since I doubt all the games would hit that exact version number or that all the ROM sets are rereleased to match each MAME version? 3 ) Should I be setting up subdirectories for ROM sets based on MAME version? Like, for Akka Arrh with its 2 versions, should I grab both ROM sets and store them separately, one in a directory with the other older ROM sets and the other with the newer ROM sets? Or is that a redundant waste of time? 4 ) For the classic arcade games is it better to grab merged ROM sets or split ROM sets? 5 ) If I'm interested in playing the different versions of a specific game, for example I believe Tempest had 3 versions made back in the day, is that something a merged ROM set would automatically include or would I need to track down each version separately? 6 ) I remember years ago ('90s) when I tried this before that some games would also include images of arcade game surround art (if the game had such a thing) and if it was downloaded and stored in the correct subdirectory that when the game was played it would be shown inside that border artwork (more arcade-ish experience). Is that still a thing, meaning that I would need to track down separate .png files or is that stuff packaged together with the ROM sets now? 7 ) Is it ok to assume that the version of MAME in the repository has all the BIOS and device ROM sets required for playing old arcade games? Meaning I'm just missing game ROM sets? 8 ) What would be the preferred UI frontend for MAME these days? I'm using KDE with Ubuntu but I assume there are many frontends for MAME by now. Sorry for all the questions but I remember getting frustrated the last time I really tried this seriously. Of course back then MAME had a lot of issues that are probably long solved so maybe now is the right time to deal with setting it up again. I plan on getting all the correct controllers (I assume USB versions) so that I'm not playing using my computer keyboard or a joystick for everything. If there are any standards (Ultimarc?) or common mistakes in that area I'd appreciate advice there, too.

Trying to create empty ATR files I noted the the provided tools only work on MS-Windows. Since creating an empty file isn't all that difficult I wrote wrote a little tool that can do this macOS and Linux. I also added a verify feature to check existing files for consistency. The tool works for Windows as well. I suggest to compile the file from source code as it is fairly simple will match your operating system so here a description on how to do this: Microsoft Windows Install Alire Download Alire from the Alire website: Start installation and just accept the defaults: Build the application Start the application by clicking on the icon. This will open the Alire powershell terminal window: Use cd to change into an directory of your choosing and type the following commands one at a time. Note the the directory name contains the version number and and hash code of current version and will change with each new release. alr toolchain --install "gnat" alr toolchain --install "gprbuild" alr get "atari_atr_tools" PUSHD "atari_atr_tools_1.1.3_1e2cccbb" alr build --release POPD During the build Alire ask up to 4 questions which should be answered with either Y or 1 depending on the type of question. This will build the tool for your machine. Run the Application The finished application inside the .\atari_atr_tools_1.1.3_1e2cccbb\bin\atr_tools-main.exe directory. Again: adjust for newer Versions. The --help option will show you available options. Apple macOS Install Alire Download Alire from the Alire website: The Alire distribution for macOS is just an executable inside a zip file. You can extract the zip to any location you like and add the executable flag to the alr binary. Build the application Start Terminal and change into an directory of your choosing and type the following commands one at a time. Note the directory name contains the version number and hash code of current version and will change with each new release. bin/alr toolchain --install "gnat" bin/alr toolchain --install "gprbuild" bin/alr get "atari_atr_tools" pushd "atari_atr_tools_1.1.3_1e2cccbb" ../bin/alr build --release popd During the build Alire ask up to 4 questions which should be answered with either Y or 1 depending on the type of question. This will build the tool for your machine. Run the Application The finished application is found at ./atari_atr_tools_1.1.3_1e2cccbb/bin/atr_tools-main. Again: adjust for newer Versions. The --help option will show you available options. SuSE Linux Install Alire Download Alire from the Alire website: The Alire distribution for macOS is just an executable inside a zip file. You can extract the zip to any location you like and add the executable flag to the alr binary. Build the application Start Terminal and change into an directory of your choosing and type the following commands one at a time. Note the directory name contains the version number and hash code of current version and will change with each new release. bin/alr toolchain --install "gnat_native>=12" bin/alr toolchain --install "gprbuild>=22" bin/alr get "atari_atr_tools" pushd "atari_atr_tools_1.1.3_1e2cccbb" ../bin/alr build --release popd During the build Alire ask up to 4 questions which should be answered with either Y or 1 depending on the type of question. This will build the tool for your machine. Run the Application The finished application is found at ./atari_atr_tools_1.1.3_1e2cccbb/bin/atr_tools-main. Again: adjust for newer Versions. The --help option will show you available options.

As there is no full direct Linux support in Altirra nor WUDSN, i did wrote a simple wrapper script that simplifies full ALTIRRA-WUDSN integration under linux. Requirements: wine Howto: Copy the attache script to your Altirra64.exe location. Open WUDSN ide, go to: Window->Preferences->Languages->Assembler->Atari 8-bit Assembler->Altirra TAB Enter path to the wrapper script instead of altirra64.exe. (see attached picture) Enjoy Your new Linux Dev Setup. AltirraLinuxWrapper.sh

Mad Pascal has a "feature" that "normalizes" path. This is not an issue under Windows, but has unexplainable behaviour under linux. I have developed a simple path, to fix that issue. Path is available on MP github. https://github.com/tebe6502/Mad-Pascal/issues/113 With that path, most mp examples compiles without issues, except fx. Mad Pac. In Mad Pac, one resource file use Capital Letters in filename. So ... I was too busy to patch this too. Instead i've renamed the file, and all references in source files. Keeping all filenames as small letters works. SO the patch is not so important. Enjoy.

No, it's not a question, it is a tutorial Promised myself to do something Atari-useful this weekend, my experimental PCBs are still in the mail, so here it goes. My quest was to figure out the possible ways of creating and using VHD files on Linux to be used with Altirra, more specifically the SIDE3 device emulation. Now, you will say that one can create VHD files from within Altirra and Bob is your uncle. This, however, creates a totally empty drive, and unless it is not to be used entirely for APT partitions and formatted from the Atari/SDX level, you are still in trouble in the Linux land, as it is possible to mount VHD files (even for R/W operations, see below), but for editing partitions or formatting them there is still no easy way of doing it on Linux (and frankly I actually did not find any way for this particular thing). All this information is not new or anything, it is all out there, but sometimes you need to do 2+2, and also, some tutorials on this are totally wrong. In any case, below my notes on how to go about doing all this and having relatively full control over the VHD files and their contents from Linux. One step in this, unfortunately, requires having VirtualBox tools installed (no need to have any Windows virtual machines though). I do this on Ubuntu 20.04, your mileage may vary, and even on Ubuntu you can go alternative routes at some points. You may also need to have some packages installed on Linux that I already have (I had tons of crap accumulated over time). There are four steps to get there: Create and initialize an empty drive image with suitable partitions Pre-populate the image with files Convert that to an VHD file Mount the VHD file on Linux to extract from or add new files to the virtual drive Preemptive warning - make sure you do not have the same VHD file mounted / used by multiple ends, like Linux / VirtualBox / Altirra, this may end up in a total disaster. I am also very modest with any deeper explanations, I hope that if you are in the Linux land you do have some clue of what you are doing and what these things are. 1. Create an empty drive image and setup a FAT partition dd if=/dev/zero of=sd.img bs=1M count=32 (adjust the count parameter to the desired size, this one is for 32MB) fdisk sd.img Inside fdisk, do "o" to write a DOS label, "n" to create a new partition, choose (p)rimary, hit Enter through other questions to get the defaults. Then say "t" to change type, choose "c" for FAT, and finally say "w" to write the partition. sudo losetup -Pf --show sd.img This will print you the loop device identifier that was linked to your image file, let's say it is /dev/loop5 (almost certainly it will be different for everyone, and it cab be different each time you do it). You can also use "lsblk" to see your loop device with the partition you created listed. Now you can format the partition with: sudo mkfs -t vfat /dev/loop5p1 At this point you can go two different routes to put some initial files on it, one is the "old-school" using mount, one is using Ubuntu / modern facilities. 2a. Pre-populate the image with files, old-school way Keep the loop device linked, and then: sudo mount -t vfat -o loop /dev/loop5p1 /mnt With super user privileges (sudo bash for example) you can now copy your files to /mnt. When done, unmount all this and unlink the loop device: sudo umount /mnt sudo losetup -d /dev/loop5 Go to point 3. below 2b. Pre-populate the image with files, udisksctl / Ubuntu way First, unlink the loop device you created in step 1. if it is still linked. sudo losetup -d /dev/loop5 Then: udisksctl loop-setup --file sd.img This will also print the loop device identifier assigned to your sd.img file, but here this is probably irrelevant. Instead, the Ubuntu file mounter should kick in, mount this for you and offer to open a file browser, use the file manager tools you are familiar with to copy the files over. (This should be the same behavior and procedures you get when inserting a USB Flash drive). When you are done you can simply unmount / eject the drive through the OS GUI. Alternatively, if for whatever reason the automatic mounting did not work, you can do things by hand: udisksctl mount -b /dev/loop5p1 Similar to the automatic way, this will mount it at /media/<your user>/<disk label>. When done copying your files over, do: udisksctl umount -b /dev/loop5p1 udisksctl loop-delete -b /dev/loop5 3. Create the actual VHD file that you can use with Altirra For this step you need to have the Oracle VirtualBox tools, installing VirtualBox is outside of scope of this instruction. VBoxManage convertfromraw sd.img image.vhd --format VHD This will create a expandable VHD, if you want to have the fixed size one (it will be as large as the sd.img file you created), you can add "--variant Fixed" at the end of the last call. At this point you can use image.vhd with Altirra, and it is now safe to delete sd.img (unless you want to keep it for whatever reason). 4. Mount the VHD file to later add more files from Linux, or copy files you created on Atari back to Linux Do not do this when Altirra is running and has the VHD file in use! For this you need guestfs things, install them with (for me it pulled in quite some dependencies): sudo apt-get install libguestfs-tools Then you need to figure out the device identifier for the partition inside the VHD, though I am convinced it is /dev/sda1 in 99.9% of cases, the proper way to do this is: sudo guestfish --ro -a image.vhd Inside guestfish say: run list-filesystems exit The second command will give you the device name for the FAT partition inside, you then use it with this command: sudo guestmount -a image.vhd -m /dev/sda1 --rw /mnt (/dev/sda1 is what you get from list-filesystems above). Now you can copy things to and from /mnt, but you do need to be in the superuser mode for this. When done, unmount (again, do not forget this before starting Altirra again!): sudo guestunmount /mnt And that is pretty much it. For the last point you can also use a Windows virtual machine if you have one running under VirtualBox, and mount image.vhd there to copy files with your virtual Windows, but I leave that exercise for the curious.

Hello, All! I've published ColEm 4.4, the ColecoVision emulator for Windows and Linux, as well as the source code for porting ColEm to other platforms: http://fms.komkon.org/ColEm/-- homepage http://fms.komkon.org/ColEm/ColEm44-Windows-bin.zip-- free Windows version http://fms.komkon.org/ColEm/ColEm44-Ubuntu-x86-bin.tgz -- free Linux version http://fms.komkon.org/ColEm/ColEm44-Source.zip -- sources This release adds support for more modern MegaCart cartridges, such as Buckrogers, Subroc, Zaxxon, and Dragon's Lair. The SGM emulation state is now saved to .STA files. I have also added support for 24c08 and 24c256 EEPROM chips, so both Black Onyx and Boxxle fully work now, saving EEPROM contents to .SAV files. ColEm will determine the need for EEPROM automatically, by ROM's CRC, or you can force EEPROM emulation with -24c08 and -24c256 options in Linux. The Windows version offers menu items for switching EEPROM type, as well as links to AtariAge ColecoVision forum, Coleco software publishers, and other sites. Finally, I have fixed a bug restoring background screen color from .STA files. See below for all the changes. ALL CHANGES: * Added ROM page switch specific for carts with EEPROM. * Added 24c08 EEPROM support (Black Onyx saves now). * Added 24c256 EEPROM support (Boxxle works). * Now saving EEPROM state into .SAV files. * Now saving SGM state into .STA files. * Now accepting both AA55h and 55AAh MegaCarts. * SGM games Buckrogers, Subroc, Zaxxon, Dragon's Lair work. * Fixed restoring background screen color from .STA files. * Added EEPROM menu selections to ColEm-Windows. * Added links to CV Addict and AtariAge forums to ColEm-Windows. * Added -24c08, -24c256, and -noeeprom command line options. * Compiled ColEm-Unix with -Wall and eliminated warnings. * Replaced -DNO_WAVE_INTERPOLATION with -DWAVE_INTERPOLATION, off by default. * Removed old LoadSTA() and SaveSTA() code. * Finally deprecated -DNEW_STATES. Have fun! PS: I will use this thread to post ColEm release news and answer questions about ColEm. If you have a question or suggestion, please, feel free to ask it here.

Well hello my fellow Atarians. If you're like me you still use the old Atari (either real thing or emulated), but you also use a modern computer like a Windows PC, Linux PC, or Mac. In that case you probably have cause to use text files from one system on the other and visa versa. As some of you know, I developed a program for the A8 to do converting called AAC. You can get info on that over in it's own topic. This new topic is about a different program with the same name that does the same job, but runs natively on the new machines. It is written in Python so has the ability to be cross platform. So here is AAC v0.1, 32-bit Windows, for your testing pleasure. It works fine as expected in every case I have tested so far, but I like to get feedback from others too. Once any bugs (if any) are ironed out. It will get it's v1.0 release. If you need a Linux version to test let me know.

I've been slowly migrating to linux over the past couple of months as an experiment to see how well this will work for me. I inherited a first generation Microsoft Surface Book from work when I upgraded my office computer, and since I did not need yet another Windows machine, I decided to install Linux Mint on it. I did lose the tablet and pen functionality of the laptop in the process, by I was never a fan of tablets to start with so no big deal there. I have to say that so far I've been able to easily do 95% of my work on it, both hobby and professional, with the exception of VPN access to the university resources and remote Citrix hospital access which I am still looking into. DosBox and Steam round up my gaming needs. Kerbal Space Program and Microsoft Space Simulator on linux: who knew??? The best surprise was the fact that all my usual TI development tools work under linux using Wine, including Classic 99, albeit the latter is a tad slower than under Windows. As a matter of fact, everything I have thrown at Wine has worked so far, such as TI99Dir, TICodEd, Winasm994a and Convert9918, thus recreating my entire development tool chain. Magellan works perfectly as well since it's Java based and Visual Studio Code is available for linux. I will however start leaning more on MAME since it is native to linux and emulation execution speed is thus not affected here, at least for real-time testing of projects. So for the past several weeks I've migrated the ongoing development of Kroll & Prumni to the linux machine and so far no issues. I am in real danger of not going back to Windows...

I have ran into this problem a few times running VJ in Linux, specifically Kubuntu 18.04 and later over the last few years, where the image of the game being played doesn't fill the window size or fullscreen properly. I have found a solution modifying the source for VJ, but I wanted to ask if there might be a simpler way of altering the code to achieve the same fix. I also wanted to make this post with the solution I have been using in case anyone else out there might be running into the same problem, and there isn't a better way to do this currently. Below is an image of what I am experiencing when opening VJ, and it holds true when playing a game windowed or in full screen. I am using version 2.1.3(final) source from the git repository. Here is a solution I am currently using to fix this. Before building Virtual Jaguar perform the following modifications to the source code: /src/gui/mainwin.cpp - Add the following line in the function MainWin::SetFullScreen, below the line where int newWidth is initialized. The line looks like this "int newWidth = (int)(aspectRatio * (double)r.height());". newWidth *= 2.2; Then alter the line just below, that looks like this "videoWidget->offset = (r.width() - newWidth) / 2;", multiplying r.width() by 2.2. It should now look like the line below. videoWidget->offset = ((r.width() * 2.2) - newWidth) / 2; /src/gui/glwidget.cpp - Now we need to multiply width() and hieght() function calls by 2.2, do this by altering the following lines. outputWidth = width(); --> changes to --> outputWidth = width() * 2.2; unsigned outputHeight = height(); --> changes to --> unsigned outputHeight = height() * 2.2; EDIT: I forgot to mention that the value 2.2 is a bit arbitrary according the the global scaling on your desktop. I actually don't know how to find the exact value you need according to a specific global desktop scaling. But raising and lowering the value should get what you are looking for. For example, 2.2 is scales the image a bit beyond the window and fullscreen borders, so I dropped it down to 1.75, and if fits great now.

For this thread, LINUX games - natively installed, or installed via a service. One of the key points about the new VCS over a normal console is that you can run other platforms on it, via PC-mode. e.g. Ubuntu Linux, Fedora Linux, SteamOS, GamerOS. (Even AtariOS installed to another disk). The most popular games service is probably Steam, but I shop around for Indie games. As SteamOS is only an older version of Ubuntu, it can be problematic, due to out-of-date drivers etc.. The VCS chip is far newer than the last release of SteamOS. IMHO it is better to use Ubuntu directly, and install Steam client as normal. I use an external USB 3.1 SSD. Some gamers just prefer to use a keyboard and mouse, and the machine has 2 USB ports under the front edge. In PC mode any USB device should work, as it supports USB 3.1, and so this opens up a lot of interesting options. The first demonstration is linked here. This is not my video. I myself also have Ubuntu Linux running on my VCS, as a dual-boot. He also posted a follow-up.

I have the scripts I wrote to select a few options from a menu, but it's all command-line. I've never developed for X11 before, so I thought I'd ask if any such thing exists already before I go reinventing the wheel.

Recently I acquired an old Bondi Blue iMac G3 with a PowerPC @266Mhz and 64MB RAM. I upgraded the RAM to 128MB and installed Debian GNU/Linux on it. Runs like a charm. I intend to use it remotely to test big-endian compilations, so I wanted the built-in monitor to be turned off. After searching the net extensively, I was unable to find a solution. setterm -blank 1 does not work (no APM support on a G3), xdpms doesn't work either (no DPMS) and pmset is only available under Mac OS X. I did find a solution though. If you configure Xorg wrongly and select a resolution the monitor can't cope with, it turns itself off. I'd rather not have X installed, but well, a dark server closet is worth the extra few megabytes of disk space And if I need the console because I locked myself out remotely or something, CTRL-ALT-F1 brings back the framebuffer console and turns on the monitor again.

I have not done any development in Linux for Atari and I'm wanting to write some programs (games or utilities) and I'm wondering if anyone has ever set up a virtual machine via Virtual Box or VM Player? I don't want to duplicate effort if it's already been done, Why a virtual machine? I have multiple computers running multiple OS's and I want to be able to develop on whatever machine I'm currently in front of. I also want this pre-configured environment to be freely distributed, which is why I will not be using Windows. (I may use Mint so that it will look like Windows for those who have not used Linux before.) Constructive ideas and suggestions appreciated.

So another thread got me thinking about drivers and their important role in keeping retro hardware useful in the current age (and how a lot of manufacturers drop the ball pretty early and leave some really great peripherals without support). Then I started searching around and found this stuff (I'm sure there's a lot more out there): http://read.pudn.com/downloads151/ebook/655187/Windriver.pdf https://bootlin.com/doc/books/ldd3.pdf

Sorry in advanced; I'm really-really new to gcc and c in general (a complete moron). SO I couldn't find atari800 rpm for Fedora 2x (at least not a 3.x version). atari800 3.x has some features not found in 2.x. I tried using alien to convert .deb's but no luck (never had much luck with alien), and even tried non-fedora RPMs. No luck there either (of course). Downloaded the tar.gz source atari800-3.1.0 - ./configure went ok, but when doing make install: xep80.o: In function `XEP80_Initialise': xep80.c:(.text+0x1479): undefined reference to `ANTIC_cur_screen_pos' xep80.c:(.text+0x148d): undefined reference to `ANTIC_cpu2antic_ptr' xep80.o: In function `XEP80_GetBit': xep80.c:(.text+0x15a2): undefined reference to `ANTIC_cur_screen_pos' xep80.c:(.text+0x15b6): undefined reference to `ANTIC_cpu2antic_ptr' xep80.o: In function `XEP80_PutBit': xep80.c:(.text+0x1673): undefined reference to `ANTIC_cur_screen_pos' xep80.c:(.text+0x168c): undefined reference to `ANTIC_cpu2antic_ptr' xep80.c:(.text+0x1715): undefined reference to `ANTIC_cpu2antic_ptr' xep80.o: In function `XEP80_StateSave': xep80.c:(.text+0x2515): undefined reference to `ANTIC_cur_screen_pos' xep80.c:(.text+0x2529): undefined reference to `ANTIC_cpu2antic_ptr' xep80.o: In function `XEP80_StateRead': xep80.c:(.text+0x2817): undefined reference to `ANTIC_cur_screen_pos' xep80.c:(.text+0x282b): undefined reference to `ANTIC_cpu2antic_ptr' collect2: error: ld returned 1 exit status make: *** [Makefile:119: atari800] Error 1 I'm guessing that's makefile line 119? which is $(CC) -o $@ $(LDFLAGS) $(OBJS) $(LIBS) dep: @if ! makedepend -Y $(DEFS) -I. ${OBJS:.o=.c} 2>/dev/null; \ then echo warning: makedepend failed; fi please take it easy on me :-( appreciate any input

Does anybody else here collect IndieBox? For those that don't know, they publish custom made boxed versions that are packed full of little goodies like color manuals, soundtracks, stickers, physical versions of the game, plushies, action figures and more. Every game is also 70% or higher on Metacritic and runs on Windows, OS X & Linux. Pretty impressive stuff! This is my list of their Top 10 releases. * This was not a paid sponsored video and the opinions are my own, if curious.

It's been a while since posting, but I found some time to (re-)start the daunting task of archiving my fl[oi]ppy collection. As I am in possession of both a Raspberry Pi (raspi) and SIO2PC hardware, I thought about putting both to good use. Archiving my floppy collection is something I think of as good use. I wrote about my setup here before, so I will leave the details of installing the raspi and sio2bsd toolkit out of this post, if you need help with either, check my other posts, or send a PM. For the Atari side of things, I start with booting the recommended 'Copymate XE 3.7'. I have two 1050's connected to my Atari (D1 and D2), so after booting the copymate application from the raspi, I kill the sio2bsd application and run the diskarchive.sh script I wrote for the archiving job. The script is a quick hack to speed up the job a bit of manually starting sio2bsd all the time. In the script, there are three variables that need to be adapted to your own setup: BLANCO=( "/var/www/html/disks/Blank_MD130k.atr" "/var/www/html/disks/Blank_SD90k.atr" "/var/www/html/disks/Blank_DD180k.atr" ) DISKDIR="/var/www/html/disks/_personal/" SIOPARM="-s /dev/ttyUSB0 - - - ${DISKDIR}" The BLANCO array contains a list of blank disks that I created that are copied to a new location with the name you enter for your disk. Note that the order of the image locations matter, as they are used later in the script if you need to switch to another density for the destination disk. I default to the 130k image when using the script. String DISKDIR tells where to store the archive of images you're about to create. In this direcory, for each image you will create, there will be three files: .atr (the actual image), .nfo (the one line descriptive text you entered, more about that later) and .log (the output of the sio2bsd tool during the creation of the image). The other string SIOPARM has the parameters for the sio2bsd program used. Remember, if you use a level converter to the GPIO ports of your raspi, you need to change ttyUSB0 to ttyAMA0. In the above example settings, the image drive will be D4. Copymate XE When the application starts, it display usage information, but after you press a key on that screen, the program guides itself on the main screen. Tip: If you haven't started the script and/or turned on your drives, do that first (and make sure the script is actualy running sio2bsd (enter disk name and description)) then press the RESET button on the Atari so the program will redetect(?) the active drives. diskarchive.sh I think the script is self explanatory to me that is, but then again, I wrote it. It asks for some info before starting the sio2bsd program, but remember, it will kill all running instances of sio2bsd! So when you run the script, it prompts for the 'Disk Name', the filename that will be stored (threefold) in the archive directory. Stick to letters and numbers, no spaces and you'll be fine. Up next is the 'One line description for the disk', where you can enter some text describing the content of the disk. Don't make it too complex but the input is less restrictive than the Disk Name. Now the script will spin up sio2bsd on D4 so copymate can write to it. Make sure the Source and Destination drives on the Atari are correct and press START to start archiving your first disk. If for some reason, your source floppy is not in the enhanced density format but is single density, press the s key and the script will restart sio2bsd with a blank SD image, if that is what the second item in the BLANCO array is. Once the copy is completed, press any key (but the 'e', 's' and 'd' keys) to continue to the next disk. If you're done archiving for the day, enter 'q' as disk name, to quit the script. You'll find the script attached to this post. Copy it to a location you prefer (your home directory on the raspi ?) and run it as root (sudo ~/diskarchive.sh). NOTE: I haven't bothered to remove the message './diskarchive.sh: line 3: 2201 Killed sio2bsd ${SIOPARM}${DISK}.atr 2>&1 > ${DISKDIR}${DISK}.log' you'll see when switching disks. If it really is a concern, let me know. diskarchive.zip

Hello, I've recently been learning Atari 2600 programming and I was reading some tutorials and it kept on saying that I needed DASM. I tried to download it and it is a Windows/Mac File only (I'm on Linux Mint 17.3). Any one know of a way around this? Thanks

Hi guys. For anyone using SIO2Linux, I wrote a menu system using python and ncurses that should make selecting files for SIO2LINUX a lot easier. Here is a link to the menuing system: https://drive.google.com/file/d/0B5fxz9VjCX_CdWM5aWV5UUxobVk/view?usp=sharing You can find SIO2Linux here: http://www.crowcastle.net/preston/atari/ Here is the usage: usage: atrmenu.py [-h] [-d DIRECTORY] [-s SERIAL] [-i SIO2LINUX] Atari Menu optional arguments: -h, --help show this help message and exit -d DIRECTORY, --directory DIRECTORY Directory where your .atr files reside (default is current working directory -s SERIAL, --serial SERIAL Directory where your .atr files reside (default is /dev/ttyS0 -i SIO2LINUX, --sio2linux SIO2LINUX directory where sio2linux resides (default is current working directory.) Screenshot:

Hi All! You are my last hope here. I try to compile a small test program using the CLEAN_START macro from macro.h (v1.06) but it gives me unresolved symbole for CLEAR_STACK in it. I'm using the latest x86-64 release of DASM 2.20.11 from the WUDSN pack. Which BTW seems to bee the latest stable release. (Yeah I know, but I use Eclipse for everything...except for linux. Linux is always problematic.) If I take out the CLEAN_START macro it's working fine. Directly copy&paste it also not works, took out the '.' so it uses global label and now it complains about CLEAN_START itself. I'm using these things for about 6 years now on Windows and I'm programming 8-bit assembly since '91 - but I can overlook anything ofcourse. Please help! I feel very lost now. Tell me if you need more information.