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?
Possible options.
1) JIffyDOS allowed if compatible withe the game and it loads from disk. This ROM replacement is highly compatible, was very commonly used in real life, and will lower TAS time of nearly ANY disk game. It removes tape compatibility though. True Drive emulation required.
needs to be purchased though
zaphod77 wrote:
2) speeder carts allowed, but aftermarket roms (like JiffyDOS) not. this will generally give a 5x speedup in loading, but cannot accelerate block reads, so many games will still load really slow.
Epyx works on NTSC, but AR6 is faster but PAL only
zaphod77 wrote:
3) non true drive emulation allowed. When this works, it gives a super fast load time that cannot be obtained on real hardware. But in the case of a single load, it vastly speeds up time to game start to console levels. The same on multiload actually affects gameplay. so it should not be allowed.
for single load you could do Direct RAM Injection
zaphod77 wrote:
4) no speeders beyond ones programmed into the game itself. this is the easiest to police, but often causes horrible load times.
don't TAS's need to be "hardware verified" to be counted as true? so we are limited to doing them within hardware limits?
zaphod77 wrote:
argument for jiffydos/carts is that they were very commonly used in real life, and thus are valid peripherals.
argument against is they were not first party peripherals like the 1541 disk drive.
argument for non true drive emulation is minimum downtime.
argument against is can never be replicated on real hardware.
also note that there's a standard sdcard solution to run a limited subset of .d64 images. used together with jjiffydos, this is a very fast loading platform on real hardware, but not sure if it's emulated. It's generally 20x faster than stock 1541 drive speeds.
nobody emulates a SD2IEC, what is the point? Direct RAM injection, Traps etc are faster
zaphod77 wrote:
And yes, tape/disk/cart versions can be different. only the disk version of lode runner has all the levels. Frogger had different cart/disk versions.
and TAPE version of Indiana jones is single load, but disk is a multiload. but both ARE the same game!
multiload tape games are horrid and should almost NEVER be TASed. they are usually sloppy conversions from disk.
the example given with enemies slower on NTSC vs PAL is an example of a glitch that would preclude the game being ran NTSC, IMHO.
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.
.g64 images can rarely be sped up by any means, as they tend to have their own fast loaders, but it's sometimes possible to speed them up with a fastload cart, and sometimes with jiffydos.
.d64 images are much more likely to be possible to speed up with a fastload cartridge, and nearly ALL speed up with jiffydos.
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.
Many emulators also support non true drive emulation, which traps the kernal loads and makes them happen darn near instantly. When a game works with this, it loads orders of magnitude faster. Try, for example, necromancer. The .d64 with errors is an original disk image. It does not load significantly faster with fast load. it does load a bit faster with jiffydos. it loads amazingly fast with true drive emulation turned off. But this was an option that nobody ever actually had.
The main argument for allowing speeders is that a) they were very commonly used on real hardware and b) they usually shave many minutes off of the total time. A game that takes 2 minutes to load from disks will often load in a fifth of that time with an epyx fastload cart. that knocks off 96 seconds of downtime, and doesn't modify the software. if the game is a multiload, even more time is saved. A speeder art does not modify the game in any way. it just replaces the standard load routines with something faster. This is why they are arguably allowed.
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?