@ZeroG

Quote:

Couldn't figure out how to do this.
Added a tooltype "Control=NOAMIGAAATTR" to L:CrossDosFileSystem's icon.

Also did a mountinfo on "USB0:", which was the device the Sansa was mounting on. And then added a "Control = NOAMIGAAATTR" to the resulting USB0 mountfile, which I put into Devs:DosDrivers/

However, after a cold reboot and plugging in the Sansa, it seemed to then avoid mounting as USB0:, but instead mounted as "USB0.0:"

I tried putting a comment into one of the files in USB0.0:, disconnect reboot, replug the Sansa, and the comment was still there - so I don't think I succeeded in enforcing NOAMIGAAATTR.

Suggestions or requests?

Thanks,

Tom

@ZeroG

Quote:

Under Functionality,
Mass Storage shows
ms ifac 1 (SCSI::BULK_ONLY)
with Information
Type: Interface
Product: SanDisk Sansa Fuze
Vendor: SanDisk
Serial no.: 0301EE170139B6A80000000000000000
Version: a5.dc

Class: Mass Storage
SubClass: 6
Driver: MassStorage Device Task

Under Topology
ohci.usbhcd unit 1
Hub
SanDisk Sansa Fuze
with Information
Type: Function
Product no.: 0x74c3
Vendor no.: 0x0781
Serial no.: 0301EE170139B6A80000000000000000
Version: a5.dc

Class: Multiclass
Subclass: 0
Mode: Interface

@ZeroG

Ah.

Will try that, and send you the USB report.

Thanks.

Tom

And it means that you gotta have something other than an Amiga if you want to use your MP3 player.

At least my Sansa Fuze, though it can be set up to be used in MSC (storage device mode) and should be usable free of Windows support, only leads to frustration if used with OS4.

The Sam recognizes it (usually) on plugging into the USB, and the internal and card storage show up on WB as devices. TuneNet can play off of it fine.
But, try moving downloaded MP3 files onto it and you will be sorry.

Seems to work ok while attached, but after removal the new files are not visible to the Sansa. Some of the old files that were already on the Sansa have disappeared. It is soon reformat-the-Sansa time.

I would blame Sandisk and Windows for monkeying around with FAT32, but doing the same things, via storage device mode, on Linux seems to work like a charm, with no glitches as on the Amiga.

Tom

Quote:

The 6127 is a nice deskjet! On your home network it can server as printer for your Amiga(s), Windows, Linux, and Mac machine.

The network device that replaces PAR: and is used by PRT: is the LPR.device originally written by Olaf Bartel, OS4 version by Stephan Rupprecht.
Very good directions for OS4. Still working fine with every update.

No SMB needed, but no interference with it either.

It resides in OS4Depot at:
http://os4depot.net/index.php?functio ... utility/print/lpr_dev.lha

I've been using the HP_DeskJet 895C (that comes with OS4), but am anxious to try the photosmart driver you mention.

Tom

@Coder

Quote:

So far as I know, it is only possible to put in a link to a picture like so:

@{" Project Window " LINK "ProjWin.jpg/MAIN"}

where the "/MAIN" is required. You can't do much but hit RETRACE after looking at the picture, but it does return then to the page with the button. It should work for anything MultiView can show.

You may be able to show a picture alongside the AG text using an ARexx script and the ONOPEN command.

Let us know if you find a good way.

Quote:

I'm open for suggestions to improve GuideMaker, if it will result in people using it!
Alternatively, I've recently realized that perhaps CubicIDE could be set up as a good AG editor. I am going to order it on the first of the year when there is a promised one day price break.

regards,

Tom

@Atheist
Quote:

These are both compilers for the language Modula-2. The first one generates M68K code, the second generates native PPC code, using "as" from the SDK to assemble, and "ld" to link to an executable.

So far as I know, anyone can download the AOS SDK from Hyperion's site (as soon as it is back up), and installation is easy as double clicking on an icon. After that, you can not worry about it as AgletM2PPC invokes "as" and "ld" for you. Besides, even if you program in Basic you will want to be able to read the latest AOS "AutoDocs" to get a good idea of what the Amiga and Amiga OS4 is and can do.

As for the pros and cons of various languages, it is hard to argue about simple programs; the difficult part of programming that can be help or hindered by the chosen language is how to handle the complexity of a significant program or package, and the amount of difficulty involved in finding bugs, extending features, breaking into reasonably independent modules that can be worked on without the fear of changes introducing problems in other parts of the package. This is where most Basics are very weak, and I believe Modula-2 outshines C and C++.

Building large, reliable, extendible programs is something you can't expect to be able to do without spending a great deal of time and effort learning, considering, and revising.

Modula-2 has a proud Amiga history, as at one point there were 3 or 4 good implementations for AOS2 and AOS3 (at least one of which is now freely downloadable). It is also available for Linux, Mac, and Windows.

Check out my current Aglet Manual at
http://home.ntelos.net/~tbreeden/AgletM2PPC.pdf

and a good site with tutorials and examples
http://www.modula2.org/

and a shareware full textbook on Modula-2.
http://www.csc.twu.ca/rsbook/index.html

@ChrisH
Quote:

Modula-2 is what the Pascal designer, Niklaus Wirth, came out with as the production language to be the successor to Pascal. Since then an ISO Standard has extended it somewhat, without introducing the chaos of C or C++. I don't know much of other modern Pascals, but I suspect they have attempted to do the same thing (while retaining the name everyone recognizes).

regards,

Tom

@freddix

Quote:

Hi,

I did that with my Modula-2 compiler, and also used the assembler to create the ELF object files.

ie, the compiler produces a PPC assembly text file that feeds into
"as". That has worked pretty well. It saved me a whole lot of time trying to get the ELF file format correct, and "as", though the docs can be misleading, is not very balky.

And using "ln" to link the files together is even more time saving. I wrote a little program to gather up the required obj files and libs and create the linker script so that the user does not have to be concerned with the linker settings.

So, I have spent most of the two years or so on generating good PPC code, and still have lots of work to do on the "good" part of it. The ABI is documented pretty well in an older document "Sys V PPC ABI" that you can download from the Internet. Getting that right is not the simplest thing. Actually, I don't thing "as" and "ln" really care if you use that the specified calling sequences and registers, but you will need to if you are going to link to amiga libraries and have the Grim Reaper give you a stack traceback when your programs crash,
if ever :)

regards,

Tom
tmb@virginia.edu