Работа с текстовым режимом (и квадратиками видеопамяти)

[Mac Buster]

Вниманию интересующихся предлагается процедура вывода одной строки символов из 80 штук на текстовый экран открытый по адресу 0xC000. Вот собственно и все, что осталось от текстового редактора, остальное утеряно. Если хотите выводить не символы, а их атрибуты, то следует число 0xC301 сменить на 0xC302. Номер строки экрана на которую выводятся символы задаётся в аккумуляторе. В регистровой паре DE - адрес начала строки символов.

Code: Select all

Xor   A
Ld    Bc,0xC301
Ld    De,sTextLine
Ld    H,0x00
Ld    L,A
Add   Hl,Hl
Add   Hl,Hl
Add   Hl,Bc

Ld    A,0x81
Out   (0x89),A

Di
Ld    D,D
Ld    A,0x50
Ld    B,B
Ld    L,L
Ld    A,(DE)
Ld    B,B
Ld    A,A
Ld    (Hl),A
Ld    B,B
Ei

Написано неоптимально, однако, благодаря использованию акселератора работает ОЧЕНЬ быстро

[Shaos]

Оказывается Mac Buster ещё в 2004 году расковырял кишки текстового режима Спринтера

Интересный вопрос - почему текстовый режим всегда использует смещение 129 (#81)?

Согласно технической документации эта часть описателя графического экрана относится ко второй видеостранице:

[Shaos]

Значится так - каждый "квадратик" представлен в области описателя экрана (Screen Description Area) прямоугольником 4x2 байта (4 по горизонтали, 2 по вертикали) - описатель, как и текстовый экран, положен "на бок" и "отзеркалирован" - первая строчка это левый столбик у которого лево это верх. Далее первые 4 байта в каждом таком прямоугольнике описывают основной режим, а вторые 4 байта - дополнительный если в графической строке 640 точек вместо 320 (режим повышенной чёткости). Четвёртый байт пока не используется (ни в основном описателе, ни в дополнительном), а первые три описаны так:

байт 0:
- биты 0,1,2,3 - задают биты 4...1 адреса блока данных (бит 0 берется из 3го бита порта #7FFD для текстового режима либо из байта 1 для графического где это всё формально задаёт старшие биты номера квадратика по горизонтали);
- бит 4 - "1" для текстового режима, "0" для графического режима;
- бит 5 - "1" для 320 точек в строке, "0" для 640 точек в строке (режим повышенной чёткости, который требует использования второй четвёрки байтов описателя);
- биты 6,7 - задают биты 12...11 адреса данных в блоке (палитра для графического режима), однако если их значение 11 вместе с 11 в битах 4 и 5, то смысл этого байта меняется - в этом случае если биты 2 и 3 имеют значение 11 то этот квадратик - гашение, а если ещё и бит 0 имеет значение 1, то это прерывание.

байт 1 в текстовом режиме: младшие 8 бит адреса (7...1), а недостающие 3 бита 10...8 берутся из номера линии в квадратике (в текстовом режиме это просто отсылка в знакогенератор и на самом деле тут сидит код символа!).
байт 1 в графическом режиме:
- биты 0,1 - дополнительный адрес в в блоке (чтобы адресовать квадратик по горизонтали);
- бит 2 - младший бит номера блока (чтобы адресовать квадратик по горизонтали);
- бит 3,4,5,6,7 - адрес квадратика по вертикали.

байт 2: младшие 8 бит адреса атрибутов для спектрумовского режима (с замешиванием), но представляют сам атрибут в случае текстового режима.

24 сентября 2021 года в телеге появилась информация, что 3 бита этого байта используются и в графическом режиме - бит 2 включает режим увеличения четвертинки квадрата, а биты 0 и 1 задают какая четвертинка увеличивается до размеров квадрата.

байт 3: не используется

В документации указано, что запутывание адреса квадратика вызвано необходимостью уменьшить размер прошивки для альтеры.
Координаты квадратика в видеопамяти для графического режима соответственно будет:
X=0.3|0.2|0.1|0.0|1.2|1.1|1.0 (0...95 т.к. старшие 2 бита не могут быть единицами одновременно если это не гашение),
Y=1.7|1.6|1.5|1.4|1.3 (0...31).
Получается, что графический режим можно рассматривать как текстовый 80x32 с многоцветным шрифтом в 3072 символов (тайлов)

[Shaos]

Пока вот научился подменять шрифт в текстовом режиме на свой, просто копируя шрифт в видеопамять по смещению 704 (8 байт в линии - по одному символу в линию):

MySprinter2020-nedoPC-font.jpg

DSS правда ставит обратно стандартный шрифт при любом изменении видеорежима средствами DSS...

P.S. Это nedoPC фонт, который задействован в http://Circuits.CC - там есть сивмолы схемки и платки рисовать

P.P.S. Похоже это старая версия nedoPC фонта - там ноль ещё не перечёркнут - надо исправить

[Lavr]

Получается, что графический режим можно рассматривать как текстовый 80x32 с многоцветным шрифтом в 3072 символов (тайлов)

То есть текстовый - не аппаратно текстовый? Не как ВГ75?

[Shaos]

Получается, что графический режим можно рассматривать как текстовый 80x32 с многоцветным шрифтом в 3072 символов (тайлов)

То есть текстовый - не аппаратно текстовый? Не как ВГ75?

Я так понял, что там всегда текстовый/тайловый режим, просто в "графическом" режиме знакоместа ссылаются на линейно расположенную видеопамять, создавая иллюзию графического режима, т.е. в Спринтере шрифт может складываться из любых квадратиков 8x8 раскиданных по видеопамяти с шагом 8 пиксeлов и собиранием всего этого для каждого кадра занимается альтера, т.е. это всё как бы "аппаратное"...

P.S. А вот честно это всё эмулить в моём эмуле будет несколько нетривиальным занятием

[Lavr]

Я так понял, что там всегда текстовый/тайловый режим, ...

Это типа как в NES-Famicom-Денди?

[Shaos]

Я так понял, что там всегда текстовый/тайловый режим, ...

Это типа как в NES-Famicom-Денди?

Ну я незнаю как в денди было, но там как-то похуже графика была вроде как

P.S. Самое интересное, что такая аппаратная реализация видео замечательно укладывается в мою концепцию nedoPC SDK (ранее известную как RW1P2), где программа, написанная на языке высокого уровня Робби (ранее известном как RW1), оперирует с цветными тайлами 8x8

P.P.S. Тут даже можно пойти ещё дальше, и сделать возможным поддержать несколько типов тайлов на той же самой сетке:

- 8x8 256-цветов (из 4 палитр 16 миллионов цветов);
- 16x8 16-цветов (из 4 палитр 16 миллионов цветов);
- текстовый тайл с одной широкой буквой (2 цвета);
- текстовый тайл с двумя узкими буквами (2 цвета);
- режим когда одна половинка тайла - графика, а вторая - текст (пока не проверял).

Вобщем по этому вопросу будет новый топик - библиотека deTiles

[Lavr]

Я так понял, что там всегда текстовый/тайловый режим, ...

Это типа как в NES-Famicom-Денди?

Ну я незнаю как в денди было, но там как-то похуже графика была вроде как

Не знаю, чем уж она там "похуже графика" - какую сам подставишь, ту и отрисует...
Я само слово "тайл" впервые "вкурил", программируя NES-Famicom-Денди:
viewtopic.php?f=104&t=17703#p137990
До этого просто не сталкивался...

[Shaos]

Похуже в смысле там нету 256-цветной палитры как на Спринтере, причём каждый цвет это полноценный 24-битный RGB...

[Shaos]

Вот ещё фоток с экрана с загруженным nedoPC шрифтом

MySprinter2020-nedoPC-font2.jpg

MySprinter2020-nedoPC-font3tasm.jpg

MySprinter2020-nedoPC-font4tasm.jpg

Как можно видеть TASM не меняет режим когда запускается, предполагая, что режим был текстовым

[Sayman]

Да, и правда, TASM нее включает принудительно и даже не смотрит на активный режим экрана. баг!
зато теперь понятно, почему оно вызывает RSOD:

Code: Select all

NoSetup	IN	A,(#82)
	PUSH	AF
	LD	BC,#1FFD
	SUB	A
	OUT	(C),A
	LD	C,#F1
	CALL	#3D14     ;!!! вотафак?
	SUB	A
	OUT	(#FE),A
	INC	A
	OUT	(#C9),A
	LD	BC,#1FFD
	OUT	(C),A
	LD	C,#02
	RST	#10
	LD	C,#01
	RST	#10
	LD	A,(MP1)
	OUT	(#82),A
	LD	A,(MP2)
	OUT	(#E2),A
	POP	AF
	LD	(DOSpage),A
	LD	A,(DP1)
	LD	(DialogPg1),A
	LD	A,(DP2)
	LD	(DialogPg2),A
	LD	A,(Cp1)
	LD	(CnTxtPg),A
	LD	A,(Cp2)
	LD	(HelpPage),A
	LD	A,(AP)
	LD	(AsmTabPg),A
	SUB	A
	LD	BC,#7FFD
	OUT	(C),A
	LD	HL,FillEnd
	LD	DE,FillEnd+1
	LD	BC,#FFFF-FillEnd
	LD	(HL),A
	LDIR 
	LD	HL,MoveP
	LD	DE,#F700
	LD	BC,MoveE-MoveP
	PUSH	DE
	LDIR 
	RET

да и кстати, исходники похоже не оригинальные. местами метки явно после дизасма.
надо кого-то привлечь к исправлению тасма.

[Shaos]

я вроде хотел им позаниматься

и кстати если программа текстовая, то несмена режима - не баг т.к. FN например перед запуском любой программы переводит режим в текстовый сам

а если запускаем вручную из шелла, то там точно экран менять ненадо

[Sayman]

это именно баг, т.к. запуск из под FN или шелла ещё ничего не говорит. я могу написать эксплойт, который врубит графрежим и вызовит exec("tasm.exe") и всё...
надо по крайней мере делать провверку тек.режима. если он не текстовый. то включать.
при запуске желательно такой большой программе сохранить экран "консоли", а при выходе его восстановить (заодно убрав после себя мусор, а тасм этого не делает).
плюс вызов 3d14 и т.д. требует напильника в общем.

[Shaos]

ну я так понимаю 3D14 это просто старый способ вызов функций биоса - можно почистить

проверку да - наверное можно вставить

чистку экрана наверное тоже - по идее TASM должен сам уметь шелл внутри себя пускать, чтобы не выходя программки тестить