Хотя да, покопался - на 8080 очень мало машин. https://en.wikipedia.org/wiki/Compucolor_II
Z80 быстрей дешевле и проще оказался.
Зато у нас как скопировали 8080 так десять лет не чесались, угу.
«Земля - слишком маленькая и хрупкая корзина, для того чтобы человечество держало в ней все свои яйца…» - Роберт Энсон Хайнлайн.
Электроника МК-61, Psion series 5mx.
Всем умеющим читать советую http://www.skeptik.net/conspir/moonhoax.htm http://lurkmore.to/Лунный_заговор
Ось безусловно должна быть. По прошествии лет мне кажется что, CP/M - наиболее логичный выбор.
На 8080 было много машин. Но это были громоздкие конструкции. Я же задался целью сделать на маленькой плате с шагом под ЛУТ и не большим количеством деталей. Чтобы дома можно было легко собрать. Плата 150х110 получилась.
Из того, что упоминается в Интернете, есть только общие описания, схемы и документация давно ушли в Реку Времен.
И еще у нас делали инвентаризацию склада, выкинули все микросхемы. Там было много от 580 комплекта, решил практически применить.
Ну и 8080 работает на 3,5МГц, так что тогда в 80-е годы Z80 не был быстрее. Это сейчас китайцы клепают Z80 на 20МГц.
То что проще -да. Условно. Всеравно в большой системе ему тоже придется шины буферизировать, а то здуется
- - - Добавлено - - -
Вытеснить, то вытеснил. Однако софта все же заработает большее количество!
Насчет компиляторов я сильно призадумался. Я юзаю MAC в связке c Wordstar. Доволен. На PC юзаю ASM8080 в связке с Win asm editor v2.2.
Раньше юзал TASM, перенастроенный на 8080/8085. Здесь ключевое слово "перенастроенный". Сейчас много ассемблеров развелось с поддержкой макросов.
Поэтому можно перенастроить на любой проц.
Real Hardware!
Чтобы иметь основание писать, что это чушь, надо привести работающую ссылку на скачивание исходника MSX-DOS. И что здесь чушь? И надо быть вежливее. Разве не лучше было бы написать "Извините, но мне кажется, что Вы неправы" и привести доказательства этого.Сообщение от Vadim
Уверен, что Вы никогда не видели, с какой скоростью CP/M работает с диском в 8 мб. И речь о CP/M. Сведения из личного опыта, не из книг.Сообщение от Vadim
В 1997 я купил б/у IDE-винчестер 42 Мб, специально чтобы поставить в ОРИОН. Но, т.к флопа 3.5" в формате 1640 Кб хватало, только в 1999 наконец собрался его подключить. Не было смысла ставить 16-ти разрядные регистры, - винты с ATA-интерфейсом допускают восьми разрядный обмен. Поэтому всё доп.железо - 1533 ЛА3, ИР22 на доп.платке и ИЕ7 в качестве регистра на основной плате ОРИОНА. Работа заняла лишь пару дней, т.к до этого я уже несколько раз решал ту же задачу (в 1989 для СПЕЦИАЛИСТА с КНГМД от КОРВЕТА и в 1994 для РК-КНГМД).
Скорость обмена с винчестером получилась примерно вдвое меньшей, чем на ВГ93 с DD-НГМД в формате 800К. Т.е в 4 раза меньше, чем в формате HD флоповода 3.5". Такая скорость получалась при дисках в 1 Мб и числе экстентов каталога до 256.
CP/M хранит список файлов всех юзеров в общем каталоге. При увеличении размера дисков и, соответственно, размера каталога и числа экстентов, скорость работы CP/M быстро падает. Если при дисководе и числе экстентов в 128, просмотр каталога отнимает 1-2 секунды, то при увеличении размера каталога в 16 раз, поиск в каталоге во столько же раз удлиняется. Учтите ещё вдвое меньшую скорость обмена.
Таким образом даже теоретически фактор торможения при поиске - 32. Не говоря уже о том, что CP/M использует оперативное построение "Allocation Table", в отличие от APPLE-DOS, где готовый VTOC просто читается с диска, или MSDOS, где FAT16 тоже в готовом виде читается с диска. По горячему старту и при копировании в НОРТОНЕ происходит построение "Allocation Table". Т.к НОРТОН рассчитан на сменяемые диски, то при каждой дисковой операции выполняется функция RESET, что вызывает торможение, - сначала для поиска файла в огромном каталоге, затем на построение Allocation Table для диска копирования и только затем выполняется копирование со скоростью вдвое медленнее, чем дисковод.
А учитывая, что сама CP/M врожденно тормозная, то работа с винтом в 8 Мб получается очень медленной.
Это чётко видно на дисководах. РК-ДОС на РК с реальным тактом в 1.3 МГЦ работает в 10 раз быстрее, чем CP/M на ОРИОНЕ с вдвое большим тактом и вдвое большей скоростью потока (MFM вместо FM). Это из-за того, что обмен в CP/M происходит логическими секторами по 128 байт, что вызывает много пересылок. Сначала физический сектор читается в дисковый буфер, а затем нужный 128-ми байтный блок пересылается на адрес DMA. А РК-ДОС работает физическими секторами и сразу читает физ.сектор в нужное место. Никаких лишних пересылок. Вот чем вызвана врождённая тормознутость CP/M.
Кстати, если программа глупая и, копирование делает не используя свой большой буфер (кратный размеру группы), а логическими блоками по 128 байт (считал-записал), то вообще получается кошмарная скорость - для каждого чтения и записи куска в 128 байт читается целый дисковый буфер. Т.к буфер стремятся сделать размером в группу, то получается 16/32 лишних считывания и записи при размере группы в 2/4 кб. Фирменных программ с такой глупостью нет, а вот любительские программы встречал.
По указанным причинам пришлось разбивать винт на партиции по 3-4 Мб. Но таблицы для дисков занимали очень много места. Решить эту проблему можно было только понижая уровень BDOS, т.е сокращая TPA, что делает саму ДОС бессмысленной. В одном BIOS уместить и дискетные п/п-ммы для ВГ93 и п/п-ммы для винта и таблицы для кучи дисков не получалось, не хватало ОЗУ. Поэтому пришлось сделать две версии ACP/M 1.63 и 1.64. В одной - только одна партиция винта и один флоповод. В другой - 12 партиций винта и эл.диск 120К из ОЗУ, но без флоповода. Опускать уровень BDOS ниже CC00 было нельзя, т.к все программы ОРИОНА сдуру привязаны к этой вершине TPA. Причём, мне не удалось даже использовать весь винчестер. И даже 12 партиций были доступны не одновременно, а спец.командой CCP выбирались, только 4 текущие партиции (одна общая для обмена). Так что винт размером более, чем 40 мб для CP/M не нужен.
Я много лет пользовался таким винчестером. Причём из-за тормознутости, только для хранения, не для использования. Когда в 2000 произошёл крах винта PC, то программы и исходники сохранились только на этом винте, отчего я потерял только половину архива.
Интересно, что ещё до винчестера, увидев насколько РК-ДОС быстрее CP/M, я написал в 1996 свою DOS, называемую TURBO-DOS (не знал, что имя уже занято в 80-х). В которой обмен не по 128 байт, а физическими секторами, что резко ускорило обмен. Также я написал вариант APPLE-DOS, не для 6502, а для Z80, но идеология была взята от APPLE. И здесь тоже обмен физическими секторами, отчего быстрее, чем CP/M.
Я тоже встречал такое утверждение в литературе. Но не вижу чем вызвано такое ограничение. При размере группы в 16 кб и двухбайтовой нумерации групп получается 16 кб * 65536 = 1000 мб. Просто при больших дисках таблицы займут всё ОЗУ 64К, а поиск в каталоге займёт вечность.Сообщение от Vadim
Нельзя так писать человеку, который Вам ничего не сделал и не писал ничего грубого. В форуме надо быть вежливым. Только больные люди, точнее психологические вампиры, стремятся обидеть, т.к получают от унижений людей кайф. Даже если кто-то заблуждается и написал в посте ерунду (кто не ошибался?), то не надо называть это бредом. Это нарушение правил форума. Гораздо лучше и выгоднее (всем) никого не обижать, а вежливо информировать в чём именно кто-то не прав, приведя неоспоримые доводы.Сообщение от Vadim
В CP/M не может быть TPA 58К, т.к сама CP/M занимает более 8 кб. А раз у Вас файловая система FAT16, то это даже, как минимум, не полностью совместимо с CP/M. Тем самым, Вы просто подтвердили то, что я написал. Что быстрой может быть только ДОС не использующая структуру диска CP/M, имеющая не один гигантский каталог в 200 кб, а множество мелких каталогов.
Это ясно из названия: "Z80 Command Processor Replacement". Поэтому я и написал - "ZCPR3 это модификация CP/M на Z80, дающая подкаталоги и командный процессор, как в MSDOS." Заменой CCP это было лишь в первой версии, а последние размещают большой кусок кода выше BIOS, потому изменяют и модули BDOS и BIOS. Кроме того заменяются и утилиты (SUBMIT и т.п). Исходник ZCPR - 2 мб, а исходник всей CP/M - лишь 150 кб. Да и документации на порядок больше. О ZCPR я узнал 27 лет назад из журнала "Компьютер за Вас" 7.1990 страница 26. Кстати, есть версия ZCPR2 для КР580 и CP/M 2.2, хотя из 100 утилит ZCPR, для КР580 адаптированы лишь десяток основных.Сообщение от Vadim
Последний раз редактировалось barsik; 11.02.2017 в 21:42.
Apple-DOS 3.3 по сути не ДОС, а расширение резидентного бейсика. Программый интерфейс там на уровне командных строк, а не подпрограмм. Я и не собирался адаптировать программный интерфейс, т.е функции, даже если бы они были. Ведь использовать ПО для 6502 всё-равно бы не смог.Сообщение от Шынни
Целью было - повторить идеологию организации диска. Т.е сектор VTOC, отражающий занятость секторов, каталог в виде связанного списка секторов и T/S LIST для каждого файла. Естественно, формат каталоговой записи изменил (зачем мне ограничение диска в 124 кб и максимум 105 файлов). Организация трековой записи во VTOC тоже иная, рассчитанная на РК-КНГМД. Размер сектора не 256, а 512 байт, что дало максимум 1280 кб на диск.
Главная задача была получить быструю ДОС, т.е с обменом физическими секторами, а не логическими, и чтобы дохлота секторов не особо вредила (в CP/M если дохлота на месте каталога или сектора с БПД - выкидывай диск). Я использовал эту ДОС с РК-КНГМД в формате 880 кб на диск 3.5" (11 секторов на трек). В начале 21 века дискеты стали дохнуть (т.к были куплены в самом начале 90-х) и большую часть дискет пришлось перевести на формат 7 секторов на трек, 560 кб на диск, который использовался для DD-дисков на НГМД 5.25". Интересно, что самые "породистые" диски с пожизненной гарантией сдохли первыми, а дешевые беспородные тайваньские служат спустя 25 лет.
ДОС работает на ОРИОНЕ в банке 0. Для всех ДОС есть цветные оконные НОРТОНЫ, программы LORD, отладчик DDT (КР580), текстовый редактор (аналог турбопаскалевского) и два макроассемблера (увы, мнемоника КР580). К сожалению, данная ДОС рассчитана на дисковод. Идеология Apple-DOS не годится для винчестера, т.к во VTOC на каждый сектор выделен бит, а не 1 бит на целую группу в 16 кб. Это позволяет более экономно тратить диск, чем в CP/M, но не годится для больших дисков.
Когда поставил винт, стал думать о формате PRODOS, но там всё намного сложнее. Главное не кодирование, а придумать саму идею грамотного и удобного формата диска. Написал ещё одну ДОС, в которой в каталоге хранились не только записи о файлах, но и записи о свободных местах (тем самым я избавился от VTOC или Allocation Table). Но и в этой ДОС тоже общий каталог, а не много маленьких. В общем, нужна грамотная идея организации диска для приводов большого размера.
Функции BDOS и команды CCP
Код:fboot EQU 0 fconin equ 1 fcout EQU 2 fdirect EQU 6 fmssgc EQU 9 frdstr EQU 10 fstatus EQU 11 fvers EQU 12 freset EQU 13 fseldsk EQU 14 fopen EQU 15 ; Вход: (ENTADR)=FCB, (ENTBYT)= 1...4 (Read/Write/Append/OverWr) fclose EQU 16 ffind EQU 17 ferase EQU 19 fsread EQU 20 ; последовательное чтение сектора (TRACK,SECTOR) fswrite EQU 21 ; последовательная запись сектора (TRACK,SECTOR) fcreate EQU 22 frenam EQU 23 ;factive EQU 24 ; выдать вектор действующих дисков faskdsk EQU 25 fsetdma EQU 26 ;falloc EQU 27 ; get VTOC TABLE fsetatr EQU 30 ; задать атрибут файла ;fgetdpb EQU 31 ; get DPB fuser EQU 32 fovwrit EQU 34 ; Прямая перезапись любого сектора файла fsize EQU 35 ; Возвращает размер файла, HL= байтов fsetns EQU 36 ; Позиционирует на нужный сектор файла fkill EQU 38 ; Удаление без освобождения занятых секторов, сектор T/S LIST освобождается, если он читается fervec EQU 39 ; вход: DE= blok of ADDR. Установить свои вектора ошибок BDOS frstvec EQU 40 ; Восстановить стандартные вектора ошибок BDOS fgetdir EQU 41 ; считать каталог диска fopros EQU 42 ; опрос клавиатуры ffrfcb EQU 43 ; формат FCB из ASCII-строки. DE-адрес FCB, HL-source line fload EQU 44 ; загрузить файл целиком fsave EQU 45 ; записать целый файл fgetlin EQU 46 ; ввод строки символов с редактированием и тимплетом (курс.вверх) ffree EQU 47 ; Выход: HL= число своб. секторов на диске fsetadr EQU 48 ; установить адрес загрузки файла fgetatr EQU 49 ; получить адрес загрузки файла fdecsz EQU 50 ; Сократить размер файла на 1 сектор for_rd EQU 1 ; файл открывается для чтения for_wr EQU 2 ; --"-- для записи for_ap EQU 3 ; --"-- для дополнения for_ov EQU 4 ; --"-- для перезаписи секторов Вот что исполняется по нажатию <F1> в CCP XHELP: RST 18H defb 'SAVE/SAVE$ NAME Н.АДР К.АДР',13,10 defb 'LOAD/LOAD$ NAME [АДР]',13,10 defb 'TYPE/TYPE$ NAME',13,10 defb 'COPY/COPY$ NAME d:',13,10 defb 'REN/REN$ SOURCE TARGET',13,10 defb 'DEL/DEL$ NAME',13,10 defb 'DIR/DIR$ [d:]',13,10 defb 'ATTR NAME HEX',13,10 defb 'CLS',13,10 if FULL defb 'GET [d:] ТРЕК СЕКТ [N СЕКТ]',13,10 defb 'MOV ОТКУДА КУДА СКОЛЬКО',13,10 defb 'FILL Н.АДР К.АДР БАЙТ',13,10 defb 'KS Н.АДР К.АДР',13,10 defb 'TEST d:',13,10 defb 'INIT [d:]',13,10 defb 'MAP [d:]',13,10 endif defb 0 RST 38H[свернуть]
Как видите, где возможно, все функции совмещены с CP/M, так что адаптация программ при наличии исходника занимает полчаса. Размер файла с точностью до байта, есть дата и время файла. У файлов есть адреса загрузки. Считывание каталога. Есть запись-чтение файлов целиком (естественно, если размер менее TPA). Встроенный цветной оконный драйвер. Встроенный эл.диск из ОЗУ. CCP работает как с дисками DOS, так и с квазидисками ORDOS.
Последний раз редактировалось barsik; 10.02.2017 в 18:02.
barsik, у ФАТа тоже есть свои костыли. вы забыли, на секундочку, при стандартном форматировании диска, скажем, на пару гигов в фат16, корень диска уже позволяет держать 512 файлов. в каждом каталоге их так же может быть много.
тут суть в том, что у цпм из-за мелкого размера диска, много файлов туда не записать. у вадима и у меня были профики (у Вадима и сейчас есть), а профик это цпм машина. У меня, к примеру, было 3 версии цпм для профи - старая древняя микродос (отечественный аналог цпм в представлении Кондора), их же следующая версия concurrent bios версии 4 и не помню чья версия 5.30 с расширением для работы с винтов. и винт я тоже цеплял, гигабайтный и создавал там сразу 4 раздела по 4 - 8мб (точно сейчас не вспомню).
интересно, от куда вы взяли, что у цпм были организации секторов в группы (кластера?). если я верно помню, то у цпм в классическом виде сектор был 128 байт и только позднее каждый производитель наделал свои стандарты этой фс, по которым сектор мог быть увеличен до 1кб. На профи именно этот вариант использовался. диск двойной плотности на 160 треков, по 5 секторов на трек. сектор 1024 байта. корень диска это список юзеров от 0 до 15. юзер по умолчанию для чтения и записи, как я помню был 0, а юзер 15 как правило использовали под всякий системный хлам типа драйверов. при всём желании вы туда 512 файлов не запишите. чтение каталога мало чем отличается от чтения каталога для фат.
Опять таки, у Вадима была своя версия доса изначально полностью совместимая с цпм, но с фатом в качестве фс. ЦПМ софт не умеет работать с каталогами, каждый каталог для цпм софта выставлялся как текущий, грубо говоря, юзер. это сильно накладывало ограничения на работу с софтом, но зато было проще хранить, т.к. был винт и фат16.
тпа в 58кб это реальность. просто большая часть ядра системы спрятана где-то в страницах, а видимая часть это типа диспетчер апи. а если посмотреть на спринтера, то там "тпа" в 4 метра)))) если в цпм размер ком файла ограничен размером тпа, то у доса на спринтере нет такого ограничения, ехе файл может быть хоть 100мб. не забываем про эмуляторы цпм. там тпа под 60кб.
Касательно msx-dos, тут действительно, вы немного не правы. во1х, есть исходники. во2х, есть куча документации по этой дос и есть весьма не маленькое комьюнити на msx.org. сама мсх-дос явно писалась под впечатлением от мс-доса и она сильно на неё похожа по некоторым логическим моментам. при этом, мсх-дос так же является цпм совместимой системой.
опять-таки не ясна ваша формулировка
что за маленькие каталоги? почему они маленькие? скажем 256 или 512 файлов на каталог это много или мало? или они маленькие по объёму в байтах? так каталог не регулируется таким методом.в MSX-DOS разбит на много маленьких каталогов
почитайте про файловые системы фат, многое вам станет понятно, благо мануалов в инете много.
и ещё про Орион - тут вам сразу дорога к Error404. я уже давно понял, что на Орионе есть штук 5 разных досов и все они цпм подобные, есть даже с прикруткой фата.
Последний раз редактировалось Sayman; 10.02.2017 в 18:40.
пожалуй самая быстрая реализация на реальном железе cpm из самоделок и да- Z80 образном.
http://noplabs.com/cpm50/cpm50.html
Ты слыхал как грузится Flyshark ?! нет, совсем не тот, что на дискете...а Flyshark, тот самый блин Flyshark...тот ,что был когда то на кассете...
zx spectrum 48 issuse 6a, Ленинград-1, zx spectum 128 +2 grey,Пентагон-128, ZXM-Phoenix 5.02 ( assembly)
Часто встречаю это утверждение. Думаю, просто какая-то неудачная реализация в прошлом установила блок на повторное осмысление, надо еще раз попробовать. CP/M 2.2 нормально работает с файловыми системами любого размера в пределах ее математической модели. Конечно, для использования бОльших емкостей приходится размер кластера увеличивать с 2кб (какой он на дисководных распространенных реализациях) до максимальных 16кб. Я не замечал замедления версии дисков с большим кластером которые мы используем для HDD по сравнению с "дисководным" форматированием (BDOS оба раза одинаковый).
Максимальный размер диска для CP/M 2.2 ЕМНИП - 1 гигабайт, а максимальный размер файла - 4Mб. Конечно для 1Гб все ТПА надо отдать под буфер ALV. Но для к примеру 100Мб диска (а это весьма прилично для 8-битки, тот же UZIX имеет предел в 32Мб на одну ФС), надо всего лишь 800 байт для буфера ALV (всего на семь сотен байт больше чем для дисковода) - вполне разумные траты. Учитывая, что ФС можно отмонтировать и менять на другую (как дискетку заменить), все выглядит очень удобно.
- - - Добавлено - - -
И файлов туда можно записать весьма много. Считать лень, но даже на один 16кб-шный кластер пишется 512 файловых дескрипторов (файлы до 128кб размером умещаются в один дескриптор), а кластеров под каталог можно отвести до 16 штук - умножьте сами. Но конечно когда диск большой (что достижимо). Для маленьких (и не очень) носителей очень часто употреблялись библиотеки LBR как подкаталоги (если не хватало штатных Юзеров) - это давало уплотнение и позволяло писать на небольшой диск большее количество файлов чем есть есть файловых дескрипторов. Многие пробвинутые CCP от CPM 3.х работали c LBR как с каталогами (по крайней мере на чтение).
Другое дело, что надо наверное брать продвинутые реализации CP/M - c датами файлов и т.п., такие тоже были (даже в исходниках встречал).
Последний раз редактировалось Error404; 10.02.2017 в 20:48.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)