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

[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 мб