ACA620 reset proof ram disk

[Toni Wilen]

Attached version hopefully fixes problem caused by acatune.

[demolition]

Thanks, that seems to solve the problem. I could now move a file to it, warm reboot with all acatune settings, and read the file back out without any corruption.

Jens should hire you to fix his software.

I can now get to try booting from it. Is it possible to change the boot priority of the drive using aca620rd after it has been already been run? Think that it would be most convenient to not have it bootable until all needed boot files has been copied to it.

Edit: I have just tried creating a bootable device and copied a WB 3.1 floppy to it. It seemed to work fine and booting time was obviously very fast. In Sysinfo I see around 5.7MB/s on the drive, so a good deal faster than the standard IDE interface.

[NovaCoder]

Originally Posted by demolition

Jens should hire you to fix his software.

That's actually a very good idea

[Toni Wilen]

Originally Posted by demolition

Thanks, that seems to solve the problem. I could now move a file to it, warm reboot with all acatune settings, and read the file back out without any corruption.

Technically it was my bug because I assumed card registers are always available but I think they were supposed to be hidden unless needed to prevent accidental card configuration changes.

Jens should hire you to fix his software.

No comments

I can now get to try booting from it. Is it possible to change the boot priority of the drive using aca620rd after it has been already been run? Think that it would be most convenient to not have it bootable until all needed boot files has been copied to it.

Not yet but it is planned.

Edit: I have just tried creating a bootable device and copied a WB 3.1 floppy to it. It seemed to work fine and booting time was obviously very fast. In Sysinfo I see around 5.7MB/s on the drive, so a good deal faster than the standard IDE interface.

It is just memory copying but during copy interrupts needs to be disabled because enabling "hidden" ram will hide part of real ram regions. (which may contain interrupt handlers or other critical system structures)

[demolition]

Originally Posted by Toni Wilen

It is just memory copying but during copy interrupts needs to be disabled because enabling "hidden" ram will hide part of real ram regions. (which may contain interrupt handlers or other critical system structures)

So it could potentially still break under certain unlucky conditions?
I don't assume that you can disable interrupts during access when operating in WB?

[Schoenfeld]

Originally Posted by demolition

So it could potentially still break under certain unlucky conditions?
I don't assume that you can disable interrupts during access when operating in WB?

forbid() is always available, also under WB. It should not be disabled too long, but it is meant exactly for things like this: Make an action atomic, because other actions may interfere with it. Unfortunately, a semaphore doesn't do the job here, as you can badly mess with the ACA620 memory layout ;-)

So no, if implemented the right way, it doesn't crash.

Jens

[Toni Wilen]

It does not break anything but it can cause programs to report unreliable speed rates.

Also "hidden" memory is located in same addresses as second 4M fast ram region = any ram disk read or write access to/from this region needs to use temporary buffer = 2x slower speed. (copy from real ram to temp location, disable interrupts, enable hidden ram, copy from temp to hidden ram, disable hidden ram, enable interrupts or vice versa when writing to real ram)

I'll add bootpriority change/disable option and then I'll release next official version.

[demolition]

Shouldn't you disable interrupts before copying data to temp location, as more data could be written while the copy is performed?

If, for some reason, memory is completely full (or almost), I guess this would cause it to fail as you would not be able to find a temp location?

But this would cause WB to bug anyway, so I guess it's not really a problem.

[Toni Wilen]

Temp location has been allocated from special ACA RAM region and it is only 512 bytes (one block), interrupts are always enabled between each block copy to allow system to stay responsive even if copy is much longer.

Speed optimization isn't always the best idea.

[Toni Wilen]

Updated.

BOOTPRI and NOAUTOBOOT parameters can be used to change autoboot priority even if ram disk is already mounted.

New OFS option can be used to force OFS format, for example if you have KS2.0+ ROM, you can mount the drive with OFS parameter and then use acatune's maprom option to boot to 1.3 from ram disk.

Ram disk now works correctly even if acatune is run during ram disk access and timing was unlucky enough.

[demolition]

This is looking better and better. That OFS feature could be useful if it can then boot from KS1.3.

How about being able to set the disk label as a parameter as well?

[Toni Wilen]

Originally Posted by demolition

This is looking better and better. That OFS feature could be useful if it can then boot from KS1.3.

It does, at least in my test

How about being able to set the disk label as a parameter as well?

I don't think it is needed, use c:relabel. (I don't want to add too many parameters because it uses quite annoying BCPL stuff which is needed for 1.3 compatibility..)

[demolition]

Originally Posted by Toni Wilen

It does, at least in my test

And it does here as well. Just copied a WB1.3 disk onto it and maprom'ed ks1.3 and it booted up just fine. The memory map program in wb crashed the machine though, but I would expect ks1.3+wb1.3 to encounter a few issues on an aca620 machine. :-)

Originally Posted by Toni Wilen

I don't think it is needed, use c:relabel. (I don't want to add too many parameters because it uses quite annoying BCPL stuff which is needed for 1.3 compatibility..)

You're right, relabel should be present anyway at the time when the drive is created.

[Schoenfeld]

Originally Posted by demolition

I would expect ks1.3+wb1.3 to encounter a few issues on an aca620 machine. :-)

Note the history of development: The "big revision bump" to 2.0 was made because while working on "1.3+", the first 68020+MMU accelerators for the Amiga were available. Along with MMUs came the first enforcer-debug tool. From what participants of the DevCon meetings told me, more than 130 enforcer-hits were fixed between Kick1.3 and Kick 2.04.

With a machine "full of memory" and 256 mirrors of the same 16MByte space, I'd expect any enforcer hit to hit valuable memory and useful structures. The probability for the ACA620 to crash is much higher than any other accelerator, just because of it's memory structure. With less memory, it's more likely to hit "empty space" with an enforcer hit, and the machine may continue to run stable.

I would therefore only run Kick1.3/WB1.3 for fun, but not for any productive work.

For those who are not familiar with the term "enforcer": That's a tool that lets you monitor memory accesses. It's like a small watchdog: If a piece of code accesses memory in "illegal areas", the enforcer program will keep that code from doing so, and halt operation - that's the "hit". It's not really memory protection, and it does not work on all memory areas, but it's still valuable (especially identifying null-pointers...).

Jens

[demolition]

Originally Posted by Toni Wilen

Temp location has been allocated from special ACA RAM region and it is only 512 bytes (one block), interrupts are always enabled between each block copy to allow system to stay responsive even if copy is much longer.

Makes sense, as I thought the temp location was in hidden ram but it is the 32kB unallocated space (trampoline area) that you're using here?

I am trying to learn how to use Resource, so I hope you don't mind I used your tool as training.

In one place, I can see that you enable the hidden ACA620 registers before you disable interrupts. Isn't that a potential problem if you get a badly timed interrupt?

[Toni Wilen]

Originally Posted by demolition

Makes sense, as I thought the temp location was in hidden ram but it is the 32kB unallocated space (trampoline area) that you're using here?

Yes. Temp buffer is there and copy code (It is the only non-chip ram region that is guaranteed to exists in all modes)

Other code is in F0 "ROM" and also device geometry and name etc.. static data is there.

I am trying to learn how to use Resource, so I hope you don't mind I used your tool as training.

Sources may be released in future but it has some quite advanced doshandler/boot magic i am not going to reveal too easily

In one place, I can see that you enable the hidden ACA620 registers before you disable interrupts. Isn't that a potential problem if you get a badly timed interrupt?

Init part may have one because I didn't want to modify it yesterday.

[demolition]

Originally Posted by Toni Wilen

Sources may be released in future but it has some quite advanced doshandler/boot magic i am not going to reveal too easily

Yeah, it's probably not the easiest thing to start with when trying to learn disassembling. Think I figured out about 5-10% so far.

Btw, I assume it was made with a C compiler? Because there's some 'register juggling' going on in places which doesn't look like how one would make it in pure asm (makes it a lot harder to follow as well).

[Toni Wilen]

It is pure asm. Register "juggling" happens when new features are added, then you run out of registers and you don't want to rewrite the code

[mark_k]

I don't have an ACA620, but here's a suggestion anyway.

Add an option to create a RDB + single partition in the ram disk, with possibility of loading a user-specified filesystem to the RDB. Then under Kickstart 1.3 you could format the ram disk as FFS and store more data. Since later FFS versions support ACTION_FORMAT that could also avoid the need to manually format on 1.3.

[Toni Wilen]

Originally Posted by mark_k

I don't have an ACA620, but here's a suggestion anyway.

Add an option to create a RDB + single partition in the ram disk, with possibility of loading a user-specified filesystem to the RDB. Then under Kickstart 1.3 you could format the ram disk as FFS and store more data. Since later FFS versions support ACTION_FORMAT that could also avoid the need to manually format on 1.3.

Too complex.

My magic filesystem code already supports external filesystems, I just didn't bother with it (in this project) because this ram disk was supposed to be very simple.

It would only need to handle two more parameters: path to filesystem and dostype.