Piotr D. Kaczorowski
-
Posts
338 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Piotr D. Kaczorowski
-
-
5 hours ago, 8-bit and more said:
I have a VBXE to install in my 130XE but while doing research on the VBXE I came across this article https://forums.atari.io/topic/7577-vbxe-is-this-upgrade-for-you/
The author states and shows examples of how the palete profile programmed in the VBXE may be for PAL systems and the colors are a little off. He further states that if you are paired with U1MB board there is a way to program a new palette file to compensate. Can anyone here shed some light on this reported issue or difference?
Rick
Check my SAVO XE addon for VBXE:
https://www.ebay.pl/itm/125814511405
Here, you will find the documentation: http://ftp.pigwa.net/stuff/projects/SAVO/
You can also order it from me privately through AtariAge. In that case, the cost via PayPal is $24.99 including shipping.
-
5 hours ago, 8-bit and more said:
I have a VBXE to install in my 130XE but while doing research on the VBXE I came across this article https://forums.atari.io/topic/7577-vbxe-is-this-upgrade-for-you/
The author states and shows examples of how the palete profile programmed in the VBXE may be for PAL systems and the colors are a little off. He further states that if you are paired with U1MB board there is a way to program a new palette file to compensate. Can anyone here shed some light on this reported issue or difference?
Rick
- First of all, thank you for the great Atari videos on your YouTube channel. Honestly, I keep checking it out all the time, and it was actually one of the two factors (besides Ultimate 1MB, VBXE, Rapidus) that made me return to Atari in 2020.
- As for the NTSC palette, an official core for VBXE has been released. There's a link above where you can find it.
- Regarding the Ultimate 1MB itself, you can install various plugins from the FJC website. Some of them offer the option to set the NTSC palette as an alternative for computers with a PAL palette. Of course, since the beginning of September, when you install the core with the NTSC palette, you can recompile the plugin with another alternative palette. Personally, on a PAL machine, I use the Rocky palette. I won't currently have a compiled plugin with a palette change to NTSC. I will use it occasionally, changing the startup core through the NC.COM program - which is perfectly sufficient for me.
-
31 minutes ago, TGB1718 said:
If it is one of these, then here's a few snapshots that will put you off ever getting one, I hooked up to a VGA monitor using an S-Video
cable as input, a standard 130XE, it couldn't even display it in colour (although I think on an old TV/Monitor that has VGA input I've seen colour)
The streaking is really that bad, I remember on the old monitor the picture was bad and a square about 1/2 of the screen.
For comparison, the second picture is the same 130XE, same cable connected via S-Video to my old monitor.
With that device, the display appeared as described, but in color. I might have used CVBS instead of S-video. I'm not sure, but the image quality was terrible.
-
On 1/11/2023 at 12:26 PM, woj said:
VBXE offers NTSC too, but check the forum for topics about NTSC pallete inaccuracies.
VBXE has official core with NTSC palette
-
On 1/10/2023 at 12:05 PM, Hrivis said:
Friend of mine experimenting with xe. He drilled some holes, 1cm on that shield part and did some wire and soldering from both sides. This is 800XE, with UltraVideoXE and Sram V3 from Lotharek. S-Video on Hercules. Pretty clean. Almost no sideshadows.
Looks like my drillings
0.4" not 1cm
Basically, I don't recommend it. It doesn't give any special effect.
It's best on the XE PAL board next to the PAL quartz to replace the choke and capacitor with a 470R resistor. This slightly smooths the signal and dampens it.
Next, stick with UltraVideoXE and replace the 470uF capacitor and all 22uF ones. It should be better on s-video.
-
2 hours ago, electrotrains said:
The cartridge port is fully hooked up to the RP2040 - no signals missing, as with the Ultimate Cart.
Main issue is memory - I put 1meg of SRAM on the Ultimate cart, so I could support 1meg (8mbit) AtariMax carts. RP2040 only has 264k of SRAM, limiting the maximum cartridge size. The flash (which is more plentiful) is too slow (from my experiments anyway) to service the atari bus.
Robin
What do you think about overclocking a bit? Maybe that will also improve the flash speed.
https://www.tomshardware.com/how-to/overclock-raspberry-pi-pico
-
7 hours ago, mytek said:
@electrotrains do you think it would be possible to make combo versions of OSS carts to run on either the A8Pico or UNO Carts? It would be like having one of the language carts plugged into the SDX cart.
So maybe something based on the 64K version of SDX combined with one of the OSS banked languages.
- SDX+MAC65
- SDX+Basic XE
- SDX+Action
I know there is currently a 128K limit on the CAR files, but this does seem doable even under that constraint.
This is essentially a continuation of my question regarding the differences between UnoCart and UltimateCart, and the use of the RP2040 microcontroller in A8Pico.
Does the RP2040 electrically have enough GPIO outputs to perform the tasks of the UltimateCart? Is it a matter of speed, handling a larger number of signals, a memory size issue, or a software issue?
-
1 minute ago, pcrow said:
I anticipate the most common use case is moving files around that originated on the Atari and will end up on an Atari. I don't want to have files getting modified when copying them.
However, it would be fine to have a magic extension that does text conversion from ATASCII to ASCII. Something like adding ".text" or ".ascii" to the file name when reading it. As long as the magic extension is four or more characters, it wouldn't interfere with any Atari files. I already do that for ".info" which shows the binary load blocks or a summary of the BASIC structure of applicable files.
You know, we live in times (e.g., ChatGPT) where determining whether a file is a text file or not is essentially trivial. In the future, there could be an option that such files are converted both ways. Other binary files might have (e.g., in Unix) an executable flag, which would indicate that they are binary and are not subject to conversion."
-
4 minutes ago, pcrow said:
I had to pick one for the directory listing, and treating the files as 8.3 file names seems like the most standard option.
For creating new files, you can just treat it as an 11-character file name, provided you don't use any '.' characters. I believe that works for accessing existing files, too, as the lookup code takes what you enter and splits it into the 11 characters as best it can (skipping to the last three if it sees a '.', otherwise just copying byte by byte).
I think I block creating files with directory-separation characters on file systems that use subdirectories, but otherwise I avoid mangling them.
This will be a mess for files with reverse-video file names, though it's just cosmetic. In Unix, the only characters you can't have in a file name are '/' and 0x00. I suppose someone out there loves to put zero-valued characters in their file names, and that's going to interact badly with atrfs. I don't ♥ dealing with that problem.
it was just proposal.... For now, there are probably more important things to do. However, for instance, in OSX there are systems that consider uppercase letters and treat both lowercase and uppercase the same. This is a design pattern that says a file can have a certain physical name, but many accessors.
-
Proposal for a Change Release.
(1)
Look at the directory of LiteDos FS.
From the Unix filesystem, we should have some different filename accessors.
For example:
1. "LITERD DRV" should be accessed by "LITERD DRV" or "LITERD.DRV"
2. "LITEINITXEX" should be accessed by "LITEINITXEX" or "LITEINIT.XEX"
(2)
In the future version, when mounting the ATR to the system, there should be an option for unix/crlf/cr/etc...
After verifying that a given file is text-based, with conversion enabled, it should recode characters and line endings to the host system, and when copying from the host, convert to the Atari convention.
If the above already exists, I apologize for the confusion
-
15 minutes ago, pcrow said:
In any case, since the simple test FUSE program works, I would like to understand why mine doesn't. If something is broken on an older FUSE version, then it would be great to work around it so that someone else doesn't hit it later.
That's why I mentioned adding "--dummy" to the current version. It should be very simple for you, and it will make the transition from one library to the other quite easy.
-
14 minutes ago, x=usr(1536) said:
Understood, and having had an iMac of that generation (2008-ish), I completely understand why you're topped out at OS X 10.11.
Thing is, most of the rest of the world is on macFUSE by now. And while I have no issues with you wanting to do an osxFUSE build of atrfs, please remember that you are building for an obsolete (and unsupported) target. If it works, great, but you are kind of a corner case on this one
(And FWIW, I feel your pain re: upgrading. I'm typing this on an early 2018 MBP, and the next macOS release will probably be the last one that will support this machine. Not thrilled about being forced into that when this one still does what I need.)
You know.. in Poland, I connected the first school to the Internet in 1993, and probably even earlier, for 2-3 years, I was working on Linux and Coherent/Xenix/Minix/Solaris/HP-UX. So I'm used to the idea that if something doesn't work, I can compile and fix it myself. Back in the day, as you might remember, a Unix Administrator = System Programmer. So, I'm kind of stuck on the old OSX. The interface is fine, my main tools are still iTerm2/tmux/joe/vim/brew, etc...
Unfortunately, I'm reaching the point where OSX is becoming a distortion of its former self. Generally, the idea used to be that everything works, and you focus on the work, not on preparing to work. Let me put it this way.. I'm not really convinced about computers on M1/M2/etc... because I feel like it's working on a mobile phone processor dressed up as a computer...
-
Awesome! :))))))))
-
5 hours ago, mytek said:
This protection scheme for the A8Pico Cart in my project has been tested and is working. Although I did have to add pull-down resistor R12 to insure that the CD74HCT4053 control inputs always had a well defined logic state, and were not allowed to float in the absence of USB 5V power.
So to review what this is doing. If the A8Pico Cart were to be left plugged into the Atari when not powered and then connected to the PC under these conditions, the RD4 and RD5 signals will be immediately disconnected from the pico, and thus prevented from seeing power under this switched OFF state. So this allows for safely flashing new firmware or adding new files to the Flash RAM without having to remove the cart from the Atari. Also diode D1 prevents back feeding from the USB supplied 5V into the Atari's 5V power bus, but still allows the Atari to power the cart if the USB 5V is not present. And the built-in diode of the pico board prevents the Atari from trying to do the reverse and back feed into the PC via the USB connection. So in other words protection has been provided for any scenario.
EDIT: This protection scheme was needed for my project since the A8Pico Cart aspect is built-in and non-removable.
Can this topic be interesting for subsequent revisions of the Fujinet project?
cc:
-
2 hours ago, x=usr(1536) said:
Hang on a sec - are you using osxfuse or macFUSE? osxfuse has been deprecated for a long, long time, and was replaced by macFUSE.
There were known (in)compatibility issues between them, which may be the cause of what you're seeing here.
So it happened that I work on a Mac Pro 3,1 (8xXeon, 32GB, SSD RAID 0) + Apple Cinema Display 30", which hardware-wise is not terrible, but thanks to Apple's policy, I have the OS X El Capitan operating system in version 10.11.6. On this system, I have the version that I have, and it works. Subsequent ones don't work. I normally use SSHFS together with Fuse. Everything works. I also provided an example, which also works without any problems. When the prices drop a bit, I plan to buy a Mac Pro Xeon W, but for now, it's still several thousand USD/EUR. For now, it might be cheaper for me to rewrite a piece of this software
-
- I bought crystals for PAL and NTSC without any problem.
- Galtron, who is a manufacturer of boards on Ebay, wrote on our Atari forums that he made them. Duddie - the manufacturer of PokeyMax replied that he ordered the crystal grid directly from the manufacturer and also has no problem making them to order.
-
I replace the 14Mhz crystals with VBXE and that's the best solution
- Nevertheless, if someone has an availability issue, the ones on Ebay will probably work.
-
8 minutes ago, bent_pin said:
These align with many ham radio bands. Suitable replacements should be cheap and plentiful.
0.70 PLN = 0.16 USD ..... Are you looking for a better price?
-
3
-
-
But why? I bought a lot of these quartz. They are generally available. You just need to check some online shops....
-
1
-
-
21 minutes ago, pcrow said:
That looks exactly like what I'm doing, only I've got more stuff. Just to eliminate anything that might be confusing it, in atrfs.c at line 594 remove everything from atr_oper except getattr, readdir, and read. When I do that, I can still list the directory and do the hexdump on .sector1. That will either say something else is confusing things on the Mac, or something is wrong in those functions. If that works, then add them back in until you find the culprit. I would think .init or .statfs would be the only other ones getting called.
Ok. During Friday I should have time to debug it.
-
-
57 minutes ago, pcrow said:
oking like the EIO is coming from MacOS itself or
Still the same...
look at this: "?atr1" (not /atr1):
-
-
12 minutes ago, pcrow said:
That's strange. The debugging output shows it's going through the code flow to look up the main directory, and it looks like it's giving a good result After that, reading .sector1 shouldn't be even touching the litedos.c code, and it shouldn't have an EIO getting returned. The EBADFD is probably a bug in hexdump's error handling causing a secondary error, so I would ignore that.
MacOS seems to be doing things a little differently, as I don't see the lookups on the main directory when doing the operations I described. It could also just be the older version of FUSE is behaving differently. I installed FUSE 2.9, and building with that gives me the same working behavior as FUSE 3.
I wonder if MacOS is expecting something different from the file system? I'm suspecting that it's something that isn't needed on Linux, so I didn't implement it, but on MacOS it's calling it and getting EIO before letting you do anything.
Here's an idea: Use -oro to mount read-only. I've seen MacOS .zip files with ._MacOS or something like that, and if it's trying to create those, that will fail, causing EIO. If it's read-only, it shouldn't try to create anything.
Side note: I just pushed the ability to specify --atrdebug=# for higher debug levels. Use '2' for more verbosity on a few things.
Left window:
$ ./atrfs -f -s --atrdebug=2 -oro --name=a.atr atr1
DEBUG: dos4_sanity: Cluster size: 6 VTOC Clusters: 66-67 (sectors 349-360) VTOC Sector count: 1 First VTOC sector: 360 Max DIR entries: 88 Max Cluster: 128
DEBUG: atr_preinit detected LiteDOS image
DEBUG: atr_statfs
DEBUG: atr_statfs
DEBUG: atr_statfs
DEBUG: atr_statfs
DEBUG: atr_getattr /
DEBUG: litedos_getattr: /
DEBUG: litedos_path: /
DEBUG: litedos_getattr: / lookup 0
DEBUG: litedos_getattr: / mode 040755
...
...
...
DEBUG: atr_getattr /
DEBUG: litedos_getattr: /
DEBUG: litedos_path: /
DEBUG: litedos_getattr: / lookup 0
DEBUG: litedos_getattr: / mode 040755
Right window:
$ cat atr1/.fsinfo
cat: atr1/.fsinfo: Input/output error
$ cat atr1/.bootinfo
cat: atr1/.bootinfo: Input/output error
$ hexdump -C atr1/.sector1
hexdump: atr1/.sector1: Input/output error
hexdump: atr1/.sector1: Bad file descriptor
-
34 minutes ago, pcrow said:
How far does it get? Run with: -f -s --atrdebug
That will keep it from forking to the background and add all the debugging.
Also check if it's just the directory listings that are broken. If your mount point is ./mnt, then:
cat mnt/.fsinfo
cat mnt/.bootinfo
hexdump -C mnt/.sector1
cp mnt/DOS.SYS .
(for the last, use any file you know exists on the image)
Don't try to change the working directory into the mount point until it's stable for you.
It doesn't go too far...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Action! snippets
in Atari 5200 / 8-bit Programming
Posted · Edited by Piotr D. Kaczorowski
EDITOR PREFERENCES
@JAC!, maybe there is a possibility to add editor preferences without extra handler ?