Вид для печати
На PLI утилиты писали. А СПМ десятки Source файлов. Завтра найду. Хоть в сети, хоть у мя.Цитата:
Сообщение от Error404
- - - Добавлено - - -
Недавно собрал под TASM СПП, БДОС ( как мя достали эти ассемблеры со своей лексикой). Отличия в 10 байт. Для Орион-128.
У меня две линейки тестов быстродействия - с использованием кадровых прерываний и с использованием таймера. Таймерные варианты лучше (работают быстрее, шире диапазон измерения), просто таймер не на всех компах есть.Цитата:
Сообщение от Error404
DRI писали на PLI - и ОС (включая V3 и MPM) и утилиты, пускай и кой-где с ассемблерными вставками, вот тут исходники их есть:Цитата:
Сообщение от OrionExt
http://www.cpm.z80.de/source.html
Все полностью ассемблерные варианты - это декомпиленные версии, в том что они компилируются в код значительно совпадающий с классическим BDOS включая его баги - ничего удивительного в этом нет, любую программу можно декомпилировать, затем компильнуть и оно будет совпадать.
А с каким дистрибутивом Ориона сравнивалось?Цитата:
Сообщение от OrionExt
Попробовал в одном из "старых" векторовских cp/mов заменить в чтении 14h на 21h - это не решает проблему, все равно читает 512 Кб и выдает код 04h Reading unwritten extent (a 16k portion of file does not exist).Цитата:
Сообщение от Error404
OS-DOS48 V2.31 200492Цитата:
Сообщение от Error404
Странно, в исходнике оно при режиме прямого позиционирования вроде обходит проверку (где-то попадалось на глаза). Возможно не все проверки обходит, конечно, т.к. мои примерчики через прямое позиционирование что-то тоже не отработали.Цитата:
Сообщение от ivagor
Попробовал сегодня "бомбануть наудачу" и увеличил (прям виндой - в образе, HEX-редактором) в процедурах послед. чтения маску обслуживаемых экстентов на пару бит (т.е. в 4 раза), в итоге текстовый файл размером 670кб последовательным чтением (фукция BDOS 14h) после этих правок прочитался до конца (чего раньше не происходило, обламывалось на 512кб). Непонятно - нафига оно вообще сделано???
Так что можно попробовать плеером с последовательным чтением (т.е. тем что был ранее как я понимаю) проигрывание более крупных (чем 512кб) WAV - а вдруг на поправленной ОС проканает?
Запись больших файлов не проверял: смысл это делать есть только в эмуляторе (плагин то понятно пишет и читает - ему на баги старых CPM пофиг), но терпения уже нету ждать пока оно разродится. :)
Поправленный образ тут (для экспериментов, грузиться с него без каких-либо изменения в образе, пробовал эмулятором как Орионом-128, так и Орионом-ПРО):
https://drive.google.com/file/d/0B3S...ew?usp=sharing
Итого поменяны 3 ячейки (адреса от начала образа, т.е. считая и MBR), не помню после какой из этих правок заработало:
132AH : 1F->7F
157CH : 1F->7F
1597H : 0F->03
Вот как оно выглядит в исходнике:
Во вложении исходники CP/M (ассемблерные, т.е. декомпилированные, но декомпилировавший проделал гигантский труд по комментированию, весьма подробному), те фрагменты что я смотрел, с BDOS от Альтаир-ДОС совпадали (по крайне мере в части файловых операций).Код:;
; 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
;
Интересно, "пропатчил" рамдисковый проигрыватель и он в этом альтаире с использованием 14h прочитал весь файл 676Кб (c 21h не весь).
Да, в этом и вопрос: зачем авторы BDOS изначально сделали искусственное ограничение - переполнение счетчика экстентов файла не по заполнению всего байта (что даже и проверяется проще - тупо во флаге переполнения), а ограничили пятью битами? Я для перестраховки (и простоты патча) только до семи бит расширил - чтобы не трогать статус флага переполнения CY (и мало ли может где в другом месте они в старшем бите что-нить смотрят). Этот "странный" алгоритм как мне кажется возник вследствие того, что BDOS изначально писан на языке высокого уровня, причем языке достаточно абстрактном и при этом не особенно наглядном (в отличие от, к примеру, С).Цитата:
Сообщение от ivagor
Я так понимаю, эти куски абсолюно одинаковые во всех реализациях BDOS от 2.2, и их тупо по сигнатурам можно найти (как я и искал в альтаировском варианте) и попробовать поправить например в векторовских реализациях где есть ограничение в 512кб.
На счет неработающей 21h: таки да, похоже тоже надо патчить - надо тоже посмотреть в исходнике как оно там реализовано (сразу не полез, не люблю разбираться в битовых операциях на сдвигах, а их там есть).
- - - Добавлено - - -
В-общем, еще слазил я в проверки, которые делает ф. 21h. Образ диска с "ручными правками по живому" тут:Цитата:
Сообщение от ivagor
https://drive.google.com/file/d/0B3S...ew?usp=sharing
Вот что поменял чтобы и при произвольном доступе была маска количества экстентов 7 бит вместо 5 (т.е. макс. размер файла 2мб вместо 512кб):
поменял такие ячейки (адреса от начала образа, т.е. считая и MBR):
172CH : 1F -> 7F
172FH : 1F 1F 1F 1F E6 0F -> 07 07 00 00 E6 03
Вот как оно выглядит в исходнике:
Теперь наконец то я смог выполнить (ранее DED.COM обламывался с чтением файла на границе в 512кб) то, о чем ранее упоминал на вопрос от OrionExt "как залить образ не имея на РС дисковода":Код:;
; 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.
;
на IDE диск (CF,SD) скидываем образ дискетки (800кб) и за одно действие посекторно копируем его целиком на дискетку (дискетка должна быть заранее форматирована на Орионе же, желательно на 80+ треков {форматерами SF.COM, F83.COM, и т.п.}, содержимое ее 80 первых треков затем перезаписывается из файла c более емкого CP/M-диска, например IDE, где лежит образ дискетки для заливки). Залил Орионом утилитой DED.COM образ с IDE на гибкий диск (эмулятором естественно), затем проверил под виндой подопытный образ диска с образцовым - совпало. :) А раньше не работало, т.к. DED читает при помощи ф.21h (так делалось для копирования файла в треки в случае единственного привода на всю система (дисковода) - меняя диски ручками, т.е. в древнючие времена для небогатых парней: DED умеет "вставьте источник"-"вставьте приемник", а когда дело идет на двух приводах, понятно, ничего не спрашивает, но по-прежнему читает файл-источник через ф.21h)
Это я пока не пробовал, а в предыдущем варианте выявились некая особенность поведения с hdd. Проблема выглядит примерно так: если записать на hdd подряд несколько больших файлов, то с некоторого момента (возможно если их суммарный объем превысит 2 Мб) вместо последних записанные файлов (которые могут быть хоть маленькие, хоть большие) дос читает нечто левое (похоже на фрагмент программы). Проблема именно в досе, плагин обратно из образа копирует все файлы правильно. С дискетой проблем нет, все равно туда только один "большой" файл влезает.Цитата:
Сообщение от Error404
Круть. К осени я подключусь. Как фулл Орион соберу. Забодаем СР/М 2.2=)
Да, есть такой эффект. Закинул сейчас на диск 4 файла по 650кб, первые три читаются нормально, а четвертый - "улетает". Трудно сказать почему.Цитата:
Сообщение от ivagor
Вообще, там еще процедуру COMPRAND надо пропатчить (сегодня просматривал и увидел что там тоже ковыряния с номерами экстентов), но вроде оно на последовательное чтение не должно влиять. Впрочем не поручусь, накручено там много, и лишнего в том числе, все взаимодействия не угадаешь - надо пропатчить COMPRAND, и посмотреть - поможет ли это.
Жуть. Во дело пошло. Я вас подбадриваю). Мне в сентябре нечего будет делать.
На вид явный заворот адреса. Это как слет LBA48 на дисках более 120ГБ под XP до SP1/SP2. Слет на LBA32 херил все на диске по причине затирания начала при завороте адресов. В вашем случае, это можно попробовать определить, загрузив файлы с определенным содержимым (текстом) и посмотреть что выведет ДОС при глюке.
Видимо, для обратной совместимости. Почитай на досуге вот это: http://www.seasip.info/Cpm/format22.htmlЦитата:
Сообщение от Error404
Скрытый текст
Код: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, там на сайте про это есть.
Эти описания такие описания...Цитата:
Сообщение от b2m
Штука в том, что
"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:
правки в COMPRAND не повлияли.Цитата:
Сообщение от HardWareMan
Да, похоже на заворот адреса - вместо четвертого файла, оно начинает читать каталог (т.е. нулевой экстент).
Но вот что мне не ясно - почему оно на разных файлах имеет как бы "продолжающийся счетчик" (который и заворачивается)? Когда переменные все инициализируются при открытии файла, т.е. счетчик экстента каждый раз должен начинаться с нуля. Я бы понял если бы файл был более 2мб и по оно заворачивалось по границе в 2мб (т.к. я порушил разрядность в сторону увеличения размера до 2мб). Но первые то три отдельных файла читаются нормально, и каждый - от начала и до конца (конец тоже определяется). Шиза какая-то.
Вот комментарий из исходников:Цитата:
Сообщение от Error404
Максимальный номер записи 65535.Код:; 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'
Покопался в исходниках - вроде всё должно работать. Если не работает, надо проверять DPB.
- - - Добавлено - - -
А размер каталога не 4Кб? А то для 4-х файлов по 650Кб надо как минимум 5.2Кб.Цитата:
Сообщение от Error404
Ну окромя относительных адресов-счетчиков есть еще и абсолютный. О чем и была речь в моем сообщении. На примере все тех же HDD, LBA это уже метрика самого диска. Какой разрядности абсолютный счетчик ДОС? Для дисковода, я так понимаю, это CHS формат.Цитата:
Сообщение от Error404
Да, есть такой комент, он страницей раньше в моем посте даже есть. :)Цитата:
Сообщение от b2m
Там все очень коряво: эти переменные (экстент 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 бит) - и "на наш век хватит". Ан нет, где-то "совместители" еще одну (а может и не одну) "мину подложили под наше молодое государство" (с) главстерх
Размер каталога - одна группа (меньше не сделаешь), т.е. 16кб. Т.е. в теории в такой каталог должно влезать 16384/32=512 файловых дескрипторов, *8=4096 групп, *16=65536кб (64Мб) дискового пространства, плюс системные треки. Размер партиции/ФС совпадает - 64Мб (или даже меньше, не помню - образ на рабочем компе).Цитата:
Сообщение от b2m
- - - Добавлено - - -
Если про BIOS, то для IDE/SD в глобальном адресе (по всей поверхности носителя) поддерживается 32-битный LBA секторами по 512 байт. Который внути каждого конкретного раздела слегка уменьшается в разрядности за счет работы 128-байтными блоками. Но все равно этих секторов там "номер трека"(16 бит)*"номер сектора"(16 бит). Т.е. в разрядность CP/M-овского 16-битного произвольного адреса записи попадает гарантированно даже в комбинациях (1трек на 65536 секторов) или (65536 треков по 1 сектору). Да и заворачивается оно не на нулевой сектор раздела, и не на нулевой сектор целого диска, а на нулевую группу (группа - это сугубо понятие BDOS, она может начинаться и не от начала раздела, собственно в данном образе так и есть) т.е. уже после системных дорожек текущего раздела. Где-то в BDOS какашка.Цитата:
Сообщение от HardWareMan
Конверсии выходного дня - две игрушки с msx (в imsx они не работают, т.к. напрямую обращаются к портам). Клавиши управления описаны в readme. Запускать из PRODOS. Поддерживаются (на автоопределении) оба варианта дешифрации AY (Пушков и zx).
Очередное большое спасибо Дмитрию2012 за проверку на реале и выявление неприятного бага!
Прикольно. Но кажется, немного быстровато...
- - - Добавлено - - -
Вообще-то, функции прямого доступа к записи (блоку из 128 байт) просто конвертируют 16-битный номер записи в те самые extra_extent, EX и номер записи 0-127. А потом вызывают всё те-же функции чтения/записи. Больше этот 16-битный номер нигде не используется.Цитата:
Сообщение от Error404
Да нет, основной способ доступа именно через те самые extra_extent, EX и номер записи 0-127. Поиск в каталоге осуществляется по номеру юзера, имени файла, 5-ти битам номера экстента и тому самому расширенному номеру S2, благо они все рядом, в пределах 15 байт. Функция поиска на входе имеет количество байт, которые нужно сравнивать. Это либо 12, для простого поиска первого попавшегося, либо 15, для поиска с нужным номером экстента (функция сравнивает номер экстента накладывая маску, которую ты хакнул, и пропускает байт S1).Цитата:
Сообщение от Error404
Функции последовательного чтения/записи после обмена с диском увеличивают номер записи, а если надо и номер экстента, а также расширенный номер (проверяя при этом, чтобы расширенный номер не стал больше 16, в противном случае выдаёт ошибку). Можно в отладчике посмотреть, что происходит после чтения 512кБ. ivagor, у тебя есть готовый образ диска, чтобы посмотреть?
b2m, если бы оно работало как ты пишешь (а я так понял ты считаешь что ошибки в BDOS нет, просто мы тут что-то неправильное ей подаем на вход), то BDOS (еще не правленная) записывала бы файлы и более 512кб, когда я (пользователь) их пытаюсь записать (а я таки пытался). Но вместо этого она обламывалась на 512кб, точно так же как и при чтении. Т.е. дело не в том как файлы записаны на диске (моим плагином или еще как-то), а в том что в BDOS ошибка в реализации, и чего там понаписано в описаниях - тоже могут быть только фантазии из серии "как оно должно бы быть". На практике, никто большие файлы не проверял (кроме нас, и еще пары человек в Инете, т.к. это было давно, в эпоху носителей-маломерок), и реально работает только адресация по номеру экстента и все. Тут или отлаживать чужие ошибки (которые могут быть и в самой логике построения этой унылой "математики" с кучей счетчиков где должен быть один), или переписать кусок - отказываться от нафиг ненужного S2 (а обойтись единым счетчиком - одним увеличенным EX как и подсказывает банальный практицизм, вместо маразма с ведением двух счетчиков да еще и перепаковывя их в разное количество байт), или (к чему я склоняюсь) - взять переписанный бдос уже без всего этого бреда (а такие у меня на примете есть, просто хотелось обойтись малой кровью - типа "поправить десяток байт и оно вдруг заработает").
А ты считаешь, что за 30 лет никто так и не заметил ошибку? :)Цитата:
Сообщение от Error404
Не только заметили, но и переписали BDOS, т.к. {цитирую по памяти} "проще было переписать".Цитата:
Сообщение от b2m
Есть у меня архив переписанной 2.2, причем уже в коде Z80, меньшего размера (что дало автору впихнуть в сстандартный объем еще и код для поддержки дат файлов, каталога по умолчанию и т.п.), и одно из упоминавшихся в описалове - он писал что исправил ошибки в файловом доступе в стандартной 2.2, что дало увеличение максимального размера - как ФС так и файлов (до математического предела, а не до бага). Конечно, все это надо проверять, т.к. делано это опять же еще до эпохи дешевых "народных" HDD.
- - - Добавлено - - -
Если память не подводит, вроде вот это оно:
http://www.gaby.de/ftp/pub/cpm/znode...ssrc/zsdos.htm
Там есть кнопки F1 и F2 для выключения/включения турбы (readme.txt). Музыка в турбе точно слишком быстрая, но в сложных (для движка) местах без турбы грустно.Цитата:
Сообщение от b2m
- - - Добавлено - - -
Есть, но я сегодня не дома, только завтра смогу выложить. У Errora404 тоже есть такой образ.Цитата:
Сообщение от b2m
Ну, господа, если вы используете что-то своё, а не CP/M 2.2, то конечно, оно у вас может и не работать :)Цитата:
Сообщение от Error404
Я вот не поленился, набил программу, которая записывает 1100h записей (544Кб) последовательно, а потом читает записи с номерами 0FFFh и 1000h. Тестировал на Корвете (там CP/M байт в байт как на Башкирии, но у Башкирии один логический диск всего 384Кб). Так вот считалось именно то, что я и записывал (а именно - 16-битный номер записи).
И в каталоге именно так, как и должно быть - номера экстентов: ... 00.1E 00.1F 01.00 01.01 ...
Моть вообще 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 раза потом сдвиг делать?
Все зависит от того, сколько бит в екстенте. Если вот это верно:
то сдвигов должно быть всего 4 а не 5. И тогда, либо первый RLA должен быть после PUSH AF (т.е. два байта поменять местами) либо один RLA после POP AF убрать. Возможно это ошибка разрабов и изначально все должно было быть по первому варианту. А оошибку сразу не выявили потому что не было столько объемов. Или я не прав?Код:; 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'
PS Я вот думаю, может натянуть какую досю на мой МХ2?
- - - Добавлено - - -
Стоп, а сдвиг то влево а не вправо. Причем через С. Так что 5 это нормально.
А действительно. Долбанные Z80-мнемоники :)Цитата:
Сообщение от HardWareMan
- - - Добавлено - - -
Короче, надо в отладчике смотреть. В теории вроде всё верно. Жду образ.
Используется BDOS который цельнотянутый на всех CP/M Ориона, откуда его утянули - сие тайна великая есть, но живет оно вот в таком вот виде с одна тысяча девятьсот мохнатого года. И код там для 8080, тремя страницами ранее есть исходники, тоже не моего производства (архив с двумя файлами - в мнемониках 8080 и Z80) - я их взял иллюстрировать свои мысли как наиболее хорошо комментированные исходники, т.к. те фрагменты что я правил, с этим исходником совпадали (за другое не поручусь) - тремя страницами треда ранее. А то что ты смотришь сейчас, это то что я как перспективное указал (а не то что использую), читай внимательнее. Оно в коде для Z80 (глянул в код в спойлере, а там индексные операции, лол).Цитата:
Сообщение от b2m
Потестировал чтение/запись под PRODOS, нет вроде никаких проблем с файлами больше 512Кб. Дайте уже то, что у вас не работает!
Ну, наверное вот это быстрее всего можно взять (там в первой партиции CP/M):Цитата:
Сообщение от b2m
https://drive.google.com/file/d/0B3S...ew?usp=sharing
Остальное я уже покоцал своими правками. :)
- - - Добавлено - - -
Ну тут я никак не могу подтвердить или опровергнуть, я ее пока не юзал. Вроде Ivagor как раз на ПроДосе файлы делил т.к. оно большими не работало?Цитата:
Сообщение от b2m
- - - Добавлено - - -
Или вот еще дисководный вариант
Может я чё неправильно делаю, но вот три теста:
1. test пишет файл размером 544Кб, каждая запись заполнена собственно номером записи
2. читает произвольным доступом две записи на границе 512Кб
3. читает последовательно 544Кб
Выполнять лучше под отладчиком, чтобы контролировать результат, т.к. тесты очень простые и ничего на экран не выдают.
Всё работает, как и задумывалось. Где ошибка?
Вложение 57701
Не знаю где ошибка, посмотрю завтра на работе, дома нет годной инфраструктуры. :)
Я последовательную запись не проверял. Я проверял на произвольной записи, утилитой DED, где оно обламывалось на границе 512кб.
А можешь записать в файл 3мб и скинуть сюда образ с этим файлом?
Вот твой образ, игрушки потёр, записал 3.МВ: altair3mbfile.rar
Попробовал test и test3 в продос - все ок. Кажется я догадываюсь, почему у меня на 512 Кб стопорилось, завтра проверю, может даже утром успею.Цитата:
Сообщение от b2m
Забавно, что odiwcx (какая-то старая версия, здесь я новую не ставил) видит в 512.KB только 512КБ. А просмотрщиком видна и остальная часть файла.
Плюс, я поправил еще одну ошибку в ODI.WCX, по файлу от b2m - файлы размером более 512кб у меня паковались не ограничивая поле экстент (EX, FCB+12) по модулю 32 с переносом в S2, а инкрементировался EX вплоть до 255 (видимо, из соображений простой человеческой логики :) ).Цитата:
Сообщение от ivagor
Ivagor, перепакуй пожалуйста большие файлы в используемом образе дисков новой версией плагина (перед запуском TC/DC надо удалить все старые - odi.wcx, odi.wcx0, odi.wcx1, odi.wcx2, odi.wcx3)
- - - Добавлено - - -
Однако ж запись (и чтение) с прямым позиционированием через ф.21h/22h (утилитой DED) все одно обламывается на 512кб. А оно там просто делает, через инкремент номера записи в FCB+34+35 и обращения через фф произвольного доступа (а он должен бы работать, там тупо инкремент 16-битного числа, битики сами складывася как надо, а уж система потом внутри себя маскми раскидывает в EX и S2). Тоже понять бы где собака порылась.
- - - Добавлено - - -
да, образ использовать такой, где система БЕЗ моих ручных патчей на увеличение разрядности EX
Вот это помогло! Теперь файлы >512 Кб записанные в образ плагином читаются нормально (пробовал по 14h и моя "догадка" оказалась ни при чем). Правда пробовал не в про, а в векторе (comanовский cp/m 59), но я думаю это не принципиально.Цитата:
Сообщение от Error404
Теперь бы еще с подряд записанными большими файлами на hdd разобраться.
- - - Добавлено - - -
Вот образ для примера. Там в user 4 несколько больших файлов (плеер в эмуляторе не работает). Начиная с bach44.wav дурит.