I'm not hacking, I'm developing. But I have some effects.
So tweak numbers
assemble
load
wait
nope that was not quite right
assemble
load
wait
nope that was not quite right
vs
LUA gui the lets me modify the values in real time
tweak
nope
tweak
nope
tweak
I can also just give the lua file to the artist so they can tweak the values to their liking. they can't handle modifying an asm file and assembling. a like GUI really really speeds things up. Then I just make a button that exports the values in a text file for me to include.
the SNES is so frustrating, everything is 5 thou out. I basically need to use 2 emulators, so I can get a debugger in one to find the memory locations because the assembler doesn't output a proper label file, or a listing file. Then I need to use bizhawk so I can get LUA with a GUI. and now I have to make my code copy stuff to RAM, and run from RAM. Then make a GUI that modifies the RAM, then convert the code back to use ROM which is a real pain. Why because the emulator can't modify a memory location...sigh...
var md = new MemoryDomainIntPtrMonitor(name, MemoryDomain.Endian.Little, (IntPtr)blockPtr, size,
id != LibsnesApi.SNES_MEMORY.CARTRIDGE_ROM, // hack: for just this one memory area, it will be readonly
byteSize, Api);
I'm using the Lua features for some dev, only CARTROM is "read only" so I can't modify anything.. I tried both BSnes and SNES9x cores.
Is there an option or config setting that unlocks CARTROM to be writable?
needs to be purchased though
Epyx works on NTSC, but AR6 is faster but PAL only
for single load you could do Direct RAM Injection
don't TAS's need to be "hardware verified" to be counted as true? so we are limited to doing them within hardware limits?
nobody emulates a SD2IEC, what is the point? Direct RAM injection, Traps etc are faster
sure but how does one test such things? I guess you could scale all the time points and then test on PAL to see if it works the same, but that is tricky to do and get working
Edited by feos: fixed the quotes.
This is not true, a D64 and G64 can be used the same way, it just so happens that we only make g64s when a game needs the extra detail in order to load, but you can have a G64 with plain prgs and no fast loader.
It only work on older games that don't use KERNAL loads, which is not many, single loads will be speed up, or budget releases and cracks. Most commercial releases will have a custom loader, so EPYX and AR and Jiffy Dos will only boost the "load the loader" load. Jiffy Dos is still sold and needs a license, so basically its unfair DLC ala Amibo's so I would think it would need to be banned. I think a better solution is to use the "you can load a save state and just add X time to you run" where the save state is "post load". also given different drives load at different rates, some are 290rpm some are 320rpm etc
There is "only released in PAL" and "PAL only" they are not the same thing.
Mayhem In Monsterland is PAL only ( there is now a mostly 100% NTSC fix for it, but it as far as I know still has some slight compromises ) , Sam's Journey is PAL only but has a NTSC version that uses an REU to make up for the NTSC deficit.
PAL has 19656 clocks per frame 63 clocks per line
NTSC Fixed has 17095 clocks per frame 65 clock per line
NTSC old has 16768 clocks per frame 64 clocks per line
if you just want to go "fastest" Drean, as its has PAL clocks at 60fps
Another issue is "graphics" in the borders, when a game opens the border to put the HUD into it, on PAL this is fine as the borders are large and can show a sprite height. NTSC has very small borders hiding most of the status bar.
Having an extra 2 clocks per line than expected will cause more code to run before an interrupt fires changing the code state, this could open up more exploits. Unlike Consoles such as the NES and SNES which are VBlank locked for graphics and sprite updates, the C64 is active and shared RAM so any part of the graphics display can and is updated as it draws. So if the game logic needs the PAL length of frame, on an NTSC machine you might get enemies updating at 30fps, and have some update this frame and some next frame, while the interrupt moves the player at 60fps, which gives a different result to player + enemies updating at 50fps.
Also worth noting that some games have NTSC and PAL versions which are completely different from each other, also Tape and Disk versions of games can differ greatly.
Some games are C128 enhanced to which they will run faster when they are run in C64 mode but on a 128. An enhanced 128 64 title can match a PAL 64 for clocks.
NTSC C64s are "paper weights" and the vast majority of software is PAL and even then mostly PAL only. Some of the early titles do have NTSC versions EA for example, and some games again the earlier ones don't use enough of the machine to be PAL or NTSC and will work on both, but PAL is the standard.
For VSP Mayhem In Monsterland is also a good test case. See also https://csdb.dk/release/?id=126927 for AGSP
I trust you know about the VICE test repository?
So new to Bizhawk, and I'm dipping my toes into the debugging potential the emulator offers.. even if the debugger doesn't work.
With the label, you can set a width, however it seems it's completely ignored and I can't make a label shorter or longer..
DateStringHDW = forms.label(formHWND,"00 Somday Year 1",0,25,250)
Version 2.3.2(x64) June 18,2019 Commit # 92847b1d1
What am I doing wrong?