I'm not a TAS expert, but my understanding is that the vast majority of console games had all of their code and operations synchronized to the frame rate, so practically everything was handled in nice, clean frame increments (image updated once per frame, inputs read once per frame, etc.). And, because the consoles were designed to run on TVs, the frame rate was always constant because the old standard-definition CRT TVs were designed to run only at a specific scanning frequency dictated by the region's broadcasting standards (NTSC/PAL/whatever). This makes console TASs fairly straightforward (in theory, at least) to work with.

Calculators are a bit weird, though, because games aren't necessarily synchronized with the display refresh. They often just run loops at some arbitrary speed. Some games might use interrupt timers to regulate their speed (and some might have the timers set to different frequencies than others), others might have do-nothing delay loops or nothing at all, leaving their running speed entirely dependent on CPU speed. And the actual key reads could happen who-knows-where in the code at who-knows-what frequency. So TASing tools for calculators would be a lot trickier to implement, I think.

Since the precise timing and content of the inputs are the primary things that makes a TAS reproducible, if I understand correctly, and not necessarily when frames are drawn, it would be important to have the timing resolution be determined by the reading of inputs. Since calc programs can read keys or the link port or whatever at literally any time, one would either need to know the code to set breakpoints in the appropriate places, or the emulator might need to detect when they're being read and pause there so the user could define the next input. The "frame rate" of a game would thus vary depending on how often the game reads the inputs, which might not actually be at a steady, predictable rate depending on how it was coded.

I fooled around a little with a simple program that counts as fast as possible. Double-buffering definitely seems to be the way to go, even for fairly simple stuff. Screen updates are very smooth and flicker-free that way. Of course, it's even faster just writing text directly to the screen (G0), but not surprisingly it flickers like mad. Unfortunately, I think I see some evidence of tearing sometimes (I guess there's no way to sync blits to LCD refresh rate) but just being able to control when the screen updates is already a very important and powerful feature.

In response to IRC (I was AFK), I don't mind splitting this discussion. I was actually wondering if I was derailing the thread too much.

I haven't tried it myself before yet, but I think It's sort of similar to how a lot of games on old consoles like the NES worked, I think. They had pretty slow CPUs by today's standards (often even slower than the old Z80 calcs, I think), but even worse, they couldn't access video RAM at the same time as the video output hardware. The video hardware had to read it almost all of the time to send the signal to the TV (which required a constant 50/60 FPS depending on NTSC/PAL), and the game program only had just enough time between frames to update maybe a couple of rows of offscreen tiles at a time or something like that. In some games when there were too many things on the screen and they lagged, IIRC there would be graphical glitches if the CPU didn't finish updating video RAM in time before the controller started reading it again for the next frame. This happens in Zelda II and TMNT I, for instance (where the screen jumps up and down or the HUD flickers on and off during lag).

Thankfully, we don't have to worry about all that on the calcs

But anyway, in a platformer, for instance, you might have variables to keep track of the current X and Y scroll offset and add/subtract it when checking screen coordinates of the objects to figure out where on the screen they actually are while taking the scrolling in account. Or something like that. In my first games, I'll likely just have the scrolling happen either a screen or a tile at a time as an animation (either like Zelda I or in games like Final Fantasy where you move on a map only in tile increments, and nothing else happens during the actual scrolling), which should be easier to do.

Quote from: DJ Omnimaga on August 12, 2016, 02:54:19 AMThe fade-in/out pixelating effects uses the buffer scaling capabilities. The only issue is that like with Z80 calcs, FOR instructions are slow it seems. A 20x15 tiles map will give you 15 FPS. But you can simply pre-render the current screen, then when you scroll around you only draw the edge that's missing.

Ah, neat. Is the 15 FPS you mention when trying to redraw everything every single frame (all 300 tiles and all sprites)? I was thinking about this and was imagining that with a scrolling tilemap, I'd render all tiles once and then only render an additional column or row (depending on scroll direction) just before it scrolls on screen, possibly using a back-buffer GROB one tile larger than the screen in each direction to do so. It sounds like this is what you're describing. I figure that'd indeed be a lot faster.

Cool.

Yeah, I stayed up late last night reading through the programming section of the user guide, and the programming language looks like it should be capable enough. Graphics programming looks interesting, as the GROB functionality in general looks quite similar to that on the HP 50g, including the ability to do double-buffering and stuff, which is pretty cool. I never did a whole lot of graphics stuff on the 50g (just a tiny bit), but I'm fairly familiar with how it works and what's possible.

One thing that may take me some getting used to is the lack of a true directory structure/file system, and of course the ability to back up/archive data on an SD card, which is how I was able to dodge the whole "how am I going to connect this thing to Linux, and will the third-party Linux software work well?" issue with the 50g: The SD card is FAT, which has worked fine on Linux for ages. I wish they had made the Prime emulate a normal USB FAT disk for file transfer and such; that would have been very simple and universal and would have avoided the need for special PC communication software.

I'm also a bit underwhelmed with the program editor, to be honest. It seems rather lacking in functionality compared to the 50g's editor. Apparently there's no search or quick navigation like jumping directly to subprogram definitions (I fear that navigating large, complex programs is going to be painful), and it's not even indentation aware. But looking through the available commands, I see there does appear to be commands to read and write to the actual program sources, so maybe it would be possible to write a better on-calc program editor.

Quote from: DJ Omnimaga on June 29, 2016, 06:02:23 AM
Yeah the issue is that the mailing lists were closed in late 2003 (they were still kinda open, but no longer public on Ticalc.org website, so few people knew they still existed) and then it took almost a decade before they open again in Google groups form. It's kinda hard to regain an audience after a 10 years hiatus during which the audience moved elsewhere.

Yeah, adding to that problem, I figure, might be that the lists are probably not very visible on the site. I feel that a lot of important things on ticalc.org are kind of hidden or hard to find in the site navigation considering our current target audience. I always wondered if we should do some sort of restructuring of the site content, but I haven't yet put much thought into it.

Quote from: DJ Omnimaga on June 22, 2016, 12:58:53 AMFun fact: Their current design dates back in August 1999 and still uses uppercase HTML tags (I was sure they were removed a few years ago, but maybe @Travis re-added them for the 20th anniversary?). They also didn't use ads until November 2006 (they had an april fools joke in 2001 where they added them)

The tag style just depends on who wrote that piece of HTML at the time (the news posts, for instance, are edited in raw HTML and injected into the appropriate page templates, which themselves contain even older HTML code that rarely changes). All the original markup uses uppercase tags, but as parts of the site were added and edited by different people, some of them were used to other styles and used them (or in my case, just got lazy and stopped bothering with caps ). If you look around, you'll probably find pages with random mixes of upper/lowercase tags as well as other weird style inconsistencies.

I wonder if anyone's told the EFF about this. They're all over that kind of abuse.

They helped us fight back against TI in the calc signing keys debacle some years ago.

Yeah, the Sennheiser headphones I bought have a removable cord, and I thought that was really nice. They came with an extra cord which is really long but would double as a replacement if I have any problems like I did with *cough*Bose*cough* headphones I had before which had rubbish design and were guaranteed to fail at the plug after a few months.

But it's been a few years, and I still haven't had any problems with the first cord yet. 

In basic terms, they have microphones on the outside that pick up surrounding sound. Then they take that sound, invert the sound waves (turn them upside down) and play them out the headphones along with the music or whatever you're playing. The inverted waves are opposite to the ambient ones reaching your ears at the same time, so they cancel out and get quieter.

It's kind of like when you push on a box lying on the ground from opposite sides at the same time with the same amount of force. It doesn't go anywhere because the forces match and cancel each other out. The noise-canceling headphones try to cancel the surrounding sounds by opposing the sound waves in the opposite direction and at the same volume.

I actually experimented with switching to left-handed mousing (or a trackball, in my case) quite a few years ago, just to see what it would be like. (This was probably around the time I learned and started using the Dvorak keyboard layout just to see what all the fuss was about. ) I don't remember everything very clearly, but I did get adjusted to it after a while. I would use it that way for a while and then switch again for a change in pace. Today, I just use it right-handed for now—my current desk layout and current type of trackball doesn't really support anything else, and I no longer seem to be the type of person to change things for change's sake as I once was.

As for ergonomics, though, the perfect case is a pointing device like the IBM Trackpoint which allows mouse usage without even removing the fingers from the home row keys. I once bought a Unicomp keyboard with such a thing thinking it would be great, but they screwed the design up so it works more like a joystick than a proper Trackpoint, so it's hard to use, and the buttons are crap and double-click all the time with a single press. Durability is also really poor. (Also, they lack basic scroll wheel and middle-clicking!) If they had designed it properly, it would have been perfect. Then I might not curse at poorly-designed GUIs that force me to constantly switch between keyboard and mouse so much.

Trackpoints were once common in a lot of laptops. Sadly, these days they almost all seem to be touchpads. I don't understand why. I hate them! I'm pretty sure they slow me down a lot more with their consistently rubbish accuracy and glitchiness than switching my desktop mouse/trackball back to lefthanded use would.

Well, there's your problem—the cloning mod is clearly cloning not just topics, but karma, too.

Who knows what else it might be cloning... 

It seems like I once heard of a reading method like this. It's an interesting concept, being able to read without moving the eyes. On the other hand, when I'm reading I often don't read in a perfectly linear way. If I feel like I missed something I'll often immediately jump backward to an arbitrary point briefly to reread a few words, and other times if I get bored or am looking for something I may start jumping ahead. And how fast I can read comfortably with decent comprehension depends greatly on context, my purpose of reading, and how fast I happen to be able to process information at the moment. This method seems to force linear reading at a set rate, which could be cumbersome at times.

Personally, I'd say use whichever you have lying around. Or flip a coin. It's not likely to make a big difference in the long run for what you're doing.

Quote from: DJ Omnimaga on February 07, 2016, 05:03:58 AM
@Travis and @tr1p1ea probably remembers the Book of TI: http://www.ticalc.org/archives/news/articles/13/131/131734.html

Nice. I actually sort of misremembered what it was. I thought you were talking about that wall of all-caps text someone posted on ticalc.org comments, but this is a fake news post Michael made.

QuoteWell, remember: If something exists, there's a walrus of it:

Hmm, is there one of Jamie Hyneman? He's often referred to as a walrus.