AmigaOS 4.1 Classic Available To Buy

[Karlos]

128MB Single sided are very rare- I have one in my A1200 at home but we have been unable to source them new recently.

The new 128MB SIMMs we have in stock measure: 108 mm x 29 mm x 8 mm

They are 50ns memory at the moment as well

I already have a pair of 128MB SIMMs already in my BlizzardPPC, but I think they are 60ns. Do you have any bustest / ragemem results for the 50ns parts?

[Karlos]

Sure,  I can run this test today:  what settings do you want me to apply in the BlizzardPPC memory config?

I would suggest that if it works reliably with all the waitstates disabled, then try that. Otherwise I'd suggest testing it set to 60ns mode and in either case, compare it against some other 60ns rated memory.

There's really no rush for this, I was just curious.

[Karlos]

@Nearly-Right

If I were a gambling man (which I'm not, but let's pretend otherwise), I would wager you wouldn't buy OS4.1 for classic if it came with hand-tested-by-Darren-himself-and-guaranteed-compatible expansions and personally installed by Carl Moppet all at no extra charge

First you complain there is no decent information on supported expansions. Then a compiled list is provided. Then you complain it's not "official", which fair enough, it isn't, but the guy providing it has been testing 4.1 classic since day zero, so it is as good as you would get from any of the developers. Then you complain that some of the available information is ambiguous and needs further clarification, which he goes off to try and find out about. No matter what the guy writes or how much he goes out of his way to answer your questions, your posts fall back onto everything being a disgrace, taking too long etc. and for all the overtures to applauding his effort, you just end up back at square one. I'm personally waiting for the Elbox intra-card DMA issue to resurface as soon as you get bored of making Darren run around answering your questions.

Let's be totally open and honest here. You got your fingers burnt with 4.0 classic and there's no way you are going to buy 4.1 classic on principal. I totally get it, it's not as if you are the only person that feels that way. However, for anybody else, 4.1 classic is available, supports more hardware than 4.0 classic did and a growing list of confirmed working expansions exists, officially sanctioned or not, the information is available and improving for anybody contemplating it.

[Karlos]

BTW - Where the A1 benchmarks (as you can see I'm not a patient man)?

It's not really a benchmark unless I can persuade DoomAttack to run a timedemo. Not sure how you do that :-/

[Karlos]

OK, so please explain the acronym 'DSI'

Data Storage Interrupt. In short, an illegal access to a given address (basically an 80000003 guru).

Sometimes these are harmless read accesses (still to be indicative of serious bugs that need fixing) that can be ignored by clicking "ignore DSI errors" when the Grim Reaper pops up.

Bad applications may also generate ISI, when you get the same sort of illegal access made by an instruction fetch. This is usually non recoverable.

The biggest problem I had with the Permedia2 driver at the beginning was fixing DSI bugs that were occurring inside the W3D_LockHardware() call (accesses to NULL and other arbitrary places), since the Grim Reaper can't pop up when the display is locked and my serial port isn't reliable enough to run a debugger over. Mostly a three finger salute then pouring over a dump of the last set of messages to the debug system.

[Karlos]

So what does the acronym 'ISI' stand for?

Take a guess:

Bad applications may also generate ISI, when you get the same sort of illegal access made by an instruction fetch. This is usually non recoverable.

Oh, incidentally:

Like the yellow bordered 'click left mouse to continue' warnings that often related to graphics library or other recoverable errors under 68k.

No, not quite. AmigaOS recoverable alerts (the yellow ones) are usually caused by a sanity check failing, rather than an illegal access to memory. An example would be trying to free memory twice resulting in corruption in the free memory list which is detected by the OS allocation system. Illegal memory accesses are lower level than that. On OS3.x and below, you can usually read from almost any memory location that physically exists without generating a Guru. It's still a bug, it's just that you'd never have known it was there unless as a side effect of reading an unexpected value from that bogus location the application does something weird. Whether or not it is harmless depends on what the consequences of that read are. However, in OS4 such accesses in tend to cause DSI, unless the memory being accessed is explicitly public.

[Karlos]

In both case result is the same, though.

That's true only if you decide to allow the program to continue. On getting a DSI, you might decide instead to generate a crashlog, terminate the process and hound the author for a fix

[Karlos]

So having a robust log service (on serial port/whatever) with proper information is much more reliable.

The information is also written to the debug buffer and by extension the serial port if serial port debugging is enabled regardless of whether or not the Grim Reaper is able to launch.

Without it, debugging the Permedia2 driver would have been extremely difficult, since most of the DSIs that rendered it unusable were happening within a hardware lock and nothing could update the screen let alone open a window on it.

[Karlos]

What's more, rather than say it's unrealistic - all the development time for OS4.x to get so far, 2003 to 2011 - 8 years approximately, has gained us NOTHING NEW in the printer area, which is the truth of the matter. Not even Turboprint 7 has been updated in a good few years.

You could always have a go at porting CUPS

[Karlos]

That's like pointing the finger of blame at me for not updating the OS4.x printing system, when I'd have hoped the OS4.x development team would have been considering/implementing some update to the printing system, seeing as it forms an integral part of any OS.

The whole reason tools like TurboPrint existed in the first place is that historically the built-in AmigaOS printer support was a bit bobbins. Was OS printing support ever a dealbreaker for you previously?

I'll just learn C and C++, etc.

You say that like it would be a bad thing...

[Karlos]

I'd like to be able to program, it's just the learning curve, and I can't just write a printer driver without that programming knowledge, but that also requires specific knowledge of how printer drivers work, and how the hardware works that I would need to support it, no easy task for a beginner.

Fancy having a go yourself?

As it happens, I aready am working on some stuff I want to see improved support for which is likely to keep me occupied for a while.