#cache/burst modes
14 messages in this thread
> . . . manv programs and some hardware devices get confused when
> the CPU is using cache memorv and fail to work properlv. For instance.
> Commodore's 386SX Bridgeboard will not run in a svstem using data cache
> memorv. Since the development of Amiga OS 2.X. Commodore has provided
> the CPU command to deal with this situation. . . .
This quote comes from Brad Webb's column THE SHELL GAME in the March
1994 issue of JUMPDISK.
Could someone explain the cache and burst modes of the 68030 (my GVP
G-Force 030 uses it with MMU and 68882)? the philosophy of using these
modes with instructions and/or data? and how they affect the the 386
Bridgeboard in particular (since I have one) and also Autopilot?
TIA in for a mini-tutorial!
Sincerely,
(Mr.) Gayle Lee Fairless
'Perfessor Fearless' from the Rocket City!
via AutoPilot 1.03a
since I also have a GVP and was interested enough to track that
down as well, I can answer your questions.
The 68030 has two on chip caches, each 256 bytes in size, one for
instructions and one for data. Let us assume we did a cold reboot,
and that we have told the CPU that both caches are turned on. The
CPU will attempt to read it's first instruction from a hardwired
location in memory. The first thing the chip does on any memory
access is to look at the cache and see if a previous copy of it is
around. Since we are starting from power-up, nothing is there, so
the CPU reads the instruction from memory. Next, as it is figuring
out what the instruction is, is keeps a copy of it in the cache.
From here on out, things proceed normally with the CPU reading
instructions and data from memory to execute the programs that the OS
or the user has told it to do. In every case, it will check to see
if an instruction or piece of data is in the appropriate cache, and
if it is, use it from there. If not, it will have to go out to
memory and read it from there, which takes longer than if it has that
information on-chip.
If the cache is full when it needs to keep a copy of some
information on-chip, the CPU will figure out what hasn't been used in
a while (using a Least Recently Used algorithm, usually abreviated
LRU) and write over with the new information. This keeps the caches
loaded with the most relevent information since most programs use the
same instructions over and over again (as in loops) and the same data
(as in the address of a string, or a data block, etc). So if a
programmer uses some planning, he can code to make sure that his
program takes advantage of this. Some do (Khalid).
Now, related to the caches is a particular memory access technique
called BURST mode. When you have a cache miss, i.e. it couldn't find
the data or instruction in the cache, a smart chip designer will
realize that it is quite often the case that not only will the CPU be
using the instruction or data asked for, but the next few words after
that, in many cases. The optimum amount of additional information to
grab is subject to debate, and depends on a _lot_ of factors, but in
the case of the 68030 it was decided that if the BURST mode is turned
on, and memory can support it, the CPU will not only grab one 32 bit
word, but the next three as well, i.e. 16 bytes. Since the memory is
set up to do this very quickly, i.e. it only takes four clock cycles
to grab 16 bytes in BURST mode instead of 8 clock cycles to grab them
individually, you usually get a measurable payback from turning this
mode on.
Now, there is a problem with certain boards and the way caches
work. The 68030 assumes that the information in the cache reflects
the information out in memory. If a chip, not the CPU, out there in
the system changes the contents of a memory location and the CPU
isn't aware that it needs to go out there and reload the change, you
can get some pretty strange things happening. In the case of our
GVP's, the Chip memory is specifically locked out from being cached,
since the custom chips can change the contents of these locations
with the CPU being none the wiser.
This isn't true of the Bridgeboard, or similiar products, that live
in the Fast RAM address space and can merrily change the contents of
the memory presented to the CPU at will. So it is very easy for the
CPU to have one number stored in the cache as being at a particular
location on the BB, while the BB has changed that value. Programs
blow up when the information has been invalidated right out from
under their feet.
The only way around this, short of having a BB jumper on the GVP
accelerator, is to turn off the data cache so that the CPU never ever
makes that bad assumption. Personally, I'd rather have a jumper to
block out caching that 2 MB of system memory, but I'm not the
engineer at GVP.
As for how they affect AutoPilot, what they will do is speed up
the programs execution provided that small, tight loops and repeated
data accesses to the same data are used. This occurs naturally
enough, so some speed up is inevitable. If Steve has optimized the
program, the speed up can become more dramatic in many cases. I
don't know enough about the internals of AP to say one way or the
other, nor have I done any testing.
Hopefully, I haven't made any egregious mistakes in this
explanation.
"You do trust me, don't you? Of course you do."
— "To Play the King" (BBC)
Brian,
Thanks for the tutorial! I have already set CPU NODATACACHE in my
user-startup to keep the BB from locking up. As you may already know from
my message on AmigaUser, now I'm trying to figure out a 1701(C) Controller
#0 Error.
Oh, well Onwards! and Upwards?
It isn't necessary to turn the cache off in order to get the
BB to work. A better solution is to RUN >NIL: <NIL: Enforcer QUIET.
Enforcer was included with the 2.1 Janus software. Or you can
download the latest version of Enforcer from the CIS data libs.
Enforcer allows you to keep the data cache turned on, which will
significantly speed up many Amiga programs, but enables the BB to
operate correctly. In fact the BB will actually work fine with the
data cache turned on even if Enforcer isn't running, but you will
find that the Janus software such as AMOUSE, ATIME, AREAD, and AWRITE
will not work. You also won't be able to use JLINKed files unless
Enforcer is running or the data cache is turned off.
Using Enforcer is the preferred method and is even recommended
in the CBM supplied info sheet that came with the Janus 2.1 upgrade.
You can run Enforcer in your startup before you run Binddrivers. You
can also write a script or AREXX program which does the same thing
but only before you get ready to boot up the BB. The important thing
to remember is that you must run Enforcer BEFORE you execute
Binddrivers.
Steven,
I have Enforcer running. It was downloaded from here. I've also
downloaded an even later version but haven't put in yet.
The DATA CACHE was turned off because the keyboard input to the
bridgeboard (BB) was freezing. Now both Enforcer is running, and
DATACACHE is off.
Presently, I'm running with 2 monitors. The C= 1084S is showing the
Amiga video, and the small NEC 13' multisync (JC-1401P3A) is taking analog
off the VGA port of Elite Micro Computers (Dave Cinege) multi-function
card.
I installed Norton Commander 3.0 to use its screen blanker. Got any
hints on BB memory tweaking? The DRDOS 6.0 EMM386.SYS clobbers my BB.
Fortunately, the JANUS 2.1 EMM.SYS does work. The BB also works w/o it.
The BB has a total of 5 MEG for onboard memory.
Sincerely,
(Mr.) Gayle Lee Fairless
'Perfessor Fearless' from the Rocket City!
via AutoPilot 1.03a
Gayle,
You shouldn't have any need for both Enforcer and no
datacache. If you are turning the data cache off, then you don't
need enforcer. Running both will degrade system performance even
more than using only one. The latest Enforcer is, I think, 37.51. If
you run enforcer don't turn off the caches, there's no need. If
keyboard input is freezing, you probably have some other problem.
Check to be sure that you have set the Janus memory segment correctly
in pcprefs. Also be sure you don't have any old Janus programs left
on the system which might be running in place of the 2.1 version
programs. If you are using a separate monitor, be sure you turn BOTH
mono and color video OFF in pcprefs.
DRDOS's emm386.sys should work fine. It works for me with no
problem. The Janus emm.sys is only for expanded memory. DRDOS's
memory manager is for extended and expanded memory. If you use the
DRDOS memory manager you should not use the Janus emm.sys.
Sounds to me that if you are having a problem with the 386BB
that you have something not set up properly. All DRDOS works fine
with it.
Gayle,
I have run into a circumstance where you can't run Enforcer, but the
NODATACACHE solution will work. Apparently if you use PCDisk, the system
will fail to find the bootable disk drive if you run Enforcer, but will
perfectly fine if you use CPU NODATACACHE. Weird but true, at least here.
If PCDisk weren't so fast, I'd dump it in a heartbeat.
"You do trust me, don't you? Of course you do."
— "To Play the King" (BBC)
Brian,
I'm not familiar with PCDisk. Is that a "replacement" for Janus'
virtual disk? It sounds like it. Must be a non-commercial program!! I use a
dedicated hard drive on the BB, so I have never had any problems with Enforcer
and it degrades system performance considerably less than turning off the
datacache.
Steven,
yes, it's in the libraries here and it is a much speedier replacement
since it goes straight to the hardware. That may be why it won't work
with the Enforcer option but will with the datacache turned off. As
usual, a trade off.
"You do trust me, don't you? Of course you do."
— "To Play the King" (BBC)
I posted a copy of my MEM file to Ron Legro in AmigaUser. Could I
see your setup in CONFIG.SYS and AUTOEXEC.BAT files? I could
probably get these working sooner than Autopilot 1.061. With the
DRDOS EMM386.SYS attempting to load, I got a "1701(C) — Controller
#0 Error."
Without any driver or with Janus EMM.SYS, the bridgeboard finds it
files and boots properly.
DEVICE=C:\DRDOS\EMM386.SYS /F=AUTO /K=2048 /B=AUTO /V /E=D000-DFFF /R=AUTO
/A=1000-FFFF DEVICE=\SSTORDRV.SYS
DEVICE=\DEVSWAP.COM
SHELL=C:\COMMAND.COM C:\ /P /E:512
BREAK=ON
HIBUFFERS=20
FILES=30
FCBS=4,4
FASTOPEN=256
LASTDRIVE=L
HISTORY=ON, 256, ON , OFF, OFF
COUNTRY=001,,C:\DRDOS\COUNTRY.SYS
HIDOS=ON
HIDEVICE=C:\DRDOS\ANSI.SYS
HIDEVICE=C:\DRDOS\VDISK.SYS 1024 128 64 /E
HIDEVICE=C:\JANUS\JDISK.SYS
Thanks for your help!
Sincerely,
(Mr.) Gayle Lee Fairless
'Perfessor Fearless' from the Rocket City!
Address Owner Size Type
0:0000 ——– A0000h, 655,360 ————- RAM
0:0000 ——– 400h, 1,024 Interrupt vectors
40:0000 ——– 100h, 256 ROM BIOS data area
50:0000 DR DOS 200h, 512 DOS data area
70:0000 DR BIOS B60h, 2,912 Device drivers
70:050B PRN Built-in device driver
70:051D LPT1 Built-in device driver
70:052F LPT2 Built-in device driver
70:0541 LPT3 Built-in device driver
70:0553 AUX Built-in device driver
70:0565 COM1 Built-in device driver
70:0577 COM2 Built-in device driver
70:0589 COM3 Built-in device driver
70:059B COM4 Built-in device driver
70:0602 CLOCK$ Built-in device driver
70:0645 CON Built-in device driver
70:0671 A:-D: Built-in device driver
126:0000 DR DOS 11B0h, 4,528 System
126:0048 NUL Built-in device driver
241:0000 DR DOS 20EE0h, 134,880 System
253:0000 EMMXXXX0 3880h, 14,464 Loadable device driver
5DC:0000 E: CB90h, 52,112 Loadable device driver (SStor)
1296:0000 CON 1020h, 4,128 Loadable device driver
1399:0000 F: 820h, 2,080 Loadable device driver
141C:0000 G:-J: C60h, 3,168 Loadable device driver
1543:0000 DR DOS 2800h, 10,240 20 Disk buffers
17C0:15C0 DR DOS DE0h, 3,552 DR DOS BIOS code
16FA:3000 DR DOS 9440h, 37,952 DR DOS kernel code
232F:0000 COMMAND 1590h, 5,520 Program
24A9:0000 COMMAND 80h, 128 Data
24B1:0000 AMOUSE C0h, 192 Environment
24BD:0000 DELWATCH 13D0h, 5,072 Program
25FA:0000 AMOUSE 16E0h, 5,856 Program
2768:0000 INSTALL C0h, 192 Environment
2774:0000 INSTALL 600h, 1,536 Program
27D4:0000 PRSWAP C0h, 192 Environment
27E0:0000 PRSWAP 180h, 384 Program
27F8:0000 NC B0h, 176 Environment
2803:0000 ——– 10h, 16 FREE
2804:0000 VSHIELD 66F0h, 26,352 Program
2E73:0000 NC 3270h, 12,912 Program
319A:0000 COMMAND C0h, 192 Data
31A6:0000 COMMAND 1590h, 5,520 Program
32FF:0000 COMMAND 110h, 272 Environment
3310:0000 MEM C0h, 192 Environment
331C:0000 MEM 13AE0h, 80,608 Program
46CA:0000 ——– 59360h, 365,408 FREE
C000:0000 ——– 8000h, 32,768 ————- ROM ——
C800:0000 ——– 2000h, 8,192 ————- ROM ——
D400:0000 ——– 2000h, 8,192 ————- ROM ——
E000:0000 EMS 10000h, 65,536 ———- EMS memory —
F000:0000 ——– 10000h, 65,536 ————- ROM ——
Conventional memory
0h 10000h 20000h 30000h 40000h 50000h 60000h 70000h
0K 64K 128K 192K 256K 320K 384K 448K
| | | | | | | |
2222222222222222222222222222222222222222222222222222222222222222
2222222222222222…………….11111…..1…..[[[[[[[[11111111
| | | | | | | | 4
512K 576K 640K 704K 768K 832K 896K 960K 1MB
80000h 90000h A0000h B0000h C0000h D0000h E0000h F0000h 100000h
Upper memory
Key: 2=RAM 1=ROM 0=Shadow ROM [=EMS
Memory Type Total Bytes ( Kbytes ) Available
Conventional 655,360 ( 640K ) 446,192 ( 435K )
Extended 4,194,304 ( 4,096K ) 3,145,728 ( 3,072K )
EMS 671,744 ( 656K ) 212,992 ( 208K )
via AutoPilot 1.03a
Gayle,
Most of mine looks sort of like yours except I don't use vdisk.sys.
However, I don't use any Expanded memory so my emm386.sys looks like:
DEVICE=c:\emm386.sys /f=none /k=0 /b=ffff /e=c800-cfff
The /e excludes memory in which my scsi adapter loads. Remind me again what
problem we are trying to solve since it's been awhile and I don't remember what
problem you were having.
You also need to be sure that the Janus memory segment set in PCPrefs is
correct. I think it should be d000.
Steven,
PCPrefs is set to D000. One of the variations that I tried in DRDOS is
as follows:
DEVICE=C:\EMM386.SYS /F=AUTO /K=2048 /B=AUTO /V /E=D000-DFFF /R=AUTO
/A=1000-FFFF
I got the '1701(C) — Controller #0 Error' on reboots of the 386
bridgeboard (BB). The first time it simply could not find any files and
would hang.
Ron Lego posted his use of HIDOS.SYS with his use of the Janus EMM.SYS
driver. That might work.
Thanks for your help! Your input is welcome!
Sincerely,
(Mr.) Gayle Lee Fairless
'Perfessor Fearless' from the Rocket City!
via AutoPilot 1.03a
Gayle,
I rechecked config.sys to see what I used.
DEVICE=C;\EMM386.SYS /F=NONE /K=0 /B=FFFF /E=CA00-CBFF,D000-D7FF /R=AUTO
HIDOS=ON SHELL=C:\COMMAND.COM C:/ \P /E:512 HIDEVICE=C:\ANSI.SYS
INSTALL=C:\SHARE.EXE /L:500 HIBUFFERS=10 BREAK=ON FILES=120
PCPrefs has the Janus segment set to D000, Shadowed=Yes, Color disabled, Mono
disabled, Default mode is Color.
Is the controller error you got on the hard drive controller or is that for the
BB floppy controller? If it's the floppy controller you may have a problem
with the BB 's floppy controller chip or something wrong with the floppy drive
setup or cabling.
If the error is for the hard drive controller, then you may have something not
setup right in the CMOS or the drive jumpers may not be set correctly.
I also don't understand the /A=1000-FFFF instruction. You might be screwing
something up with that and it shouldn't be needed. You ought to consider not
using exanded memory unless you absolutely need it for a program. Nowadays
most programs are written to use extended memory. By using /F=NONE /K=0 you
tell EMM386.SYS not to allocate a page frame for expanded memory which will
free up 64K in the UMB. It may be that by allocating the page frame you don't
have any UMBs left for the hard drive controller ROM which usually has to
locate itself in the UMBs. That could explain the controller error if it's for
the hard drive controller. I would recommend you try the setup I use without
expanded memory and see how things work.
Thats a keeper. In fact, the next time I see the Motorola Rep I'm
gonna ask why they don't add such a clear explanation to the
Progammer's Reference Manual. All you get is one short section on
the cache management instructions and no real explanation of what the
heck they are doing to/for you.