CRC и коммутация ПрофПЗУ в скорпе

Yahoo!!!!!!!! Убив несколько часов на изучение ПрофПЗУ довожу до вашего
сведения общий принцип управления. Итак, начнем с описания: ППЗУ 512кб состоит
из 2х половинок по 256кб никоим образом не связанных с друг другом и
переключающихся тумблером;). Соответственно в каждой из этих частей полностью
содержится система (по моим оценкам она занимает 70-80кб).
Далее, каждая часть побита на блоки по 64кб. Переключение внутри блоков банков
по 16кб стандартное: если в 1FFD бит D1=1, то включено ПЗУ монитора (при любом
значении бита D4 7FFD), иначе если D4=1 (7FFD), то басик48, если D4=0, то
басик128. Чтобы, включить пзу трдоса нужно при включенном басике48 сделать
JP #3DXX.
Теперь о переключении блоков. Сначала врубается область теневика (D1=1,
1FFD). Пусть номер блока (0-3) задан в А, тогда у МОА видим следущее:
ld hl,#0110:add a,l:ld l,a:jr nc,m1:inc h
m1 ld l,(hl):ld l,(hl):ret
в строке с m1 видим 2 ключевые команды ld l,(hl)! Первая просто читает значение
из таблицы (всего там их 4 штуки: #00,#04,#08,#0c), а вторая врубает блок.
Вроде все тривиально, однако непонятно зачем нужна таблица? Причем в каждом из
блоков таблицы разные: используются те же значения 0,4,8,c, но порядок их
расположения другой! Также отмечу, что ячейка #0101 используется для
идентификации текущего блока. Пример: запомнили число из #0101, включили
какой-нибудь блок, выполнили какие-либо операции, для восстановления
предыдущего блока использовали запомненное значение и т.п.

Теперь о популярной проблеме вычисления CRC сектора подключений;). При
изучении исходного текста (ZX NEWS 54) было выявлено несколько HУ ОЧЕHЬ тупых
ошибок, благодаря чему расчет CRC теперь занимает немного блоьше времени,
однако памяти тратится всего 68 байт!
Комментировать не буду, влом;). Hе рекомендую лишь использовать эту процедуру в
других целях, лучше напишите свою или возьмите готовую из Hrust Library.

═══════════════════ newcrc .C ══════════════════

;CRC CALCULATOR ;-)
;easy generated by J7n/4D/PeRM/RuSSIA/29.07.2001
.LOCAL
;INP: HL - BUF, BC - LEN
;OUTP: DE - CRC
CRC_CALC
PUSH IX
LD IX,#FFFF
...0
LD A,(HL)
XOR LX
LD E,A
CALL ...1
XOR HX
LD LX,A
INC E
LD A,#88
CALL NZ,...1
LD HX,A
CPI
JP PE,...0
EX (SP),IX
POP DE
RET

...1
LD A,E
RRA
RRA
RRA
RRA
LD D,A
AND #0E
XOR E
AND #1F
RRA
JR C,...2
LD D,A
RRCA
RRCA
AND #C1
XOR E ;BIT 0,E=0!!!
RRCA
AND #F0
OR D
RET
...2
ADD A,A
ADD A,A
ADD A,A
ADD A,A
XOR D
AND #F0
XOR D
RET
DISPLAY $-CRC_CALC
═══════════════════════════════════════════

P.S. не разрешается публикация данного алгоритма в ZX NEWS.

С Вами был .┌─┐┌─┐┬┌ .┌─┐ aka J7n/4D
│┼─┼│ ├┴┐│├┤
jtn_собака_mail.ru
└┘┘ └└─┘┴ ┴└└─┘
sp...@fbi.com

30 Июл 01 00:22, Vassili Klimov -> All:

Что ж, большое спасибо за новyю пpогpаммy pасчета CRC, с твоего позволения бyдy
внедpять ее в тело своего коммандеpа.

VK> XOR E ;BIT 0,E=0!!!

^^^^^^^^^ Что это значит?

VK> P.S. не pазpешается пyбликация данного алгоpитма в ZX NEWS.

А почемy ты так негативно относишься к этомy изданию?

VK> С Вами был .┌─┐┌─┐┬┌ .┌─┐ aka J7n/4D
VK> │┼─┼│ ├┴┐│├┤
VK> jtn_собака_mail.ru
VK> └┘┘ └└─┘┴ ┴└└─┘

Кстати, подпись свою подпpавь, а то нижняя стpока вниз отъехала :)

Stanislav

Однажды, Пон Июл 30 2001 00:22, Vassili Klimov писал к All:

VK> Теперь о переключении блоков. Сначала врубается область теневика
VK> (D1=1, 1FFD). Пусть номер блока (0-3) задан в А, тогда у МОА видим
VK> следущее:
VK> ld hl,#0110:add a,l:ld l,a:jr nc,m1:inc h
VK> m1 ld l,(hl):ld l,(hl):ret
VK> в строке с m1 видим 2 ключевые команды ld l,(hl)! Первая просто читает
VK> значение из таблицы (всего там их 4 штуки: #00,#04,#08,#0c), а вторая
VK> врубает блок. Вроде все тривиально, однако непонятно зачем нужна
VK> таблица? Причем в каждом из блоков таблицы разные: используются те же
VK> значения 0,4,8,c, но порядок их расположения другой!

да мозги они пудрили! чтобы сложнее было на логике сделать ;)

Всего хорошего.
Дмитрий. [ZX] [Quake]

np: The Beatles - Helter Skelter

VK>> NEWS.

SU> А почемy ты так негативно относишься к этомy изданию?

Hе могу отвечать за J7n'а, говорю за себя: Лично мне не нравится
некомпетентная (в некоторых вопросах)
назидательно-разоблачительно-снисходительная позиция главных редакторов (видимо
Jedi), что особенно видно по статьям о DemoScene, автор считает нормальным
указывать всем: кому, что, в каком количестве и когда нужно делать или не
делать (в данном случае демы), при том что сам _никаким_ боком к Demomaking не
относится (могу ошибаться, но, похоже это так), да даже если бы и относился,
все равно _так_ навязывать свое мнение, даже не
мнение, а _ситему_ценностей_, причем весьма неотлаженную и глючную, он и тогда
не имел бы права. Думаю, очень просто понять чувства demomaker'ов
(кодеров/художников/музыкантов/дизайнеров), прочитавших такое в ZxNews...
Человек нетолерантный к другим типам мышления/системам ценностей вызывает у
меня смешанные чувства, в том числе и сожаление (правильное чувство, ничего
оскорбительного в нем для обьекта нет), но публиковаться в газете такого
человека я бы не захотел ;)))
Вдруг после публикации он обьявит musicmacker'ов врагами спектрума? И
возьмется их искоренять? А что, все правильно: вместо того чтобы писать
полезный системный/игровой софт, сидят часами в ProTracker'е и в ус не дуют
;)))

Хотя, возможно, наличие такой позиции у редакции и не причина для того
чтобы игнорировать (читай бойкотировать) газету, но, чтобы так поступать надо
быть ангелом-во-плоти ;)))

SU> А почемy ты так негативно относишься к этомy изданию?
некоторые members 4D не согласны с серией публикаций (если конкретней, то
касающихся demoscene).

До скорого, Stanislav. jtn{a}mail.ru
├┬
─┘│n/ЧD sp...@fbi.com