ПК8000 - загрузка с внешних носителей

[DemonId7]

я про это уже писал. CS устанавливается при обращении по адресу 4000Н, дальше мега сама дешифрует младшие адреса.

Хорошо, есть дешифратор, выставляющий некий CS, по которому микроконтроллер выставляет на шину некие данные. А тогда в чем принципиальная разница, если то же самое будет делать ПЗУ? Зачем МК эмулировать работу ПЗУ? Чтобы покупать самую дорогую модель МК?

пустых образов море, а переносить в них файло мона из эмулятора уважаемого b2m.
для начинающего юзера нет риска затереть винт, например

Как средство отладки - эмуль хорош. Но пользоваться им для записи образов довольно неудобно.

---------- Post added at 04:18 ---------- Previous post was at 04:14 ----------

моя идея оптимизации:
мы ТОЧНО знаем порядок чтения байт из пзу

Не понял, порядок чтения чего? И откуда мы его точно можем знать?
БИОС ПК, после старта, мэппирует поочередно разъемы расширения на адрес 4000h, выискивая на них сигнатуру наличия ПЗУ. Если нашел, то читает оттуда же адрес, на который и передает управление.

и по этому с помощью детекта изменения A0 (чтение всегда увеличивает байт адреса на 1)
соответственно для детекта адреса нужно не 16 линия а достаточно 1й
+ нужен четкий детект начала последовательности чтения.

а дальше используя MODE2 ВВ55 уже идёт обмен в режиме API

итого мы обходимся всего 14 проводами (8дата, +1 A0, + 1 детект режима, +4 mode2 control)

У нас совсем по другому. Контроллер подключается непосредственно к шинам адреса и данных ПК. Поэтому и нужен нормальный дешифратор адреса. Это как шина ISA, только чуток попроще.

это похоже применимо частично в случае РК8000, хотя
у вас там есть WAIT, можно тормозить процессор на и не гнаться за скоростью

Что за WAIT?

и 16 бит адресса сравнивать не нужно, у вас же есть CS для нужного слота ?

Есть Slot select. Но, на слоте может сидеть несколько устройств, так что дешифратор адреса необходим.

по поводу CPM, для упрощения
т.к. ЦПМ обменивается ТОЛЬКО 128 байтными блоками то достаточно ей это обеспечить и всё.
т.е. это элементарно мапится на образ на SD карте.
на ПЦ уже работать с образами не напрягает.

? CP/M как бы уже успешно адаптирована под жесткие диски больших объемов. Поэтому я не понимаю, зачем обратно переходить на флоппи, пусть даже в виде образов?


Вообще же вы меня ребята запутали. Я уже и не знаю что требуется

[Advertiser]

[hantarex]

Хорошо, есть дешифратор, выставляющий некий CS, по которому микроконтроллер выставляет на шину некие данные. А тогда в чем принципиальная разница, если то же самое будет делать ПЗУ? Зачем МК эмулировать работу ПЗУ? Чтобы покупать самую дорогую модель МК?

некий CS вызывает прерывание при обращении к ВВ, ПЗУ эмулировать НЕ НУЖНО
(вообще - можно, в целях минимизации схемы)

например: по И складываем сигнал дешифратора старшей тетрады и сигнал ЧТ.ВВ. и заводим на INT0 меги. сигнал дешифратора старшей тетрады и сигнал ЗП.ВВ. заводим на INT1 меги. получается 16 адресов(устройств) мега дешифрует только младшие четыре бита адреса и выставляет-читает данные. эдакий байт-порт. мона использовать периферю меги: СОМ-порт, SPI, I2C. на SPI вешаем SD и какие-нит далассовские часы реального времени. СОМ-порт - и так понятно
это применительно к Atmega16. если использовать 128ю, или 256ю, у них вроде 5 внешних прерываний - мона весь дешифратор сделать внешней схемой

Вообще же вы меня ребята запутали. Я уже и не знаю что требуется

ничего не требуется, только предлагается

---------- Post added at 10:24 ---------- Previous post was at 08:38 ----------

а еще мона поюзать вот это http://zx-pk.ru/showpost.php?p=208744&postcount=144
ежели в СР\М настроить DMA, то процик мона ваще не юзать, все мега сделает

хотя, конешно, у пиков есть PBC(или PCB?), но я с ними не работал и помочь не смогу.

[DemonId7]

Все эти детали реализации в железе конечно интересны, но пока несущественны и лишь запутывают меня. Давай сначала проясним саму концепцию устройства, в твоем понимании. Что и для нужно, что за что отвечает, где хранится код и какой. И как все это взаимосвязано.
Моя идея предельно проста и по максимуму совместима с HDD. Есть два дешифратора - один для ПЗУ, другой для МК (если выводов хватит, то сам МК будет дешифратором).
С ПЗУ все по старому - она отображается на адреса 4000h-8000h, и является хранилищем как самой ОС, так и загрузчика этой ОС в память ПК. То есть ПЗУ используется стандартно, как на контроллерах FDD и HDD.
МК же используется исключительно как конвертер интерфейсов SPI в шину данных и обратно. Для этого он предоставляет несколько портов - порт адреса, порт данных, порт операции и порт статуса операции. Для этого потребны лишь линии Чт.ВВ, Зп.ВВ, и 8 адресных линий. Плюс линии для SD. И все.
При старте ПК управление получает загрузчик в ПЗУ, который грузит из ПЗУ ОС куда треба и передает ей управление. Сама ОС обращается к SD через порты, то есть посредством МК.
Как то так. В принципе ОС не обязательно хранить в ПЗУ, можно прямо на диске. Но память не безгранична и ПЗУ помогает более эффективно ее использовать. Да и наиболее критически важные подпрограммы не затрутся в случаях ошибок ПО.
Как то так

[esl]

Хорошо, есть дешифратор, выставляющий некий CS, по которому микроконтроллер выставляет на шину некие данные. А тогда в чем принципиальная разница, если то же самое будет делать ПЗУ? Зачем МК эмулировать работу ПЗУ? Чтобы покупать самую дорогую модель МК?

как не смешно, для удешевления конструкции
самую дорогую модель и не нужно,
да и запрграммировать МК сегодня проще чем олдфаг УФ ПЗУ.

Не понял, порядок чтения чего? И откуда мы его точно можем знать?
БИОС ПК, после старта, мэппирует поочередно разъемы расширения на адрес 4000h, выискивая на них сигнатуру наличия ПЗУ. Если нашел, то читает оттуда же адрес, на который и передает управление.

давайте исходить из реальности
есть живая ПК8000, и в реале к ней не будет подключено ничего кроме эмулятора, это раз.
вы всё знаете, только пока не догадываетесь об этом.
давайте по шагам распишем что происходит

опишу HAPPY PATH (т.е. если всё удаётся)
биос доходит до проверки ПЗУ

код из ПЗУ

ROM:24C6 checkROM:                               ; CODE XREF: do_Start+6Dp
ROM:24C6                                         ; do_Start+74p ...
ROM:24C6                 lxi     d, 4000h
ROM:24C9                 ldax    d
ROM:24CA                 cpi     'A'             ; if [4000h] != 'A' then exit
ROM:24CC                 rnz
ROM:24CD                 inx     d
ROM:24CE                 ldax    d
ROM:24CF                 cpi     'B'             ; if [4001h] != 'B' then exit
ROM:24D1                 rnz
ROM:24D2                 inx     d
ROM:24D3                 ldax    d
ROM:24D4                 mov     l, a
ROM:24D5                 inx     d
ROM:24D6                 ldax    d
ROM:24D7                 mov     h, a
ROM:24D8                 pchl                    ; jmp [4002h]

[свернуть]

он выставляет CS нужному слоту
читает байт 4000 A
читает байт 4001 B
читает байт 4002 LO
читает байт 4003 HI (для простоты пусть там будет 4004)
читает байт 4004 .....

т.е. ЗНАЯ точно порядок чтения, можно обойтись 1 битом для адресса
(детект изменения A0)

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

Что за WAIT?

ошибся, я имел в виду HLDA
на схеме это 40 вывод разъема
(блин, ну как всегда, документация тех компов - теплых слов не выдерживает, в табличке там прочерк)

т.е. внешнее устройство может затормозить проц, сделать своё грязное дело, и отпустить проц, т.е. нет нужны в жестком тайминге со стороны однокристалки.

я не электронщик, по этому это может быть ересью.

CP/M как бы уже успешно адаптирована под жесткие диски больших объемов. Поэтому я не понимаю, зачем обратно переходить на флоппи, пусть даже в виде образов?

можно пример ?
как я понимаю просто ставится размер диска в параметрах нужный ?

и кто вам запрещает использовать "образ" размером 8 мб ?
только без диреторий удобство работы с многомегабайтными "дисками" стремиться к 0.
вас же не заставляют использовать образы по 320к
сделайте по 1 мб, для цпм это огромный размер.
так образы выполняют роль "директорий"

а на пц для цпм есть куча тулзов для работы с образами
куча плагинов для far/total
если они пока не понимают дисков для ПК8000 - вопрос решаемый.

и еще раз, для ЦПМ все диски имею сектор 128 байт ......
задача биоса с конвертировать физический размер сектора в логические которыми оперирует цпм ...
и макс размер "диска" 128*256*256/1024/1024 ~8 мб

[DemonId7]

как не смешно, для удешевления конструкции
самую дорогую модель и не нужно,
да и запрграммировать МК сегодня проще чем олдфаг УФ ПЗУ.

Есть флэши, программируются даже с самого ПК. Так что как раз это не проблема. При желании можно в схеме это предусмотреть и обновлять ПЗУ прямо с ПК8000

давайте исходить из реальности
есть живая ПК8000, и в реале к ней не будет подключено ничего кроме эмулятора, это раз.

Ээээ... Я вроде как к ней винт подключил и Compact Flash. SD - это просто более удобное средство переноса файлов между ПК и PC, так как допускает динамическое подключение.

т.е. ЗНАЯ точно порядок чтения, можно обойтись 1 битом для адресса
(детект изменения A0)

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

Кто же его грузить то будет? БИОС ПК этого не делает, он тупо передает управление на считанный адрес с ПЗУ, справедливо полагая, что туда отображается ПЗУ с разъема расширения.
Поэтому я и не врублюсь, что даст лишь одна линия адреса?

ошибся, я имел в виду HLDA
на схеме это 40 вывод разъема

Ее нет. Это были хотелки проектировщиков на следующую модель, которая так и не увидела свет.

т.е. внешнее устройство может затормозить проц, сделать своё грязное дело, и отпустить проц, т.е. нет нужны в жестком тайминге со стороны однокристалки.

Тайминг - это радиолюбительский трюк. По хорошему создается порт статуса, по которому программа отслеживает готовность данных от/к МК.

можно пример ?
как я понимаю просто ставится размер диска в параметрах нужный ?

Нет. Параметры диска хранятся на самом диске, как это сделано в MS-DOS. Поэтому система может работать с дисками любых размеров, хватило бы памяти.

и кто вам запрещает использовать "образ" размером 8 мб ?

Никто. А зачем, если система может работать непосредственно с диском?

только без диреторий удобство работы с многомегабайтными "дисками" стремиться к 0.

Это было бы справедливо, будь количество файлов хотя бы под 200 и выше.

Тем более:

так образы выполняют роль "директорий"

Система может работать с несколькими дисками сразу - на одном храним утилиты, на другом - игрушки, на третьем музон и тд. Это не считая областей USER.

а на пц для цпм есть куча тулзов для работы с образами
куча плагинов для far/total
если они пока не понимают дисков для ПК8000 - вопрос решаемый.

Вы бы тему на несколько страниц отмотали

и еще раз, для ЦПМ все диски имею сектор 128 байт ......
задача биоса с конвертировать физический размер сектора в логические которыми оперирует цпм ...
и макс размер "диска" 128*256*256/1024/1024 ~8 мб

В моей реализации и 32Мб подключаются, по несколько сразу Программисты мы, или хрен собачий?

[esl]

ЦПМ как я понимаю и не получится в ПЗУ хранить
все реализации что я видел - читают ее в ОЗУ

и еще забыл озвучить
в однокристалку мы поместили не просто интерфейс к SD
а высокоуровневое апи
типа "смонтроуй диск DISK1.KDI" как диск A
"прочитай сектор с образа A:track:sector"
etc
т.е работа с фат и прочие радости жизни сидит в однокристалке
драйвер в CPM BIOS - минимален, т.к. нет буферов и прочего

к сожалению ПК8000 кривая копия MSX Ж(
в MSX дос сидит в ПЗУ
и по этой причине позволяет творить чудеса,
вон гляньте на nextor dos
там вон давече реализовали прозрачное монтирование образа диска с винта
при этом работает весь софт
и из бейсика все дисковые функции
т.к. биос куча хуков на все функции, и только стандартны точки входа.

[DemonId7]

ЦПМ как я понимаю и не получится в ПЗУ хранить
все реализации что я видел - читают ее в ОЗУ

Можно и в ПЗУ. Никто не запрещает. В моей реализации практически весь BIOS CP/M хранится именно в ПЗУ.

и еще забыл озвучить
в однокристалку мы поместили не просто интерфейс к SD
а высокоуровневое апи
типа "смонтроуй диск DISK1.KDI" как диск A
"прочитай сектор с образа A:track:sector"
etc

Вот как раз этого я и не хочу. Я сторонник жесткого разделения софта и железа. ОС отвечает за файловую систему, МК - за железки. А мешая все в кучу, мы только наживаем лишние проблемы.

к сожалению ПК8000 кривая копия MSX Ж(
в MSX дос сидит в ПЗУ
и по этой причине позволяет творить чудеса,

То же самое и на ПК8000. Единственно из-за чего не захотел портировать DOS-MSX - это геморой с разными процессорами и избыточность FAT для ПК.

вон гляньте на nextor dos

Гляну вечерком.

[esl]

Есть флэши, программируются даже с самого ПК. Так что как раз это не проблема. При желании можно в схеме это предусмотреть и обновлять ПЗУ прямо с ПК8000

а смысл ?
у нас STAGE2 LOADER читается с SD, а его заменить много проще чем флеш перешить.

Ээээ... Я вроде как к ней винт подключил и Compact Flash. SD - это просто более удобное средство переноса файлов между ПК и PC, так как допускает динамическое подключение.

я приблизительно про это и говорил
что в реальной жизни там будет одно устройство.

Кто же его грузить то будет? БИОС ПК этого не делает, он тупо передает управление на считанный адрес с ПЗУ, справедливо полагая, что туда отображается ПЗУ с разъема расширения.
Поэтому я и не врублюсь, что даст лишь одна линия адреса?

биос и будет, однокристалка эмулирует минипзу
биос то тупо передаёт, но проц память читать то не перестает ?

Ее нет. Это были хотелки проектировщиков на следующую модель, которая так и не увидела свет.

я посмотрел по схеме, там есть.
если нет - вариант с пзу будет проще.

Тайминг - это радиолюбительский трюк. По хорошему создается порт статуса, по которому программа отслеживает готовность данных от/к МК.

если мне не изменяет память то скорости ПК8000 не хватало даже для чтения вг93
и там был трюк с 4мя ячейками рама и хитрым циклом чтения ?

а тормозить проц для таких вещей имхо нормально.

Нет. Параметры диска хранятся на самом диске, как это сделано в MS-DOS. Поэтому система может работать с дисками любых размеров, хватило бы памяти.

и как это сделано у Корвета
в первых 128 байтах диска живет DPB и биос читая диск первый раз настраивается на него.

Никто. А зачем, если система может работать непосредственно с диском?

а зачем работать непосредственно с диском если можно это отдать в мозги контроллера ?

Это было бы справедливо, будь количество файлов хотя бы под 200 и выше.

не понял.
а сколько будет файлов в директории на диске размером 8 метров ?

Тем более:
Система может работать с несколькими дисками сразу - на одном храним утилиты, на другом - игрушки, на третьем музон и тд. Это не считая областей USER.

с коими в cpm работать жутко неудобно
в микродос - чуть удобнее.
да и ограничении на колв-во файлов в директории не отменяется.

В моей реализации и 32Мб подключаются, по несколько сразу Программисты мы, или хрен собачий?

это да

---------- Post added at 12:03 ---------- Previous post was at 12:00 ----------

Вот как раз этого я и не хочу. Я сторонник жесткого разделения софта и железа. ОС отвечает за файловую систему, МК - за железки. А мешая все в кучу, мы только наживаем лишние проблемы.

в этом месте наше мнение радикально расходится
в нашей реализации ос всё еще отвечает за файловую систему
просто для однокристалка от нее прячет тот уровень о которой цпм знать не стоит.
ибо таки да, работать на 8080 с FAT - это долго и дорого.

---------- Post added at 13:03 ---------- Previous post was at 12:03 ----------

Можно и в ПЗУ. Никто не запрещает. В моей реализации практически весь BIOS CP/M хранится именно в ПЗУ.

и ТПА пользователя увеличивается ??

[esl]

Перечитал тему
как в том анекдоте "много думал"
Половину тем мы уже выше обсуждали

[DemonId7]

а смысл ?
у нас STAGE2 LOADER читается с SD, а его заменить много проще чем флеш перешить.

Смысл в том, чтобы использовать предусмотренные производителем средства. Я бы вообще сделал все на рассыпухе, но что-то слишком сложно получается. Для меня сложно.

я приблизительно про это и говорил
что в реальной жизни там будет одно устройство.

Нет, не одно. У меня три подключаются - HDD, RTC и AY.

биос и будет, однокристалка эмулирует минипзу
биос то тупо передаёт, но проц память читать то не перестает ?

В принципе да. Но как то это на трюкачество смахивает

я посмотрел по схеме, там есть.
если нет - вариант с пзу будет проще.

По схеме HOLD действительно есть. А вот в руководстве по эксплуатации этот пин заявлен неподключенным. Вот и думай кому верить

если мне не изменяет память то скорости ПК8000 не хватало даже для чтения вг93
и там был трюк с 4мя ячейками рама и хитрым циклом чтения ?

Да, был. И, отдавая должное смекалке конструкторов, я бы за такие вещи бил по рукам. Если написать сколько проклятий сыпалось от программистов на инженеров, например за стандарт VGA нашпигованный такими радиолюбительскими трюками, то получился бы многотомник побольше всех собраний сочинений Ленина.

и как это сделано у Корвета
в первых 128 байтах диска живет DPB и биос читая диск первый раз настраивается на него.

Не в курсе. Я сразу ориентировался на разбиение диска на логические разделы, утилитой fdisk из DOS'а, а значит каждый диск должен был иметь свой блок параметров.

а зачем работать непосредственно с диском если можно это отдать в мозги контроллера ?

В любой ОС предусмотрены модули/драйвера как раз для работы с железом на низком уровне. И если ОС работает с принтером и видео напрямую, то почему не должна работать с носителями?

не понял.
а сколько будет файлов в директории на диске размером 8 метров ?

Сколько зарезервируешь места при форматировании диска. Там ключами выбирается размер кластера и директории.

и ТПА пользователя увеличивается ??

Что?

---------- Post added at 20:12 ---------- Previous post was at 20:11 ----------

Перечитал тему
как в том анекдоте "много думал"
Половину тем мы уже выше обсуждали

Одно дело обсуждать перспективы, а другое решать законченный вид девайса.
Неплохо бы услышать мнение всех заинтересованных сторон, чтобы уж окончательно определиться