В русификации от Sunsoft/DreamTeam. И не учи дедушку кашлять, я загонял куда надо именно перед стартом игры. Именно потому и спрашиваю, что разница не заметна.
Вид для печати
В русификации от Sunsoft/DreamTeam. И не учи дедушку кашлять, я загонял куда надо именно перед стартом игры. Именно потому и спрашиваю, что разница не заметна.
А, работает только 0 и любое другое число. я 0 не пробовал и ничего не менялось.
Не всё сразу :v2_dizzy_hello:
- - - Добавлено - - -
Смотря что считать корректным. Формально она не корректная, но фактически сложно представить реальную (а не выдуманную) ситуацию в которой она не сработает. Вряд ли кто-то будет что-то химичить с содержанием страниц, а потом, без рестарта компа решит поиграть в игру. Даже в детстве, када я грузил с мафона, было правило, что перед каждой попыткой загрузки делался reset. И мне кажется, что все так делали/делают.
Т.е. эта проверка - достаточная. Можно конечно сделать проверку "маниакальную", предельно корректную для всех случаев. Можно конечно сделать, для интереса. Правда тада не получится:
ld a,20
......
dec a ; a=19
Ибо придется делать примерно так:
1. В сжатом блоке хруста находим после 49151 какой-то байт, который равен нулю. Берём этот адрес на карандаш.
2. Грузим картинку и основной блок.
3. Переключаем на 19
4. Заносим по этому адресу "19"
5. Переключаем обратно на 16.
6. Смотрим что лежит по адресу.
7. Если там 19, то JZ на 48-ой сценарий.
8. Иначе (0) - по любому 128. И пофиг что там в каких страницах лежало до загрузки игры.
В 48-ом сценарии конечно придется перед стартом добавить
XOR A
LD адрес , A
Изначально разговор шёл почему и что даёт 1, если в другой версии записывается 255.
Посмотрел фирменную версию, там понятно стало. Там нет прямой записи значений, оно косвенно идёт через тест объёма, в результате 1 записывается если в машине 128кб памяти, 0 - если 48 кб памяти. И если в 48 кб записать туда не 0, то будет висяк. Потому что в обработке прерываний проверяется значение и если оно не равно 0, то включается 3 страница памяти для воспроизведения музыки.
Вот такой ответ мог бы ты дать на вопрос "что даёт 1 в ячейке памяти", а не умничать зря.
Хотя и
ld a,20
......
dec a ; a=19
можно вставить.
Если перед загрузкой основного блока сделать 20 страницу,
загрузить в неё блок,
потом dec a,
переключить,
занести по адресу "19",
inc a,
переключить,
и смотреть что по адресу,
Потом правда в 128-ом сценарии непонятно. Ведь основной блок должен лежать в 16, а он будет лежать в 20 :v2_conf2:
- - - Добавлено - - -
Я не умничал. Просто раз ты мне написал "проверь сам", то я тоже самое и написал тебе. И про 1 и про 0 тоже сразу же написал.
Дык у меня тоже идёт, пусть и не косвенно, а на прямую, но тоже через тест объёма ))
- - - Добавлено - - -
В фирменных версиях не было сражения за каждый байт, ибо интерес был коммерческий, а не спортивный. Работает - и ладно. А сейчас всё не так, сейчас надо в добавок к "рабочести" ещё и сжать и сократить всё что можно, а иначе не спортивно.
ну и в догонку - в фирменной версии проверка как раз корректная в загрузчике:
Код:LD HL,(C000)
PUSH HL
LD A,55
LD (C000),A
LD A,13
CALL SET_RAM_PAGE
LD A,AA
LD (C000),A
LD A,10
CALL SET_RAM_PAGE
LD A,(C000)
AND 01
LD (728E),A
POP HL
LD (C000),HL
LD A,(728E)
AND A
JP Z,5E5E; START
LD A,13
CALL SET_RAM_PAGE
LD IX,C000
LD DE,4000
CALL LOAD_BLOCK
LD A,10
CALL SET_RAM_PAGE
JP 5E5E; START
Экономить по байту - не наш метод! )
К тому же, как заметил Шынни, проверка не корректная (мало ли что окажется в памяти перед запуском игры). В общем, я упростил некоторые конструкции и убил таким образом сразу двух зайцев: сэкономил 14 байт, и проверка стала корректной :biggrin: "Всё и сразу" (с)
Код:ORG 23894
LD BC,#1605
LD HL,42000
CALL LOAD
CALL 42000
DI
LD BC,#7D05
LD HL,26000
CALL LOAD
LD A,18
CALL PAGE
LD A,(50100)
CP 84
JR Z,ZX48
ZX128 CALL PAGE
LD BC,#1105
LD HL,49152
CALL LOAD
CALL 49152
LD A,16
CALL PAGE
LD SP,24137
CALL 26000
RUN JP 24158
ZX48 LD SP,24137
CALL 26000
XOR A
LD (29326),A
JR RUN
LOAD LD DE,(23796)
CALL 15635
RET
PAGE LD BC,32765
OUT (C),A
RET
осталось все сжатые блоки расположить с одного адреса.
и можно будет экономить
Код:ld b,x
call load
..........
load ld c,5
ld hl,26000
.......
ZX_NOVOSIB, я предвкушаю тот момент, когда ты обратишься в сторону написания tiny intro xD
Например, LOAD и PAGE можно объединить и сократить, если нужно.
Разъединение bc дало экономию в 1 байт. При условии, что у нас 3 блока. Если блока будет 2, то экономия будет отрицательной.
Картинку можно с основным блоком расположить с одного адреса. Но ведь третий блок (музыка) надо грузить с 49152 :confused:
коль пошла речь о экономии:
похожий вызов с 42000. поставь в LOAD push hl и убери CALL. -5 байт вродеКод:LD HL,49152
CALL LOAD
CALL 49152
- - - Добавлено - - -
упс, не так
LD HL,26000
CALL LOAD1
LOAD
push hl
LOAD1
Я понял.
Но тут вопрос идеологический. Выходит в 48-ом режиме зря будет что-то грузиться, а это не айс. Если на это забить, то можно вообще было бы блоки склеить и за один раз всё загрузить, или по крайней мере за 2 захода всё загрузить. Но мне больше нравится когда всё по отдельности. Это если бы под код загрузчика вообще места не было, тада другое дело.
- - - Добавлено - - -
Шынни, про push не совсем понятно. Где push, там по идее и pop, как гласит народная мудрость. Но как это всё применить в загрузчике пока не пойму.
Шынни, наконец до меня дошло :v2_yahoo: Минус 5 байт.
еще один незначительный выигрыш: при вызове LOAD ты используешь
LD BC,#xx05 - три раза
если оставить LD b,#xx а в процедуре LOAD ld c,5 , то выигрыш 1 байт
И далее:
LD SP,24137
CALL 26000
RUN JP 24158
ZX48 LD SP,24137
CALL 26000
XOR A
LD (29326),A
JR RUN
неясно, зачем заносить 0 в 29326, но 8 лишних байт итак видно.
в общем, намек дан, если горит сокращать, то думай. для 128 наверняка значение не 0 в ячейке. по идее можно как-то выкрутиться.
в самой игре тоже есть чего сократить.
там после старта создаётся пара таблиц, проверяется наличие кемпстон джойстика,
а потом чистится буфер (в котором что-то есть),
вот это что-то можно смело занулить
Это слишком сложно ) Смысл сокращать имеет тогда, когда ты понимаешь чего и почему ты сокращаешь.
- - - Добавлено - - -
А есть какая-нибудь пусть и не оптимальная, но зато наглядная и простая для понимания процедура зануления произвольной области памяти?
ld hl,xxxx
ld de,xxxx+1
ld bc,yyyy-1
ld (hl),0
ldir
........................
ld hl,xxxx
ld bc,yyyy
l ld (hl),0
inc hl
dec bc
ld a,b
or c
jr nz,l
;8 bytes
ld h,$80 ; l не важно
xor a
zm:
ld (hl),a
inc hl
cp h
jr nz,zm
Если всё сводится к экономии места на диске (в секторах), то есть несколько способов добавочной экономии:
1) данные (например лоадер или его часть можно хранить в неиспользeемой области. Поясню. К примеру, длина кодового блока 30000 байтов, в секторах это займёт 118 секторов, по факту в последнем секторе не будут использоваться (118*256)-30000=208 байт.
2) лоадер ((или его часть) можно хранить в неиспользуемой области экранной заставки, спрятав под атрибутами - но это не всегда возможно.
это всё имеет смысл, если басик файл с кодом в REM строке занимает более 1 сектора (>256 байтов).