Цитата(Mayk @ 14.6.2005, 15:42)

Надо еще вспомнить устройство экрана,

Область памяти размером в 8К. Первый байт по адресу 16384. В высоту 24 знакоместа (каждое знакоместо 8x8 пикселей, цвет чернил и фона задается одним байтом). Ширину экрана не помню, надо в интернете поискать. Область видеопамяти разбита на 4 части - три под пикселы (каждая высотой в 64 пиксела), одна под цвет.

Цитата(Mayk @ 14.6.2005, 15:42)

работу с памятью >48K,

через порт. Кажется #7FFD. Записью значения в него переключается номер отображаемой страницы.

Цитата(Mayk @ 14.6.2005, 15:42)

работу с TRDOS.

Передача управления на байт по адресу 15616 приводит к переходу в оболочку tr-dos, по адресу 15619 можно осуществлять выполнение отдельных команд.

Это сообщение отредактировал(а) DENNN - 14.6.2005, 17:15

ну все память освежили ) пора тетрис или питона начинать делать имхо )

Цитата(oleg1973 @ 14.6.2005, 17:24)

ну все память освежили ) пора тетрис или питона начинать делать имхо )

Да, что-то когда участники услышали эту фразу, сразу решили по тихому скрыться в теме ZX+Games . Имхо если говорить обо мне, то рановато еще писать гаму на zx-asm'е - нужно еще дочитать книгу "Как написать игру на Ассемблере для ZX Spectrum". Дочитаю, вернусь в этот топик и мы с вами напишем то, о чем вы говорите.

Давайте лучше подробнее вспомним устройство графики и ввод с клавиатуры!
Подробней вот отсюда:

Цитата(DENNN @ 14.6.2005, 16:57)

Область видеопамяти разбита на 4 части

На установление всего опытным путём времени мало.
Ну а пока, может на басике что-нибудь напишем? Спеки - не PC. На спеки на басике писать совсем не стыдно

Payne
Книгу можно найти где-нибудь в электронном варианте?

да че там вспоминать?
клава там с какогото порта читается, экран тоже не проблема )

oleg1973
На четыре части можно разделить многими способами. Я хочу такой справки:
#4000-XXXX - экран прорисовывается так-то так-то и так-то
XXXX+1-YYYY - так-то и вот так-то
YYYY+1-#5800 - вот так и никак иначе
#5800-ZZZZ - аттрибуты. Они представлены так-то и так-то.

Цитата(oleg1973 @ 16.6.2005, 15:55)

клава там с какогото порта читается

#0FE
Там кажется надо послать бит, идентифицирующий полуряд клавиатуры,
а потом считать оттуда какая клавиша полуряда нажата

Это сообщение отредактировал(а) Mayk - 16.6.2005, 18:28

Цитата(Mayk @ 16.6.2005, 13:01)

Давайте лучше подробнее вспомним устройство графики

Насчет графики.
С адреса 16384 (#4000) начинается видеопамять. Она имеет размер 6 Кб. Далее, с адреса 22528 (#5800) идет область атрибутов экрана (768 байт).
Размер экрана ZX Spectrum составляет 256x192. Стандартные знакоместа имеют размер 8x8 пикселей. Следовательно, на экран можно вывести 24 строки по 32 знакоместа в каждой.
При выводе изображения на экран каждый байт экранной области определяет состояние 8 расположенных горизонтально одна за другой точек (бит 7 соответствует левой точке, бит 0 - правой). Байты, соответствующие строкам экрана, расположены в памяти не последовательно. Первые 32 байта экранной области задают слева направо верхнюю строку, следующие 32 байта - 9-ю сверху, следующие - 17-ю и далее через 8 строк вплоть до 57-й. Затем расположены байты, соответствующие 2-й, 10-й и т.д. до 58-й. Так задается треть экрана. Аналогично задаются средняя и нижняя трети экрана. Я так понимаю, что из-за этого и получается разбивка видеопамяти на 4 части - под пикселы и цвет.

Цитата(Mayk @ 16.6.2005, 13:01)

Книгу можно найти где-нибудь в электронном варианте?

Книги ищи здесь.

на виртуал тр-дос книги есть

И все молчат.
oleg1973 прально сказал, давайте делать питончика.
Итак, давайте думать как его реализовать.
Давайте рассмотрим возможные алгоритмы перемещения.

1) Связной список координат
На си это так: struct snake_node{ snake_node* prev; snake_node* next; int x,y; };
Перемещение делается элементарно - вычисляется координаты головы, отцепляется хвост, хвостовой элемент ставится в голову. Стоимость выполнения О(1).
Недостатки - расход памяти(даже если сделать список с одинарными связями)
Достоинства - легкость реализации(в си, на асме я линкед листы давно не делал)

2) Массив координат
struct node{int x,y};
node[MAX_SNAKE_LEN]
int head_offset; - node[head_offset] -здесь начинается голова змия
int len_offset; - node[head_offset+len] - здесь хвост змия

Стоимость движения в среднем O(1):
node[head_offset-1].x=new_head_x
node[head_offset-1].y=new_head_y
head_offset--;
Недостатки:
В худшем случае(head_offset=0) потребуется переместить всего змия в конец массива... LDIR, как мы выяснили, делает это за константное время => в худшем случае время тоже О(1)
Длина змеи ограничена MAX_SNAKE_LEN элементами.

3) Массив направлений
typedef enum{North, South, West, East};
int tail_x, tail_y;
int directions[]
directions[] показывает в какую сторону двигаться от хвоста к голове. Используя LDIR добиваемся все того же О(1):
Head Direction: North
int directions[] = {East, East} (сейчас змея вот так стоит >>> )
Пихаем в direction[2]=North (>>>^), сдвигаем змею: >>^
Достоинства: Жрет мало памяти
Недостатки: LDIR почти каждый ход(если змея не растет). Нужно высчитывать координаты змеи.

4) Массив сильно сжатый
Модифицировать 3ий алгоритм. Направления задавать не 8ью битами, а двумя:
00 - двигаем на север
01 - на запад
10 - на восток
11 - на юг
Достоинства - ест ОЧЕНЬ мало памяти
Недостатки - LDIR использовать уже нельзя. Следовательно, при каждом движении потребуется около n/8+1 одних только сдвигов

5) ????


PS.Блин, narod.ru какой-то тормознутый, чтобы файлы качать.

Это сообщение отредактировал(а) Mayk - 17.6.2005, 18:37

массив 192*256*2 бита
там рисуем питона битами
храним координату ЖО питона, ну ее удалять нада при движении ))
ну и нужна процедура вывода бит-массива на экран
типа 0 - пусто
1- спрайт сегмента питона
2- типа яблоко которое сожрать нада чтоб вырости
и так далее )
имхо отрисовку нада делать в 128 режиме на 2х экранах (мыж в 21 веке все таки) )

Цитата(oleg1973 @ 19.6.2005, 15:24)

массив 192*256*2 бита

Это же размеры экрана? А как тогда отличить яблоко от змия? Давай делать tile 4x4 бита. Таким образом размер массива: (192/4)*(256/4)*2 бита = (68)*(64)*2 бита=4352/4 = 1088 байт. Кстати, нужен еще статус бар.
Шрифты стандартные не юзаем. Используем те же 4х4 бита. А массив теперь становится 67*64*1/4=1072 байта. Запомним это число.

Цитата(oleg1973 @ 19.6.2005, 15:24)

там рисуем питона битами храним координату ЖО питона, ну ее удалять нада при движении ))

Да, точно. Так и сделаем!
+2 байта = 1074 байт.

Цитата(oleg1973 @ 19.6.2005, 15:24)

ну и нужна процедура вывода бит-массива на экран типа 0 - пусто 1- спрайт сегмента питона 2- типа яблоко которое сожрать нада чтоб вырости

Лучше все же хранить в массиве направление к голове - тогда потребуются еще 2 байта на координаты яблока, но питон будет рисоваться очень быстро.
1074+2=1076 байт

Цитата(oleg1973 @ 19.6.2005, 15:24)

и так далее ) имхо отрисовку нада делать в 128 режиме на 2х экранах (мыж в 21 веке все таки) )

Не стоит имхо. Памяти столько не расходуем
Да и изменения на экране минимальны. Вот начнем писать стратегию


Теперь надо придумать как изображать тайлы. Для змия и яблока потребуются 16 байт. Запихнем их в область шрифтов для экономии места
Также не забудем про шрифт. Сгруппируем все в 32 байта. И заменим редко используемые символы в шрифте.
Наброски тайлов:

Код

01234567  01234567  0####.AA. 0.WWWEEE.  1####AAAA 1WW.WE.EE  2####AAAA 2WW.WE.EE  3####.AA. 3.WWWEEE.  4.0..1... 4.NN.SSSS  50.0.1... 5NNNNS..S  60.0.1... 6N..NSSSS  7.0..1... 7NNNN.SS.  01234567  01234567  0222.333. 0.66.777.  1..2..3.. 16.....7.  222....3. 2666..7..  3222.33.. 3.6...7.. 44.4.555. 4.8...9.. 5444.55.. 5888.999.  6..4...5. 6888...9. 7..4.55.. 7.8..99..

Расшифровка:
# - тело змия
0...9 - цифра
N - голова направлена на сервер(хвост направлен на юг)
W - голова направлена на запад(хвост направлен на восток)
S - голова на юг
E - голова на восток
Ну для хвоста можно еще 8 байт использовать

Нда, шрифты надо фиксить, бо уродство.

Ладно, хватит теории. Пора переходить к практике, но не сегодня.