@derfs

First, thanks for a very nice looking, full-featured and useful program (though it would be helpful to have a bit more detail on what the different benchmark tests do, so one knows what exactly is being benchmarked).

However, I get a recoverable DSI when I run the two most recent versions of AmigaDiskBench (v. 2.5.3 and 2.5.2) on my X1000 running FE Update 3. The DSI occurs soon after I start the program, apparently while it's scanning the drives. I can click on 'Ignore DSI Errors' and the program then appears to run normally (but see below for a different problem).


There is also a second, more fatal, crash. Because it's very similar to a crash in the most recent version of Rave, I posted the details of this crash in the Rave thread, where the problem has been discussed at some length.

@trixie

The latest version of AmigaDiskBench (v. 2.5.3) seems to have a very similar bug as Rave: When I run the program, select the Disk Info tab, and then click on "Fixed Drives/sb600sata.device" in the listview the program stops responding, along with much of the OS. (There is a recoverable DSI when I first run the program; that DSI doesn't seem related to the lockup bug.)

Like Rave, the crash happens when the program is working with ReAction gadgets, and the stack trace shows the crash occurs during a series of nested calls to the layout.gadget, followed by a call to the button.gadget. The first part of the crash log, including the general info and the register dump, seems to go missing. But what remains is enough to get an idea what was happening when the crash occurred:


The exact code where the crash occurs is different than Rave. There are some other differences as well: unlike Rave, the crash occurs under FE Update 2, as well as under Update 3. And unlike Rave, the crash occurs even if AmigaDiskBench is run from the RAM disk. While the crash occurs most of the time, it occasionally doesn't, unlike Rave where it is always repeatable. Since I have only an X1000, I can't say if the crash only occurs on the X1000, as it does with Rave.

AmigaDiskBench isn't your responsibility, but the fact that a very similar bug occurs there is some evidence that it's not caused by your code doing anything wrong, and may in fact be a system problem of some sort. And perhaps the differences between the Rave crash and the AmigaDiskBench crash provide some clues as to where the problem lies.

I don't use the mui file requester since many years because of some problem it gave me that i could not live with.

I should ofcourse have reported it but never got around to do so.

Does anyone know what kind of problem it gave and have it been fixed?
I can't remember what it was.

@bennyQuote:

Is there a timeline for that?

@n3m3

Problably when Mos 3.20 is ready

@C16Oli

In MUI you can choose what buttons shall be shown in the Window-border. Snapshot is the option that you are looking for.

@Tuvok

but names are strings and no numbers. they will be sorted alphabetically.
so this is the expected result.

regards...
michael

@Tuvok

next is 100,000 mark

@tao

Fix (or enhance) name sorting in Workbench (or is it a dependency in locale?)

e.g. on the Workbench the files below sorted by name are displayed in the following order.

filename_09.txt
filename_1.txt
filename_10.txt
filename_12.txt
filename_123.txt
filename_13.txt
filename_2.txt
filename_20.txt
filename_3.txt
filename_830.txt
filename_9.txt

Seems wrong. Mathematically ist seems more correct like this:

filename_1.txt
filename_2txt
filename_3.txt
filename_9.txt
filename_09.txt
filename_12.txt
filename_13.txt
filename_20.txt
filename_123.txt
filename_830.txt

@Ferry

Can you check your signature links? They don't work.

@328gts



92067

I know this question has been asked, multiple times.

How far are we out from being able to start purchasing and building our own?

@Tuvok
Thanks! Corrected.

@sailor

The article was an interesting read! I noticed a small little typo in the 3rd paragraph. T2021 instead of T2081.

Since the last demo reused the graphics of the previous one (with improved quality and additional effects, thanks to the extra alpha channel), the latter didn't look that good anymore, so I decided to rework it to produce a more meaningful and interesting result. I just released it, so who wants to try in on their machine can get it from https://retream.itch.io/ptdq as usual.



LAYERS

Common:
* PTDQ system
* RGBWa color model
* 320x256 visible dots
* interleaved bitplanes
* horizontal and vertical scrolling

Background:
* 336x272 dots
* maximum 256 colors

Foreground:
* 672x576 dots
* maximum 81 non-transparent colors
* 8-bit alpha per base color

NOTES

* Both the layers reside in CHIP RAM.
* The layers use 6 bitplanes in all.
* If the foreground had not used 100% transparent dots, its maximum number of colors would have been 256.
* The foreground mode is changed by writing a whole 24-bit palette to the COLORxx registers with the CPU during the vertical blanking. The required palettes are pre-calculated at startup.
* The Copper is idle most of time (but if the staggered lines are on, it performs a wait and a write for each visible rasterline). The Blitter is idle.
* The texture is 512x512 dots and gets scaled and rotated onto a triple-buffered 128x128 dots raster.
* The raster gets rendered onto the foreground while racing the beam by means of PTDQ_DoC2P_R() when, at the end of a frame, it is found to have changed (so, at most 50 times per second, even if the fps limit is off).

PERFORMANCE

On a stock Amiga 1200, the speed is about 17.5 fps.
On an Amiga 1200 equipped with a Blizzard 1230 IV mounting a 50 MHz 68030 and 60 ns FAST RAM, the speed varies between 80 and 94 fps.
The fps fluctuation depends on the fact that the fetching of the texture dots is more of less friendly to the CPU data cache according to the scale factor and the rotation angle.

English version of Mirari benchmark is on IntuitionBase

Reviving an old thread…

I had the same idea some time ago, to have an internal SCSI drive in my desktop A1200 with Blizzard SCSI Kit, but I didn't want to lose the possibility to connect external devices, so what I did is to make a new cable:

SCSI Kit connector ==> Internal DB25 ==> External DB25 (the original one)

Both DB25 connectors are female, and usually devices have male ones, but it's a wise decision to have some DB25 gender changers (male-male), just in case, some devices have the other gender, or you need an adaptor with the other gender (SCSI2SD needed a IDC50 to DB25 adaptor, and the DB25 in the adaptor was female, so a gender changer was mandatory).

So, whatever I connect to the internal one, inside the A1200, it has the termination set to OFF, so I can connect external devices on the rear DB25 connector. I have external HDs, a ZIP drive, several 2GB Jaz drives, a tape drive, a scanner, optical drives, even a SCSI 3"1/2 floppy drive from a SGI…

I have tried internally a SCSI2SD, a ZuluSCSI RP2040 and a SCSIknife Multi, all three work well.

You may wonder what happens if termination is set to OFF and i don't connect anything to the external one, problems may arise (even if I have never faced a single problem with only one device connected in 30 years), or else I should open the A1200 lid and change termination: I have an external DB25 terminator ( https://i.imgur.com/LAXOMja.jpeg ), so when nothing else is connected, I plug the terminator. Solved.

Now I want to try an internal BlueSCSI v2 with a RPi Pico 2W, it has WiFi, a nice and useful feature, and I'd like to give it a go. The problem with these small devices, this one and the ZuluSCSI Slim Pico, both designed to be external, the last device, is that both have termination forced to ON by design, you cannot change it. Fortunately, a friend with knowledge in electronics tweaked the BlueSCSI v2 DB25 and redesigned it, taking out the soldered termination resistances and placing holes for a socket for two resistive grids that do termination, like in the old hard disks, so you can connect them or not depending on the use. When internal, they will be unplugged, but I will be able to use it as external too just plugging them in its place.

Saluditos,

Ferrán.

@derfs
Thanks!
It works fine on macOS on A1.
Video test to see how it works



On Linux, I have peg2 and it doesn't work properly there.
Similarly, on peg2, I have problems with Virtio SCSI....

@ncafferkey


change CMOS battery

@kas1e

That's correct. But the file requester does not have any prefs unlike a full MUI window/apps.