Emulators will become more important in the future...
category: general [glöplog]
This video shows the stark horrible difference between LCD and CRT, on a platform that was designed for the latter:
https://www.youtube.com/watch?v=v3SZkjF1RDI
https://www.youtube.com/watch?v=v3SZkjF1RDI
Pretty sure I've watched "Total Triple Trouble" 100% on WinUAE, have you configured it properly? (don't just use the stock settings for each device) Which is another thing, I wonder how many people are using some old version of WinVICE and moaning about emulators here. Honestly as so many people use them for dev work there isn't that much that doesn't run 100% anymore. For a start that latest Censor demo's loader isn't going to run on old versions but is fine on new builds.
Both AMD and Nvidia are pushing towards variable refresh rate instead of being locked to something like 50 Hz. They have worked with VESA and the feature is already available in DisplayPort, so it's not entirely unthinkable that HDMI and TVs will get support in the future. Perhaps that would solve the timing issues.
emulators should add fake CRT postprocessing shaders in their display routines! and some low Hz hum in the audio and random flickering and static to simulate old and bad connectors!
Some of them do.
Quote:
Some of us don't have the space or money for the real stuff, Groepaz ;)
considering you have the money to buy a PC that is powerful enough to run those emus, the money argument is hilarious. as for space - dig yourself a bigger hole.
Quote:
The two interlaced fields that make up a full frame have slightly different timing, so when old consoles and home computers trick the TV into half resolution progressive scan by sending a technically illegal signal that only consists of upper or lower fields, the resulting framerate is slightly higher or lower.
the progressive signal being "illegal" or "out of specs" is actually a myth :) that said, the actual signal produced by the C64 (and many other devices of that era) _IS_ out of spec, but for other reasons =)
Quote:
the progressive signal being "illegal" or "out of specs" is actually a myth
Maybe "illegal" or "out of spec" aren't the right words because the timing differences were well within tolerances IIRC, but it was non-standard, not supported by a lot of broadcast equipment, and forbidden to broadcast. If you have evidence to the contrary I'm very eager to read about it. :)
No such thing as an accurate C64 palette, there's just a margin of error. Most emulators have a palette that fits well within the margin of error seen on actual machines so yeah.
Same goes for SID filters. Especially the 6581.
Welcome to the Digital-Analog hybrid hell!
Also, are C64s still being manufactured? If not, maybe it's time to realize that the prices are only gonna go up with time, so while they might be cheap today (But without software it's just a pretty paperweight so you gotta buy some data transfer stuff which costs over twice as much AFAIK! Or you can just poke in one-filer demos/intros byte-by-byte, if you're insane and in dire need of carpal tunnel syndrome.) they won't be affordable by an average person sooner or later.
Emulators will, sooner or later, be the only way (for majority of people at first, then for everyone as the last piece of compatible hardware that lays in some rich retro collector's hands just dies) to experience software developed for those machines. You might not like it, but whining ain't gonna do much about it, sorry. You just gotta accept this fact.
And damn, that's quite depressing actually.
Same goes for SID filters. Especially the 6581.
Welcome to the Digital-Analog hybrid hell!
Also, are C64s still being manufactured? If not, maybe it's time to realize that the prices are only gonna go up with time, so while they might be cheap today (But without software it's just a pretty paperweight so you gotta buy some data transfer stuff which costs over twice as much AFAIK! Or you can just poke in one-filer demos/intros byte-by-byte, if you're insane and in dire need of carpal tunnel syndrome.) they won't be affordable by an average person sooner or later.
Emulators will, sooner or later, be the only way (for majority of people at first, then for everyone as the last piece of compatible hardware that lays in some rich retro collector's hands just dies) to experience software developed for those machines. You might not like it, but whining ain't gonna do much about it, sorry. You just gotta accept this fact.
And damn, that's quite depressing actually.
TomoAlien: Nothing would prevent people of the future to 3D-print their perfect replicas of C64. Not emulators... replicators!
replicator it beautiful
Quote:
TomoAlien: Nothing would prevent people of the future to 3D-print their perfect replicas of C64. Not emulators... replicators!
3D printing is such bullcrap, so overrated and I don't believe for one moment the things I've seen have been 3D-printed. No-one EVER heard anything about it until just a few short years ago, and I think it's a big scam, frankly.
TomoAlien: So while you still have it, document it while you can.
ham: Let me know when 3D printers can print working electronics, not just plastic models that looks like a C64.
ham: Let me know when 3D printers can print working electronics, not just plastic models that looks like a C64.
Quote:
TomoAlien: So while you still have it, document it while you can.
That implies reverse-engineering. Why reverse-engineer at ALL? Don't these microchip designs get published?
Isn't it obvious that the answer is "no"? Would you want your comptetion to be able to rebuild all your hardware components?
Foebane72: Yes they do get published. But a lot of demo production eventually works it's way into things the chips do that wasn't intended or documented, and that's what needs to be covered.
I also admit I'm discussing this from the perspective of someone who's written code for the PC platform where there's a lot more variation in hardware and a lot of undocumented quirks to documented hardware. Many obscure tests in older DOS programs and even still in the Linux kernel are testament to that.
I also admit I'm discussing this from the perspective of someone who's written code for the PC platform where there's a lot more variation in hardware and a lot of undocumented quirks to documented hardware. Many obscure tests in older DOS programs and even still in the Linux kernel are testament to that.
TheGreatCodeholi: I expect 3D-printing technology will evolve to the point that you will print replacements for your living organs. So replicate a C64 will be easy and cheap.
And those emulators will be considered heresy! Replicators for the win!
And those emulators will be considered heresy! Replicators for the win!
Quote:
Quote:Some of us don't have the space or money for the real stuff, Groepaz ;)
considering you have the money to buy a PC that is powerful enough to run those emus, the money argument is hilarious. as for space - dig yourself a bigger hole.
Why is the 'space' argument digging a hole? I'm not prepared to have a huge table of 8-bit machines taking up my living room just so I can watch a few of the latest demos on platforms that I have no real interest in doing anything else with. I can afford the hardware if I want but having a "computer collection" doesn't fit into my urban apartment / lifestyle.
This would be like if I demanded everyone set up a DOS machine with a GUS just for the privilege of listening to my modules. It's ridiculous. No one's going to do that, and the players for them on other platforms are perfectly good (even if sometimes only 99% accurate instead of 100%.) Why wouldn't I want them accessible to as wide of an audience as possible?
( Not to mention the Pentium 4 PC I built out scavenged components from the garbage is powerful enough to emulate every 8-bit platform there is and even does a credible job with FS-UAE and Hatari. Cost: free. )
Quote:
This would be like if I demanded everyone set up a DOS machine with a GUS just for the privilege of listening to my modules.
I always wondered about musicians insisting that listeners use GUS for their XM files. AFAIK GUS used linear interpolation, just like FT2's software mixer with SB16. Was either implementation buggy? Or was it to ensure lower sample rate if more than 14 channels were used?
Of course, if some of those modules got four channels you must play them on Amiga no less!
Quote:
I always wondered about musicians insisting that listeners use GUS for their XM files. AFAIK GUS used linear interpolation, just like FT2's software mixer with SB16. Was either implementation buggy? Or was it to ensure lower sample rate if more than 14 channels were used?
Early GUS cards 'probably' had better quality output DACs than pre-AWE SBs ... but that's not saying much. :p The authors could have been concerned that 486-era PCs weren't powerful enough to play their big complicated XMs in software, but I'm guessing 99% is just platform-wankery (GUS IS BEST, HATERS GONNA HATE, WOOOOO.)
Quote:
Maybe "illegal" or "out of spec" aren't the right words because the timing differences were well within tolerances IIRC, but it was non-standard, not supported by a lot of broadcast equipment, and forbidden to broadcast. If you have evidence to the contrary I'm very eager to read about it. :)
at this point you'll have to be very careful to define what you are talking about... first there is the "progressive scan" thing which a lot of consoles/computers of that era use. that by itself is perfectly within specs - even if the specs do not explicitly say so (and no TV broadcast was ever like that). i dont know if it was "forbidden" to broadcast, perhaps it was - however according to specs all displays from that era (regardless if PAL or NTSC) _must_ be able to display that sort of signal. it wasnt ever ment for broadcast, so whether that works or not is irrelevant :)
the other thing is the non standard frequencies used by many of these consoles/computers - these are kindof out of spec, but still work because monitors/tvs can still sync to them due to how their analog circuits work. this is also the one thing a lot of "modern" equipment has problems with, unfortunately.
i wish i could give some decent links... but i cant. detail info on that topic seems to be rare, unfortunately.
Quote:
No such thing as an accurate C64 palette, there's just a margin of error. Most emulators have a palette that fits well within the margin of error seen on actual machines so yeah.
actually, using a palette is fail to begin with - at least VICE and micro64 have builtin color generation that accurately resembles how the colors are actually generated inside the VICII, and offer the respective controls monitors/tvs have to adjust them to whatever you like. also look here (somewhat outdated, need to update this...)
Quote:
Also, are C64s still being manufactured?
tada :=)
Quote:
Isn't it obvious that the answer is "no"? Would you want your comptetion to be able to rebuild all your hardware components?
What I mean is, wouldn't they be kept locked away in company vaults somewhere?
Quote:
Early GUS cards 'probably' had better quality output DACs than pre-AWE SBs ... but that's not saying much. :p The authors could have been concerned that 486-era PCs weren't powerful enough to play their big complicated XMs in software, but I'm guessing 99% is just platform-wankery (GUS IS BEST, HATERS GONNA HATE, WOOOOO.)
At one time, I was eager to demonstrate Elwood's Dead Lock XM file on a Pentium-level PC around late 1997 to a family member using Windows 95 and Mod4Win. If I recall, this was no GUS but a bog-standard SB card. The trouble was, the PC couldn't quite handle the demands of the XM and the main melody was extremely out of tune. My family member didn't think much of the music in the end, unfortunately.
Quote:
it wasnt ever ment for broadcast, so whether that works or not is irrelevant :)
It sounds like you're discussing de facto standard, not specified standard. PAL and NTSC are standards for broadcast, so instead of being irrelevant, they're in fact the ONLY relevant thing. Rec. ITU-R BT.470 says:
Quote:
Note 2 - At the beginning of each first field, the edge of the field-synchronizing pulse, OV, coincides with the edge of a line-sychronizing pulse if l is an odd number of half-line periods as shown.
Note 3 - At the beginning of each second field, the edge of the field-synchronizing pulse, OV, falls midway between the edges of two line-synchronizing pulses if l is an odd number of half-line periods as shown.
As you can see, it's not a myth that the progressive scan hack used by early consoles and home computers doesn't adhere to the specification. It simply worked because of the way most/all manufacturers of CRTs implemented the standard. As such it's not surprising that it doesn't work perfectly on modern TVs that adhere more strictly to the standard because they're designed in a completely different way.
The specs of analog display era were always a bit flexible. Nobody expected exact frequencies but rather a close range.