I got 2.0 ROMS! Yeah!
26 messages in this thread
For those keeping score, I am the first person in Austin to have the 2.0
ROMS installed. I happened to be in the store buying a new 2000 for work
when UPS showed up with 2 ROM kits. I promptly took one. 🙂 Seem to work
well, so far!
Loyd
Steve;
I would want to 'bust your bubble' but I doubt that you are 'the first
person…' since there are probably developers that have had one installed
for quite a few months. Nevertheless, congrats!
-bill/ARS KB7LX
Developers aren't people! Especially this crowd around here! <looks
nervously about for a ProWrite hit squad>
Loyd
I don't keep score. Don't know (or care) if I am first in Denver. But I
do have the 2.04 ROMS installed. Bought them Friday afternoon, the 1st of
November, and installed today. Interesting effort, leaving lots of things
in place and moving the 2.04 OS into place. Went pretty well, and for
myself I commend CBM on the installation procedure(s). I am looking for
things to delete and clean out… things like on old undelete program that
is useless now (whether or not it works under 2.04!) Finally got rid of
TextCraft. I suspect strongly that it will not work under 2.0 and I'm
really using Prowrite anyway.
Thanks Commodore! I've waited a year and a half for 2.0. BTW – Where's
the manual divider for the AREXX section?
To any of you that know which end of a screw driver is which, the ROM
installation is really quite simple. If you're faint of heart have your
dealer install the ROM. If your Amiga is still under warranty, have your
dealer install the ROM. Otherwise, save yourself a few bucks and do it
yourself. The ROM is a simple DIP, and quite a bit easier to install than
the AGNUS chip. It took me about an hour and a half (I read the "Getting
Started" booklet twice) to get to the point of booting a "functioning" 2.0
Workbench. It ain't completely done, but it is getting there.
I was concerned that 2.0 might be visibly slower than 1.3 on my A2000HD.
As far as I can tell it is not slower, and possibly a bit faster. Gawd,
there are quite a few new options in screen and window management.
– Nelson …
– via Whap!
Nelson,
BTW the ARexx docs supplied with the release set is almost the same
as the OLD ARexx manual and doesn't include any of the updates through Ver.
1.15! If you aren't an old ARexx user, then there's a lot of enhancements
that ARexx has that aren't documented. I also noted that the new docs
don't give any info about Enforcer (like when do you use it and why and for
what.) Although the new docs are large there seems to be stuff missing.
No discussion about using the scalable fonts, can they be used in
wordprocessors, how are they used, etc. I downloaded a nice PD commodity,
NewAF, which makes them "available" to the system, but they don't do
anything special in ProWrite, still jaggy output. I'm sort of disappointed
in these missing items since I'm not a developer and have no idea how to
fully utilize some of the less obvious features of 2.0. The OS is super,
nevertheless. I'm impressed by how much more versatile and powerful it is
than 1.3, but "I want to know MORE!" I'm puzzled by the fact that when I
change the display method for windows to View by Name then move the window,
snapshot it, and next time it opens it's back in the same old place. Some
of them won't even hold the view mode, going back to icon display. Wish
the docs talked about this sort of stuff, cause nothing I do seems to work.
The changes aren't saved to disk and not disk activity occurs nor does a
wait pointer come up when I snapshot. This works sometimes and sometimes
not, why?
Steven,
Re: Enforcer. If you have no idea when you _might_ want to use it, you
DO NOT want to use it. It is a debugging tool for developers (and _I
think_ only runs on machines with MMUs).
Vic,
Well, it definitely wants an MMU, which I have, but I still don't
know what it's for. One mention in the docs is to use it to run the
Bridgeboard on 68020/030/040 machines instead of disabling the data cache
with setcpu. However, it didn't do what it was supposed to do, so I had to
use setcpu anyway. Oh well! Of more immediate interest is why I can't
snapshot my windows and have them stay snapshotted. Seems that any effort
to snapshot window position and size doesn't work, other than the main
window. I don't know why this is and no mention of such a problem is
mentioned in the docs. Also no mention of using Fountain on scalable
fonts, although that one is pretty easy to figure out.
Steve,
Humm…I'm not sure what doc file you're talking about on Enforcer
and the BB…but my guess would be not to run Enforcer while you're using a
BB since the Janus software takes all kinds of Enforcer hits…and you'd
quickly run out of paper on your printer!
Don
Don,
There is a "prescribed usage" for using Enforcer with the Bridgeboard
with a 68030 system. The problem is that, because of the dual-ported memory
used by the Janus software, the Data Cache of the '030 will cause a
problem. One way around that problem is to use either SetCPU or the 2.0
CPU command to turn off the Data Cache. Unfortunately, this is a global
solution that will aversely affect other software. Using Enforcer with the
command-line option of "QUIET" will allow Enforcer to set up the MMU table
so that the dual-ported memory space is not cached, while allowing the Data
Cache to be used for the rest of the memory space. This solves the Janus
"problem", while not aversely affecting the rest of the system. Running
"enforcer quiet" will prevent it from reporting problems, but install
itself in an "end-user" configuration to work-around this problem.
Hope this makes sense….
…BobR
BobR, Enforcer appears not to work with my PP&G 040 board. I have not had
a problem with my XT BB, even though the "Getting Started" book mentions
running enforcer or turning of the Data Cache. Also, were is ENFORCER
documented in the new 2.04 manual?? I looked in the table of contents, the
index, etc and could find NO mention of it. Thanks,
Norm,
The 040's MMU isn't compatible with the 030's. Enforcer doesn't work with
the 040.
The good news is that you don't need Enforcer to use the BB with an 040
card. The 68040.library takes care of not caching the BB.
…Denny Atkin
Denny,
Thanks for the quick reply :). I was wondering why I would not work.
Norm
The 68040 MMU (Memory Management Unit) is radically different to the degree
that I will be supprised if there ever is an enforcer program for it.
Enforcer requires a MMU. You need to protect and detect accesses to certain
memory areas and only a MMU makes that possible.
To sum up the problems with the 040 MMU (there are at least four): The
first is MMU page size. The 030 can protect an area as small as 256 bytes.
The 040 is limited to an area of either 4K or 8K. A 1K area is needed for
enforcer to protect the exception vector table. If I create a 4K entry, you
need to trap the access, determine if the write is to the exception table
or to the legimate portion of chip ram, rewrite the MMU tables, execute the
write while in Supervisor mode, rewrite the MMU tables, all while disabling
interrupts. Fun.
Number two is that enforcer/mungwall keeps track of memory you've allocated
and print out anytime you are accessing an area you aren't supposed to. The
4K granularity of the MMU means that 4K areas of RAM will be allocated (to
prevent another task from allocating that same space) for as little as an 8
byte allocation by your program.
Number three is that caching can't be controlled separately from the MMU
address translation tables (ATCs). There is a cache on/off bit which
affects both caches in the ATC tables for each page entry. The 030 MMU
could create a separate set of tables which could control the data cache
separately from the instruction cache on a page by page boundary.
Number four is the ATC table search tree is fixed at three levels.
This means a miss in the ATC requires three memory accesses to find
the proper translation for an individual 4K or 8K page. There are 128
table entries in the internal MMU cache, (64 for instruction
accesses, 64 for data) which helps a lot. The 030 only had 22. The
030 had the ability to create a tree with one to five levels. A
branch could be effectively pruned to one level for a table search,
covering a much larger area and is much faster. The 040 can only
prune the tree for invalid pages, which generate an illegal address
exception (crash). The missing feature is called early page
termination. The lack of early page termination really hurts the
overall performance capability of the MMU. The dual 4K caches
(instruction & data) are the only saving grace here.
Number five (see, I knew I could come up with more than four!) is when the
MMU is disabled, all memory is set cache enabled in writethru
(nonserialized) mode. This is somewhat safe as the caches are turned off at
reset/power-up, but in another OS which might turn on the cache too early,
boom! Motorola should have been a little conservative and set the default
mode to non-cachable, serialized access mode.
Because the MMU is so different, the encoding of the opcodes were all
changed to force an exception. This is good as it will do less damage for a
system to go dead when 030 MMU instructions are encountered than to go on
half working, perhaps doing real damage to hard drives, etc.
The saving grace is that the 040 has four special MMU bypass registers
called Transparent Translation registers, two for each cache. When these
are enabled, a memory area is not translated and the logical address passes
through to physical addresses within a clock cycle. Careful programming of
these registers gives some rudimentary control of independantly turning the
caches on or off relative to some memory address ranges. You need at least
four of each to properly map the A3000 memory map, including the ZorroIII
space (but there are only two). The PP&S CPU040 program just sets/resets
the cache enable bits of these registers. A potential problem is that for
A3000 users, the PP&S default MMU setup may not work with non-RAM (i.e.
I/O) ZorroIII cards since they turn on caching in the ZorroIII area. Of
course ZorroIII I/O cards are real popular and plentiful right now!
-Greg
– via Whap!
Don,
There is a small Getting Started booklet that comes with the
Enhancer kit. It provides info on running the BB under 2.04 with a
68020/030/040 accelerator. It specifically states that in order to use
Janus 2.0 you must either: 1) run Enforcer QUIET or SetCPU cache nodata
nofastrom. However, I found that running Enforcer QUIET didn't work,
although the second alternative worked fine. The booklet also stated that
Janus 2.1 would be released soon and would be fully compatible with the new
OS and accelerator processors. So that should inform the world about the
query. I was particularly interested in what Enforcer was for, other than
the obvious.
Steve,
Interesting…I've got an A2620 in my A2000 (I guess that means
I've really got an A2500/20 now) and a BB and run the disk based 2.04 and
have 0 problems with the BB (don't run enforcer most of the time).
I suppose that's because the '020 doesn't have a data cache…on an
instruction cache.
Don
Don,
Yes, that's probably the case. I just replaced my 020 card with
the 030 card. I never had any BB problems with the 020 card, either. Now
I know why!
If you are using enforcer to make a bridgecard work on an A3000, you use
the enforcer quiet option, and make sure you put the enforcer call *before*
the binddrivers command. enforcer and setcpu are not compatible. (I
believe CPU and enforcer are, though). enforcer is not needed on an 020
card, and probably isn't needed on most 020 cards (no data cache 🙂 ).
andy
Andy,
Well, that's more info than CBM provided. The docs only stated
that you must run Enforcer QUIET or SetCPU cache nodata nofastrom in order
to get the BB to work on 020/030/040 cards. I found that Enforcer QUIET
didn't work, but I hadn't placed it before BindDrivers, which may explain
why it didn't fix the BB problem. I did find that the second alternative
worked just fine regardless of when it appeared, so it's easier to po put
into my ARexx script to control booting the BB. The docs also said that
Janus 2.1 will be out in the near future and would be fully compatible.
The problem is that you lose performance if you turn the datacache off.
enforcer quiet allows you to have the cache on and still use the bridgecard
by using the MMU to map out the bridgecard from the cache point of view.
andy
Andy,
What's the correct sequence of commands? I normally run SetCPU
right at the beginning of the startup-sequence, but Enforcer doesn't much
like it. I've been told that Enforcer must run before BindDrivers, so is
the correct sequence to disable what I've set with SetCPU, then run
Enforcer, followed by SetCPU to turn on the instruction cache, then run
BindDrivers? Also, will the BB run if I have ROM mapped into 32-bit RAM?
SetCPU and Enforcer don't get along; Setcpu was written before Bryce
developed the convention for swapping out MMU tables. You might try CPU
instead. enforcer should be run first. Then binddrivers. Then use CPU.
Note: instruction cache is on by default. data cache is turned on by
setpatch. You only need to use the CPU command to turn on burst, or for
the fastrom option. (the current version of CPU doesn't allow the use of
fastrom when the mmu is in use by enforcer either, unfortunately)
andy
Andy,
I just picked up a book at B. Daltons on 2.0 and there was
your name above a quote. I didn't realize you are CBM's 2.0 Man! Your
just the expert I should talk with, huh? OK, I understand what you're
telling me. Since I'm mapping ROM into fast memory, then I guess I have to
use SetCPU. However, I noted that when I turned the data cache and fastrom
off with SetCPU, then ran Enforcer quiet (before binddrivers) the BB didn't
work. I'll change my startup and try using Enforcer only and leave burst
mode off and fastrom off and see how the BB performs. On some other
matters, I noted that the docs don't provide any info on Fountain, although
not much is needed to figure it out, some users won't even realize its
existence. I used Fountain to get all my Adobe fonts into the Fonts:
directory and create the .font and .otag files. I then tried a PD program,
NewAF, which is a commodity that forces AvailFonts() to cache the scalable
fonts so my WP programs would access them. Is there some other way to
accomplish this? Nothing in the docs deals with the use of the scalable
fonts other than that they can be used for onscreen usage. Do I need to
create normal font files for them to get the screen bitmap fonts, or isn't
that necessary with the scalable fonts? I also learned that you cannot
snapshot window sizes and positions when you use the View Name mode of file
display. Snapshotting only seems to work when View Icon mode is used. I
guess this is a "missing feature", but I'd like to suggest that it should
be possible to shapshot regardless of view mode. I spent almost two hours
trying to figure out why I couldn't get the snapshots to "take". I'd also
like to note that the ARexx docs are OLD. They are version 1.0 docs and
don't document the new functions added thru version 1.15. Not that I'm
complaining, Andy! Release 2.0 is truly a marvel relative to 1.3 and I
agree with the quote of you saying that "once you try 2.0 you'll never want
to go back to 1.3." It's a major step forward, but the documentation could
go further.
Andy,
Speaking of the BB and 2.04…. Installation of 2.04 was easy on my
A2000HD but I have two snags. 1. Cannot drag the PC window when border is
hidden. 2. Running Timeserv crashes the machine. Neither is a huge
problem. Am I the only one who has a problem with Timeserv?
….Mark 74335,1677
1. Correct. The drag anywhere code was kind of 'special'. I don't
remember if I kludged it back into the 2.1 bridgecard software release. 2.
I believe that's fixed in the 2.1 version of the janus libraries.
Scott found some interesting problems with services.
andy (nope, I don't know when they will release it;
I'm in CDTV land now)
Scott had told me just a tad, but he seemed fascinated by some of the
'features' in the existing Janus software. I think we've all been
downright astonished by some (my current favorite is trying to use amouse
with Prodigy, where the mouse and actual pointer go in very different
directions).
Ron
Andy,
At least someone has noticed the BB problems. None seem too serious.
Hopefully Janus 2.1 will arrive soon. My use of the BB will wane when my
business gets a new UNIX system installed and I can use a any old term
program instead of a proprietary one that runs only on a PeeCee.
Even though you are now in CDTV land I hope you realize how your new
presence here is appreciated. Solid, straight answers from someone who was
directly responsible for much of 2.04 are very valuable. I hope you are
enjoying the interaction on CI$ as much as we are.
….Mark 74335,1677