I realized that stat() is basically a peek() analogue for system status registers.

To my knowledge, there is currently no functionality attached to the second arg onwards.

Would it be a good idea to let stat(index, n) return an n-tuple just like peek(addr, n) does?

It'd allow simplifications like this:

_update60()
  -- mouse stats
  _mx,_my,_mb=stat(32,3)

  -- or keep a fifo list of the last second's worth of mouse stats:
  deli(_m,#m)
  ins(_m,1,{stat(32,3)})
  print(_m[16][3]) -- print the buttons 0.25 seconds ago

  -- or take a snapshot of all stat() values at the start of _update()
  -- (probably silly but you can imagine subsets being useful)
  _statshot={stat(1,255)}
end

_init()
  -- fifo used above
  _m={} for i=1,60 do _m[i]=0 end
end

Seems like a simple little QoL thing, I hope?

Wow, didn't realize you could peek multiple values at once with peek. How feasible is it to peek the entire screen into a nice array, do some effect tweaking (add noise by pixel swaps for example) and poke back the updated screen into video ram, performance wise ? You'd still get two pixels per value but it'd still be much more convenient than picking the pixels one by one or one byte at a time.

Note that there's is already a stat command - 28 - which accepts a second argument for other purposes.

But doing this for other cases would still be useful, for querying the wall clock as well.

@thisismypassword
Ah, yeah, the wall clock would be a great example.

That's too bad about the raw keyboard scancodes. It might have been better to have some arbitrary 256-long range of scancode stats:

if(stat(28, 0x1c)) print("enter key")
        vs.
if(stat(0xff1c)) print("enter key")

you could even make the prefix 0x5C for 5canCode. 😉

But @zep probably won't want to break back-compat at this point by redoing that. Hey @zep, what do you think?

I guess you could special-case 28... I mean, retro systems were all about that kind of hacky jank.

I agree that this useful feature will be added.

If I were to implement a feature, several options would come to mind.

• A new API separate from the current STAT() will be implemented to ensure compatibility without any problems.
  Just like the relationship between ADD(), DEL(), and DELI().
  (Like when index specification for ADD() was implemented in v0.2.1 and DELI() was implemented for DEL())

• Or make it possible for desired values (especially mouse input!) to be formally retrieved through new APIs (MOUSE(), DATE(), etc.). This will be easier for new users to understand.

• As an example where the implementation cost is low, STAT(STRING) returns multiple values associated with it. However, I personally feel like this takes away from the retro console feel.