Subversion Repositories pentevo

06.01.2012, lvd:


NMI from ROM: execute M1 at 0066, then swap to ram page FF (savelij request)
DONE and tested. Need to add somewhere DOSON bit to distinguish ROM NMIs 
from usual ROM page and from DOSed ROM page.
DONE and tested a bit.


overscreen AVR display: юзаем 1 штуку памяти. Всего 512*8 = 4096 бит.
64x64, 128x32, 256x16? Выдача сверху на бордюре белым по чёрному. Запись:
со стороны АВРки, сразу весь массив. Биты включения и обнуления адреса (2 регистра).


AVR access to SDcard: делаем бит в SPI-контроллере для avr, что мол захватить
доступ. Доступ захватывается, как только Z80 поднимет CS на sdкарту. После этого
контроль над CS и отправкой-приёмом данных переходит к AVR. Z80 ничего сделать 
не может: записи в игнор, чтения - говно. Софты должны диагностировать такое,
как отсутствие sdкарты. АВРка работает так: бит для залочки (чтение-запись),
бит для поднятия-опускания CS (запись), регистр чтения-записи, аналогичный по
функциональности Z-контроллеровскому.
DONE and tested!!!!


readback fontrom: читать symbyte в порт. Для считывания надо руками на экране
устраивать "мультиколор" с перебиранием всех байтов pixbyte. Так как за 8 строчек
проходит только 1 ряд символов, то за это время можно считать ну пусть 16 символов.
за 25 строчек - 400. Итого вполне можно считать фонтрому за кадр. На каждую группу
из 5 символов придётся 20 тактов 7мгц (nowait), вполне достаточно для считывания
(INI:INC B).
DONE!!!!   Z80 routine done!


03.01.2012, lvd:

x640 ham mode:

00rrggbb load two pixels colors (x320 truъ color)

0101RRrr modify (XOR or ADD) color components of adjacent x640 pixels
0110RRgg
0111RRbb
1001GGrr
1010GGgg
1011GGbb
1101BBrr
1110BBgg
1111BBbb

0100xxxx ?
1000xxxx ?
1100xxxx ?

screen format ?
320x200 or 256x192
if 320x200, which organization?
320x200 variants: 320 bytes per line, 512 bytes per line, ???

in parallel, we can have paletted x640 16c mode with byte format
like current x320 or x256 16c

Вопрос с форматом -- что делать для 3 кодов?
Нужен ли вообще такой ХАМ.

Вопрос с алонекодером - делать ли ему префетч скроллок каждую строку
из рамы?

Скроллки: ворд Х-скролла (9 бит: 0..511), ворд Y скролла (0..511 или сколько там).
Алоний ещё хочет dual playfield по 16 цветов каждый - надо ли и как?



11.06.2011, lvd:


(в порядке бреда)
про кэш:

1. 2 кусочка по 256 байт из 1 штуки памяти
2. на каждый кусочек - тэг 8бит и общий бит валидности
3. на каждый ворд из всех 256 - свой бит валидности. при необходимости можно играться - 
   делать больше кусочков, но в сумме меньше вордов, чтобы сэкономить биты валидности на
   каждый ворд.
4. условия заполнения кеша: 
  1) чтение по M1 - если теги не совпадают, выбирается одна из 2 половинок (по какой-либо
     методике), переписывается тэг, инвалидируются все ворды, новый ворд пишется, половинка
     маркируется в целом валидной.
  2) чтение не по М1 - если попадает в кеш, то слово валидируется, если не попадает - игнор.
  3) запись, попадая в кеш, инвалидирует слово
5. условия инвалидации кеша
  1) любая запись в порты (или в некоторые порты) инвалидирует весь кеш
  2) исполнение из пзу инвалидирует кеш