"Начиная с ревизии 1989" + "начиная ревизии 1992" - я ещё раз внимательно пересмотрела изменения, нашла ровно одно отличие: для полного соответствия в core/dll.inc:irq_serv.main после вызовов call [{fdc,irq14,irq15}_func] должно стоять mov [check_idle_semaphore], 5 - это влияет на планировщик. Когда maximYCH поправит всё, что он напортил, я залью изменение, пока что желающие могут попробовать так.

Выяснить, почему что-то не работает в Bochs, обычно довольно легко - нужно запастись несколькими сотнями свободных метров на диске, добавить в bochsrc строку "debug:action=report" взамен умолчальной "debug:action=ignore" и изучить полученный лог.
Дискета не работает по следующей причине: код записывает 0 в порт 3F2 - это переводит контроллер в состояние сброса, бит 2 = 0. Потом код записывает 1C/2D туда же - это переводит контроллер в рабочее состояние, бит 2 = 1, и инициирует собственно сброс. По окончании сброса генерируется прерывание, которое никто не обрабатывает. PCIное прерывание такого бы не потерпело, но ISAшное просто тихо отказывается генерировать дальнейшие прерывания. Решение, очевидно, - создать функцию инициализации, которая и будет переводить контроллер в рабочий режим, а при основной работе не сбрасывать контроллер. На реализацию я не располагаю временем.

Через пару часов будет.
И ничего _я_ не портил Я лишь не учел особенностей автосборщика, а точнее его привязанности к путям некоторых файлов.

А что, автосборщик должен обладать искусственным интеллектом и ухитряться выяснять, куда делись файлы, даже после переименования и перемещения? При этом выбирая правильный вариант, если их несколько? И более того, на лету исправлять порушенные зависимости, из-за которых обламывается fasm при существующем главном файле?

CleverMouse
Спасибо за разъяснение. Всё больше люблю Bochs, несмотря на его некоторую угловатость в плане использования.

2103 - makefile обновлены, автосборка должна работать нормально, ошибок в логе нет

qemu тоже поддерживает трэйсинг - опция "-d cpu,exec, in_asm" - вывод может варьироваться.

XVilka, в Bochs не трейсинг, в Bochs конкретные записи отдельных устройств о том, что происходит, типа "[FDD ] write access to port 0x03F2, value=0x00" и "[FDD ] controller reset in software".
maximYCH, ну зачем было гробить svn-историю перемещённых файлов?

CleverMouse, что именно я погробил?

В принципе, можно поправить, тупо удалив на сервере последние ревизии. Тем, кто ещё не обновлялся, повезёт

Сравни http://redmine.kolibrios.org/projects/k ... kernel.asm и http://redmine.kolibrios.org/projects/k ... kernel.asm . А также http://redmine.kolibrios.org/projects/k ... kernel.asm и http://redmine.kolibrios.org/projects/k ... kernel.asm .

mike.dld, можно и не столь радикально, svn remove include/kernel.asm && svn copy kernel.asm@2100 include/kernel.asm && svn commit. Но гробить-то зачем было?

mike.dld, можно и не столь радикально, svn remove include/kernel.asm && svn copy kernel.asm@2100 include/kernel.asm && svn commit. Но гробить-то зачем было?

1. Мне может кто-нибудь объяснить, что я погробил?
2. Блин, я первый раз SVN пользуюсь.
3. Если скопировать kernel.asm@2100, то работать не будет потому что были изменены пути к подключаемым файлам + при загрузке (если lang eq ru) число памяти и значение частоты процессора "поедут" в сторону, ибо там ещё до меня мега костелем сделано было, пришлось подстраиваться.

Если мне объяснят, что не так, я попробую исправить.

maximYCH
1)Ты погорячился, запихнув kernel.asm init.inc data32 data16 в /include.
2)Содержимое заголовка kernel.asm было причиной эпичнейшего срача на форуме. Ветераны должны помнить. А ты его одним махом.