| Change | Time difference | Comment |
|---|---|---|
| Baseline (Post #538557) | 25139 frames | |
| Change ulysse to odysse | −34 frames | ? |
| Combine two-part commands (e.g. put solid;case → put solid in case) | −1479 frames | |
| Use more conventional words (peal→ring, heap→coal) | +3 frames | ? |
| Stack directional commands (w;s;e;u→w.s.e.u) | −781 frames | |
| temple rather than pray after getting coffin | +152 frames | ??? |
pray frames | pray command | temple frames | temple command | Difference |
|---|---|---|---|---|
4334 | open it | 4334 | open it | 0 |
4511 | u.s | 4511 | u | 0 |
4623 | pray | 4547 | tEmPLE | −76 |
4721 | e.s.e.w.w | 4656 | d.E.e | −65 |
4940 | put solid in case | 4814 | put solid in case | −126 |
5146 | open trap | 4983 | open trap | −163 |
Two subgraphs. The left is a line graph with the title "Frames to reach each input line". The x-axis is "line" and the y-axis is "frames". There are two series: PRAY and TEMPLE. The two series are identical until about line 250/frame 5000, then TEMPLE starts to have slightly fewer frames per line. At about line 800/frame 15000, PRAY moves ahead and finishes at about line 1600 about 150 frames faster. The subgraph on the right is titled "Swaps". Its y-axis is "frame" and is aligned with the left subgraph. Two columns of a few hundred horizontal lines, colored to match the PRAY and TEMPLE lines in the other graph, show at what frames swaps occurred. They are identical up to about frame 5000, then they diverge.
What's going on? I thought about it a lot. My best guess is that is has to do with the virtual memory system of the Z-machine. The game's story file is over 80 KB large, but the Apple II has only 64 KB of memory (and not all of that can be freely used). So what the game does is swap information from the disk into memory on demand. A page table keeps track of what pages in memory correspond to what pages on disk. Once the page table is full, every page that is swapped in from disk necessarily evicts a page that already existed; if that other page is needed again later, it will have to be swapped back in.
I suspect that the pray→temple route change, even though it uses fewer and faster commands, perturbs the contents of the page table in such a way that eventually requires doing more swaps and spending more time waiting for the disk. The right-hand side of the graph above shows the frames at which swaps occur in the two routes. They are identical up to the route change; then they diverge. There are some similar patterns, but one is not simply the shift of the other. In total, the pray route uses 655 swaps and the temple route 670.
This kind of thing is hard to optimize, when a small change can have far-reaching and unpredictable effects. It does suggest a heuristic, which is to try to minimize the ranges of addresses that are accessed. I haven't checked, but that may be what's going on with the ulysse→odysse change. In the source code, ODYSSEUS is the main syntax element, while ULYSSES is marked as a synonym. It may be that these two words are stored in different tables in memory, and that odysse requires only one memory access while ulysse requires two. That's just a guess, I haven't checked. I plan to try switching some commands to use the main word rather than synonyms, even when the synonym is shorter.
It may explain why peal→ring had heap→coal an effect. In this case, though, RING and COAL are the main syntax elements. Maybe the lists of synonyms is near a page boundary, or something. I haven't checked.
Differences in page tables is also the kind of thing where changes elsewhere in the route may end up making the temple variant faster after all.I hope to automate this style of RNG manipulation to enable flexible experimentation with routing. As things stand now, if you wanted to try s.e instead of n.e to get behind the house at the beginning of the run, for example, it would desync all later random events. Automated RNG manipulation might also make it possible to play (what is effectively) the same run in either 40-column more or 80-column mode, or in either brief more or verbose mode. That would not normally be possible, because the timing, and hence the RNG, in the various modes would be different. But with a Lua script automatically adjusting the letter case of commands to make sure random rolls always come out the right way, it may be possible for the same route to work in either mode. One movie might have get eGg where the other has get EGg, but they would be effectively the same. Automated RNG manipulation may also make the run robust to timing changes in a future version of the emulator.
| Columns | Brevity | Frames | Time |
|---|---|---|---|
| 40 | superbrief | 18775 | 5:12.92 |
| 80 | superbrief | 19827 | 5:30.45 |
| 40 | brief | 23433 | 6:30.55 |
| 80 | brief | 25139 | 6:58.98 |
| Columns | Brevity | Command |
|---|---|---|
| 40 | superbrief | N;n;hit iT |
| 80 | superbrief | n;n;Hit it |
| 40 | brief | n;n;hit It |
| 80 | brief | n;n;hIT IT |
(enter-commands
[
; ...
;; Get the painting and go back to the cellar.
"s"
"e"
"get"
"w"
"n"
;; Defeat the troll. The troll has a <PROB 33> chance of attacking as
;; soon as we enter the room, before we get a chance to act.
[{:must-not [(make-check-exec-zaddr VILLAIN-BLOW-ZADDR)]}
[
"n"
]]
;; Require a one-hit kill with the shortest remark
;; "The troll takes a fatal blow and slumps to the floor dead."
;; https://github.com/historicalsource/zork1/blob/34cc828c4f/1actions.zil#L3574
[{:must [(make-hero-blow-res-remark KILLED 3)]}
[
"hit it"
]]
; ...
]) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0300 10 06 .. .. .. .. .. .. 7a 80 7a 80 00
0310 L2 00 N2 N2 N2 N2 15 .. .. .. .. .. .. .. .. ..
0320 .. .. .. .. .. .. .. .. .. .. .. .. 04 10 80 a0
0330 L4 00 N4 N4 N4 N4 15 18
0303 BPL 0x030b
030B NOP
030C NOP #0x7a
030E NOP #0x00
0310 L2
0311 0x00
0312 N2
0313 N2
0314 N2
0315 N2
032C NOP 0x10
032E BMI 0x02d0
0330 L4
0331 0x00
0332 N4
0333 N4
0334 N4
0335 N4
C935 JSR EnterBattle_L ; start the battle!
C938 BCC :+ ; see if this battle was the end game battle
@VictoryLoop:
C93A JSR LoadEpilogueSceneGFX
C93D LDA #BANK_ENDINGSCENE
C93F JSR SwapPRG_L
C942 JSR EnterEndingScene
C945 JMP @VictoryLoop
:
C948 JSR ReenterStandardMap ; if this was just a normal battle, reenter the map
| 0x00 Fighter | 0x01 Thief | 0x02 Black Belt | 0x03 Red Mage | 0x04 White Mage | 0x05 Black Mage |
|---|---|---|---|---|---|
| BRK impl | ORA impl | JAM | SLO X,ind | NOP zpg | ORA zpg |
0310 01 00 ORA (0x00,X) ; character class 0x01, (0x00,X) points to zero so there is no effect
0312 AF B2 8D LAX 0x8db2 ; set A = X = 0x38, the value stored at 0x8db2
0313 90 15 BCC 0x032c ; use the preexisting 0x15 operand, jump ahead to character 4 data
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0130 92 c9 01 18 00 0b 05 92
0140 c9 01 08 00 0b 05
0330 03 00 SLO (0x00,X) ; character class 0x03, doesn't change A when X = 0x38
0332 9A TXS ; set SP = X, SP points to one byte before 0xc9
0333 4C 9F AA JMP 0xaa9f ; jump to code that will run PHA and RTS for us
| Opcode | Instruction | Bytes |
|---|---|---|
| 0xa3 | LAX X,ind | 2 bytes |
| 0xa7 | LAX zpg | 2 bytes |
| 0xaf | LAX abs | 3 bytes |
| 0xb3 | LAX ind,Y | 2 bytes |
Sadly I could not find a use for the TAS instruction :(Language: python# 4468M payload, with all possibilities for branch instruction and PHA+RTS code address. # Also consider 2-byte LDA, ADC, EOR, SRE, or RRA followed by TAX as an alternative for 3-byte LAX. # Also consider 2-byte LDX followed by TXA as an alternative for 3-byte LAX. (LAX3 | (LDA2 | ADC2 | EOR2) + TAX | LDX2 + TXA) + BRANCH + TXS + JMP_PHA_RTS, # SRE and RRA can also serve to set A, though they may also change the value # of processor flags, so try more options for the branch (BVS and BCS in # addition to BVC and BCC). (SRE2 | RRA2) + TAX + ALL_BRANCH + TXS + JMP_PHA_RTS, # When we do 2-byte LDX first, we also have the option of doing TXS before TXA. (LDX2 + TXS) + BRANCH + TXA + JMP_PHA_RTS, # 2-byte LAX with jump to PHA+RTS, padding with 1-byte NOPs (or what are # effectively NOPs) in every possible position. What works as a NOP differs # in each position. # Anything that assigns to A or X is a NOP if it happens before LAX. # (As long as it doesn't interfere with the address mode of LAX.) # PHA and TXS work too, as we're not using the stack yet. Also include # TAY, even though it may interfere with the address mode of the LAX. (NOP | TXA | TYA | TAX | TAY | LSRA | PHA | TXS) + LAX2 + BRANCH + TXS + JMP_PHA_RTS, # After LAX, A and X are equal, so TXA and TAX are NOPs. We may now # clobber Y with TAY or DEY. PHA and TXS are still available to us too. LAX2 + (NOP | TXA | TAX | TAY | DEY | PHA | TXS) + BRANCH + TXS + JMP_PHA_RTS, # After TXS, we may still interchange A and X, or clobber Y. We can also # use a second TXS as a NOP. But we cannot use PHA anymore, because the # stack is now set up. LAX2 + TXS + BRANCH + (NOP | TXA | TAX | TAY | DEY | TXS) + JMP_PHA_RTS, # In the final position, don't use a NOP, just repeat the previous byte. LAX2 + TXS + BRANCH + JMP_PHA_RTS + REP, # 2-byte LAX with PHA and jump to RTS. LAX2 + TXS + BRANCH + PHA + JMP_RTS,
[0xaf 0xb2 0x8d 0x90] 22 [0x9a 0x4c 0x95 0xaa] 30 52
[0xaf 0xb2 0x8d 0x90] 22 [0x9a 0x4c 0x96 0xaa] 30 52
[0xaf 0xb2 0x8d 0x90] 22 [0x9a 0x4c 0x9a 0xaa] 30 52
[0xaf 0xb2 0x8d 0x90] 22 [0x9a 0x4c 0x9f 0xaa] 30 52
[0xaf 0xb5 0xc3 0x50] 23 [0x9a 0x4c 0x95 0xaa] 30 53
[0xaf 0xb5 0xc3 0x50] 23 [0x9a 0x4c 0x96 0xaa] 30 53
[0xaf 0xb5 0xc3 0x50] 23 [0x9a 0x4c 0x9a 0xaa] 30 53
[0xaf 0xb5 0xc3 0x50] 23 [0x9a 0x4c 0x9f 0xaa] 30 53
[0xb3 0x59 0x9a 0x90] 32 [0x48 0x4c 0x4b 0xc3] 23 55
[0xb3 0x59 0x9a 0x90] 32 [0x8a 0x4c 0x9f 0xaa] 23 55
[0xa3 0x50 0x9a 0x90] 32 [0x4c 0x9f 0xaa 0xaa] 23 55
Connecting commands with dots. It's possible to enter multiple commands at once, separated by periods. This capability is given in the manual. (c-square, your N,N,U,GET EGG,D in Post #476712 would have worked if you used periods instead of commas.) It was the main trick used to speed up the "fastest eaten by a grue" TAS, where it enabled ending input early. I didn't use this feature in this run, but I did a quick test, and to my dismay it appears that entering multiple commands on one line is slightly faster. N.N.U.GET EGG.D was 1690 frames in my test, compared to 1709 frames with the commands on separate lines. I say "to my dismay" because this would be a pretty extreme speed/entertainment tradeoff, a small gain in speed for a large decrease in entertainment. It's nicer to watch a run where the results of commands are close to the commands that caused them, not separated from them by pages of scrolling. I'm tempted not to make use of this trick, except perhaps when traversing long distances, such as through the mazes.
The Troll Room There is a bloody axe here. >e.e.e.echo.get bar East-West Passage Round Room Loud Room On the ground is a large platinum bar. The rest of your commands have been lost in the noise. >
Loud Room On the ground is a large platinum bar. >echo.e The acoustics of the room change subtly. Loud Room On the ground is a large platinum bar. >
RNG. Speaking of RNG, the good and bad news is that the RNG in the Apple II version is very sensitive, changing with granularity smaller than a frame. I suspect (but have not confirmed) the Apple II port of Zork uses the built-in KEYIN random number generator, which simply rapidly increments a 16-bit number whenever waiting for keyboard input. This is good in the sense that, in principle, you can probably get any RNG output you need with less than a frame of waiting. It's bad in that it's hostile to console verification, and the Virtu core doesn't provide easy access to sub-frame inputs, as far as I know. In this run, I've done RNG manipulation by manually inserting frame delays. But I also experimented with toggling the Shift key while entering commands, and that alone seems to change the CPU cycles enough to affect RNG. I think it should be possible to eventually do such RNG manipulation automatically, using the script, but it will require more work to understand the game's memory layout, in order to read the results of commands.
ADC RNUM1 ;FUTZ WITH RANDOM
STA RNUM1
EOR RNUM2
STA RNUM2
;; "80-COLUMN DISPLAY? (Y/N)"
(enter-text "n")
;; Skip over some loading. Get to somewhere near the first input prompt.
(savestate.next-frame 300)
(enter-commands ["super"])
(wait-for-keyboard-ready)
(savestate.next-frame 1) ;; RNG manipulation (avoid songbird).
; TODO use Shift or other keys for RNG manipulation.
;; Enter the schedule of commands.
;; TODO joining with "." can save time and alter RNG.
(enter-commands
[
;; Climb the tree, get egg, and climb down again.
"n"
"n"
"u"
"get egg"
"d"
;; Enter the house.
"s"
"e"
"open"
;; ...
])
C83B:E6 4E 57 GETKEY INC RNDL ;BUMP RANDOM SEED
C83D:D0 02 C841 58 BNE GETK2
C83F:E6 4F 59 INC RNDH
C841:AD 00 C0 60 GETK2 LDA KBD ;KEYPRESS?
C844:10 F4 C83B 61 BPL GETKEY ;=>NOPE
C846:8D 10 C0 62 STA KBDSTRB ;CLEAR STROBE
C849:60 63 RTS
>PUT SOLID
WHAT DO YOU WANT TO PUT THE SOLID IN?
>CASE
DONE.
s.e.open.w.u.uLanguage: diffdiff --git a/grue.fnl b/grue.fnl index 6e8c42e..48d5a34 100644 --- a/grue.fnl +++ b/grue.fnl @@ -81,11 +81,11 @@ ; (enter-commands ["go e" "go s" "go e" "open window" "go in" "go u" "go u"]) (wait-for-keyboard-ready) - (savestate.next-frame 2) ;; Delay for RNG manipulation. + (savestate.next-frame 0) ;; Delay for RNG manipulation. ;; Enter the schedule of commands. NB the "." inputs need to be manually ;; re-added to Input Log.txt in the .bk2 movie file, at least as of ;; BizHawk 2.10: https://github.com/TASEmulators/BizHawk/issues/4391. - (enter-commands ["s.e.open.in.u.u"]) + (enter-commands ["s.e.open.w.u.u"]) ;; Buffer a Space press to clear the "[MORE]". (savestate.next-frame) (savestate.joypad-press-release "Space")
Even though this submission is a joke, there are ways to improve it. Here's a movie that reduces the time from 900 frames to 500 frames.
Language: diffdiff --git a/grue.fnl b/grue.fnl index 3811692..6e8c42e 100644 --- a/grue.fnl +++ b/grue.fnl @@ -86,11 +86,9 @@ ;; re-added to Input Log.txt in the .bk2 movie file, at least as of ;; BizHawk 2.10: https://github.com/TASEmulators/BizHawk/issues/4391. (enter-commands ["s.e.open.in.u.u"]) - ;; Buffer a Return press to clear the "[MORE]". + ;; Buffer a Space press to clear the "[MORE]". (savestate.next-frame) - ;; Add a blank frame because the previous frame was also Return. - (savestate.next-frame) - (savestate.joypad-press-release "Return") + (savestate.joypad-press-release "Space") ;; Sync the emulator to the state after entering all commands, for the ;; purpose of saving a movie.
The main mechanical piece is the function wait-for-keyboard-ready, which finds the earliest frame at which keyboard input is accepted. It does this by repeatedly pressing a key, then looking forward 1 frame ((savestate.next-frame $)) to see if the most significant bit in KEYBOARD-DATA-STROBE-ADDR is clear, indicating that the program has read the input. The function is implemented in terms of earliest-effective-frame in the savestate module, which encapsulates this test-and-look-ahead procedure. Like all functions written in this style, wait-for-keyboard-ready takes a savestate object as input and produces a different savestate object as output. Savestate objects never change once created, so you could use the same input again for another purpose. Then enter-character is implemented using wait-for-keyboard-ready, also mapping string characters to Apple II key names. enter-text types in an entire string using enter-character. enter-commands enters a whole list of command strings. Originally I was expecting to have to enter multiple commands, as in #5891: adelikat's AppleII Zork I: The Great Underground Empire "Fastest eaten by a grue" in 00:15.00. That was before I learned you can join individual commands with . and thereby end input early. So the code ends up calling enter-commands with a table of length 1. I had to do a little low-level savestate.next-frame and savestate.joypad-press-release work after the commands themselves, to buffer an input to clear the [MORE] prompt that appears when too much input is produced at once. I was able to use the savestate.fnl module mostly unchanged from my experiments with Final Fantasy. But I had to add a couple of workarounds for bugs in the Apple II core (Virtu) in BizHawk. One is that joypad.getdoesn't work. For this, I added an auxiliary table inside the module that tracks the state of keyboard keys in the same way BizHawk would, and redefined joypad.get to consult this table instead of asking BizHawk directly. See JOYPAD-STATE in savestate.fnl. The other is that the keyboard state partially bleeds across savestate loads: the state of the emulator can be slightly different depending on what its state was when you loaded the savestate. This required a bit more elaborate of a workaround. I modified savestate objects to contain, in addition to a savestate ID and a schedule of inputs, the key that was registered as being pressed on their previous frame. Whenever a savestate is loaded, the code does a little procedure to sychronize the emulator's internal keyboard state with what it should be for the savestate being loaded. See ?virtu-current-key-pressed in savestate.fnl.Language: fennel;; Unload our own modules, to avoid old versions being cached in package.loaded ;; from a previous execution. (each [_ modname (ipairs [:bizhawk :savestate :util])] (tset package.loaded modname nil)) (local savestate (require :savestate)) ;; https://archive.org/details/Apple_IIe_Technical_Reference_Manual/page/n45/mode/1up ;; The least significant 7 bits of this memory location contains the most ;; recently typed character. The most significant bit (the strobe bit) is 1 ;; until the memory location 0xc010 (the clear-strobe switch) is read or ;; written. (local KEYBOARD-DATA-STROBE-ADDR 0xc000) (lambda wait-for-keyboard-ready [st] (let [(before-press _ _) (savestate.earliest-effective-frame st #(savestate.joypad-press-release $ "X") ;; Look ahead 1 frame to see if the strobe bit is 0. #(savestate.await-u8-satisfies (savestate.next-frame $) 1 KEYBOARD-DATA-STROBE-ADDR #(= 0 (band $ 0x80))))] before-press)) ;; Return the name of a joypad key that stands for the given character. (lambda key-for-character [c] (if ;; Digits and various other characters are named after themselves. (string.match c "^[%d%'%,%-%.%/%;%=%[%\\%]%`]$") c ;; Lowercase letters are named by the corresponding uppercase letter. (string.match c "^[%l]$") (string.upper c) ;; Some characters have textual names. (case (. {"\x7f" "Delete" "\x09" "Tab" "\x0a" "Return" "\x1b" "Escape" "\x20" "Space"} c) key key ;; We don't handle characters like uppercase letters, which would ;; require multiple keys (including Shift). _ (error (string.format "unknown how to enter %q" c))))) (lambda enter-character [st c ?prev-key] ;; Find the earliest frame at which the keyboard strobe bit will become 0 on ;; the following frame (indicating that the game read the input). (let [key (key-for-character c)] ;; Insert a blank frame if this key is the same as the previous one. (values (-> (if (not= key ?prev-key) st (savestate.next-frame st)) (wait-for-keyboard-ready) (savestate.joypad-press-release key)) key))) (lambda enter-text [st text] (var ?prev-key nil) (accumulate [s st c (string.gmatch text ".")] (let [(s key) (enter-character s c ?prev-key)] (set ?prev-key key) (savestate.next-frame s)))) (lambda enter-commands [st commands] (accumulate [s st i command (ipairs commands)] ;; Do a next-frame between commands, but not after the final command. (-> (if (= i 1) s (savestate.next-frame s)) (enter-text command) (enter-character "\n")))) (lambda main [] (-> (savestate.new-from-emulator!) ;; The emulator accepts an input on the very first frame, before the ;; game has begun. Skip that frame, and thereafter rely on ;; enter-character to find then next frame at which input is accepted ;; (after boot is finished and the game has presented a prompt). (savestate.next-frame) ;; Skip over most of the boot sequence, just to save time in looking for ;; the first frame that accepts keyboard input. (savestate.next-frame 450) ; ;; https://tasvideos.org/5891S inputs: ; (enter-commands ["go e" "go s" "go e" "open window" "go in" "go u" "go u"]) (wait-for-keyboard-ready) (savestate.next-frame 2) ;; Delay for RNG manipulation. ;; Enter the schedule of commands. NB the "." inputs need to be manually ;; re-added to Input Log.txt in the .bk2 movie file, at least as of ;; BizHawk 2.10: https://github.com/TASEmulators/BizHawk/issues/4391. (enter-commands ["s.e.open.in.u.u"]) ;; Buffer a Return press to clear the "[MORE]". (savestate.next-frame) ;; Add a blank frame because the previous frame was also Return. (savestate.next-frame) (savestate.joypad-press-release "Return") ;; Sync the emulator to the state after entering all commands, for the ;; purpose of saving a movie. (savestate.sync-emulator!))) (savestate.run main)
go e
go s
go e
open window
go in
go u
go us.e.open.in.u.u
[Plus an extra Return to dismiss a [MORE] prompt.]| Modification | Change in frames |
|---|---|
| Remove go e | −46 |
| Remove go everywhere | −25 |
| Remove window | −22 |
| Join commands with ., end input early | −309 |
| RNG manipulation | +2 |
I checked wram in mainmemory.read_u8 but the numbers are different, so it looks like I'm looking at ram.
memory.read_u8(addr, "WRAM")memory.getmemorydomainlist() --> {[0]="RAM", "System Bus", "PPU Bus", "CIRAM (nametables)", "PALRAM", "OAM", "Battery RAM", "PRG ROM", "VRAM", "WRAM"}Why didn't the first code work?
local val = {function(addr, val, flags)And then a "script.lua" stub that executes the main Fennel file:Language: fennel(console.log "Hello Fennel") (console.log (string.format "ROM name: %q" (gameinfo.getromname))) (local fennel (require :fennel)) ;; for fennel.view (console.log "joypad" (fennel.view (joypad.get) {:one-line? true}))
The "fennel" module comes from fennel.lua, which you just have to install in the directory alongside your scripts. The two-file approach works fine. But I found a way to get the same effect with just one file. The file is simultaneously a Lua program and a Fennel program; i.e., a polyglot. It looks like this:Language: luarequire("fennel").install().dofile("script.fnl")
The ;; marks a comment in Fennel. So from the point of view of a Fennel interpreter, the first and last lines of the file disappear, leaving only the lisp code in between. In Lua, ; is an empty statement, a no-op separator. So the Lua interpreter sees and executes the require("fennel").install().eval(...). The [==[ marks the beginning of a long literal string that lasts until the ]==] on the last line—encompassing the entire text of the Fennel program. To the Lua interpreter, the Fennel part of the program looks like one long string, which gets passed to the fennel.eval function. It would be nice if only required adding something to the top of the file, not both top and bottom, but I couldn't think of a way to do that. I've found just one problem with the polyglot approach, which is that BizHawk won't let you load a file with a ".fnl" filename extension with the --lua option on the command line. I want to name the program file "script.fnl", so that when I edit it, I get syntax highlighting and automatic indentation appropriate for Fennel. But BizHawk's --lua option only allows ".lua" and ".txt" as filename extensions, and silently ignores files with any other extension. (Except for ".luases", which I don't know what that is.) You can load .fnl files from the "Open Script" UI in the Lua Console; it's just the --lua option that doesn't work. So I have to name the file "script.lua", which adds inconvenience when editing it as Fennel code. So I might stick with the two-file method anyway. If you want to see how the Fennel code compiles to Lua, you can paste it in here.Language: lua;; return require("fennel").install().eval([==[ (console.log "Hello Fennel") (console.log (string.format "ROM name: %q" (gameinfo.getromname))) (local fennel (require :fennel)) ;; for fennel.view (console.log "joypad" (fennel.view (joypad.get) {:one-line? true})) ;; ]==])
We can’t wait to welcome you all to this year’s Roguelike Celebration on Oct 25th and 26th - but first it is time to open the door to this year’s batch of speakers! Our conference is only as good as our speakers and presenters, and luckily every year we welcome a breadth of creative, passionate, and talented individuals to step onto the virtual conference stage. The call for presenters is now open, with a submission form here. Submissions will be open until June 30th. Please be sure to pass the link along to anyone you think would have something compelling to share. We welcome all types of presentations and performances, and encourage anyone with the hint of an idea to look at our past years to see just how wide an array of topics we accept and how many different backgrounds and life experiences can make up a Roguelike Celebration speaker!
After I discovered my visualisation luascript doesn't run correctly due to syntax errors that have somehow slipped into that post… Here is the script with syntax errors "seemingly fixed".
I don't think it was a syntax error, exactly. It's just that the old script used the table.getn function, which was deprecated in Lua 5.1 and removed in Lua 5.2. BizHawk currently uses Lua 5.4. You fixed it correctly by changing it to use the # operator.Language: diff-for n=1,table.getn(addressList) do +for n=1,#addressList do
I tried to fix the script but now it will output information that's different from before (when compared to the screenshot I had posted).When running the "seemingly fixed" script, I noticed the information output is different between v1.0 and v1.1 of the game. V1.0 (Every few frames of running right)
V1.1 (Every few frames of running right)
match up with the listed addresses in the 1.1 ROM:Language: lua[2]={0x2258,0xFFFFE000,"READ FFEA"}, [3]={0x225D,0xFFFFE000,"READ FFE9"},
0x2258: ld a, [0xffea]
0x225a: cp 0x01
0x225c: ret nZ
0x225d: ld a, [0xffe9]0x224f: ld a, [0xffea]
0x2251: cp 0x01
0x2253: ret nZ
0x2254: ld a, [0xffe9]i just finished playing this game and i wanted to watch some speedruns and TASes, and the speedrun.com page says they might get removed by twitch!!! this is scary, also some of these links in the conversations don't work anymore, i hope we don't lose material for future TASing because of this inactivity!
<a class="nav-link active" title="Manage" href="/Profile"><i class="fa fa-user d-inline"></i> Sand</a><a class="nav-link" title="Manage" href="/Profile"><i class="fa fa-user d-inline"></i> Sand</a>gameend.fnl gives the overall plan of the TAS, fairly removed from the nitty-gritty of savestate manipulation. The code loads an ff1jp module for some memory address constants. The game module has subroutines specific to Final Fantasy, things like "open a menu" and "move on the map". The main function should be easy to follow. We start by advancing through the title menu and selecting a party with the given classes and names. Walk up 6 times to enter the castle (using an Up constant imported from the game module), then walk up another 16 times to reach the stairs. Walk up/down the stairs 18 times, open and close the menu, then walk up/down the stairs 13 more times. Finally, walk down the stairs a final time and open the menu to jump to the game ending sequence. How the glitch works is explained by pirohiko in Post #505719. The (restore-savestate!) at the end of main is only there for saving a movie file. As I've tried to explain, the whole point of programming in this way is not to have to think about the dynamic state of the emulator, but rather to think in terms of pure functions operating on immutable data. The emulator is just a tool that computes functions over savestates. But saving a movie from the BizHawk menu is one of the rare times we do care about the exact emulator state. The restore-savestate! function syncs the emulator with the final computed savestate and its input log, so you can "Stop Movie" in BizHawk and have a movie that ends exactly there. The function's name ends in an exclamation point to emphasize that it is not a pure function, but depends on or alters global state (which is a naming convention in Fennel). The next level of abstraction down is the game module, in game.fnl. The functions in this module describe how to do actions that are specific to the game of Final Fantasy, implemented on top of the lower-level code in the savestate module. The functions vary in complexity: title-menu, for example, accounts for input differences in the Japanese and USA releases of the game, and party-select computes an optimal sequence of inputs to enter the given names. Let's look at an easy function, await-screen-wipe, which waits for the horizontal screen wipe transition effect to finish:Language: fennel;; Unload our own modules, to avoid old versions being cached in package.loaded ;; from a previous execution. (each [_ modname (ipairs [:ff1 :ff1jp :game :savestate :ucs :util])] (tset package.loaded modname nil)) ;; Here we load a version-specific ff1 module, then additionally store it as ;; package.loaded.ff1. Other modules will require it simply as :ff1. (local ff1 (require :ff1jp)) (tset package.loaded :ff1 ff1) (local game (require :game)) (local {: run : restore-savestate!} (require :savestate)) (local {: Up : Down} game) ;; Call f iteratively n times, starting with the value init. (lambda times [init n f] (faccumulate [acc init _ 1 n] (f acc))) (lambda main [savestate] (-> savestate ;; Do the title menu and party selection. (game.title-menu 0) (game.party-select {:class ff1.CONST.CLS.FT :name [0x8b 0x90 0x91 0x96]} ; いきくす {:class ff1.CONST.CLS.TH :name [0xaf 0xb2 0x8d 0x90]} ; よるえき {:class ff1.CONST.CLS.BB :name [0x4c 0x51 0x50 0x55]} ; ごぞぜで {:class ff1.CONST.CLS.RM :name [0x9a 0x4c 0x9f 0xaa]}) ; ちごにむ ;; Enter the overworld. (game.await-screen-wipe) ;; Enter Coneria Castle. (times 6 #(game.move-on-map $ Up)) (game.await-screen-wipe-2) ;; Approach the stairs. (times 16 #(game.move-on-map $ Up)) ;; Start the repeated stair traversals. (times 18 #(-> $ (game.move-on-map Up) ; Step onto stairs. (game.await-screen-wipe-2) ; Screen transition. (game.move-on-map Down))) ; Step off of stairs. ;; Open and close the menu. (game.open-menu) (game.await-palette-cycle) (game.close-menu) (game.await-palette-cycle) ;; More stair traversals. (times 13 #(-> $ (game.move-on-map Up) ; Step onto stairs. (game.await-screen-wipe-2) ; Screen transition. (game.move-on-map Down))) ; Step off of stairs. ;; One last stair traversal. (game.move-on-map Up) (game.await-screen-wipe-2) ;; Open the menu. (game.open-menu) ;; Sync the emulator state to the final computed savestate, in order to ;; save a movie. (restore-savestate!))) (assert (run main))
The implementation is simple: using the await-exec function from the savestate module, let the emulator run for up to 128 frames until the code address ScreenWipe_Finalize is executed, then return the resulting savestate. If the address is not executed within 128 frames, something is not as expected, so raise an error. await-screen-wipe is a good example of how Fennel compiles to Lua:Language: fennel(lambda await-screen-wipe [savestate] (assert (await-exec savestate 128 ff1.CODE.ScreenWipe_Finalize)))
There's also await-screen-wipe-2, which just waits for two screen wipes in sequence, such as happen when climbing or descending stairs:Language: lualocal function await_screen_wipe(savestate) return assert(await_exec(savestate, 128, ff1.CODE.ScreenWipe_Finalize)) end
The -> macro is useful for sequences of operations like this, where the output of one function becomes the input to the next function. We pass the input savestate to await-screen-wipe to get a new savestate, then pass that new savestate into another invocation of await-screen-wipe. You'll see -> used also in the main function in gameend.fnl. This is how await-screen-wipe-2 compiles to Lua:Language: fennel(lambda await-screen-wipe-2 [savestate] (-> savestate (await-screen-wipe) (await-screen-wipe)))
The savestate module is the lowest level of abstraction, the code that interfaces directly with the running state of the emulator. It does all the event registration / coroutine yield / callback operations as were described in Post #532299. await-screen-wipe was defined in terms of await-exec from the savestate module, so let's look at await-exec:Language: lualocal function await_screen_wipe_2(savestate) return await_screen_wipe(await_screen_wipe(savestate)) end
As you can see, await-exec just passes the given savestate and ?frame-limit (name prefixed by a question mark to indicate it may be nil) to the await-event function, along with a function that describes how to register an event listener for the specific BizHawk event we're looking for (using the # and $ syntax for anonymous functions). await-event is the analog of what was called run_until_event in Post #532299, a core function whose purpose is to let the emulator run until an event happens, then return. The savestate module is what makes the data-oriented programming style possible. It's where the most complicated code is, but if you're interested in looking at it yourself, it's really not that bad: just 400 lines, plenty of which are comments.Language: fennel;; Return a new savestate representing the state of the emulator at the frame ;; boundary after the address addr is executed, or nil if ?frame-limit is ;; reached. (lambda await-exec [savestate ?frame-limit addr] (await-event savestate ?frame-limit #(bizhawk.event.on_bus_exec $ addr)))
The current version of the support code wouldn't work well for press-and-hold inputs (Kwirk only needs one-frame presses). In order to hold buttons in a convenient way, you may have to enrich the savestate object to support some kind of "sticky" inputs that don't become unpressed when the frame is advanced.
CPP pushed a fix for pcall, so please try again with a new dev build.
A B C D E F G H I J
K L M N O P Q R S T
U V W X Y Z ’ , .
0 1 2 3 4 5 6 7 8 9
a b c d e f g h i j
k l m n o p q r s t
u v w x y z - ‥ ! ?|..|...R....| 'B'
|..|.D......| 'L'
|..|...R....| 'M'
|..|.D......| 'W'
|..|.......A||..|...R....| 'e'
|..|........|
|..|...R....| 'f'
|..|........|
|..|...R....| 'g'
|..|.......A||..|...R....| 'e'
|..|..LR....| 'f'
|..|...R....| 'g'
|..|.......A|あいうえおがぎぐげご
かきくけこざじずぜぞ
さしすせそだぢづでど
たちつてとばびぶべぼ
なにぬねのぱぴぷぺぽ
はひふへほゃゅょっ。
まみむめも０１２３４
らりるれろ５６７８９
やゆよわん－！？‥ |..|.D......|........| 'か'
|..|...R....|........| 'き'
|..|.D......|........| 'し'
|..|U.L.....|........| 'ち'
|..|.......A|........|