Piotr D. Kaczorowski

I've checked 3 images... staring from two standard atrs from LiteDOS dist. archive and 3rd was SDX.. Same results.

@pcrow, Alright. Everything is going great, and we can probably refine and add new systems. The only drawback right now is that it simply doesn't work for me - Input/Output Error 5. So, we need to determine the next steps. Do you have any ideas, or should I try to set up a tunnel and expose the host so you can check it, or should I add debugging in my free time and see what's going on?

Electronics is my focus.

Sure.. But A8Pico is based on RP2040 Pico purple clone. Is there any chance to port UltimateCart on such platform ?

@electrotrains, How much does the hardware handling differ between UnoCart and UltimateCart? Could UltimateCart be made based on Pico?

A bit off-topic, but I've noticed that UltimateCart has returned to the market. https://www.ebay.com/itm/115911490326

I know this is probably not what you'd like to hear, but as you know, many of us simply have a second Atari in either PAL or NTSC version. It might be hard to expect demos to account for the 50/60Hz versions as well as NTSC Artifacting (probably in two versions) and PAL Blending. There's a clear reluctance even at the stage of porting PAL games for NTSC systems.

A small request that will enable debugging under different systems with different versions of libraries. It shouldn't be too complicated and probably won't take much time, but it can help many times. Please consider to add a "--dummy" option, e.g. "atrfs --dummy /mnt/atrdisk"? The goal is to test-install a virtual ATR, which will return a short list of files, or for files, it will return the content "hello world", allow copying a file to the virtual disk - but only this will create a file that will contain "hello world". Such a thing will make it easier to add DEBUG and determine incompatibility with a given system or fuse library. In the future, the fs layer could be divided into two layers. The lower one would simply work generically, and the higher one, interfacing with the FS library, would have all the options/pragmas related to a specific version of fuse or another library that would allow the implementation of a virtual FS. I know that, unfortunately, this would require a thorough rewrite, as it's a change at the design level.

A use case consistent for many years with Unix systems: mount_atr montezuma.atr /mnt/atrdisk1 So, mount_atr corresponds to atrfs, but in principle, you shouldn't add --name. Personally, I would replace name with "--src", although this would mean that when creating disks it should be "--dst". However, if a token in the arguments has the ".atr" extension, it should be treated as "--name=....atr". All in all, it's just a cosmetic touch at the end, once other more important issues are resolved.

I had something like that in the Atari set when I bought it again in 2020 after many years. You can safely throw it away. The image quality is terrible.

@pcrow I've checked the sources. I'll likely add more DEBUGs to the code either tomorrow or on Friday to identify the issue.

atrfs -f -s --atrdebug --name=a.atr atr1 > log.txt 2>&1 $ ls DOS XE 1.0.atr atrfs.prev LiteDOS manual.pdf b.atr LiteDOS-SE (build 2022-02-07).atr c.atr TBasic UBasic (No DOS).atr log a.atr log.txt atr1 test.sh atrfs [eightcore: ~/Downloads/LiteDOS-SE] $ cd atr1 -bash: cd: atr1: Input/output error log.txt

I have an older Mac running OS X El Capitan (OSX 10.11.6) Here is comment in fuse.h * IMPORTANT: you should define FUSE_USE_VERSION before including this * header. To use the newest API define it to 26 (recommended for any * new application), to use the old API define it to 21 (default) 22 * or 25, to use the even older 1.X API define it to 11. I tried to compile using both 25 and 26, which correspond to the old and new API versions. In both instances, the compilation was successful. However, I did have to modify 'atrfsc.c', changing 30 to 26. #if (FUSE_USE_VERSION >= 26) , NULL #endif ---- I almost succeeded in mounting the atr file to the filesystem: $ mount .. .. .. .. atrfs@osxfuse0 on /Users/piotr/Downloads/LiteDOS-SE/atr1 (osxfuse, nodev, nosuid, synchronous, mounted by piotr) As you can see, I'm using FUSE version 3.10.4 for OSX (FUSE for macOS 3.10.4). Unfortunately, the mounted directory isn't functioning. I receive an 'Input/Output Error (5)' when I attempt to access it. Do you have any suggestions on how to resolve this issue?

Awesome! I will speak with Mr. Atari, and we will conduct tests.

During the second half of the week, I will test it and report directly to @drac030 if needed.

Check out this: https://dfi-america.com/estore/pcsf51.html and https://www.dfi.com/Uploads/DownloadCenter/fbc72ed8-5a84-49c4-b45d-0dd4e4f1f99d/DFI-PCSF51-1.8-SBC-DataSheet.pdf PCSF51-BN-86R254 - has R2514

Well, actually... I would try the R2514 instead of the R1606G... It seems like it's just the next generation. The same pinout. However, there might be a need for a BIOS/EFI update, and that could be an issue. At the moment, I don't know where one can simply buy the AMD Ryzen Embedded R2514. Alternatively, it could be the R2544. Maybe it's worth finding some Micro PC board and transferring the processor from it, as well as possibly the BIOS.

@pcrow, Great job! Thank you! I have a small request, if possible. Could you please add the LiteDOS filesystem? LiteDOS is a compact DOS created by Mr. Atari. As I recall, it has a filesystem similar to DOS 2.0 but with more space. It's crucial to have both read and write access. LiteDOS can be used for cross-development for users who have Atari, Fujinet, and a local TNFS server with a mounted ATR image, for example, in the LiteDOS format. Using the CC65 compiler or another, one can perform cross-compilation and then directly run it on real Atari hardware. It's also important for such software to manipulate the disk, rather than create an entirely new disk that contains files in the directory. It's important for all types of LiteDOS formats to work - that is, also those with significantly more disk space for data. Here is the webpage with documentation that includes the filesystem specification: http://www.mr-atari.com/Mr.Atari/LiteDOS/ At one point, I planned to write such a program in Python so it could run on Win/OSX/Linux, but I ran out of time. If needed, there's also contact with Mr. Atari, who will surely be willing to help.

@Albert, Congrats! Good job! Every acquisition of a great service/network/startup/company with capable, valuable people is a step in the right direction. Congratulations to the entire Atari team as well!

A planned update for the 80-column driver will be tailored to the VBXE core for the NTSC region.

A planned update for the 80-column driver will be tailored to the VBXE core for the NTSC region.

A little more advanced.

@wildstar87, @woj, I can introduce an additional product to the SAVO line that will produce proper synchronization for VBXE without needing SAVO. It will eliminate noise from the Atari and reverse noise from the cable.

So maybe I have my tiny contribution It's great that it has been taken into account.