Then when you upgrade to Final Edition, all your serial device problems will be solved.

@smf

Just what I was going to say. The Final Edition version of serial.device says (when you do a "version full"):

serial.device 53.9 (14/06/2012)
Universal PPC version

@Severin

That's hot-installation, not hot-swapping ;)

In either case, I'm pretty sure that it's not implemented in any of our drivers.

@OldAmigan

No, that's nonsense.

That seems to be a peculiar way to find out the size of a file. Besides, you are assuming that the result will fit into 32 bits, whereas the result of (current) DOS calls is 64-bit.

I would suggest something like this (sorry, it's in C):

uint64 FileLength (char *path)
{
BPTR file = ZERO;
uint64 fileLength = 0;

file = IDOS->Open (path);
if (file != ZERO)
{
fileLength = IDOS->GetFileSize (file);
IDOS->Close (file);
}
return fileLength;
}

Yes, you can use an external USB drive. The only problem I can remember is that you will almost certainly need one with its own external power, as the USB ports in the SAM can't supply enough DC power to run things like CD-ROMs or floppy drives.

It should "just work". You will be able to plug in a PC-formatted floppy (FAT-32) and it will mount automatically. But you will not be able to read old Amiga disks.

Yes, I've had one die on me only a few days ago. The boot process seemed to freeze, but left to itself, it would complete after half an hour or so. The card seemed to be continuously interrupting while ever a HD was connected to it.

Once the system was up, I could move the mouse, but nothing would seem to change for about a minute, when the mouse pointer would jerk on the screen. You can imagine how long it took to type a command on the console.

Replacing the card fixed the problem, but it *could* have been just the act of unplugging the card and replugging the new one. I didn't recheck the old one after satisfying myself that it was the fault of the card.

At least TW sems to be immune.

@LyleHaze
That's great! Glad to see they are performing so well!!




er...




is there another team?

@nexus

So where are the figures for *before* the conversion? You said "10-11C higher", but we can't compare them unless you give us the figures.

Your figures for *after* the conversion are all very consistent for the rise above (case) ambient:

Case 30, CPU +7, Core 1 +13, Core 2 +9
Case 33, CPU +6, Core 1 +12, Core 2 +8
Case 37, CPU +6, Core 1 +11, Core 2 +7

Those temperature rises are all pretty close.

But what were they before the conversion?

@sundown

That's odd, I can't see any standoffs under my heatsinks. It looks as though the heatsinks in both machines have integral standoffs/feet machined to fit.

@MARCOM

Marcus, the heat sink used on the X-5000 looks the same as that used on the X-1000. Both are custom heatsinks made for VariSys.

I don't like the way they are machined - the fins are so thick and the gaps between them so narrow that they must restrict the air flow to a large extent.

That said, the heat sinks work, ie, they keep the CPU cool, well within its operating limits. If I were to replace the heatsink, it would only be to make it look better or run more quietly.

Is your heatsink custom-machined to fit the chip, or are you using a standard heatsink? If you are using a standard heat sink, how do you get it to fit the chip?

Can you provide a photo of the heatsink mounted in your X-1000?

No, because the filesystem is responsible for making sure that what is read from the medium is the lastest, most up-to-date version.

So either the Read will be taken from the cache or any outstanding Writes will be flushed before the Read is performed.

@zzd10h

Do you have a Compact Flash card plugged into the card socket on the motherboard?

The stack is an area of memory reserved for dynamic allocations and function call return addresses. The program starts with the "stack pointer" at the top of that area, and it grows downwards (towards lower addresses). As the dynamically-used parts are released, the stack pointer moves back up again. Unlike in many other OSes, AmigaOS does not have the capability to expand the stack area once allocated. The best we can do is to swap to another new, bigger stack for critical parts of the code, then swap back again later.

The "guard area" is a set of four longwords at the bottom of the stack area. If the stack grows so much that it reaches the bottom four longwords (without actually overflowing the whole space), then you get that indication. It's just an indication, no more, and it is not the reason that the program stopped.

If the stack went further (into the "red zone"), then you would get the "Stack pointer is outside bounds" message.

You should not continue from a DSI in any case, unless you are desperate. You never know what has been corrupted by the errant program before it finally crashed.

Are you sure you're not being too impatient? When you stick a CD in the drive, it takes some time to recognise it and try to mount it with every filesystem on your system. Only after it has failed with every available filesystem will it appear as an audio CD on the Workbench.

I would wait at least a minute before saying that "it doesn't mount". The fact that MTB (Media Toolbox) can see it means that it is at least connected.

You could have a problem with your SATA cable - those little connectors are vile and the designer should be sent to Guantanamo. Pamper them by bending the cable so it approaches the drive/mobo straight (not pulling the connector at an angle). If you can replace them with the variety that have little metal clips, even better.

Good luck.

@LiveForIt

Thanks for the thought, but I've forgotten everything about Classics and OS3.x. These days I have trouble remembering my own name.

@Billt: Are you sure that the problem isn't exactly what it says? If you have 1000 buffers set in MTB (it's in the Filesystems window, top RHS), then that will take 1000 x 512 or half a megabyte. If you have something other than 512 B for "Buffer Size", that will make it even worse.

Mick said earlier that block size should be 512 B. Joerg has said a couple of times that only 512 B block size has been fully tested. Other sizes may work but are not guaranteed. 512 B is safe.

Lastly, I seem to recall that on a Classic, you need to install a 68K version of the filesystem only if the Boot partition uses something other than FFS. I'm pretty sure that a PPC version is no use to you in that position.

cheers
-er- tony

@Mikey_C

I've had the same problem on my Sam 440ep with a USB external CD/DVD drive. It's one of those laptop-sized units, only half an inch thick. It used to work OK when plugged into the A1-XE, but not at all in either of the Sam 440s.

I eventually split the cable and connected it to +5V separately. It has worked flawlessly since then.

@tekmage

Maybe we should have a "free-for-all" session where Questions Without Notice can be asked and answered.

Do you think it needs to be replaced? Why?