Вид для печати
Совершенно непонятно зачем. На экран обычно пишется информация из других участков памяти, содержащих, скажем спрайты. А читать байт с экрана, чтобы его опять записать в экран - это применительно разве что для скроллинга. Да и то, обычно идет чтение пачкой, и запись пачкой, для скорости.Цитата:
Сообщение от Soplik
В случае, когда всем записываем байтам дается текущий атрибут, находящийся в защелке - более подходящ.
А если три режима -- копирование с атрибутами, с одним атрибутом и совсем без?
Да пожалуйста)Цитата:
Сообщение от Soplik
Хотя три разных режима -- это не Спектрум.
Да и все остальные пункты - это тоже не спектрум)Цитата:
Сообщение от Soplik
Адресацию могли сделать, а цепочку LDI -- забыть в коде.
---------- Post added at 02:17 ---------- Previous post was at 01:58 ----------
А вообще получается, что игровой спектрум -- это денди.
Можно ли турбировать оригинальный 128-й Спек?
Теоретически можно. Только надо знать что куда вешать.
Дело скорее в реализации. РК ограничен ПЗУ и скоростью процессора. Возможно влияла старая элементная база. Читал кажется в Открытых письмах Вектрист эксперементировал с кодированием на ленту в Манчестере и удивлялся почему на спектруме так не сделалиЦитата:
Сообщение от zst
Позволю себе маленький постик.
Как по мне, на той же конфигурации железа стоило бы сделать 3 вещи:
1. Сигнал прерывания надо подавать не во время вертикального хода луча, а сразу после отрисовки области экрана. Так никакого 0хFF не надо.
2. Стандартизировать или (лучше) вывести (хотя бы один) джойстик, причём желательно с двумя кнопками.
3. Горизонтальное разрешение увеличить до 320.
4. Доп графрежим. Горизонтальное разрешение в 2 раза меньше. Но 4 цвета на знакоместо, пусть оно и в 2 раза шире. Тогда хоть частично конфликт атрибутов снимется, в простых играх.
Добавлено.
5. Как по мне, схема отрубания тактирования проца - перебор. Лучше читать данные в регенерационный цикл, а также в просветы между чтением данных МП. В крайнем случае, если мы начали читать и тут процессор припекло - давать сигнал WAIT.
Вы прямо ATM Turbo описали :) Только там вместо джойстика мышь, а вместо прерывания в конце экрана - две экранных области.
Когда я делал свой Специалист на дискретах, я плотно изучил временные эпюры как ВМ80 так и Z80. Я из тех, кто хочет сделать грамотно и без костылей и ненавижу тормозить процессор без крайней необходимости. Скажу, что у обоих процессоров просто куча времени, когда можно спи... :3 украсть память, не нарушая процесс исполнения команды, причем у ВМ80 этого времени больше: он требует данные только по одному перепаду Ф2, а у Z80 по обоим (так уж сделали: М1 по одному и R/W по другому). Заметьте, что по Спец собран и работает, т.е., все выкладки, которые я реализовал в нем после изучения процессоров, верны. Так что это можно применить в этом вашем Спектруме. ;)Цитата:
Сообщение от predatoralpha
Я Вас понимаю... Но Вам проще. У вас только пиксели, без цвета.. Вам достаточно одного такта.Цитата:
Сообщение от HardWareMan
Но я могу понять и конструктора Спектрума. Всё делалось на УЛА с весьма ограниченными ресурсами. Спектруму надо 2 такта - пикселы и цвет. Фифо там вроде нет. Значет, нужен максимально простой автомат - один такт - защёлкивается пиксель, второй такт - цвет.
Вы думаете, почему экран сделан так специфично, что сначала идёт первая строка, потом 8-я и т.п.? А соседние строки разнесены на 256 байт. Только что бы на 1 строку смещаться инкрементом старшего байтика? Это тоже, но есть одно "железное" но. Всё байта знакоместа лежат в одной строке RАМ. Причём в одной же строке лежат не только пикселы одного знакоместа, но и их атрибут. Цикл обращения к видеопамяти специфичен - сначала падает RAS, с защёлкиванием строки, а потом 2 раза CAS защёлкивает адреса столбцов пикселей и атрибутов, причём отсчёлкивается так, что бы данные появлялись как раз в конце такта. Потом уже освобождается RAS.
Я не думаю, что если бы Вам надо было читать 2 байта подряд - Вы бы мягко въехали в процессор. А если не подряд - то это надо фифо и более сложный автомат. Для которого у разработчиков Спека врядли бы было место на УЛА.
ПС. Насчёт цвета погорячился - Ваш клон цветной, как я увидел опосля. Но я не думаю, что у Вас идут 2 чтения поподряд, и без фифо, так что основной посыл поста - в силе.
На ULA+ смотрели ?Цитата:
Сообщение от predatoralpha
А смысл смотреть? Мы ж говорим про 83-й? Там нормально основные цвета не выводились, картинка плыла - а вы про какие-то палитры говорите.Цитата:
Сообщение от Valen
Синклер хотел ставить самую дешевую память :)Цитата:
Сообщение от predatoralpha
Но чередовать строки именно таким образом вовсе необязательно. Подойдет любая раскладка при единственном условии равенства любых семи битов адреса растрового байта и соответствующего атрибутного (в том числе похожая на раскладку Специалиста, растр и атрибуты в одном столбце).
В целом сводится к "именно таким образом - не обязательно, а подобным образом - да." Впрочем, можно ещё "перепутать" адресные линии от процессора, тогда байты могут лежать и даже поподряд... для процессора, конечно. Всё равно регенерирует УЛА.Цитата:
Сообщение от Lethargeek
нет, не сводится, любая значит любая (при единственном условии для быстрого чтения)
из условия должно быть понятно, что потребоваться может и перепутывание
быструю раскладку в духе специалиста иначе и не сделать
Зачем же фифо, вон в некоторых клонах, таких как Пентагон и Орель БК-08, память читается без замедления процессора. На одном триггере и некотором кол-ве мелкой логики реализован арбитр доступа к памяти.Цитата:
Сообщение от predatoralpha
2 Lethargeek
Останемся каждый при своём мнении. Байт и атрибут должны лежать в одной строке. Остальное - ньюансы.
Меня больше интересует, как Вы в своём специалисте это решили. Самая критическая операция от процессора Z80 - вычитка первого кода операции, которая занимает 2 такта. Остальные чтения/записи берут 3 такта, и в них вклиниться легко.
У Вас сколько тактов берёт вычитка байта и атрибута видеопамяти? Вы их поподряд читаете, или можно и прервать? А доступ к памяти для процессора сколько тактов берёт?
---------- Post added at 13:26 ---------- Previous post was at 13:21 ----------
А память с каким временем доступа применяется? Те же 150 наносекунд что и в оригинале или более быстрая?Цитата:
Сообщение от Barmaley_m
зачем?Цитата:
Сообщение от predatoralpha
прозрачный доступ делается очень просто, такты процессора делятся пополам, даже при выборке копа 1 такт можно использовать для целей формирования картинки, видеогенератору надо поток данных в 1.75мгц что ровно в половину меньше частоты процессора. Итого если начинать читать данные в буфер на 1 такт раньше чем надо - получтся, что либо в текущем, либо в предыдущем такте будут данные для видеогенератора. Что бы совместить атрибуты и пиксели хватает 4х битного сдвигового регистра.
---------- Post added at 13:21 ---------- Previous post was at 13:21 ----------
Обычная тормозная РУ5ГЦитата:
Сообщение от predatoralpha
Там же атрибуты в отдельной памяти, напрямую процессору недоступнойЦитата:
Сообщение от predatoralpha
Идея в том, что процессор никогда не допускается на шину памяти дольше, чем на 1 такт. В цикле M1 обращение к памяти длится полтора такта, из них во время одного процессор будет допущен на шину. В остальных циклах обращения к памяти процессор активирует MREQ на 2 такта, и из них опять же, во время одного ему будет предоставлен доступ к памяти.Цитата:
Сообщение от predatoralpha
Процессор обращается к памяти гарантированно не чаще, чем 1 раз за 2 такта, поэтому из каждых двух идущих подряд тактов один можно предоставить видеоконтроллеру, чего как раз достаточно для его нужд. Одно знакоместо по горизонтали занимает 4 такта, для него надо считать 2 байта (пиксели и атрибут).
В советских клонах не используется доступ к памяти в пределах одной строки без активации RAS. Это было бы слишком сложно в реализации.
По 1 такту на то и другое.Цитата:
Сообщение от predatoralpha
Можно прервать. Схема арбитра "Орель БК" позволяет иметь максимум 2 такта между считыванием байта пикселей и атрибута, но на практике больше одного такта не бывает, т.к. процессор никогда не обращается к памяти 2 такта подряд.Цитата:
Сообщение от predatoralpha
[QUOTE=predatoralpha;458699]А доступ к памяти для процессора сколько тактов берёт?[COLOR="Silver"]
1 такт.
Память работает с постоянной частотой RAS и CAS 3.5МГц. Период составляет 285нс - этого достаточно для РУ5В и может быть даже для РУ5Г. Во всяком случае, в большинстве клонов ставится РУ5Г.Цитата:
Сообщение от predatoralpha
Гм..
Как я понимаю, для Спектрума был выбран максимально простой автомат. Два такта чтения (байт и атрибут) и два байта пропуска. Что бы не конфликтовать с процессором - проц просто отрубался.
Не факт, что использование задержек - это самая простая реализация арбитража. В конце концов, им все равно нужно было где-то иметь сигнал конфликта процессора и памяти, нужно было иметь какую-то логику прекращения подачи тактовых импульсов и т.д. В совокупности это может быть ничем не проще, чем реализация "Пентагона" и "Орели" без задержек. Но чтобы предметно говорить, надо рассмотреть оба варианта схемы в пределе их упрощения.
Как по мне, то в оригинальном самая примитивная схема арбитража. Если идет запрос в память/порт, то тупо вырубать. Только для памяти проверяются А14 и А15.Цитата:
Сообщение от Barmaley_m
Вырубается, похоже, на все эти 32 пары чтения, по 4 такта на пару. Какое-либо вклинивание в паузы вообще не предусмотрено. Так что примитивно до ужаса.
Если бы не было 3-х тактового чтения/записи, то возможно что как-то вклинивали бы на 2 такта. А так - сэкономили на тригерах.
Ну вот на каком основании ты так считаешь? Ты сравнивал схему арбитража синклера и советских клонов? Может быть схемы советских клонов с "прозрачным" доступом к памяти даже проще, чем блокирующая синклерская. Схему синклерского арбитража - в студию. Без этого говорить не о чем.Цитата:
Сообщение от predatoralpha
Можешь глянуть, что раскопал Крис Смит:Цитата:
Сообщение от Barmaley_m
http://www.zxdesign.info/docs/waitGen-1.17.pdf
Схема вроде не предполагает вклинивания.
Кроме того есть разные "проще". Есть проще в количестве логических элементов/тригерров. Есть проще в разработке/отладке на макете. Это разные проще.
Спасибо, понятно. Схема довольно сложная. Для сравнения прилагаю схему арбитра памяти Орель БК-08. Как говорится, почувствуйте разницу.Цитата:
Сообщение от predatoralpha
В реальном компьютере вместо IC3A стоит более сложная схема, предназначенная для реализации теневого ОЗУ и других дополнительных возможностей "Орели" по сравнению с оригинальным ZX, а если бы требовалась только функциональность ZX, то достаточно было бы только элемента, который я показал как IC3A. Остальные элементы, показанные на моей схеме, соответствуют реальным элементам схемы "Орели", и я указал их обозначения на схеме DD7.1, DD9.2, DD15.1.
Логика работы этой схемы следующая. Если обнаружено обращение процессора в память по адресам 4000-FFFF - то формируется активный низкий уровень сигнала /CSM - запрос обращения к ОЗУ. Далее, если процессору в этом цикле обращения к памяти доступ к ОЗУ еще не был предоставлен - то с триггера DD15.1 формируется низкий уровень сигнала /HM - это выход арбитра. Он там формируется не более чем на 1 такт, после чего снова возвращается в исходное состояние лог. 1.
Так как циклы обращения к памяти Z80 не длятся более 2 тактов, то за каждое обращение к памяти на сигнале /HM будет сформирован один импульс отрицательной полярности длительностью в 1 такт.
Ну вот, теперь у тебя появилась возможность сравнить обе схемы и проанализировать их. Какая из них, с твоей точки зрения, проще для понимания и наладки?Цитата:
Сообщение от predatoralpha
Сразу видна неприменимость для оригинального Спектрума - на Синклере микросхема УЛА обрабатывала не только память, но и порты. Соответственно, нужен дополнительный арбитраж для портов. А цикл чтения-записи портов уже не 2, а 3 такта. Со всеми вытекающими отсюда последствиями.Цитата:
Сообщение от Barmaley_m
Во-вторых, наличие такого арбитра, что Вы привели, предполагает
а) что УЛА может подождать 1 такт
б) что вычитка байта и атрибута могут быть не поподряд.
Т.е. что упрощение схемы здесь может усложнить схему "там".
А при чем здесь вообще порты? При обращении процессора к портам нет конфликта между процессором и видеоконтроллером, потому что адресное пространство их не пересекается. Как я понял, шина адреса у процессора и видеоконтроллера в оригинальном спеке тоже раздельная, иначе верхняя память тоже бы тормозила.Цитата:
Сообщение от predatoralpha
Мне трудно с этим согласиться. Обоснуйте, зачем нужен арбитраж для портов?Цитата:
Сообщение от predatoralpha
Какими последствиями?Цитата:
Сообщение от predatoralpha
А почему она не может подождать, обоснуйте.Цитата:
Сообщение от predatoralpha
Зачем она должна быть подряд? В этом нет никаких упрощающих схему факторов. Шина адреса у видеоконтроллера отдельная. Он выставил туда адрес байта пикселя или атрибута, и ждет, когда ему будет предоставлен доступ к памяти. Если процессор занял память на 1 такт - то в следующем такте видеоконтроллер получит то, что ему нужно. Если процессор память не занял - то видеоконтроллер считает свой байт из памяти дважды.Цитата:
Сообщение от predatoralpha
Где "там"? Покажите конкретно, что в схеме упрощается из-за того, что процессор тормозит при обращении к памяти.Цитата:
Сообщение от predatoralpha
http://scratchpad.wikia.com/wiki/Contended_IOЦитата:
Сообщение от Barmaley_m
Да уж, как все запущено. Подобные схемотехнические решения вызывают у меня глубокое недоумение. Если кто-нибудь сможет объяснить, что упрощается в схеме благодаря медленной работе портов ввода вывода (по большому счету, единственного порта - FE - так как других не было) - буду премного благодарен.Цитата:
Сообщение от Lethargeek;459776[url
Barmaley_m, Вот схема. У ULA мало ножек, поэтому шина данных медленной памяти и шина данных порта FE совмещены.
Blade, спасибо. Теперь, по изучении схемы, понятно насчет необходимости арбитража портов. Также понятно, что без регистра на выходной шине данных памяти реализовать "прозрачный" арбитраж доступа к памяти невозможно. Память должна держать данные на выходе в течение всего цикла обращения процессора к ней, а не только один такт, как это сделано в "Орели" и в "Пентагоне". Потому что авторы советских клонов решили не ставить резисторы между ШД процессора и памяти, а поставили регистры. Но советские авторы тоже вынуждены были это сделать, так как у синклера, судя по всему, сигналы RAS и CAS на память формируются довольно сложным образом (чтобы память держала данные на выходе более двух тактов). Сэкономив регистр, авторы советских клонов вынуждены были бы поставить несколько корпусов логики, что ни по цене, ни по площади платы выигрыша не давало никакого. А у синклера вся логика в УЛА.
Давным-давно курю эту идею. Буду рад любым тапкам. Итак, техзадание:
Читерским способом за год до офф.выхода Спектрума разрабы имеют его уже готовым.
В смысле классический 48й с 1,2кб пустой дыры в ПЗУ и кучей ошибок.
Производить его в 81м негде, и только-только пошел ZX81й. Зато у них есть год на курение мануалов, в смысле на разработку. Задача та же - максимально дешевый уберкомп.
Прежде нужно посмотреть на ближайших конкурентов, уже имеющихся или перспективных.
Commodore VIC 20, в продаже с 81го до 85го. Базово 5кб.
22*23 символа, 16 цветов по знакоместам, пиксельно макс 88*184*4цвета.
Commodore 64, в продаже с 83го по 93й.
40*25 символов, 16 цветов по знакоместам - 320*200 точек.
160*200 точек, на знакоместо 4*8 идет 3цвета+1фон.
И до кучи куча спрайтов,ага.
Атари... У них дико извращенные цветовые режимы, без поллитры не разобрать - и спрайты, опять же.
Делают с 1979 и до 90го, примерно. На момент выхода "Спека" Atari 400 идет по 160£, с 4мя килобайтами памяти на борту.
В 84м выйдет Амстрад СРС.
Абсолютно без спрайтов, 64кило базово.
160*200*16цветов, 320*200*4цвета и 640*200.
В процессе вылезет Орик, Дракон, и Энтерпрайз. Который самый крутой и у него 256*160*16цветов и 180*80*аж256.
Есть еще Акорновские ВВС и Электрон - 160*256*16цветов, 320*256*4, 640*256.
Из основных конкурентов всё.
В реале Спек был с обычным 256*192*атрибуты = 6912б.
Timex покурил немного травы, и добавил 256*192*мультиколор = 12288, 2 стандартных экрана (как в +128к)=13824 и 512*192*2цв=12288 байт.
===================
А вот теперь вопросы. Если еще подумать, то в 12288б впихуется 4х цветный 256*192, это раз.
В два стандартных (в Timex они рядом в ОЗУ) 13824 байт лезет 512*192 с атрибутами 8*8, а это уже круто для работы.
И в эти же 13824 байта можно вместить 192*144 на 16 цветов. На пиксель.
Если у Амстрада в 84м году 160*200*16ц пошли "на ура", то как такой режим сказался бы на истории ZX в самом начале?
Авиасимы под него были бы красивы...
Кстати, отношение сторон классическое, 4:3.
Ессно это просто гимнастика для ума, но на фоне агрегатов тех лет такой Спек смотрелся бы намного круче...
Спасибо. Хорошо излагаете.
512*192*атрибуты посимвольно 8*8 подходит для НЕ динамичной игры. Был в Profi и с турбой 7-15 Мгц.
Моя мысль наоборот еще ускорить и увеличить качество графики на оригинале. За счет
Другой адресации экрана по столбцам. Предложено и описано Lethargeek В оригинале процедура вычисления адреса минимум 5,5 тактов + таблица 384 байта. в измененной 4 такта 1 команда INC/DEC +768 байт дополнительных атрибутов
Возможен режим как в MSX 64*48 точек каждая точка своим цветом.
И другие аппаратные решения упрощающие жизнь программеру.
P.S. Почитайте тему. Теория: почему 128к игры такие убогие. Пример как сделали в ущерб графике.
Бука, вы забыли еще Apple II с реально извращенным экраном
но при этом 2 областями видеопамяти (идеально для игр)
Этот режим больше для работы с текстом, с CP/M.Цитата:
Сообщение от _Andrey
Читал. Про память я забыл добавить - изначально взять схему банкования от Timex 2068: свободное переключение 8кб банок РОМ и РАМ, не прибитых криво, как в 128к оригинале.Цитата:
Сообщение от _Andrey
Итого до двух мег штатно адресуемой памяти - выше крыши для 8битки.
Да, и первый спек выпускать без разделения на 16-48к.
16к Спек был колоссальной ошибкой!
Туева хуча покупателей увидела рекламу - "16кб памяти, красивая цветная графика, цена 125 фунтиков".
Толпа сложила 2+2, цену ч/б ZX-81го и 16кб к нему - получилось 120ф. И, естественно все потенциальные покупатели zх81 заказали 16к спек.
Результат - продажи ZX81 были провалены, производство завалено заказами на 16к спеки.
Результат 2 - получив вожделенное, пользователи убедились что свободно лишь 9 из обещанных 16ти килобайт. Нормальные игры туда не лезут, значит нужен апгрейд до 48к - а его можно сделать лишь на заводе SRL. И снова был завал из присланных на доработку машин - и это на фоне проблем с ULA и завалом производства.
За год, к маю 1983го было выпущено всего около 300к Спеков. И тогда же пришлось снижать цену до 129ф за 48 и 99 за 16к. Идиотизм...
=========
По уму надо было (как Джек Тремиел с комодом) сразу сделать Спектрум 64к, и если интерполировать цену - то по 199 фунтов толкать.
Команды для RАМ-диска вставить в Барсик сразу же. Кстати, в нем дофига ненужных токенов.
Например LINE - нужна лишь для автостарта загруженной проги, который можно организовать по другому - например SAVE "Prog" GO TO хх, и т.д.
Но это если бы у Синклера были мозги... А он посрался с разрабами, и в ПЗУ навечно осталось почти полкило свободного места.
Организация экрана могла быть более вменяема. Тут предлагали по столбцам, это неплохо для рисования всяких линий, но тогда надо делать либо 256 строк на экране, итого экранная область будет 9 КБ, либо оставить 192 строки и вычисление адреса обратно усложнится.
Есть ещё комбинированный вариант. На экране в одной строке идут байты 16384, 16392 и т.д, на следующей строке идут байты 16385, 16393 и т.д. Т.е., идущие подряд 8 байт относятся к одному знакоместу.
Преимущества:
- при печати текста можно использовать быстрые команды копирования,
- после копирования последнего байта адрес автоматически указывает на первый байт следующего знакоместа,
- автоматический перенос строк, т.к. после вывода последнего символа в строке адрес указывает на начало первого символа в следующей строке.
- одна символьная строка на экране занимает 256 байт, отсюда, чтобы перейти на следующую строку надо увеличить старший байт адреса, чтобы вернуться на начало строки нужно обнулить младший байт адреса,
- вывод спрайтов тоже облегчается. Можно выводить спрайты 16х8 пикселей, просто копируя 16 байт подряд,
- даже при выводе линий и точек вычисления упрощаются и получаются единообразные для всего экрана.
Это дало бы заметное ускорение вывода спрайтов в играх, и даже текста в стандартном бейсике, плюс облегчение программирования. А надо всего лишь несколько линий адреса переставить.