Пока только код от Patron
http://zx-pk.ru/attachment.php?attac...1&d=1359811007
Вид для печати
Пока только код от Patron
http://zx-pk.ru/attachment.php?attac...1&d=1359811007
Сначала лучше загрузку с эмулятора TU58 по С2 наладить - для неё я (в принципе) могу сделать лог всех выполняемых процессором команд.
---------- Post added at 17:09 ---------- Previous post was at 17:01 ----------
А если не грузиться сразу при помощи TU58.SAV, а сначала загрузиться как обычно и дать команду:
DIR/FU/BL/VOL DD:
А потом:
BOOT DD:
---------- Post added at 17:17 ---------- Previous post was at 17:09 ----------
Вообще, насколько я понимаю - разница в работе с последовательным портом между эмуляторами ДВК и УКНЦ в настоящий момент только в том, что в эмуляторе ДВК в принципе невозможен оверран.
Я давал уже раньше здесь код, позволяющий имитировать работу С2 по кабелю с квитированием ( т.е. в принципе без потери байтов ) - пора этот код испытать.
На текущем коде эмулятора (ревизия 482), палитра GRB.
Думаю, этот тест можно считать пройденным.
http://img-fotki.yandex.ru/get/6424/..._7834a066_orig
Beta 38
- Палитра в 128 цветов, из-за этого размер файла скриншота увеличился в два раза
- Интегрирован код работы с COM-портом и код реализации сети через COM-порт от Vamos; работа Стык С2 явно улучшилась; но сеть пока практически не работает
- Для настройки COM-портов сделан диалог редактирования структуры DCB
- Исправление ошибок
http://ukncbtl.googlecode.com/files/...beta38-exe.zip
Благодаря лучшей реализации Стык С2 появилась возможность загрузки и работы с HX Server, связь двух программ на одном PC выполняется через виртуальные порты com0com.
Последняя версия HX Server by Patron: http://zx.pk.ru/showthread.php?p=569515#post569515
Инструкции по настройке: http://zx-pk.ru/showpost.php?p=564797&postcount=160
Запускаем HX Server. После этого запускаем эмулятор, в Settings указываем правильное название и настройки порта. В главном меню УКНЦ выбираем загрузку со Стык С2. Ожидаем загрузки системы.
Выражаю особую благодарность тем, кто активно помогал и содействовал появлению этой версии: Vamos, Patron, Titus и конечно hobot.
У меня сложилось впечатление, что в коде посылки BREAK можно обойтись вообще без Sleep(15)
Код:if (!(m_Port176574 & 01))
{ // BREAK
SetCommBreak( m_hEmulatorComPort );
Sleep(15);
}
Поскольку утилита оказалась востребованной, сделал небольшое улучшение.
Теперь в командной строке можно задать опцию -dcb и указать к ней параметры структуры DCB, например:
UkncComSender.exe COM8 VERT.SAV -dcb "rts=on"
Реализация использует функцию Win32 BuildCommDCB(), которая парсит строку параметров и заполняет DCB: http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspxКод:UkncComSender Utility v1.2 by Nikita Zimin [Feb 3 2013 19:57:55]
Serial port name is not specified.
Usage: UkncComSender [<Options>] <PortName> <FileToSendName>
Options:
-dcb "<DcbParams>"
<DcbParams>:
baud=b
parity={n|e|o|m|s}
data={5|6|7|8}
stop={1|1.5|2}
to={on|off}
xon={on|off}
odsr={on|off}
octs={on|off}
dtr={on|off|hs}
rts={on|off|hs|tg}
idsr={on|off}
http://ukncbtl.googlecode.com/files/UkncComSender.zip
nzeemin, вот с таким ini крашится, не знаю, нужно ли что-то поправлять, без него-то работает =)
Скрытый текст
Код:[UKNCBTL]
Toolbar=1
Keyboard=1
Tape=0
ScreenHeightMode=4
Debug=0
Cartridge1=C:\Documents and Settings\User\Мои документы\Dropbox\УКНЦ\UKNCBTL\roms\ide_wdromv0110.bin
Sound=1
Hard2=C:\hdd.img
Parallel=0
Autostart=0
SerialPort=
SoundVolume=27531
[свернуть]
Помучал еще код эмулятора, добился стабильной загрузки TU58, теперь загрузка из сети проходит до стадии загрузки системы а дальше опять облом с переполнением :( .
http://zx-pk.ru/attachment.php?attac...1&d=1360080317
http://zx-pk.ru/attachment.php?attac...1&d=1360080317
Вот код, эмулирующий работу по кабелю с квитированием и полностью исключающий переполнения:
Код:#include <deque>
std::deque<BYTE> CA_OverrunBuf;
BOOL CFirstMemoryController::NetworkInput(BYTE inputByte)
{
if (m_Port176560 & 0200) // Ready?
{
if( bEmulate_CA_Overrun )
{
m_Port176560 |= 010000; // Set Overflow flag
}
else
{
CA_OverrunBuf.push_back( inputByte ); // Store byte..
}
}
else
{
m_Port176562 = (WORD)inputByte;
m_Port176560 |= 0200; // Set Ready flag
if (m_Port176560 & 0100) // Interrupt?
return TRUE;
}
return FALSE;
}
WORD CFirstMemoryController::GetPortWord(WORD address)
{
switch (address) {
case 0176562: // СА: Регистр данных приемника
case 0176563: // нижние 8 бит доступны по чтению
m_Port176560 &= ~010200; // Reset bit 12 and bit 7
if( CA_OverrunBuf.size() )
{
WORD uPrev = m_Port176562;
m_Port176562 = (WORD)CA_OverrunBuf.front();
CA_OverrunBuf.pop_front();
m_Port176560 |= 0200; // Set Ready flag
if( m_Port176560 & 0100 )
m_pCPU->InterruptVIRQ(9, 0360);
return (uPrev + m_NetStation);
}
return (m_Port176562 + m_NetStation);
}
}
Кстати - при переполнении в регистре данных остаётся старый байт, а не появляется новый.
Дело в том что сеть УКНЦ работает без квитирования и у меня задача чуть больше чем соединить два эмулятора. И проблема на самом деле как я и писал ранее в том что код эмулятора в определенные моменты не успевает за отведенное системным фреймом время сбросить бит готовности, кое что из вашего кода я сейчас попробую, спасибо, есть подозрение что обработка прерываний тормозит.
В любом случае - принятый байт может попасть в регистр данных только если бит готовности сброшен.
Исходник, который я редактировал - содержал ошибку:
Должно быть так:Код:BOOL CFirstMemoryController::NetworkInput(BYTE inputByte)
{
m_Port176562 = (WORD)inputByte;
if (m_Port176560 & 0200) // Ready?
m_Port176560 |= 010000; // Set Overflow flag
else
{
m_Port176560 |= 0200; // Set Ready flag
if (m_Port176560 & 0100) // Interrupt?
return TRUE;
}
return FALSE;
}
Код:BOOL CFirstMemoryController::NetworkInput(BYTE inputByte)
{
if (m_Port176560 & 0200) // Ready?
m_Port176560 |= 010000; // Set Overflow flag
else
{
m_Port176562 = (WORD)inputByte;
m_Port176560 |= 0200; // Set Ready flag
if (m_Port176560 & 0100) // Interrupt?
return TRUE;
}
return FALSE;
}
Так я уже пробовал, только другим способом в результате загрузка останавливалась почти сразу, причем не важно по прерываниям или с проверкой бита готовности работала программа. В случае с СА там происходит переполнение не случайным образом а стабильно в одном и том же месте т.е. вторичный загрузчик из сети уже работает по прерываниям, а вот когда загрузилась RT-11 похоже в момент смены адресов вектора прерывания этот лишний байт и пролезает
http://zx-pk.ru/attachment.php?attac...1&d=1360084655
http://zx-pk.ru/attachment.php?attac...1&d=1360084655
На скорости 57600 при 12 битах на посылку порт СА получает 4800 байтов в секунду, а значит новый байт приходит через каждые 208'000 наносекунд.
Если я все правильно понимаю, то в эмуляторе каждое телодвижение синхронизировано с системным фреймом, и какое бы кол-во байт в сек. не приходило оно будет считываться из буфера строго в определенный момент времени и на выполнение команд процессором отведено времени кратно этому считыванию и если за отведенный промежуток времени на считывание процессор не успевает прочесть приемник то возникает преполнение. Как то так.Код:Каждый фрейм равен 1/25 секунды = 40 мс = 20000 тиков, 1 тик = 2 мкс.
* 20000 тиков системного таймера - на каждый 1-й тик
* 2 сигнала EVNT, в 0-й и 10000-й тик фрейма
* 320000 тиков ЦП - 16 раз за один тик
* 250000 тиков ПП - 12.5 раз за один тик
* Отрисовка 288 видимых строк, по 32 тика на строку (только в первой половине фрейма)
** Первая невидимая строка (#0) начинает рисоваться на 96-ой тик
** Первая видимая строка (#18) начинает рисоваться на 672-й тик
* 625 тиков FDD - каждый 32-й тик
* 52 тиков обмена с COM-портом - каждый 416 тик
* 8 тиков обмена с NET-портом - каждый 64 тик ???
Если 1 мс это 500 тиков, то в порт С2 поступает по одному байту каждые 573 тика ( а не каждые 416 тиков), а в порт СА по одному байту каждые 104 тика ( на не каждые 64 тика ).
Patron, Вы абсолютно правы, просто расчеты не мои и делилось не на 12 бит а на 8, но это сути дела не меняет. Попробую еще раз объяснить, ситуация аналогична как с НХ сервером при работе со сжатием, только в данном случае на мой взгляд почему-то кодом эмулятора процессора долго обрабатывается прерывание или что-то еще. Т.е. на 104 тика отведенные для чтения из регистра процессору дается 104*16 тиков, а вот успеет ли выполнится тот или иной набор команд вопрос, видимо не всегда успевает.
Точных таймингов команд до сих пор нет. Кроме того, время выполнения команд конечно зависит от времени отклика устройств на шине.
Имеющиеся тайминги команд основаны на таймингах команд БК и несколько изменены, с тем чтобы время выполнения команд по тестам примерно совпадало с реалом.
Конкретику можно посмотреть в emubase/Processor.cpp.
Например, простейшие операции регистр-регистр занимают 11 тактов.
Рекомендую для отладочных вещей пользоваться вызовами DebugLog() и DebugLogFormat() -- они пишут в файл trace.log, это быстрее DebugPrint() и не ограничено размером буфера виндового контрола EDIT (кажется, 64К текста).
Если нужно получить в логе трассу команд, можно в конец CProcessor::FetchInstruction() вставить примерно такой блок:
Код:#if !defined(PRODUCT)
WORD address = GetPC() - 2;
WORD data[4];
for (int i = 0; i < 4; i++)
data[i] = GetWord(address + i * 2);
TCHAR strInstr[8];
TCHAR strArg[32];
DisassembleInstruction(data, address, strInstr, strArg);
DebugLogFormat(_T("%06o: %s\t%s\n"), address, strInstr, strArg);
#endif
---------- Post added at 00:10 ---------- Previous post was at 00:05 ----------
Цифры все в коде, цифр этих много, зависит от команды и режимов адресации.
Если хочется видеть по конкретному коду сколько тактов занимают команды -- можно смотреть или логировать в конце CProcessor::Execute() на выходе из функции CProcessor::CommandExecution() сколько прописано в m_internalTick -- это и будет время выполнения команды.
Чтобы замедлить/ускорить процессор можно либо в CMotherboard::SystemFrame() изменить количество вызовов SYSTEMFRAME_EXECUTE_CPU и SYSTEMFRAME_EXECUTE_PPU, либо в коде процессора изменять m_internalTick.
Т.е. общего тактирования на процессор нет? так чтобы в одном месте подправить.
И еще не понятно сколько времени отводится для выполнения прерывания VIRQ, т.е. процессор вроде как ни каких команд не выполняет но должен сохранить много чего в стеке кажется.
nzeemin, посмотрел новый билд. Не понравилась смена курсора на кнопках, имхо лучше подсвечивать сами клавиши. Было бы неплохо иметь хоткеи на load/save state. Да ещё play/pause на Break для откладки повесить.
Жаль сохранение от старой версии не хочет восстановить в последней бете)
Гоняю 38 версию - впечатления самые положительные в целом, особенно в плане
флопов - я не знаю правили там что то или нет, но работают лучше чем когда либо.
Глюк что некоторые приложения с харда отказываются дискеты видеть, но тут
такая вещь - я на реальной машинке столкнулся с этим, иногда без всякого повода
выскакивает ошибка, а повторный запрос может сработать 50\50 (в эмуляторе почти так-же).
Картинки чётко сохраняет вроде проверил в папку эмулятора (!)
Присоединяюсь к Vamos - полноэкранный режим (Screen Mode 5 - почти оно)
(по поводу других прочих версий (QT,SDL) я действительно мог что-то и неправильно написать, поскольку писал с чужих слов-впечатлений - сам пользуюсь и интересуюсь (пока) только Win32 версией)
А по RT11DSK сюда баги писать? А то у меня она крэшится когда в "rt11dsk l" я ей пихаю образ не дискетки, а винта =)
То что крэшится конечно не гуд, но для работы с винчестером предназначены команды hl, hx, hu:
Код:Disk image commands:
rt11dsk l <ImageFile> - list image contents
rt11dsk e <ImageFile> <FileName> - extract file
rt11dsk a <ImageFile> <FileName> - add file
Hard disk image commands:
rt11dsk hl <HddImage> - list HDD image partitions
rt11dsk hx <HddImage> <Partn> <FileName> - extract partition to file
rt11dsk hu <HddImage> <Partn> <FileName> - update partition from the file
Parameters:
<ImageFile> is UKNC disk image in .dsk or .rtd format
<HddImage> is UKNC hard disk image file name
<Partn> is hard disk image partition number, 0..23
<FileName> is a file name to read from or save to
Да, хелп-то я сообразил посмотреть, потому и засомневался, постить ли...
http://code.google.com/p/ukncbtl/wiki/Debugger -- этого недостаточно?
Или давай по конкретным проблемам -- что не получается.
nzeemin, извините если отнял ваше время, все работает, пора мне отдыхать,
только щаз заметил в самом низу строчку в которой надо вводить, раньше тыкал в окне выше.
В приложенном архиве сохранения из игры Knight (2-3-4 - уровни).
Записывались и проверялись для версии эмулятора beta38.
Подробности
Скрытый текст
По счёту на картинках видно, что этот забег был ради прохождения,
а не ради счёта. Целью взять все бонусы и убить всех врагов -
набирая максимальный счёт не ставилась.
Файл в архиве:2level.uknc
http://savepic.ru/4036054.png
Ничего сложного - новые монстры появляются только.
Файл в архиве:2.5level.uknc
http://savepic.ru/4037078.png
Во втором же, только ближе к финалу.
Файл в архиве:3level.uknc
http://savepic.ru/4008406.png
Начало 3-го уровня, его стоит пройти самому
что-бы понять что будет поджидать тебя дальше.
Файл в архиве:3level_FINALMONSTR.uknc
http://savepic.ru/4000214.png
Финальный монстр 3-го уровня.
Жук - очень колоритный персонаж(монстр).
Файл в архиве:4level.uknc
http://savepic.ru/3999190.png
4-й уровень, первый по настоящему сложный для
прохождения, но миновать два перекрёстных обстрела
всё же можно. Задача максимум - пройти без потери попыток.
[свернуть]
Запускать в выше указанной версии UKNCBTL.
используя функцию Load State.
http://savepic.ru/4041174.png
На всякий случай, надо и управление напомнить:
F1(K1) - включение\отключение паузы
F2(K2) - три режима звука последовательно
Если во время игры взять бонус "Ферзь" и после
появления счётчика времени включить и отключить
паузу фон продолжит двигаться при замерших монстрах.
Загружаем, пробуем играть.
А можно ли сделать так, чтобы окно эмулятора было не с фиксированным размером, а изменяемым, его максимизированный статус мог сохраняться, а изображение от УКНЦ центрировалось в окне?