THE 64 - Computer and Handheld Console


That would depend entirely on the emulator they've used. If they've created their own bespoke system then it might not, but if they've used VICE (and all indications are that they have, unlike their Spectrum Vega which used a custom job) then it might.

Coincidentally, there's work afoot to remove input lag even from games that have it built in - Sonic has two frames of input lag, so for each frame they emulate, they store two frames previous as machine-state snapshots. If input is detected, they roll back by two frames and inject the input into the new (old) machine state and re-emulate those next two frames so that there's no input lag. Fascinating stuff.
 
Well, VICE is GPLv2 licensed, so you're free to tivoise it. I'm not sure what Spectrum emulators they looked at, but if all the ones they were interested in using were GPLv3 licensed, they'd need to get it relicensed to be able to use it in a commercial product I think.

That menthod of removing lag is interesting, but suboptimal I'd suggest. Any test like the one we saw that illustrates the lag by flashing the screen or beeping will still show lag between the joystick being pressed and the indicator being received, and a game like sonic would show two frames of him tapping his foot before he'd suddenly running two frames forward including two frames of distance travelled. You'd miss two frames of animation, if any C64 games have non-repeating transition animations like that. Perhaps it's not an important disctinction when it comes to 8-bit games, but I wouldn't like to see an approach done on anything 32-bit or later, from about a decade or so on. Just imagine Street Fighter 3 Third Strike crippled like that!
 
Well, VICE is GPLv2 licensed, so you're free to tivoise it. I'm not sure what Spectrum emulators they looked at, but if all the ones they were interested in using were GPLv3 licensed, they'd need to get it relicensed to be able to use it in a commercial product I think.

For the Vega, it was a home-grown emulation written in-house. For the Vega+ with the departure of the two directors, they used Fuse, the Free Unix Spectrum Emulator that's under the GPL. Of course, that's not been released as of yet.

That menthod of removing lag is interesting, but suboptimal I'd suggest. Any test like the one we saw that illustrates the lag by flashing the screen or beeping will still show lag between the joystick being pressed and the indicator being received, and a game like sonic would show two frames of him tapping his foot before he'd suddenly running two frames forward including two frames of distance travelled. You'd miss two frames of animation, if any C64 games have non-repeating transition animations like that. Perhaps it's not an important disctinction when it comes to 8-bit games, but I wouldn't like to see an approach done on anything 32-bit or later, from about a decade or so on. Just imagine Street Fighter 3 Third Strike crippled like that!

At the risk of derailing this thread, I'll go on. You don't lose any frames at all. Consider Sonic again:

Emulate a frame of CPU work, including graphics. Save the state in a two-frame buffer.
Emulate another frame, save that state also.
Emulate another frame, but detect user input - so re-load the first frame from the buffer.
Now, with the user input present, re-emulate both stored frames (and this third frame) without disturbing the display.
Display this new frame.
Continue, using a rotating pointer to the state buffer.

Because emulation is not time-bound, the user notices no missing frames because instead of Sonic starting his running animation two frames from now, he starts it on the same frame the user initiated the action. The effect is that input no longer has a lag of two frames and appears immediately responsive to the user.

Now, it's not authentic as Sonic has been coded by the original authors with a two-frame delay for input-response on the original hardware. But it does present an interesting mechanic. All the user has to do is tell the emulator how many emulation frames the game will skip before responding to input. And it will glitch if the game doesn't actually wait that long, you have to know what the input lag was originally. But for hardware that has built-in lag, it will be very interesting indeed and useful to overcome it.

Possibly.
 
True, but as far as I know nobody's added netcode to the SF3 series, so it is a deterministic system based entirely on local inputs. That's one of it's main interests to people who care about that sort of thing, but there are more people who want online, and then you have to sacrifice this determinism slightly. And those presumably only kick in when lag is detected - you won't always lose the first two frames after a transition like this does.

Even the mighty SF3 will have some intrinsic lag, as you might hit the button just at the start of it painting a frame, and as far as I know it's vsync locked, so it'll take until the start of the next frame for your input to have any effect. That's only about 30ms or so in the worst case though. I don't generally mind a bit of lag though, and would probably even take 8 frames of lag over two of the frames that were expertly painted by Capcom artists always being omitted, especially in the case of these old 2D hand-drawn games.

Edit: Yes, if this is lag that's built into the original code, then you're hiding nothing, and just improving the responsiveness. It wouldn't be the same as the original game, but provided I can turn it on and off, it might be worth experimenting with.
 
True, but as far as I know nobody's added netcode to the SF3 series
Really? When GGPO used to be a platform too, you could play SF3. Also the XBox (and PS) ports had netplay... and the new anniversary edition that's due out has netplay version.

Rollback in fighting games don't "buffer" the input like is being described here, but rather every frame is basically cached and as updates are sent between players, if there's any differences between frames, the game rolls back to the last consistant frame between players, adjusts inputs for both players and resumes.

The SFV input lag that I was referring to as well is the way the game buffers inputs, but rather than rolling the game back, it's used to determine if special moves have been entered etc.
 
Sorry if that sounded a bit condescending, reading it back now, it kinda sounds a bit, but that wasn't intentional.
 
The C64 Mini got a new firmware v1.1.2, that allows easier handling of files etc.

Easy handling of e.g .d82 (1mb!) and .crt (e.g. EasyFlash, some reported EF3 working?), in combination with save-state game slots makes this cute thing quite usable.
more info here:
https://thec64.com/file-loader/

New, NTSC version arrived to USA market:
 
Hmm I'll try to give it a go this weekend :)
[doublepost=1539370530,1539367782][/doublepost]Just tried it and it's a good update. The usb icon makes it so much easier to load and run disk files!

I downloaded a bunch from the Freeze 64 website, which has some good collections, and also ones specifically hacked to fix the second joystick issue with the mini:
https://freeze64.com/c64mini-hacks/ (the fanzine Vinny produces there is really good too)

I also found out that my USB SNES controller works ("iBuffalo") just fine so I'm happy :)
 
New firmware update added Galencia to Carousel (Menu) of Mini. What a lovely gift for Christmas!
But there is one potentially annoying thing with this update: it brings "virtual joystick" to numeric pad, 2 configuration (NumLock on/off). But it means no numerics at numpad anymore! People who used C64 Mini for programming are furious now.
I hope it will be fixed soon.
Btw, It is officially confirmed that "full" (big) version is coming in 2019. Mini is selling well, appearing of big version will cannibalise whole sale. I don't think it will come before Q2.

Another interesting stuff is that RGL announced they are looking for software & hardware partnerships for TheC64 project! (hint: Galencia). So if anybody wants to sell his games or adapters to TheC64... :D
Happy Holidays folks!

Edit: and now it comes - it is alive! :D
 
Last edited:
The C64 never had a number pad as I recall, none of the 8-bit home computers did as I recall. I don't know any programmers myself who ever used the number pad myself, it always seemed to be something more used by payroll accountants in my experience who came to computers from desktop calculators, or maybe I'm just showing my age here.
 
The C64 never had a number pad as I recall, none of the 8-bit home computers did as I recall. I don't know any programmers myself who ever used the number pad myself, it always seemed to be something more used by payroll accountants in my experience who came to computers from desktop calculators, or maybe I'm just showing my age here.
I never thought I used it much... until I bought a mechanical keyboard without one... then I was surprised how many times I went for the keypad only to find that it wasn't there.
Not so much in direct programming, but used in calculator usage and data entry. Entering numbers using a 3x4 grid is much easier than a 10x1 row
 
As someone who grew up in the 8-bit era, I never really adjusted to having a number pad, and given most laptops don't have one that's probably a benefit these days. I think that last time I used one was playing Tomb Raider 1 on a PC without a compatible joystick; far easier remembering that 2 and 8 are forward and back if they are forward and back of a central 5 key rather than having to find them on a single row.
 
The C64 never had a number pad as I recall, none of the 8-bit home computers did as I recall. I don't know any programmers myself who ever used the number pad myself, it always seemed to be something more used by payroll accountants in my experience who came to computers from desktop calculators, or maybe I'm just showing my age here.
You never typed in data lines? Really? Well, we employed once Sam/Reciter ("Say It") to read it for us, in search for typos. It was that thing I missed at C64: e.g. you recalculate your sprites or music, and then - type, type, type...
Btw, as a student I was employed at AmEx to enter "slips" (bills); it was so well payed that I learned that extremely well. They even "rented" me (no kidding) when there was rush somewhere...
Howling AL, author of NAV, co-author of DotBASIC+ etc is now using Mini with some hobby programming. He was pretty much furious when he updated firmware... He even bought new keyboard just for Mini iirc :D
But as I see now he is playing Galencia so it is not so bad I suppose ;)
 
I've typed in plenty of data lines for type in listings or character sprites or envelopes back in the day, and I didn't have a number pad so learned to use the top numbers pretty reliably. These days big data tends to go into some data file rather than being embedded in the source, but I still never learned to use the number pad to do it.
 
You never typed in data lines? Really?

Of course we did. Huge lists of numbers (or more commonly towards the mid-80s - Hex notation in strings) from magazine type-in games. But the C64 didn't have a number pad so we didn't use one, you know? In fact, at least on the Speccy where I spent most of my youth, a number pad would have been a hindrance when typing in hex data. Actually, the Speccy 128k did get a number pad but it was only available for the Spanish version so quite rare in the UK.
 
It's interesting, because back in the day, I bought an Amiga 600 mostly because it didn't have the number pad (though I wish I had gone for the A1200 in the end, all the software on magazines seemed to indicate A500 or A1200, and finding out if it worked on the A600 was a bit trial and error IIRC).
 
Back
Top