Moderators: Mug UK, moondog/.tSCc., lp, [ProToS], instream, Moderator Team, Nature
Code: Select all
*=======================================================*
* 68040 extensions: updated 12/06/97 *
*=======================================================*
page_size = 8192
*-------------------------------------------------------*
initialise_pmmu:
*-------------------------------------------------------*
move.l #-1,bss_handle
move.l #-1,display_handle
ifd use_xmmu
move.l #'XMMU',d0
bsr cookie_search
tst.l d0
bmi.s .npmu
move.l 4(a0),a0
move.l pmmu_read_pds(a0),pmmu_read_rout
move.l pmmu_write_pds(a0),pmmu_write_rout
move.l pmmu_chg_2_cb(a0),pmmu_cbc_rout
move.l pmmu_chg_2_ns(a0),pmmu_noc_rout
bsr mark_bss
bsr mark_display
endc
.npmu: rts
*-------------------------------------------------------*
mark_bss:
*-------------------------------------------------------*
* Allocate space for BSS pages *
*-------------------------------------------------------*
lea bss_start,a0
lea bss_all_end,a1
moveq #13,d2
move.l a0,d0
move.l a1,d1
add.l #page_size-1,d1
lsr.l d2,d0
lsr.l d2,d1
sub.l d0,d1
lsl.l #2,d1
move.l d1,d0
movem.l a0-a1,-(sp)
moveq #VRAM_preferred,d1
bsr allocate_chunk
tst.l d0
ble err_super_xmmu
movem.l (sp)+,a0-a1
tst.l d0
ble.s .nbss
pushall
move.l d0,a0
move.l d1,d0
jsr turbo_memclr
popall
move.l d0,bss_handle
move.l d0,a2
jsr ([pmmu_read_rout.l])
jsr ([pmmu_cbc_rout.l])
.nbss: rts
*-------------------------------------------------------*
mark_display:
*-------------------------------------------------------*
* Allocate space for display pages *
*-------------------------------------------------------*
move.l display_start,a0
move.l display_size,d0
lea (a0,d0.l),a1
moveq #13,d2
move.l a0,d0
move.l a1,d1
add.l #page_size-1,d1
lsr.l d2,d0
lsr.l d2,d1
sub.l d0,d1
lsl.l #2,d1
move.l d1,d0
movem.l a0-a1/d1,-(sp)
moveq #VRAM_preferred,d1
bsr allocate_chunk
tst.l d0
ble err_super_xmmu
movem.l (sp)+,a0-a1/d1
tst.l d0
ble.s .ndsp
pushall
move.l d0,a0
move.l d1,d0
jsr turbo_memclr
popall
move.l d0,display_handle
move.l d0,a2
jsr ([pmmu_read_rout.l])
jsr ([pmmu_noc_rout.l])
.ndsp: rts
mikro wrote:It doesn't require anything else. It just "limits" the amount of usable memory to 1 GB, then it perhaps crashes on an PMMU error because there are no PMMU entries for addresses between 0x40000000 and 0x7FFFFFFF (and these are no longer translated as copy back, they are illegal from now). So the correct solution would be of course to map the SV-RAM area (0xA0000000 - 0xA7FFFFFF) in the PMMU tree but it's too much work for too little (zero) effect. It's software, can be changed later
shoggoth wrote:mikro wrote:It doesn't require anything else. It just "limits" the amount of usable memory to 1 GB, then it perhaps crashes on an PMMU error because there are no PMMU entries for addresses between 0x40000000 and 0x7FFFFFFF (and these are no longer translated as copy back, they are illegal from now). So the correct solution would be of course to map the SV-RAM area (0xA0000000 - 0xA7FFFFFF) in the PMMU tree but it's too much work for too little (zero) effect. It's software, can be changed later
Awesome. I'll make this optional for now in case it clashes with some other hardware (CTPCI?).
calimero wrote:so Quake now will be even faster? :D
mikro wrote:calimero wrote:so Quake now will be even faster?
Don't get your hopes too high, buddy. The bottleneck in Quake isn't surprisingly the c2p process but Quake itself. Absolute difference between SV-featured rendering and not rendering at all is 0.5 FPS (!). So from C2P to this "new" method you get about 2-3 FPS at most. Not so cool, is it.
shoggoth wrote:higher screen rez?
dml wrote:shoggoth wrote:higher screen rez? :)
This man speaks wisdom :)
instream wrote:Now we have tested Mikro's program with our oscilloscope, with and without the PMMU changes. Unfortunately byte/word/long writes are not grouped into move16 lines as we hoped but still written as bytes/words/longs. The speed gain comes from that the five idle cycles between writes have disappeared.
mikro wrote:It will definitely slow down things a little but maybe not that much
mikro wrote:The bottleneck in Quake isn't surprisingly the c2p process but Quake itself. Absolute difference between SV-featured rendering and not rendering at all is 0.5 FPS (!).
mikro wrote:mikro wrote:It will definitely slow down things a little but maybe not that much
AHEM. Although it has been an amazing look to see all the stuff in hires, FPS in 640x480 dropped to maybe 5 or 6, hard to say because my favorite demo2 has frozen when jumping into the waterTherefore - not playable.
mikro wrote:instream wrote:Now we have tested Mikro's program with our oscilloscope, with and without the PMMU changes. Unfortunately byte/word/long writes are not grouped into move16 lines as we hoped but still written as bytes/words/longs. The speed gain comes from that the five idle cycles between writes have disappeared.
But how come the move16 tests report the same bandwidth all the time, with or without the change to the PMMU? If I understood our discussion right, you claim that those move16 bursts do happen without my change.
EDIT: Ah, now I get it. You have hoped that bytes and words would be grouped into a long access at least. Anyway, I don't care why it's faster, it's faster and that's important
Users browsing this forum: No registered users and 2 guests