- вон чего ММ сотворил
-
? BD - 18.08.2018 18:01
http://zx-pk.com/forum/viewtopic.php?f=7&t=10561&p=106782
ЭСППЗУ, перешивается прямо на БК.
тестировать буду в сентябре, пардон.
-
? RADIX50 - 23.08.2018 10:23
SUBJ: "ЭСППЗУ,перешивается прямо на БК"
...Внутрисхемное программирование! Жаль,не было такой возможности в 80-е годы! :)
Да,тоже пристально наблюдаем за ходом разработки!.. Весьма нужная весчЪ! :)
-
? BD - 24.08.2018 15:18
на STM32F205 уже давно было, ради экономии драгоценных РР-ок.
http://forum.pk-fpga.ru/viewtopic.php?f=43&t=5450
-
? RADIX50 - 24.08.2018 23:10
TO: BD
SUBJ: ЭСППЗУ
...Ну,да,окромя RE-эмулятора(от VSlav'а,если не путаю..). Но,насколько помню,его сделали в неск. "стэндовых" экземплярах, и усе )) ..А,да,еще попадалась на какой-то из барахолок(типа ныне уже не существующего "молоток-ру") новодельная "БК-0011" с установленной RE-эмулятором(вроде как,с закачанными сразу несколькими прошивками;вопрос,правда,как они переключаются - определяет сам "RE-эмулятор",выдавая нужную по требованию системной платы при перезагрузке и смене режимов - напр.,выбор "Монитора" или "BASIC"'а?..). И как-то там была путанно объяснена причина продажи(так и не удалось выяснить - технол./производст. брак или еще что-то не работало?), а потом лот был несколько раз перекуплен участниками,а потом вроде как снят с продажи(а может,"сдох" вместе с самим сервером "Мешка"),и после этого момента дальнейшая история того лота мне не известна..
-
? RADIX50 - 24.08.2018 23:40
TO: BD
SUBJ: ЭСППЗУ(2)
Против RE-эмулятора ничо не имею(вещь нужная), но рад,что идея сделать "одиночный"(на 1 образ/бинарник,но хорошо и удобно перешиваемый) "pin-2-pin" аналог КР1801РЕ##/РР## все же нашла воплощение(кстати,помнится,я на форуме ранее как-то ее высказывал,но народ вроде как сошелся к мысли,что РР'ок и так вроде бы еще много,да и "скоро на подходе RE-эмулятор от VSlav'а",потому на какое-то время "заглохло").
О возможности внутрисхемного программирования я в тот момент,кстати,как-то даже не подумал.. :)
...Кстати, в журнале "М.П.С.С." за 1984..-какой-то год, был вариант электронного (ОЗУ/ПЗУ)-диска(смотря какие м/сх поставишь) для ДВК,объемом килобайт на 256..512, каждая "ячейка"("кластер"?) которого выполнена на 2 м/сх "обычного" 8-бит ПЗУ(типа 2764..27512) с КР556РТ5 в качестве аппаратного "декодера" выборки байта/слова(т.к. шина мультиплексированная); причем,при установке в набор м/сх другой емкости требовалось перешивать 556РТ5-ю под каждую м/сх своего объема (табличка прошивки "РТ"-шки для м/сх соотв. емкости приводилась в статье).
Возможно,это было сделано из-за отсутствия в 80-е гг в СССР микросхем с 16-битовой разрядностью; сейчас для такого "диска" можно было бы применить флэш-РПЗУ типа "28F2048-16A"(или как бишь она там точно называется),именно с 16-бит ячейками, или аналогичное стат.ОЗУ с батарейкой/ионистором в качестве резервного питания и аппаратным/программным запретом записи, в наиболее компактном корпусе и доступности(цена/доставка).
.. Правда,RE-эмулятор вышел компактнее(в габаритах DIP28), но,в общем случае, размеры "аналога" я считаю не особо критичными: т.к. ту же конструкцию,как у MM,вполне можно подключать к схеме,выведя с платы "косичку" под "ответную" колодку-"DIP",которой эмулятор и подключается к рабочей ЭВМ заместо своего "заводского" прототипа(чтобы облегчить снятие/замену в случае ремонта или необходимости).
-
? BD - 25.08.2018 19:46
у меня было "энегронезависимое ОЗУ" 16Кб в 1988 от товарища Зальцмана. адреса (120000-140000-160000) на БК10 переключались тублерами ))
-
? RADIX50 - 25.08.2018 22:35
To: BD
RE:"энергонезависимое ОЗУ 120 000 - 160 000":
Да хоть как бы переключались,главное,шоб работало! ) Сейчас можно сделать "модняво", джамперами! )
Подключалось "вторым этажом" в КНГМД или вешалось на разъем МПИ?
...А схемку в студию можно? ;)
-
? Александр... - 26.08.2018 11:37
Это, наверное, схема, которая потом в ВТиП публиковалась. Она простая. Вешалась на МПИ. На РУ10. Он только не сделал W/B декодер.
-
? BD - 26.08.2018 13:53
да, на РУ10, втыкалось в МПИ. КНГМД тогда не было ))
-
? BD - 26.08.2018 17:38
----
Ну,да,окромя RE-эмулятора(от VSlav'а,если не путаю..). Но,насколько помню,его сделали в неск. "стэндовых" экземплярах, и усе ))
----
Voland новодельные БК комплетует ими давно, у меня есть.
----
вопрос,правда,как они переключаются - определяет сам "RE-эмулятор",выдавая нужную по требованию системной платы при перезагрузке
----
он подменяет все ПЗУ БК11М, включая бейсик, в работе ничем не отличается от обычной БК11М.
вопрос в том, что STM32 прошиваются через UART на РС вместе с кодом программируемой логики (ну как флоппи-эмулятор). этим владеют Vslav и Kisser.
MM же сделал флешку + софт-прошивальщик для БК - извращайся как хочешь прямо на БК ))
-
? Vslav - 26.08.2018 18:39
>>что STM32 прошиваются через UART на РС вместе с кодом программируемой логики (ну как флоппи-эмулятор). этим владеют Vslav
По РЕ-мулятору никаких скрытых сакральных знаний нет, лицензия свободная и бесплатная, абсолютно все открыто - схемы, платы, исходники прошивки, хорошо документировано (подробный документ написан отдельный, на русском языке) и выложено в открытый доступ - весь код для stm32, утилита прошивки с PC и прочее. Внутрисхемное программирование (от PC, не вынимая изделия из панельки БК) РЕ-мулятором поддерживается сразу "из коробки". Другое дело, что это все никому нахрен не нужно и разбираться никто не хочет от слова совсем.
¤
Даже Воланд выпустил полсотни ремулей не от хорошей жизни - остатки 1801РР1 дефицит, цены на них ползут вверх и РЕ-мулятор уже хорошо выигрывает по себестоимости. Но про внутрисхемное программирование вопрос задал по почте только один человек. Всех устраивает стандартный набор прошивок от БК11М - монитор+васик.
-
? RADIX50 - 29.08.2018 17:47
RE:"внутрисхемное программирование": про наличие RS232(или USB)-порта на плате RE-мулятора я в курсе(он виден,в т.ч.,на фото).
Под вн.сх.-программированием имелось в виду возм-ть прошивки 573РР##/1801РР##,не снимая ее с панельки на плате БК / блока МСТД, без программатора(которых тогда в наличии и не было нигде,кроме как на заводах у самих разработчиков). Вычитав в справочнике по м/сх о наличии перешиваемых 573-х и 1801-х чипов, долго не мог понять,почему нет такой возможности делать это прямо в блоке МСТД(допустим),не вынимая ПЗУ из схемы,как,напр., на материнках IBM PC и их аналогов(на той же "5SVA" или "MVP4" сам перешивал BIOS таким способом); (отсюда и название - "внутрисхемное").
...
Еще хотелось бы уточнить(или прошу напомнить,если уже говорилось/тема была ранее): насколько помню,какие-то определенные партии заводских м/сх КР1801РР## имели своего рода "дескриптор","указатель" адреса(рабочего?) прошивки,размещаемой в ПЗУ как таковой(если смотреть сам бинарник - то размещалось где-то в первых байтах файла), и там был такой момент,что этот "адрес" было можно изменять только в сторону увеличения(поправьте,если путаю..), т.е., напр., если предыдущий раз "шили" программу для запуска с адр. "100 000", то в следующий раз нужно шить уже с адреса "120 000", "160 000" и т.д.(ну или примерно в таком духе).
Можно уточниться,зачем так сделано для ПЗУ типа "РР1"(флэш-память с эл.стиранием и перезаписью)? Ну,для каких-то экземпляров "неизменяемых" ПЗУ типа "1801РЕ##",предназначенных для конкретных случаев, этот адрес,может,и нужно было делать "фиксированным"(одна ЭВМ стартует с "100 000", другая со "120 000"), а для ЭСППЗУ зачем?.. И что происходило с 1801РР1,когда вот этот "указатель адреса" достигал,допустим,некоторой "верхней" отметки и дальше увеличивать его нельзя(т.к. число выходит за рамки разрядности или за пределы адресн.простр-ва ЭВМ),а уменьшать не позволяет сама м/сх ? Т.е.,по сути,еще исправные РР1(не исчерпавшие ресурса перезаписи ячеек) приходилось выбрасывать(не использовав ресурс полностью)?.. При электрическом стирании "РР1" на программаторе(сбросе ячеек в исх. сост. по всему объему м/сх) разве все указатели не "сбрасывались" тоже в "начальное" состояние(позволяющее потом при следующем программировании,именно с записью нового бинарника,записать и новый указатель "адреса старта" ПЗУ)?.. Или это была нестираемая группа ячеек по типу "Бут-Блока" в м/сх типа "28F1000"(куда пишут BIOS для IBM PC-материнок)?..
Насколько знаю,"SPECTRUM" и IBM PC(и еще какие-то представители микроархитектур того времени) при подаче питания стартуют с адреса "000000";в МП машин типа "HP/UX", DEC/Alpha и аналогичных, в принципе,предусмотрена техн. возм-ть стартовать "с любого" адреса(что в целом,удобно,т.к. адрес возможно варьировать под конкретные варианты применения таких вычислителей: грубо говоря,запускать что-то "свое" вместо штатного "Монитор'а" или "Фокода",не трогая остальную "раскладку" адресов для др. программ; либо "передвинуть" тот же "Монитор",запустив/разместив его "с другого" адреса,так сказать, "в пользу" своего самопального ПЗУшного отладчика). Но мне немножко не совсем понятна реализация такого "указателя (...начального...? ) адреса" в м/сх типа 1801РР##: зачем именно "так" было сделано(с увеличением номера адреса)?..
...А если скопировать "стандартную" прошивку из "1801РЕ##"("неизменяемую") в равную ей по объему "1801РР##",сделав полный бинарный "образ"(программатором), - то,с учетом вот такого "увеличивающегося" указателя, - будет ли "копия" "заводского" ПЗУ работоспособна(если в "РЕ-шке" имеется такой же "указатель", и он окажется "меньшего" значения,чем уже имеющийся в "РР-ке",подготовленной для записи копии этого образца)?
..Подскажите,плиз (или напомните,где посмотреть,если где уже обсуждалось ранее),буду очень признателен. :)
...
А как решается этот "вопрос" в обоих вариантах разработки "RE-эмуляторов"-аналогов(как они "управляются" с этими "начальными указателями": меняют при заливке бинарника или выдают нужные значения "на ходу" при запросе от МП на чтение ПЗУ)?..
...
В любом случае,обе разработки хороши,нужны и имеют право на существование.
У каждого,конечно,свои предпочтения(при работе/обслуживании), но лично я предпочитаю работать с ПЗУ с помощью программатора(так в больш-ве случаев надежнее); но при отсутствии оного, в ряде случаев, удобнее,когда есть возм-ть обновить/считать/зашить "прошивку" не вынимая ПЗУ с системной платы (как на IBM PC в "горячем" режиме с помощью утилит типа "MOD-BIN" + "AWDFLASH"/"BFLASH").
-
? Alexander "Sandro" Tishin@ - 30.08.2018 18:41
У 1801РР1 это не "стартовый адрес", а адрес, с которого ПЗУ будет располагаться в адресном пространстве машины. Программируется отдельно от данных. Так сделано, чтобы микросхеме не требовался внешний дешифратор старших разрядов адреса.
-
? BD - 05.09.2018 17:32
http://www.phantom.sannata.ru/forum/index.php?t=29829&p=464704#pp464704
¤
это всё. "платку" сам не соберешь без шаблона на пасту. требуйте готовый экземпляр.
-
? S_V_B - 06.09.2018 16:47
Продайте кто-нибудь 3 микросхемы ВАСИКА для 11м,а то ВОЛАНД плашку приложил.., а ПЗУ нет.. как бэ вакуум образовался..
-
? BD - 06.09.2018 17:42
а зачем? см. BASIC11M на дисках мкдос, андос, ксидос.. в реале ПЗУ не используется, когда хочешь доступ к диску.
-
? S_V_B - 06.09.2018 17:59
что бы вакуума не было :)
-
? BD - 06.09.2018 18:48
пиши воланду. у него куча нерабочих бк11м.
http://zx-pk.com/forum/viewtopic.php?f=35&t=9325
-
? S_V_B - 06.09.2018 19:38
Да Чего-то он молчит.. хотел у него пленки на клаву взять.. и тишина... может не те суммы :)
-
? microxa - 12.03.2019 16:12
Да.. ну, RE-эмулятор от VSlav'а, это шедевр.. Наверное если насадить на стм32 сдвиговые регистры (что то типа к155ир13), и можно и ВП37 заэмулить, а?
¤
А вот трайдент9000 исовый.. Помню его по Quake-1 в DOS-е.. Тормоз тот еще... В 486ых bios можно было множитель накрутить, гдето была 5метров аж пропускная. Максимум 360х480 можно было отжать, более-менее играбельных, на разогнаном до 166мгц AMD5x86-133.
¤
Сравнивал с пневыми конфигурациями (via586/PentiumMMX-233, via694T via-PIII-Tualatin 1300), тормозили они об пропускную (которая ни в биосе и вроде как в самих регистрах чипа уже не устанавливалась).
¤
Короче даже на таких космических скоростях, было то еще.. слайд шоу..
¤
А программировался то вообще мрак. я както переделывал эмуль Дмитрия Тюрьева под комбинированый (чб+цвет) графон так это.. всё, проклял... 640Х350 устанавливал. 16цветов. и какойто капец был по коду.
(впрочем все тоже самый квест имеется и на встроеном Ынтел 3150).
¤
Разве что текстовый графон 80х25, всетаки шедевральный. Сравнительно недавно узнал что аж
160x100 16 color можно с него отжать.. https://deathshadow.com/pakuPaku
не знаю, не знаю.. осилит ли трайдент такой изврат. но атомная встройка тянет. я аж был в шоке с этого паку пак пакмана-нах..
-
? microxa - 12.03.2019 16:43
хотя какие нафик 155ир13... Под LCD экранчик-то.. 16битные вродеже есть. с 640х480.. или нет..
-
? BD - 12.03.2019 18:56
microxa, у тебя реальный, работающий БК есть? нефиг напиваться и ностальгировать с написанием эмуляторов, хотя ты в этом крут. у нас стоит задача уже, чтоб реальную БК подружить с PC с реальным доступом к диску через wifi.
gid реализовал ИРПС, но не все работает и софта нет.
-
? BD - 12.03.2019 19:03
http://forum.pk-fpga.ru/viewtopic.php?f=15&t=5606
-
? microxa - 12.03.2019 20:09
>>microxa, у тебя реальный, работающий БК есть?
BD,
Ой чур, чур меня.. Хватает его имитации, c "эффектом дежавю".. на мелком нетбуке..
p.s
писюки то, вон.. оказались кидаловом.. а это вообще.. впрочем.. не знаю что "это было.."
-
? BD - 12.03.2019 20:53
https://play.google.com/store/apps/details?id=su.comp.bk
¤
гениально. но эмулятор лишен возможнотси общаться с внешним миром. для это надо посмотреть исходки gid, для эмуляцци регистров ирпс. мы, с S_V_B
очеееень будем благодарны ))
-
? microxa - 12.03.2019 21:59
>>для это надо посмотреть исходки gid, для эмуляцци регистров ирпс
ну вроде как сделано на прерываниях и адресах. мне не знакомых
default:
case MODE_V060:
addr = 0177560;
vec = 060;
break;
¤
case MODE_V360:
addr = 0176560;
vec = 0360;
break;
¤
case MODE_V370:
addr = 0176570;
vec = 0370;
break;
¤
Для меня этот ИРПС ограничивался 1777714-ым портом. Были какието там попытки 1777714-ый порт напрямую в LPT (в 8битном режиме) перенаправлять.. Хренью глюкавой какойто все кончилось :)
-
? Manwe - 10.04.2019 09:50
Очень странная пара переключателей торчит. Обломать ножку в процессе переключения – как нечего делать. Гораздо эстетичней и надёжней заменить их на обычные джамперы.
-
? BD - 11.04.2019 00:56
ничего не надо. надо только соплю бросить на сигнал DOUT от проца. можно просто снимать контакт, когда перепрошивка не требуется. там 2 светодида - процесс показывается )) можно на МПИ вывести DOUT и использовать плату МСТД для экспериментов. софт под rt-шку, правда пока, т.е. нужен двойник МПИ.
-
? svinka - 11.04.2019 01:49
для экспериментов не только плату МСТД использовать но любую другую где есть место под ПЗУ типа КР1801РЕ2. Например контроллер НГМД.
#
Хотелось бы программатор для УП.
-
? BD - 11.04.2019 12:36
svinka, на УП без извращений не получится.
"Заготовки" валяются уже полгода, ввиду слепоты, кривых рук и лени так идею и не опробовал..
¤
https://i.ibb.co/QXMjcQw/4309.jpg
-
? sav - 26.04.2019 14:55
Интересно, а почему подавляющее число ретро компов использовало для доступа к памяти жесткий цикл - доступ процессора /доступ видеоконтроллера? Если установить дополнительный буферный регистр перед сдвиговым регистром и дважды в него записывать данные, а в конце второго цикла перезаписывать их в сдвиговый регистр, то процессору можно забирать ближайший цикл, а не ждать своей очереди. Память побыстрее работать будет, уберутся циклы 1.3 мкс. В той-же ВП 037 для этого можно было бы использовать 26-27 ноги, а тестовый режим сделать как в 030/013. Однако...
-
? RADIX50 - 26.04.2019 23:21
TO: SAV
SUBJ: "дважды в него записывать данные...", "процессору можно забирать ближайший цикл,не ждать своей очереди..."
RE: %SUBJ%
...
Если ничего не путаю,то тов. KISSER в спроектированной им примочке "BK_SVGA"(которая на микроконтроллере) как раз использовал примерно похожий принцип. Дословно не помню,но что-то вроде "..получаются 2 копии содержимого видеоОЗУ + 2-кратная перезапись/обновление"; но его разработка почему-то подверглась некоторой.. ну.. критике, - как раз именно из-за вот этого "2-кратного повторения/хранения"(содержимое базовой видеоОЗУ "БК-001#" дублировалось в местном ОЗУ микроконтроллера); да плюс еще тогдашние "тролли"(коих тут обиталось одно время в те годы довольно заметное количество),не имевшие особого интереса/отношения к теме (возрождения)БК, "подливали масла" в огонь,конфликтуя с участниками форума.
Не знаю,как кому,но мое мнение такое: приставка свою задачу(преобразование БКшного RGB в IBM_SVGA,причем,"на лету") решает? - решает(причем,без вмешательства в электросхему самой БКшки,т.е.,самостоятельно,в режиме "черного ящика")! А уж сколько копий видеокадра там хранится/дублируется, - для данного случая особой разницы не имеет(тем более,что быстродействие и объем своего ОЗУ выбранного KISSER'ом микроконтроллера заметно превосходят "БКшные",т.е., позволяют допустить некоторую "вольность",как в данном случае,позволив себе некоторую "расточительность" в виде 2-й(3-й) копии кадра), - т.к. для хранения основной программы(алгоритма) работы контроллера его встроенного ОЗУ хватало(причем,с "избытком",который можно тоже как-то использовать,"нагрузив" его дополнительными/промежуточными данными,которые "видны" только самому микроконтроллеру и на работу БК никак не влияют).
-
? Alexander "Sandro" Tishin@ - 06.05.2020 11:02
Чего-то раньше пропустил эту тему.
¤
sav, да, это можно и нужно было сделать. В ВП1-37 свободна ровно половина микросхемы, места завались. Реально сложности с размещением и трассировкой БМК начинаются где-то в районе 2/3 .. 3/4 заполнения, зависит от регулярности логики.
¤
Даже если просто уметь использовать текущий цикл, а не ждать следующего, уже можно было бы значительно ускорить всё. У даже реально сделанной БК окно доступа для ЦП составляет 666 нс, а время цикла у 565РУ6В -- 280 нс, время есть (Сколько там у РУ6Г? 350?).
¤
Ну а с регистрами 2x16 можно было бы получить, действительно, мгновенную запись и очень быстрое чтение. Да.
¤
Правда, разработчики 1-37 этого бы точно не осилили :(
¤
В качестве примера: мало того, что у них в кадре не стандартные 312,5 строк, а 320, так ещё и счётчик там зачем-то сделан переключаемый на 256 и 64 строк, по очереди. Зачем так? Нельзя нормально было?
- << Форум