@geennaam
Quote:

Tried that some years ago. Added to AmigaBoot the ability to read a single file containing all the Kickstart modules. Problem was that reading the microSD card is slow, slower than reading a physical disk. Best improvement I could get was about half a second (in 35 sec), so the idea was abandoned.

@nbache

I haven't downloaded Capehill's version, but mine is:

>list c:top
Directory "c:" on Saturday 25-Mar-23
top 10224 ----rwed 01-Aug-08 00:38:28
1 file - 9K bytes - 6 blocks used

>md5sum c:top
f6a4c63de1f02afdfb17339cfc511769 c:top

@Deniil

When you say "new monitor", I assume that it is a "new" monitor, recently made, not just an old CRT. If it is an old CRT or does not support DDC, then please accept my condolences and ignore this reply.

Why do you feel the need to generate special display modes at all? Why not simply enable "Detect settings automatically" and "All supported modes"? That way you will get all the possible modes that the software and monitor can both handle.

You don't need both the "Radeon" driver and the "Radeon 6570" driver. I think the "Radeon" driver is just the original default.

The graphics library interrogates the monitor (using the DDC protocol) and obtains a list of the display modes that the monitor can handle, along with its preferred mode, min/max scan rates, etc. Graphics then strikes out any modes that the card and driver can't handle and shows you a list of what's left. The only say you have in the process is to add entries to the tooltypes of the Radeon 6570. It's better to leave them all disabled (in parentheses) and let the driver sort it out.

My Radeon 6450 driver icon has:

CMPLENGTH=14
BOARDNAME=Radeon HD 6450
DDCMODE=All
...
(lots of disabled entries)
...
DISABLEFAKENATIVE=Yes
INTERRUPT=Yes

That's enough. As a result I get modes with scan rates of 640x480 all the way up to 1920x1080 (the natural resolution of the monitor), with CLUT8, RGB16 and ARGB32 for each rate.

Quote:

Yes it does. Like most other file systems, there is a Root Block that contains all the geometry for the partition. The "Partition Geometry" structure contains the disk addresses of all important structures. Using it, you can determine where the bitmap resides/how many blocks it contains, and from there, which blocks are currently used and unused. It is not public information, and is subject to change at any time without warning, even if nothing is written to the disk (internal housekeeping).

@joerg

It's a long time now since I looked at the problem and I've forgotten most of what I learned. However, your step 1 is fairly easy to do and I think I did it back then (whenever it was). It was step 2 that I couldn't get to work. AFAIR the drive would not accept my TRIM commands and simply returned an error status.

I don't think any change is required to implement 4k sectors *in the driver*, and certainly not in NGFS, which can use 32 kB sectors if the driver specifies such a size in the geometry. MTB is another matter, but is obsolete in any case.

Sure you can read the bitmap to identify all the unused blocks (and I was intending to mark "deleted" data as "unused"), but, as I said, I couldn't get it to work with any of the SSDs that I tried.

@geennaam

Many years ago, I spent several weeks trying to implement TRIM in our standard device drivers (SiI3112/3512/3114 etc). Like you, I was intending to use the Erase feature on data blocks that were no longer in use, so the file system would "Erase" the blocks with a call to the device driver.

I couldn't get a proper TRIM response from any of the SSDs that I tried, and eventually I gave up. I could have been sending the device the wrong commands or format.

I'm sure you will agree that the Erase feature must be incorporated into the device driver, as only the driver knows whether the device is an SSD or a frisbee. My intention was to get the driver to set some status that a caller could interrogate, so that a file system would know when erasing was possible. It would also be possible to prohibit people from doing a Full Format on an SSD partition.

I did make some measurements of device speed on SSDs and frisbees, and I found that SSD Write transfer speeds were essentially constant, regardless of transfer length (which means that overheads in DMA processing and task switching were considerable). Of course, I was unable to measure the speed of Writes to "deleted" blocks Vs Writes to "occupied" blocks. However, I can say that the overall speed of file system operations is not going to be much improved by ensuring that old blocks are cleared. The speed of SSDs is such that file system operations are not limited by device speed, but by DMA transfers, overheads and housekeeping within the file system (garbage collection, cache maintenance, etc).

So to answer your query - only the file system knows which blocks have been freed and can be deleted. Once they have been freed, the file system does not know any more and there is no means for an outside entity to find out.

The information you want depends on the file system, naturally. What a file system does with "deleted" data is very low level, very private and subject to change with evolution.

In the file systems that I know of, the addresses of deleted data blocks are not saved anywhere, as they are simply returned to the general pool of available data blocks. Most times they are stored in a bitmap (one bit per block), which simply marks each block as "used" or "free". There is no indication of which have been used before or what each block is used *for*.

So, since you can't say where the deleted data was, and since the data blocks it used it may have been reassigned for some other purpose, the question is impossible to answer. The file system still knows while it is deleting the old file (or whatever it was), but once that is finished, there is no longer any information to say where it used to be.

Another problem is that data that has been "deleted" on an SSD no longer exists - the disk firmware actually wipes the data from memory. I don't know of any file systems in Amigaland that invoke the "delete" feature on an SSD, but it will probably happen one day.

@rjd324

Everything starts with Exec.library. If you want the address of foo.library, you have to call Exec's OpenLibrary() to get it. If you want to print something, you need to Open() a device. So you must have the address of exec.library first of all.

Since it can change at any time (could be loaded in a different place since it's not in ROM any more), the address is stored in a known place, ie 0x4.

@rjd324

You can't. Any sort of freeze is going to make it impossible to save (and close) an output file on the same machine. You can sometimes save a file after a crash if you are lucky, but a lot of stuff has to still be running, and usually Workbench is hung up and crashed because it was Workbench that ran the program in the first place.

In the case where you ran the crashed program from a Shell, I have sometimes had a second Shell already open when the first Shell crashed, and then I can leave the first program crashed (don't touch the Reaper window) and click in the second shell to save the debug file; but just clicking in another Shell can lock the machine totally if it's a bad crash.

Your only reliable method is to use a second machine to receive and save the debug output.

On second thoughts, if you had a very, very, very long cable, you could reboot the machine after the crash and be ready to capture and save the crash log when it finally finished the round trip...

@kas1e

I know a lot of this has been said before, but...

CFE is old and has not been updated since the original public release. It was modified to recognise FFS as well as
the other FS that it already knew (Ext2, FAT32 etc). It does not recognise or read SFS, NGFS or any other Amiga FS.

At boot time, CFE looks for and reads amigaboot.of (from the device nominated in the ENV-vars command line).
The current version of amigaboot is 54.8, which you should have as a betatester. That amigaboot version can read and boot
any Amiga FS and is the same as amigaboot.ub on the X5000, but is loaded and run by CFE instead of by U-Boot on the X5000.

CFE can certainly load and run amigaboot from a USB stick - that is how I booted my X1000 back when I first got it.
IIRC the instructions were in the PDF manual. The USB stick has to be in the "first" port. Don't remember any more about it,
it was over ten years ago.

You can load amigaboot from a CF card also, but it will probably have to be FAT32. There is no benefit to be gained
by formatting a CF card with FFS. You may be able to write a whole AmigaOS installation onto a CF card, but it would be slow as hell
to run, since it can not do DMA transfers.

Once CFE/U-Boot has loaded and run amigaboot, Amiga file systems FFS, SFS and NGFS are then readable,
on any device that CFE/U-Boot can read.

Amigaboot uses CFE/U-Boot functions to read everything from the boot volume. So you can only boot (load Kickstart modules from)
a device that CFE or U-Boot can read. That means no PCI devices.

AmigaBoot can decode any of the file systems listed above, it only has to be able to read them using CFE/U-Boot functions in raw mode.

It's moved on in the sense that FileInfoBlocks are obsolescent. We have all spent many happy hours removing such outdated structures from system software and replacing them with calls to IDOS->ExamineObject() etc.

@Magic

Can you run both X5000s at once? If so, you could connect a serial cable between them and perhaps see (on the /020) what is wrong with the /040.

The X5000 only needs a sniff of electricity. Your graphics card will consume more than the rest of the machine.

Three things to test:

1. Open the machine in a place where you can really get inside it - plenty of light, on the kitchen bench or somewhere.
Remove the screw holding the gfx card and remove the card. With a plastic eraser, run over the PCI-e connector (both sides) lightly. Don't touch the connector with your fingers, but clean off the eraser dust with a small, dry paintbrush.
With the brush, clean the inside of the motherboard connector.
Replace the card and check that the card is not pulled crooked when you tighten the screw. You can bend the bracket slightly to make the screw fit properly.
Repeat for any other PCI-e cards.

2. Check the 3V CR2032 coin cell. Sometimes suppliers leave a small piece of plastic insulator in the socket to prevent the cell from discharging in storage. If you have a voltmeter, check the voltage from the exposed side to chassis - it should be 3.0 to 3.3 V. Less than 3.0 V and it must be replaced (but the X5000 will run with no coin battery in place).

3. Reseat the SATA cable(s). They are notorious for developing bad contact after a time. Make sure that the cable is straight and not pulling the connector to one side - you can bend the cable to make it sit straight.

Is that a wombat?

Hi guys,

Only a few weeks ago we found and fixed a bug in the battclock.resource. It was causing exactly the problem that the OP describes, ie after losing backup power, the clock can't be made to run from battery any more.

"Setclock reset" should re-enable this ability, but due to a bug, it wasn't always working. It affected the X5000/20, X5000/40 and A1222, but some machines worked regardless (for instance my X5000/20 was OK). There are probably some clock chips that behave slightly differently from others.

It has now been fixed (in beta releases at least).

@kas1e

Please try using IExec->DebugPrintF() instead of printf(). "printf()" calls a clib/newlib library function which WILL inevitably cause a Reschedule() and that will allow other tasks to run, even if only briefly.

DebugPrintF() does NOT call any C library code: it writes directly to the serial port without using interrupts, or Waits, or any code that could encourage or force a Reschedule().

My guess is that DebugPrintF() will act the same as (no printf() at all) does, suggesting that your problem is "fixed" by forcing a Reschedule().

If that is true, then you have to find out why preventing a Reschedule() prevents the "compile" from working. I don't know anything about these advanced graphics, so I don't even understand what you are "compiling".
But presumably there is a Process that has to operate on some pseudo-code or tokenised code, and it fails unless something else gets control of the CPU sometimes. Correct?

I've looked at AmiDVD also, and yes, there is no version string that can be read in the pure binary, but C:Version finds one, so you have to LoadSeg() the binary before it becomes legible.

Perhaps we should LoadSeg() the binary into a buffer, and then try looking at the buffer content.

Has anyone asked Joerg if he is prepared to update the program?

kas1e,

The binary for Odyssey is huge - some 36 MB. Because it is >32 MB, its PPC FP op-codes can't be translated into SPE op-codes and it will have to run under emulation on the A1222.

Can you split part of the browser off as a library, to keep the largest binary down below 32 MB?

Sorry if I've missed this in an earlier post.

I downloaded the OS4Depot version and installed it to a fresh partition. I have copied my bookmarks.html file over from the previous installation but I don't see any of my old bookmarks.

Has the format changed? What have I done wrong?

@beanbandit

It won't work on an X5000 or an A1222. It has to be supported by the driver and there is no support for it yet.

I can understand Matthew's plan: it is to progressively replace the Amiga commands and utilities with new versions that offer the same or better features, but with the advantage that they are free of the Amiga curse.

For that reason, it is preferable (even essential?) to replace the old "tainted" versions with the new "clean" versions, by using the same names. As Matthew has said several times, it is up to us whether we install the new versions over the old, or rename them to something new.

As long as we know the situation, we can avoid a problem when we install Enhancer.