Fwd: [MSXBR-L] Viabilidade Cartucho Savestate

[Emiliano Fraga]

Olá pessoal,

Quero compartilhar neste grupo uma ideia posta em discussão noutra Lista de MSX.

Talvez isto já tenha sido discutido nesta lista, mas estive pensando num cartucho que possibilitasse o "save state" do MSX.

Este Cartucho de "savestate" teria:

• Flash Ram para armazenar o estado do MSX (512k seriam suficientes?)
  
• ROM / EPROM com código para execução / recuperação do estado da máquina
  

O funcionamento seria algo do tipo:

• Cartucho de jogo inserido inserido no slot X
  
• Cartucho "savestate" inserido inserido no slot Y
  
• Código de ativação residente

Durante execução do jogo, uma certa combinação de teclas (hook?) ativaria o código para armazenar o estado do MSX (RAM, pilhas, registradores etc).

Este estado ficaria na FlashRAM, de tal forma que, mesmo após desligar o MSX, poderíamos:

opção a) salvar o estado armazenado na FlashRAM em disco com uso de um programa.

Exemplo: SAVERAM.COM "nomedoarquivo"

opção b) carregar um estado salvo em disco na FlashRAM com uso de outro programa.

Exemplo: LOADRAM.COM "nomedoarquivo"

opção c) retornar o MSX ao estado armazenado na FlashRAM

Exemplo: LOADSTAT.COM

Esta ideia foi baseada após ler sobre o Game Runner, software do Sharksym: http://sharksym.egloos.com/5101790

Vejam os comentários no MSX Org:

http://www.msx.org/news/en/game-runner-11

     "The MSX-DOS2 utility allows you to run MSX1 ROM games of up to 32kb and exit to DOS once you're done playing.

     But that's not all. Game Runner adds extra features that set the tool apart from traditional ROM loaders as Game Runner also allows you to decrease the game speed (from 30 to 60 frames per second in several steps), pause the game and even to save your progress on-the-fly with a feature that we know all to well from popular MSX emulators: save states.

     To use Game Runner you require an MSX2 with 128kB VRAM. A memory mapper is not required."

     Na thread do MSX org, o usuário Guillian indica o GRun combinado com outros utilitários que também implementam Savestate:

(http://soft.mundivia.es/mpazos/utilidades/Utilidades.html)

     TRLOAD version 0.2: Ejecuta cualquier ROM de 16 o 32 Kb y MegaROMs de Konami, con la posibilidad de emular un segundo cartucho para hacer combinaciones, y las nuevasopciones de LOAD/SAVE con las que podrás cargar o grabar partidas EN CUALQUIER MOMENTO DEL JUEGO. Sólo turbo R.

 

     NSTOOL: Paquete de utilidades para pasar cartuchos de 16 o 32 Kb a ficheros ROM, ejecutarlos posteriormente con la opción de poder cargar y grabar partida, y volver al juego desde el DOS. Realizado por Okei y Niga.

Percebam que temos algumas maneiras, bem restritas, de implementação de Savestate.

Todas elas se valem da memória do MSX, nenhuma contempla o uso de alguma expansão de memória, como SRAM ou Flash.

Acredito que esta ideia de savestate em cartuchos de memória não-volátil seja um "próximo passo" das soluções apresentadas.

Por outro lado reconheço que trata-se de algo muito sofisticado e não-trivial!

O que vocês acham?!

Abraços,

Emil

[PopolonY2k]

Opa @Emiliano...

...de fato eu acho que existe um projeto que pode transformar o save state em realidade e está bem próximo disso.

É o MSXARM pois acredito que o save state do MSX se resume em salvar o conteudo dos registradores e o(s) banco(s) de memória do MSX, é isso ou tem algo mais ?

Acho que isso no MSXARM está mais próximo de acontecer pois já tem toda uma estrutura pronta, podendo inclusive salvar em MicroSD.

[]'s

PopolonY2k

2013/4/5 Emiliano Fraga <efr...@gmail.com>

--
Você está recebendo esta mensagem porque se inscreveu no grupo "Grupo de desenvolvimento de software e coisas legais para MSX e afins" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para gdmsx+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Emiliano Fraga]

Oi Rogério,

Isto é ótimo,

Apesar que minha ideia maluca visa a aplicação do Savestate com os recursos atuais: software + cartucho flashrom, por exemplo.

Abraços,

Emil

2013/4/10 Rogerio Machado <rog...@gmail.com>

O Tiago postou na MSXBR uma mensagem bastante esclarecedora sobre isso :

"E1000,

Uma vez eu cheguei a pensar em algo pareciso com isso... Uma especie de M1

pro MSX (M1 eh um cartucho para o ZX Spectrum, que eh como se fosse um Mega

Assembler mas com um botao fisico que te permite interromper qualquer coisa

que estiver rodando naquele momento e abrir o editor mantendo o conteudo da

RAM e mais algumas coisas para garantir que voce possa retomar o

processamento a partir daquele ponto, exatamente como um debugger de

emulador!)

Acontece que nao eh soh o conteudo da RAM que precisa ser preservado: Cada

componente do MSX (Z80, PPI, PSG, VDP e o que mais estiver presente como

mapper, FM, MSX-Audio...) tem registradores que precisam ser salvos, e

alguns deles nao podem ser lidos (os do PSG e do VDP por exemplo... a

mapper, tem registradores que precisam ser salvos e nao po.... digo, nao

devem ser lidos!) Entao fazer isso sem um hardware auxiliar eh impossivel.

(e ainda assim bastante complicado, tem que prever todo o mapa de I/O

possivel do MSX) Gerar um hook no BIOS pode causar alguma

incompatibilidade, entao precisamos muito cuidado (a M1 do Spectrum utiliza

um recurso do Z80 chamado Non-Maskable Interrupt, mas para isso seria

necessario que o pino NMI do Z80 estivesse disponivel no barramento)

-- Tiago"

A arquitetura proposta do MSXARM(http://187.33.0.151/foswiki/pub/MsxArm/MsxarmArchitecture/msxarm.png) permite implementar o "save state". O estado de cada componente do MSXARM  e do MSX(PSG,FM,PCM,VDP,PPI) pode ser salvo no SD/MMC sendo que o processamento do emulador Z80/R800 pode ser interrompido a qualquer momento atraves de um evento que poderia ser o botao de reset do MSX(Entao o MSXARM deve monitorar o reset do Z80 fisico e associar isso ao evento de savestate). Para contornar o problema de salvar o estado dos componentes com registradores de "write only" eh necesario ter uma copia destes registros no modulo "Z80 zombie coprocessor" (Ver http://187.33.0.151/foswiki/pub/MsxArm/MsxarmArchitecture/msxarm.png) ou no modulo "Z80/R800 emulator". Para os cartuchos conectados no MSX seria muito complexo suportar todos os dispositivos conhecidos(V9990,IDE,midipac...)

Uma implementacao mais elegante(a implementacao do M1 ZX Spectrum) seria associar o evento do botao de reset do MSX com o start do Z80/R800 debugger (http://187.33.0.151/foswiki/bin/view/MsxArm/MsxArmBasicDebug). Assim a aplicacao pode ser intenrrompida para depuracao (disassembler,breakpoints,display memory) ou salvar o estado :)

--

Você está recebendo esta mensagem porque se inscreveu no grupo "Grupo de desenvolvimento de software e coisas legais para MSX e afins" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para gdmsx+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
Emiliano Vaz Fraga

[Rogerio Machado]

O Tiago postou uma mensagem  na MSXBR bastante esclarecedora sobre isso:

"E1000,

Uma vez eu cheguei a pensar em algo pareciso com isso... Uma especie de M1

pro MSX (M1 eh um cartucho para o ZX Spectrum, que eh como se fosse um Mega

Assembler mas com um botao fisico que te permite interromper qualquer coisa

que estiver rodando naquele momento e abrir o editor mantendo o conteudo da

RAM e mais algumas coisas para garantir que voce possa retomar o

processamento a partir daquele ponto, exatamente como um debugger de

emulador!)

Acontece que nao eh soh o conteudo da RAM que precisa ser preservado: Cada

componente do MSX (Z80, PPI, PSG, VDP e o que mais estiver presente como

mapper, FM, MSX-Audio...) tem registradores que precisam ser salvos, e

alguns deles nao podem ser lidos (os do PSG e do VDP por exemplo... a

mapper, tem registradores que precisam ser salvos e nao po.... digo, nao

devem ser lidos!) Entao fazer isso sem um hardware auxiliar eh impossivel.

(e ainda assim bastante complicado, tem que prever todo o mapa de I/O

possivel do MSX) Gerar um hook no BIOS pode causar alguma

incompatibilidade, entao precisamos muito cuidado (a M1 do Spectrum utiliza

um recurso do Z80 chamado Non-Maskable Interrupt, mas para isso seria

necessario que o pino NMI do Z80 estivesse disponivel no barramento)

-- Tiago"

A arquitetura proposta do MSXARM(http://187.33.0.151/foswiki/pub/MsxArm/MsxarmArchitecture/msxarm.png) permite implementar o "save state". O estado de cada componente do MSXARM  e do MSX(PSG,FM,PCM,VDP,PPI) pode ser salvo no SD/MMC sendo que o processamento do emulador Z80/R800 pode ser interrompido a qualquer momento atraves de um evento que poderia ser o botao no MSXARM(Ou talvez uma sequencia de teclas no MSX). Para contornar o problema de salvar o estado dos componentes com registradores de "write only" eh necesario ter uma copia destes registros no modulo "Z80 zombie coprocessor" (Ver http://187.33.0.151/foswiki/pub/MsxArm/MsxarmArchitecture/msxarm.png) ou no modulo "Z80/R800 emulator". Para os cartuchos conectados no MSX seria muito complexo suportar todos os dispositivos conhecidos(V9990,IDE,midipac...)

Uma implementacao mais elegante(a implementacao do M1 ZX Spectrum) seria associar o evento do botao com o start do Z80/R800 debugger (http://187.33.0.151/foswiki/bin/view/MsxArm/MsxArmBasicDebug). Assim a aplicacao pode ser interrompida para depuracao (disassembler,breakpoints,display memory) ou salvar o estado :)

 

Em sexta-feira, 5 de abril de 2013 17h50min27s UTC-3, Emiliano Fraga escreveu:

[Rogerio Machado]

Segundo o Tiago e eu concordo que com os recursos atuais(software em Z80 com cartucho flashrom) eh impossivel! O problema principal eh como interromper o processamento e como restaurar do registro "write only" do VDP,PSG

[Emiliano Fraga]

Oi Rogério,

Não tenho intenção de questioná-los ou sequer de duvidar do parecer de vocês.

Meus conhecimentos são pífios demais.

Contudo, como será que implementaram savestate nos softwares GRun, TRLOAD e NSTOOL? (abaixo)

Note que há limitações, tamanho dos jogos, Konami, outro somente TR etc, mas os caras conseguiram! :-)

A única coisa é que a implementação deles salva em disco. Pensei em algo que utilize uma Flashrom.

Abraços,

Emil

2013/4/10 Rogerio Machado <rog...@gmail.com>

>Oi Rogério,

>Isto é ótimo,

>Apesar que minha ideia maluca visa a aplicação do Savestate com os recursos atuais: software + cartucho flashrom, por exemplo.

>Abraços,

>Emil

Como o Tiago afirmou e eu concordo, com os recurso atuais eh impossivel! 

Problemas: 

1 - Interromper o processamento do Z80

2- Registradores "Write-only" do PSG e VDP

Em sexta-feira, 5 de abril de 2013 17h50min27s UTC-3, Emiliano Fraga escreveu:

--

Você está recebendo esta mensagem porque se inscreveu no grupo "Grupo de desenvolvimento de software e coisas legais para MSX e afins" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para gdmsx+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
Emiliano Vaz Fraga

[Rogerio Machado]

Entao o programa que salva o contexto(GKRun,TRLOAD,NSTOOL) conhece a estrutura dos programas da Konami(enderecos especificos que contem o estado do programa).

[Rogerio Machado]

Entao para descobrir estes enderecos especificos o primeiro passo seria desassemblar alguns jogos da Konami e encontrar estas areas de memoria comuns que contem o estado do game. Acho que a solucao + rapida seria desassemblar o GRun, TRLOAD ou NSTOOL. Assim ja teria rotinas prontas que salvam e restauram o estado do game. E depois adicionando o codigo para salvar na flash.

[PopolonY2k]

Será que não...

...pegaram a idéia e código do GameMaster da Konami ?

[]'s
PopolonY2k

[Emiliano Fraga]

Veja isto, do MSX.org:

http://www.msx.org/news/en/game-runner-11

--
RAM/VRAM contents and CPU state are easy to save.
VDP regs are write-only. VDP address, irq, and sprite related regs can be determined with some tricks. But it is not possible to determine the current color/pattern table or screen mode 1/2/3. Most MSX1 games use the same table offsets and screenmode throughout the game though so this should not be a big problem.
--
Of course, and he doesn't even have to save the complete CPU state. The program loads/saves the state while the CPU is running the program. This means it'll only have to save CPU state that is not used by the program itself, such as register I, and maybe the shadow regs.
--

Vou contactar os autores dos respectivos programas com minha sugestão e verei o que eles respondem.

Abraços,

Emil

[Emiliano Fraga]

Não obstante, um savestate no MSX ARM seria uma "feature" muito interessante!!!!

:-D :-D :-D

Abraços,

e1000

2013/4/10 Emiliano Fraga <efr...@gmail.com>

--
Emiliano Vaz Fraga

[Tiago de Queiroz Valença]

Ressucitando a mensagem:

Tem outro ponto impeditivo importante:

Quando você dispara uma interrupção no MSX a primeira coisa que o Z80 faz é pegar o PC e colocar na pilha (PUSH). A segunda é desviar a execução para o vetor de interrupção (&H0066 se for NMI)

Acontece que NADA me garante que quando eu disparar uma interrupção não mascarável no MSX eu não vá estourar a pilha. Estariamos então perdendo um dado qualquer, com consequências imprevisíveis para a execução do código. Isso tem que ser estudado melhor...

-- Tiago