Release numbers?
19 messages in this thread
I'm looking for a list of the correspondences between the thirty-something
version numbers and the real-world release numbers for AmigaDOS. I've lost
track of which numbers go with which release. For example, there's V36,
V37, V38 – V38 is 2.1, V37 is 2.0? and V36 is 1.3? Is there an even more
detailed list of minor vrelease numbers in both 30-ish and 1.3.2 format
that CBM has published somewhere?
I thought that there was a list of the release numbers in the last set of
devcon notes. Unfortunately, mine have been loaned out at the moment and
can't look them up. Is there something specific you are trying to get at?
Most of the functionality should be better keyed off the presense of
certain libraries (like gadtools…)
John,
Since I've been installing and using every intermediate release I've
forgotten all the various version numbers. I can tell you tho (with some
certainty) that the release version of 2.04 is 37.175 and the release
version of 3.0 is 39.106.
-sja
I'm getting ready to throw this darn machine out the window. Something's
wrong, and I can't stand it. The GVP 040 board on loan to my local dealer
has functioned flawlessly in both a stock A2000 rev 6, and a fully-loaded
Toaster system. I can install InterChange Plus on my machine here without
indicent. Installation proceeds smoothly on the dealer's machines, too –
except on the A4000, when I try to start InterChange itself, either from
the WB or CLI, it sometimes says "Out of memory" on a requester. Two-three
attempts later, it launches fine. I'm running release 2.01 here.
I'm thinking about buying a new A2000, either a complete machine or a new
motherboard. Does CBM dev sales sell motherboards, or am I dreaming? I
want to install from virgin 2.01 or 2.1 disks and slowly restore everything
else. I think that should waste a good day or two, won't it?
John,
On the 4000 and the GVP '040 card make sure that the caches are turned
off before loading your code. If it makes a difference then you probably
have some self modifing code somewhere. (overlays can cause the same sorts
of problems)
Are you actually running 2.01 or 2.1? If 2.01 you really should upgrade
to 2.04 at least.
Dean
DKB Software
I made very few changes to my code, and now it runs on the A4000. There
were a few dusty places in the code that were still passing a "NULL" as the
memory requirements in AllocRemember() calls. I changed them to
MEMF_PUBLIC. Not having an A4000 at my side, I had to make several other
changes at the same time, so I'll never know if that made a difference. I
also made the GetScreenData() changes described in other messages. The "out
of memory" message I saw was from *our* code, not WB. The function that
performed the GetScreenData() was a void function, so it couldn't have been
returning the "out of memory" error, I think it was the AllocRemember().
Which leads me to a more general question looming in my mind. By virtue of
cut-and-paste editing, there's a lot of places in our code that ask for
MEMF_PUBLIC memory for general, private allocations. I should change these
to MEMF_ANY in hope for a future version of the OS that might give MMu
protection of any non-public and non-chip requests. Are there other
considerations I should re-think with the advent of the A4000, in regards
to the MEMF_ flags?
John,
The only thing I can think of is to make sure that any memory
allocations you do have the MEMF_PUBLIC flag set if the block of memory
has any possibility of being passed to to another task to handle. If you
don't then there is a 'possibility' that at some time in the future the
other task won't be able to access that memory block.
Other than that, I'd also strongly suggest you use the available OS
functions to allocate any memory pertaining to graphics if such OS
functions are available. In fact use the OS functions to allocate any OS
structures if possible, even if it requires doing version checks to
determine if the allocation functions exist. (There are a number of new
allocation/initilization functions in 2.04, and even more in 3.0) Using
the OS functions will isolate you from most, if not all, OS and hardware
changes.
Then again, you probably already know all this! <g>
It appears that CBM is starting to accelerate the development of new
OS's and new hardware. Designing according to the 'rules' is going to be
even more important than ever was.
Dean
DKB Software
John,
I would change all MEMF_PUBLIC which isn't _required_ to be to
MEMF_ANY. But then, we've been _assuming_ that MEMF_PUBLIC meant what it
said in the ver 1.0 RKMs (memory which _may_ be referenced by more than
one task or an interrupt routine….by OUR inference—not swapped out).
If you're really running 2.01 you've got a LOT of problems! Get a release
version of the OS (2.04 or 2.1).
RKM:Libraries, Third Edition, page 10 says:
V30 – 1.0
V31 – 1.1 NTSC only
V32 – 1.1 PAL only
V33 – 1.2
V34 – 1.3
V35 – Special kickstart to support A2024 monitor
V36 – 2.0 (old release on A3000)
V37 – 2.04 (ROM release)
As you've said, V38 is 2.1. Presumably V39 is 3.0 but as I haven't
received my 3.0 disks yet, I can't say for sure. (Kindof odd, that – I
ordered 2.1 as part of the same order and got it immediately… I wonder
what's holding up my 3.0 disks… Rather frustrating too, as they have
the autodocs for both 2.1 and 3.0 – there aren't any docs on the 2.1
disks. <sigh>)
–>Steve Bennett
We haven't received 3.0 disks at Syndesis, either, and we're commercial
status.
Our 3.0 disks and docs arrived yesterday (Saturday). I _knew_ there'd be
a good reason to come into the office.
Heh… So did mine. <grin>
–>Steve Bennett
Still waiting for mine. (Sigh)
MikeM:) "Amiga means never having to say your sorry!"