Важная информация

User Tag List

Страница 8 из 24 ПерваяПервая ... 456789101112 ... ПоследняяПоследняя
Показано с 71 по 80 из 238

Тема: Самодельный комп на i8080

  1. #71
    Moderator
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    4,577
    Спасибо Благодарностей отдано 
    61
    Спасибо Благодарностей получено 
    106
    Поблагодарили
    92 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Vadim Посмотреть сообщение
    200К это только для ФАТ16. ФАТ12 ограничена 12К и там просто всё летает. Диск размером в 32М на ФАТ12 работает очень быстро, вам такие скорости даже не снились уверяю. А далее, с вами согласен насчёт недостатков ФС ЦПМ, про экстенты и большие диски. Всё так и есть.
    Опять вставлю свои 5 копеек, раз уж тут такой откровенный флейм.
    ФАТ12 же позволяет обслужить в файловой системе только 64Мб на максимальном кластере (или 32Мб? забыл я уже... давнишнее дело то). Значит, она уже маловата для серьезных нужд, и надо смотреть в сторону FAT16, где все уже будет медленнее. И опять же откуда информация (уже больше к barsik вопрос) по то, что большие логические блоки - это плохо? Это как раз таки очень хорошо, т.к. снижает количество блоков, снижает требование к размеру ALV, уменьшает количество экстентов в каталоге на файл (т.е. больше файлов запишется при прочих равных), и ускоряет построение битовой маски занятости блоков (той самой - BDOS функции 27/31). А физическое чтение BIOS при любом размере блока(группы, кластера) все равно делает минимальным сектором устройства (если нет задачи буферизировать вероятное чтение следующего блока), т.е. тут разницы по скорости никакой. Возможно чуть медленнее отработает функция перекодировки номера группы в номер сектора (на несколько команд сдвигов больше - микросекунды). Недостаток больших блоков один: меньшая эффективность хранения по емкости (больше "пропадает" места на носителе для не полностью занятого последнего блока файла) - менее выгодно хранить кучи мелких файлов. Но это будет аналогично и на FAT-е с большим кластером.

    И упоминание про медленные большие ФС как мне кажется растет именно отсюда - из попыток растянуть формат принятый CP/M для дискеток (с блоком 1..2кб) на большие разделы, а всего то надо было - переформатировать на большой блок.

    К примеру, в ССР где я делал свои хотелки, размер занятого и свободного пространства на диске у меня выводится каждый раз при выполнении dir, т.к. никакой видимой задержки (с блоком 8 или 16 кб) это не дает.
    Нажмите на изображение для увеличения. 

Название:	dir.jpg 
Просмотров:	223 
Размер:	25.2 Кб 
ID:	59743
    Также, для ускорения, носитель в CP/M можно объявить несменным (CSV=0 в описателе диска в BIOS), и тогда не будет выполняться контроль (пересчет) каталога для защиты от неожиданной замены дискетки. Я даже это делать не стал, у меня все HDD - сменные носители (т.к. это в т.ч. и CF/SD-карты), но видимых задержек все равно не заметно, уж по крайней мере в сравнении с дисководом.
    Последний раз редактировалось Error404; 13.02.2017 в 15:17.
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

  2. #72
    Activist Аватар для ALS
    Регистрация
    14.09.2012
    Адрес
    г.Севастополь
    Сообщений
    427
    Спасибо Благодарностей отдано 
    234
    Спасибо Благодарностей получено 
    67
    Поблагодарили
    47 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от freddy Посмотреть сообщение
    ...Поэтому, если не учитывать архитектуру и железо машин, а взять чисто процессор, я бы выбрал всеже 8080 на большей частоте.
    Согласитесь, выбирать можно что угодно, но вот так безаппеляционно заявлять, что что-то там тормозное и непрогрессивное - это по меньшей мере моветон.
    И такие заявы на этом (и подобных) форумах всегда вызывают негодование.

    Скрытый текст

    Я сейчас утрирую, конечно, и не желаю никого обидеть, но это все равно, что слышать от какого-нибудь еврообщечеловека "Как, вы не долбитесь в ж*ппку ? Фи, это удивительно. Так старо и тормозно..."
    [свернуть]
    Последний раз редактировалось ALS; 13.02.2017 в 15:20.

  3. #73
    Moderator
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    4,577
    Спасибо Благодарностей отдано 
    61
    Спасибо Благодарностей получено 
    106
    Поблагодарили
    92 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    И потом, мы тут забываем один очень важный момент - он называется "плата за удобство". Я например готов платить за большое TPA чуть большей тормознутостью работы (т.к. ядро ОС пришлось унести в другие страницы и делать туда вызовы). Готов на то что удобство больших по емкости носителей что-то может тоже привнести в общее замедление. Удачно, что не привнесло (т.к. новые носители быстрее старых, новые процы быстрее, и т.п.)
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

  4. #74
    Master
    Регистрация
    05.01.2009
    Адрес
    г. Одесса, Украина
    Сообщений
    548
    Спасибо Благодарностей отдано 
    16
    Спасибо Благодарностей получено 
    150
    Поблагодарили
    66 сообщений
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от ALS Посмотреть сообщение
    Я сейчас утрирую, конечно, и не желаю никого обидеть, но это все равно, что слышать от какого-нибудь еврообщечеловека "Как, вы не долбитесь в ж*ппку ? Фи, это удивительно. Так старо и тормозно..."
    Ну да, в общем в стиле 6502. Сказано зачетно!

    - - - Добавлено - - -

    Цитата Сообщение от Error404 Посмотреть сообщение
    И потом, мы тут забываем один очень важный момент - он называется "плата за удобство". Я например готов платить за большое TPA чуть большей тормознутостью работы (т.к. ядро ОС пришлось унести в другие страницы и делать туда вызовы). Готов на то что удобство больших по емкости носителей что-то может тоже привнести в общее замедление. Удачно, что не привнесло (т.к. новые носители быстрее старых, новые процы быстрее, и т.п.)
    Может я зря нацелился на классическую CP/M? И еще, зачем этому УГ на 8080, что я строю, большие диски и много файлов? каков от этого практический смысл? Немного в голове не укладывается, просветите пожалуйста. Я в старых осях не силен. Хорошо знаю только MS-DOS
    MSDOS однако 8080 не осилит...
    Real Hardware!

  5. #75
    Moderator
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    4,577
    Спасибо Благодарностей отдано 
    61
    Спасибо Благодарностей получено 
    106
    Поблагодарили
    92 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от freddy Посмотреть сообщение
    Может я зря нацелился на классическую CP/M? И еще, зачем этому УГ на 8080, что я строю, большие диски и много файлов? каков от этого практический смысл? Немного в голове не укладывается, просветите пожалуйста. Я в старых осях не силен. Хорошо знаю только MS-DOS
    MSDOS однако 8080 не осилит...
    Зависит от планов по использованию и пристрастий. Если просто хранить файлы, то наверное любая система подойдет (и можно даже без системы, а как на Спеке - отдельными прогами, например командером и терминалом, выйти из положения). Если же какие-то есть более широкие планы по применению (например комфортно править файлы любого размера {в пределах носителя конечно}), или использовать какие-то среды программирования, то тут (на 8080, и тем более если Z80) конкурентов у CP/M (+MSXDOS) практически и нет. Что до размера диска, то например лучший нативный C для Z80 (на 8080 не пойдет) Hitech C занимает с либами 800к дискету уже сам по себе, а ведь еще надо место под проект (еще 800к как минимум, а у меня есть проекты и на мегабайты только исходника на С). Аналогично Паскаль МТ+ (он для 8080) если не подводит мой склероз, с либами тоже с трудом лезет на 800к. Wordstar ЕМНИП тоже большой - с оверлеями, а вдруг вам надо бухгалтерию на dBase (реально видел в 90-х конторы с dBase) - так это уже база данных с соответствующими требованиями. Как то так.

    - - - Добавлено - - -

    Кроме того, CP/M проще в портировании: BDOS и консольный процессор можно взять вообще готовыми (бинарным куском)- они аппаратно независимы, адаптировать надо только BIOS (те самые подпрограммы ввода-вывода на консоль и на диск) и загрузчик.
    Последний раз редактировалось Error404; 13.02.2017 в 16:26.
    Лучше сделать и жалеть, чем не сделать и жалеть.

    Некоторые из моих поделок тут: https://github.com/serge-404

  6. #76
    Guru Аватар для Vadim
    Регистрация
    24.07.2008
    Адрес
    г. Курган
    Сообщений
    2,062
    Спасибо Благодарностей отдано 
    10
    Спасибо Благодарностей получено 
    17
    Поблагодарили
    17 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Error404 Посмотреть сообщение
    ФАТ12 же позволяет обслужить в файловой системе только 64Мб на максимальном кластере (или 32Мб? забыл я уже... давнишнее дело то)
    Если принять, что диск в ФАТ12 может иметь максимально FF0 -1 -2 (нумерация идёт с 2), получаем FED=4077 кластеров. Кластер, размером в 64К я не делал, не знаю обработает ли такой диск msdos/windows, а вот 32К делал и диск вполне валидный с т.з. ms-dos/windows, получаем его размер 127М. Но родные утилиты dos/windows при размере диска более чем 16М включают ФАТ16. У меня в системе есть свой форматтер и там ключами можно задать любые возможные параметры (валидные имею ввиду). Диск в 32М - это было ограничение в ms-dos 3.30 и в моей системе, пока я не сделал 32 бит на номер начального сектора при обращении к дисковому драйверу. Пока ограничение было, то диск был ограничен 32М на ФАТ12 (ФАТ16 в то время тоже у меня не была поддержана). Сейчас все эти ограничения сняты, и можно отформатить 127М диск на ФАТ12, в PQDOS он будет работать точно. И свободное место система будет выдавать быстро, т.к. надо просканировать всего 6К.
    Теперь про размер таблиц ФАТ -в ФАТ12 не более 6К даже (про 12 я соврал). Функция получения свободного места очень быстро может её прощёлкать, а вот когда пробуем в PQ-DOS получить размер свободного диска на лог.диске размером 400-600М, на ФС - ФАТ16, то там уже секунд 15 стоит втупливание (идёт прочитка ФАТ). Не минуты, а 15 с, но это всё равно долго. Любые вычисления показывают, что это время вполне нормальное. Объём данных большой, уменьшить его до 1-2 с нереально или почти нереально. И я решил закешировать значения свободного места. Для не сменных дисков (а винты у меня не сменные) в дисковой таблице хранится значение кол-ва свободных кластеров.
    Последний раз редактировалось Vadim; 13.02.2017 в 17:15.

    Скрытый текст

    Profi 5.06 1024K 12Mhz (кварц на 24), палитра, COM-порт, часы, hdd, covox, программатор
    ZX-Spectrum +3, ZX-Spectrum +2B, ZX-Spectrum +2, ZX Spectrum 48, ZX Spectrum 48+
    ZX Evolution Rev B.
    Color 48 + Beta Disk Interface +FDD+YM2149F
    Орель-08БК
    Pentagon-48 (недоссобранный кем-то)
    Pentagon-128 (полуубитый)
    Кворум-128 (в ремонте)
    Магик-05 (в ремонте)
    Robotron 1715
    Корвет ПК8020 и ПК8010
    Amstrad CPC 464
    Amstrad CPC 6128
    [свернуть]

  7. #76
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  8. #77
    Banned
    Регистрация
    05.10.2016
    Адрес
    г. Санкт-Петербург
    Сообщений
    1,080
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    5
    Поблагодарили
    5 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Vadim
    Очень странно, что вы не в курсе о 6502, хотя об этом проце писали ещё в середине 90х, что не смотря на низкую тактовую частоту производительность у него как минимум не хуже, чем у Z80/i8080 благодаря тому, что команды исполняются быстрее.
    Это обсуждали не в 90-тые, а на 20 лет раньше в журналах 1975-76 годов и чётко установили, что 6502 немного уступает даже 8080 с тактом 2 МГЦ. Это признавал и сам разработчик 6502. А когда в 1976 появился 8080A с тактом 2.5 МГЦ, то 6502 с тактом 1 МГЦ остался далеко позади. А когда в 1978 появились клоны 8080 с тактом в 3.15 и 3.5 МГЦ, то 6502 остался просто в заднице. И только в начале 80-тых, когда появился 65C02 и позднее 65816, то ситация перевернулась. Но речь то шла именно о 6502 в сравнении с КР580 и Z80.

    Я это и имел ввиду, что 6502 ошибочно приписывают превосходство над КР580 и даже над Z80, что вообще наглость http://ruecm.forum2x2.ru/t895-topic#10882.

    Цитата Сообщение от Vadim
    Я использовал Profi 5.03 в 1996 ... скорость была быстрее дискетной в ~4 раза
    Утверждение, что IDE-контроллер работает в 4 раза быстрее, чем контроллер на ВГ93, заставили меня задуматься.

    Конечно частично выигрыш вызван тактом CPU. Жаль, что не приведён использованный такт Z80 (в ZX такт Z80, минимум, 3.5 МГЦ). Скорость обмена с IDE прямо зависит от CPU, тогда как для флопа скорость обмена от скорости CPU не зависит. Такт CPU 2.5 МГЦ - минимальный для флопа на 800К. На этой частоте и надо производить сравнение, чтобы выяснить на сколько обмен с винтом быстрее. После чего можно считать выигрыш при любом такте Z80.

    Проанализировав п/п-ммы я пришёл к выводу, что винт должен работать быстрее, чем дисковод. Даже, хотя бы потому, что в дисководных п/п-мах опрашивается готовность, а в IDE этого нет. Всё происходит без тормозов.

    Посчитав число маш.тактов подпрограмм, я обнаружил, что моя подпрограмма для винта вдвое быстрее, подпрограммы для ВГ93, даже без учета циклов готовности.

    Неизбежен вывод, что использованный мной винт - тормозной. Ранее, идею о тормознутости винта я даже не брал в рассмотрение, т.к всякий знает, что винт по определению на порядок более скоростной, отчего скорость обмена ограничена только со стороны компьютера. Потому невозможно предположить, что винт медленный. Ведь винт считал сектор и далее идёт обмен только со скоростью электроники и без тормозов

    Использованный винт от ноутбука из начала 90-х, в мини-факторе и, соответственно, низкопотребляющий и энергосберегающий (сам выключает мотор через 5 секунд простоя). Возможно в нём нет кэша и не читается сразу 32К соседних секторов. Вывод: не покупайте старых винтов от ноутбука.

    Скорость обмена с винтом никак не отменяет торможения при чтении большого каталога на медленном CPU. Хотя, если скорость обмена выше в 3 или 4 раза, то приемлемым объёмом партиции становится уже не 4 мб, а 12 или 16 мб. Но не гигабайты.

    Цитата Сообщение от Sayman
    Расскажите, что в вашем понимании логические и физические сектора?
    Это не в моём понимании. Это во всём мире так. Лог.сектор это 128 байт и BDOS вызывает BIOS п/п-ммы READ/WRITE, что делают обмен с тем лог.сектором, что задан функциями SETTRK, SETSEC. В MSDOS и MSX-DOS точно также. Ну а физический сектор, как его понять как-то иначе?

    Цитата Сообщение от Sayman
    Цитата Сообщение от barsik
    У Apple-II, MSX и Commodore совсем другой (и гораздо более убогий) контроллер
    Серьёзно? Пользователи MSX и Apple с вами очень сильно не согласны
    Они согласны. КНГМД в Apple-II всего на 6-ти TTL корпусах, где SOFT-sectored диски 120К и весь обмен, управление фазами мотора и даже упаковку байтов делает 6502, отчего обмен ненамного быстрее обмена с МГ. Скорость обмена с диском у Commodore потрясает тормознутостью. А у MSX формат 720К меньше 800К КОРВЕТА, а HD-формат, как ОРИОН, он не читает.

    Цитата Сообщение от Sayman
    Цитата Сообщение от barsik
    На дискете грамотной CP/M Вы считаете BOOT-сектор
    Что в вашем понимании "грамотная дискета CP/M"? Я ещё раз напомню, что форматов дисков для CP/M превеликое множество
    Написано о грамотной версии CP/M, не о дискете. А грамотной CP/M делает её BIOS. В хорошей реализации, должна быть гибкая процедура загрузки, позволяющая грузить ЛЮБУЮ ДОС в любые адреса и банки, т.е по определению должен быть BOOT-сектор. А сама ДОС должна грузить и читать диски любого формата. И даже, если Вы пользуетесь дисками одного формата, Вам захочется получить доп.объём, отформатировав диск не на 80 дорожек, а на 83 дорожки. ОРИОН это может, а ПРОФИ - нет. На ОРИОНЕ мы можем продлить жизнь старых дисков ИЗОТ 1985 года используя FM вместо MFM (т.е SD вместо DD), а на ПРОФИ дохлые диски придётся выкинуть.

    Цитата Сообщение от Sayman
    Цитата Сообщение от barsik
    Что в ПРОФИ сам код CP/M грузится из файла, как в MSDOS?
    Поясните этот момент? Не понятно про что вы говорите. Если вы говорите про загрузку системы с диска, ну так да. Любая нормальная DOS должна загружаться с диска. а не как у ATM из ПЗУ
    Вообще-то это был вопрос. Хотелось узнать откуда там грузится CP/M. Раз системных треков нет, то остаётся вариант загрузки из ПЗУ или из дискового файла.

    Для ответа придётся изложить общеизвестные истины.

    Скрытый текст

    По базовой концепции CP/M сам код этой DOS хранится на системных треках и в зависимости от числа байтов на дорожке, на систему тратится от 1-й до 6-ти дорожек. Число системных дорожек читается из БПД в BOOT-секторе, что позволяет иметь на дискете каталог на любой дорожке и тем самым можно иметь и несистемные диски в которых не тратятся впустую системные дорожки. На ОРИОНЕ это свойство не использовалось, т.к не было форматёра, который задавал бы вопрос о том, надо ли резервировать место для системных треков или каталог можно сразу размещать на дорожке 1 (он появился несколько лет спустя, когда CP/M ОРИОНА уже устоялась). Заметим, что в системах, где есть BOOT-сектор, хранящий загрузчик CP/M, каталог не может располагаться в треке 0, т.к там BOOT-сектор, а каталог должен начинаться с начала трека.

    В продвинутых CP/M, а также в MSDOS и MSX-DOS, чтобы не тратить впустую место на несистемных дисках на резервированные под систему дорожки, сам код ДОС помещают в дискетные файлы. Обычно это CPMBIOS.SYS, CPMDOS.SYS и COMMAND.COM (или CCP.SYS).

    Вторичный загрузчик имеет очень маленький объём, потому грузит только файл CPMBIOS.SYS, причём беря его код с фиксированного места дискеты, из первого-же блока сразу после конца каталога. Именно поэтому в MSX-DOS и MSDOS системные файлы надо копировать на пустую дискету. При ДОС в дискетных файлах, если на диске есть системные файлы, то диск загрузочный, а если нет, то рабочий, зато в нём больше свободного места.
    [свернуть]
    Последний раз редактировалось barsik; 28.11.2017 в 08:00.

  9. #78
    Guru Аватар для Vadim
    Регистрация
    24.07.2008
    Адрес
    г. Курган
    Сообщений
    2,062
    Спасибо Благодарностей отдано 
    10
    Спасибо Благодарностей получено 
    17
    Поблагодарили
    17 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от barsik Посмотреть сообщение
    Утверждение, что IDE-контроллер работает в 4 раза быстрее, чем контроллер на ВГ93, заставили меня задуматься.

    Конечно частично, выигрыш вызван тактом CPU. Жаль, что не приведён использованный такт Z80 (в ZX такт Z80, минимум, 3.5 МГЦ).
    На том экземпляре Профи была тактовая частота 9Мгц, но с wait'ами. Можно принять что это примерно равно 7Мгц без вейтов.


    Цитата Сообщение от barsik Посмотреть сообщение
    Хотя, если скорость обмена выше в 3 или 4 раза, то приемлемым объёмом партиции становится уже не 4 мб, а 12 или 16 мб. Но не гигабайты.
    Разделы были по 8Мб в той системе. Насколько я помню. Просмотр каталогов был хоть и не мгновенный, но и не медленный. Каталог на 256 входов.


    Цитата Сообщение от barsik Посмотреть сообщение
    Написано о грамотной версии CP/M, не о дискете. А грамотной CP/M делает её BIOS. В хорошей реализации, должна быть гибкая процедура загрузки, позволяющая грузить ЛЮБУЮ ДОС в любые адреса и банки, т.е по определению должен быть BOOT-сектор.
    Вот это про тот мой ответ о BIOS-CP/M профи. Отвечу сейчас о настраиваемом драйвере дисков в ЦПМ. Как Сейман писал выше - форматов было много, очень много. Автор ЦПМ как-то не придумал хранить параметры диска в каком-то определённом месте. Он предполагал, что вот мы делаем нашую некую адаптацию ЦПМ, выбираем физический формат диска, втискиваем логический, потом все параметры из этого посчитали, забили в исходник BIOS-CP/M откомпилировали и всё. Так и было в подавляющем большинстве ЦПМ машин. А вот в ms-dos придумали хитро хранить параметры диска в бут секторе. И сделали это стандартом. Решение надо признать очень здравое. Не так давно я узнал, что такой же принцип использовали и в фирме Амстрад, в самом первом секторе дискеты, который там тоже называется boot там есть параметры дискеты, CKS, DRM и прочее - всё что нужно. Но это не стандарт, другие системы ничего о их "стандарте" и слыхом не слыхивали. Из вашего поста узнал, что и на Корвете так же было сделано. Но повторю - это исключение и не стандарт.
    И да, в МикроДОС на Профи понятия бут сектора с параметрами не было. "биос" - глупый. А в PQ-DOS у меня всё не так. Там нет БИОС ЦПМ, он есть но только в рамках эмуляции, и дисковые точки входа там не работают вообще.

    - - - Добавлено - - -

    Цитата Сообщение от barsik Посмотреть сообщение
    Вообще-то это был вопрос. Хотелось узнать откуда там грузится CP/M. Раз системных треков нет, то остаётся вариант загрузки из ПЗУ или из дискового файла.
    В самых первых версиях МикроДОС на профи система грузилась, как и должна была, с системных треков. Таких вариантов системного диска мне долго найти не удавалось, только упоминания о ней (но в конце концов я такой образ нашёл и посмотрел). А то, что видели массы, уже была версия когда кол-во системных треков свели к нулю. Загрузчик был в виде файла и получал управление не важно как, но получал, оказавшись в ОЗУ он считывал каталог (каталог начинался с первого сектора на диске), находил в нем файлы ОС, а их было 2 - BIOS.BIN BDOS.BIN, читал их куда надо и всё что нужно делал, после чего передавал управление CCP.

    - - - Добавлено - - -

    Цитата Сообщение от barsik Посмотреть сообщение
    Заметим, что в системах, где есть BOOT-сектор, хранящий загрузчик CP/M, каталог не может располагаться в треке 0, т.к там BOOT-сектор, а каталог должен начинаться с начала трека.
    бут сектор в Профи сделали не 1-м, как везде, а 5-м по счету на 0-м цилиндре. Секторов 5 по 1024 байт. Изначально они имели номера 1,2,3,4 и 5. Но. Профи это продвинутый спектрум. И вот люди решили сделать так, что бы ЦПМ стартовала из TR-DOS, вдаваться в подробности не буду, важно что бы у нас был сектор номер 9 размером более 256 байт, тогда можно сделать так, что от любой команды в trdos, например CAT. Перехватывается управление кодом самого сектора. И диск может запуститься. Для реализации этой возможности формат на дрожке 0 головы 0 изменили. Секторы стали иметь номера 1,2,3,4 и 9. Первые 4 сектора это каталог. 128 входов. С сектора 9 начинается область данных диска. Первым файлом на дискету пишется файл загрузчика. И он работает перехватом управления из трдос, по её ошибке. И как ЦПМ программа при запуске из ЦПМ. Вот так.

    Скрытый текст

    Profi 5.06 1024K 12Mhz (кварц на 24), палитра, COM-порт, часы, hdd, covox, программатор
    ZX-Spectrum +3, ZX-Spectrum +2B, ZX-Spectrum +2, ZX Spectrum 48, ZX Spectrum 48+
    ZX Evolution Rev B.
    Color 48 + Beta Disk Interface +FDD+YM2149F
    Орель-08БК
    Pentagon-48 (недоссобранный кем-то)
    Pentagon-128 (полуубитый)
    Кворум-128 (в ремонте)
    Магик-05 (в ремонте)
    Robotron 1715
    Корвет ПК8020 и ПК8010
    Amstrad CPC 464
    Amstrad CPC 6128
    [свернуть]

  10. #79
    Banned
    Регистрация
    05.10.2016
    Адрес
    г. Санкт-Петербург
    Сообщений
    1,080
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    5
    Поблагодарили
    5 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Ранее в этой теме знатоки высказали идею, что в CP/M возможны огромные диски, а максимальный размер файла ограничен в 8 мб. Для проверки я заглянул в ДОК по CP/M, посмотрев раздел, где описаны поля FCB. Вот, что я обнаружил.

    EX - текущий номер экстента. В процессе ввода/вывода файла находится в диапазоне 0...31

    В документации также указано, что поле RC (офсет 15), показывающее сколько лог.секторов описывает экстент с номером EX и может быть только в диапазоне 0...128.

    Если руководствоваться только этими описаниями можно думать, что RC это число лог.секторов описанных в этом экстенте. И таким образом каждый экстент не может хранить более 128*128= 16 кб. И тем самым, исходя из ограничения поля EX (номер экстента) в 32 и получается ограничение размера файла в 16*32 = 512 кб.

    Если разбираться, то выяснится, что поле RC действительно не превышает 128, но это не число лог.секторов описанных в этом экстенте. Таким образом документация точно вводит в заблуждение.

    Если размер блока умноженный на 8 содержит более 128 лог.секторов, то шаг нумерации экстентов превышает 1. В частности, при блоках в 4К и размере файла более 16К, номер первого экстента (EX) становится не 0 (как при блоках 1К и 2К), а 1, и поле RC показывает не общее число лог.секторов описанных этим экстентом, а остаток от деления на 128. Я никогда не имел размера блока более 2 кб, поэтому удивился увидев такое. Может быть это у меня глючная версия CP/M.

    Таким образом получается, что поле EX это не текущий номер экстента, как указано. Точнее так, только при блоках в 2К, тогда в этом поле в экстентах числа 0,1,2,3.... А например, при блоках в 4К в этом поле экстентов оказываются числа 1,3,5... Таким образом поле EX считает не сами экстенты, а 16-ти килобайтные куски файла. И тем самым даже при блоках в 16К, при ограничении поля EX в 31 нельзя иметь файлы более 512К.

    Очень многие программы, считают размер файла вручную, суммируя поля RC у всех экстентов файла. Так получается всё верно при размере блока в 1 или 2К. Программы так делают, потому что один раз считать каталог, и узнать размеры всех файлов таким способом быстрее, чем для каждого файла вызывать функцию 35, возвращающую размер файла в лог.секторах в полях R0,R1.

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

    Выше приведено утверждение из мануала, что поле EX не может превышать 31. Если этому верить, то величина максимального размера файла не может превышать 512К даже при блоках в 16 кб. Но тогда почему из описания функции прямой записи следует, что можно писать в файл размером до 8 мб?

    Вместо того, чтобы гадать, необходимо проверить на практике. К сожалению в моём эмуляторе ОРИОНА слишком маленькие диски (только из ОЗУ). Поэтому я решил странслировать дискетную версию CP/M с блоками в 4,8,16 кб и погонять её в эмуляторе B2M. Но столкнулся с трудностями использования эмулятора B2M. Но это другая тема.

    Дополнение к теме несовместимости CP/M и MSX-DOS. Проблемы несовместимости CP/M и MSX-DOS вызывает не только отсутствие Allocation Table, но и отличие в работе BDOS функций использующих FCB. Вот что пишут об этом:

    Существуют CP/M-программы которые "смотрят слишком пристально" на поля FCB. Что и вызывает проблемы. Это делают даже некоторые продукты написанные Microsoft до появления MSX-DOS. Речь идёт о полях FCB+14 (S2, поле для внутреннего использования CP/M) и FCB+15 (RC, счётчик записей в текущем экстенте)
    Узнал, что первый эмулятор 8-ми разрядки написал Тим Паттерсон.

    Скрытый текст


    Тим Патерсон - американский программист, наиболее известный как автор первой версии MSDOS, наиболее широко используемой операционной системы персональных компьютеров в 1980-ых.

    Мы недавно обратились к нему с вопросами и Тим любезно согласился поделиться историей разработки системы MSX-DOS с MSX Community. Вот его рассказ.

    Вот, что я могу вспомнить об истории MSX-DOS. 10 августа 1983 мне позвонил Пол Аллен и попросил меня сделать Z80 версию MSDOS. Я не ухватился за это предложение, поскольку был тогда занят подготовкой к выпуску первых продуктов Falcon Systems. Я предложил ему обратиться сначала к одному программисту, кто мог бы это сделать, затем к другому, но он сказал, что у них уже спросил. Он сказал, что это надо сделать в сжатые сроки и никто другой не согласился на такие условия. Но он предложил хорошие деньги и разрешение для моей компании распространять MSDOS. Так что я решил, что это хорошая сделка. 17 августа я подписал договор на разработку версии MSDOS 1.25 для Z80 за 100.000 USD и право распространять MSDOS 2.0, 2.5, и 3.0 с моими аппаратными продуктами без лицензионного платежа.

    Для меня это был только процесс трансляции. Ранее я написал программу трансляции ассемблерных исходников на Z80 на ассемблер 8086 (TRANS). В этом случае я вручную переводил программу в обратном направлении. Поскольку MSDOS была сделана так, что была способна выполнять приложения CP/M, которые были транслированы в коды 8086, то это означало, что MSX-DOS будет способна выполнять оригинальные программы CP/M. Так, можно считать MSX-DOS версией MSDOS на Z80, но одновременно её можно считать вариантом CP/М, которая использует формат диска MSDOS.

    Я сидел за терминалом Zenith H19 связанным с 8086 компьютером от 'Seattle Computer Products' работающем в MSDOS с помощью двойного PerSci 8" НГМД. В качестве редактора я использовал MicroPro WordMaster из CP/M (а не более известный WordStar), причём я перенес его на MSDOS самостоятельно дизассемблированием 8-ми битовой версии CP/М и последующим переводом (with TRANS) на ассемблер 8086. Я смотрел на несколько строк исходного текста DOS на ассемблере 8086 и печатал соответствующие команды на Z80 ассемблере.

    Сначала я написал эмулятор Z80, который выполнялся под MSDOS, моделируя Z80 машину c CP/М. Этот эмулятор заработал уже через 10 дней, 27 августа 1983. Это позволило мне делать весь проект разработки под MSDOS. Я транслировал исходный текст на ассемблере Z80, используя CP/M-ассемблер M80 от Microsoft, выполняющийся под этим эмулятором, и затем компоновал REL-файл используя CP/M-компоновщик L80.

    MSX-DOS, который я писал, имел систему ввода/вывода, которая имела интерфейс непосредственно к процедурам ввода/вывода машины MSDOS, которая выполняла эмуляцию. Это давало прямой доступ из MSX-DOS к управлению дисковым форматом. Большинство основного кода было управлением файлами, так что это было необходимо отладить. Я делал резервную копии своей работы на втором диске 'PerSci', и стартовал код под эмулятором, давая тем самым MSX- DOS полное управление. Резевирование было необходимо, т.к, естественно, в ранних версиях, неожиданно возникали ошибки, приводящие к крушению диска.

    К 2-ому октября я добился, что БЕЙСИК Microsoft и M80, выполнялись под MSX-DOS. COMMAND.COM я закончил программировать несколько дней спустя. После тестирования, я устранил несколько багов и продемонстрировал работу MSX-DOS Полу Аллену 11 октября. Я официально поставил тестовую Beta-версию 26-ого октября. Это включало пасхальное яйцо, которое выводило на экран мое имя, но я не помню, как это активизировалось. Мое имя было закодировано кодом FAT, так что это не могло быть найдено, просто просмотром кода.

    После моей поставки код послали фирме 'ASCII' в Японию. Они создавали I/O System для MSX машины. Они должны были сообщить об ошибках, и я мог бы устранить их. В ходе этого однажды, в начале января 1984, я сделал ревизию ДОС, которая привела к крушению диска, когда я запустил код под эмулятором. К сожалению, я уже привык, что всё отлично работает и не сделал копии. Потребовался целый день труда, чтобы возвратить потерянные данные.

    Фирма 'ASCII' имела на проекте очень крутого японского программиста Джея Судзуки. Он обнаружил моё пасхальное яйцо и добавил своё имя к нему наряду с моим.

    В фирме ASCII возникли проблемы при изготовлении MSX-DOS, работающей на реальной MSX машине. Они не предоставили машину для меня, и вместо этого сделали так, что я вынужден был прибыть в Токио, чтобы помочь им. 28-ого января я уехал в Японию с Крисом Ларсоном, где мы встретились с Кей Ниши и его людьми. Оказалось, что они сильно изменили код, не сообщив мне, так что мы работали не над одинаковым исходным кодом. Я потратил три дня в Токио, чтобы выяснить проблемы (отчего осталось мало туристского времени). Я плохо работаю под давлением, так что я отказался делать любое кодирование там. В феврале я продолжил работу над MSX-DOS уже дома.

    Крис Ларсон и Джей Судзуки приезжали в мой офис в конце февраля и в начале марта. Они привезли MSX машину с внутрисхемным эмулятором для отладки. Мы запустили всё в работу, и я не слышал ничего более до апреля. Оставалось доделать очень немногое и затем 23 апреля 1984, фирма Microsoft приняла работу и сделала заключительную оплату.

    После этого я устранил ещё несколько ошибок, и это стало концом всякого контакта с проектом. После чего я вообще ничего не слышал больше о MSX. В выпуске версии MSX-DOS 2.0 с подкаталогами, я не участвовал.

    Я надеюсь, что это отвечает на ваши вопросы.
    [свернуть]
    Последний раз редактировалось barsik; 24.02.2017 в 18:59.

  11. #80
    Moderator
    Регистрация
    14.08.2006
    Адрес
    Владимир
    Сообщений
    4,577
    Спасибо Благодарностей отдано 
    61
    Спасибо Благодарностей получено 
    106
    Поблагодарили
    92 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    S2 это как раз те недостающие старшие биты для файлов размером более 512кб. Вот тут мы это обсуждали с народом:
    http://zx-pk.ru/threads/24285-orion-...la/page19.html
    если их правильно обрабатывать (ошибку в 2.2 я ранее упоминал), файлы более 512кб БДОС пишет и читает прекрасно.

Страница 8 из 24 ПерваяПервая ... 456789101112 ... ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. PMI-80 - одноплатник на i8080
    от rw6hrm в разделе Разное
    Ответов: 72
    Последнее: 02.09.2022, 12:27
  2. Самодельный комп на х386 и выше. Обсуждение
    от Ghost в разделе Разработка электроники
    Ответов: 26
    Последнее: 10.04.2019, 01:38
  3. Мнемоники i8080 vs Z80
    от Vladimir_S в разделе Разное
    Ответов: 153
    Последнее: 20.12.2016, 13:02
  4. Квадратный корень на i8080
    от shoorick в разделе Разное
    Ответов: 31
    Последнее: 25.08.2016, 14:04
  5. Эмулятор i8080
    от Higgins в разделе Разное
    Ответов: 2
    Последнее: 20.05.2011, 11:43

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •