Clock Signal: a Vic-20 emulator for macOS and Linux

You need an actual VIC.

Moderator: Moderators

groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: A heavyweight Vic-20 emulator with twists

Post by groepaz »

Yes please! I love test suites.
ok - so look at this - the requirements are listed at the bottom of the file. let me know if something is not clear, this is all very much work in progress :)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

@Tom
it feels to me you're more creating a sort of CRT monitor emulator than a VIC-20 emulator.

At that point, when you start considering phosphor persistence & al, I guess you should choose whether you're emulating a Commodore 1702, A Sony trinitron TV studio monitor or a junk Magnavox TV set on channel 4.

Today, a 4k monitor is probably so finely accurate as to even reproduce the individual RGB cells of a CRT. They differ from brand to brand and tube size... just take a look at those on the SX-64 monitor...

Do you want to go that far?
Last edited by eslapion on Fri Jun 17, 2016 7:04 pm, edited 1 time in total.
Be normal.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: A heavyweight Vic-20 emulator with twists

Post by groepaz »

no need to consider TFTs - as they generally suck arse for vintage 8bit stuff =P
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

groepaz wrote:no need to consider TFTs - as they generally suck arse for vintage 8bit stuff =P
Is that in answer to me or an advice for Tom ?

Am I living through a weird anachronism?

Back in the 1982, everyone was whining about the VIC-20's poor video quality and excessive video noise. People tried all sorts of tricks to improve image quality.

Nowadays, the challenge appears to be replicating the garbage!!

I loved WinVICE 2.1 because when used with an ATI video card and Rage3D Tweak, you can activate the S-Video out at 848x480 and get that perfect VIC-20 display with zero noise you would have loved to have on a CRT display back in the days.

Later version of WinVICE force scaling and makes that impossible.
Be normal.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: A heavyweight Vic-20 emulator with twists

Post by groepaz »

you can always disable hardware scaling completely and get the terrible ultrasharp picture that you prefer apparently - however, most people dont :)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

groepaz wrote:you can always disable hardware scaling completely and get the terrible ultrasharp picture that you prefer apparently
Yeah but then you can't get it at the proper aspect ratio for a TV compatible resolution.
Be normal.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: A heavyweight Vic-20 emulator with twists

Post by groepaz »

perhaps - then again, that never was the case
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

groepaz wrote:perhaps - then again, that never was the case
WRONG!

XVIC of WinVICE 2.1 displays at EXACTLY the correct ratio when selecting 848x480.
Be normal.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: A heavyweight Vic-20 emulator with twists

Post by groepaz »

eslapion wrote: WRONG!
XVIC of WinVICE 2.1 displays at EXACTLY the correct ratio when selecting 848x480.
in PAL it shows 544x283 and in NTSC it shows 416x252 - none of which maps EXACTLY to 848x480. it's kindof close (for NTSC), but thats pure coincedence. and that wasnt changed until after 2.4 either (ok, it shows one rasterline more, but that shouldnt give a visual difference at all in fullscreen)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

@groepaz
I would have to capture the S-Video output to show you exactly but it requires an external TV capture device and that's cumbersome.

I have other priorities for now but I will get to it.
Be normal.
Tom
Vic 20 Amateur
Posts: 63
Joined: Mon Jun 06, 2016 9:07 am

Re: A heavyweight Vic-20 emulator with twists

Post by Tom »

eslapion wrote:@Tom
it feels to me you're more creating a sort of CRT monitor emulator than a VIC-20 emulator.

At that point, when you start considering phosphor persistence & al, I guess you should choose whether you're emulating a Commodore 1702, A Sony trinitron TV studio monitor or a junk Magnavox TV set on channel 4.
What I want is an emulator that is both indistinguishable from a real machine to software, and indistinguishable from a real machine to the user. I feel like the first is solved by VICE in a way I'll probably never match, so I'm emphasising the second in order potentially to be interesting when otherwise my little thing most definitely wouldn't be. But all of it is fun to me.

Though I am more drawn to the junk level of screen having grown up with the bog-standard no-brand high street 14".
eslapion wrote:Today, a 4k monitor is probably so finely accurate as to even reproduce the individual RGB cells of a CRT. They differ from brand to brand and tube size... just take a look at those on the SX-64 monitor...
Yes, definitely, and to their credit this is one of the few areas (the only area?) in which Apple has actually pushed the envelope in recent years. Never perpetually ahead, of course, but high-density computer displays such as those in most Macs now are at the sort of level where one stops having to think about integral multiples and the exactities of what goes where, and start just expressing the general rules of a CRT and leaving your computer to figure out the difference.
eslapion wrote:Do you want to go that far?
I think it'd make sense, I just feel like it's a long way ahead.
eslapion wrote:Am I living through a weird anachronism?

Back in the 1982, everyone was whining about the VIC-20's poor video quality and excessive video noise. People tried all sorts of tricks to improve image quality.

Nowadays, the challenge appears to be replicating the garbage!!
I just like authenticity by default. To capture and to preserve.

I'm not arguing back to basics and forcing everybody to sit through 20 minutes of a loading screen each time they fire up a game; I'm just arguing that an ideal emulator would support that first and foremost, and everything else is an optional bell and whistle.
groepaz wrote:
Yes please! I love test suites.
ok - so look at this - the requirements are listed at the bottom of the file. let me know if something is not clear, this is all very much work in progress :)
A million times thank you. It's going to take me quite a while to look at because my emulator cannot currently be launched from the command line. It has no concept of that whatsoever. But that's my problem now, isn't it?

(obiter, as to the emulator: 6522 unit tests have helped me 'perfect' the timer emulation (i.e. confirm that the implementation meets my current best understanding), which fixes a couple of things, and I've implemented loading of PRGs-that-go-in-RAM by deferring their installation until after the machine has booted and then issuing a 'RUN'. I guess I may need to do something smarter to determine whether RUN is more appropriate than a SYS call at some point but that's it for now. Having given the machine the ability to type things for itself anyway, I threw in pasting from the clipboard, which destroys the fun of type-ins. I otherwise drifted off into improvements for one of the other emulated machines.)
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

@Tom
If that is so then I think what you should do is a plug-in to XVIC rather than create an all-new emulator.

A strictly video plug-in which takes-in the video output and filters it to simulate the 6560's video anomalies + possibly CRT imperfections.

That would yield the desired results with much less work.
Be normal.
Tom
Vic 20 Amateur
Posts: 63
Joined: Mon Jun 06, 2016 9:07 am

Re: A heavyweight Vic-20 emulator with twists

Post by Tom »

eslapion wrote:@Tom
If that is so then I think what you should do is a plug-in to XVIC rather than create an all-new emulator.
I think that what I want from an emulator and what XVic supplies are somewhat divergent. I don't think negatively is warranted because it's an excellent piece of software and the work of a whole bunch of skilled and dedicated people, but I have different goals.
eslapion wrote:A strictly video plug-in which takes-in the video output and filters it to simulate the 6560's video anomalies + possibly CRT imperfections.

That would yield the desired results with much less work.
What I have written is not a filter. It's an emulation of a TV set. As in, it is authentic to the actual signal-level means by which real machines really communicate with a real analogue screen.

EDIT: an example of the difference: the rules applied are that the logical leading edge of the sync level triggers horizontal sync. While sync is active a quantity accumulates. If sync was active for long enough (a continuous period not being required because, you know, equalisation pulses) that triggers a vertical sync. When data is output for a certain period it is output along the line then traced by the ray. An attempt is made at phosphor decay. All of this happens at whatever the pixel resolution is of your screen or window.

One corollary? Interlaced video works. Not because my emulator has some special signal that doesn't exist on the real hardware to tell some special post filter, but for the same reason it works on a real TV: that by triggering vertical retrace on the half line, and because scans are diagonal, the centres of the one field of scans lie upon the edges of the other.

(additional comments: I already have a battle tested, good-form 6502 emulation, so that's pretty much zero cost. But it's 1,209 lines for the record. The 6522 I want so that I can also attempt a panoply of other machines so is not directly a Vic-20 cost but, incomplete, is currently 303 lines. The 6560 is Vic specific in effect and also unfinished but 'complete' and 454 lines. The remainder of the stuff that joins the dots is 250 lines. Fixes to the 6560 shouldn't cost many extra lines but additions to the 6522 probably will so the number definitely isn't final but that means that so far I'm spending only 2,216 lines on Vic emulation, 1,209 of which are already reused by other parts of the program and predate my Vic effort, and a further 303 of which will be reused. So writing one's own is not a huge amount of work. But it is a huge amount of fun.)
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: A heavyweight Vic-20 emulator with twists

Post by groepaz »

One corollary? Interlaced video works.
... and *everything else* - which is why emulating things as they actually happen is the way to go for a "modern" emulator. some things just cant be done by post processing as in VICE.
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
Tom
Vic 20 Amateur
Posts: 63
Joined: Mon Jun 06, 2016 9:07 am

Re: A heavyweight Vic-20 emulator with twists

Post by Tom »

Returning selfishly to just the emulator itself, this weekend I added support for .TAP* which buys me a large amount of new testing material as long as I'm patient. I need to download one of the ROM disassemblies and properly digest it, I think, in order to find the best way to offer turbo-speed loading. On one of the other emulated machines that was as simple as locating the subroutine that recognises a single byte from the tape and writing a time-warping emulator-side implementation of that, triggered by a PC trap. All optional, obviously. A better understanding of how the ROM encodes data on a tape would also allow me to work with .T64 files; .CSW looks like it might also be worth grabbing.

The 6560 is improved to the point that all I'm missing is two additional cycles of delay on output pixels. With a net effect that palette changes take effect a little early.

I finally twigged on the partial decoding of the bus that would in theory allow one to write to or read from both the VIC and a VIA simultaneously. I also found an askew reference to the user-port VIA being wired to NMI so split the two accordingly. They were previously both wired to IRQ, as logical ORs.

Of the titles I'm currently scoring myself against: Dragonfire now looks correct; Demon Attack and the PWP Warning demo are still both inexplicably missing most of their graphics — in both cases there are framing graphics and evidence of ongoing execution (though only audio in Demon Attack's case) but the main animated visual stuff is completely absent. So probably something like a 6522 error, failing to generate some interrupt or another. Hopefully I'll figure it out.

(* since I found the documentation somewhat vague and implicit, for input it's just: a 1-bit ADC, wired up to CA1 on the keyboard VIA, plus a tape sense line that goes to bit 6 of port A on the user-port VIA. Tape sense is low if a tape is inserted and the user has pressed play, high otherwise. CA2 on the user-port VIA will also give a motor control output for the tape. It looks like PB3 on the keyboard VIA would act as the reverse of the 1-bit DAC if you were writing. The ROM sets one of the VIA timers up to generate an interrupt and enables interrupts on CA1; if the CA1 interrupt occurs sooner than the timer then this is a short pulse, if it occurs later then it's a long. And hence are bits encoded.

... which makes me wonder why a specialised accessory was felt necessary, as most other computers seem fine performing the equivalent of tape sense by just waiting for lead-in tone. But perhaps 'necessary' was more about economics? The external tape player I had in the '80s had a motor control input amongst its set.)
Post Reply