Subversion Repositories pentevo

Rev

Details | Last modification | View Log | RSS feed

Rev Author Line No. Line
543 lvd 1 
06.01.2012, lvd:
2 
 
3 
 
4 
NMI from ROM: execute M1 at 0066, then swap to ram page FF (savelij request)
5 
DONE and tested. Need to add somewhere DOSON bit to distinguish ROM NMIs
6 
from usual ROM page and from DOSed ROM page.
7 
DONE and tested a bit.
8 
 
9 
 
10 
overscreen AVR display: юзаем 1 штуку памяти. Всего 512*8 = 4096 бит.
11 
64x64, 128x32, 256x16? Выдача сверху на бордюре белым по чёрному. Запись:
12 
со стороны АВРки, сразу весь массив. Биты включения и обнуления адреса (2 регистра).
13 
 
14 
 
15 
AVR access to SDcard: делаем бит в SPI-контроллере для avr, что мол захватить
16 
доступ. Доступ захватывается, как только Z80 поднимет CS на sdкарту. После этого
17 
контроль над CS и отправкой-приёмом данных переходит к AVR. Z80 ничего сделать
18 
не может: записи в игнор, чтения - говно. Софты должны диагностировать такое,
19 
как отсутствие sdкарты. АВРка работает так: бит для залочки (чтение-запись),
20 
бит для поднятия-опускания CS (запись), регистр чтения-записи, аналогичный по
21 
функциональности Z-контроллеровскому.
22 
DONE and tested!!!!
23 
 
24 
 
25 
readback fontrom: читать symbyte в порт. Для считывания надо руками на экране
26 
устраивать "мультиколор" с перебиранием всех байтов pixbyte. Так как за 8 строчек
27 
проходит только 1 ряд символов, то за это время можно считать ну пусть 16 символов.
28 
за 25 строчек - 400. Итого вполне можно считать фонтрому за кадр. На каждую группу
29 
из 5 символов придётся 20 тактов 7мгц (nowait), вполне достаточно для считывания
30 
(INI:INC B).
31 
DONE!!!!   Z80 routine done!
32 
 
33 
 
519 lvd 34 
03.01.2012, lvd:
35 
 
36 
x640 ham mode:
37 
 
38 
00rrggbb load two pixels colors (x320 truъ color)
39 
 
40 
0101RRrr modify (XOR or ADD) color components of adjacent x640 pixels
41 
0110RRgg
42 
0111RRbb
43 
1001GGrr
44 
1010GGgg
45 
1011GGbb
46 
1101BBrr
47 
1110BBgg
48 
1111BBbb
49 
 
50 
0100xxxx ?
51 
1000xxxx ?
52 
1100xxxx ?
53 
 
54 
screen format ?
55 
320x200 or 256x192
56 
if 320x200, which organization?
57 
320x200 variants: 320 bytes per line, 512 bytes per line, ???
58 
 
59 
in parallel, we can have paletted x640 16c mode with byte format
60 
like current x320 or x256 16c
61 
 
543 lvd 62 
Вопрос с форматом -- что делать для 3 кодов?
63 
Нужен ли вообще такой ХАМ.
519 lvd 64 
 
543 lvd 65 
Вопрос с алонекодером - делать ли ему префетч скроллок каждую строку
66 
из рамы?
519 lvd 67 
 
543 lvd 68 
Скроллки: ворд Х-скролла (9 бит: 0..511), ворд Y скролла (0..511 или сколько там).
69 
Алоний ещё хочет dual playfield по 16 цветов каждый - надо ли и как?
519 lvd 70 
 
71 
 
72 
 
467 lvd 73 
11.06.2011, lvd:
228 lvd 74 
 
75 
 
467 lvd 76 
(в порядке бреда)
77 
про кэш:
78 
 
79 
1. 2 кусочка по 256 байт из 1 штуки памяти
80 
2. на каждый кусочек - тэг 8бит и общий бит валидности
81 
3. на каждый ворд из всех 256 - свой бит валидности. при необходимости можно играться -
82 
   делать больше кусочков, но в сумме меньше вордов, чтобы сэкономить биты валидности на
83 
   каждый ворд.
84 
4. условия заполнения кеша:
85 
  1) чтение по M1 - если теги не совпадают, выбирается одна из 2 половинок (по какой-либо
86 
     методике), переписывается тэг, инвалидируются все ворды, новый ворд пишется, половинка
87 
     маркируется в целом валидной.
88 
  2) чтение не по М1 - если попадает в кеш, то слово валидируется, если не попадает - игнор.
89 
  3) запись, попадая в кеш, инвалидирует слово
90 
5. условия инвалидации кеша
91 
  1) любая запись в порты (или в некоторые порты) инвалидирует весь кеш
92 
  2) исполнение из пзу инвалидирует кеш
93