Hyperion Entertainment Message Boards

Hi Folks! This is an update to this thread.

I've installed a compatible 15K SCSI Drive (a Maxtor 36GB U320 off _bay for about 11 salad leaves US) and it is working fine; there were some issues with the U160 to U320 communication with random "block errors," but they went away when I replaced the 18GB Atlas V drive with the 36GB one. No I can't use both, my Amy is filled with: floppy (still a requirement), CD/DVD-R/W, SCSI card reader (more useful in OS3.9), the 160 GB SATA drive hanging off my sii3114ide device, and the "new" drive. Obvious changes (speed increases) to WorkBench, but may be due to larger on-board cache. SWAP speed seems about the same. On a lark, I tried a SSD via 68-pin SCSI->ACARD SCSI_IDE->IDE-to-SATA-> SATA SSD, and the speed was actually slower. Probably a lot of overhead in all the little electronic gizmos. But this (the 36GB U320 15K), as I figure it, is the fastest route for a swap partition given the nature of the present classic hardware.

With a few tweaks along the way, I can get in the mid-70 MB range for memory left behind after OS 4.1 loads -- leaving room for a nice display. As a side note, I see a lot of folks upping their program stacks for reasons of compatibility vs. not crashing. The stack is not memory used by the program for executing instructions or data, it is an area of memory set aside to keep track of "the stack;" the area of memory where addresses are stored when a program calls a subroutine. The main program keeps pointers to the addresses so that when a return from subroutine instruction occurs, the program knows where to go. Something like, "I'm in the main program and I need to call a subroutine, I push my current address on the stack and jump to the subroutine; I need to end the subroutine and return to the main program, so I pull that address off the stack. If you use a lot of subroutines, use a larger stack, i.e., if you are the programmer set an appropriate stack. If you are the end user, don't fiddle. If you use recursive programming, then you need to run a stack checker to prevent you from "popping" your stack and ending up lost in space; recursive routine call themselves again-and-again. You could use a stack checker with every program, and just bebop up an error like, "Sorry Dude, no RAM left for your stack!" As I recall, Turbo Pascal did this.

I'm not a UAE user (why emulate hardware on a classic machine that already has it), but some older (KS 1.2/1.3) programs will run on it without degrading your system to ground zero. I've found that WHDLoad works better under older OS's. Because of the SCSI CF card read/writer, I have set up CF cards with just OS 3.1, 3.5 and 3.9; I just slip in the OS I want and I'm right there. I've only WHDLoad'ed my own original disks and found a few of them just crash regardless; and some just suck, I mean don't stand up to the interest they used to hold. I am not much of a gamer, but the OS 4.1 version of the Quake engine does a great job with that program. Sorry to get off thread. And if the Amiga uses its stack differently than the rest of the world, please help out my poor brain cells.

Dan

danbeaver wrote:The stack is not memory used by the program for executing instructions or data, it is an area of memory set aside to keep track of "the stack;" the area of memory where addresses are stored when a program calls a subroutine.

This is not correct - or at least far from the whole truth. Apart from return addresses, the stack is also used for allocating local variables for functions called (which incidentally is what makes recursion possible), and I believe also for saving register contents when switching tasks. The latter is not too space-consuming, but if lots of local data is used, the stack can quickly grow very large indeed. A way to avoid this can be to allocate the required data space dynamically and only store pointers to it as local variables.

And if the Amiga uses its stack differently than the rest of the world, please help out my poor brain cells.

This is nothing special for AmigaOS, it is - to the best of my knowledge - the usual way in most OSs and programming languages.

Best regards,

Niels

Thanks Neils!

My programming skills are about 30 years out of date, so you are, I'm sure correct. Aside from local variables and data storage set up before starting the program, we did use the stack to store register contents so everything would be back to "status" before resuming the main program; yet there are only a set number of words/long words used, and the end user has no idea of the programmers design on the whole. My point was that arbitrarily increasing, by let's say, doubling the stack because it makes one feel "warm-and-fuzzy" just allocates memory that does not help function. Or is that the wrong assumption?

Dan

danbeaver wrote:My point was that arbitrarily increasing, by let's say, doubling the stack because it makes one feel "warm-and-fuzzy" just allocates memory that does not help function. Or is that the wrong assumption?

Partly.

Of course it is not a good idea to "arbitrarily" increase stack settings for no good reason. But quite often it is actually the correct remedy for a problem.

When a program gives you the Grim Reaper, you are usually told whether the stack ran over (the protection area was damaged or something, don't remember the exact wording right now). You can also find your crashed process in the list of processes in the crash log you save, or in the main Grim Reaper window, and check whether the stack is used up or close to being used up.

If that is the case, it makes good sense to increase the stack setting in your icon or shell.

Best regards,

Niels

OK, thanks for that clarification! I appreciate your help.

Dan

As an aside, I was asked off-thread to show a "minimal" kernel built, so here it is:
I removed all comments to speed loading and simplify parsing, at least that was my thought process.

Update: put an Atlas 36GB 15k U320 HDD (80-pin) in my back up A4000T and it went very well, funny it cost less than the 18GB U160 Atlas (Maxtor) it replaced, and while I was at it got a new 400W AT power supply for only 30 US salad leaves.

The backup Amy lacks USB under OS 4.1; I hope some clever EE type comes up with another Deneb. I had a thought that the fast serial nature of USB might merge with the inexpensive SATA controller chip; both are serial and the SATA supports PIO.
Or perhaps FPGA solution.

As a note, if you "read" the boot loader file, you find pubmem option which doesn't seem to do anything; with playing around, I believe when you set it to a value (pubmem=10M) the system reserves 10 Megabytes of RAM for "public access" in which case this 10 MB cannot be swapped out the virtual memory. I found that if l set it to 60M' then large programs failed to load. This also brings up the issue that a program has to fully fit into available ram first before either instruction code (guessing from my PDP 11/60 experience) or data bytes, BEFORE it can be swapped out. The DEC PDP would swap the program and it's data all at once, but this is not necessary if the data is not being accessed or a sub routine is not being used; I'm not sure how OS 4.1 does it, but a flag could be set for blocks of code or data to tell the OS that this is not in use much and it's ok to put it swappable memory pool.

You guys have any thoughts on the matter?

Dan

Hey Guys!

Found a few things out this past week; I have played the original Dune Nukem 3D in the 90's but don't know where the disks are, but fell across "theoldcomputer.com" web site which after registering gives you access to a bunch of older programs (some from platforms/computers I've never heard of). In addition to Amiga work applications and games, it has old DOS versions of Quake, Doom and Duke Nukem -- Atomic edition. Unzipped it and tried to use the OS 4.1 "wrapper" from Os4depot which of course ran under version 4.0 but not 4.1. Tried the 68k version with compatability black listed and, Boom! Works like a charm. Also, after reading a thread, installed the RTG_Master library system with the OS 4.1 fix; it is said to stabilize RTG issues with some programs. Certainly I believe these findings have resolved some compatability problems. My Ami has been purring along happy as a kitten.

Off topic I went about putting together a Mac system to compare MorphOS 3.1 to Amiga OS along with registering the MorphOS and found it more like a Mac than an Amiga. In fact it is setup as a dual boot system and in my opinion the OS X 10.4 is better than the MorphOS. If you want to do Amiga stuff, the Mac with E-UAE & Hi-Toro is more compatable than Morph. Compared to a real Amiga, especially OS 4.1, I go with the Classic Amiga hands down.

There are some new posts here to look at about a flaw in the CD for OS 4.1 and, as always, SCSI issues. I put in my 2 cents but like everything, it is just my opinion based on my experience. In statistics that is a "'N' of 1 error." Or assuming that because it works that way in only one instance, the rest of the world works that way.

Mark Twain said, "There are liars, there are damn liars, and then there are statistitians."

P.S., Found this http://eab.abime.net/showthread.php?t=65087
It concerns a 256 MegaByte ram expansion for A3000/A4000(T)'s called BigRamPlus for 99.Euros (Individual Computers). Likely access is too slow for use as system ram, but a good swap partition.

Quick note: I installed Hyperion's Quake 2 on my Ami and again it crashed under OS 3.9; with help from Amigakit and update for running under OS 4.1, it works pretty well in 4.1, it just needs tweaking to get the frame rate up.

Found the Elbox pci.library version 10.0 that has been discussed on this forum as an attempt to be compatable with OS 4.1, and installed it the kernel with it showing up in the loaded libraries. It is supposed to let less compatable Radeon cards function in 4.1; can't say it did or didn't, as mine was working pretty well already. It does not inable either the Spider II card nor the SB128 card. What it did do was disable my SATA hard drive on my sii3114ide controller; Media Toolbox said the device had no drives attached. I removed the library and decided to use it under OS 3.9 to evaluate it.

Folks, a new, small version of the audio filter switch software just showed up on Aminet and it works fine in OS 4.1 -- I had all but forgotten about this, but I had AmigaAmp playing some of my mp3's when I kicked it in; all of a sudden crisp high notes filled the room like sunshine spilling into a darkened room and even my little speakers on my 32" screen kicked some serious tuchus. I installed in my startup-sequence to make sure the filter was off