Amiga questions you've always been too embarrassed to ask

[Exodous]

Thomas said "For nil: you are right". Therefore he is in agreement with that statement, so it's not that one

To access the redirected "content", software makes use of the dos.library "Open" function (or method if that's what you'd prefer to call it)

I used the term "file" because that is exactly what is used in the official Commodore "Includes & Autodocs" documentation:

Synopsis: file = Open( name, accessMode )

Results: file - BCPL pointer to a file handle

http://amigadev.elowar.com/read/ADCD.../node02D6.html


If I'm wrong using the term "file", then Commodore are also wrong, so I'll take that

[Leandro Jardim]

Another thing, what is the reason to execute a tool with double redirection after the Run command? Like a example very similar to this I have seen another day:

Run <>NIL: C:Foobar <>NIL:

I know what the Run command does, and I understood the meaning of the double redirection now (thanks!), but why someone would like to send the CTRL+C key sequence to the Run command to break it for example, if on this example it is run in background with the >NIL: redirection? I suspect the effect of that double redirection is null, and if I think someone would like to break the execution of the tool, I guess would be more logical to double redirect only the I/O of the C:Foobar tool, no?

[Exodous]

That just looks like the result of some confused thinking.

*cli in the response below relates to shell, cli, command window or whatever else you want to call it.

**stream in the response below indicates file, device etc. as the term file seems to be disliked

The "run" command launches the supplied command with the respective arguments, but the redirection is only done at the point of the cli executing the "run" command.

When the command is "released" as a separate task, the file pointers to the input and output streams are assigned to the Exec task structures.

If input/output redirection isn't done, then the command being "run" has a link to the cli for input and output. This means the cli can't be closed until all commands have finished execution (technically, they could probably close their input / output stream via the Exec task structure, but that's probably extremely bad form and likely to cause instability)


When both redirections are the same, there's probably no harm in having both of them, though it's unnecessary.

However, expanding this further if there were two different instances, for example "run <a c:Foobar <b" it would be very much down to the cli parsing which was the chosen input stream. Worse still is that it is likely to be inconsistent between different versions of the OS.

Therefore, it's probably best to only have one input and one output redirection as it should then be consistent.

[Exodous]

I missed a bit, if the process has been released from the current cli, then ctrl-c won't have any effect upon the released process.

Open a shell and run something like:

dir dh0: opt a

ctrl-c works and breaks the listing.

Now do the following, with no redirection:

run dir dh0: opt a

ctrl-c has no effect and you have to wait for the listing to end.

If your hard disk isn't "dh0:" then replace that with whatever your hard disk assignment or drive name is.

[thomas]

Originally Posted by Leandro Jardim

Run <>NIL: C:Foobar <>NIL:

There might be differences in AmigaDOS versions, but at least in 2.0 thu 3.9 run >nil: is sufficient to completely detach the new process from the current CLI.

The new process inherits its input and output from the mother process, so run >nil: something >nil: is overkill.

Run prints the CLI number of the new process to its output window, so you want to use run >nil: to suppress this.

But as run >nil: also suppresses the output of the child process, you might want to use something like run >nil: something >con: to get the output of the child somehow.

[Leandro Jardim]

Thanks for the help with my questions guys, that's all for now.

[Viceroy]

Hi All. With having plenty time on my hands at the moment I have finally got around to getting my old Amiga Dopus 4 config buttons onto my Winaue set up.
I'm all but done, but I'm stumped on a few buttons?
I have 3 buttons. XFD Decrunch which works fine, I also have a XFD List button which seem to go through a dir and list what each file is packed with, that works fine but can I hell remember how to configure it so that when it finishes scanning you have to press mouse button to quit window? After scanning it just closes window!
I also have a XFD Scan button which asks for a filename prompt?
Lastly I have a XPK Decrunch button, Do I need XFD & XPK, is there any difference, hope somebody can assist ;-)

[daxb]

For DOpus5 there is an option to hold open a window. If DOpus4 doesn't have this option you can redirect the output to CON: and use the WAIT (and CLOSE?) option that should not close the window. E.g.: "yourCommand >CON:0/12/400/200/"window title"/WAIT/CLOSE"

[Viceroy]

Originally Posted by daxb

For DOpus5 there is an option to hold open a window. If DOpus4 doesn't have this option you can redirect the output to CON: and use the WAIT (and CLOSE?) option that should not close the window. E.g.: "yourCommand >CON:0/12/400/200/"window title"/WAIT/CLOSE"

Sorry but I don't understand any of that?

[NLS]

Use all that as command.

[d4rk3lf]

Just out of curiosity:
Is there any Amiga 500, 040 or 060 accelerator?
All I could find is this old one:
Progressive Peripherals 040-500

Looks interesting, but it seems a very rare, and I couldn't find any clip on youtube on how it works.

Nothing else on the market?

[Jope]

The Warp 560 is coming along hopefully.

[d4rk3lf]

Yeah, saw the warp project too... looks amazing.
Looking at the A2000 accelerators, and they mention, that this one should work on A500 too.
Blizzard 2060

060/50Mhz

Imagine having one in your A500, and your friend is bragging on how his A1200 030 is fast.

[zipper]

Yes, but my blizzardised A500T runs 57 MHz (also 60, 64 locks up).

[d4rk3lf]

Neat!
I'd like to see that in action!
Do you maybe have youtube account and some clips with it, or someone with similar setup?
I started getting more and more interested in these, non standard, configurations.

[Toni Wilen]

Not exactly same thing as "real" A500 accelerator but ACA500/ACA500plus can be used to connect A1200 accelerators to A500. At least Blizzard 1240, 1260 and PPC do work.

[d4rk3lf]

I am an (happy) owner of Aca 500+, and I knew that I could attach other Aca accelerators (up to the 030), but I had no idea you could attach Blizzard 1240, 1260 and PPC.
Thanks for the info.

[Gilbert]

Not embarrassed to ask this but can the Amiga CD32 stream in data from CD while it's playing games - using the Akiko chip?

If so I figure you could really use a lot of animation data in the game - extra enemies and animation frames that you stream in just before they appear. This could make more arcade perfect ports possible.

[jotd]

The Amiga CD32 can read data from CD in 2 different ways:

- play audio tracks
- read files, like any other hard disk or floppy device. The transfer rate is around 300kb/second with a slow access time.

So no, dynamic frame loading isn't even done with hard disks, so with CDs it's not going to happen either. At the time, the CD just offered huge storage capacity (which explains a lot of games with talk, as opposed to their floppy counterparts that didn't have some), and in this case, yes there were streaming of the audio data to the Paula chip
And it also allows to play CD-quality music (44khz, much more than the Paula 28khz) while the game is running with 0% CPU overhead and the 4 paula channels free for sound effects.

What you're talking about only happens in Neo-Geo style games where the ROM was almost equivalent to the size of a CD (hundreds of megs) but accessing ROM is very fast.

[TroyWilkins]

Originally Posted by Gilbert

Not embarrassed to ask this but can the Amiga CD32 stream in data from CD while it's playing games - using the Akiko chip?

If so I figure you could really use a lot of animation data in the game - extra enemies and animation frames that you stream in just before they appear. This could make more arcade perfect ports possible.

I see jotd has already responded to this, but I wanted to add to the response.

I think the biggest issue would be the seek times reading from a CD, and as mentioned, the data rate isn't particularly fast either. I can't recall the exact average seek time for the double-speed CD-ROM in the CD32, but on fast CD-ROM drives it can be measured in 10ths of a second.

That does make me wonder, is that the way the "video" shown in the main window of the CD32 game "Microcosm" was loaded? Does anyone know? That would have made sense, as that could be streamed without the seek times or data rate being an issue?