Shortcuts for operations applying to whole chip?

[jscrane]

I've been bitten a couple of times now by just entering the r key on its own and being surprised by just receiving 256 bytes from xmodem. (This is due to defaulting end to 0xff, I guess maybe for the d command?)

Would it be worthwhile to add some new commands, e.g., R, D, etc, which operate on the entire chip? I'm happy to take a crack at it...

[TomNisbet]

Having better defaults for the commands or having them fail if the parameters are not specified is a good idea. I'm not too keen on adding case-sensitive commands though. Using prom.size() to default commands like R is absolutely the correct answer. Even though the device size is specified in the constructor, I don't think it is actually used or enforced anywhere.

The current implementation of 255 as the end address was just me being lazy to get a very useful D0 command to dump the first block of memory. It does produce unfortunate side effect with other commands.

A better approach would be to define an uninitialized value, like 0ffffffff, and then have the individual commands check for parameters present and either fail or create their own defaults for missing parameters. That would let the Dump command default to start=0 and end=start+255. The Read and IsBlank commands would very naturally default to the entire device.

I'm not sure about defaults for some of the others and interested to hear your thoughts.

[jscrane]

"make the easy things easy, and the hard things possible"

Perhaps everything which takes start + end should default to the whole chip? Certainly B/C/E/R/S.

F might be ambiguous with defaults for start and end? I'm not sure how it is handled now.

D could default to start=0, end=start+$ff. It might be interesting to set start=end+1 and save it for next time, so you could go D, D, ,,,?

I agree about using an uninitialized value to allow commands to set their own defaults, instead of introducing new commands.

[TomNisbet]

Agree that B/C/R/S should default to the whole chip.

It might be better to have E and F fail if all parameters are not specified. Right now, if you just type F it will fill the first 256 bytes with FF. That's probably not expected or useful. The W command defaults to zero, which makes sense, but you also need to start a transfer before any data is written to the chip. That doesn't let you accidentally write to your chip the way the E and F would.

I like the idea of having the Dump command page through the chip. That's a nice enhancement.

[jscrane]

OK: #70

[TomNisbet]

I've recently acquired some old Atari cartridges that use 2316 and 2332 ROMs and have been trying to read them. The new default behavior of the Dump command made it so easy to page through the chips. Thanks for adding that!