- This old bug is still there in 4.1. When opening a new screen screen background is not cleared.
- This one is new. When a program does DisplayBeep() (flashing screen colours) the most of time screen title colour is not changed back to white but it stays black on any public screen other than Workbench. On Workbench screen this doesn't ever happen.
- I think this is an old one. Using Notepad (texteditor.gadget related ?) it leaves some dots there.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
I have also that problem with screen not cleared. I also use 1680x1050 wide screen in 32bit. Someone told me to wait for os4.1 and test but its the same there. I use DVI connection also.
A1G4XE 800mhz. 512mb ram. Radeon9200 (not se)
language: english country: sweden GMT+1 kbd: iso-8859-15
fonts workbench icon/drawer: Dejavu sans oblique/13 drawer text: Bitstream Vera Sans/12 System def: Bitstream Vera Sans Mono/12 screen font: Dejavu sans/13 antialising on
As regards graphics-related bugs, here's another glitch: once screenblanking caused the screen to go black with just a ~10 pixels wide, 1 pixel tall row of variously coloured pixels... and the system to freeze entirely! Note that I use the screenblanker engine without any modules - I just want a black screen. Fortunately for bug hunting, the very same problem is given always by the Blanker commodity again set to show nothing but a black screen (which I replaced only when I got AOS 4.1, exactly because of this problem).
TSK wrote: - This old bug is still there in 4.1. When opening a new screen screen background is not cleared.
I have the same problem here with a Radeon 9250 (and a 9100 before) and a 1680x1050x32 screen on a 22" LCD monitor. I had no problem with the 9100 and a 1280x1024x32 screen on a 17" LCD monitor.
Ciao Gabriele
in a world without walls and fences we won't need windows and gates
That last one, the dots off the left side of the Notepad program have been driving me crazy. It's just annoying.
I use ATI 7000 800*600 32 bit, and I'm pretty sure it was the same in 16 bit as well.
Change to courrier 11 point. Put a capital "W" in the first character position, then delete it, and that pixel remains there.
I tried all 25 other capitals and couldn't get it to appear. Don't know which other characters and sizes may do the glitch.
Support Amiga Fantasy cases!!! How to program: 1. Start with lots and lots of 0's. 10. Add 1's, liberally. "Details for OS 5 will be made public in the fourth quarter of 2007, ..." - Bill McEwen Whoah!!! He spoke, a bit late.
1. When accessing pull-down menus on a window that has none attached, there is a spurious extra pixel under the titlebar at the very left-hand side of the screen. (the shell is a good thing to open to see this)
2. I've just been trying out JXFS. It appears to support hardlinks but doesn't correctly identify them as such (they don't get underlined in WB or tagged as <hl> by dir). softlinks are being correctly identified as links though.
Is there any way to hide the .recycled dir like you can in SFS? (so you can CD to it but it doesn't show up in a directory listing)
Here's a weird bug in prerelease4. I just figured out how to recreate it.
I did: sort allfiles allfiles2
It is a big text file (~200K) of all the files and directories on my hard drive. What happened was, the new file created (allfiles2) was 1 character bigger! It added a carriage return at the end creating one extra blank line. Now, at first I couldn't recreate it, but remembered that in notepad I erased the last blank line at the end of my text file and saved it, and that's when it gets reattached after the sort. Obviously sort shouldn't alter the size of a file.
Support Amiga Fantasy cases!!! How to program: 1. Start with lots and lots of 0's. 10. Add 1's, liberally. "Details for OS 5 will be made public in the fourth quarter of 2007, ..." - Bill McEwen Whoah!!! He spoke, a bit late.
I wrote an Arexx Script which redirects the text output of a running program to a CON: window, namely with this command:
[b]put program here > "CON:100/200/820/71/111111111x222222222x333333333x444444444x555555555x666666666x777777777x888888888x999999999x000000000x"
Just for testing purposes, can someone do a test with a "type big_file" and this redirection, please?
For me the line in the CON window is cut at 98, which was not the case with 4.0. It gets even worse when using text instead of these numbers, then my text is cut at letter 88.
Why is that, what was changed that made it cut at that position? Or is it maybe a LOCALE problem?
Any help, suggestions or pointer on what i may be doing wrong very much appreciated.
Another limitation is in the env var display on the title bar. It seems its limited to 69 chars and then gets cut, mostly noteable while using the "playing" env var from TuneNet and displaying it through Workbench prefs.
Is this intended? Because i still have plenty of space left (1920x1200 resolution here)
Obviously sort shouldn't alter the size of a file.
Actually, this isn't at all obvious. Think about it for a moment from a programmer/implementation perspective:
You split the file into lines, with each line ending in a CR. Then you sort the lines, before finally outputting them into the new file. But the line at the end of a file may not end with a CR, yet it should still be counted as the end of a line. What happens when you move this line (without a CR) before other lines? Should it still lack a CR? No, of course not! Therefore you add a CR, increasing the file size by 1 character as observed.
You *could* argue that Sort should have special-case handling that strips the new file's final CR, if the original was missing it too. But then Sort is actually deleting a character that was previously present at the end of a line, so no doubt someone ELSE might claim *that* is a bug!
The only reason I can think for choosing one implementation over the other is that the file generated by Sort my be used as the input to some other automated processing, and the presence/lack of a final CR *might* conceivably cause problems if it differed for the original. But it certainly isn't "obvious".
For those with screen "erasing" problems, try changing the size of the screen from 1680x1050 to 1696x1056 (to make it a multiple of 32 pixels wide). See if that makes any difference.
Re console "problem": I don't think there are any real changes to the console or con-handler between the 4.0 2007 July Update and the 4.1 release.
AOS4 prerelease 4 system lockup. AmigaOne XE 800 MHz, 2 gigs of ram. No fixes.
A most interesting observation when my computer locked up today.
I've had the computer run as long as 30+ days and sometimes the keyboard and mouse stop working at the same time, but the OS seems to still be working. (As I said before, I've let it sit extra days until the OGR25 ran out of packets to resolve, and the internet link wasn't working either, when it tried to send done and recieve new packets.)
It is a PS2 keyboard and mouse. Both have chords.
Okay, so get this, there is a "number lock" and "Caps lock" light on the keyboard. After the lock up, neither of the lights would turn on and off when I pressed the buttons. I thought that they operate independent of the AmigaOne's CPU! Does this help track down why the lock up happens? Anyone using AOS4 final or AOS4.1 get a higher uptime than ~32 days?
I think that there may be an incrementing variable that hits overflow, as it has frozen in the ~32 day region on me about 3 times now.
I haven't made a script file that can isolate the time closer to when it occurs.
Not sure I can, other than something like a script that writes to HD every 30 mins, but the HD I think keeps working no problem as the OGR program can keep opening and closing a file in RAM:. I am not able to make something that say polls the keyboard/mouse/internet connection until it fails.
Support Amiga Fantasy cases!!! How to program: 1. Start with lots and lots of 0's. 10. Add 1's, liberally. "Details for OS 5 will be made public in the fourth quarter of 2007, ..." - Bill McEwen Whoah!!! He spoke, a bit late.
I've formally reported the graphics bug (dot left behind when a "W" is erased). Let's hope we can get it fixed this time.
Did anyone try the screen dimension test? I seem to remember that the Radeon driver needs a bitmap that is a multiple of 32 (or it might be 64 or 128) pixels wide and high.
If you use Prefs/ScreenMode to increase the size of your screen to W*32 x H*32, it might make a difference. To keep the display dimension a fit for the monitor, maintain the displayed size (in the Prefs) as 1680 (Width) x 1050 (Height). Unclick the "Default" box on each line.
If that doesn't work, try 1728 x 1088 (multiples of 64), keeping the Width = 1680 and Height = 1050.