nedoPC.org

В общем, да, все так

Поддержка РОМ-диска для РК немного в незавершенном виде, настраивается только через конфиг.
Просто в журнальном РК вообще таймер предполагалось подключать параллельно РОМ-диску, мне это не очень понравилось при реализации в эмуляторе, поэтому РОМ-диск по умолчанию выключил.

Да и вообще, реализацию РОМ-диска буду со временем переделывать для унификации интерфейса для разных компьютеров...

Тем не менее - для работы многостраничного ром-диска на РК требуется изменение кода

Возьмёшь пул-реквест пока реализацию ещё не переделал?

Я свою реализацию ещё причешу, чтобы осталось совместимость с dsdos-ом и чтобы просто ромдиск тоже работал как и раньше...

Я не в курсе, существует общепринятая реализация многостраничного ром-диска на РК? Как страницы переключаются?

PR не могу точно обещать, что возьму. Но, если что, перепишу по-своему...

Тот же vinxru, но подцепленный к РК


И потом я настраиваемое делаю - не только полмега и мег, как в оригинале от vinxru, но и 2 мега, и даже 4 мега (под них схема расширяется элементарно - просто ставится 8 микросхем 49F040 или 29F040 и немного логики)


Я буду стараться сделать красиво и не сломать что уже работает

Так-то он реализован уже, по умолчанию в конфиге Апогея...

Но в РК это не работает

(на самом деле работает)

И там только полмега (16 страниц):

вроде сделал настраиваемо - на уровне конфига это вот так предлагается:

Я правильно понимаю, что через PageSelector выбираются страницы размером в 512 Мб?
То есть по сути это расширение уже реализованного ApogeyRomDisk?

В таком случае будет логичнее сделать производный класс от ApogeyRomDisk или даже просто добавить к нему еще один метод для выбора текущей страницы...

Да, так тоже работает:
Но тут только 512КБ, а я планировал чтобы можно было указать разные размеры - не только 512КБ, но и 1МБ, 2МБ или 4МБ.

Хотя наверное и класс ApogeyRomDisk можно расширить, добавив необязательный конфигурационный параметр sizeMB (по умолчанию размер будет как и теперь 512КБ, а при указании sizeMB=1, sizeMB=2 или sizeMB=4 будет установлено соответствующее количество мегабайтов (маска 0x1f, 0x2f или 0x3f соответственно вместо 0xf):

P.S. Кстати монитор Апогея НЕ засылает #FF в порт C по окончании работы директивы R, как это делается в мониторе РК! Это означает, что если подключать к РК схему vinxru как есть, то перед каждым R надо указывать страницу (даже нулевую - через R8000) т.к. после каждой R (если адрес был не #80XX), оно просто запомнит произвольную страницу в соответствии с последним значением, записанным в порт B, например после R,F оно ошибочно поменяет страницу на номер 15:


По идее это легко чинится аппаратно путём добавления в квазидиск логики, которая предотвращает сохранение номера страницы, если бит 7 и бит 6 порта C оба установлены в 1 - только если бит 7 в 1, а бит 6 в 0 - тогда всё будет ок...

А зачем в начале каждого исходного файла стоит непечатная последовательность #EF #BB #BF?



P.S. Погуглил - это похоже вот это: https://en.wikipedia.org/wiki/Byte_order_mark

Ещё вопрос - про шрифты:

Как переключаться между этими тремя типами шрифтов? Alt-F вроде как только между двумя вариантами переключается - какой-то хардкод и какой-то большой размер из файла rk86/fontr.bin - как подменить обычный фонт 8x8 на свой?

P.S. А всё нашёл - rk86/sgr.bin надо подменить

Расширил

https://github.com/vpyk/emu80v4/pull/22

PR вижу, постараюсь завтра внимательно посмотреть, сегодня уже не успеваю.

sgr.bin - это родной знакогенератор, а fontr.bin - альтернативный, если в эмуляторе захочется красивых символов. Там для каждого символа последовательно записаны версии 8*8, 8*12 и 8*16, выбирается подходящий в зависимости от разрешения. Наследие еще DOS-версии эмулятора, рисовал эти альтернативные наборы еще тогда, по крайней мере для РК.

BOM добавил, чтобы файлы в кодировке UTF-8 нормально воспринимал Visual Studio 2015, без этого он думает, что исходники в кодировке windows. Для Linux это несколько странно, но, по крайней мере, допустимо и не мешает. Хотя основной инструмент сборки у меня - GCC, тем не менее совместимость с VS2015 поддерживается. В более поздних версиях VS тоже проблем нет, но меня неоднократно просили сохранять совместимость с WinXP, так что также приходится поддерживать совместимость со старыми инструментами сборки...

Поясни, для чего планируется использовать этот расширенный РОМ-диск? Есть какой-то софт, на котором можно его протестировать или, наоборот, эмулятор планируется использовать для его разработки, а уж потом воплощать в железе? Как планируется грузить начальный загрузчик? Будет модифицированный Монитор (или какой-то другой стандартный софт или ОС)? Не вникал пока в нюансы, но если запускать через стандартный Монитор, то вместо доп. логики можно, наверное, загрузчик дублировать в начало каждой страницы. Достаточно всего нескольких байт, я думаю...

да не вопрос - когда время будет


Я вроде пробовал разрешение переключать, но всё равно одна и та же часть из fontr.bin использовалась - ну да ладно, мне главное было уметь подменять основной знакогенератор


А WinXP умел UTF-8?
Так то GCC в моём дебияне Emu80 v4 собирает без проблем - просто когда я в коде копаюсь, я чисто для собственного удобства перевожу исходик в UNIX-фомат через dos2unix, который прибивает эту троицу в начале файла - потом при превращении обратно в DOS приходится их ручками добавлять в HEX-редакторе (я их сначала даже не заметил - мне git diff показал отличие в начале файла и только потом я стал в HEX-виде разглядывать чего там такое).


Ну начнём с того, что vinxru после варианта 512кб сам предложил вариант 1МБ
https://zx-pk.ru/threads/17316-apogej-bk01-i-apogej-bk01ts-vneshnij-rom-disk.html?p=436029&viewfull=1#post436029
А где 1 мег, там можно и до 2 расширить и до 4 совершенно прозрачным образом
Изменения монитора или спец.загрузчик ненужны - всё работает и так с "ручным" подходом, когда странички переключаются через R8000, R8001, R8002 и т.д. (см.скриншот выше - единственное, что в РК это надо делать перед каждой операцией чтения через команду R). Загрузчик в каждой странице тоже ненужен (как я писал без него вообще можно обойтись). А так я конечно же хочу привести Emu80 к состоянию, чтобы он "из коробки" умел играть мою 2-битную музыку, где некоторые музычки зашкаливают за 1 мег (я 10 лет назад чисто для себя подправлял Emu80 v3, чтобы он умел квазидиск и микширование INTE с выходом мафона делал, но в современном 64-битном дебияне тот код уже не собирается), а в перспективе я таки сделаю возможность записи в микрухи типа 49F040 или 29F040 и выпущу платку с поддержкой в своей операционке ShaOS (но это уже очень далёкое будущее).

P.S. Потом можно с видео на РК поиграться
Игры с видео и музыкальными вставками поделать
И конечно же Emu80 мне бы сильно помог в разработке таковых

Не сложилось в прошлое воскресенье, так и осталось почти до следующих выходных

А может, маску вычислять просто из фактического размера файла? Или софт будет предполагать фиксированный размер, и из самого содержимого РОМ-диска фактический размер определить не получится?

И вот это не понял:
+ else if(mb<4) mb = 2;

То есть, если указать 3, будет доступно 2? Может просто ограничить выбор вариантами 0,1,2,4? Можно и auto добавить (см. выше).