Hopefully I didn't just kill the thread... Athiest?

@Atheist Quote:
Negative thinking does not help you achieve things, nor does under-estimating your abilities. Perhaps you are expecting to work things out instantly, and your failure to do so is leading you conclude that you can't ever do it?

If you changed your mindset, I'm quite sure that you could work out all this & more - it might just take you a LONG while to read, experiment, read some more, more experiments, and so on. Where-as most of us have already done that for *similar* problems (over some years), so we can easily work out how to do that kind of thing again.


Now, maybe you don't have the patience for lots of reading & experimenting, but IMHO that is unavoidable for any programming language *including* AMOS Pro. I should know, because I had the huge tome known as the AMOS Pro manual permanently beside my A1200, and was always referring to it. (This is before I gave-up on AMOS Pro v1.0 being too buggy, especially with floating-point numbers.)

@Chain-Q
I kind of feel that those "Pascal Advantages" are mostly available for E too (with AmigaE/ECX/PortablE) :
* Very clean language.
* No Makefiles. (Only with PortablE, not AmigaE/ECX.)
* E compilers are Fast with a big F. (Applies to AmigaE/ECX, but not yet true about PortablE, as I have not done much optimisation so far.)
* Each unit has it's own identifiers.
* High speed, low memory use. Being a language that is compiled into fast machine code by a modern compiler.
* Great integration with assembler. (Applies to AmigaE/ECX, but not true for PortablE since it has different aims.)
* Object oriented programming
etc

@BillE
8Mbit British "broadband" will be laughed at in many countries, never mind that the average speed is more like 4Mbit

@madmonkey
Ah, I should have said that ASyncWB only causes problems for Workbench file operations. Note that "AutoUpdateWB" may also cause problems with WB.

Perhaps I also have the same problem as you, but I would not know because the write speed has prevented me from testing SMBFS heavily.

@madmonkey
Sounds like you are using AsyncWB. Remove it from the WbStartup folder, then reboot, and you should now be able to copy files using Workbench reliably.

I tried changing Roadshow's MTU (thanks Elwood) and my Router's MTU, but neither helped, even after reboots.

Would be interested to know if anyone else can (or can't) write files (>4KB) to Samba on OS4.1 from Windows XP with Service Pack 3 (SP3).

@daveyw
Unless you use a *modern* codec like XviD or DivX (or MPEG4), I don't think you should expect much of a file reduction, since DVD videos are already MPEG compressed (albeit not fantastically).

@Daedalus
Tried changing Windows MTU with a registry hack (I assume it worked), but it didn't help Samba. I can't see any MTU setting for Roadshow. Not yet tried MTU setting on router.

@MamePPCA1
1. Is your OS4.1 a clean install? (First question for any problems!)
2. I suggest disconnecting the joystick/joypad, then booting OS4.1, then reconnecting it, before trying AmigaInput.
3. Also see what happens to AmigaInput without anything connected.

@TiredOfLife
OK, but it's a software problem then. AmigaInput and Lowlevel emulation is a bit buggy, although a lot better than I hear it was in OS4.0.

@Slayer
Dunno about MAME-specific joysticks, but the Competition Pro USB (as sold by AmigaKit) works well with OS4.1 on the Sam440, and it has four buttons.

@fishy_fis
Don't get your hopes up about AB3D2 with the RTG patch - it never worked well on my Amithlon system, so I suspect it has little chance of working on OS4.

@TiredOfLife
Since my Comp Pro USB works on OS4.1, you can easily test if your joystick is broken or not (see below). Your problem also sounds like you may not have calibrated it:

1. Plug in joystick, and wait for USB recognition message.
2. Start Sys:Prefs/AmigaInput .
3. Click on "USB" in "Available interfaces". Ensure the Comp Pro is the highlighted device/driver.
4. Click "Test/Calibrate unit" button.
5. In the new window that opens, click the "Calibrate" button.
6. Now wiggle the joystick in different directions - the cross-hair in the box should move in the same direction. Do not press fire yet.
7. Now follow the text instructions at the top of the window to calibrate the joystick.
8. You can also press different fire buttons, to see if they are registered too.
9. Now save your calibration settings


EDIT: It may also help if you plug the joystick into USB *after* OS4 has booted, so that you see the connection pop-up.

@Skov
AB3D is very demanding, because it is a 3D game, and so needs lots of CPU power. A basic A1200 did not run it very well, you really needed a 25MHz 030, and I doubt UAE can emulate that speed without JIT.

I have to wish everyone else was not posting on this thread, because then I feel that Athiest could have focused on what I was saying, rather than getting distracted by lots of other issues (that are generally more complex than I was trying to explain), and that would surely have helped.

As it is, I can only suggest that Athiest re-reads just my posts in this thread, perhaps copying & pasting them into a text file for easy reading.

edit: @Allanon, everyone is just as entitled to post here as me, and I do not for one minute expect others to stop posting. My wish was about the past, not the future.

@Atheist Quote:
Actually you don't need access to everything at once. It is only because you have not split-up your program in to procedures the right way (or at all). And that is at least partly because you are using a limited programming language like AMOS. Of course you don't realise it is limiting, because you have never experienced anything different.

If your game (?) was written using a better programming language, you could avoid having ANY global variables. Loads of global variables simply mean that anything can affect anything else, and that means it will quickly get difficult to change how anything works - not to mention meaning you tend to need to know how everything works at the same time.

@athiest
It does seem that you have some sort of "mental block" regarding programming, where if it is different from AMOS then your brain goes "I can't deal with that" & doesn't even TRY to understand it.

Well, unfortunately that is your problem (not the rest of the world's), and I don't see how I can help any further. Except to re-iterate my suggestion of Hollywood. Or perhaps switch to (Dark) Basic programming on a Windows PC.

(Of course, if you actually made any progress due to my previous post, then I would be happy to try to continue helping you. But currently I see *zero* progress on your part. Feel free to re-read my previous posts at your leisure, and PM me if you think you might have understood a little of what I have been trying to explain.)

@Atheist Quote:
It's the same reason the sky is blue - IT'S JUST THE WAY THINGS ARE, so you have to accept it. I can see why jahc got fed up - and I shall probably follow his lead...

edit: However, if I was being slightly more helpful, I would also say that the brackets are there to tell E that you are calling a procedure. There is nothing between the brackets, because closeWindow does not need or expect any extra information.

Quote:
Please tell me, how is this a lot to expect?:
Plot(159, 99, 2)

The other stuff is to open & close a window - something you didn't need to do in AMOS, because it opened a screen for you whether or not you wanted it!

PROC main()
openWindow(320, 200)

Plot(159, 99, 2)

waitForUserToCloseWindow()
closeWindow()
ENDPROC

Precisely why is this a lot to expect from someone? It has ONE LINE to open a window, ONE LINE to plot a pixel, ONE LINE to wait for the user to click on the close button, and ONE LINE to close the window.

I really don't get your problem. The WHOLE POINT of the "athiest.e" file I created was to HIDE the stuff that you never need to see again. This is how programming languages work - you look-up how to do the hard stuff, then hide it in a procedure (and a file) that you may never look at again.

Not to mention that "athiest.e" file was mostly a copy & past job from Jason Hulances example. It took me a minute at most, and I didn't even need to understand how most of it worked.

@Atheist
I would class a 4,000 line program as being small (edit:or maybe small-medium). By comparison, PortablE is composed of maybe 50,000 lines of code, although probably only 35,000 are specific to PortablE (the rest being general-purpose stuff that I can reuse in other programs).

But still, if you had very few bugs, then your program cannot have been doing anything complicated IMHO. Either that or you are a genius... (I can see jahc fainting already!)

Quote:
This is VERY bad programming practice.... but it is also very common in BASIC programs. Here's a program I wrote in a BASIC-like language a few years ago, which had more globals than I would have liked:
http://freepoc.org/viewapp.php?id=60

And I can tell you now that BASIC was the WRONG language to program it in. However, it still (mostly) worked, it was just a severe pain to write. Doing it in AmigaE would have been much much easier.

P.S. I would appreciate a comment on what I write in post #91.