Xpeccy

[SAM style]

Почему за такт? Вроде за 3 (через 8 после начала).

Хотя да, это только IN...
Мне сейчас видится всё так: за 3 такта до конца z80 сигнализирует, что байт отправлен в порт. Некоторое время требуется во-первых, дешифратору портов, а во-вторых устройству (регистру TM9 в случае с портом 254), чтобы принять данные. Есть сомнения, что на этих 2 узлах набегает задержка ещё в 2 такта, но всё же... Далее - бордюр обновляестся каждую точку/такт?

[SAM style]

Между делом, во вчерашней сборке:

• Устранен скос (прошелся от 50 до 60% бордюра, было прямо)
• В опциях на вкладке xpeccy->help показываются хоткеи
• Каталог по умолчанию в файловом диалоге для windows - это каталог с эмулем
• Сделана попытка подвинуть бордюр в нормальное положение.

[zebest]

ну не знаю, че ты к этим двум точкам причепивси... ОказываеЦЦо все нормально работает с числом 138 !
layout = Pentagon:448:320:138:80:80:16:64:0
это правильная строка. просто вчера я число пробовал менять в файле config.conf
не перегружая эмууля, а он видимо только раз конфу читает, а не кажный раз.
во-общем со 138 - все ровно. Нашел твою дефолтную строку
vidSetLayout(vid,448,320,138,80,64,32,0,64,0);
в ней как бы на один параметр больше или мне так кажеЦЦо???
ну и

Между делом, во вчерашней сборке:

между делом посмотреть не можем, т.к. не входим в то огромнойе сообщество в количестве полтора человек, которые могут это откомпилить, да еще и под windows

[SAM style]

ну не знаю, че ты к этим двум точкам причепивси... ОказываеЦЦо все нормально работает с числом 138 !
layout = Pentagon:448:320:138:80:80:16:64:0
это правильная строка. просто вчера я число пробовал менять в файле config.conf
не перегружая эмууля, а он видимо только раз конфу читает, а не кажный раз.
во-общем со 138 - все ровно. Нашел твою дефолтную строку
vidSetLayout(vid,448,320,138,80,64,32,0,64,0);
в ней как бы на один параметр больше или мне так кажеЦЦо???
ну и

между делом посмотреть не можем, т.к. не входим в то огромнойе сообщество в количестве полтора человек, которые могут это откомпилить, да еще и под windows

136 или 138 - это влияет на положение основного экрана относительно начала строки. По всем картинкам должно быть 136, но при этом экран с бордюром расходятся на 2 точки. Чтобы нейтрализовать эту фигню, я поставил 138 в default. Сейчас пытаюсь вернуть то, что должно быть, но при этом рисовать бордюр на 2 точки левее.
Лишний параметр в vidSetLayout - это задел на будущее, должен определять положение INT в строке (сейчас - строго в начале).
Сборка под Windows будет к выходным, сразу с drag'n'drop-ом.

added
Хотя, частично bad news. Дроп работает только на полностью Qt-шном окне. В SDL событие дропа замечено в документации на 2.0, но отсутствует начисто в 1.2.

[SAM style]

Win32, build 20120705 - http://rghost.ru/39059167

• Drag'n'drop. Работает только с отрисовкой в Qt (под windows она по умолчанию). Можно кидать несколько файлов сразу - на текущую машину погрузятся снапшоты, лента, диск А: (образы или hobet'ы) или rzx
• В заголовке показывается "fast", если эмуль работает на полной скорости
• Исправлены кавычки на апострофе в сборке с Qt
• И bad news - русские буквы в путях под windows не распарсиваются

[SAM style]

Полоски в тесте, видимо, лечатся. Выскакивают они только на экране. Скорее всего, это связано с тем, что на реале атрибут для знакоместа читается заранее, за 4 точки до самого знакоместа. У меня это не сэмулировано - и пиксели, и атрибут читаются прямо перед отрисовкой.
+добавлен баг: в режиме паузы скриншоты не делаются. Точнее, он будет сделан только после распаузивания.

[Vitamin]

И bad news - русские буквы в путях под windows не распарсиваются

Попробуй

std::locale::global(std::locale(""));

в самом начале main.

[SAM style]

update

• Не-латинские буквы под Windows побеждены почти полностью. Не понимает только в путях, переданых через командную строку. Через F3 и дроп съел даже японские и русские символы сразу
• Оторвал Qt-шные коды клавиш от раскладки - в русской раскладке буквы не работали
• Значок чтения-записи диска показывается и при использовании Qt

build 20120710, win32 - http://rghost.ru/39139184

[SAM style]

ну там наверное и пробелы не понимает. а если в кавычках передавать, как положено???

Да не, тут разница в том, что F3 и дроп дают мне пути в QString, а с командной строки они приходят аргументами в char, причём, кажется, у cmd.exe есть привычка работать в старой досовской кодировке (ibm866).

[ram_scan]

Да не, тут разница в том, что F3 и дроп дают мне пути в QString, а с командной строки они приходят аргументами в char, причём, кажется, у cmd.exe есть привычка работать в старой досовской кодировке (ibm866).

Дак ить так всегда и было в винде. В гуевых программах либо UTF-8 либо cp1251, в консольных cp866 (для русской винды).

Собственно мне думается что правильно спросить kernel32.GetOEMCP(), kernel32.GetACP() и конвертить при разборе командной строки это щасте из одной кодировки в другую. Фигово что фича виндофс-специфичная, надо на условную компиляцию морочиться.