Videopac / Odyssey2 forum
September 25, 2021, 07:28:55 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Al lot of attachments from Nov 2011 till april 2012 are damaged. Please ask the original poster to re-upload if you need them.
 
   Home   Help Login Register links videopac.nl  
Pages: [1]   Go Down
  Print  
Author Topic: How to reset a game?  (Read 191 times)
DFL
Trying to get the cartridge in...
*
Posts: 4


« on: September 11, 2021, 02:09:48 PM »

Hi, I'm trying to do a "complete reset", something like pressing the Reset key on the keyboard. The idea is to reset the game after a (self-made) Multicart loads a game

I'm testing a few things like the code below, but I believe I'm missing something.

Code:
REBOOT
   MOV A,#00
   MOV PSW,A
   JMP 000h

Any help is appreciated.
Logged
TedFoolery
Attacked the Timelord
***
Posts: 101


« Reply #1 on: September 13, 2021, 04:51:24 PM »

Not sure if clearing PSW is necessary or not, but there's a routine to reset everything at 01fh

Code:
REBOOT
   CLR A        ;not sure if these are needed
   MOV PSW,A    ;not sure if these are needed
   CALL 01Fh    ;call to INIT routine
   JMP 0400h    ;jump to cart's SELECTGAME routine. To jump to bios' routine, change to 02c3h
Logged
DFL
Trying to get the cartridge in...
*
Posts: 4


« Reply #2 on: September 13, 2021, 08:50:50 PM »

Hey Ted, thanks for the reply.

I believe the problem is about the moment that I change the "rom". The firmware is a rom too, right? So, at some point, the user selects the file to load, and I lose a few milliseconds to load the file from SD.
My guess is the videopac CPU is hanging. even if I force a few opcodes for the rebooting, I believe the CPU already lost control.

Guessing here, maybe the correct way is to pause the CPU somehow? Anyway, I',m still trying to figure it out.
Logged
TedFoolery
Attacked the Timelord
***
Posts: 101


« Reply #3 on: September 14, 2021, 03:58:05 PM »

Not exactly sure I fully get what's going on, but if I understand correctly, you should be able to use the bios routines (anything from $000 - $3ff) since there is no way to override this rom area and is always present. If you jump to the select-game routine, in theory you should then be able to completely wipe out and replace all cart data ($400 and above) without the machine crashing. That is, I assume you have some other CPU doing the SD reading and RAM loading?
Logged
DFL
Trying to get the cartridge in...
*
Posts: 4


« Reply #4 on: September 16, 2021, 07:22:20 PM »

Yes, I'm using an ARM microcontroller. In a nutshell, I have:
1 - the microcontroller reads the SD file names to an array.
2 - the first 8 array entries are displayed for the user selection
3 - if I move to another page, the pointer is adjusted to the next/previous page
4 - Up to here, itīs just a closed loop reading the bus address and serving the data. (And then, back to step 2)
5 - So far, so good. But the problem is when the user makes a selection. I need to abandon this (steps 2,3,4) loop and read the SD to get the selected game data.
6 - At this point, I would like to pause(??) somehow or waste some CPU cycles, because the videopac bus is active.
7 - Now the game data is loaded, but fails to start. My guess is the CPU crashed because of the lack of bus data

Itīs just a matter to press RESET and play the game at step 7, but I would like to figure out how to auto-start.

You are correct, the BIOS is 000 to 3FF, and maybe the solution is to keep the CPU at this range somehow on step 6 above.

But what is the best choice to waste some time? It's less than one second, but for the CPU it's a thousand instructions, literally.

Thanks for the help
Logged
TedFoolery
Attacked the Timelord
***
Posts: 101


« Reply #5 on: September 17, 2021, 04:15:59 PM »

You could also try disabling interrupts before the reboot code (dis i and dis tcnti), since these may cause the CPU to jump out of the bios.

How much RAM area do you have? Maybe you could use 2 areas - the first 8k is to run the game selection, but once the game is selected, you write the game code to a higher area in RAM while the O2 is still running on the lower 8k. Once the data is written, jump to the reboot code (should take a few ms to finish since it loops a lot to clear everything) and just "flip-an-address-bit" so when the O2 returns it will be in the new code.

Here's some revised REBOOT function
Code:
REBOOT
   CLR A        ;not sure if these are needed
   MOV PSW,A    ;not sure if these are needed
   DIS I        ;disable interupt
   DIS TCNTI    ;disable counter interrupt
   SEL RB1      ;should be set for init call
   CALL 01Fh    ;call to INIT routine
   JMP 0400h    ;jump to cart's SELECTGAME routine. To jump to bios' routine, change to 02c3h
Logged
DFL
Trying to get the cartridge in...
*
Posts: 4


« Reply #6 on: September 17, 2021, 08:34:49 PM »

Plenty of RAM, 192Kb, or something like that, but I already have two separated arrays, one with 2kb, the O2 "firmware" for the selection, and another with 8kb for the carts. (should be expanded later to handle the special cases).
So, the second one receives the loaded data from SD.

The main problem, there is no "external" ram, to make the "O2 still running". Is a microcontroller program that serves the data for the bus, so when an SD file is read, there is no data for the bus.

something like: (pseudocode)
Code:
while(1){
      bus_data = firmware_rom[bus_addr];
      if (file_selected) break;
}

load_file(file_selected);

while(1){
      bus_data = cart_rom[bus_addr];
}

Between the break, load_file, and the new loop, the CPU misses a lot of code, I guess.
So, I can't reboot just before the break, because the ROM isn't there yet, but maybe if the CPU waste some time in the BIOS area,
I can force the reboot opcodes after the load_file and them, reboot to the new rom
Logged
TedFoolery
Attacked the Timelord
***
Posts: 101


« Reply #7 on: September 17, 2021, 11:24:02 PM »

If my calculations are correct, the init routine takes 5.81ms to complete on an O2 and 5.29ms on a VP. Is that enough time to do the loadfile?
Also, it looks like the interrupt does get enabled during the init, so disabling it is pointless.  So, that means at some point it might look for the interrupt routine at $0403. If that is blank or there's a jump to some other code in the cart, it could mess things up. If you can keep a 'retr' at $0403 until the game switches, that should help.

And another thought - after it does the init, it is returning to wherever the CALL was. This won't work. You need to make it return to either $0400. I think if you clear the stack area first, then when it hits the RET, it will return to $0000, which jumps to the carts $0400.
Code:
REBOOT
   MOV R0,#010h
   MOV R1,#08h
   CLR A
STACKLOOP
   MOV @R1,A
   INC R1
   DJNZ R0, STACKLOOP
   SEL RB1      ;should be set for init call
   JMP 01Fh    ;jmp to INIT routine

Edited. Changed the CALL to a JMP, since we hijacked the way it will return
« Last Edit: September 18, 2021, 11:52:01 PM by TedFoolery » Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!