Просмотр полной версии : Орион-ПРО. Софтверные дела
Всем привет!
У кого-нить имеется следующий софт ?
* Исходники ROM-BIOS V2.10 для Орион-Про (ROM1 и ROM2)
* Исходники редактора SURED V3.0, пакета IBM-disk V2.2
* Исходники редактора Corona V2.20
* Исходники TASM V4.10 (под ORDOS)
* Пакет IBM-disk V2.2 (типа проги "MSDOS" от "Lucksian Key")
* ORDOS 6.1 beta (автор В.Михаловский)
Error404
20.11.2014, 00:07
Можно поинтересоваться, зачем исходники?
Можно поинтересоваться, зачем исходники?
Нет, это у меня есть данные пакеты (имиджи дискет в формате teledisk). Хотел узнать, есть ли у кого-нить еще интерес ко всему этому или нет. Если надо, то могу выложить на яндекс.диск и кинуть сюда ссылку.
Интерес есть, выкладывайте :)
Error404
20.11.2014, 09:52
Нет, это у меня есть данные пакеты (имиджи дискет в формате teledisk). Хотел узнать, есть ли у кого-нить еще интерес ко всему этому или нет. Если надо, то могу выложить на яндекс.диск и кинуть сюда ссылку.
Конечно выкладывайте, нам пригодится, в особенности это:
"Исходники ROM-BIOS V2.10 для Орион-Про (ROM1 и ROM2)"
Конечно выкладывайте, нам пригодится, в особенности это:
"Исходники ROM-BIOS V2.10 для Орион-Про (ROM1 и ROM2)"
Нивапрос. В ближайшее время брошу сюда сцылку. Просто в какой-то мессаге попалось (по теме константы задержки для клавы), что надо реинженерить монитор, вот и подумалось, что видимо у народа некоторый напряг с сорцами.
Error404
20.11.2014, 13:03
Нивапрос. В ближайшее время брошу сюда сцылку. Просто в какой-то мессаге попалось (по теме константы задержки для клавы), что надо реинженерить монитор, вот и подумалось, что видимо у народа некоторый напряг с сорцами.
Что есть, то есть. В наших деревнях в 90-х ПО доставалось с большим геморроем и за большие деньги (собственно на "деревенских" пользователях и зарабатывали столичные кооперативы, торговавшие ПО), а сырцы нам вообще никогда не перепадали - только дизасм, только хардкор. :)
Что есть, то есть. В наших деревнях в 90-х ПО доставалось с большим геморроем и за большие деньги (собственно на "деревенских" пользователях и зарабатывали столичные кооперативы, торговавшие ПО), а сырцы нам вообще никогда не перепадали - только дизасм, только хардкор. :)
Выложил архив на яндекс.диск. Что-то уже есть у народа (или сами выписывали когда-то в стародавние времена или с CD-компакта Романа Чунина).
ссылка на архив:
https://yadi.sk/d/9ob2f5_KcqQo9
АлександрПП
14.02.2015, 14:39
У кого-нибудь есть образ системного диска ORDOS-6 для "Орион"?
И вообще все, что касается ORDOS-6.
Error404
14.02.2015, 17:48
У кого-нибудь есть образ системного диска ORDOS-6 для "Орион"?
И вообще все, что касается ORDOS-6.
Это ж Ордос, там не системный диск, там системная кассета должна быть. :)
А если серьезно, ничего не слышал про ORDOS-6, об чем оно хоть было?
АлександрПП
14.02.2015, 23:39
Точнее будет сказать, загрузочный диск. О кассете не может быть речи. Ведь в "Орион-Про" о магнитофоне и не заикались.
А если без юмора, то прикладываю образ диска.
Выдернул с него текстовые файлы.
Но образ не полный. Нет главного - ORDOS.SYS.
Дмитрий2012
04.12.2015, 22:16
Просматривая архивы софта для Ориона, обнаружил интересную программку “Video-Tools” для просмотра графических файлов с расширением .TV и .BMP
Кто-нибудь знает, существовала ли полная версия (не beta) этой программы? Может кому встречалась информация по ней?
АлександрПП
04.12.2015, 23:27
Не встречалась
Error404
05.12.2015, 00:20
от Luсksian Key вообще мало что осталось на носителях. Как-то они унесли все свои разработки с собой.
А ведь была весьма многообещающая группа любителей
Небольшой тест быстродействия Ориона-Про. В архиве таблица с результатами, исходник и com (com и исходник соответствуют варианту, обозначенному в таблице vstvi102). Используется ВИ53 на дополнительной плате COM-портов/AY. Подробные тесты на реале провел Дмитрий2012, за что ему большое спасибо! Можно воспринимать этот вариант теста как бета-версию, т.к. это QnD переделка векторовского теста и здесь нет уникальных команд z80. Но это не мешает примерно оценить реальное быстродействие про с доработкой Воронова. Для лучшего соответствия реалу в emu стоит уменьшить частоту "турбы" примерно до 6.5 МГц
Error404
06.12.2015, 11:30
Используется ВИ53 на дополнительной плате COM-портов/AY.
Экзотика, однако.
АлександрПП
14.12.2015, 17:13
Уважаемый Vasil!
Обращался в личку, но ответа так и не получил.
Если появляетесь на форме, ответьте, пожалуйста. Есть у меня пара вопросов, которые хотелось бы обсудить.
> Меня очень интересует образ диска ORDOS6.td0. Как он был получен, когда и от кого.
Был получен от Пушкова, когда он был доступен, т.е. давно (дата файла td0-образа 2001 год). Присланная мне
ридмишка:
---------------------------------------------------------------------------------------------------------------------------------
Высылаю пакет ORDOS V6.10, который, к сожалению еще очень сырой.
Все замечания просьба указывать непосредственно В.Михаловскому для
ускорения работы.
================================================== ===
Адрес В.Михаловского имеется в файле ORDOS.TXT на диске. Hа всякий случай
сообщаю: 214000, Смоленск, г/п а/я 228.
================================================== ===
---------------------------------------------------------------------------------------------------------------------------------
Никакой другой инфы (и файлов) у меня нет.
АлександрПП
14.12.2015, 19:38
А попытки запустить ORDOS-6 были? Он работал?
Black Cat / Era CG
15.12.2015, 13:45
Граждане Орионове(о)ды, простите за глупый вопрос.
Посмотрел тоже образ с Ordos-6 и вот интересно, а что за такие файлы .BRU? Насколько я понял там какой-то заголовок с именем оригинального файла и еще чем-то, а затем содержимое этого оригинального файла? Что-то типа контейнера?
Vladimir_S
15.12.2015, 14:20
Что-то типа контейнера?
Ну в общем то да. Файлы в формате ОРДОС с помощью специальных программ можно хранить на дискетах.
АлександрПП
15.12.2015, 14:26
Формат переноса на диск и обратно. Формируется программой ATLAS$.
Black Cat / Era CG
15.12.2015, 16:04
Ну так и думал. А есть где-то подробности по формату, что там внутри кроме имени файла?
АлександрПП
15.12.2015, 16:21
Если вопрос касается ORDOS-6, то нет ничего, кроме того, что есть на этом диске. На этом же диске и файлы описания.
Black Cat / Era CG
15.12.2015, 18:10
Если вопрос касается ORDOS-6, то нет ничего, кроме того, что есть на этом диске. На этом же диске и файлы описания.
Нет. Мне интересно, что хранится между именем файла и его содержимым в файлах .BRU вообще.
> А попытки запустить ORDOS-6 были? Он работал?
Нет, попыток запустить не было. С тех пор я не занимаюсь орионом.
АлександрПП
15.12.2015, 18:32
Но Михаловсикй и Пушков, видимо, его запускали.
Иначе зачем бы они его пересылали для ознакомления и доработок.
Ну, ладно. Восстановил все исходники. Будем копаться дальше.
Нет. Мне интересно, что хранится между именем файла и его содержимым в файлах .BRU вообще.
Восемь байт - имя файла. Два байта - адрес посадки в ОЗУ. Два байта - длина в байтах, только сам кодовый блок, без заголовка. Еще четыре байта - от балды, нули или как хочешь.
Black Cat / Era CG
15.12.2015, 21:48
Спасибо. Это и надо было мне:)
HardWareMan
16.12.2015, 06:03
Восемь байт - имя файла. Два байта - адрес посадки в ОЗУ. Два байта - длина в байтах, только сам кодовый блок, без заголовка. Еще четыре байта - от балды, нули или как хочешь.
Что, даже контрольки нет?
Что, даже контрольки нет?
Существование контрольки в природе не замечено.
Я уже много файлов перелопатил, народные умельцы выдирали их из памяти кто как горазд.
Вопрос о сумме не возникал ни разу, хоть это и странно. В четырех оставшихся байтах обычно стоят просто нули.
АлександрПП
16.12.2015, 11:22
Была такая ORDOS-5. Вот в ней предусматривалась контрольная сумма. Заносилась она в ячейки 0DH, 0EH.
При считывании контрольная сумма проверялась, если была ошибка, то выводилось соответствующее сообщение.
При считывании контрольная сумма проверялась...
Скорость записи/чтения файла при этом уменьшилась наверное на порядок... ((
Error404
16.12.2015, 12:28
Скорость записи/чтения файла при этом уменьшилась наверное на порядок... ((
Больше. Представьте, что надо поменять два байта в середине большого файла. Получается, ОС должна пересчитать КС? А если еще надо поменять, и еще? Смысл теряется. Тогда, получается нужно вводить блочное хранение и КС для каждого блока, а если уж делать блочное хранение (и файл как цепочку блоков), то и файловую систему нормальную: допускающую фрагментирование файла и в ОС нормальные функции, а не урезанные как в Ордос. Т.е. за ниточку потянешь, и вот Ордос вся распустилась, как вязаная варежка. Хоть пятой хоть десятой версии. Ордос имеет смысл только как она есть в версии 4, в чем меньше, тем лучше объеме ПЗУ. А для реальных пацанов были и нормальные реализации ОС в ПЗУ для Ориона - да хоть та же питерская RamDOS от Казимирчака ЕМНИП 1991 года выпуска, с нормальной организацией эл. диска, т.е. не кучкой обособленных дисков по 60к.
АлександрПП
16.12.2015, 13:00
Ордос имеет смысл только как она есть в версии 4
Ну так ORDOS-5 так и осталась только в журнальной версии.
А что касается проверки контрольной суммы. то это относится только к файлам, размещенным в ПЗУ ROM-диска.
А что касается проверки контрольной суммы. то это относится только к файлам, размещенным в ПЗУ ROM-диска.
В ПЗУ как раз меньше всего нужда в проверке к/с, т.к. это R/O-память, там ничего попортиться не может в принципе, а проверка целостности данных делается один раз - на этапе прошивки программатором.
Таковая проверка актуальнее всего для ГМД, где теоретически данные могут портиться. Хотя лично я ни разу не сталкивался с некорректным чтением сектора на ГМД. Сектор либо не читается вообще (такое бывает), либо читается и там всегда то, что нужно.
АлександрПП
16.12.2015, 20:14
Нет, я не прав. Посмотрел описание, проверяются файлы на всех квазидисках. О дисководе речи нет.
Надо попробовать в действии, ради любопытства.
А попытки запустить ORDOS-6 были? Он работал?
Но Михаловсикй и Пушков, видимо, его запускали.
Иначе зачем бы они его пересылали для ознакомления и доработок.
Ну, ладно. Восстановил все исходники. Будем копаться дальше.
Тоже решил покопаться. Вариант для Орион-128 похоже не рабочий (из 7-мой страницы обращается к F836, а та на выходе включает нулевую страницу). А вот вариант для Орион-Про запустился, но там тоже есть свои тараканы. Проще всего залить на ROM-диск файл ORD6$.BRU, однако там по умолчанию выбран винчестер, конфигурационные файлы соответственно не грузятся, но ДОС всё-же пытается выполнить их из того места в памяти, куда они должны были грузиться (после того как выбран диск A - ROM-диск). В результате ничего хорошего не происходит, т.к. конец файла должен быть отмечен точкой с новой строки (т.е. байты 0D 2E), а такое сочетание маловероятно в неинициализированной памяти. В исходниках версии для Орион-128 есть обработка этой ошибки, там в самое начало этого буфера точка записывается.
Но есть возможность обойти загрузку конфигурационных файлов, надо просто держать нажатой какую-нибудь клавишу (благо после запуска ДОС она долго пытается загрузить сектор с винчестера). В исходниках можно найти распределение дисков по умолчанию:
A - ROM диск
B,C,D,G - квазидиски страниц 1,2,3,6
E,F - винчестер
H,I - дисковод
Мой эмулятор опознаёт файлы размером ровно 720Кб как образ диска с 9-ю секторами по 512 байт, таким образом можно взять образ диска формата FAT12 данного размера (задав расширение .odi или добавив его расширение в конфиг), и тогда этот диск будет доступен как H или I. Туда можно записать SG610.COM (хотя я грузил его в эмуляторе прямо в память в отладчике). После запуска SG610 спросит, на какой диск записывать ORDOS.SYS, нужно указать например Н, после чего этот диск будет загрузочным. Орион-Про с него прекрасно грузится. Можно и из режима Орион-128 загрузиться, если закинуть на ROM-диск файл BOOT4$.BRU.
Что касается версии для Орион-128, её видимо тестировали на Орион-Про с другим биосом (тем же, что и для Орион-Про), в котором п/п F836 не переключает страницу, а использует дополнительные возможности Орион-Про (16Кб окно).
Исходники на диске не все, нет утилит и версии SG610 для Орион-Про. Файлы с подчёркиванием - для Орион-128, с апострофом - для Орион-Про (или для обеих версий?).
- - - Добавлено - - -
Кстати, в этой версии ORDOS в заголовке .BRU по смещению 0Dh хранится дата, формат такой
struct Date {
unsigned day:5;
unsigned month:4;
unsigned year:7; // from 1980
}
АлександрПП
17.12.2015, 13:24
Исходники на диске не все, нет утилит и версии SG610 для Орион-Про.
Версия sg610 для ПРО у меня есть. А откуда взялся диск с исходниками? Я их нашел на диске ORDOS6.ODI, восстановив программой unerase$.
Через час вернусь домой выложу найденное.
Версия sg610 для ПРО у меня есть.
Имеется ввиду бинарник или исходник? Бинарник на диске есть.
А откуда взялся диск с исходниками? Я их нашел на диске ORDOS6.ODI, восстановив программой unerase$.
Ну и я примерно так-же сделал, разве что ручками в hex-редакторе.
АлександрПП
17.12.2015, 15:37
А что происходит при запуске sg610?
А что происходит при запуске sg610?
Генерируется система, т.е. записывается загрузочный сектор и ORDOS.SYS на выбранный диск.
А эти исходники с другого диска? Вроде как SG610'AS.BRU на диске, который на второй странице этой темы, точно нету.
- - - Добавлено - - -
На диске с исходниками кое-какие файлы зря восстановлены, содержимое левое:
clok_as.bru
date.com
date_as.com
format.com
ord6$.bru
pismo7.txt
time.com
time_as.com
- - - Добавлено - - -
Утилиты format.com, clok.com, date.com, time.com лучше брать с того другого диска, тем более, что они разные для Орион-128 и Орион-Про (лежат в разных пользователях, user 1 Орион-128, user 2 Орион-Про).
АлександрПП
17.12.2015, 16:26
Да, это разные диски. Один тот, что выложил vasil. Второй с CD от chrv. Они практически идентичны, но вот отличия в паре файлов.
Генерируется система
Странно, у меня это не идет. После выбора дисковода пишет "ошибка чтения".
Можно выложить sg610, которая запускается?
А ты sg610 из ОРДОС-6 запускаешь? Без ОРДОСа он работать не будет.
Я брал с того, первого диска, из user 2.
АлександрПП
17.12.2015, 17:23
Ага, ясно. То есть он создает загрузочный диск, уже находясь в системе ORDOS-6.
Значит задача зайти в нее.
А если создать загрузочный диск и выложить его образ?
А если создать загрузочный диск и выложить его образ?
Что значит "если"? :)
Я создал тестовый диск, записал на него sg610.com, однако он не грузился. Выяснилось, что этот ОРДОС-6 использует некоторые байты записи в каталоге не по назначению. Сперва выяснилось, что нужно задать адрес посадки. Но это можно сделать командой из самого ОРДОС-6. Потом выяснилось, что грузится неправильное количество байт, несмотря на указанный размер. Оказывается, если файл дефрагментирован, можно задать количество загружаемых кластеров, и тогда обращение к FAT вообще не будет. Это, кстати, используется для ORDOS.SYS. К сожалению, этот байтик опять попал на время создания файла. И обнулить его можно лишь подредактировав образ диска в hex-редакторе. Таким образом, записывать файлы сторонними программами на образ нельзя (кроме тех, которые пишут нулевое время создания файла).
Кроме того, почему-то нельзя генерировать систему на втором дисководе, с него потом не грузится. Единственное отличие в файле ORDOS.SYS пара байт, судя по всему имя текущего/системного диска.
- - - Добавлено - - -
Да, это разные диски. Один тот, что выложил vasil. Второй с CD от chrv.
Порылся в архивах, нашёл тот диск :)
Действительно, разница лишь в том, что после удаления исходников кто-то записал ещё одну копию SG610.COM, поэтому три файла исходников перезаписались/потерялись.
АлександрПП
17.12.2015, 19:32
Что-то не то с образом диска. Плагином не открывается. На реале начинается загрузка - ORDOS IS STARTING и потом - DISK LOAD ERROR.
На эмуляторе error404 не запускается.
А вот на твоем эмуляторе все идет превосходно.
Да и размер файла. Обычно он 800 Кб, а у тебя 720 Кб. Чем делал?
Что-то не то с образом диска. Плагином не открывается.
Не тот плагин :) Можно переименовать в *.img и открыть как обычный диск формата FAT12.
На реале начинается загрузка - ORDOS IS STARTING и потом - DISK LOAD ERROR.
Реал это Орион-Про? А диск точно был отформатирован на 9 секторов по 512 байт?
На эмуляторе error404 не запускается.
Он видимо считает диск обычным, 5 секторов по 1024 байт.
А вот на твоем эмуляторе все идет превосходно.
Я же писал, мой эмулятор опознаёт файлы размером ровно 720Кб как образ диска 9 секторов по 512 байт.
Да и размер файла. Обычно он 800 Кб, а у тебя 720 Кб. Чем делал?
Взял обычный пустой образ MSDOS диска.
Error404
17.12.2015, 19:55
Жесть какая.
Портировали бы уж тогда MSX-DOS, раз так сильно хотелось 720кб на дискете вместо 800кб. Тогда хоть BDOS/BIOS был бы нормальный, а не деревенский. А на винчестере у них что?
АлександрПП
17.12.2015, 19:58
А диск точно был отформатирован на 9 секторов по 512 байт?
А вот это я не внимательно читал.:)
раз так сильно хотелось 720кб
Хотелось видимо, чтобы все ордосовские программы стали работать также и с дисководом, и с винчестером.
А на винчестере у них что?
Я пока не копал, но подозреваю, что всё тот-же FAT.
АлександрПП
18.12.2015, 08:22
FAT. И во всех описаниях через строку о совместимости с MSDOS по формату записи.
Error404
18.12.2015, 12:25
Хотелось видимо, чтобы все ордосовские программы стали работать также и с дисководом, и с винчестером.
Но ведь это не возможно (не говоря уже об том что программ интересных просто не было). Половина (если не болше) Ордосовских программ лазила в RAM-диски напрямую, т.к. они были написаны во времена Ордос 2.4 (в поздние времена программ писалось очень мало, все они - ранние) в которой тупо не было нормального файлового BDOS и не поддерживалось все ОЗУ. Я как-то уже в современности какую-ту свою CP/M прогу пытался адаптировать к Ордос. Уж не помню во что я уперся (то ли записывался там файл только целым куском, то ли читался целым куском, то ли какие-то дикие привязки к "адресам посадки"), но писать через процедуры Ордос в стиле нормального человека было весьма затруднительно. Плюнул. Как говорится, "невермор".
В-общем, как обычно делали очередную запускалку игр. Как и в CP/M "видели" только файловый носитель для BRU-шной помойки.
Половина (если не болше) Ордосовских программ лазила в RAM-диски напрямую, т.к. они были написаны во времена Ордос 2.4
Ну, видимо, раз уж Михаловский стал дальше развивать Ордос, то наверное собирался и другие программы доделать. И вряд ли он во что-нибудь упёрся бы :) Правда, после 2000 года публикаций в прессе про Орион уже не стало, вот всё и заглохло. Я так думаю.
какие-то дикие привязки к "адресам посадки"
Это да - крутейшая "фича" Ордоса :)
АлександрПП
18.12.2015, 23:40
Что-то не совсем то!
Образ диска test6.odi записан на дискету и с него создан образ диска HFE для эмулятора НГМД.
У двоих владельцев "железных" "Орион-ПРО" картина одна и та же при загрузке что с реальной дискеты, что с образа HFE.
Чтобы долго не рассказывать прилагаю ссылку на видеоролики. Там загрузка с дискеты в двух вариантах. Напрямую из меню-Орион-про и через ORD4$. Похоже, что система переносится не совсем туда.
https://yadi.sk/d/5Z0lew8jmKwHE
На эмуляторе все идет прекрасно. Видимо, он не совсем точно эмулирует "Орион-ПРО".
На эмуляторе все идет прекрасно. Видимо, он не совсем точно эмулирует "Орион-ПРО".
Может и не совсем точно, но я же запускаю именно те файлы, что работали у Михаловского! Работало у него - работает и в эмуляторе. Может всё-таки диск битый? Сравни записанный образ и считанный с этого диска.
АлександрПП
19.12.2015, 00:32
Может всё-таки диск битый?
Возможно. Но у двоих? Мы же делали диски независимо друг от друга из выложенного образа. Может выложен подпорченный?
Хотя в эмуляторе то он работает.
Хренотень какая-то.
Завтра еще у Дмитрия переспрошу, сегодня он уже в состоянии покоя.
- - - Добавлено - - -
Сравни записанный образ и считанный с этого диска
Попробую.
Возможно. Но у двоих?
Я думал, что образ для эмулятора НГМД делался с одного и того-же диска.
АлександрПП
19.12.2015, 12:47
Если иметь ввиду образ диска то да, с одного, скачанного с форума. Но Дмитрий2012 делал образ диска в hfe формате. Я и в нем и в нормальной дискете.
У меня пока только одно предположение: процедура чтения сектора с диска работает в эмуляторе и работала у Михаловского, но как-то неправильно работает у вас. Возможно, есть какие-то особенности реализации контроллера НГМД.
- - - Добавлено - - -
Имеется ввиду её реализация Михаловским.
АлександрПП
19.12.2015, 13:31
как-то неправильно работает у вас.
Это самое верное. Что-то я делаю не так.
А как Вы делаете дискету из образа?
Error404
19.12.2015, 15:15
Что-то не совсем то!
Образ диска test6.odi записан на дискету и с него создан образ диска HFE для эмулятора НГМД.
Чем записывали ODI на дискету?
- - - Добавлено - - -
Это самое верное. Что-то я делаю не так.
А как Вы делаете дискету из образа?
Он не делает дискет из образов. :)
АлександрПП
19.12.2015, 16:03
Чем записывали ODI на дискету?
format a: /N:80 /N:9
Затем образ писал на дискету с помощью rwwrtwin.exe/
Он не делает дискет из образов
Да, верно. У него как раз все наоборот. С диска - образ.
format a: /N:80 /N:9
Затем образ писал на дискету с помощью rwwrtwin.exe/
Может там какие параметры указать надо? Я вообще не в курсе, как оно образ пишет, сколько и каких секторов...
Да, верно. У него как раз все наоборот. С диска - образ.
У меня ещё проще. Просто образ, скачанный из сети :)
АлександрПП
19.12.2015, 19:27
Да нет, с форматированием все верно. Он потом и определяется как диск на 720 Кб. Тут скорее дело в записи. Я в таком формате никогда не писал, возможно что-то не так делаю.
Попробовал считать образ с записанной дискеты, выдает ошибку. Надо поискать какую-то другую программу для записи.
Достал из запасника антикварную утилитку (просмотрщик/конвертер) для вектора и приделал к ней сохранение в формате "как бы для ориона-про с мультикартой".
Как пользоваться: запускаем SPRView, открываем bmp, png, gif или pcx (16 цветные, размер до 256x256), при сохранении выбираем тип o32.
На орионе используем o32view с указанием имени картинки с расширением. Выход в дос - пробел.
Спасибо Дмитрию2012 за тестирование на реале и выявление шероховатостей!
Дмитрий2012
20.12.2015, 14:34
Добавлю несколько картинок с реала. И еще раз поблагодарю ivagor за то, что не оставляет без внимания Орион-ПРО. Благодаря ему появляется новый софт для Ориона, который раскрывает его возможности.
DDp наконвертил (http://zx-pk.ru/showthread.php?t=9720&page=3&p=694068&viewfull=1#post694068) картинок для своего варианта палитры 444. Они очень удачно подходят и для Ориона-Про с мультикартой.
АлександрПП
23.12.2015, 01:15
На настоящее время уже трое (АлександрПП, Дмитрий 2012 и Vladimir_S) попробовали запустить Ордос-6 на реале, используя образ диска. И ни у кого это не получается. Ордос хорошо идет на эмуляторе b2m. На эмуляторе ERROR404 я запустил ORD6$, придержав нажатой любую клавишу.
Симптомы неудачной загрузки похожи. Начинается загрузка, затем на экран выводится мусор и все зависает.
Хорошо бы если кто-то попробует запустить ОРДОС-6 на "Орион-Про", собранный на авторской плате. Такие, вроде есть. Если там пойдет, то дело в нашем новоделе. Где-то ошибка.
Ведь если мусорится область видео-ОЗУ, значит что-то с адресацией или переключением окон-сегментов?
Есть ли у кого-то какие-либо мнения на этот счет?
В ссылке видео загрузки из режима ПРО, 128 и загрузка ORD6$.
https://yadi.sk/d/5Z0lew8jmKwHE
Из видео ясно, что загрузочный сектор вроде-бы правильно считался. Он пишет ORDOS IS STARTING ... после чего пытается считать MBR, т.е. делает попытку определить диски на винте. Делает он это несколько секунд, а после неудачи должен был считать ORDOS.SYS, но вместо этого куда-то улетает. В варианте запуска из 128 (BOOT4$) приземляется на него-же (вывод надписи ДИСКИ НЕ ГОТОВЫ это из него, а не из загрузочного сектора). В варианте запуска из Про этого кода в памяти нет, и он гадит полэкрана. В варианте запуска ORD6$, судя по эмулятору, поведение должно быть аналогичным (попытка считать MBR в течение нескольких секунд), однако на видео он сразу вылетает, и гадит немножко на экран. Такое ощущение, что управление раскладкой памяти не подходит.
- - - Добавлено - - -
ORDOS6 активно использует окна по 16Кб, может где-то тут собака порылась?
АлександрПП
23.12.2015, 01:48
ORDOS6 активно использует окна по 16Кб, может где-то тут собака порылась?
Такие же мысли приходят.
Такие же мысли приходят.
Правда, тут же приходят мысли об iMSX ivagor-а, который тоже вроде бы использует эти окна. Но тут он сам смог бы поподробнее прокомментировать...
АлександрПП
23.12.2015, 13:05
Но тут он сам смог бы поподробнее прокомментировать...
Желательно бы...
Ничего необычного или неожиданного про обращение с 16Кб окнами сказать не могу. Использовал и в imsx и в o32view - везде работало как реализовано в emu. Есть отличия от emu в быстродействии турбы и особенности в программировании палитры, но к данному вопросу это вряд ли имеет отношение.
- - - Добавлено - - -
Есть предположение - возможны некие особенности при одновременном использовании 16Кб окон и переключении страниц через F9 (сам не пробовал, возможно поэтому не столкнулся с отличиями от emu)
Error404
23.12.2015, 13:26
Есть предположение - возможны некие особенности при одновременном использовании 16Кб окон и переключении страниц через F9 (сам не пробовал, возможно поэтому не столкнулся с отличиями от emu)
Таки да.
По части диспетчера по 16к были две версии Орионов ПРО, они отличалсь куда проецируется "склеенное ОЗУ" режима О-128:
Orion-Pro - v2.9 (RAM f000..ffff at segment 3)
Orion-Pro - v3.10 (RAM f000..ffff at segment 31)
Возможно тут собака порылась.
По части диспетчера по 16к были две версии Орионов ПРО, они отличалсь куда проецируется "склеенное ОЗУ" режима О-128:
Orion-Pro - v2.9 (RAM f000..ffff at segment 3)
Orion-Pro - v3.10 (RAM f000..ffff at segment 31)
Не знал, однако. У меня в доках только про 31 сегмент есть.
- - - Добавлено - - -
Вобщем, если проблема только в этом, то пропатченный загрузочный сектор должен отработать нормально (см. аттач).
АлександрПП
23.12.2015, 20:03
Что-то изменилось. Нет зависания. В обоих случаях выходит сообщение "ДИСКИ НЕ ГОТОВЫ", нажатие клавиши не влияет.
И в конце попытки загрузки небольшая пачкотня. Судя по всему дисковод дважды дергается на нулевой дорожке.
https://yadi.sk/d/PglwCRufmSEpm
Эмулятор OrionZEmu не находит ORDOS.SYS
"пачкотня" - это содержимое стека. Интересно только, почему он на экране оказался.
- - - Добавлено - - -
В обоих случаях выходит сообщение "ДИСКИ НЕ ГОТОВЫ"
Ну, эксперимент не совсем чистый, после первого запуска BOOT4$ он остаётся в памяти, и если во втором случае вылет происходит на него-же, то и результат одинаковый. Для чистоты эксперимента нужно каждый раз отключать питание.
В конце концов, можно же выяснить прямо в мониторе, какой странице соответствует интересующая нас область. Надо просто включить её в одно из окон, и посмотреть, там ли сидит код БИОСа. Например, включим младший бит порта 0А, выведем 03 или 1F в порт 04, и посмотрим дамп по адресу 3800. Там будет либо код БИОСа, либо мусор. Команды такие:
ia - читаем порт 0A, в эмуляторе выдаёт 50
oa,51 - включаем младший бит
o4,1f - включаем 31-ю страницу в окно 0
d3800 - смотрим дамп
АлександрПП
24.12.2015, 00:18
В 31- странице ничего нет. А вот в 3-й странице фрагмент диска test29, начиная с адреса 5A00 (смотрю в WINHEX).
То есть загрузочный сектор отработал правильно. Тогда непонятно, почему в эмуляторе работает, а на реале нет. А попробуй держать нажатой клавишу, есть подозрение, что он всё-таки пытается отработать конфигурационные файлы. Хотя в эмуляторе этого не происходит. Михаловский пишет, что конфигурационные файлы обязательно должны быть на диске.
АлександрПП
24.12.2015, 01:02
Пробовал. При запуске из ПРО в любом случае заполнение экрана слева-направо на две трети.
При запуске BOOT4$ при нажатой клавише выходит сообщение Диски не готовы и рестарт загрузки.
А если в эмуляторе положить на диск config.sys? Описать в нем хотя бы диски.
Хотя вряд ли это к чему-либо приведет. В эмуляторе-то работает.
Error404
24.12.2015, 01:02
Эмулятор OrionZEmu не находит ORDOS.SYS
Я делал эмуляцию только для дискет с 1024-байтными секторами (т.е. образ 800к и более). Образы дискет по 720 к и подобные (с 512-байтными секторами) работать не будут.
А вот в 3-й странице фрагмент диска test29, начиная с адреса 5A00 (смотрю в WINHEX).
Я тут подумал, посмотрел в эмуляторе, и пришёл к выводу, что карта памяти у тебя нормальная, т.е. непереключаемая область - это всё-таки 31-я страница. Во-первых, при переключении в режим Орион-128 стартовый код Ориона-Про тоже грузит БИОС Ориона-128, и грузит скорее всего в 31-ю страницу (вариант, что у тебя нестандартый ROM я отметаю). Во-вторых, при выходе в монитор, БИОС, загруженный с диска, должен был быть пререзаписан из ROM-а Ориона-Про. Тот факт, что в третьей странице он остаётся, говорит о том, что эту область памяти никто не трогает. Так что test29 - это полная лажа.
- - - Добавлено - - -
В 31- странице ничего нет.
Совсем ничего? Или всё таки что-то похожее на БИОС?
- - - Добавлено - - -
Просматривать память лучше наверное во втором окне, в первом при работе монитора половину занимает БИОС Ориона-Про. Т.е. в порт 0A выводить 52, номер страницы в порт 05, а смотреть в диапазоне 4000-7FFF.
- - - Добавлено - - -
А если в эмуляторе положить на диск config.sys? Описать в нем хотя бы диски.
Описывать диски не обязательно, если устраивает назначение букв дисков по-умолчанию. Задавать количество буферов тоже пока не нужно (загружаемых драйверов нет). Можно, конечно, добавить файлы и записать туда всего лишь точку, но мне кажется ничего не изменится.
АлександрПП
24.12.2015, 01:41
Посмотрел. Что-то есть, но код какой-то беспорядочный.
А вот в странице 31 с адреса B200, как и надо лежит ОРДОС6. И вот он то при запуске и заполняет экран, как и при холодном старте.
Да нет, код совсем не беспорядочный. Там то что надо.Перенос диска с адрес 2A00.
А вот в странице 31 с адреса B200, как и надо лежит ОРДОС6.
Надо бы определиться с терминологией, чтобы не путаться :)
Если говорить о странице 31, то размер её 16 Кб, т.е. диапазон адресов 0000-3FFF.
Если её включать через порт F9 (он же порт 08), то она окажется в диапазоне C000-FFFF.
Её можно конечно подключить в окно 8000-BFFF, но смысла особого нет, так что непонятно, что там "с адреса B200".
- - - Добавлено - - -
Что где должно лежать, можно посмотреть в эмуляторе. В отладчике в окне дампа нажать Ctrl+M, выбрать mem1. Только там вся память одним блоком, страница 31 будет в диапазоне 7C000-7FFFF. Информация есть в диапазонах 0B000-0BFFF и 78000-7FFFF.
Error404
03.01.2016, 16:22
Кстати, раз уж мы затеяли дискуссию о Fuzix на Орионе, может отделишь начиная с моего сообщения со скриншотом в отдельную тему?
Перенесено сюда: FUZIX для Ориона (ПРО)
http://zx-pk.ru/showthread.php?t=26004
Пытаюсь запустить развёрнутый на дискетку образ PRODOS20.ODI
Получаю вот такую ерунду:
http://cs627417.vk.me/v627417907/3df80/0D-8vkNk04E.jpg
Насколько я понимаю из написанного, загрузчик почему-то считает, что его запускают в режиме "Орион-128", а он хочет "Орион-ПРО".
Образ отсюда - http://zx-pk.ru/showthread.php?t=22389&p=841893&viewfull=1#post841893
Есть скачанный ранее где-то на форуме другой образ, называется также PRODOS20.ODI, но содержимое отличается. Он загружается по-другому - в широкоэкранном режиме, ничего не пишет про режим Ориона и в финале запускает Нортон.
Первый мне больше подходит, т.к. он загружается в обычном режиме 384х356 точек, и я могу что-то увидеть и прочитать. Но как ему "доказать", что я выбираю в меню "Орион-ПРО", а не "Орион-128" ???
- - - Добавлено - - -
Кажется понял. Если запустить PG200.COM, то она "патчит" загрузчик и он начинает нормально грузиться, но в широкоэкранном режиме ((
Если потом запустить WIDTH.COM и выставить "узкий" экран, то загрузка в 384х256, но режим компа распознаётся как "Орион-128" и вкусняшки не грузятся. Замкнутый круг, по ходу.
Ещё заметил странность. "Узкий" режим не влияет на команду просмотра текстовых файлов в Нортоне - их просмотр всегда переключается в широкоэкранный.
- - - Добавлено - - -
Ещё одна непонятка. В образах дисков от Орион-Софт файлы в формате BRU. Их напрямую в PRODOS не запустить. На диске есть программа BRU.COM, если её запустить, то она выводит каталог файлов, по которому можно перемещаться, но запускать оттуда BRU-файлы по-прежнему нельзя (( По нажатию Enter файлы куда-то копируются, но куда - не понятно. Выхожу в ДОС, пытаюсь выбирать другие диски - пишет ошибку "на диске нет системы". Как же запускать эти BRU ?
П.С. файлы точно куда-то копируются! т.к. повторное копирование файла выводит сообщение о том, что такой файл уже "там где-то" есть :)
- - - Добавлено - - -
И сразу же ещё одна трабла, на этот раз на IBM-PC: утилита записи образов DiskUtil.exe с драйвером fdrawcmd.sys.
Форматирует дискеты - нивапрос. Проверка результатов форматирования всегда ок. Но при попытке записи образа на случайном треке вываливается с ошибкой "Не удается найти заданный сектор на диске". Большая редкость, когда удаётся записать до 25-го сектора, обычно вылетает на секторах до 10-го. Перепробовал всё, что знал: переустанавливать драйвер, менять шлейф и дисковод - бестолку! Обратил внимание, что вылетанию с этой ошибкой всегда предшествует "своп" на винчестер, т.е. Винда что-то начинает писать на винт, и тут же DiskUtil вылетает с этой ошибкой. Пытался останавливать все ненужные службы, отключал локальную сеть, в диспетчере задач удалял всё лишнее - ничего не помогает. Гугл ничего не знает о моей проблеме, видимо слишком старинный и неактуальный софт, выдаёт единственную страницу - http://simonowen.com/fdrawcmd/ , на которой ничего по моей проблеме нет.
Кто-нибудь заливал ODI-образы на труъ-дискеты 3,5" ? Как вы это делаете??
Дмитрий2012
09.01.2016, 09:44
Насколько я понимаю из написанного, загрузчик почему-то считает, что его запускают в режиме "Орион-128", а он хочет "Орион-ПРО".
скорее всего на плате не включен контакт 4 на DIP переключателе SW1-SW8. вот и грузится OSDOS.
АлександрПП
09.01.2016, 12:28
Пытаюсь запустить развёрнутый на дискетку образ PRODOS20.ODI
Мой косяк. Образ диска с записанной на ней ORDOS, а не PRODOS. Перезалил.
Просто грузится ORDOS, а на дискете программы PRODOS. Вот система и сообщает, что программы только для Орион-Про.
PRODOS20.ODI, но содержимое отличается. Он загружается по-другому - в широкоэкранном режиме,
Здесь все загружается правильно. PRODOS работает в широком экране.
Если запустить PG200.COM
Правильно. Это программа генерации PRODOS на дискету.
В образах дисков от Орион-Софт файлы в формате BRU
Это формат обмена файлами между ORDOS и дискетой. Проограмма BRU4.com загружает их на квазидиски. Надо выйти из PRODOS и на квазидисках C-H будут лежать эти файлы. Чтобы работать с этими файлами лучше сразу заходить в ORDOS (Орион-128). И лучше запускать Atlas$.
Тут главное - понять, что перед нами как бы два компьютера - Орион-Про и Орион-128. Естественно, программы Орион-Про, как правило, на Орион-128 работать не будут. Ведь Windows тоже ругается когда мы пытаемся запустить программы MSDOS.
Но при попытке записи образа на случайном треке вываливается с ошибкой "Не удается найти заданный сектор на диске".
Тут не понятно. Утилита работает прекрасно.
Думаю, что 1-12 провода в шлейфе перевернуты, окно плотности заклеено.
А в какой Винде делаем это? По-моему утилита работает только до XP. Это точно знает ERROR404.
скорее всего на плате не включен контакт 4 на DIP переключателе SW1-SW8. вот и грузится OSDOS.
Пробовал - без разницы. 4-ый переключатель отвечает за страницу ОЗУ, в которую грузится СР/М.
АлександрПП
09.01.2016, 13:18
Пробовал - без разницы
Естественно!
Загрузка зависит не от положения переключателей, а от того, что записано на дискете.
Получаю вот такую ерунду
DIP8 надо включить.
8 Режим работы:
On – «Pro», Off – «Orion-128»
(CP/M-80) (ORDOS)
DIP8 надо включить.
8 Режим работы:
On – «Pro», Off – «Orion-128»
(CP/M-80) (ORDOS)
Это я всё понимаю. Разумеется, стоит "On" (CP/M-80).
- - - Добавлено - - -
Это формат обмена файлами между ORDOS и дискетой. Проограмма BRU4.com загружает их на квазидиски. Надо выйти из PRODOS и на квазидисках C-H будут лежать эти файлы. Чтобы работать с этими файлами лучше сразу заходить в ORDOS (Орион-128). И лучше запускать Atlas$.
Ясно. Спасибо!
Тут не понятно. Утилита работает прекрасно.
Думаю, что 1-12 провода в шлейфе перевернуты, окно плотности заклеено.
А в какой Винде делаем это? По-моему утилита работает только до XP. Это точно знает ERROR404.
Да, шлейф родной, с ним дисковод работает отлично: Винда форматирует дискету, записывает/читает без проблем.
Окно плотности, разумеется, заклеено. Странно, что форматирование/верификация всега проходят без проблем, все 80 дорожек, ни разу не было вылета. И только при попытке записи образа такая фигня.
Винда как раз ХР. Комп супердревний мамонт - Пентиум-3, 512 Мб ОЗУ :) Но думаю для такой примитивной утилиты этот факт без разницы, да и весь остальной софт на нём работает без проблем.
- - - Добавлено - - -
Вот как это выглядит:
Попытки записи образа - http://www.youtube.com/watch?v=XO_MM2_q15E
Проверка диска - http://www.youtube.com/watch?v=E9nWwcJZWjg
Мой мозг отказывается это понимать %)
- - - Добавлено - - -
П.С. вариант "DiskUtil disk10.odi a:", т.е. без форматирования и проверки, только запись тоже пробовал - всё тоже самое, вылетает на случайном треке.
Error404
09.01.2016, 19:53
Diskutil только делает обращения к драйверу FDRAWCMD одной командой "выбрать вид физ.формата диска"/"записать сектор"/"считать сектор" (ее исходники кстати есть в исходниках эмулятора - можете сами убелиться). Все остальное делает драйвер. Пока ни у кого на XP проблем с этим драйвером не было, а вообще он подтверждено работает на всех клонах XP (т.е. по Win8 включительно) - на основе этого драйвера 100500 утилит написано разными людьми, под разные платформы и разные физические форматы дискет. Думаю, дело в престарелом приводе или в носителях или в их взаимодействии.
ее исходники кстати есть в исходниках эмулятора - можете сами убелиться
Да, я заметил. Но Visual C не знаю, увы.
Пока ни у кого на XP проблем с этим драйвером не было...
У меня же на работе были те же самые проблемы, просто там удавалось иногда записать почти весь образ. А тут совсем другой комп, другие железяки, а грабли те же самые. Может у меня сама утилита битая? Но по идее, если бы была битая, то вылеты были бы стабильные, по крайней мере в одних и тех же местах.
Думаю, дело в престарелом приводе или в носителях или в их взаимодействии.
Я ж написал, что приводы менял. И форматирование/проверка/ проходят на ура. Запись/чтение файлов в формате IBM-PC на этом железе работает безупречно.
Если я правильно понимаю сообщение об ошибке, то оно говорит о том, что софтинка в течении какого-то времени не нашла на данном треке сектор с нужным номером. Но он там точно есть, т.к. верификация всегда проходит, а в процессе верификации действия те же самые - ищем нужный сектор, читаем его содержимое, как-то там верифицируем.
Либо при записи образа ответы от контроллера искажаются (например, какие-то конфликты между флопом и винтом по прерываниям... фантазирую), либо может винда видит, что на дискету что-то записывается и пытает сделать что-то своё "умное", типа закэшировать новые данные... х/з.
Что-то не совсем то!
Образ диска test6.odi записан на дискету и с него создан образ диска HFE для эмулятора НГМД.
У двоих владельцев "железных" "Орион-ПРО" картина одна и та же при загрузке что с реальной дискеты, что с образа HFE.
Чтобы долго не рассказывать прилагаю ссылку на видеоролики. Там загрузка с дискеты в двух вариантах. Напрямую из меню-Орион-про и через ORD4$. Похоже, что система переносится не совсем туда.
https://yadi.sk/d/5Z0lew8jmKwHE
На эмуляторе все идет прекрасно. Видимо, он не совсем точно эмулирует "Орион-ПРО".
Александр, каким образом можно залить этот образ на реальную дискету? Хочу попробовать на своём реале.
Есть DiskUtil.exe, но он работает с 800-килобайтной разметкой (на дорожке 5 секторов по 1 Кб), а образ TEST6.ODI в 720-килобайтной (9 секторов по полкило).
АлександрПП
19.01.2016, 14:13
Надо скачать WinImage. А там, вроде, все понятно.
https://yadi.sk/d/Zog0foAfnKzvJ
Надо скачать WinImage. А там, вроде, все понятно.
https://yadi.sk/d/Zog0foAfnKzvJ
У меня на рабочем компе совершенно случайно оказался установленный какой-то:
http://denn.ru/img/winimage.jpg
Наверное подойдёт..
АлександрПП
19.01.2016, 14:46
Конечно подойдет.
Открыл образ TEST6.ODI в WinImage, а там всего два файла:
http://denn.ru/img/test6.jpg
Всё верно?
АлександрПП
20.01.2016, 18:18
Да, главное, ordos.sys на месте.
В общем, у меня на реале образ тоже не взлетел. Сначала пишет "ORDOS starting" или что-то в этом духе, а потом примерно 2/3 экрана заполняется мусором и всё.
АлександрПП
21.01.2016, 01:43
А плата авторская или наш новодел?
А плата авторская или наш новодел?
Июнь 2015-го.
- - - Добавлено - - -
Ещё вот какая бяка получилась при попытке загрузки с образа TEST6.ODI. После того, как полюбовался пейзажем глюков и перестал крутиться дисковод, я нажал на сброс, как обычно загрузилось стартовое меню на красном фоне... но клавиатура работала некорректно! У меня клавиатура PS/2 через МК. При нажатии Enter, текущий пункт меню моргал 2-3 раза и ничего не происходило, стрелка вверх не работала вообще (не перемещался указатель), а работала только стрелка вниз. Понажимал несколько раз сброс, в т.ч. аппаратный на плате - безрезультатно. Решил, что в ОЗУ прописалось какое-то некорректное значение касательно запоминания пунктов меню... выключил питание, включил обратно - проблема на месте! Я приуныл, решил, что образ что-то попортил аппаратно, например (как предположение) перепрограммировал порт клавиатуры "все линии на вывод" и т.о. пожёг ВВ55 или МК ((. Выключил питание, но включил не сразу, а подождал долго. Включил... слава богу, пронесло, клава и меню работает как надо. Второй раз пробовать не стал.
АлександрПП
21.01.2016, 12:40
но клавиатура работала некорректно!
Аналогично.
Выключил питание, но включил не сразу, а подождал долго
На ОЗУ куча конденсаторов, им надо разрядиться.
На ОЗУ куча конденсаторов, им надо разрядиться.
Они стоят по питанию, и разряжаются через все микросхемы Ориона! Там банка в 6800 мкф разряжается в ноль за долю секунды. Скорее всего сами ячейки ОЗУ "помнят" данные какое-то время.
Дамы и господа, а есть ли какая-нибудь небольшая софтинка тестирующая КНГМД на ОРИОН-ПРО ?
Некий TESTD$ у меня на ПРО не работает (лампочку зажигает, шпиндель раскручивает и виснет насмерть).
Нужна для препарирования на предмет понимания программной работы с дисководом. Так что если прога будет с хорошо комментированным исходником, то вообще шикарно!
Дмитрий2012
05.02.2016, 15:00
Есть исходник TESTD для ПРО.
Дмитрий2012
29.03.2016, 22:31
Оставлю это здесь, может кого заинтересует. Программа предназначена для тестирования различных функциональных узлов компьютера Орион-ПРО. Изначально тест на реале и в эмуляторе не запускался. Спасибо ivagor, поправил код и все заработало.
Интересный диск, там ещё и музыкальный плеер, и просмотрщик ZX-картинок, и ещё всякая всячина (в других номерах пользователя).
Error404
30.03.2016, 15:01
а плеер каких файлов?
а плеер каких файлов?
AY плеер. Играет файлы "*.PT3". Музыка в формате муз. процессора от Ямахи.
https://www.youtube.com/watch?v=5TfHR_ugjIk
Error404
30.03.2016, 21:23
Прикольно. А для набортного ковокса (порт FE) есть какой-нибудь софт/треки (может на других дисках)?
Давно хотел поделиться, но перманентное желание улучшать, вылизывать не давало это сделать. Решил всё таки выложить очередную "бэту", т.к. все ключевые хотелки вроде реализованы, дальше уже будет оттачивание мелочей.
Итак, версия ОС DSDOS теперь и для ПРК "Орион-ПРО".
Ссылки для скачивания образов ROM-дисков:
http://denn.ru/orion/dsdos/dsdos380spro.rar
http://denn.ru/orion/dsdos/dsdos380fpro.rar
Первый вариант - т.н. "лайт" версия, для ПЗУ ROM-диска объёмом 64 Кб, содержит базовый набор ПО, для ознакомления.
Второй - полная версия, для 2-х микросхем ПЗУ ROM-диска, общим объёмом 128 Кб, содержит расширенный набор ПО + несколько игрушек.
Возможна сборка ROM-диска общим объёмом 256 Кб (задействованы четыре микросхемы ПЗУ), ОС поддерживает прозрачную работу с полным объёмом ROM-диска.
ROM-диск стандартный, который идёт в составе родной мультикарты.
Основные отличия от ОС DSDOS для ПРК "Орион-128":
- прозрачная поддержка ROM-диска мультикарты максимально возможного объёма (256 Кб);
- поддержка квазидиска объёмом 360 Кб;
- FAT квазидиска с кластером размером 256 байт (скорость доступа на 80% быстрее!);
- максимальное кол-во файлов на ROM-диске и на виртуальном диске - 255;
- поддержка виртуального диска со скоростью доступа 115200 Бод;
- поддержка клавиатуры PS/2 (через адаптер на МК от Caro) по-умолчанию;
- реакция клавиатуры адаптирована для тактовой частоты ЦПУ = 10 МГц.
Для запуска необходимо сконфигурировать ПРК в режим загрузки "ORDOS" с ROM-диска, а в стартовом меню выбирать пункт "Орион-128".
П.С. Огромное спасибо Дмитрий2012 за помощь в тестировании многочисленных бэта-версий! :)
После предыдущего поста была произведена некоторая работа над ошибками, ну и разумеется очередная порция улучшайзинга,
в результате решил оформить в виде очередной версии - DSDOS v3.81 PRO.
Ссылки для скачивания:
Сборка-лайт "ознакомительная" под ROM-диск 64Кб - http://denn.ru/orion/dsdos/dsdos381spro.rar
Полная сборка под ROM-диск 128Кб (две 64Кб ПЗУ мультикарты) - http://denn.ru/orion/dsdos/dsdos381fpro.rar
Документация по API ОС - http://denn.ru/orion/dsdos/dsdos381docs.rar
Теперь виртуальный диск ( G: ) интегрирован в BIOS, глюки на скорости 115200 Бод в режиме ЦПУ "2,5 МГц" устранены. Сделана поддержка двух вариантов организации порта: родного (COM1) на ВИ53+ВВ51А и нового (COM3) на чипе 16C550 (схему опубликую позже, как обычно :)). По-умолчанию загрузчик ОС выбирает наиболее быстрый из имеющихся в наличии (автодетект при "холодном" старте ОС). Программно порты доступны через соотв. процедуры BIOS'а.
В связи с поддержкой двух типов клавиатур (РК86 и PS/2), пришлось изменить алгоритмы обработки "горячих" клавиш, т.к. в режиме "РУС" на клавиатурах не совпадают коды одинх и тех же клавиш, в связи с этим изменились параметры процедур настройки и статуса клавиатуры, а также изменились соотв. алгоритмы обработки "горячих" клавиш в ПО (оболочка DC$ и текстовый редактор ED$).
В ED$ добавлена возможность вызова справки (Esc & "H") и конфигуратора ED$CFG (клавиша F5) из редактора.
Исправлен глюк с зависанием в режиме ЦПУ "2,5 МГц" при форматировании дискеты.
При обращении к процедурам ОС теперь принудительно отключаются прерывания (вызывало конфликты с некоторым ПО под ORDOS).
ПО, использующее прямые обращения к портам, определяет тип ПРК (Орион-128 или Орион-ПРО), чтобы корректно использовать адресацию портов (LDA/STA vs. IN/OUT).
Также произведена оптимизация кода и исправление мелких недочётов в системном ПО.
Побаловался - сделал ротозумер. Для меня это первая реализация, поэтому наверняка можно оптимизировать, но все не так плохо, на реале будет давать около 13 FPS, а в эмуляторе еще больше.
Требуется мультикарта (палитра), т.к. взял картинку в оттенках серого.
Управление:
курсор вправо - вращение по часовой стрелке
курсор влево - вращение против часовой стрелки
курсор вниз - уменьшение ("отдаление")
курсор вверх - увеличение ("приближение")
пробел - выход в дос (отлаживал в ProDOS, насчет других не уверен).
Дмитрий2012
20.07.2016, 19:16
ЗдОрово. В цвете конечно смотрелось бы поинтересней:)
На реале у меня на экране присутствуют помехи в виде вертикальных черточек, похоже мультикарта глючит:( Хотя, если смотреть картинки в просмотрщике никаких помех нет.
https://youtu.be/7Wmx1vsKKTM
OrionExt
20.07.2016, 23:00
Забавно. Начали демки появляется. И на ютубе, даже можно посмотреть:)
На реале у меня на экране присутствуют помехи в виде вертикальных черточек, похоже мультикарта глючит Хотя, если смотреть картинки в просмотрщике никаких помех нет.
Полоски на стыке байтов, плюс в этом месте переход с цвета переднего плана к цвету фона, вероятно один из этих факторов или оба сказываются. Еще возможно влияет конкретное сочетание цветов на стыке, где видны полоски.
В просмотрщике использован другой режим - цвет/точку. Для ротозумера с "точкой" 4x4 он будет заметно медленнее.
Требуется мультикарта (палитра), т.к. взял картинку в оттенках серого.
Без распаянной видеочасти на мультикарте не имеет смысла запускать? Иными словами, в стандартный экран Ориона программа не рисует?
Управление:
курсор вправо - вращение по часовой стрелке
курсор влево - вращение против часовой стрелки
курсор вниз - уменьшение ("отдаление")
курсор вверх - увеличение ("приближение")
пробел - выход в дос (отлаживал в ProDOS, насчет других не уверен).
Опрос клавиатуры организован через API ПРОДОС ?
WAV-плееры (https://yadi.sk/d/fOUAYacttY5vt). 3 версии - для 8-битного ковокса (к порту принтера), для 4-битного набортного (порт FE) и для AY/YM (плата COM+AY). Поддерживаются wavы с параметрами 8 бит ИКМ, моно, частота дискретизации 8000/11025/16000/22050 Гц.
Запуск
wavcvx8 имя_файла.wav
wavcvx4 имя_файла.wav
wavay имя_файла.wav
Большое спасибо Дмитрию2012, который потратил много времени и сил на проверку прототипов проигрывателя. Надеюсь, я с тех пор не внес серьезных ошибок и все продолжит работать.
По ссылке два диска, на которых кроме проигрывателей есть примеры, по одному на каждую частоту дискретизации. Файлы должны быть до 304 Кб.
Без распаянной видеочасти на мультикарте не имеет смысла запускать? Иными словами, в стандартный экран Ориона программа не рисует?
Рисует на стандартном экране ориона, но без палитры будет цветное психоделическое изображение.
Опрос клавиатуры организован через API ПРОДОС ?
Нет, напрямую через порты. Функцию опроса cp/m вызываю только один раз, перед выходом.
WAV-плееры (https://yadi.sk/d/fOUAYacttY5vt). 3 версии - для 8-битного ковокса (к порту принтера), для 4-битного набортного (порт FE) и для AY/YM (плата COM+AY).
Супер! А можно попросить выложить архивом с файлами, а не образом дискеты?
Error404
22.07.2016, 18:37
И если бы еще были WAV-плееры с версией для AY на портах BFFD/FFFD (Спектрума) - было бы вообще хорошо. У нас же еще Орион128 есть, где при разработке портов подключения AY не страдали синдромом фатального недостатка (http://0s.nr2xe23nn5zgkltdn4.cmle.ru/%D4%E0%F2%E0%EB%FC%ED%FB%E9_%ED%E5%E4%EE%F1%F2%E0% F2%EE%EA) (как везде на ПРО, ну вот буквально за что ни возьмись), а делали очевидным путем - для максимальной совместимости. :)
А файлы размером 304 Кб как читаются с дискет? По мере проигрывания подгружаются файловыми процедурами CP/M или как-то иначе?
Дмитрий2012
22.07.2016, 18:43
Полоски на стыке байтов, плюс в этом месте переход с цвета переднего плана к цвету фона, вероятно один из этих факторов или оба сказываются. Еще возможно влияет конкретное сочетание цветов на стыке, где видны полоски.
У кого-нибудь из собравших мультикарту, наблюдаются подобные вертикальные полосы в ротозуме?
Уже не первый раз наблюдаю глюки с мультикартой. В играх портированных со спектрума вообще ерунда какая-то творится на экране. https://youtu.be/NsNW8R85YoE?t=81
Для ротозумера с "точкой" 4x4 он будет заметно медленнее.
Это понятно, что будет медленнее:) чисто теоретически, примерно на сколько может просесть FPS?
архивом с файлами, а не образом дискеты
Приложил к посту
AY на портах BFFD/FFFD
Сделать можно, но в реале же вроде для про такого нет? "Ранние" версии imsx для этих портов я сделал потому, что тогда не знал про вариант Пушкова.
А файлы размером 304 Кб как читаются с дискет? По мере проигрывания подгружаются файловыми процедурами CP/M или как-то иначе?
Перед проигрыванием загружаются в память процедурами CP/M
В играх портированных со спектрума вообще ерунда какая-то творится на экране.
Попробуй запустить blackfix перед запуском игрушки
чисто теоретически, примерно на сколько может просесть FPS?
Сложно сказать, может даже в 4 раза
Error404
23.07.2016, 09:58
Сделать можно, но в реале же вроде для про такого нет? "Ранние" версии imsx для этих портов я сделал потому, что тогда не знал про вариант Пушкова.
Перед проигрыванием загружаются в память процедурами CP/M
Пушкову руки бы оторвал. Деятель блин, сколько теперь переделывать из-за их "стандатизаторского зуда". К счастью, большая часть их творений неинтересна из-за примитивности, и можно просто отправить в /dev/null. И ладно если бы были первопроходцы, так ведь нет! Кстати, на 3.20 платы AY и под дешфрацию Спека планировались (только доотладить надо похоже).
Для загрузки в память какое-то используется АПИ?
В АльтаирДос есть управление памятью средствами системы (доп. функции BDOS) размером системной памяти до 1Мб - работа блоками по 4кб : карта занятости (отсутствует/свободно/занято в разрезе по процессам), выделение и освобождение как конкретного блока (или группы из N блоков) по его адресу, так и резервирование любого свободного (или группы из N блоков) - типа malloc/free. Это сделано было в 95 году еще.
Сейчас плееры в ней запускаются, но только единократно, т.к. похоже пропиливают системные области "по железу", а между тем запускать имеет смысл именно в ней, т.к. там в отличие от древних реализаций (где цельнотянутая питерская ACPM с минимальными косметическими правками) поддерживаются не только дисководы и RAM/ROM диски, но и емкие носители (IDE/SD) - как раз под большие музыкалки. Лично проверял - CP/M 2.2 пишет файлы до 512 кб, раздел может быть до 64Мб (в текущей реализации). А раз файлы пишутся в ОЗУ целиком, то их еще можно было бы паковать (все одно формирование WAV идет на PC), а при загрузке на Z80 можно было бы разжимать в ОЗУ (распаковка обычно быстро работает и не сложно алгоритмически на большинстве депакеров). Это был бы идеальный плеер. :)
Для загрузки в память какое-то используется АПИ?
Памятью распоряжаюсь самостоятельно, это да. Но в альтаире еще разница в конфигурации некоторых портов, это тоже сказывается. Если честно, то я вряд ли соберусь переделать/доделать проигрыватель под альтаир, хотя все же такая вероятность есть.
С ограничением в 512 Кб я столкнулся, длинные файлы приходилось разбивать на части (в wav-плеере это не поддерживается)
Зато совместно с Дмитрием2012 подправили blackfix (версия из поста выше работает под prodos, но там она вроде не особо нужна) под альтаир - он решает проблему черного/серого в игрушках.
Error404
23.07.2016, 21:34
Памятью распоряжаюсь самостоятельно, это да. Но в альтаире еще разница в конфигурации некоторых портов, это тоже сказывается.
А что именно за порты? Как по мне (что неудивительно - делал то под себя), то в Альтаир-ДОС гораздо проще писать в особенности использующее орионовские фишки: многостраничные программы и программы с прерываниями, т.к. в BIOS есть сервисы для этого. При этом сохраняются все функции BDOS CPM 2.2.
Что до ПРО-ДОС, то даже с первых пользовательских действий у меня отторжение: система какая-то по пояс деревянная. Клавиатура вялая (а автоповтор безумно быстрый) чего было не работать по прерыванниям независимо от частот? Упростили себе жизнь. Нормального редактирования в системной консоли нет (как там мне вставить два символа в середину или начало уже набранной строки из сорока-пятидесяти символов? все стирать?), а повторить команду поправив пару символов? Т.е. тимплета понятно тоже нет, автоподмен CCP подозреваю наверняка нет, батники в OS-DOS (то что было как ПРО-ДОС но для 128-го, подозреваю тут те же яйца вид сбоку) хотя и были встроенными как у меня (выполнение без XSUB/SUBMIT) но были без параметров и без вложенности. И т.д. и т.п., не говоря уже о том, что BIOS у ПРО-дос застрял в прошлом веке и вряд ли кто им будет заниматься (ввиду выбытия авторов, да и неизвестно есть ли исходники). ТPА маленький - 51к (против 58к у АльтаирДОС). Искейп коды драйвера консоли они тоже переписали (ну что пля за люди?), тогда как коды от чистяковского 480C это уже был фактически стандарт на Орионе и что характерно - за несколько лет до ПРО-ДОС (да и Ориона-ПРО в целом).
Если честно, то я вряд ли соберусь переделать/доделать проигрыватель под альтаир, хотя все же такая вероятность есть.
Ну, тогда лучшее решение - это open source, и пусть каждый допилит под ту ОС где более удобно. :)
А то всегда схема одна и та же: посмотришь, "ну круто, чо, если бы не {1,2,3..}", shift+del.
C творениями b2m такая же фигня, будь оно OS, хоть что-то можно было применить в хозяйстве.
Зато совместно с Дмитрием2012 подправили blackfix (версия из поста выше работает под prodos, но там она вроде не особо нужна) под альтаир - он решает проблему черного/серого в игрушках.
Это для платы палитр нужно? Что именно оно делает?
Сделал вариант проигрывателя wavов для ay/ym на спековских портах.
А что именно за порты?
Как минимум FB, еще там что-то отличалось.
Ну, тогда лучшее решение - это open source, и пусть каждый допилит под ту ОС где более удобно.
Только не текущий вариант, мне не нравится код. Может когда-нибудь соберусь переписать.
Это для платы палитр нужно? Что именно оно делает?
Да, это для палитры на мультикарте. По умолчанию пзу задает 0 - черный, 8 - серый, а для некоторых игрушек нужно чтобы 0 и 8 были одинаковые (черные), фикс как раз это и делает.
- - - Добавлено - - -
Насчет open sourceности - выкладывал довольно много исходников, но с трудом могу вспомнить, чтобы кто-то их дорабатывал и использовал, т.ч. есть исходники или нет - результат для меня одинаковый. А исходники, выложенные b2mом я неоднократно использовал, можно даже сказать злоупотреблял.
И еще один вариант (https://yadi.sk/d/47oCkuW7taQFC) проигрывателя wavов с примерами - теперь для ram-диска (который 1 Мб).
У него два преимущества:
1. Поддержка файлов максимального размера (до 512 Кб)
2. Поддержка более высокой частоты дискретизации 32000 Гц
Сделать этот вариант очень помог Дмитрий2012. В эмуляторе поддержки рам-диска нет и в первых вариантах были ошибки. Кроме того, в книжке "Радиолюбительский компьютер Орион-ПРО" на странице 33 ошибка - перепутаны порты A0 и A2.
Дмитрий записал с реала два примера - с наименьшей частотой дискретизации 8000 Гц (https://drive.google.com/file/d/0B7xjYWTXlb9mS1ZXZDhrRmF2M28/view?pref=2&pli=1) и наибольшей 32000 Гц (https://drive.google.com/file/d/0B7xjYWTXlb9mcktKZnhKN1VkVDg/view?pref=2&pli=1)
Пара слов насчет поддержки hdd и sd в досах для ретрокомпов. Плохо, когда ее совсем нет, когда она есть с использованием файловой системы cp/m - это лучше, но имхо удобный вариант - это поддержка FAT. CP/M пусть работает с образами, а новые программы - с файлами FATа
- - - Добавлено - - -
Оффтоп, но раз заходила речь про большие файлы и hdd. Пользуюсь OdiWcx - работает отлично, а вот OhiWcx работет довольно странно. Файлы больше определенного размера (в районе 32 Кб) портит. Записывал большие файлы на образ hdd из под альтаира - так ошибок нет, но очень медленно и неудобно.
Error404
24.07.2016, 20:53
Сделать этот вариант очень помог Дмитрий2012. В эмуляторе поддержки рам-диска нет и в первых вариантах были ошибки. Кроме того, в книжке "Радиолюбительский компьютер Орион-ПРО" на странице 33 ошибка - перепутаны порты A0 и A2.
А чего опять порты? Если нужен "сырой" доступ, то можно же хотя бы через BIOS (прямо посекторно без ФC, просто указав номер диска), это и то хоть как-то можно пользовать тем, кто не будет все те нелепые железки собирать на сотне РУ7х.
CP/M пусть работает с образами, а новые программы - с файлами FATа
Библиотека FAT - это порядка 20кб "прибавки" в каждую программу которая это захочет юзать и дикие тормоза. У меня есть программа работающая с FAT (я использовал порт FatFS от ElmChen-а) как утилита для обмена (скопировать файл из/на ФС CP/M, т.е. в обе стороны), на большее она неспособна ввиду тяжеловесности алгоритмов (например, использования int32 математики) и как следствие - величины кода.
Оффтоп, но раз заходила речь про большие файлы и hdd. Пользуюсь OdiWcx - работает отлично, а вот OhiWcx работет довольно странно. Файлы больше определенного размера (в районе 32 Кб) портит. Записывал большие файлы на образ hdd из под альтаира - так ошибок нет, но очень медленно и неудобно.
Да, я знаю про этот глюк. Глюк проявляется только на файловых системах CP/M размеченных с размером группы в 16кб (это максимум возможный для CP/M, я не сразу стал его использовать, по началу юзал 8кб на которых и отлаживал плагины). Это глюк именно в OdiWcx, т.к. вся логика именно в нем (OhiWcx только обертка для вычисления оффсета партиций и вызова с этим параметром OdiWcx), логика в OdiWcx универсальная и настраиваемая по DPB диска (просто на образах дискет где размер группы 2кб глюк не проявляется). В орионовских образах HDD размер группы 16к где файловые системы (партиция) 64Mб или более (они обычно делались fdisk последней версии, делающим размер группы 16к) - там глюк есть. А вот где размер группы 8кб (обычно это ФС/партиции 32Мб и менее более старых образов, созданые предыдущим FDISK) - он не проявляется и туда нормально записываются файлы больше 32кб.
Просто пока этим пользовался я один, трассировать и ловить баг не было стимула (есть поинтереснее чего попрограммить), я тупо пользовал разделы со старых образов. Теперь обещаю исправиться и баг изловить и изничтожить. :)
Дмитрий2012
24.07.2016, 21:32
А чего опять порты? Если нужен "сырой" доступ, то можно же хотя бы через BIOS (прямо посекторно без ФC, просто указав номер диска), это и то хоть как-то можно пользовать тем, кто не будет все те нелепые железки собирать на сотне РУ7х.
У пользователей уже есть на руках RАМ диски, где куча РУ7 успешно заменены на две микрухи:)
http://zx-pk.ru/threads/21889-orion-pro-sozdanie-originalnoj-repliki.html?p=808283&viewfull=1#post808283
Error404
24.07.2016, 23:42
ну-ну.
теперь добейтесь чтобы оно выполнялось на конкретном экземпляре ромдиска. привязываться к железке - так уж насмерть.
Старик Килдалл не дожил, посмотреть как растоптано все то, за что он боролся полвека тому назад создавая CP/M. Какие-то там абстрактные уровни, выенесение железа "за скобки". Зачем вам вообще ОС? Вам в Ордос, парни. Пиццот рамдисков по 64к, во все писать через порты. :)
- - - Добавлено - - -
И магнитофон. И пять кассет на каждый Wav . А то ишь - "дисковод из вашей CP/M мы берем, нам понравилось, а все остальное нам не нать". :)
OrionExt
25.07.2016, 00:51
А в Pro-DOS была поддержка памяти больше 64 КБайт? Менеджер памяти на уровне операционной системы или что-то подобное.
А чего опять порты? Если нужен "сырой" доступ, то можно же хотя бы через BIOS (прямо посекторно без ФC, просто указав номер диска), это и то хоть как-то можно пользовать тем, кто не будет все те нелепые железки собирать на сотне РУ7х.
В биосе есть функция, которая прочитает произвольный байт за, например, тактов 30, ну 50? Нету ведь, а значит при использовании биоса просто невозможно сделать проигрыватель wav для частот дискретизации 8000/11025/16000/22050/32000 Гц. Вариантов два - можно сделать с доступом напрямую или просто нельзя сделать, зато через биос или дос.
Error404
25.07.2016, 13:25
А в Pro-DOS была поддержка памяти больше 64 КБайт? Менеджер памяти на уровне операционной системы или что-то подобное.
Я не помню, надо смотреть, возможно что-то найдем в описаниях от ПРО, и уже тогда надо будет проверить - а есть ли оно в коде (т.к. не факт).
Я тему ПРО слабо отслеживал (вообще не думал что у меня когда-то оно будет, но оказалось что собрать ПРО с нуля проще, чем разогнать Орион-128, собственно кроме быстродействия мне всего хватает на 128), поэтому отплевываюсь уже по ходу изучения "новых стандартов" когда начинаю что-то для себя настраивать/добавлять, или когда оказывается что вещи сделанные до ПРО вдруг надо переделывать ибо творцы не сошлись во мнениях.
- - - Добавлено - - -
В биосе есть функция, которая прочитает произвольный байт за, например, тактов 30, ну 50? Нету ведь, а значит при использовании биоса просто невозможно сделать проигрыватель wav для частот дискретизации 8000/11025/16000/22050/32000 Гц. Вариантов два - можно сделать с доступом напрямую или просто нельзя сделать, зато через биос или дос.
Ну ОК, нельзя так нельзя.
Версия ротозумера под режим 16 цветов/точку. Она получилась медленнее, но все же не в 4, а в 2 раза, чем версия (http://zx-pk.ru/threads/24285-orion-pro-softvernye-dela.html?p=879104&viewfull=1#post879104) для атрибутного режима, на реале 6 FPS должна выдать.
OrionExt
26.07.2016, 02:04
С методами программирования по портам Орион-Про не взлетит.
Это какое-то зх-спектрумский подход к делу. Все по железу:(
- - - Добавлено - - -
Зачем мне нужно под каждую хотелку код программы переделывать?)
Дополнение к тесту быстродействия (http://zx-pk.ru/threads/24285-orion-pro-softvernye-dela.html?p=845379&viewfull=1#post845379). Дмитрий прогнал тест еще и в режиме 5 МГц. В этом режиме все просто - каждое обращение к памяти или порту +1 такт.
Пара слов про ВИ53 - раньше у Дмитрия была установлена советская микросхема, она при включенной турбе нестабильно программировалась и читалась. Теперь он заменил на зарубежный аналог и стало возможно работать с таймером не выключая турбу.
Пара слов про ВИ53 - раньше у Дмитрия была установлена советская микросхема, она при включенной турбе нестабильно программировалась и читалась.
Есть такая фигня. Я у себя в коде решил вопрос так.
Вместо простого и логичного обращения: OUT PT_TM1
Пишу так:
CALL Sv8253
...
Sv8253:
OUT PT_TM1
RET
На первый взгляд какая-то фигня :) На самом деле исполнение "лишних" команд CALL/RET вносит достаточную задержку между обращениями к таймеру и он надёжно программируется.
Error404
26.07.2016, 10:12
С методами программирования по портам Орион-Про не взлетит.
Это какое-то зх-спектрумский подход к делу. Все по железу:(
- - - Добавлено - - -
Зачем мне нужно под каждую хотелку код программы переделывать?)
Там проблема в быстродействии что по-другому не получается.
По сути, работа с портами допустима (конечно, при этом программа сразу из разряда классических проваливается в "демы"), но нужен некий софтверный БИОС, который определяет возможен или не возможен доступ к порту или какому-то участку памяти в данном инстансе ОС (т.е. по факту на данном клоне).
Чтобы пользовательсяка программа перед тем как лезть по железке в ОЗУ элементарно проверила - а не занято ли уже это ОЗУ каким-то другим процессом, как уже выставлены порты (чтобы не порушить чего или "неожиданно" не сесть на область перекрытую диспетчером). Чтобы не как сейчас оно пропиливало "наудачу" и после проигрывания вешалось. Я например об этом подумал сразу как начал писать многостраничные программы (и для этого сделал соответствующие механизмы в ОС). К сожалению, делалалось это еще в 95г., когда в наших деревнях был информационный вакуум, и хотя я все сделал довольно удобно (например, когда я уже в 2015 стал портировать Юзикс, а это очень большой проект полностью утилизирующий все ресурсы Ориона128 до последнего байта и такта, все очень удачно легло на те архитектурные решения). Но получилось это несовместимо с например CPM3 (где тоже есть программные обвязки для маппера памяти). И нет там никаких проблем с портами, порт FB например используется только один раз при старте для включения прерываний (как и на ПРО, только на ПРО его программируют неграмотно - не учитывая что в порту FB на "классике" есть еще функции). Благодаря этому, ОС работает даже на плате Z80 от Орион-Сервиса (тот убогий вариант где вместо прерываний эмулируется звук по ei/di и 8-битные порты), и на ПРО чтобы ее запустить мне было достаточно только в экранном драйвере (т.е. даже не в самом когде ОС) тупо переключать при запуске в
режим "Орион-128", ну и пара коррекций для прерываний (которые авторы могли сделеать совместимо с лениградцами, но таки не сделали ибо "сделано не нами").
- - - Добавлено - - -
На первый взгляд какая-то фигня :) На самом деле исполнение "лишних" команд CALL/RET вносит достаточную задержку между обращениями к таймеру и он надёжно программируется.
Странно все это. Как и неуспевающий контроллер клавиатуры. Ведь именно чтобы этого не было (насколько я понял мысл создателей) на ПРО они и сделали узел на D87, формирующий /WAIT при IORQ (ну и до кучи и при MREQ). ТМ8 там последовательно переписывает из одного триггера в другой, и смотря сколько триггеров в цепочке получается разная длительность /WAIT, причем для портов и для памяти эта длительность отличается, и еще есть свободный триггер, т.е. можно попробовать как удлиннить так и укоротить /WAIT.
Для себя я подумываю вообще выкинуть /WAIT для портов, и ставить быстрые импортные чипы. Ибо к примеру скорость программного IDE на ВВ55 (который у меня первое время будет за основного) прямо зависит, и не хочется ее снижать.
Странно все это. Как и неуспевающий контроллер клавиатуры. Ведь именно чтобы этого не было (насколько я понял мысл создателей) на ПРО они и сделали узел на D87, формирующий /WAIT при IORQ (ну и до кучи и при MREQ). ТМ8 там последовательно переписывает из одного триггера в другой, и смотря сколько триггеров в цепочке получается разная длительность /WAIT, причем для портов и для памяти эта длительность отличается
Тем не менее. Самое смешное, что даже на Орионе-128 с ВМ80А и клоком 2,5 МГц те же самые проблемы с программированием ВИ53, просто они проявляются черезвычайно редко. В итоге пришлось и в ПО для О-128 делать аналогичные задержки.
К примеру, такой код:
MVI A,12
STA PT_TM1
XRA A; здесь нужен 0 и для сокращения кода обнуление сделано одной командой
STA PT_TM1
нифига не работает с ВИ53, даже на О-128@2,5МГц. Видимо, слишком быстро прилетает второй конфигурационный байт,
а ВИ53 ещё первый не "скушала".
А вот это уже работает (но в ~99% случаев):
MVI A,12
STA PT_TM1
MVI A,0
STA PT_TM1
И только через CALL/RET работает 100%
Для себя я подумываю вообще выкинуть /WAIT для портов, и ставить быстрые импортные чипы. Ибо к примеру скорость программного IDE на ВВ55 (который у меня первое время будет за основного) прямо зависит, и не хочется ее снижать.
У такого решения есть минус - написанное и отлаженное ПО вероятно будет криво работать у других юзеров со стандартной платформой /-)
Если выкидывание WAIT'ов при обращении к портам даёт катастрофический прирост скорости, то это конечно может быть оправдано, но тогда придётся писать транспаранты крупными буквами, что для работы с ПО требуется доработка. А лучше делать автодетект имеющегося оборудования и подстраиваться программно, но это не всегда возможно (
OrionExt
26.07.2016, 12:50
По сути, работа с портами допустима (конечно, при этом программа сразу из разряда классических проваливается в "демы"), но нужен некий софтверный БИОС, который определяет возможен или не возможен доступ к порту или какому-то участку памяти в данном инстансе ОС (т.е. по факту на данном клоне).
Чтобы пользовательсяка программа перед тем как лезть по железке в ОЗУ элементарно проверила - а не занято ли уже это ОЗУ каким-то другим процессом, как уже выставлены порты (чтобы не порушить чего или "неожиданно" не сесть на область перекрытую диспетчером). Чтобы не как сейчас оно пропиливало "наудачу" и после проигрывания вешалось.
Вот и я об этом хотел сказать.
Для себя я подумываю вообще выкинуть /WAIT для портов, и ставить быстрые импортные чипы. Ибо к примеру скорость программного IDE на ВВ55 (который у меня первое время будет за основного) прямо зависит, и не хочется ее снижать.
Желание увеличивать быстродействие всегда прямо пропорционально существующему быстродействию. Как говорится, аппетит растет во время еды. А кто потом будет гарантировать совместимость старого ПО с новым "турбо" режимом. Это какой-то неправильный путь развития.
Дорабатывать схему имеет смысл, если для этой доработки существует весомый багаж ПО. Пример порт FB.
Error404
26.07.2016, 12:58
Если выкидывание WAIT'ов при обращении к портам даёт катастрофический прирост скорости, то это конечно может быть оправдано, но тогда придётся писать транспаранты крупными буквами, что для работы с ПО требуется доработка. А лучше делать автодетект имеющегося оборудования и подстраиваться программно, но это не всегда возможно (
Там при чтении сектора цикл, в котором на чтение каждого байта с IDE приходится сделать до полдюжины обращений в ВВ55. Соответственно, думаю исключение вейтов улучшит общие показатели на 15-20% . Понятно, что проверить надо будет работу в обоих режимах (вынести джампер который вейты как включает, так и выключает), на клавиатуру вейты оставить независимо ни от чего. Но в целом, программно реализованный IDE (хоть на регистрах авторского контроллера по аналогии с NemoIDE, хоть на ВВ55 где просто больше команд надо на чтение и соответственно медленнее общая скорость) и так уже зависит от частот процессора. На Орионе-128 нормально работало и на на частоте 2,5, и на 5+wait. Так что, прогноз благоприятный.
Дорабатывать схему имеет смысл, если для этой доработки существует весомый багаж ПО.
Или, как вариант, предполагается самостоятельное написание ПО под свои личные нужды, без оглядки на совместимость ;)
- - - Добавлено - - -
думаю исключение вейтов улучшит общие показатели на 15-20% .
Имхо, эти цифры не стоят того. Я бы подумал в сторону изобретения новой железки, которая увеличит скорость в разы ;)
Пусть даже это будет примочка на МК, и пёс с ней, с "религией"!
OrionExt
26.07.2016, 13:10
Добавлю.
На примере платформы MSX, по идеологии среди 8-биток она наиболее приближена к «правильному» подходу к аппаратным расширением, методами написания ПО.
За все это время там никто не решился убирать аппаратные костыли того времени. Ну, разве что в частном порядке, в виде эксперимента. И это правильно. Меня как пользователя, прежде всего, интересует работа ПО, подключение аппаратных расширений. Все должно работать из коробки.
За все это время там никто не решился убирать аппаратные костыли того времени.
Тут ещё дело в "масштабах бедствия". Юзеров MSX (причём "тогда", т.к. я понял речь про время, когда платформа была на пике актуальности) было чуть менее, чем дофига, в связи с этим что-то менять и т.о. "кидать" кучу народу было бы действительно дико.
У нас же сейчас, как я понимаю, ситуация примерно следующая: юзеров Ориона примерно "полтора" человека, причём далеко не самых ленивых :) Т.е. фактически можно лепить стандарты прямо на ходу, сильно никто не пострадает :)
П.С. но лично я всё же до последнего придерживаюсь консервативной позиции, и новые аппаратные решения приветствую только в случае очевидной нужды.
Error404
26.07.2016, 13:37
А кто потом будет гарантировать совместимость старого ПО с новым "турбо" режимом. Это какой-то неправильный путь развития.
Дорабатывать схему имеет смысл, если для этой доработки существует весомый багаж ПО. Пример порт FB.
это не тот случай, где есть или нет какая-то совместимость или несовместимость. ПО никак же не меняется, и железка меняется тупо добавлением джампера "wait/nowait".
Ближайший аналог - это уже существующий как на 128 так и на ПРО джампер верхней чатоты процессора (тот самый "турбо"). Тупо ставишь и смотришь - если работает, то замечательно, если не работает (например, верхнюю частоту не тянет проц) - просто верни джампер в нижний режим, тебе не повезло. :) как то так.
- - - Добавлено - - -
Имхо, эти цифры не стоят того. Я бы подумал в сторону изобретения новой железки, которая увеличит скорость в разы ;)
Пусть даже это будет примочка на МК, и пёс с ней, с "религией"!
Ну, одно другого же никак не отменяет. Первое - совсем малой кровью на первое время, оно просто уже есть. Второе еще надо сделать, и когда оно будет, поставил в слот и пусть работает.
исполнение "лишних" команд CALL/RET вносит достаточную задержку между обращениями к таймеру и он надёжно программируется.
А я просто выключал турбу, писал/читал таймер, включал турбу. На про Дмитрия это работало. А с импортным 8253 можно и турбу не выключать.
Error404
26.07.2016, 17:55
Оффтоп, но раз заходила речь про большие файлы и hdd. Пользуюсь OdiWcx - работает отлично, а вот OhiWcx работет довольно странно. Файлы больше определенного размера (в районе 32 Кб) портит. Записывал большие файлы на образ hdd из под альтаира - так ошибок нет, но очень медленно и неудобно.
Да, я знаю про этот глюк. Глюк проявляется только на файловых системах CP/M размеченных с размером группы в 16кб (это максимум возможный для CP/M).......
Просто пока этим пользовался я один, трассировать и ловить баг не было стимула (есть поинтереснее чего попрограммить), я тупо пользовал разделы со старых образов. Теперь обещаю исправиться и баг изловить и изничтожить. :)
Поправил плагины - убрал вышеописанный глюк (новые файлы во вложении). Новых глюков вроде не наделал, но тестил мало, так что пишите если чего всплывет.
Ошибка была, как я и предполагал, в odi.wcx (там вся логика), но попутно немного поправил и ohi.wcx (функционально и косметически), так что заменить надо обе wcx.
- - - Добавлено - - -
В следующем приступе программистического энтузиазма сделаю поддержку файловых операций в партициях UZIX, тоже давно хочу, но как-то все руки не доходят: лень сильнее. :)
Спасибо за работу над плагином, но пока совсем хорошо не стало. Файл в 55 Кб теперь скопировал в .ohi нормально, а вот файлы 130 и 256 Кб обрезал
Black Cat / Era CG
27.07.2016, 13:49
o32
А расскажите про формат. Что там внутри?
Error404
27.07.2016, 14:19
Спасибо за работу над плагином, но пока совсем хорошо не стало. Файл в 55 Кб теперь скопировал в .ohi нормально, а вот файлы 130 и 256 Кб обрезал
Тогда, дубль два. Нашел еще один недочет в odi.wcx (заменяя его, надо прибивать и odi.wcx0,1,2,3).
Попробуй пожалуйста вот эту версию (во вложении).
Сегодня проверялся на файле размером 670кб (книга, txt), плагин в итоге нормально стал ее копировать в обе стороны, а вот в эмуляторе в CPM2.2 почитать из нее дает только первые 512кб. :) Похоже в BDOS CPM 2.2 где-то или в разрядность счетчиков упирается, или тупо где-то там есть баг (т.к. из описания тех. характеристик ФС CP/M я не припоминаю ограничения на файл в 512кб, возможно это глюк того реализа, который размножился по миру как версия 2.2 - фактическое ограничение в силу бага).
А я просто выключал турбу, писал/читал таймер, включал турбу.
Мне приходится на два фронта работать (О-128 и О-ПРО), поэтому проще и логичнее по возможности использовать универсальное решение проблемы для обеих платформ.
П.С. "писал/читал таймер, включал турбу" - а если комп уже по каким-то причинам работает не в турбе? ;)
Error404, этот вариант работает хорошо, так и с ohi стало можно работать.
Насчет 512 Кб - пробовал старые векторовские cp/mы, орионовские - в них это ограничение есть. В новых векторовских досах это ограничение, насколько могу судить, убрали, по крайней мере в рамках дискеты файлы можно не разбивать.
Black Cat / Era CG, мне было лень разбираться в своих старых исходниках вывода bmp на экран вектора и пошел легким путем - палитра+картинка по плоскостям. Не думаю, что где-то еще стоит делать поддержку такого формата.
Denn, причина проблем, как я понимаю, в том, что обычные ВИ53 были официально рассчитаны максимум на 2 МГц, а в орионах работали/работают на 2,5. Некоторые экземпляры это переносят, некоторые нет. 2,5 официально поддерживает ВИ53Д.
Насчет того как бороться - вряд ли буду использовать таймер на про в других программах (кроме теста быстродействия). Если придется - может сделаю "тормозное" обращение к таймеру. Но имхо в идеале на про нужно использовать микросхемы стабильно работающие даже в турбе, не говоря уже про 2,5 МГц.
вряд ли буду использовать таймер на про в других программах (кроме теста быстродействия)
Чёрт возьми, спасибо за идею! Как же я не додумался-то... точно, ведь это же таймер!
Error404
27.07.2016, 18:40
Error404, этот вариант работает хорошо, так и с ohi стало можно работать.
Насчет 512 Кб - пробовал старые векторовские cp/mы, орионовские - в них это ограничение есть. В новых векторовских досах это ограничение, насколько могу судить, убрали, по крайней мере в рамках дискеты файлы можно не разбивать.
Это таки "фича" BDOS CP/M 2.2 - ограничение в 512кб для последовательного чтения/записи, по крайней мере об этом знали и на прочих непатченных клонах CP/M 2.2. Вот например это обсуждают для AppleII (с платой Z80 и CP/M2.2):
http://www.verycomputer.com/74_3c7b339c31ec863b_1.htm
В более поздних CP/M это скорее всего исправили (что могли унаследовать и векторовские поздние Микродос-ы).
Искать этот баг дизассемблером я вряд ли буду, но в статье (а точнее переписке) по ссылке выше народ считает, что эта "фича" ограничивает только последовательное чтение (функция 014h BDOS), а функциями произвольного чтения (21h) типа должна читать и сверх 512кб т.к. разрядность номера записи - позволяет, а неправильно написанная процедура проверки переполнения экстента в этом случае не влияет. Т.е. можно было бы плагином записать нерезанные WAV-ы, а в проигрывателе для чтения использовать ф-ю произвольного чтения, просто номера секторов (а их для этой функции придется явно указывать в FCB файла) увеличивать последовательно. :) И работать это должно на всех версиях CP/M 2.х и выше (поддерживающих произвольный доступ)
- - - Добавлено - - -
Насчет того как бороться - вряд ли буду использовать таймер на про в других программах (кроме теста быстродействия). Если придется - может сделаю "тормозное" обращение к таймеру. Но имхо в идеале на про нужно использовать микросхемы стабильно работающие даже в турбе, не говоря уже про 2,5 МГц.
Наверное этот способ хорош для компа на 8080 где нет прерываний. Где прерывания есть (8080 или Z80) ИМХО для вычисления быстродействия удобно посчитать количество инструкций выполнившихся между двумя соседними "приходами" прерываний регулярного таймера (в Орионе это таймер кадрового бланка - 50Гц)
Где прерывания есть (8080 или Z80) ИМХО для вычисления быстродействия удобно посчитать количество инструкций выполнившихся между двумя соседними "приходами" прерываний регулярного таймера (в Орионе это таймер кадрового бланка - 50Гц)
Тогда сперва встаёт задача определить, есть ли на данной платформе прерывания или нет :)
OrionExt
27.07.2016, 23:45
Это таки "фича" BDOS CP/M 2.2 - ограничение в 512кб для последовательного чтения/записи, по крайней мере об этом знали и на прочих непатченных клонах CP/M 2.2. Вот например это обсуждают для AppleII (с платой Z80 и CP/M2.2):
Вот. Я тему поднял (вот и аукнулось у других). Когда хотел за раз образ диска записать 800К)
Сорцы то открыты СПМ2.2, зачем их дизассемблировать?
Дальше ничего не понял. Подпрограмма (разрядность вх. параметров), позволяет читать более 512КБ?
- - - Добавлено - - -
Только сейчас дошло. А зачем последовательно вычитывать в память овер дохрена. В буфер. Скинули. И сначала. Это какой-то экстрим. Го 8 Гбайт за раз читать:v2_eek:
- - - Добавлено - - -
А с макс размером файла х.з. Надо читать. Пока я тут не видел пруфоф на документацию .
- - - Добавлено - - -
Тогда сперва встаёт задача определить, есть ли на данной платформе прерывания или нет :)
Вы какие-то максим планки берете. Хоть Ось (ПРО-ДОС), тут нормально работает?
Error404
27.07.2016, 23:55
Сорцы то открыты СПМ2.2, зачем их дизассемблировать?
Сорцы Килдалла - на PLI (это язык подремучее фортрана-77), одно дело в тех сорцах разбираться глаза сломаешь, другое - что уже и скомпилировать это хрен знает чем (даже если найдешь чего править). А ассемблерное всеми получалось дизасмом, понятно какая там степень комментирования и вообще читаемости. Самое правильное - разобраться в ассемблерном, я примерно сегодня уже нашел где, но с наскока не выйдет, надо вникать.
Дальше ничего не понял. Подпрограмма (разрядность вх. параметров), позволяет читать более 512КБ?
Программа в которой ограничение до 512кб - там вообще только один параметр: имя файла (открываешь его по имени, затем read_next-read_next-read_next-.....until_eof). Только вот EOF подпрограмма read_next в непатченной 2.2 возвращает не по концу файла (большого), а по границе в 512кб.
А с макс размером файла х.з. Надо читать. Пока я тут не видел пруфоф на документацию .
Макс. размер файла 32мб, макс. размер файловой системы - 512мб. Там есть ньюансы (чем больше ФС, тем больше под нее нужно места в ОЗУ под хранение битовой карты занятых блоков), но если есть вагон ОЗУ которого под это не жалко - все возможно.
OrionExt
28.07.2016, 00:25
Сорцы Килдалла - на PLI (это язык подремучее фортрана-77), одно дело в тех сорцах разбираться глаза сломаешь, другое - что уже и скомпилировать это хрен знает чем (даже если найдешь чего править). А ассемблерное всеми получалось дизасмом, понятно какая там степень комментирования и вообще читаемости. Самое правильное - разобраться в ассемблерном, я примерно сегодня уже нашел где, но с наскока не выйдет, надо вникать.
На PLI утилиты писали. А СПМ десятки Source файлов. Завтра найду. Хоть в сети, хоть у мя.
- - - Добавлено - - -
Недавно собрал под TASM СПП, БДОС ( как мя достали эти ассемблеры со своей лексикой). Отличия в 10 байт. Для Орион-128.
Наверное этот способ хорош для компа на 8080 где нет прерываний. Где прерывания есть (8080 или Z80) ИМХО для вычисления быстродействия удобно посчитать количество инструкций выполнившихся между двумя соседними "приходами" прерываний регулярного таймера (в Орионе это таймер кадрового бланка - 50Гц)
У меня две линейки тестов быстродействия - с использованием кадровых прерываний и с использованием таймера. Таймерные варианты лучше (работают быстрее, шире диапазон измерения), просто таймер не на всех компах есть.
Error404
28.07.2016, 11:55
На PLI утилиты писали. А СПМ десятки Source файлов. Завтра найду. Хоть в сети, хоть у мя.
DRI (https://en.wikipedia.org/wiki/Digital_Research) писали на PLI - и ОС (включая V3 и MPM) и утилиты, пускай и кой-где с ассемблерными вставками, вот тут исходники их есть:
http://www.cpm.z80.de/source.html
Все полностью ассемблерные варианты - это декомпиленные версии, в том что они компилируются в код значительно совпадающий с классическим BDOS включая его баги - ничего удивительного в этом нет, любую программу можно декомпилировать, затем компильнуть и оно будет совпадать.
Недавно собрал под TASM СПП, БДОС ( как мя достали эти ассемблеры со своей лексикой). Отличия в 10 байт. Для Орион-128.
А с каким дистрибутивом Ориона сравнивалось?
в статье (а точнее переписке) по ссылке выше народ считает, что эта "фича" ограничивает только последовательное чтение (функция 014h BDOS), а функциями произвольного чтения (21h) типа должна читать и сверх 512кб т.к. разрядность номера записи - позволяет, а неправильно написанная процедура проверки переполнения экстента в этом случае не влияет
Попробовал в одном из "старых" векторовских cp/mов заменить в чтении 14h на 21h - это не решает проблему, все равно читает 512 Кб и выдает код 04h Reading unwritten extent (a 16k portion of file does not exist).
OrionExt
28.07.2016, 17:40
А с каким дистрибутивом Ориона сравнивалось?
OS-DOS48 V2.31 200492
Error404
28.07.2016, 18:25
Попробовал в одном из "старых" векторовских cp/mов заменить в чтении 14h на 21h - это не решает проблему, все равно читает 512 Кб и выдает код 04h Reading unwritten extent (a 16k portion of file does not exist).
Странно, в исходнике оно при режиме прямого позиционирования вроде обходит проверку (где-то попадалось на глаза). Возможно не все проверки обходит, конечно, т.к. мои примерчики через прямое позиционирование что-то тоже не отработали.
Попробовал сегодня "бомбануть наудачу" и увеличил (прям виндой - в образе, HEX-редактором) в процедурах послед. чтения маску обслуживаемых экстентов на пару бит (т.е. в 4 раза), в итоге текстовый файл размером 670кб последовательным чтением (фукция BDOS 14h) после этих правок прочитался до конца (чего раньше не происходило, обламывалось на 512кб). Непонятно - нафига оно вообще сделано???
Так что можно попробовать плеером с последовательным чтением (т.е. тем что был ранее как я понимаю) проигрывание более крупных (чем 512кб) WAV - а вдруг на поправленной ОС проканает?
Запись больших файлов не проверял: смысл это делать есть только в эмуляторе (плагин то понятно пишет и читает - ему на баги старых CPM пофиг), но терпения уже нету ждать пока оно разродится. :)
Поправленный образ тут (для экспериментов, грузиться с него без каких-либо изменения в образе, пробовал эмулятором как Орионом-128, так и Орионом-ПРО):
https://drive.google.com/file/d/0B3S0wVWNPLrwSkhURThVeVk0WEE/view?usp=sharing
Итого поменяны 3 ячейки (адреса от начала образа, т.е. считая и MBR), не помню после какой из этих правок заработало:
132AH : 1F->7F
157CH : 1F->7F
1597H : 0F->03
Вот как оно выглядит в исходнике:
;
; Check extents in (A) and (C). Set the zero flag if they
; are the same. The number of 16k chunks of disk space that
; the directory extent covers is expressad is (EXTMASK+1).
; No registers are modified.
;
SAMEXT: PUSH BC
PUSH AF
LD A,(EXTMASK) ;get extent mask and use it to
CPL ;to compare both extent numbers.
LD B,A ;save resulting mask here.
LD A,C ;mask first extent and save in (C).
AND B
LD C,A
POP AF ;now mask second extent and compare
AND B ;with the first one.
SUB C
AND 1FH ;(* only check buts 0-4 *) <--- 132AH
POP BC ;the zero flag is set if they are the same.
RET ;restore (BC) and return.
;
;
; Routine to close the current extent and open the next one
; for reading.
;
GETNEXT:XOR A
LD (CLOSEFLG),A ;clear close flag.
CALL CLOSEIT ;close this extent.
CALL CKFILPOS
RET Z ;not there???
LD HL,(PARAMS) ;get extent byte.
LD BC,12
ADD HL,BC
LD A,(HL) ;and increment it.
INC A
AND 1FH ;keep within range 0-31. <--- 157CH
LD (HL),A
JP Z,GTNEXT1 ;overflow?
LD B,A ;mask extent byte.
LD A,(EXTMASK)
AND B
LD HL,CLOSEFLG ;check close flag (0ffh is ok).
AND (HL)
JP Z,GTNEXT2 ;if zero, we must read in next extent.
JP GTNEXT3 ;else, it is already in memory.
GTNEXT1:LD BC,2 ;Point to the 's2' byte.
ADD HL,BC
INC (HL) ;and bump it.
LD A,(HL) ;too many extents?
AND 0FH ; <--- 1597H
JP Z,GTNEXT5 ;yes, set error code.
;
; Get here to open the next extent.
;
GTNEXT2:LD C,15 ;set to check first 15 bytes of fcb.
CALL FINDFST ;find the first one.
CALL CKFILPOS ;none available?
JP NZ,GTNEXT3
LD A,(RDWRTFLG) ;no extent present. Can we open an empty one?
INC A ;0ffh means reading (so not possible).
JP Z,GTNEXT5 ;or an error.
CALL GETEMPTY ;we are writing, get an empty entry.
CALL CKFILPOS ;none?
JP Z,GTNEXT5 ;error if true.
JP GTNEXT4 ;else we are almost done.
GTNEXT3:CALL OPENIT1 ;open this extent.
GTNEXT4:CALL STRDATA ;move in updated data (rec #, extent #, etc.)
XOR A ;clear status and return.
JP SETSTAT
;
; Error in extending the file. Too many extents were needed
; or not enough space on the disk.
;
GTNEXT5:CALL IOERR1 ;set error code, clear bit 7 of 's2'
JP SETS2B7 ;so this is not written on a close.
;
; Read a sequential file.
;
RDSEQ: LD A,1 ;set sequential access mode.
LD (MODE),A
RDSEQ1: LD A,0FFH ;don't allow reading unwritten space.
LD (RDWRTFLG),A
CALL STRDATA ;put rec# and ext# into fcb.
LD A,(SAVNREC) ;get next record to read.
LD HL,SAVNXT ;get number of records in extent.
CP (HL) ;within this extent?
JP C,RDSEQ2
CP 128 ;no. Is this extent fully used?
JP NZ,RDSEQ3 ;no. End-of-file.
CALL GETNEXT ;yes, open the next one.
XOR A ;reset next record to read.
LD (SAVNREC),A
LD A,(STATUS) ;check on open, successful?
OR A
JP NZ,RDSEQ3 ;no, error.
RDSEQ2: CALL COMBLK ;ok. compute block number to read.
CALL CHKBLK ;check it. Within bounds?
JP Z,RDSEQ3 ;no, error.
CALL LOGICAL ;convert (BLKNMBR) to logical sector (128 byte).
CALL TRKSEC1 ;set the track and sector for this block #.
CALL DOREAD ;and read it.
JP SETNREC ;and set the next record to be accessed.
;
; Read error occured. Set status and return.
;
RDSEQ3: JP IOERR1
;
Во вложении исходники CP/M (ассемблерные, т.е. декомпилированные, но декомпилировавший проделал гигантский труд по комментированию, весьма подробному), те фрагменты что я смотрел, с BDOS от Альтаир-ДОС совпадали (по крайне мере в части файловых операций).
Интересно, "пропатчил" рамдисковый проигрыватель и он в этом альтаире с использованием 14h прочитал весь файл 676Кб (c 21h не весь).
Error404
29.07.2016, 16:11
Интересно, "пропатчил" рамдисковый проигрыватель и он в этом альтаире с использованием 14h прочитал весь файл 676Кб (c 21h не весь).
Да, в этом и вопрос: зачем авторы BDOS изначально сделали искусственное ограничение - переполнение счетчика экстентов файла не по заполнению всего байта (что даже и проверяется проще - тупо во флаге переполнения), а ограничили пятью битами? Я для перестраховки (и простоты патча) только до семи бит расширил - чтобы не трогать статус флага переполнения CY (и мало ли может где в другом месте они в старшем бите что-нить смотрят). Этот "странный" алгоритм как мне кажется возник вследствие того, что BDOS изначально писан на языке высокого уровня, причем языке достаточно абстрактном и при этом не особенно наглядном (в отличие от, к примеру, С).
Я так понимаю, эти куски абсолюно одинаковые во всех реализациях BDOS от 2.2, и их тупо по сигнатурам можно найти (как я и искал в альтаировском варианте) и попробовать поправить например в векторовских реализациях где есть ограничение в 512кб.
На счет неработающей 21h: таки да, похоже тоже надо патчить - надо тоже посмотреть в исходнике как оно там реализовано (сразу не полез, не люблю разбираться в битовых операциях на сдвигах, а их там есть).
- - - Добавлено - - -
Интересно, "пропатчил" рамдисковый проигрыватель и он в этом альтаире с использованием 14h прочитал весь файл 676Кб (c 21h не весь).
В-общем, еще слазил я в проверки, которые делает ф. 21h. Образ диска с "ручными правками по живому" тут:
https://drive.google.com/file/d/0B3S0wVWNPLrwUEtYTUNWR3J0Y0U/view?usp=sharing
Вот что поменял чтобы и при произвольном доступе была маска количества экстентов 7 бит вместо 5 (т.е. макс. размер файла 2мб вместо 512кб):
поменял такие ячейки (адреса от начала образа, т.е. считая и MBR):
172CH : 1F -> 7F
172FH : 1F 1F 1F 1F E6 0F -> 07 07 00 00 E6 03
Вот как оно выглядит в исходнике:
;
; For random i/o, set the fcb for the desired record number
; based on the 'r0,r1,r2' bytes. These bytes in the fcb are
; used as follows:
;
; fcb+35 fcb+34 fcb+33
; | 'r-2' | 'r-1' | 'r-0' |
; |7 0 | 7 0 | 7 0|
; |0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0|
; | overflow | | extra | extent | record # |
; | ______________| |_extent|__number___|_____________|
; also 's2'
;
; extent -> расширяем на 2 бита (до 7 бит), extra -> соответственно уменьшаем с 4 до 2 бит.
;
; On entry, register (C) contains 0ffh if this is a read
; and thus we can not access unwritten disk space. Otherwise,
; another extent will be opened (for writing) if required.
;
POSITION: XOR A ;set random i/o flag.
LD (MODE),A
;
; Special entry (function #40). M/PM ?
;
POSITN1:PUSH BC ;save read/write flag.
LD HL,(PARAMS) ;get address of fcb.
EX DE,HL
LD HL,33 ;now get byte 'r0'.
ADD HL,DE
LD A,(HL)
AND 7FH ;keep bits 0-6 for the record number to access.
PUSH AF
LD A,(HL) ;now get bit 7 of 'r0' and bits 0-3 of 'r1'.
RLA
INC HL
LD A,(HL)
RLA
AND 1FH ;and save this in bits 0-4 of (C). <---- 172Ch : 1F -> 7F
LD C,A ;this is the extent byte.
LD A,(HL) ;now get the extra extent byte.
RRA ; RLCA <---- 172Fh
RRA ; RLCA
RRA ; NOP
RRA ; NOP
AND 0FH ; AND 3
LD B,A ;and save it in (B).
POP AF ;get record number back to (A).
INC HL ;check overflow byte 'r2'.
LD L,(HL)
INC L
DEC L
LD L,6 ;prepare for error.
JP NZ,POSITN5 ;out of disk space error.
LD HL,32 ;store record number into fcb.
ADD HL,DE
LD (HL),A
LD HL,12 ;and now check the extent byte.
ADD HL,DE
LD A,C
SUB (HL) ;same extent as before?
JP NZ,POSITN2
LD HL,14 ;yes, check extra extent byte 's2' also.
ADD HL,DE
LD A,B
SUB (HL)
AND 7FH
JP Z,POSITN3 ;same, we are almost done then.
;
; Get here when another extent is required.
;
Теперь наконец то я смог выполнить (ранее DED.COM обламывался с чтением файла на границе в 512кб) то, о чем ранее упоминал на вопрос от OrionExt "как залить образ не имея на РС дисковода":
на IDE диск (CF,SD) скидываем образ дискетки (800кб) и за одно действие посекторно копируем его целиком на дискетку (дискетка должна быть заранее форматирована на Орионе же, желательно на 80+ треков {форматерами SF.COM, F83.COM, и т.п.}, содержимое ее 80 первых треков затем перезаписывается из файла c более емкого CP/M-диска, например IDE, где лежит образ дискетки для заливки). Залил Орионом утилитой DED.COM образ с IDE на гибкий диск (эмулятором естественно), затем проверил под виндой подопытный образ диска с образцовым - совпало. :) А раньше не работало, т.к. DED читает при помощи ф.21h (так делалось для копирования файла в треки в случае единственного привода на всю система (дисковода) - меняя диски ручками, т.е. в древнючие времена для небогатых парней: DED умеет "вставьте источник"-"вставьте приемник", а когда дело идет на двух приводах, понятно, ничего не спрашивает, но по-прежнему читает файл-источник через ф.21h)
Образ диска с "ручными правками по живому" тут:
Это я пока не пробовал, а в предыдущем варианте выявились некая особенность поведения с hdd. Проблема выглядит примерно так: если записать на hdd подряд несколько больших файлов, то с некоторого момента (возможно если их суммарный объем превысит 2 Мб) вместо последних записанные файлов (которые могут быть хоть маленькие, хоть большие) дос читает нечто левое (похоже на фрагмент программы). Проблема именно в досе, плагин обратно из образа копирует все файлы правильно. С дискетой проблем нет, все равно туда только один "большой" файл влезает.
OrionExt
29.07.2016, 17:39
Круть. К осени я подключусь. Как фулл Орион соберу. Забодаем СР/М 2.2=)
Error404
29.07.2016, 19:31
Это я пока не пробовал, а в предыдущем варианте выявились некая особенность поведения с hdd. Проблема выглядит примерно так: если записать на hdd подряд несколько больших файлов, то с некоторого момента (возможно если их суммарный объем превысит 2 Мб) вместо последних записанные файлов (которые могут быть хоть маленькие, хоть большие) дос читает нечто левое (похоже на фрагмент программы). Проблема именно в досе, плагин обратно из образа копирует все файлы правильно. С дискетой проблем нет, все равно туда только один "большой" файл влезает.
Да, есть такой эффект. Закинул сейчас на диск 4 файла по 650кб, первые три читаются нормально, а четвертый - "улетает". Трудно сказать почему.
Вообще, там еще процедуру COMPRAND надо пропатчить (сегодня просматривал и увидел что там тоже ковыряния с номерами экстентов), но вроде оно на последовательное чтение не должно влиять. Впрочем не поручусь, накручено там много, и лишнего в том числе, все взаимодействия не угадаешь - надо пропатчить COMPRAND, и посмотреть - поможет ли это.
OrionExt
29.07.2016, 19:47
Жуть. Во дело пошло. Я вас подбадриваю). Мне в сентябре нечего будет делать.
HardWareMan
29.07.2016, 20:10
На вид явный заворот адреса. Это как слет LBA48 на дисках более 120ГБ под XP до SP1/SP2. Слет на LBA32 херил все на диске по причине затирания начала при завороте адресов. В вашем случае, это можно попробовать определить, загрузив файлы с определенным содержимым (текстом) и посмотреть что выведет ДОС при глюке.
Да, в этом и вопрос: зачем авторы BDOS изначально сделали искусственное ограничение - переполнение счетчика экстентов файла не по заполнению всего байта
Видимо, для обратной совместимости. Почитай на досуге вот это: http://www.seasip.info/Cpm/format22.html
The CP/M 2.2 directory has only one type of entry:
UU F1 F2 F3 F4 F5 F6 F7 F8 T1 T2 T3 EX S1 S2 RC .FILENAMETYP....
AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL ................
UU = User number. 0-15 (on some systems, 0-31). The user number allows multiple
files of the same name to coexist on the disc.
User number = 0E5h => File deleted
Fn - filename
Tn - filetype. The characters used for these are 7-bit ASCII.
The top bit of T1 (often referred to as T1') is set if the file is
read-only.
T2' is set if the file is a system file (this corresponds to "hidden" on
other systems).
EX = Extent counter, low byte - takes values from 0-31
S2 = Extent counter, high byte.
An extent is the portion of a file controlled by one directory entry.
If a file takes up more blocks than can be listed in one directory entry,
it is given multiple entries, distinguished by their EX and S2 bytes. The
formula is: Entry number = ((32*S2)+EX) / (exm+1) where exm is the
extent mask value from the Disc Parameter Block.
S1 - reserved, set to 0.
RC - Number of records (1 record=128 bytes) used in this extent, low byte.
The total number of records used in this extent is
(EX & exm) * 128 + RC
If RC is 80h, this extent is full and there may be another one on the disc.
File lengths are only saved to the nearest 128 bytes.
AL - Allocation. Each AL is the number of a block on the disc. If an AL
number is zero, that section of the file has no storage allocated to it
(ie it does not exist). For example, a 3k file might have allocation
5,6,8,0,0.... - the first 1k is in block 5, the second in block 6, the
third in block 8.
AL numbers can either be 8-bit (if there are fewer than 256 blocks on the
disc) or 16-bit (stored low byte first).
Кстати, ограничение в 512кБ было в CP/M 1.4, там на сайте про это есть (http://www.seasip.info/Cpm/format14.html).
Error404
29.07.2016, 23:02
Видимо, для обратной совместимости. Почитай на досуге вот это: http://www.seasip.info/Cpm/format22.html
Эти описания такие описания...
Штука в том, что
"formula is: Entry number = ((32*S2)+EX) / (exm+1)"
нифига не работает. Играет только EX, как только он заполняется - всё, кирдык, 32 куска по 16к = 512кб.
А "S2 = Extent counter, high byte." на самом деле в коде - 4 бита (глючных при том).
Вот кстати. Та CP/M, что практически повсюду, на Башкирии выдаёт версию 1.2! Это, конечно, просто текст из биоса CP/M, который писали в КБ завода им. Кирова, но наводит на мысли, что это никакая не 2.2
А ещё, на том сайте есть такая фраза: CP/M 1.4 fits in 6.5k. Так вот вместе с биосом оно именно столько и занимает.
Интересно, почему все решили, что это версия 2.2?
Корвет, например, выдаёт:
CP/M-80 v. 2.2
ОФП НИИЯФ МГУ BIOS
Ver. 1.2 (c) III 1988
Вроде как рядом со словом CP/M стоит 2.2, но и тут есть про версию 1.2! Хотя вроде как это типа версия биоса.
Совпадение? Не думаю :)
- - - Добавлено - - -
Но, вообще-то, функция выдачи номера версии честно выдаёт 22h. :confused:
Error404
30.07.2016, 00:38
На вид явный заворот адреса. Это как слет LBA48 на дисках более 120ГБ под XP до SP1/SP2. Слет на LBA32 херил все на диске по причине затирания начала при завороте адресов. В вашем случае, это можно попробовать определить, загрузив файлы с определенным содержимым (текстом) и посмотреть что выведет ДОС при глюке.
правки в COMPRAND не повлияли.
Да, похоже на заворот адреса - вместо четвертого файла, оно начинает читать каталог (т.е. нулевой экстент).
Но вот что мне не ясно - почему оно на разных файлах имеет как бы "продолжающийся счетчик" (который и заворачивается)? Когда переменные все инициализируются при открытии файла, т.е. счетчик экстента каждый раз должен начинаться с нуля. Я бы понял если бы файл был более 2мб и по оно заворачивалось по границе в 2мб (т.к. я порушил разрядность в сторону увеличения размера до 2мб). Но первые то три отдельных файла читаются нормально, и каждый - от начала и до конца (конец тоже определяется). Шиза какая-то.
А "S2 = Extent counter, high byte." на самом деле в коде - 4 бита (глючных при том).
Вот комментарий из исходников:
; For random i/o, set the fcb for the desired record number
; based on the 'r0,r1,r2' bytes. These bytes in the fcb are
; used as follows:
;
; fcb+35 fcb+34 fcb+33
; | 'r-2' | 'r-1' | 'r-0' |
; |7 0 | 7 0 | 7 0|
; |0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0|
; | overflow | | extra | extent | record # |
; | ______________| |_extent|__number___|_____________|
; also 's2'
Максимальный номер записи 65535.
Покопался в исходниках - вроде всё должно работать. Если не работает, надо проверять DPB.
- - - Добавлено - - -
Да, есть такой эффект. Закинул сейчас на диск 4 файла по 650кб, первые три читаются нормально, а четвертый - "улетает". Трудно сказать почему.
А размер каталога не 4Кб? А то для 4-х файлов по 650Кб надо как минимум 5.2Кб.
HardWareMan
30.07.2016, 05:19
правки в COMPRAND не повлияли.
Да, похоже на заворот адреса - вместо четвертого файла, оно начинает читать каталог (т.е. нулевой экстент).
Но вот что мне не ясно - почему оно на разных файлах имеет как бы "продолжающийся счетчик" (который и заворачивается)? Когда переменные все инициализируются при открытии файла, т.е. счетчик экстента каждый раз должен начинаться с нуля. Я бы понял если бы файл был более 2мб и по оно заворачивалось по границе в 2мб (т.к. я порушил разрядность в сторону увеличения размера до 2мб). Но первые то три отдельных файла читаются нормально, и каждый - от начала и до конца (конец тоже определяется). Шиза какая-то.
Ну окромя относительных адресов-счетчиков есть еще и абсолютный. О чем и была речь в моем сообщении. На примере все тех же HDD, LBA это уже метрика самого диска. Какой разрядности абсолютный счетчик ДОС? Для дисковода, я так понимаю, это CHS формат.
Error404
30.07.2016, 12:22
Вот комментарий из исходников:
; For random i/o, set the fcb for the desired record number
; based on the 'r0,r1,r2' bytes. These bytes in the fcb are
; used as follows:
;
; fcb+35 fcb+34 fcb+33
; | 'r-2' | 'r-1' | 'r-0' |
; |7 0 | 7 0 | 7 0|
; |0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0|
; | overflow | | extra | extent | record # |
; | ______________| |_extent|__number___|_____________|
; also 's2'
Максимальный номер записи 65535.
Покопался в исходниках - вроде всё должно работать. Если не работает, надо проверять DPB.
Да, есть такой комент, он страницей раньше в моем посте даже есть. :)
Там все очень коряво: эти переменные (экстент EX и переполнение extra_extent=S2) существуют в двух ипостасях одновременно: в байтах FCB+12,+14 (для любых операций) и FCB+33,+34 (для прямого позиционирования, причем в коде довольно часто перепрыгивает с подпрограмм произвольного на последовательный и обратно). При этом FCB+12 - ровный байт, и FCB+14 - ровный байт (номер записи отдельно в третьем байте), а вот FCB+33 и +34 - это 5 (EX) и 4 (extra=S2) битов упакованные вместе с номером записи в общий 16-битный целый. Т.е. S2 не может быть больше 4 битов даже там, где он хранится целым байтом. И BDOS постоянно на сдвигах тасует их между этими двумя способами представления, где-то сглюкивая (не отрабатывает переполнение EX либо тупо не умеет позиционироваться по EX+extra_extent, а только по EX). Погнались за совместимостью (какой?с чем?) и наколбасили.
Ну я поначалу и думал: раз оно не умеет отрабатывать переполнение EX увеличением extra_extent (хотя по коду вроде должно, собственно поэтому в реальности максимальный номер записи не 65535, а 4096, т.е. 512кб), или что более вероятно не адресуется по extra_extent (а вот это я по коду не понял - да или нет), то тупо увеличу EX в разрядности за счет пропорционального уменьшения extra (чтобы упакованно осталось как и ранее 16 бит) - и "на наш век хватит". Ан нет, где-то "совместители" еще одну (а может и не одну) "мину подложили под наше молодое государство" (с) главстерх
А размер каталога не 4Кб? А то для 4-х файлов по 650Кб надо как минимум 5.2Кб.
Размер каталога - одна группа (меньше не сделаешь), т.е. 16кб. Т.е. в теории в такой каталог должно влезать 16384/32=512 файловых дескрипторов, *8=4096 групп, *16=65536кб (64Мб) дискового пространства, плюс системные треки. Размер партиции/ФС совпадает - 64Мб (или даже меньше, не помню - образ на рабочем компе).
- - - Добавлено - - -
Ну окромя относительных адресов-счетчиков есть еще и абсолютный. О чем и была речь в моем сообщении. На примере все тех же HDD, LBA это уже метрика самого диска. Какой разрядности абсолютный счетчик ДОС? Для дисковода, я так понимаю, это CHS формат.
Если про BIOS, то для IDE/SD в глобальном адресе (по всей поверхности носителя) поддерживается 32-битный LBA секторами по 512 байт. Который внути каждого конкретного раздела слегка уменьшается в разрядности за счет работы 128-байтными блоками. Но все равно этих секторов там "номер трека"(16 бит)*"номер сектора"(16 бит). Т.е. в разрядность CP/M-овского 16-битного произвольного адреса записи попадает гарантированно даже в комбинациях (1трек на 65536 секторов) или (65536 треков по 1 сектору). Да и заворачивается оно не на нулевой сектор раздела, и не на нулевой сектор целого диска, а на нулевую группу (группа - это сугубо понятие BDOS, она может начинаться и не от начала раздела, собственно в данном образе так и есть) т.е. уже после системных дорожек текущего раздела. Где-то в BDOS какашка.
Конверсии выходного дня - две игрушки с msx (в imsx они не работают, т.к. напрямую обращаются к портам). Клавиши управления описаны в readme. Запускать из PRODOS. Поддерживаются (на автоопределении) оба варианта дешифрации AY (Пушков и zx).
Очередное большое спасибо Дмитрию2012 за проверку на реале и выявление неприятного бага!
Прикольно. Но кажется, немного быстровато...
- - - Добавлено - - -
Там все очень коряво: эти переменные (экстент EX и переполнение extra_extent=S2) существуют в двух ипостасях одновременно
Вообще-то, функции прямого доступа к записи (блоку из 128 байт) просто конвертируют 16-битный номер записи в те самые extra_extent, EX и номер записи 0-127. А потом вызывают всё те-же функции чтения/записи. Больше этот 16-битный номер нигде не используется.
И BDOS постоянно на сдвигах тасует их между этими двумя способами представления, где-то сглюкивая
Да нет, основной способ доступа именно через те самые extra_extent, EX и номер записи 0-127. Поиск в каталоге осуществляется по номеру юзера, имени файла, 5-ти битам номера экстента и тому самому расширенному номеру S2, благо они все рядом, в пределах 15 байт. Функция поиска на входе имеет количество байт, которые нужно сравнивать. Это либо 12, для простого поиска первого попавшегося, либо 15, для поиска с нужным номером экстента (функция сравнивает номер экстента накладывая маску, которую ты хакнул, и пропускает байт S1).
Функции последовательного чтения/записи после обмена с диском увеличивают номер записи, а если надо и номер экстента, а также расширенный номер (проверяя при этом, чтобы расширенный номер не стал больше 16, в противном случае выдаёт ошибку). Можно в отладчике посмотреть, что происходит после чтения 512кБ. ivagor, у тебя есть готовый образ диска, чтобы посмотреть?
Error404
30.07.2016, 22:23
b2m, если бы оно работало как ты пишешь (а я так понял ты считаешь что ошибки в BDOS нет, просто мы тут что-то неправильное ей подаем на вход), то BDOS (еще не правленная) записывала бы файлы и более 512кб, когда я (пользователь) их пытаюсь записать (а я таки пытался). Но вместо этого она обламывалась на 512кб, точно так же как и при чтении. Т.е. дело не в том как файлы записаны на диске (моим плагином или еще как-то), а в том что в BDOS ошибка в реализации, и чего там понаписано в описаниях - тоже могут быть только фантазии из серии "как оно должно бы быть". На практике, никто большие файлы не проверял (кроме нас, и еще пары человек в Инете, т.к. это было давно, в эпоху носителей-маломерок), и реально работает только адресация по номеру экстента и все. Тут или отлаживать чужие ошибки (которые могут быть и в самой логике построения этой унылой "математики" с кучей счетчиков где должен быть один), или переписать кусок - отказываться от нафиг ненужного S2 (а обойтись единым счетчиком - одним увеличенным EX как и подсказывает банальный практицизм, вместо маразма с ведением двух счетчиков да еще и перепаковывя их в разное количество байт), или (к чему я склоняюсь) - взять переписанный бдос уже без всего этого бреда (а такие у меня на примете есть, просто хотелось обойтись малой кровью - типа "поправить десяток байт и оно вдруг заработает").
я так понял ты считаешь что ошибки в BDOS нет
А ты считаешь, что за 30 лет никто так и не заметил ошибку? :)
Error404
30.07.2016, 23:56
А ты считаешь, что за 30 лет никто так и не заметил ошибку? :)
Не только заметили, но и переписали BDOS, т.к. {цитирую по памяти} "проще было переписать".
Есть у меня архив переписанной 2.2, причем уже в коде Z80, меньшего размера (что дало автору впихнуть в сстандартный объем еще и код для поддержки дат файлов, каталога по умолчанию и т.п.), и одно из упоминавшихся в описалове - он писал что исправил ошибки в файловом доступе в стандартной 2.2, что дало увеличение максимального размера - как ФС так и файлов (до математического предела, а не до бага). Конечно, все это надо проверять, т.к. делано это опять же еще до эпохи дешевых "народных" HDD.
- - - Добавлено - - -
Если память не подводит, вроде вот это оно:
http://www.gaby.de/ftp/pub/cpm/znode51/specials/zsdossrc/zsdos.htm
Прикольно. Но кажется, немного быстровато...
Там есть кнопки F1 и F2 для выключения/включения турбы (readme.txt). Музыка в турбе точно слишком быстрая, но в сложных (для движка) местах без турбы грустно.
- - - Добавлено - - -
ivagor, у тебя есть готовый образ диска, чтобы посмотреть?
Есть, но я сегодня не дома, только завтра смогу выложить. У Errora404 тоже есть такой образ.
Не только заметили, но и переписали BDOS, т.к. {цитирую по памяти} "проще было переписать".
Ну, господа, если вы используете что-то своё, а не CP/M 2.2, то конечно, оно у вас может и не работать :)
Я вот не поленился, набил программу, которая записывает 1100h записей (544Кб) последовательно, а потом читает записи с номерами 0FFFh и 1000h. Тестировал на Корвете (там CP/M байт в байт как на Башкирии, но у Башкирии один логический диск всего 384Кб). Так вот считалось именно то, что я и записывал (а именно - 16-битный номер записи).
И в каталоге именно так, как и должно быть - номера экстентов: ... 00.1E 00.1F 01.00 01.01 ...
ksanf(138)
31.07.2016, 12:08
Моть вообще CPM 3 запилить, где то помню попадались исходники. Поддержка страничной памяти, TPA 60 Килобайт. Ещё чего то не помню. )
Альтаирка неплоха ,конечно, но охота ,чего то охота. ;) А чего еще не понял. ;)
А теперь посмотрим на исходники, на которые дал ссылку Error404. Интересует, как они конвертируют номер записи:
LDFCB: LD (RDWR),A ; Save Read/Write flag
LD A,(IX+33) ; Get first byte random record
LD D,A ; Save it in D
RES 7,D ; Reset MSB to get next record
RLA ; Shift MSB in carry
LD A,(IX+34) ; Load next byte random record
RLA ; Shift Carry
PUSH AF ; Save it
AND MAXEXT ; Mask next extent
LD C,A ; Save it in C
POP AF ; Get byte
RLA ; Shift 4 times
RLA
RLA
RLA
AND 0FH ; Mask it
LD B,A ; Save data module number
LD A,(IX+35) ; Get next byte random record
LD E,6 ; Set random record to large flag
CP 4 ; Test random record to large
JR NC,LDFCB8 ; Yes then error
RLCA ; Shift 4 times
RLCA
RLCA
RLCA
ADD A,B ; Add byte
LD B,A ; Save data module number in B
LD (IX+NXTREC),D ; Set next record count
LD D,(IX+FCBMOD) ; Get data module number
BIT 6,D ; Test error random record
JR NZ,LDFCB0 ; Yes then jump
LD A,C ; Get new extent number
CP (IX+FCBEXT) ; Compare with FCB
JR NZ,LDFCB0 ; Not equal then open next extent
LD A,B ; Get new data module number
XOR (IX+FCBMOD) ; Compare with data module number
AND MAXMOD ; Mask it
JR Z,LDFCB6 ; Equal then return
LDFCB0: BIT 7,D ; Test FCB modified (write)
Обратите внимание на выделенные красным цветом строчки. Правильно ли запомнились в стеке 4 бита расширенного номера экстента? Или может быть нужно было только 3 раза потом сдвиг делать?
HardWareMan
31.07.2016, 13:06
Все зависит от того, сколько бит в екстенте. Если вот это верно:
; For random i/o, set the fcb for the desired record number
; based on the 'r0,r1,r2' bytes. These bytes in the fcb are
; used as follows:
;
; fcb+35 fcb+34 fcb+33
; | 'r-2' | 'r-1' | 'r-0' |
; |7 0 | 7 0 | 7 0|
; |0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0|
; | overflow | | extra | extent | record # |
; | ______________| |_extent|__number___|_____________|
; also 's2'
то сдвигов должно быть всего 4 а не 5. И тогда, либо первый RLA должен быть после PUSH AF (т.е. два байта поменять местами) либо один RLA после POP AF убрать. Возможно это ошибка разрабов и изначально все должно было быть по первому варианту. А оошибку сразу не выявили потому что не было столько объемов. Или я не прав?
PS Я вот думаю, может натянуть какую досю на мой МХ2?
- - - Добавлено - - -
Стоп, а сдвиг то влево а не вправо. Причем через С. Так что 5 это нормально.
Стоп, а сдвиг то влево а не вправо. Причем через С. Так что 5 это нормально.
А действительно. Долбанные Z80-мнемоники :)
- - - Добавлено - - -
Короче, надо в отладчике смотреть. В теории вроде всё верно. Жду образ.
Error404
31.07.2016, 13:25
Ну, господа, если вы используете что-то своё, а не CP/M 2.2, то конечно, оно у вас может и не работать :)
Используется BDOS который цельнотянутый на всех CP/M Ориона, откуда его утянули - сие тайна великая есть, но живет оно вот в таком вот виде с одна тысяча девятьсот мохнатого года. И код там для 8080, тремя страницами ранее есть исходники, тоже не моего производства (архив с двумя файлами - в мнемониках 8080 и Z80) - я их взял иллюстрировать свои мысли как наиболее хорошо комментированные исходники, т.к. те фрагменты что я правил, с этим исходником совпадали (за другое не поручусь) - тремя страницами треда ранее. А то что ты смотришь сейчас, это то что я как перспективное указал (а не то что использую), читай внимательнее. Оно в коде для Z80 (глянул в код в спойлере, а там индексные операции, лол).
Потестировал чтение/запись под PRODOS, нет вроде никаких проблем с файлами больше 512Кб. Дайте уже то, что у вас не работает!
Error404
31.07.2016, 14:04
Потестировал чтение/запись под PRODOS, нет вроде никаких проблем с файлами больше 512Кб. Дайте уже то, что у вас не работает!
Ну, наверное вот это быстрее всего можно взять (там в первой партиции CP/M):
https://drive.google.com/file/d/0B3S0wVWNPLrwLXgwZE9Ebnh6eHc/view?usp=sharing
Остальное я уже покоцал своими правками. :)
- - - Добавлено - - -
Потестировал чтение/запись под PRODOS, нет вроде никаких проблем с файлами больше 512Кб. Дайте уже то, что у вас не работает!
Ну тут я никак не могу подтвердить или опровергнуть, я ее пока не юзал. Вроде Ivagor как раз на ПроДосе файлы делил т.к. оно большими не работало?
- - - Добавлено - - -
Или вот еще дисководный вариант (http://zx-pk.ru/attachment.php?attachmentid=57630&d=1469097524)
Может я чё неправильно делаю, но вот три теста:
1. test пишет файл размером 544Кб, каждая запись заполнена собственно номером записи
2. читает произвольным доступом две записи на границе 512Кб
3. читает последовательно 544Кб
Выполнять лучше под отладчиком, чтобы контролировать результат, т.к. тесты очень простые и ничего на экран не выдают.
Всё работает, как и задумывалось. Где ошибка?
57701
Error404
31.07.2016, 14:26
Не знаю где ошибка, посмотрю завтра на работе, дома нет годной инфраструктуры. :)
Я последовательную запись не проверял. Я проверял на произвольной записи, утилитой DED, где оно обламывалось на границе 512кб.
А можешь записать в файл 3мб и скинуть сюда образ с этим файлом?
Вот твой образ, игрушки потёр, записал 3.МВ: altair3mbfile.rar (http://bashkiria-2m.narod.ru/files/orion/altair3mbfile.rar)
вот три теста
Попробовал test и test3 в продос - все ок. Кажется я догадываюсь, почему у меня на 512 Кб стопорилось, завтра проверю, может даже утром успею.
Забавно, что odiwcx (какая-то старая версия, здесь я новую не ставил) видит в 512.KB только 512КБ. А просмотрщиком видна и остальная часть файла.
Error404
31.07.2016, 19:59
Попробовал test и test3 в продос - все ок. Кажется я догадываюсь, почему у меня на 512 Кб стопорилось, завтра проверю, может даже утром успею.
Забавно, что odiwcx (какая-то старая версия, здесь я новую не ставил) видит в 512.KB только 512КБ. А просмотрщиком видна и остальная часть файла.
Плюс, я поправил еще одну ошибку в ODI.WCX, по файлу от b2m - файлы размером более 512кб у меня паковались не ограничивая поле экстент (EX, FCB+12) по модулю 32 с переносом в S2, а инкрементировался EX вплоть до 255 (видимо, из соображений простой человеческой логики :) ).
Ivagor, перепакуй пожалуйста большие файлы в используемом образе дисков новой версией плагина (перед запуском TC/DC надо удалить все старые - odi.wcx, odi.wcx0, odi.wcx1, odi.wcx2, odi.wcx3)
- - - Добавлено - - -
Однако ж запись (и чтение) с прямым позиционированием через ф.21h/22h (утилитой DED) все одно обламывается на 512кб. А оно там просто делает, через инкремент номера записи в FCB+34+35 и обращения через фф произвольного доступа (а он должен бы работать, там тупо инкремент 16-битного числа, битики сами складывася как надо, а уж система потом внутри себя маскми раскидывает в EX и S2). Тоже понять бы где собака порылась.
- - - Добавлено - - -
да, образ использовать такой, где система БЕЗ моих ручных патчей на увеличение разрядности EX
поправил еще одну ошибку в ODI.WCX
Вот это помогло! Теперь файлы >512 Кб записанные в образ плагином читаются нормально (пробовал по 14h и моя "догадка" оказалась ни при чем). Правда пробовал не в про, а в векторе (comanовский cp/m 59), но я думаю это не принципиально.
Теперь бы еще с подряд записанными большими файлами на hdd разобраться.
- - - Добавлено - - -
Вот образ (https://yadi.sk/d/Wlkq5CLkto2oK) для примера. Там в user 4 несколько больших файлов (плеер в эмуляторе не работает). Начиная с bach44.wav дурит.
Error404
01.08.2016, 16:55
Теперь бы еще с подряд записанными большими файлами на hdd разобраться.
Вот образ (https://yadi.sk/d/Wlkq5CLkto2oK) для примера. Там в user 4 несколько больших файлов (плеер в эмуляторе не работает). Начиная с bach44.wav дурит.
А эти файлы записаны последним плагином? И в образ раньше чем с моими третьего дня правками?
Просто я думал, что проблема с "заворотом" на четвертом большом последовательно лежащем файле оттого, что не правильно работал плагин (нумеровал экстенты больших файлов в каталоге в "переполненной" с точки зрения BDOS форме) плюс порушенная мной для эксперимента разрядность EX в BDOS.
Иначе (если оно так и на неправленной мной BDOS), с ходу не понятно на что и думать.
- - - Добавлено - - -
В-общем попробовал на неправленном BDOS, "заворачивается" оно на группе с номером 2000h. Вместо группы 2000h читает группу 0000h (т.е. каталог). Такое ощущение, что в коде BDOS где-то делается "groupN and 1FFFh". :) Какие будут мысли?
09 50 45 54-4C 59 41 20-20 54 58 54-07 00 00 80 ○PETLYA TXT• А
FE 01 FF 01-00 02 01 02-02 02 03 02-04 02 05 02 ■☺*☺ ☻☺☻☻☻♥☻♦☻♣☻
09 50 45 54-4C 59 41 20-20 54 58 54-0F 00 00 80 ○PETLYA TXT☼ А
06 02 07 02-08 02 09 02-0A 02 0B 02-0C 02 0D 02 ♠☻•☻◘☻○☻◙☻♂☻♀☻♪☻
09 50 45 54-4C 59 41 20-20 54 58 54-17 00 00 80 ○PETLYA TXT↨ А
0E 02 0F 02-10 02 11 02-12 02 13 02-14 02 15 02 ♫☻☼☻►☻◄☻↕☻‼☻¶☻§☻
09 50 45 54-4C 59 41 20-20 54 58 54-1F 00 00 80 ○PETLYA TXT▼ А
16 02 17 02-18 02 19 02-1A 02 1B 02-1C 02 1D 02 ▬☻↨☻↑☻↓☻→☻←☻∟☻↔☻
09 50 45 54-4C 59 41 20-20 54 58 54-07 00 01 80 ○PETLYA TXT• ☺А
1E 02 1F 02-20 02 21 02-22 02 23 02-24 02 25 02 ▲☻▼☻ ☻!☻"☻#☻$☻%☻
09 50 45 54-4C 59 41 20-20 54 58 54-09 00 01 4E ○PETLYA TXT○ ☺N
26 02 27 02-00 00 00 00-00 00 00 00-00 00 00 00 &☻'☻
- - - Добавлено - - -
Вот DPB этого раздела:
C3 30 00 00-00 00 00 00-00 00 02 00-40 00 00 04
//-------------------------------------------------------------------- Orion specific
jump: array [0..7] of byte;
PAGE1: byte;
PAGE2: byte;
LEN1: byte; // phisical sector size (1=256, 2=512, 3=1024)
LEN2: byte; // sides (density?) (0=one_side, 1=double_sided)
SEC: word; // phisical sectors per track
TRK: word; // phisical tracks on disk (one side)
00 01 07 7F-07 FD 07 FF-01 80 00 80-00 01 00
//-------------------------------------------------------------------- CP/M standard
SPT: word; // logical sectors (128) per track
BSH: byte; // Block Shift - Block Size is given by 128 * 2^(BSH)
BLM: byte; // Block Mask - Block Size is given by 128 * (BLM +1)
EXM: byte; // Extent Mask
DSM: word; // user space size in kb = SEC * (TRK-OFF) - (CKS/8)
DRM: word; // max quantity of file records (FCBs) in catalog
AL: word; // 16-bit Directory Allocation Pattern
CKS: word; // Directory Check Sum = catalog size (in logical blocks)
OFF: word; // system tracks
Думаю, в проверке нуждаются EXM и DSM
А эти файлы записаны последним плагином? И в образ раньше чем с моими третьего дня правками?
Да, последней версией плагина в "старый" образ.
Error404
01.08.2016, 18:10
что-то я не нахожу ошибок в DPB
Вместо группы 2000h читает группу 0000h (т.е. каталог).
Ясен пень, если у тебя BSH=7, а номер кластера 200h. Сдвинь-ка это число семь раз налево, получишь номер записи 10000h. Я выше писал, что максимальный номер записи 65535.
Вообще, почему все молчат об ограничении в 8Мб? Это-ж известный факт :)
- - - Добавлено - - -
Вот, кстати, в сорцах zsdos я видел, что там ещё 2 бита учитываются, т.е. максимальный размер тома там 32Мб.
- - - Добавлено - - -
что-то я не нахожу ошибок в DPB
А я нашёл еще и ошибку в DPB: размер диска указывается в кластерах (т.е. блоках), а не в килобайтах. Нужно туда номер последнего доступного блока записывать. У тебя будет 1FFh.
- - - Добавлено - - -
Хотя у тебя для 64Мб правильно указано :)
Error404
02.08.2016, 00:34
Номер записи - абстрактное свойство файла, А не файловой системы. Причем тут номера групп сиречь номера кластеров? 32 мб предел размера файла а не ФС, максимальный размер ФС ZSDOS 1гиг, ЕМНИП
- - - Добавлено - - -
А я нашёл еще и ошибку в DPB: размер диска указывается в кластерах (т.е. блоках), а не в килобайтах. Нужно туда номер последнего доступного блока записывать. У тебя будет 1FFh.
Хотя у тебя для 64Мб правильно указано :)
Почему 64? 64 это размер всего образа, в нем 4 партиции.
Не, для DSM вроде верное значение - 7FDh (2045). Размер группы (=блока=кластера) 16кб, размер самой партиции (ФС) 32Мб (800h * 16кб), минус системный трек (32кб, т.е. 2 группы по 16к), минус каталог (1 группа по 16к).
- - - Добавлено - - -
Тут в чем-то другом собака порылась.
Дико не хочется лезть в отладчик.
Дико не хочется лезть в отладчик.
Так я сначала залез, а потом ответил тебе. В одной из процедур номер кластера сдвигается влево на 7. В результате в HL ноль.
Номер записи это не только свойство файла. Номер кластера не сразу пересчитывается в номер дорожки и номер записи на дорожке. Сначала находится номер записи файловой системы, потом он делится на количество записей на дорожке SPT. Частное будет номером дорожки, остаток - номером сектора (т.е. записи). SPT не обязательно должно быть степенью двойки. Например для нашего диска 5 секторов по 1024 байт SPT равно 40 (или 80, в зависимости от того, где биос будет учитывать номер стороны).
Error404
02.08.2016, 13:34
Так я сначала залез, а потом ответил тебе. В одной из процедур номер кластера сдвигается влево на 7. В результате в HL ноль.
Номер записи это не только свойство файла. Номер кластера не сразу пересчитывается в номер дорожки и номер записи на дорожке. Сначала находится номер записи файловой системы, потом он делится на количество записей на дорожке SPT. Частное будет номером дорожки, остаток - номером сектора (т.е. записи). SPT не обязательно должно быть степенью двойки. Например для нашего диска 5 секторов по 1024 байт SPT равно 40 (или 80, в зависимости от того, где биос будет учитывать номер стороны).
Зачем группа сдвигается на семь? В какой именно процедуре (вот в исходнике во вложении этого поста (http://zx-pk.ru/threads/24285-orion-pro-softvernye-dela.html?p=880144&viewfull=1#post880144)можно сориентироваться)? Значит, аффторы там накосячили с разрядностью переменной которую двигают, она должна быть 24-разрядная, а не 16 разрядная. Чтобы не улетали значащие биты.
Я DPB формирую (в fdisk) по описаниям от CP/M 2.2, которые встречал и в русских и в английских источниках (примерно одно и то же везде пишут (http://atmturbo.nedopc.com/inf/bios_cpm.htm#72)), где прямым текстом пишут, что для групп(кластера) размером в 16кб BSH,BLM,EXM должны быть таким-то. Вот должны и все тут.
Если не затруднит, распиши как я пишу, типо на пальцах: такая-то переменная DBP, такое-то значение, потому что в коде оно так. Потому что из того что я читал не следует ограничение на файловую систему ни в 8М ни 32М. И согласно тем описаниям, ошибки в DPB я не нахожу.
По "номеру записи" я тебя тупо не понял. Т.к. в описаниях CP/M record - это относится к файлу (та самая текущая позиция по которой читается 128-байтная запись из файла), все что к диску относится - это что угодно другое (группа, сектор, дорожка,...).
Что имеется в виду под "номер записи файловой системы"? Группа (кластер), номер которых указывается в FCB-шках в позициях FCB+16...FCB+31? Других логических единиц хранения на диске вроде нету у CP/M. Дорожки и сектора это уже физические (они передаются в BIOS как параметры).
Ограничение на файловую систему вытекает из того, что в CP/M 2.2 используется 16-битная арифметика для рассчёта номера записи файловой системы. Чтобы не путаться в понятиях:
запись = 128 байт = сектор в терминах биос CP/M
кластер = группа (в твох терминах) = блок
экстент = 128 записей = 16 Кб (у тебя совпадает с размером кластера, может отсюда и путаница)
модуль (тот самый S2) = 32 экстента
Давай логически прикинем, как преобразуется номер записи файла file_rec в номер дорожки track и номер сектора sector (большими буквами далее - значения из DPB):
blk_rec = file_rec & BLM;
file_blk = file_rec >> BSH;
file_ext = file_rec >> 7; // т.к. 1 экстент = 128 записей
extent = file_ext & 1Fh;
s2 = file_ext >> 5;
get_dir_record(file_name, extent, s2); // у номера экстента игнорируются младшие биты, еденичные в EXM
blk = dir.alloc[file_blk & 7]; // для случая с 16 однобайтовыми значениями берём нужную половину, в зависимости от младшего бита номера экстента
record = (blk << BSH) | blk_rec; // тут у нас переполнение т.к. record 16-битная переменная
record += DRM/4;
sector = record % SPT;
track = record / SPT + OFF;
Вроде бы нигде не ошибся.
Error404
02.08.2016, 14:22
Т.е. ошибка все же "авторская" (не думали про большие носители - структуры распланировали заманчиво, а реализацию в коде обкарнали), и вот этот вот кусок
record = (blk << BSH) | blk_rec; // тут у нас переполнение т.к. record 16-битная переменная
record += DRM/4;
sector = record % SPT;
track = record / SPT + OFF;
надо в BDOS переписать поправив математику так, чтобы разрядность record увеличить с 16 до 24 бит.
В какой процедуре оно в тексте во вложении?
Собственно проблемная строчка это процедура LOGICAL. Но нужно будет ещё посмотреть места, где используется 16-битная переменная BLKNMBR, потому что она там используется и как номер блока, и как номер записи (вот такой дурдом). Рассчёт сектора и дорожки, где эта переменная уже как номер записи, это процедура TRKSEC1. И да, деление там сделано циклом с вычитанием :)
- - - Добавлено - - -
Пока заметил следующие места, где нужно будет учесть третий байт номера записи:
1. при чтении каталога (TRKSEC), нужно обнулять третий байт
2. собственно рассчёт сектора и дорожки (TRKSEC1), лучше всего переписать с использованием нормального деления 24/16
3. естесственно LOGICAL
4. ну и процедура записи, там есть зануление неиспользованного пространства блока, тоже 16-битный счётчик номера записи
- - - Добавлено - - -
У тебя ведь SPT=100h, можешь для начала сделать так:
1. проблем не должно составить
2. тупо использовать старшие 16 и младшие 8 бит номера записи в качестве номера дорожки и сектора
3. тут надо сделать честно
4. зануление выкинуть нафиг, всё равно наверное не используется
Таким образом, если всё будет работать как надо, то и 2, и 4 тоже дописать до честного варианта.
Error404
02.08.2016, 19:55
Что-то я не понимаю смысла возни с SCRATCH2(current track) и SCRATCH3(current sector) в TRKSEC2. В комментах указано, что SCRATCH3=current_sector, накой из него в цикле вычитать SPT(SECTORS), и делать это пока BLKNMBR меньше SCRATCH3(current_sector)?
Понять не могу что там на что делится и зачем. SCRATCH-и тоже надо что ли 24 битными заводить?
Если делать честную процедуру деления, то SCRATCH 2 и 3 можно вообще выкинуть. Работает там это так: когда идём на нулевую дорожку, обнуляем оба 16-битных числа. А затем, когда нужно перейти к сектору NNN одно число увеличивается (или уменьшается, если обратно надо) на SPT, получая при этом номер дорожки умноженный на SPT, а второе число на еденицу, получая просто номер дорожки. Когда номер сектора достиг почти нужного числа, то нам будет известен номер дорожки, а чтобы вычислить номер сектора, из NNN вычитается накопленный номер сектора (т.е. track*SPT).
- - - Добавлено - - -
Если непонятно объяснил:
SCRATCH2 = track
SCRATCH3 = track*SPT
Оба числа изменяются синхронно. Ищется такой SCRATCH3, который удовлетворяет критерию SCRATCH3 <= BLKNMBR < SCRATCH3+SPT
Error404
02.08.2016, 22:53
*****код детектед. :)
Я подумаю об этом завтра, не буду на ночь терзать нервную систему созерцанием шизы от Килдалла.
Как файлы *.bru сконвертировать в *.ord? Хочу собрать прошивку для ромдиска, есть какие-то правила?
OrionExt
03.08.2016, 00:15
Как файлы *.bru сконвертировать в *.ord?
Так это одно и тоже. *.bru - это авторское расширение, а *.ord делала программа LORD (сохранялся/читалка Ордос-файлов на/с диска).
Хочу собрать прошивку для ромдиска, есть какие-то правила?
Х.з, я руками собирал в hex-редакторе. Это не так уж часто нужно. Если ордос файлы на PC напрямую тянуть с образа дисков, то в конце будет оставаться мусор от CP/M файлов.
*****код детектед
Не скажи. При последовательном чтении/записи, а это 99% всех случаев, это работает побыстрее честного деления.
Error404
03.08.2016, 19:54
Ну, вроде заработало с увеличением битности указателя блоков с 16бит до 24 бит. :) По крайней мере группы более 200h стали обрабатываться.
Исходники тут (http://zx-pk.ru/threads/18451-altair-dos-v3-x.html?p=479327&viewfull=1#post479327). Правился файл bdos1.mac (в архиве есть его бэкап для сравнения что поменяно).
Вот образ для тестирования (https://drive.google.com/file/d/0B3S0wVWNPLrwUDA2Vmxrd2ZjSnM/view?usp=sharing) (понимает большие файлы и не должен "заворачиваться" на нулевой кластер после N больших файлов)
Чтение немного погонял, а запись не проверял. Соответственно не правил (и не совсем понял о чем) вот это:
"4. ну и процедура записи, там есть зануление неиспользованного пространства блока, тоже 16-битный счётчик номера записи
"
HardWareMan
03.08.2016, 20:10
ЧТД.
Соответственно не правил (и не совсем понял о чем) вот это:
"4. ну и процедура записи, там есть зануление неиспользованного пространства блока, тоже 16-битный счётчик номера записи"
Это про то место, которое в твоих исходниках начинается меткой AD68C. В других местах LOGSECT (номер первого сектора блока) не используется.
А в COMBLK и CHKBLK не надо было расширять, там переменная BLKNMBR ещё как номер блока, т.е. достаточно 16 бит.
Error404
03.08.2016, 23:41
Ну, я бабахнул "по площадям", перестаховался. :)
OrionExt
06.08.2016, 19:03
Error404, как дела продвигаются?) Тестить не на чем мне. Чужой софт ток на реале. Это свой можно в эмуляторе гонять.
А не прикрутить ли нам к СР/М ALU. Не тот старый, а новый с четырьмя ножками (*8);)
- - - Добавлено - - -
В Паскаль МТ+ была такая возможность, cos на лету считать:v2_dizzy_botan:
Error404
08.08.2016, 20:10
Не знаю на счет сопроцессора, хотя быстрая целочисленная математика была бы очень не лишней - например имея полный спектр операций над INT32 можно было бы подумать над использованием носителей FAT32 в повседневном Орионе (прямой работе с файлами на CF/SD-карте записанными Виндой)
А так, мне бы пока более приземленные вопросы решить.
Например, у меня на ПРО не будет РОМ-диска (зачем он - проще на месте штатной ROM2 поставить ПЗУ на 1Мб и там много чего разместить, тамошняя 32-ногая панелька позволяет), но на первое время для отладки что-то надо. Поэтому слепил на скорую руку такое (https://github.com/serge-404/OriZEmu/tree/master/ROM/MakeProROM): в неиспользуемых областях ROM2 (8кб в сумме внутри первых 32к ПЗУ) размещаю набор ордосовских прог, которые по включению питания копируются из ПЗУ ROM2 на диск B: (т.е. в ОЗУ). Такой вот РОМ-диск для бедных (и экономим слот). В архиве есть утилита для заливки в эти 8кб любых программ, что поместятся.
Естественно, в качестве ROM2 куда льём, нужно использовать комплектный ROM2-321.ROM из того архива (ибо в нем патч-распаковщик на диск В).
UPD. Поправил недочет в проверке предела заливки (те самые 8кб)
вроде заработало с увеличением битности указателя блоков с 16бит до 24 бит
Да, вроде заработало. Накидал в образ 4Мб файлов и они читаются. Теперь можно мегабайтные wavы воспроизводить.
- - - Добавлено - - -
Доработанная версия проигрывателя wavов с использованием рамдиска. От первой (http://zx-pk.ru/threads/24285-orion-pro-softvernye-dela.html?p=879597&viewfull=1#post879597) версии два отличия: поддержка файлов до 1 Мб и частоты дискретизации 44 кГц. Как обычно большое спасибо Дмитрию2012, который тщательно проверил на реале - работает в альтаире (лучше с последним выложенным образом hdd с правленым досом) и продосе.
Кроме того Дмитрий обнаружил баг в nc (связанный с тем, что дос ушел вперед, а nc остался прежним), про который он лучше расскажет сам.
Дмитрий2012
13.08.2016, 21:37
Кроме того Дмитрий обнаружил баг в nc (связанный с тем, что дос ушел вперед, а nc остался прежним), про который он лучше расскажет сам.
Глюк заключается в том, что видимо командер не видит файлы размером больше 512к. Сама ДОС видит. Хорошо бы поправить это.
Возможно дело не в 512Кб. В usere 4 записано 8 файлов, дос по dir показывает все (а wvcvx8rd их успешно читает). nc показывает только 4 первых и неверно показывает размер 2 из 4. Вот образ (https://yadi.sk/d/uDL4mZY7uCMGn) того hdd
Error404
14.08.2016, 09:19
Возможно дело не в 512Кб. В usere 4 записано 8 файлов, дос по dir показывает все (а wvcvx8rd их успешно читает). nc показывает только 4 первых и неверно показывает размер 2 из 4. Вот образ (https://yadi.sk/d/uDL4mZY7uCMGn) того hdd
Причина понятна, там самодельный алгоритм чтения каталога посекторно через bios, a не через поиск первого/следующего BDOS. Так работало быстрее на больших каталогах. Вот и не знаю, допилить существующий устранив ошибки или переписать на стандартные функции БДОС. Пр хорошему еще и массив надо увеличить, сейчас ограничение на 256 файлов, а это увеличение разрядности всех индексов с 8 до 16 и т.п.
Error404
16.08.2016, 14:40
Народ, подскажите пожалуйста, тут где-то мануал по системному софту ПРО пролетал, сейчас уже не вспомню где (или это выдержки были?).
Интересуют подпрограммы Монитора F800 для режима Орион-128 (ЕМНИП чего-то они там меняли в процедурах F830,F833,F836 относительно Монитора-2 образца 1990 года).
Но и полный манул в копилку бы не помешал.
- - - Добавлено - - -
Всем привет!
У кого-нить имеется следующий софт ?
* Исходники ROM-BIOS V2.10 для Орион-Про (ROM1 и ROM2)
* Исходники редактора SURED V3.0, пакета IBM-disk V2.2
* Исходники редактора Corona V2.20
* Исходники TASM V4.10 (под ORDOS)
* Пакет IBM-disk V2.2 (типа проги "MSDOS" от "Lucksian Key")
* ORDOS 6.1 beta (автор В.Михаловский)
архивы исходников от Vasil сохранились у кого-нить? Перезалейте, пож. а то все ссылки на яндексдиск уже дохлые (ух, не люблю яндексдиск)
Интересуют подпрограммы Монитора F800 для режима Орион-128 (ЕМНИП чего-то они там меняли в процедурах F830,F833,F836 относительно Монитора-2 образца 1990 года).
Но и полный манул в копилку бы не помешал.
http://denn.ru/orion/pro/bios/vectors.jpg
Более подробно тут - http://denn.ru/orion/pro/orion-pro.djvu
архивы исходников от Vasil сохранились у кого-нить? Перезалейте, пож. а то все ссылки на яндексдиск уже дохлые (ух, не люблю яндексдиск)
Была паблик-выключена по недосмотру.
https://yadi.sk/d/sdCypO9GuFnvj
АлександрПП
16.08.2016, 22:07
Вот что у меня надергано с дисков:
https://yadi.sk/d/Vgd9Cb3luGQ6E
Error404
18.08.2016, 20:02
Слепил на скорую руку расширитель для ROM2 - в емкую ПЗУ (я планирую туда 27C080 как в ревизии512 - ПЗУ емкостью 1Mb) в область выше первых 64к (в первых 64к сам ROM2) разместил Альтаир-ДОС, которая загружается из режима ПРО Орион-128 программой MBOOT (второй пункт меню - загрузка из ROM). MBOOT надо использовать из GitHub ниже по ссылке (https://github.com/serge-404/AltairDOS/tree/master/App/source/mboot) (он допилен до универсальности - грузит АльтаирДОС из расширенного ROM как для аппаратной классики-128 с управлением расширенными 64к-страницами портом 0FEh, так и для ПРО c управлением 8к-фрагментами портом 09h). В эмуляторе работает, на реале проверю через какое-то время (может кто раньше?).
Аппаратно - надо просто поставить более емкую ПЗУ с прошивкой из архива по ссылке, и при помощи 4 проводников (для ПЗУ 1Mb, а вообще ВВ55 порта ROM2 позволяет до 2Мб) МГТФ расширить в настоящее время незанятые старшие разряды порта ВВ55 на соответствующие старшие адресные ноги ПЗУ (благо 32-ногая панелька ROM2 позволяет)
https://drive.google.com/file/d/0B3S0wVWNPLrwVnNlWmdJZ3F1ZkU/view?usp=sharing
В архиве также исходники, которые правил для поддежки расширенного ПЗУ ROM2, и также для удобства отдельно 64к ПЗУ ROM2 (ROM2-321.ROM) с микро-ромдиском, формированным как описывал в этом посте (http://zx-pk.ru/threads/24285-orion-pro-softvernye-dela.html?p=881319&viewfull=1#post881319), только с новым MBOOT, и диск CP/M (DEBUG.OD3) который можно потрошить обычным плагином для ODI (https://github.com/serge-404/OriZEmu/tree/master/UTILS/OdiWcx-OhiWcx)(описатель для OD3 там есть). Прошивка ПЗУ получается "склеиванием" этих двух файлов:
copy /b ROM2-321.ROM + DEBUG.OD3 ROM2-321-ALTAIR.BIN
UPD 17.09.2016: Предварительно обновите систему в DEBUG.OD3 до актуальной требуемой версии для HDD (не FDD!)
Error404
29.08.2016, 11:13
Ну что, проверил на реале, на моем ПРО работает АльтаирДОС из ПЗУ 27С801 (1Mb), цена вопроса: одну ножку отрезать - перенести питание ПЗУ на выв.32, и 4 адресных проводничка от выв. 21,22,23,24 ВВ55 D80 к выв. 2,30,31,1 D67-ROM2. Правда, есть вопросец к свежеиспеченной п/п работы ROM2 в BIOS АльтаирДОС (почему-то приостанавливает прерывания до очередного нажатия клавиши, надо смотреть), но пользоваться можно уже и этой версией.
В принципе у кого нет в хозяйстве 27C080/27C801 (1Мб), хотя это конечно упущение с вашей стороны, даже на барахолке их недавно продавали по смешным ценам, то можно прошить первую половину прошивки в 27C040 (512Кб) - CP/M работать будет, игры отвалятся (один хрен для них на ПРО нужно дорабатывать порт FB (http://zx-pk.ru/threads/26504-sborka-pk-quot-orion-pro-quot-versii-3-20.html?p=873198&viewfull=1#post873198) - лень мне был подбирать игрухи работающие на кастрированном порте FB классического ПРО, кому не лень - файлы CP/M в прошивку можно перезалить плагином как описано постом выше).
Фотосессия: :)
1.
http://images.vfl.ru/ii/1472466284/414aeef0/13916582_m.jpg (http://vfl.ru/fotos/414aeef013916582.html)
2.
http://images.vfl.ru/ii/1472466073/df79d013/13916518_m.jpg (http://vfl.ru/fotos/df79d01313916518.html)
"Метровые" 27C801 ещё доступны - http://www.chipdip.ru/product/m27c801-100f/
А вот 27C040, увы, нет (( Есть только одноразовые (не интересено) и по неадекватной цене - http://www.chipdip.ru/product/at27c040-70pu/
Error404
29.08.2016, 11:39
"Метровые" 27C801 ещё доступны - http://www.chipdip.ru/product/m27c801-100f/
Мне метровые 27C801 понравились, на них хорошо ромдиски разные организовывать - ПЗУ достаточно емкие, корпус все еще 32 ноги (максимум что бывает из параллельных ПЗУ в 32ногих корпусах). Willem программатор их шьет (у меня такой). 27C040 теперь со старых материнок добывать наверное, ну и в Китае (там как в Греции все есть, но не всегда адекватная цена, в особенности на старые раритеты типа V9958 c Ямах).
Мне метровые 27C801 понравились, на них хорошо ромдиски разные организовывать - ПЗУ достаточно емкие, корпус все еще 32 ноги (максимум что бывает из параллельных ПЗУ в 32ногих корпусах). Willem программатор их шьет (у меня такой).
Я тоже ими затарился, теперь надо под них программатор ваять: придумывать схему и прогу к Ориону :)
OrionExt
29.08.2016, 16:42
Завязывайте самодельные программаторы ваять под импортную комплектуху. Китайцы уже все придумали. MiniPro TL866. Цена вопроса 45$. Умеет шить аж 14 тыс. микросхем (ROM, MCU, GAL).
OrionExt, если так рассуждать, то и с орионами давно надо завязать, а если дальше подумать в том же ключе, то на западе вообще давно всё придумано, нам можно не жить и даже не рождаться :)
OrionExt
29.08.2016, 17:00
Не то. Я о том, что энергию можно направить на что-то интересное, полезное для того же Ориона. А не пытается в 10 тыс раз придумать велосипед, который к Ориону малое отношение имеет.
А если уж хочется сделать уникальный программатор для Ориона с пользой. Предложу следующие. Заменить M27C801 на флешку и менять прошивку ROM-диска на лету прямо из CP/M или DSDOS.
Не то. Я о том, что энергию можно направить на что-то интересное, полезное для того же Ориона. А не пытается в 10 тыс раз придумать велосипед, который к Ориону малое отношение имеет.
Программатор это именно интересное с точки зрения разработки устройство и безусловно полезное именно для Ориона, т.к. это его память (ROM-диск). Программирование ПЗУ - это как раз адекватная для Ориона задача и совершенно трушно и канонично, если это будет делать сам Орион :)
А если уж хочется сделать уникальный программатор для Ориона с пользой. Предложу следующие. Заменить M27C801 на флешку и менять прошивку ROM-диска на лету прямо из CP/M или DSDOS.
Всему своё время, до флэшек тоже доберёмся, если это будет актуально.
С флэшкой есть одна проблема. В процессе её программирования необходимо читать код ответа (статус прошивки сектора), т.е. менять направление передачи ШД. В стандартном подключении ROM-диска используется ВВ55, которая при перепрограммировании режима (в нашем случае направления передачи) обнуляет линии всех своих портов. Т.е. для корректной работы придётся заводить управляющие сигналы на флэшку с другой ВВ55...
Error404
29.08.2016, 17:58
А у меня тупо запас этих 27С801. А флешек нету. Как говорится, бытие определяет сознание. :)
OrionExt
29.08.2016, 18:37
Вот и мое бытие определило сознание, после покупки программатора:v2_smile:. Теперь репу не чухаю:v2_dizzy_wall:, как же запрограммировать этих тараканов. При такой цене этот программатор даже клонировать не имеет смысла. Дешевле не выйдет сделать.
Кстати M27C801 (два плюс два) заказал у китайцев. Посмотрим, что приедет.
Error404
07.09.2016, 21:15
Сделал корректировки в ПЗУ ROM1 (минимальные, планирую еще тамошний начальный загрузчик IDE позже переписать более грамотно) и ROM2 (существенные) - добавил возможность загружать Альтаир-ДОС штатным загрузчиком. Добавил ту самую подпрограмму 0F834 (чтение сектора) (http://zx-pk.ru/threads/25327-periferiya-quot-orionpro-quot.html?p=883972&viewfull=1#post883972), ничего при этом не поломав (как я надеюсь) и не отменив. Заработали штатные загрузчики MBR и BOOT-сектора раздела Альтаир-ДОС, правда в MBR пришлось воткнуть пару NOP чтобы на адрес 002Fh попало число 01 (номер страницы куда ПРО-шный BIOS грузит с диска), соответственно на два байтика в MBR поправился и образ с которого грузимся (https://drive.google.com/file/d/0B3S0wVWNPLrwaV8zWTBKcUxlMlk/view?usp=sharing) (я туда FDISK-ом уже запилил обновленный MBR).
Возможность загрузки остальных ОС штатным загрузчиком сохранена (но не проверялась).
В ROM2 также до кучи залит "микроромдиск" с TESTDEV для контроллера PRO, MBOOT.
Естественно, это не отменяет необходимости правки BIOS самой Альтаир-ДОС в HDD-образе (подпрограмм работы с IDE по варианту PRO, а еще лучше сделать универсальный), в настоящее время она грузится в меню MBR, оттуда загружается BOOT-сектор выбранного раздела, который грузит в память код ОС, ОС стартует и выводит счетчик памяти, но далее по обращению к диску выводит "BadSector" (что и логично при неправленном BIOS).
Error404
08.09.2016, 19:53
Естественно, это не отменяет необходимости правки BIOS самой Альтаир-ДОС в HDD-образе (подпрограмм работы с IDE по варианту PRO, а еще лучше сделать универсальный), в настоящее время она грузится в меню MBR, оттуда загружается BOOT-сектор выбранного раздела, который грузит в память код ОС, ОС стартует и выводит счетчик памяти, но далее по обращению к диску выводит "BadSector" (что и логично при неправленном BIOS).
Ну, в-общем сделал те правки для PRO-шного IDE, в эмуляторе работает.
Пока что на условной компиляции (т.е. или IDE8255 на порту F600 или IDE-RTC от PRO). Универсально (чтобы оба одновременно) - слишком долго, но по прежнему в планах.
Образ диска для загрузки тут (https://drive.google.com/file/d/0B3S0wVWNPLrwVHZuT2dEUkd4X1k/view?usp=sharing)
Исходники ОС и ROM-ы для ПЗУ1 и ПЗУ2 с последними правками на GitHUB (https://github.com/serge-404/AltairDOS)
IDEBDOS там тоже поправленный - от ksanf(138)
Дмитрий2012
08.09.2016, 19:57
в настоящее время она грузится в меню MBR, оттуда загружается BOOT-сектор выбранного раздела, который грузит в память код ОС, ОС стартует и выводит счетчик памяти, но далее по обращению к диску выводит "BadSector" (что и логично при неправленном BIOS).
Попробовал на реале. У меня загрузка зависает на экране с надписью SECTOR 26, при этом на IDE контроллере постоянно горит светодиод. До счетчика памяти даже не доходит.
Error404
08.09.2016, 20:03
Попробовал на реале. У меня загрузка зависает на экране с надписью SECTOR 26, при этом на IDE контроллере постоянно горит светодиод. До счетчика памяти даже не доходит.
А попробуй сегодняшнюю версию. Заранее предупреждаю: надо использовать те прошивки ПЗУ для ROM1 и ROM2 что лежат на GitHUB (*-321*). С другими прошивками может не запуститься. Ну и других правок в сегодняшней тоже было - не относящихся к ПЗУ, а некоторые ошибки которые раньше могли не проявляться.
Я в эмуляторе пока что делаю. На реале столько перекомпиляций и проверок сделать не реально. Но в выходные буду пробовать. :)
Дмитрий2012
08.09.2016, 20:34
А попробуй сегодняшнюю версию.
У меня не работает. ROM1 и ROM2 брал на GitHUB, образ диска из этого поста http://zx-pk.ru/threads/24285-orion-pro-softvernye-dela.html?p=884732&viewfull=1#post884732 Симптомы те-же. Только теперь зависает с надписью на экране SECTOR 25 и также постоянно горит светодиод. Гружу с CF карты. Надо, чтобы еще кто-нибудь проверил на реале.
ksanf(138)
09.09.2016, 16:23
В общем ,скомпилил я эту сборочку с ГитХаба на дискеточку. Ну что, всё работает, иногда сбоит,вылетает после обращения к жёсткому.
Всё то же самое, что и с теми образами, что я выкладывал.
В эмуляторе - BAD SECTOR.
- - - Добавлено - - -
Странное дело! А IDEBDOS в эмуляторе работает. FDISK разделы образа видит.
Error404
10.09.2016, 10:57
В общем ,скомпилил я эту сборочку с ГитХаба на дискеточку.
А загрузку с IDE не пробовал?
С ПЗУ *321* из этого же каталога на ГитХаб?
ksanf(138)
10.09.2016, 12:07
Ну , с загрузкой с IDE у меня уже другая эпопея... Не, ну загрузчик грузит, что я могу сказать.
Вопрос в другом - почему комп сбоит иногда (!) после обращения к жёсткому. Особливо на чтении каталога гуси улетают порой.
И - почему не работает в эмуляторе?
Error404
10.09.2016, 12:53
Эмулятор я прошагаю, разберусь. Вопрос нескольких дней (когда выбиру время, я сейчас плату AY запускаю).
А к каталогу просто больше всего обращений, вот статистически на нем оно и обламывается, а причина - в железке ИМХО. У меня например есть две абсолютно одинаковые CF-карты на 64М (с соседними серийниками даже), так вот на РС работают обе, а в контроллере ПРО - только одна из них. :)
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot