Просмотр сообщений
1
Картриджи / диски / Дампинг, обсуждаем, делимся ромами своих дампов
« : 23 Июль 2025, 23:37:39 »
Все, я победил этот странный баг с искаженными цветами 
Обновил архив с исходниками и скомпилированными файлами ядра.
Проблема никак не связана с моими правками и проявилась только из-за более новой версии компилятора.
Вот функция, которая читает 16-битное слово из регистра VDP, в нашем случае из регистра данных с указателем в CRAM
А вот функция чтения 32-битного значения из памяти при эмуляции инструкций CPU 68000, например для инструкций типа "move.l (a0),d1".
Переменная "temp->read16" для данного случая содержит указатель на функцию, приведенную выше.
Найдете ошибку?
Обновил архив с исходниками и скомпилированными файлами ядра.Проблема никак не связана с моими правками и проявилась только из-за более новой версии компилятора.
Вот функция, которая читает 16-битное слово из регистра VDP, в нашем случае из регистра данных с указателем в CRAM
Код: [Выделить]
/* vdp_ctrl.c */
static unsigned int vdp_68k_data_r_m5(void)
{
uint16 data = 0;
/* Clear pending flag */
pending = 0;
/* Check destination code (CD0-CD3) & CD4 */
switch (code & 0x1F)
{
case 0x00:
{
/* read two bytes from VRAM */
/* .... */
break;
}
case 0x04:
{
/* VSRAM index */
int index = addr & 0x7E;
/* .... */
break;
}
case 0x08:
{
/* Read 9-bit word from CRAM */
data = *(uint16 *)&cram[addr & 0x7E];
/* Unpack 9-bit CRAM data (BBBGGGRRR) to 16-bit bus data (BBB0GGG0RRR0) */
data = ((data & 0x1C0) << 3) | ((data & 0x038) << 2) | ((data & 0x007) << 1);
/* Unused bits are set using data from next available FIFO entry */
data |= (fifo[fifo_idx] & ~0xEEE);
/* .... */
break;
}
case 0x0c: /* undocumented 8-bit VRAM read */
{
/* .... */
break;
}
default:
{
/* Invalid code value (normally locks VDP, hard reset required) */
break;
}
}
/* Increment address register */
addr += reg[15];
/* Return data */
return data;
}
А вот функция чтения 32-битного значения из памяти при эмуляции инструкций CPU 68000, например для инструкций типа "move.l (a0),d1".
Переменная "temp->read16" для данного случая содержит указатель на функцию, приведенную выше.
Код: [Выделить]
/* m68kcpu.h */
INLINE uint m68ki_read_32(uint address)
{
cpu_memory_map *temp;
uint val;
m68ki_set_fc(FLAG_S | m68ki_get_address_space()) /* auto-disable (see m68kcpu.h) */
m68ki_check_address_error(address, MODE_READ, FLAG_S | m68ki_get_address_space()) /* auto-disable (see m68kcpu.h) */
temp = &m68ki_cpu.memory_map[((address)>>16)&0xff];
if (temp->read16) val = ((*temp->read16)(ADDRESS_68K(address)) << 16) | ((*temp->read16)(ADDRESS_68K(address + 2)));
else val = m68k_read_immediate_32(address);
#ifdef HOOK_CPU
if (UNLIKELY(cpu_hook))
cpu_hook(HOOK_M68K_R, 4, address, val);
#endif
return val;
}
Найдете ошибку?
, причем даже если просто собрать не модифицированное ядро, без моих изменений. На Debug сборках такого не наблюдается...Я собирал под VisualStudio 2019, может какие-то настройки проекта неправильно импортировались 
Genesis-Plus-GX-TheSecretOfTheFourWinds-Sources.rar
Сейчас еще раз посмотрел исходники - для сохранений эмулируется параллельная SRAM память, как на обычном картридже, тогда как на реальной плате используется последовательная EEPROM. Приношу свои извинения!
Так что это уже не маркетинг, а просто вранье.
Пример: если игра записывает значение xxxx по адресу yyyyyy и начинает играть один трек, а потом записывает значение zzzz туда же, и начинает играть другой трек, то значит регистр по адресу yyyyyy управляет воспроизведением аудио треков. И так далее. 
Так что либо его потом придется разбирать и перепаивать, либо покупать сразу дорогой кабель типа HDRetrovision.
Тогда неудивительно, что id флешки прочитать не удается.