Орион-128: Софт - поиск и обсуждение

[Denn]

Графический редактор для формата *.4C тоже есть на Орионе. Логика управления там, к сожалению, не очень логичная (на мой взгляд) и он весь чересчур, простите, "гуёвый", в смысле много оконных наворотов, и чтобы добраться до какой-то функции, необходимо долго открывать разные окошки - по пути забываешь зачем шёл ))

Как я понимаю, ЛК описание формата "4C", мягко говоря, не афишировали, так что скорее всего придётся потратить некоторое время на вскрытие.

Касательно монохрома. На мой взгляд интереснее именно родной цветной вариант. Жаль, конечно, что нет белого цвета, но варианты программного замеса пикселей дают неплохие художественные возможности расширения кол-ва цветов. Самое главное это конечно возможность окрашивания каждой точки в свой цвет, это сразу придаёт Ориону оттенок "взрослости", а не "игрушечной синклеровости" байтовой организации цвета.
На Орионе есть ещё моментальное аппаратное переключение палитры 4-цветного режима на альтернативную, думаю этим можно поиграться и "высечь" ещё пучок фантомных цветов.

- - - Добавлено - - -

ivagor, спасибо за инфу, попробую анализировать данные файлов в этом ключе.

П.С. если убрать пп. "1" и "4.1", то получается алгоритм PENX'а для 16-цветного режима

[Advertiser]

[ivagor]

Добавил про картинки без сжатия.

[Denn]

ivagor, спасибо! Коротко, без лирики и по делу!

- - - Добавлено - - -

ivagor, возник вопрос по параметру "не 00". В файлах, которые у меня, это FFh. Или всё же могут быть варианты?

1.1. "не 00" 00 - 4х цветная картинка (2 битплана)
1.2. "не 00" "не 00" - 2х цветная картинка (1 битплан, 0я страница, т.е. зеленый цвет)
1.3. 00 00 - 4х цветная картинка (2 битплана) без сжатия
1.4. 00 "не 00" - 2х цветная картинка (1 битплан, 0я страница, т.е. зеленый цвет) без сжатия

[ivagor]

SHOW$4C проверяет только "0" / "не 0". А так да, в файлах, которые есть у меня, в качестве "не 0" используется FF.

[Denn]

ivagor, отлично, спасибо!

- - - Добавлено - - -

Всё получилось! Удалось развернуть передний план картинки:






Вот код, если кому-то будет интересно:

; Декодер формата графических файлов *.4C
; (C) 2018 Соловьев Д.Н. /Санкт-Петербург/
; Версия: 1.0

; Создано:  12.02.2018
; Изменено: 12.02.2018

;LdByte:EQU 0F836h
SvByte:EQU 0F839h


Show4C:
; Вывод изображения на экран
; I: [BC]-адрес ЛВУ, [D]-ширина, [E]-высота
;    [HL]-а/н буфера
MOV A,M
ANA A
;<Z>=1 - без сжатия, <Z>=0 - сжатие
INX H
MOV A,M
RRC
; <C>=0 - FG+BG, <C>=1 - FG
INX H
MOV E,M ; [E]=высота
INX H
MOV D,M ; [D]=ширина
INX H
; вывод FG
PUSH D
PUSH B
PUSH PSW
;CZ PLAIN_FG
CNZ UNPACK4C_FG
POP PSW
POP B
POP D
RET; JC OK_RET; только FG
; вывод BG
;JNZ UNPACK_BG

;PLAIN_BG:
;RET


UNPACK4C_FG:
; Распаковка экранных данных в формате 4C
; I: [BC]-адрес ЛВУ, [D]-ширина, [E]-высота
;    [HL]-а/н буфера
; O: [HL]-а/к буфера +1
PUSH B
SHLD M_Unpk4cFG
POP H
MOV A,E
STA M_Unpk4cFg1E
STA M_Unpk4cFg2E
MOV A,L
STA M_Unpk4cFg1L
STA M_Unpk4cFg2L
CALL Unpk4cFG
LHLD M_Unpk4cFG
RET

Unpk4cFG:
;CALL GetBYTE
PUSH H
LHLD M_Unpk4cFG
MOV A,M
INX H
SHLD M_Unpk4cFG
POP H
RLC
ANA A; <C>=0
RAR
MOV C,A
JNC Unpk4cFgSame
; серия разных

Unpk4cFgDiff2:
;CALL GetBYTE
PUSH H
M_Unpk4cFG:EQU $+1
LXI H,0
MOV A,M
INX H
SHLD M_Unpk4cFG
POP H
MOV M,A
; Получить адрес следующего байта экрана
INR L
DCR E
JNZ Unpk4cFgDiff3
M_Unpk4cFg1E:EQU $+1
MVI E,0
M_Unpk4cFg1L:EQU $+1
MVI L,0
INR H
DCR D
RZ; конец экрана

Unpk4cFgDiff3:
DCR C
JNZ Unpk4cFgDiff2
JMP Unpk4cFG

Unpk4cFgSame:
; серия одинаковых
;CALL GetBYTE
PUSH H
LHLD M_Unpk4cFG
MOV A,M
INX H
SHLD M_Unpk4cFG
POP H

Unpk4cFgSame2:
MOV M,A
; Получить адрес следующего байта экрана
INR L
DCR E
JNZ Unpk4cFgSame3
M_Unpk4cFg2E:EQU $+1
MVI E,0
M_Unpk4cFg2L:EQU $+1
MVI L,0
INR H
DCR D
RZ; конец экрана

Unpk4cFgSame3:
DCR C
JNZ Unpk4cFgSame2
JMP Unpk4cFG

END

- - - Добавлено - - -

add...
Все, встречающиеся мне картинки в *.4C (в т.ч. продукты сохранения граф. редактора) - в сжатом формате. У меня возникает вопрос, а существуют ли в природе несжатые варианты? И для чего оно такое может быть нужно?
По скорости вывода ощутимой разницы не будет. Хранить несжатую графику нерационально. В чём профит?

[Lethargeek]

Захват видео в цвете - намного сложнее, но главное бесполезен, т.к ОРИОН не может это отобразить. Зато в монохроме на экране 384*256 при 4-х градациях серости на каждую точку вполне удаётся отобразить фотографии. В монохроме даже Commodore-64 (не имеющий 4-х градаций серости, что имеются в ОРИОНЕ) на своём крошечном экранчике 320*200 вполне разборчиво отображал фотографии

ну еще бы, ведь в бездуховном басурманском комодуре градаций ПЯТЬ (кроме чёрного и белого - серых ТРИ)

[Error404]

Мне для работы в ORDOS с дискетами вполне хватает зашитой в ROM-диске программы JINN. Вполне удобно обмениваться файлами между дискетой и RAM-дисками в стиле NC.

Вложение потерялось

[VituZz]

Так вроде никакого вложения не было...

[Error404]

Так вроде никакого вложения не было...

Так и я о том же.
В контексте упоминания никому не известной, но небезынтересной программы. Какой формат дискет она поддерживает?

[VituZz]

Невероятно, чтобы это была неизвестная программа... JINN10$, автор - Крышталь А.П., сентябрь 1994 г. Работает, как сказано в её описании, с любым "Монитором", ОРДОС и дискетами CP/M.

Хотел зафоткать внешний вид, включил "Орион" - клац, и дымок! Монитор сгорел... ГРПШЦ!!! Опять ремонтировать... Пока вот нашёл старую нерезкую фотку, так что звыняйте!

Слева - панель с user-ом, справа - диски B, C, D.