Т.е. всего 2232 файла - максимум возможного.Цитата:
Сообщение от shattered
В этой ситуации добавить записи уже нельзя, поэтому в общем случае - скопировать файл на такой диск невозможно.
Вид для печати
Т.е. всего 2232 файла - максимум возможного.Цитата:
Сообщение от shattered
В этой ситуации добавить записи уже нельзя, поэтому в общем случае - скопировать файл на такой диск невозможно.
Точно. Исправлю код так, чтобы помещался только 2231, или даже 2230.
---------- Post added at 16:57 ---------- Previous post was at 15:42 ----------
И можно приступать к сборке архива игрушек, для чего, собственно, все и затеяно :-)
Только выяснилось, что dosbox портит время у файлов без патча -> http://vogons.zetafleet.com/viewtopic.php?t=22600
Вот, нашел кто проверяет home block.
При автоинсталяции системы определяются диски со стандартным home block (но не RT-11) и они отмечаются как непригодные для автоинсталяции.
В моем случае диски DU0 и DU1 на которых FILES-11 пропустились и для установки предложен DU2 на котором XXDP+ записан.
Патч (лицензия BSD): https://gist.github.com/shattered/5465119
Как работает COPY/BOOT (из DHM, стр. 1-87 [100]):
Цитата:
Use the COPY/BOOT xxn:filnam ddm: to copy the secondary bootstrap from the
monitor file on device xx to blocks 2, 3, 4, and 5 of device dd. In the command line,
xx represents the device on which the monitor file is stored; n is its unit number; dd
represents the 2-character name of the device that is to receive the bootstrap; m is
its unit number.
As soon as this command is issued, DUP checks that devices xx and dd are random-
access devices. Next, it locates the monitor file filnam.SYS on the xxn: device. It
reads blocks 1 through 4 into a memory buffer [1]. These blocks contain the secondary
bootstrap for the monitor.
DUP locates the appropriate handler file on device dd. DUP then reads block 0 of
the device handler file into a memory buffer [2], using the contents of locations 62 and
64 to locate the primary driver, and reads it into a memory buffer [3].
The handler for the system device dd must already be located on dd before you can
copy the bootstrap to the device. DUP loads two words of Radix–50 for filnam into
locations 4724 and 4726 of the memory buffer [1]. Next, DUP copies the primary driver
into block 0 of device dd. Finally, DUP writes the secondary bootstrap to blocks 2
through 5 of device dd.
Две маленьких детали для тех, кто захочет это (COPY/BOOT) воспроизвести:
- location 4724 -- смещение от начала файла монитора
- putr.asm заполняет еще локации 4716 и 4730
Код:; the next few patches aren't in SSM but someone did them, must be DUP
mov es:4730,dx ;set B$READ = B.READ offset
mov ax,ds:rtfile ;set B$DEVN = dev name
mov es:4716,ax ;(hope this is right!)
переписал все это под MAME, в следующем релизе imgtool будет уметь читать образы MX/MY дисков -- https://github.com/mamedev/mame/blob...dules/rt11.cpp
сравнил с rt11dsk "[Apr 14 2013 18:41:37]" и PUTR, нашел отличия:
- rt11dsk: считает E.TENT файлы за полноценные и они попадают в список
- rt11dsk: считает даты 20xx неверными
- putr: неверно считает смещение первого файла на одном из образов
Еще один инструмент -- https://gitlab.com/NF6X_Retrocomputing/pyRT11