Просмотр полной версии : SD-ROM Картридж
В расширенном загрузчике есть возможность грузить программу с ROM через порт ПУ, в картотеке есть картридж (http://asdasd.rpg.fi/~svo/scalar/ware/675/) который грузит программу которая сканирует ПЗУ их там может быть 7 штук и выводит список записанных туда программ. Подобное для Апогея и Радио 86РК сделал vinxru http://vinxru.livejournal.com/235725.html.
Пока есть схема и разведенная платка.
CodeMaster
21.12.2014, 20:47
в картотеке есть картридж который грузит программу которая сканирует ПЗУ их там может быть 7 штук
Подобное для Апогея и Радио 86РК сделал vinxru
Причём тут картридж? И у vinxru программ может быть не 7, гораздо больше.
Вопрос (реклама)
возможно пременимо и тут
в нашем проекте для корвета удалось сильно сократить кол-во необходимых ног
может и тут такое подойдёт ?
(по схеме не понял)
у корвета из коробки РОМ подключёт как
PPA - Data
PPB-PPC - A0-A15
и чётко известно в каком порядке биос читает данные
загрузку разбили на 2 этапа
Stage 1 - размером 256 байт (минимальный размер который может прочитать БИОС)
он отдаётся после рестарта
на этом этапе МК отслеживает ТОЛЬКО изменение A0 (т.е. нет необходимости читать 16 бит из порта и читаь по соответсвующий им байт)
что ГОРАЗДО быстрее и нет вопроса с синхронизацией.
дальше как прочитали 256 байт, уже наш код в Stage 1 переключает ВВ55 в Mode 2
а там уже красота.
для аппаратного квитирования используются PC4-PC7
МК переходит в режим комманд и грузим всё что надо уже под нашим управленим
да и код простейший.
итого хватает 8(DATA) + 1 (PPB - A0, временно для Stage1) + 4 (PPC Mode 2 support)
ну плюс служебное.
итого хватает 8(DATA) + 1 (PPB - A0, временно для Stage1) + 4 (PPC Mode 2 support)
для чтения 512 байт никак не хватит одной адресной линии.
Так как в Векторе в ПЗУ которая стоит на борту есть только загрузчик и при старте программы он отключается, то программа которую загрузили с внешнего ПЗУ должна иметь и фонты и обработчик клавиатуры ну и саму программу общения. В картридже (http://asdasd.rpg.fi/~svo/scalar/ware/675/) который в картотеке это все помещается в два килобайта. В своей схеме я завел все порты ВВ55 в процессор, для начала буду пробовать использовать программу без изменений которая идет с картриджем (http://asdasd.rpg.fi/~svo/scalar/ware/675/) а процессором эмулировать ПЗУ для которого содержимое брать с SD карточки.
для чтения 512 байт никак не хватит одной адресной линии.
1й линии хватит для последовательного чтения любого числа байт :-)
Это уже работает в железе
---------- Post added at 01:15 ---------- Previous post was at 01:13 ----------
Я писал в общем не про эмулятор пзу
А куда это можно развить
Хватило-бы только АтМеге скорости, чтобы не сбиваться с "ритма" загрузки данных.
Хотя это критично только для заливки "Загрузчика", в нем свой алгоритм будет, там и "картридж" сможет синхронизировать загрузку...
В алгоритме чтения картриджа вроде нет ни какой синхронизации, со стороны Вектора просто перебираются адреса и читаются данные, это ведь "картриджу" сложно контролировать.
Проще для такой "читалки" использовать режим загрузки из "ЛВС".
Алгоритм сложнее, но есть синхронизация чтения. Это моё субъективное мнение...
именно про эти два пункта речь и идёт ;)
A0 - сильно помогает в 1м
а Mode2 во втором
вот про скорость и вопрос то
там не очень понятно когда байт читать
т.е. цикл вида
читаем A0-A7,
читаем A8-A15
читаем байт ROM[A0..A15]
выставляем D=ROM
и это кушает кучу времени в реальности
надо считать в тактах сколько и как идёт процесс чтения
(брать код загрузчика - смотреть и считать)
и хватит ли быстродействия.
вариант же с A0 сильно упрощает цикл
while len>0
while (A0&1 == prevA0)
prevA0=A0&1
D=ROM[ADDR]
ADDR+=1
len-=1
end
esl, я примерно догадываюсь, о предлагаемом способе загрузки данных.
Но artyr_n уже писал, что в загрузчике Вектора нет такого алгоритма, а весь фокус - сделать картридж работающий на "стандартном" загрузчике.
---------- Post added at 23:36 ---------- Previous post was at 23:22 ----------
В расширенном загрузчике есть возможность грузить программу с ROM через порт ПУ, в картотеке есть ...
Пока есть схема и разведенная платка.
Чет я сообразить не могу, что за двухрядный 30-ти контактный разъём J1 ?
И что у него за порядок бит данных/адреса ?...
Чет я сообразить не могу, что за двухрядный 30-ти контактный разъём J1 ?
BHR30-G
http://zx-pk.ru/attachment.php?attachmentid=50372&stc=1&d=1419271935
родные разъёмы не достать поэтому я развел переходник
http://zx-pk.ru/attachment.php?attachmentid=50373&stc=1&d=1419272154
который впаивается вместо родных разъёмов
И что у него за порядок бит данных/адреса ?...
Порядок определила разводка переходника.
esl, я примерно догадываюсь, о предлагаемом способе загрузки данных.
Но artyr_n уже писал, что в загрузчике Вектора нет такого алгоритма, а весь фокус - сделать картридж работающий на "стандартном" загрузчике.
я всё время и пишу про способ совместимый со стандартным ПЗУ
точнее так
он будет загружаться стандартным пзу
но дальше уже должно быть всё самописное.
даже полез исходники смотреть
для определённости
http://asdasd.rpg.fi/~svo/scalar/ware/888/
вот код загрузчика (цифра - такты)
lxi b,0
lxi h,0x8000
ROM_LOAD:
;младший адрес
mov a,l ;5
out 7 ;10 PA
;старший адрес
mov a,h ;5
out 5 ;10 PC
;чтение байта ROM
in 6 ;10 PB
stax b ;5
inx h ;5
inx b ;5
mov a,b ;5
cpi 80h
jnz ROM_LOAD
jmp start
я собственно про что всё время говорю
что т.к. в коде нет никакой синхронизации (т.к. там ПЗУ стоит)
смотрим код, между записью старшего байта паузы НЕТ ВООБЩЕ
смотрите в коде
OUT 5 ;записали старший байт
<<<<<<<<<<<<<<<<<<<вот тут вы должны успеть всё сделать обычным образом.
IN 6 ;прочитали байт данных
т.е. нет паузы вообще на тот код который я приводил как "стандартный"
(читать байтики из двух портов и вытаскивать байт из масива.)
также этот код не делает проверок вообще, и грузит насильно 32к
(может в более навороченных есть проверки но мне уж точно лень смотреть, хотя пищущему такое нужно точно знать)
мы точно знаем сколько он будет грузить.
мой способ с контролью изменения A0 точно будет работать ;)
объясню еще раз
младший байт тут меняется как 00,01,02,03,04,05,06
соответственно A0 -> 0,1,0,1,0,1,0,1
мало того очень удачно что младший байт задаётся первым
т.е. после его записи есть пауза 15 тактов
(или можно исхитрится что пауза будет весь хвост с inx,cpi,jmp)
времени у однокристалки должно хватитить на:
подождать изменения и записи байта данных
посде этого можно подготовить следующий т.к. есть чуть больше пауза.
p.s. или я не понимаю о чём мы говорим ;)
esl, я почитал Вашу разработку и документацию к ней. Читать только A0 это интересная идея, но просматривая листинг загрузчика я там увидел что проверка наличия ПЗУ в векторе это вычитывание с какогото адреса подряд 55 АА, так что в первый момент все равно нужно будет анализировать больше чем одну линию, еще и сброс системы туда не выведен и отдельного сигнала как в корвете нет (запрос наличия картриджа в разъеме), поэтому понять что в системе произошёл сброс и идет проверка наличия картриджа можно видимо анализируя еще и старший адрес. Соберу железо попробую разные варианты.
---------- Post added at 06:32 ---------- Previous post was at 05:43 ----------
Дизассемблированный код загрузчика (http://asdasd.rpg.fi/~svo/scalar/ware/545/)
; проверка наличия модуля ППЗУ
M0107H: MVI A,82H ; код управления порта
OUT 04 ; записать в РУС
MVI B,0FFH ;
M010DH: MOV A,B ;
OUT 05 ;
MVI A,0FEH ;
OUT 07 ;
IN 06 ;
CPI 55H ; проверка ключевого кода 55
JNZ M012EH ; код не совпал
MVI A,0FFH ;
OUT 07 ;
IN 06 ;
CPI 0AAH ; проверка ключевого кода AA
JNZ M012EH ;
MOV A,B ;
ANI 7FH ;
INR A ;
MOV D,A ;
JMP M0136H ; МППЗУ подключен - на выход
M012EH: MOV A,B ;
SUI 20H ;
MOV B,A ;
JM M010DH ;
XRA A ; обнулить А - МППЗУ не подключен
M0136H: ORA A ;
RET
из него видно что по адресу 0xFFFE в ПЗУ должно быть 55, а по 0xFFFF должно быть AA. А если по адресу 0xFFFE нет 55 то начинает вычитать 0x20 и опять проверять, это видимо на случай если ПЗУ меньшего объема.
esl, приношу свои извинения, глючу... :(
По не понятной причине, не воспринял используемую в Ваших текстах "А0" - как младший бит шины адреса. Поэтому ошибочно предположил о необходимости дополнительного тактового выхода.
...
Дизассемблированный код загрузчика (http://asdasd.rpg.fi/~svo/scalar/ware/545/)
; проверка наличия модуля ППЗУ
...
из него видно что по адресу 0xFFFE в ПЗУ должно быть 55, а по 0xFFFF должно быть AA. А если по адресу 0xFFFE нет 55 то начинает вычитать 0x20 и опять проверять, это видимо на случай если ПЗУ меньшего объема.
Вот и получается, что если загружать как ПЗУ, то минимальный размер 8Кб, можно конечно отдать только 2Кб, потом выставить на шине 00 и ждать когда Вектор считает остальные "пустые" данные.
Кстати, признаком начала чтения модуля "ПЗУ" со стороны Вектора соответственно является перебор адресов, соответственно на выходе "ПУ" будут перебираться старшие байты адреса:
FF DF BF 9F 7F 5F 3F, ну а при появлении там 1F уже нужно "идентификатор ПЗУ" подсовывать :) (Если я правильно понял и опять не глючу)...
Читать только A0 это интересная идея, но просматривая листинг загрузчика я там увидел что проверка наличия ПЗУ в векторе это вычитывание с какогото адреса подряд 55 АА, так что в первый момент все равно нужно будет анализировать больше чем одну линию
тут похоже более глубокая проблемма
и надо дизассемблировать ВСЕ вырианты ПЗУ
т.к. тот код что я приводил выше из одного из них, и в нём нет такой проверки!
и похоже есть несколько вариантов !!
Однакое если считать что у вас всегда стоит тот код что проверяет 0x55aa
то просто сделать чтобы первые два байта что выдаёт эмулятор были именно 0x55 0xAA ;)
Т.о. вообще игнорируем шину адреса (кроме A0)
и выдаём именно те байты которые ожидает загрузчик.
Если вариантов всегда 2 то можно просто добавить кнопку "выбора типа ПЗУ".
Врядли у реального пользователя больше 1го пзу на реальной машине и просто можно выбрать нужный.
По поводу детекта ресета - это возможно проблемма
как вариант забить на это дело (ввести кнопку ресета эмулятора)
или посмотреть нет ли там на разъеме чего-то что таки зависит от ресета.
По поводу главного заргузчика:
как вариант написать более сложный код загрузчика
который детектирует загрузились ли два "лишних байта" и обрабатывает это.
речь вот о чём,
если загрузчик проверяет наличие 0x55aa то загрзится код без этих байт
если же загрузчик не проверяет то получим в памяти да лишних байта
(и код как бы сдвинут на два байта)
55AA ->
mov d,l
xra d
т.е. ничего опасного если на них попадёт управление.
а дальше определить есть ли эти байты и выполнить две ветки начального загрузчика.
каждая для своего типа.
немного усложняем код, зато меньше завивимости.
даже набрасал что то (правда в мнемоники z80)
он пересылает "основной загрузчик" на постоянное место
хотя как вижу можно и в 0й адресс его грузить.
nop
nop
nop
nop
nop
nop
nop
ld de,0
ld hl,0
ld a,(hl)
cp 0x55
jp nz,no55AA
inc hl
ld a,(hl)
cp 0x55
jp nz,no55AA
nop ;если код сдвинут попадем сюда
nop
code55AA:
ld de,2
nop ;если код сдвинут попадем сюда
nop
no55AA:
ld hl,code
add hl,de ;сдвинуть на 2 байта
ld de,newCODE
ld bc,LEN
nop ;если код сдвинут попадем сюда
nop
.a1:
ld a,(hl)
ld (de),a
inc hl
inc de
dec bc
ld a,c
or b
jp nz,.a1
jp newCODE
т.к. тот код что я приводил выше из одного из них, и в нём нет такой проверки!
Это похоже код который рассчитывался загружаться с магнитной ленты и грузить программу из ПЗУ модуля, поэтому в нем нет никаких проверок. В загрузчиках которые стоят на плате проверки должны быть так как в основном они мультизагрузочные КВАЗИДИСК, ДИСКОВОД, МППЗУ, МАГНИТОФОН, СЕТЬ, с пумощью F1 F2 F3 и их комбинаций можно принудительно заставить грузится с определенного устройства, но если устройство не обнаружено то загрузчик автоматически переходит на загрузку со следующего найденного устройства.
Это видно если посмотреть весь код загрузчика который я привел выше.
Тем проще : )
Тогда перед кодом пзу всегда выдаем два байта
И все работает
---------- Post added at 13:35 ---------- Previous post was at 13:33 ----------
Но проверить все загрузчики для надёжности надо бы
Проблема отсутствия ресета и необходимости синхронизировать передачу данных снимается если применить протокол "ЛВС" :)
"Контроллер ЛВС" постоянно ждет от Вектора определенных "манипуляций" на шине.
После чего они договариваются и переливают данные.
Для АтМеги8 я исходник "контроллера ЛВС" вроде выкладывал...
В них изменений-то совсем ничего, кидать в буфер данные не принятые из СОМ-порта, а из массива прошивки (или где код загрузчика будет храниться).
главное вгрузить загрузчик любым стандартным способом!
а это ЛВС есть во всех загрузчиках ?
Для АтМеги8 я исходник "контроллера ЛВС" вроде выкладывал...
Помню что читал про такую разработку, но найти не смог. Можете пальцем ткнуть куда она спряталась?
Помню что читал про такую разработку, но найти не смог. Можете пальцем ткнуть куда она спряталась?
Вот, среди "Железа"
http://zx-pk.ru/showthread.php?t=8669&page=15
Сначала выкладывал только готовый проект, потом прошивку вместе с вариантом для 51-го проца.
А на счет того, во всех ли загрузчиках есть ЛВС, это конечно вопрос, не могу утверждать, в "заводском" на сколько могу судить - есть...
и винкса был вариант (кажется для специалиста)
где начальный загрузчик через магнитовон грузится
делать как раз очень просто ;)
Помню что читал про такую разработку, но найти не смог. Можете пальцем ткнуть куда она спряталась?
Сидел я, чесал репу, вспоминал тот проект...
Для передачи инфы Вектору по ЛВС, она (эта инфа) должна быть "завернута" в конверт из служебных байт. Но в прошивке АтМеги этот конверт не готовится, он уже готовый принимается по СОМ-у и передается без изменений. Поэтому мой исходник придется допиливать.
Значения/назначение этих служебных байт я описывал, но думаю там всё равно "без полтарашки не разобраться"... :(
То, что я тут написал, оно верно. Но я нашел у себя первый вариант тестилки протокола ЛВС. Там автономный вариант, который загружал в Вектор программки "Тест ОЗУ", код которых был массивом внесен в сам "контроллер". Это ведь то-что нужно.
Загрузка вынесена в отдельную процедуру, код на Си. Даже краткие пояснения есть (что на меня не похоже)...
artyr_n, может в личку кинуть, для посмотреть?
Загрузка вынесена в отдельную процедуру, код на Си. Даже краткие пояснения есть (что на меня не похоже)...
artyr_n, может в личку кинуть, для посмотреть?
Да киньте если не сложно.
Сегодня собрал макет и собрал переходник на вектор. Вечером хотел попрограмить но usbbasp после обновления системы и видимо averdude на отрез отказались прошивать, точнее прошивка не проходит проверку
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0100
0xff != 0x72
avrdude: verification error; content mismatch
Завтра соберу программатор на FT232RL.
Немножко фоток.
То ли я что то не правильно делаю, то ли вектор сильно быстро хочет получить данные.
По анализатору получается что после выставления адреса порт читается через 3 микросекунды, а реакция атмеги наступает через 0.8 миллисекунды.
Выкинул из заготовки программы всё лишнее и мега стала реагировать за 1 микросекунду. На экране увидел значок ПЗУ и пошло чтение ПЗУ, между выставленным адресом и чтением из ВВ55 9.8 микросекунды.
Выкинул из заготовки программы всё лишнее и мега стала реагировать за 1 микросекунду. На экране увидел значок ПЗУ и пошло чтение ПЗУ, между выставленным адресом и чтением из ВВ55 9.8 микросекунды.
А RD и WR на графике анализатора, это именно на ногах ВВ55?
На одном графике WR одиночные а на другом "двойные".
Я так понимаю, одиночные - это поиск ПЗУ, двойные - это уже чтение ПЗУ?
RD и WR это на ногах ВВ55. Одиночный WR во время поиска ПЗУ, сначала записывается 0xFE и считанное сравнивается с 0x55, потом записывается 0xFF и считанное сравнивается с 0xAA. Потом на экране появляется значок ПЗУ и пауза в секунду и потом начинается чтение ПЗУ.
RD и WR это на ногах ВВ55. Одиночный WR во время поиска ПЗУ, сначала записывается 0xFE и считанное сравнивается с 0x55, потом записывается 0xFF и считанное сравнивается с 0xAA. Потом на экране появляется значок ПЗУ и пауза в секунду и потом начинается чтение ПЗУ.
Значит нет особых проблем с реализацией протокола ПЗУ?
А перезапуск Вектора удается контролировать?
Значит нет особых проблем с реализацией протокола ПЗУ?
Как и советовал esl буду использовать A0 как тактовый смены адреса, ну и загрузим загрузчик который начнет общаться с атмегой по нормальному протоколу.
А перезапуск Вектора удается контролировать?
Пока видится отслеживание A15 (PC7 ВВ55) по включению и после загрузки он 0 перед поиском ПЗУ он становится 1 и все время поиска и загрузки он в 1.
Пока видится отслеживание A15 (PC7 ВВ55) по включению и после загрузки он 0 перед поиском ПЗУ он становится 1 и все время поиска и загрузки он в 1.
Я прикидывал, скорее всего, на РС7 не "0", а он настроен на "ВХОД".
Нужно посмотреть другую Векторовскую периферию, возможно Р4-Р7 "стандартно" настроены на ВХОД, и только после обнаружения устройства, которому порт "С" нужен как ВЫХОД, перенастраивают его.
Я это к чему, возможно есть смысл, "подтянуть" РС7 к "GND" через 100К.
Ну так сказать для исключения "шума"...
Ну если верить этому (http://asdasd.rpg.fi/~svo/scalar/ware/675/) и этому (http://asdasd.rpg.fi/~svo/scalar/ware/783/) то РС7 и отвечает за разрешение ПЗУ выставить данные
---------- Post added at 16:17 ---------- Previous post was at 14:41 ----------
Тест ОЗУ в вектор загрузил, не работает. Посмотрел анализатором что грузится, похоже на правду, видимо в векторе проблема с нулевой страницей ОЗУ.
Ну если верить этому (http://asdasd.rpg.fi/~svo/scalar/ware/675/) и этому (http://asdasd.rpg.fi/~svo/scalar/ware/783/) то РС7 и отвечает за разрешение ПЗУ выставить данные
Честно говоря, я не совсем в этом уверен, что "РС7 отвечает за разрешение ПЗУ выставить данные".
Поскольку РС7, это именно А15 - старший бит шины адреса.
А следовательно, если загружать из ПЗУ до 32КБ там должен быть "0", если загружать больше 32КБ - в определенный момент появится "1"...
Я так думаю...
В векторе 64 КБ ОЗУ, из них 32 для программы и 32 видео, так что грузить программу более 32 КБ вроде как не нужно.
с детектом ресета - всё грустно
основная причина - что софт как хочет так и пишет в порты
эт я по мотивам Корветовской ExtRom пишу, и док не читали
или забивали, ибо в те веремна о совместимости не думали ...
в вашем случае выглядит заманчиво детект записи 0xfffe 0xffff в порты, но как это реализовать не очень понятно ....
В векторе 64 КБ ОЗУ, из них 32 для программы и 32 видео, так что грузить программу более 32 КБ вроде как не нужно.
Для заливки Загрузчика действительно не нужно, но алгоритм поиска ПЗУ предусматривает поиск начиная с какого адреса?
То esl, про алгоритм обнаружения ресета Вектора я уже намекал ранее...
Думаю можно попробовать отслеживать значение старшего байта адреса.
Зная интервалы времени через которые Вектор выставляет адреса при поиске ПЗУ, можно именно эту последовательность и отлавливать...
Ну типа
StartPZU_FF:
if(Px != 0xFF) StartPZU_FF
if(Px != 0xDF) StartPZU_FF
if(Px != 0xBF) StartPZU_FF
if(Px != 0x9F) StartPZU_FF
if(Px != 0x7F) StartPZU_FF
...
и т.д. расставив между ними "нужные" задержки...
И пусть какой-нибудь пользовательский софт попробует это повторить :)
но алгоритм поиска ПЗУ предусматривает поиск начиная с какого адреса?
0xFFFE 0b1111 1111 1111 1110
если прочли не 55 из старшей половины вычитается 0x20
0xFF - 0x20 = 0xDF весь адрес выглядит 0xDFFE 0b1101 1111 1111 1110
потом вычитается еще 0x20 0xDF - 0x20 = 0xBF 0xBFFE 0b1011 1111 1111 1110
0xFFFE 0b1111 1111 1111 1110
если прочли не 55 из старшей половины вычитается 0x20
0xFF - 0x20 = 0xDF ... 0xDF - 0x20 = 0xBF ...
Вот, и я о том-же с 0xFFFE - фактически загрузчик Вектора позволяет загрузить из ПЗУ 64КБ программного кода (минус 2 Байта 55 АА)... :)
Конечно при загрузке экранной области и области стека будет сбой, но ведь теоретически возможно...
Кстати Шахматы вроде были более 32Кб, и ещё чей-то было...
А во время работы загрузчика экранная область ограничена 16КБ от 0xA000 до 0xDFFF - вроде-бы... если склероз не изменяет...
Значит "Загрузчик" (абстрактный) может без повреждения кода загрузить программу размером 48КБ, если начнет загружать с адреса 0xE000.
Так ведут себя ВСЕ загрузчики? :-)
Так ведут себя ВСЕ загрузчики? :-)
Которые читают ПЗУ, уверен на 99.99% поскольку основаны они на "заводских" а тут смысла чего-то менять совсем нету...
Если у кого есть все загрузчики, можно дать "поиск по содержимому файла" какой-нибудь последовательности байт характерной для загрузчика из ПЗУ. Думаю она будет найдена во всех вариантах.
Подозреваю, что начало во всех одинаковое:
MVI A,82H
OUT 04
MVI B,0FFH
MOV A,B
OUT 05
MVI A,0FEH
OUT 07
IN 06
...
Нашел у себя 4 загрузчика. В 3-ех код аналогичен, только в загрузчике "hdd_boot.bin" начало поиска с 0x1F.
Посмотрел внимательно на код определения наличия ПЗУ в "заводском" загрузчике:
; проверка наличия модуля ППЗУ
M0107H: MVI A,82H
OUT 04
MVI B,0FFH
M010DH: MOV A,B
OUT 05
...
M012EH: MOV A,B
SUI 20H
MOV B,A
JM M010DH ; продолжить поиск если старший бит "1"
XRA A
M0136H: ORA A
RET
Соответственно, поиск ПЗУ вообще прекращается после 9F-20=7F...
Похоже А15 действительно не участвует в формировании адреса для ПЗУ, иначе проверка была-бы только с адреса FF до 9F.
Мир рушится, Шахматы (и чего-то там ещё) нельзя загрузить из ПЗУ, поскольку из ПЗУ можно загрузить только до 32КБ... :(
Посыпаю голову пеплом, признаю, заблуждался, я был о "загрузчике" лучшего мнения...
На фоне всего этого, стало понятно, что и в загрузчике "hdd_boot.bin" тоже проверка идёт с FF до 9F (с адреса 7F по 1F), просто код изменен:
; проверка наличия МППЗУ
L0530: mvi a,$82
out $04
mvi h,$1F
L0536: mov a,h
sui $20
rp ; выход если старший бит "0"
mov h,a
out $05
...
Всё, пошел "бухать с горя", напьюсь минералки, и буду валяться под столом в забытии...
Которые читают ПЗУ, уверен на 99.99%
Нашел у себя 4 загрузчика. В 3-ех код аналогичен, только в загрузчике "hdd_boot.bin" начало поиска с 0x1F.
если меня не подводит мой скалероз, то минимальный объем микросхемы пзу на ром-модуле был 8к в канонических версиях загрузчиков. 1F - это уже доработка, для того чтоб загрузить биос котролера диска, а он был по моему в 2к.
P.S. Могу ошибаться, давно было
если меня не подводит мой скалероз, то минимальный объем микросхемы пзу на ром-модуле был 8к в канонических версиях загрузчиков. 1F - это уже доработка, для того чтоб загрузить биос котролера диска, а он был по моему в 2к.
P.S. Могу ошибаться, давно было
Не, это просто измененный алгоритм, работающий аналогично "стандартному" загрузчику ПЗУ.
Я выше привёл кусок начала алгоритма, там видно, что первичное значение берётся "1F" и сразу от него отнимается "20", и далее используется уже результат вычитания, т.е. фактически начинается с того-же "FF".
Причём как я уже тоже писал, выяснилось, что старший бит адреса не участвует в формировании адреса ПЗУ, это бит "активации" ПЗУ как писал artur_n.
Так-что загрузчик "hdd_boot.bin" проверяет ПЗУ так-же как "стандартный", с шагом 8КБ.
и грузить прямо с картотеки
Разумеется, в этом весь зловещий план.
Проверил, все хорошо, не лежит. Может быт какой-то перебой.
Чет форум перекинул тему обратно в 15-й год.
Тестирую 1.. 2.. 3... в прошлый раз отвечал, весь форум навернулся. Позоже уже не исправится.
Загрузка прямо из картотеки это само собой :)
- - - Добавлено - - -
Тестирую 1.. 2.. 3... в прошлый раз отвечал, весь форум навернулся. Позоже уже не исправится.
Загрузка прямо из картотеки это само собой :)
- - - Добавлено - - -
KTSerg, ты посмотри на дату своего сообщения ;)
Пока борюсь с SD картой написал заготовку для запуска программ с SD карточки для вектора.
В прикрепленном файле описание того что задумывалось и исходники которые реализуют чтение с SD карты загрузчика и передачи его в вектором по протоколу эмуляции ПЗУ, также схема и платка. Если есть желающие помочь доделать проэкт до рабочего состояния буду очень рад.
Упомяну еще один возможный вариант.
1. Есть программная часть - xsd b2mа (читалка SD карт с FAT16 на асме 8080)
2. Есть аппаратная часть - очень простой контроллер. Он не под вектор, но адаптировать к вектору вряд ли сложно. Ссылку, сейчас, к сожалению не дам, но думаю b2m подскажет.
С использованием пп.1 и 2 и v06cc svofski я делал прикидочный вариант читалки/запускалки rom для вектора и выкладывал его в соответствующей ветке.
Недостатки прикидочной реализации:
1. В качестве bios использовал монитор-отладчик, что очень избыточно. Если собраться, то можно написать компактный bios.
2. Запускались только rom ограниченного размера. Несложно доделать, было бы место, куда грузить.
3. Можно сделать загрузку образов edd. Тогда можно будет запускать и .com и .bas c квазидиска.
Дополнительное достоинство - эта штука эмулируется в emu, можно отлаживать софт.
Недостаток того контроллера - он довольно медленный (зато очень простой, никаких микроконтроллеров)
ivagor, а что насчет адаптировать микродос для SD карты? Выкинуть все про дисковод и вместо этого написать драйвер, который битбенгом через ПУ будет работать с SD картой, свисающей на проволоках.
- - - Добавлено - - -
Все, что можно загрузить модным загрузчиком .rom-файлов, можно загрузить и с магнитофонного входа. А Микродос, работающий напрямую с картой, позволит работать практически без дополнительного железа запускать дисковые программы, которым нужна работа с диском. Для подгрузки оверлеев, например. Кстати, вместо SD-карты я бы уже думал сразу о esp8266 (esp12f), к которой в свою очередь уже можно привесить SD-карту.
Я хоть и делаю девайс с квазом и эмулятором флопа, но я его буду делать медленно и неопределенно долго. А для привешивания SD-карты на ПУ нужно только софт заточить.
ivagor, а что насчет адаптировать микродос для SD карты? Выкинуть все про дисковод и вместо этого написать драйвер, который битбенгом через ПУ будет работать с SD картой, свисающей на проволоках.
Да я только за, я тогда сразу про это написал. Но для меня это сложновато. Надо дизассемблировать дос.
Все, что можно загрузить модным загрузчиком .rom-файлов, можно загрузить и с магнитофонного входа.
Тоже соглашусь, но в формате ром грузить большие файлы долго. Тогда (в 2014) турбо-загрузчика не было, а сейчас более-менее есть.
Совсем оффтоп - меня тогда с супер-турбой (в районе 48 МГц, если не путаю) v06cc загрузчик с sd спас. С магнитофона в супер-турбе, понятно, не грузит и твой эмулятор fdd на таких частотах тоже не работает.
А Микродос, работающий напрямую с картой, позволит работать практически без дополнительного железа запускать дисковые программы, которым нужна работа с диском.
CP/Mовские - да, а вот векторовские дисковые игры и тем более демы - не все. Но, с другой стороны, их не так уж и много.
CP/Mовские - да, а вот векторовские дисковые игры и тем более демы - не все. Но, с другой стороны, их не так уж и много.
Да, подумал, что наверное все особенно зловредные демки лезут прямо в порты, а как же иначе...
Кстати, вместо SD-карты я бы уже думал сразу о esp8266 (esp12f)
и грузить прямо с картотеки
кстати что то она лежит
да что то форум глюканул
Ага, вчера эту тему еле нашел в 15ом году, не смотря на наличие новых сообщений, написал об этом, а сообщение 15ым годом стало датироваться.
В исходниках sd-rom картриджа, что за упоминания о загрузчике? Это остатки от "рыбы"?
Improver
06.02.2018, 14:04
Здравствуйте, все.
Некоторое время назад у меня, независимо от этого форума, тоже появилась идея сделать картридж для моего "вектора" на современной электронной базе, вот, хочу поделиться своими идеями...
В качестве основы решил взять ардуино + SD-карту. И первая проблемка, которая у меня возникла -- нехватка портов на ардуине для подключения к порту ПУ. Собственно, решать я её попробовал двумя способами:
1. При помощи расширителей портов, типа PCF8574 или MCP23017.
2. Переписать загрузчик так, чтобы он использовал меньше выводов разъёма ПУ.
По второму варианту написал на ассемблере соответствующий вариант загрузчика для "вектора", но даже не протестил его, как появилась другая идея -- передавать данные последовательно, на магнитофонный вход, или даже минуя компаратор D82 (по схеме Вектор-06ц) непосредственно на вывод 13 микросхемы D30. Выходы на ардуине имеют TTL-уровни, передача "в цифре", так что можно повысить скорость до максимальной и не делать дублирование блоков. Плюс ко всему этот вариант будет наиболее универсален -- можно будет грузить программы на любом векторе, с любой прошивкой.
В общем, на текущий момент у меня ардуинка умеет передавать данные в формате ROM, при подаче сигнала на вход звуковой карты ПК они нормально распознаются утилитой WAV2ROM, но вот только протестировать на "живом" векторе пока ещё успел. Если идея Вас заинтересовала, то могу поделиться скетчем на ардуино, но для этого, наверно, надо создать новую тему, чтобы не путать с картриджем для порта ПУ.
Improver, у меня есть ардуина-нана, на досуге как-нибудь я мог бы подвесить ее на проводках к магнитофонному разъему для тестирования. На практике для себя я не вижу большого преимущества по сравнению с загрузкой с выхода на наушники компьютера, но разные бывают ситуации.
Хорошо бы интегрировать в этот проект турбо-загрузчик ivagor-a. Разница в скорости просто брутальна.
Скеч для ардуины переносим и его можно будет засунуть в Ардуину на ESP8266 (ESP12F), и вот в этом я уже вижу объективный кайф. Правда ей придется 3.3В регулятор приделывать, но это делов-то.
Спасибо за упоминание MCP23S17, я как раз его искал для себя и забыл, как называется ;)
Искал инфу по ESP8266. Создалось впечатление, что со стандартной прошивкой с АТ командами, особенно не разгуляешься. Практически все решения с заменой ПО в ESP. Даже простой WiFi-удилнитель СОМ-СОМ, на АТ-командах проблемотичен (судя по форумам). Хотя для ESP наверное лучше смотреть не как на удлинитель СОМ, а сразу переходить на UDP-пакеты.
Но если заработает, скрестить ESP12 с SD-ROM картриджем, думаю труда не составит.
Ну и как бонус "для гурманов" выход с картриджа на магнитофонный вход, для медитации на квадратиках... :)
Improver
06.02.2018, 18:02
Improver, у меня есть ардуина-нана, на досуге как-нибудь я мог бы подвесить ее на проводках к магнитофонному разъему для тестирования.Ок, я как раз эксперименты проводил на ардуине нано (китайский вариант v3, на ATMega328). Завтра выложу скетч для теста.
На практике для себя я не вижу большого преимущества по сравнению с загрузкой с выхода на наушники компьютера, но разные бывают ситуации.В принципе да, преимущества перед, например, обычным mp3-плеером минимальны... Я пока только начал что-то делать в этом направлении, но если ещё дополнить возможностью записи, как тут: Магнитофон для Спектрума на ATMega128 (http://zx-pk.ru/threads/25622-magnitofon-dlya-spektruma-na-atmega128.html), то может получиться очень полезное устройство, тогда можно будет писать и читать данные в любом формате, не только ROM.
Потом ещё можно так скомбинировать: через магнитофонный вход заливается маленький загрузчик, который следом с той же ардуины грузит основную программу через ПУ. И этот загрузчик может, например, работать по такому принципу: передаётся начальный адрес (два байта), длина (два байта), а потом идут потоком данные, по одному байту на каждый синхроимпульс с Вектора (типа сигнал "данные получены"). И тогда достаточно будет всего девяти линий, т.е. использовать, допустим, порт PA и одну линию порта PC для синхронизации.
Хорошо бы интегрировать в этот проект турбо-загрузчик ivagor-a. Разница в скорости просто брутальна.Извиняюсь, а что это за загрузчик?
Скеч для ардуины переносим и его можно будет засунуть в Ардуину на ESP8266 (ESP12F), и вот в этом я уже вижу объективный кайф. Правда ей придется 3.3В регулятор приделывать, но это делов-то.В принципе да, это тоже плюс...
Извиняюсь, а что это за загрузчик?
Вот этот (http://zx-pk.ru/threads/10002-rom-format-avtozapusk-zashchita-sekrety.html?p=863641&viewfull=1#post863641)
На тему ускоренной заливки программ в вектор с поддержкой в загрузчиках еще вспоминаются
1. "Сеть" с современной реализацией KTSergа
2. Загрузка через ПУ Tim0xи. У меня этот вариант даже работал, но очень давно. Тогда у меня был pentium 133. Для современных компов надо переделывать.
Я когда-то перегонял проги с дискет Вектора на РС, для этого соединял ПУ с LPT, писал проги с протоколом на подобии Нортон-овского (полубайтного), правда цель была сделать только в одну сторону, с Вектора на РС...
В исходниках sd-rom картриджа, что за упоминания о загрузчике
работа sd-roma планируется в два этапа.
этап первый, после сброса вектора он щупает порт ПУ на предмет наличия ПЗУ, атмега по состоянию ПУ понимает что вектор перегрузили, считывает с sd-карты загрузчик в память и ждет пока вектор начнет перебирать адреса считывая ПЗУ.
На этом этапе не удается подчитывать файл с карточки так как вечтор считает что это ПЗУ и довольно шустро перебирает адреса, сказать вектору подожди возможности нет.
второй этап
После передачи загрузчика и запуска его пользователем загрузчик начинает общаться с атмегой через порт ПУ по протоколу запрос ответ и тогда уже можно читать с карточки и передавать в вектор. Скорее всего на этом этапе имеет смысл в автомате загрузить и запустить нортон подобную оболочку с содержимым карточки.
Ага, ясно, это не реализованная функция.
Просто связанные кнопка, LED, bootloader - такие термины, как будто это перевод самой Меги в режим программирования.
Improver
07.02.2018, 12:47
Improver, у меня есть ардуина-нана, на досуге как-нибудь я мог бы подвесить ее на проводках к магнитофонному разъему для тестирования.Вот, выложил всё тут: http://zx-pk.ru/threads/28819-rom-pleer-na-arduino.html
работа sd-roma планируется в два этапа.
этап первый, ... считывает с sd-карты загрузчик в память и ждет пока вектор начнет перебирать адреса считывая ПЗУ.
...
Чет мне не удаётся открыть файл, расположенный в папке. Из корневого файл открывает, в папке не находит...
Правда я исходники не на Меге проверял, а на LPC. Может перегнал криво...
Чет мне не удаётся открыть файл, расположенный в папке.
До чтения с папок я не добрался и не проверял.
Ясно, ещё раз спасибо за исходник, он не большой, с урезанным функционалом, но позволил довольно быстро "войти в тему".
Нашел интересные примеры работы с СД-картой под LPC, библиотеки с подходящим функционалом, даже вроде немного разобрался, осталось "обработать напильником"...
В виду наличия на моей макетке только одного порта 8Бит и нескольких пинов, у меня не получится контролировать "шину адреса ПЗУ", что-бы понять когда начинать передавать данные :(
Но для протокола ЛВС одного порта вполне достаточно.
И бонус использования протокола ЛВС в том, что не нужно сначала передавать короткий биос/загрузчик, можно сразу грузить нужный файл (проводник) прямо с SD-карты.
На данный момент отладил загрузку с SD-карты в Вектор файлов, на выбор, по протоколу ЛВС или через магнитофонный вход. Файл 23КБ грузится с SD-карты по ЛВС 3.8сек., через магнитофонный вход 100сек.
Пока ещё в отладочном режиме, управление загрузкой с РС по СОМ порту.
KTSerg, а какие загрузчики поддерживают этот протокол?
В виду наличия на моей макетке только одного порта 8Бит
на сколько я помню там и не проверяется адрес а только контролируется перепады первых адресов.
KTSerg, а какие загрузчики поддерживают этот протокол?
Да вроде практически все кроме простых магнитофонных. Протоколы у них одинаковые что магнитофонный, что ЛВС, структура данных и служебной инфы одинаковая.
На том загрузчике, что я знаю, ЛВС вызывается F1+F3, при перезапуске. Появляется обозначение компа (ЛВС).
artyr_n, при передаче, так и есть. Но сначала нужно понять, что Вектор ищет ПЗУ, и опрашивает последовательность адресов 7FFE, 5FFE, 3FFE, 1FFE, 1FFF.
Можно конечно следить только за старшими битами порта С (старшими битами адреса), и одним младшим битом адреса...
Попробую ещё пины найти, попробовать...
на сколько я помню там и не проверяется адрес а только контролируется перепады первых адресов.
Нашел "свободных" пинов, перепаяю шлейфы, переопределю порты/пины в софте, буду пробовать...
- - - Добавлено - - -
KTSerg, а какие загрузчики поддерживают этот протокол?
Блин, видимо в разных загрузчиках ЛВС разными комбинациями вызывается. На том, что у меня сейчас установлен в простой Вектор 06Ц, значёк ЛВС (без подключения самого контроллера) появляется при перезагрузке с нажатой "АР2".
У меня лежит свеженькая 573РФ2. Я как-то интуитивно тянусь к http://sensi.org/scalar/ware/540/
Его описание: https://github.com/svofski/vector06sdl/blob/master/boot/boots.txt
Вот тут написано, что АР2 — это через LPT, а сетевой — это F1+F3. Хм?
Вот в этом boots и смотрел, что ЛВС это F1+F3, а проверил на простом векторе, на нём АР2, причем без адаптера картинка появляется. Проверил на 02ом, там стоит заводская ПЗУ 556РТ7А, ни какие комбинации эффекта не дают, кроме F5 - грузит из внешнего ПЗУ (даже при его отсутствии). При нажатии всех других комбинаций, всё равно выходит на кассету. Видать контролирует наличие соответствующего оборудования.
Спасибо Tim0xe, есть дизассемблированый загрузчик от .02 (http://sensi.org/scalar/ware/545/)
https://pastebin.com/zrQN4PGu
Детектор адаптера ЛВС - M00D9H. Для меня это совершенно мистический аппарат. Кто-нибудь его когда-нибудь видел?
Спасибо Tim0xe, есть дизассемблированый загрузчик от .02 (http://sensi.org/scalar/ware/545/)
https://pastebin.com/zrQN4PGu
Детектор адаптера ЛВС - M00D9H. Для меня это совершенно мистический аппарат. Кто-нибудь его когда-нибудь видел?
Я слышал, что были целые учебные классы информатики в школах с Вектор-ами, возможно там была ЛВС, таких подробностей не помню, и лично в таком классе не бывал. Настоящего адаптера/контроллера ЛВС не видел.
Кстати, судя по дизассемблерному коду, в этом "штатном" загрузчике, на загрузку из ЛВС при наличии Квазидиска не выйти. Поскольку спец-кнопок для перехода на ЛВС нет, а в очереди он только после Квазидиска... :(
Фу, блин, написано, что Ф1+Ф2 переход на дисковод, а по адресу перехода проверка ЛВС...
Кстати, судя по дизассемблерному коду, в этом "штатном" загрузчике, на загрузку из ЛВС при наличии Квазидиска не выйти.
Если такие классы и были, вряд ученические машины были оснащены квазидисками, шибко жирно, так что можно было не заметить ошибку. Но интересно было бы поподробней про такие классы узнать, должно же было остаться какое-то свидетельство этого. Может быть это была экспериментальная разработка, которая в серию не пошла?
Ф1+Ф2 перескакивает проверку Квазидиска, и выходит именно на проверку наличия ЛВС, при её отсутствии проверка наличия контроллера дисковода.
Это я не внимательно код посмотрел, а описание переходов не совсем корректное.
И вроде по адресу "M0090H" всёравно косяк.
По этому адресу вызов подпрограммы проверки наличия ЛВС, а следующая строка, это проверка результата - при наличии ЛВС переход на загрузку с магнитофона...
Или просто я уже сплю...
Офф-топ...
Но интересно было бы поподробней про такие классы узнать, должно же было остаться какое-то свидетельство этого.
Я не силён в соц-сетях и не знаю как там сообщения распространяются.
Может есть возможность в соц-сети создать сообщение общее или как-то вне группы, с вопросом, у кого в школе, в кабинете информатики, в 90-ых, был Вектор06Ц.
Кто не помнит на каком компе учился, тот подробностей не вспомнит... а кто интересовался, может и вспомнит чего...
Просто мне когда-то знакомый рассказывал, что когда в его школе компы в кабинете информатики меняли, они со старых компов деребанили, всё что могли...
В дизассемблированном 2 Кб загрузчике Tim0xи (kish2, в исходнике - версия 2) при F1+F2 сначала проверяется ЛВС, если ее нет - дисковод.
Интереснее при F2 - сначала проверит наличие ЛВС, и если ЛВС есть, то будет грузить с магнитофона (?, так понимаю, что это ошибка). Потом проверит наличие внешнего ПЗУ. Если внешнее ПЗУ есть - грузим с него, если нет - с магнитофона.
При обнаруженном квазе по F1+F3 выведет "(с)ТЕМИРАЗОВ&СОКОЛОВ".
В 2 Кб загрузчике Tim0xи (boots3) после F1+F2 проверяется дисковод, если его нет - hdd, если и его нет - ЛВС, если и его нет - внешнее ПЗУ, если и его тоже нет - грузим с магнитофона.
При F1+F3 проверяется ЛВС, далее по списку (ПЗУ, магнитофон).
При АР2 проверяется изобретение Tim0xи 0-модем, как и ЛВС и ПЗУ подключаемое к ПУ. Пользовался этой штукой, когда у меня был pentium.
Можно и 32 Кб загрузчик посмотреть, но там скорее всего как в boots3 + встроенные программы.
Реклама КУВТ ВЕКТОР+ в вектор-user 7.
Реклама КУВТ PS-1000a в вектор-user 23.
В дизассемблированном 2 Кб загрузчике Tim0xи (kish2, в исходнике - версия 2)
Неправильно назвал. Это счетмашевский 2 Кб загрузчик, который устанавливался, как я понимаю, в .02 и который дизассемблировал Tim0xA.
И, кстати, волгоградский (системотехника) в отношении ЛВС ведет себя аналогично.
Ещё один интересный факт.
В заводском загрузчике Вектора (выпуска 92г.) есть поддержка ЛВС, но в Вектор-Юзер №22 (94г), в таблице "железа" для Вектора, нет упоминаний о контроллере ЛВС...
В вектор-user 7 явно специально разместили рядом рекламы 06Ц.02 и КУВТ ВЕКТОР+.
В рекламе .02 есть фраза: "Подключение и загрузка с внешних устройств: ..., адаптера локальной сети, ..."
В вектор-user 7 явно специально разместили рядом рекламы 06Ц.02 и КУВТ ВЕКТОР+.
В рекламе .02 есть фраза: "Подключение и загрузка с внешних устройств: ..., адаптера локальной сети, ..."
Возможность такая есть, а адаптера нет...
Ну вряд ли КУВТ ВЕКТОР+ был чисто бумажным прожектом, какое-то железо должны были сделать, хотя бы на этапе разработки. И программа для IBM должна быть.
В PS-1000a изменили концепцию - векторы и в качестве РМП и РМУ, т.е. должна быть еще и программа для РМП.
Только среди участников форума, похоже, очевидцев нет. Наверно Vector-user самый знающий по этой теме.
Загрузка файла BOOT\sdbios.r0m с SD-карты (как из ПЗУ) у меня заработала.
Сравнил логи шины у 06Ц и .02.
При поиске ПЗУ, оба Вектора читают порт осле установки адреса, через 9мкс при поиске 55h. И через 3мкс при поиске ААh. А вот при чтении из ПЗУ данных 06Ц читает порт через 9мкс, а .02-ой через 21мкс.
Повторюсь, что на .02-ом установлен заводской загрузчик. (похоже потом нужно будет заняться его считыванием).
Наткнулся ещё на один "косяк" в стандартном/заводском загрузчике Вектор06Ц.02.
Пока не понял из-за чего, буду смотреть код загрузчика.
Смысл глюка в том, что если при активации "SD-ROM картриджа" перегрузить Вектор без нажатия кнопок "F", то всё работает и файл загружается. Но если перегрузить с нажатой "F5" (вроде как срабатывает принудительная загрузка с внешнего ПЗУ), то появляется картинка микросхемы, заполняется загрузочная сетка, запускается загруженный мусор, т.к. при загрузке ничего из портов НЕ читается и адреса чтения на ПУ не выставляются...
Ну вряд ли КУВТ ВЕКТОР+ был чисто бумажным прожектом, какое-то железо должны были сделать, хотя бы на этапе разработки. И программа для IBM должна быть.
Только среди участников форума, похоже, очевидцев нет. Наверно Vector-user самый знающий по этой теме.
Адаптеры сети точно были, поскольку было классы в школах с вектором, НО все уперлось в желание разработчиков кушать и "родной" схемы лвс для вектора мне так увидеть не удалось. К сожалению позжее я отошел от векторства и тема для меня перестала быть актуальной. В настоящее время я думаю, что и найти уже ничего нельзя, все что было уже выкинули, а те кто что-то знали или забыли и забили.
P.S. По случаю купил вектор :)
Прошу прощения, небольшой оффтоп. Ищу схему, прошивки и информацию для создания собственных прошивок для картриджа от Vinxru (краткое описание здесь http://raregame.ru/text/vector.html, видео нашёл здесь: https://youtu.be/gGYUjJxeJAY) Если у кого есть - пришлите, пожалуйста.
Соответствующая тема (https://zx-pk.ru/threads/33511-rom-kartridzh.html)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot