In theory it should be possible, but I think there might be DMA issues from the Zorro-III bus not being able to access the RAM on the local PCI connector. Such a limitation wouldn't have mattered for a CyberVision card as nothing other than the CPU would want to write to it and it didn't need access to anything other than the accelerator, but if system-wide fast RAM is available there, it could be allocated for DMA by any other device.

@ChrisH

Yep, that's kinda what I was saying (though not as clearly). Support for drives that don't 100% follow the mass storage rules is the key here - bigger systems have better tolerance, smaller systems don't.

I think he means "here" as in "in this situation" rather than providing a link, since he's talking about BackUp, which I linked to further up.

It's a shame that drive doesn't work with OS4. I find so many drives don't work with niche systems - I've got drives that don't work on OS4 but work on MOS, drives that work on OS4 but not on MOS, and some that work on both but not on my Blu-Ray player, and more still that don't work with another media player box. Basically it seems that only the main systems (windows, Mac and Linux) are likely to support most drives, once you move away from them to anything else it's less certain.

Are you using USB 2.0 or 1.1? Some drives might not support 1.1, even though they probably should.

I don't know if they're interested in updating the USB stack, but it would do no harm to submit a bug report with a USB debug dump or similar.

I use BackUp on my Amigas to sync between drives including network drives mounted with SMBFS. It works well, only copying files that have a newer timestamp than the destination. It can also optionally delete files at the destination that no longer exist at the source. It's 68k only, but works fine for me on OS 4.1. Well worth a look! http://www.onyxsoft.se/backup.html

Sometimes using a printer over CUPS like that isn't really doable, for example I need my non-Postscript printer connected to my Windows machine in order to use the carefully controlled colour management workflow I have set up. I guess I could unplug it and reconnect it every time I want to print something from the Amiga but it's hardly convenient. Under XP I could set up a virtual PostScript printer under Windows and share that for the Amiga to use, but that same method doesn't work under Windows 7.

Besides, when I did have it working under XP, it was only of limited use since Wordworth wouldn't print to it without substituting all the fonts for terrible ones, and printing raw text would cut characters off, regardless of the margin settings.

I'm sure some people have managed to get a working setup along the lines of what I'm trying to do, but the time and effort I've already poured into it means it's not worth bothering with. Perhaps some day we'll have a refresh of our printing system, but until then all my printing has to happen under Windows or Linux.

Many 3D printers (at least the ones we have in work) also accept GCode on USB drives or SD cards, so "all" you need is the software for slicing up the model and generating the GCode and you should be good to go. There are open source solutions but I've no idea what sort of dependencies they have. Hardware-wise though there's no problem...

@Kamelito

If it's possible to do it, it should be included in the SDK. Just because it's unlikely to be used is no excuse for it not to be documented. OS4 can use the classic chipset so the methods for doing so should be documented, just in case someone for whatever reason wants to do that.

I don't see how it's any different from something like fpga.resource for example. I can't use it on my A1-XE G4, and yet it's included in the SDK. Should that be removed? Can you name any current application that uses it?

OS 4.x also runs on classics you know...

I did suggest talking to Elbox about it as well, they use precision cut PCI-specification connectors for their Mediator adaptor boards, and the job they do is so good that I couldn't tell it was two cut-n-shut connectors until I desoldered one. Obviously it's not ideal, but my Mediator's been happily working away for over a decade with such a connector so it's a definite path that could be followed.

@mritter0

This is the one I use for shared SMB drives/volumes:



Is there something else you're looking for?

Hi all,
I've just uploaded an update for InstallerGen, my tool for creating Installer scripts using a GUI. This update fixes a few bugs and adds a couple of new features. Changes include:

- Localised pop-up bubble help
- Automatic creation of LhA archives of the relevant files
- Added Spanish translation (thanks AmiSpaTra)
- Fixed bug where custom classes weren't detected on MorphOS if they weren't previously opened
- Fixed some GUI issues with some MUI themes
- Additional checks and warnings during script generation

InstallerGen is tested and works on OS 3.9, 4.1 and MorphOS. It's available on Aminet, or you can grab it here.

Thanks to everyone for the feedback, suggestions and donations!

I think what makes it a little bit confusing regarding the WBPattern prefs is that it may refer to image placement as in "Windows" rather than "Drawers". The windows it's talking about however are the windows under Workbench's control, which are only really ever used to show the contents of drawers.

I've had a look on my MorphOS installation before and couldn't find any specific developer or licencing documentation for SMBFS. It is listed as a "port" however so that would suggest it's based on some other code which may or may not stipulate source code availability.

Having a bit of a search now it seems it might not support SMB2 after all, but at least correctly negotiates SMB1 support when connecting to Windows so shares still work properly, and that's still a massive improvement over what we have. I might send them an email but I won't hold my breath for a helpful response.

@pvanni

Not that I've found. I don't know and it isn't obvious what sort of licence it's under, so it could possibly be a ground-up implementation that has been kept closed source, rather than being based on the open-sourced code of the SMB 1 version. Which is a shame...

@ChrisH

Yeah, that looks like as far as we can get with our current software. I haven't been able to do any more anyway. What we need is an updated smbfs - the MorphOS version supports SMB2 and works fine with Windows 7 shares.

Anyone familiar enough with that sort of programming to do a port? I'd pay good money to see it!

What about merging it with OpenAmiga.org, so that all projects are in one place? They could still be categorised as 3rd party OS components or bounties, and it might help to increase the interest and simplify administration to a point where it's more worthwhile.

Again, sorry to hear about your accident, sounds pretty awful! I've posted a link to this thread on AW.net (and EAB) in case someone there is interested. But it's not just you falling foul of the blacklisting issues there, it happens regularly to me in work and on my mobile too...

Wishing you a speedy recovery my friend!

As an aside, do you really need the backslash key for network shares? Samba and FTP both use forward slashes for their paths and roots - it's only accessing shares from within Windows that I know of that uses backslash for paths.

@BSzili

So it has! I'm sorry about that, I've never come across it before surprisingly. Looking at the documentation now...

Anyway, the OS4 documentation specifically talks about lowlevel.library emulation so it's possible gameport.device isn't supported.

Huno's library mentioned above looks like it's what you need, but I haven't used it myself...

You can use lowlevel.library and that will give you compatibility with 3.1 and above - AmigaInput will emulate lowlevel.library with whatever controller you choose on OS4.

I haven't come across GamePort as an API - it's not part of OS3 AFAIK so I assume it's an alternative to AmigaInput rather than something AmigaInput creates a wrapper around - it might even conflict with AmigaInput if that's the case.