Из памяти M68k в VRAM VDP Из памяти M68k в VRAM VDP перекидывал так:
while(n--)VDP_DATA_32=*src++;
}
}
Без понятия что там сгенерится, но скорее всего
@loop:
move.l (a0)+(a1)
dbf d0,@loop
или
@loop:
move.l (a0)+(a1)
move.l (a0)+(a1)
dbf d0,@loop
что недостаточно для большой скорости.
Должно быть примерно такое :
lea vdpSpriteCache,a0
lea $C00000,a1 ; vdp_data
move.l #$74000003,4(a1) ; vram: $F400
move.w highestVDPSpriteIndex,d1 ; количество спрайтов 1-80?
bne.s @have_spr
moveq #1,d1 ; (минимум 1 спрайт для обновления если нет спрайтов).
@have_spr
add.w d1,d1 ; *2
add.w d1,d1 ; *4 = 320
move.w #320,d0
sub.w d1,d0
jmp copy_to_vram(pc,d0.w)
copy_to_vram
dcb.w 160,$2298 ; то есть move.l (a0)+,(a1) повторить 160 раз. (160*4 = 640)
rts
Это медленнее чем с DMA, но вполне неплохо. Тем более для 640 байтов. Звук семплов это улучшит.
С тайлами сложнее, там много уже не передать без DMA, но могут быть варианты:
а) Тайлы обновляются не всё время.
б) Пал режим, тут гораздо больше времени вбланка. (Проверять если VDP в ПАЛ - не использовать DMA).
Также можно с CPU только в момент когда семпл играет, а в остальных случаях с DMA.
Примерный код для тайлов - передаём в цикле по 64 байта (2 тайла), максимум 2560 байт.
lea tiles,a0 ; тайлы
move.w tiles_cnt,d1 ; количество тайлов от 1 до примерно 80, при превышении - DMA.
cmpi.w #80,d1
BCC.S too_many_tiles
subq.w #1,d1
lsr.w #1,d1
bcc.s @odd
@copy
move.l (a0)+,(a1) ; 1тайл = 32байта.
move.l (a0)+,(a1)
move.l (a0)+,(a1)
move.l (a0)+,(a1)
move.l (a0)+,(a1)
move.l (a0)+,(a1)
move.l (a0)+,(a1)
move.l (a0)+,(a1)
@odd
move.l (a0)+,(a1) ; 2-ой тайл
move.l (a0)+,(a1)
move.l (a0)+,(a1)
move.l (a0)+,(a1)
move.l (a0)+,(a1)
move.l (a0)+,(a1)
move.l (a0)+,(a1)
move.l (a0)+,(a1)
dbf d1,@copy
rts
too_many_tiles:
тут код с dma.
Также кроме тайлов и спрайтов, можно переделать обновление палитры и hscroll если они есть.
Добавлено позже:Вот этот вариант:
Вот этот вариант более интересен.
Можно ли заставить XGM движок играть семпл из памяти Z80, предварительно скопировав его из ROM ?
Ну это сложная система. Поэтому врядли. Из движков GEMS это умеет.
Добавлено позже:И тут я более понял, что нужно посмотреть dma.c что там делается. И не зря. Там творится полный ужас - останавливается Z80 когда идёт транзакция DMA:
Ну как бы это также есть и в почти всех играх на SEGA.
Z80 в любом случае останавливается, при попытке доступа к РОМУ, если в этот момент используется DMA.
Но в играх это делается принудительно, что при любом обращении к памяти z80, так как по рекомендациям в мануале, сказано что так надо. Иначе могут быть проблемы, то ли в зависимости от ревизий Сеги, или от скорости памяти точно не скажу. А вот в некоторых эмуляторах z80 не останавливается сам.
Добавлено позже:Всё отлично работает! DMA успевает пролететь раньше - сразу же после освобождения шины Z80, до того как Z80 снова её займёт.
Я рад! Сопли в звуке прошли - все семплы чётко и ровно звучат, и спрайты не артефачат. 
Такое врядли может быть:
При 14 кгц звуке если он читается напрямую из ROM, полностью дисторшен никак не может пропасть. Это по 233 байта за кадр. То есть в среднем почти каждую строку по байту. За vblank-dma это байтов 20 или больше.
Если только у тебя dma не разбито на много маленьких кусков, и то сомнительною
То есть тут либо xgm всё же умеет 'кешировать' семпл. Либо эмулятор такой, если на нём проверял.