Спасибо огромное, попробую. Удивительно, что БК0011 читает прекрасно, а вот БК0011М почему то только замедленное в 2 раза...
Вид для печати
К сожалению, причина другая. Емкость не возимела ни какого эффекта, так же - идеально грузится все в 11 и 10, а в 11М только замедленное в 2 раза...
А если время работы ЗУ немного меняется, то калибровка сбивается, правильно я понимаю? Тут же речь идет о програмной эмуляции ПЗУ, то есть, плюс минус может меняться время выдачи информации. Хотя, для STM32 c ее 120мгц мне кажется совсем не сложно вовремя выдавать информацию на выходы, тем более, что автор ре-мулятора говорит, что тайминги ре-мулятора соответствуют таймингам 1801РЕ2A.
Цитата: "Пооптимизировал основную процедуру ремулятора (обработка сигналов МПИ), в итоге получилось время выборки в пределах 250-300нс. По крайней мере не хуже чем у оригинальной 1801РЕ2А с ее паспортными 300нс."...
Вот тут обратите внимание может ли "толщина" ответа приблизительно в 50 нс выступать в роли нестабильности времени работы ЗУ ? Нужно попробовать разогнать STM32..
Ну тогда у меня есть такое предположение.
Вот как читает байт классическая п/п драйвера магнитофона БК10:
Вот как читает байт п/п драйвера магнитофона БК11:Код:; Вход: R1 - адрес ОЗУ
; R2 - длина блока
PCTBL: mov #10, R0
3$: call PCTBIT ; читаем бит
cmp R4, GRDL0
bhi 1$
clc
br 2$
1$: sec
2$: rorb (R1)
sob R0, 3$
add INCADR, R1
sob R2, PCTBL
return
; End of function PCTBL
переключение страниц делается между прочитанными байтамиКод:GetDaX: Add IncADR,R1 ;Go next Address
Bit #140000,R1
Beq 10$
Add #2,AdrSel
Mov @AdrSel,@R3 ;Set New Sel1 Value
10$:
GetDat: Bic #140000,R1
Mov #8.,R0 ;Bit per Byte Counter
10$: Call GetBit ;Get Data bit
Cmp R4,BitLng ;Check bit Value
Bhi 20$
Tst (PC)+ ;Zero, Clear Carry
20$: SeC ;One, Set Carry
30$: RorB Window(R1) ;Shift Data bit in
Sob R0,10$ ;Byte loop
Sob R2,GetDaX ;Data Block Loop
Return
А вот как читает байт п/п драйвера магнитофона БК11М:
ненужное переключение страниц делается каждый бит. Из-за чего быстродействия может тупо не хватить.Код:; Чтение блока.
; Вход: R1 - адрес
; R2 - длина в байтах
ReadBlk1$: ; CODE XREF: ReadFile$+46P
; ReadBlk1$+44j
mov #10, R0
loc_156354: ; CODE XREF: ReadBlk1$+36j
call CalcPulse$ ; счёт импульсов
; Выход: R4 - длительность импульса
cmp R4, 42676 ; это что?
bhi loc_156370 ; "1"
tst (PC)+ ; "0"
; ───────────────────────────────────────────────────────────────────────────
loc_156370: ; CODE XREF: ReadBlk1$+14j
sec
loc_156372: ; CODE XREF: ReadBlk1$+16^
mov @#114, @R3 ; подключаем страницы из БП
mov @R3, R4
rorb @R1 ; сохраняем бит
mov #54002, @R3 ; восстанавливаем ПЗУ
sob R0, loc_156354 ; и так все 8 битов
add 42674, R1 ; изменение адреса
sob R2, ReadBlk1$ ; и так весь блок
return
заодно стоит попробовать заоверклочить и проц ВМ1 на 6МГц. Потому что про быстродействие, я имел в виду именно процессор, а не ПЗУ. Две лишние трёхсловные команды могут отожрать достаточно много времени, чтобы успевала слететь синхронизация при чтении на высокой скорости. Ведь как я понимаю, под замедлением в два раза имеется в виду не стандартная БКшкая скорость, а том, высокоскоростной файл, который Manwe подготовил? Или нет? Или мы тут все каждый о своём и друг друга не понимаем?
К сожалению моя БК не запускается на 6 мгц, не подает ни каких признаков жизни, и даже на повышение напряжения питания не реагирует...
В первом сообщении этого форума взял. Вот он, падлец, не грузится как есть...
Сейчас сравнил, дамп, который я слил на БК0010-01 через бейсик - он 56 секунд. Файл который устойчиво загружается (из 1 сообщения увеличенный в 2 раза) - 45 секунд... А файл из 1 го сообщения - 19 секунд... То есть он в нестандартном формате ?