TS Forum

А вот картинка этого же эффекта Rage на ламповом пентагоне:
http://zx-pk.ru/attachment.php?attachme ... 1367664905

introspec wrote:А вот картинка этого же эффекта Rage на ламповом пентагоне:
http://zx-pk.ru/attachment.php?attachme ... 1367664905

1 пиксель?

Ага. В динамике не очень хорошо видно, но когда замедляется - увы. Нужно запретить этот пиксель законодательно :)

На бейзконфе тоже 1 пиксель, только в другую сторону смещен:

Кстати, чем больше я на этот разброд и шатание с пентагонами любуюсь, тем больше мне нравится наше решение рисовать пикселами 8х1.
С таким раскладом плюс-минус пиксель почти не светится, имхо.

Sergey78 wrote:Слева дефолтный ИНТ, справа HSINT=1:

Выход настоящего ёжика - вынести обцию в биос

introspec, ложку дёгтя в бочку твоего мёда - порты SMUC-2:

Code: Select all

PORT              ADRESS          DECODING
hex/dec         A15 ... A0       A15 ... A0          READ            WRITE
--------------------------------------------------------------------------------
#5FBE/24510  0101111110111110 0x011xxx101xx110 Revision               -
#D8BE/55486  1101100010111110 1x011xxx101xx110 IDEdata-hi        IDEdata-hi
#F8BE-#FFBE  11111CBA10111110 1x111CBA101xx110 IDEcs0/cs1        IDEcs0/cs1

Black_Cat wrote:introspec, ложку дёгтя в бочку твоего мёда - порты SMUC-2

Ничо, прорвёмся, - ребята проверяют три старших бита в младшей половинке как "101", а у меня там будет или "000" или "111". Мой говномёд говнокод голыми руками не возьмёшь :)

Ну как, формат хранения какой-то нарисовался уже?

moroz1999 wrote:Ну как, формат хранения какой-то нарисовался уже?

съедобный для БК.

ебаная Орега, как поставил новую, так и плююсь с неё..

moroz1999 wrote:Ну как, формат хранения какой-то нарисовался уже?

Двоичный формат я уже дважды менял, и раз программа всё ещё не закончена, пока открывать не хочу.
В то же самое время, я собираюсь сделать сборщик, для ассемблера, в котором художнику нужно будет только приготовить картинку в спец. формате и скормить её сборщику, который приготовит просмотрщик. Формат картинки для сборщика будет текстовым файлом вот такого вида:

Code: Select all

 BORD_UPPER 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,2,2,2,2,2,2,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ; 64 строки верхнего бордюра вот такого вида (48 знакомест)
 BORD_SCR 2,2,2,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,2,2,2,2,2 ; 192 строки экрана (учитываются по 8 знакомест слева и справа; 32 знакоместа под экраном игнорируются)
 BORD_LOWER 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2 ; ещё 48 строк бордюра под экраном (48 знакомест)

Пробел в начале каждой строки принципиален. Размер итоговой картинки - 384х304 пиксела. Любой конкретный компьютер/монитор будет обрезать части изображения по краям. Например, только пентагон сможет показать все 64 строки бордюра над экраном. В то же самое время, число строк, которые можно нарисовать под экраном, на классике - больше.

Ноосфера иронически прокомментировала выбор итогового разрешения: 384х304 :)
Если честно, я так и не услышал более-менее внятных аргументов уменьшить разрешение до 360х288. Как я это себе понимаю, выигрыш от такого решения будет такой: всё, что нарисует художник, будет 100% показано на современном цифровом телевизоре. Но при этом я вижу и недостаток: многие эмуляторы, тот же Unreal, может показать именно 384х304 и тогда поля окажутся замусоренными. Старые аналоговые телевизоры, с одной стороны, гораздо более агрессивно обрезали кадр, а с другой - позволяют заглянуть туда, куда современный цифровой телевизор не может.
Поэтому я решил взять размер с небольшим перехлёстом. В плане памяти, это копейки. В плане сложности рисования, ничего не меняется. Я просто не вижу серьёзных причин не сделать 384х304.
При этом, могу порадовать радетелей за 360х288. На гигабордере и мультигигабордерскрине ширину, скорее всего, придётся уменьшать; думаю, даже, не до 360, а до 352. Впрочем, об этом пока думать рано.

Народ, кому тут бордер небезразличен? надо бы погонять просмотрщик на реалах и посмотреть, насколько плохо (или хорошо) он работает. Сейчас реализована поддержка всех сортов классики, пентагона и пентевы. Скорпион прямо вот сейчас пока не готов, но на днях добавится поддержка и жёлтого, и зелёного. Если есть возможность запустить тапок на вашем реале, стукните, плиз, на zxintrospec@gmail.com

Кого ещё из клонов я незаслуженно обошёл вниманием? если найдутся тестеры, в большинстве случаев сможем добавить поддержку. Если trd удобнее на реале - могу легко доделать и trd. Короче, дайте знать, сделаем в лучшем виде.

Пентеву я могу погонять.

TS-Labs wrote:Пентеву я могу погонять.

Бросил тапку на мыло, глянь, когда сможешь.

На тсконфе тапки нечем грузить пока. Смогу тока на бейзе.
Кинь в нетапке.

TS-Labs wrote:Кинь в нетапке.

OK, через пару часов будет и нетапок :)

Наро-о-о-о-од! Кто может бордер на реалах потестить? Нужны добровольцы на 2 вида скорпионов (желтые и зелёные) и на профи.
На классике кое-то проверено, кое-что - нет, но про классику я даже спрашивать боюсь :)
На пентеве всё вроде работает, хотя вопрос о сдвиге экрана по умолчанию тут уже обсуждался.

Я бы рад, но у меня реала уже четыре года как нет. Был ATM2, но сдохло что-то в районе памяти, а поискать причину тут в эстонии некому.
Я уже задумался о приобретении пентевы, пока недопц не раздумали их делать.

moroz1999, эх, про поддержку АТМ2 я тоже думал, но что-то читая доки складывается ощущение, что выйдет если только цвета ограничить.
Хотя показания эмуляторов реально не сходятся :)

moroz1999 wrote:Ну как, формат хранения какой-то нарисовался уже?

moroz1999, я буду делать вот так: http://pastebin.com/kjH5HFTM

Эээ. Фигово, что прибито к знакоместам.
1. Надо чтоб минимальный элемент изображения был не меньше одного аута (24 пикселя) - нафига тратить впустую байты?
2. Чтоб позиция элемента была произвольная, с известными ограничениями.

TS-Labs, для "неприбитых" к знакоместам изображений в любом случае нужен будет отдельный формат. Тут - некий компромисс между простотой отрисовки и простотой подготовки файла. Примерно из похожих соображений, хранятся байты вместо минимальных элементов т.к. около краёв изображения и экрана можно эти требования расслабить (т.к. реально просмотрщик рисует 52 знакоместа в случае полных строк и по 12 знакомест по сторонам экрана).

Т.е., мы обсудили, хотим ли мы сейчас делать что-то совершенно универсальное и поняли, что не хотим. Поддержка исключительно пентагона нас в любом случае пока не интересовала (тем более, что там придётся менять формат, из-за более высокого разрешения бордюра и растущей одновременно с этим памяти). Поэтому, пока во всяком случае, нас больше прельщает иерархия форматов вместо одного формата и иерархия просмотрщиков, вместо одного универсального. Это компромисс, но он позволит нам сделать нужный софт сейчас, а не кормить людей завтраками.

Ясн.

introspec wrote:moroz1999, я буду делать вот так: http://pastebin.com/kjH5HFTM

спасибо, начал разбираться.

192x[4+4] for 192 lines of the screen, 8 border "pixels" are stored to
the right of the screen and 8 "pixels" to the left;

Не совсем понял - сначала идут из правой колонки, а потом из левой?
Если всё ок, завтра запилю оба формата.