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 »

the c2n was just a cashing-in ... any other tape recorder with motor control works fine (adapters existed)

i wouldnt bother with writing a high level kernal-trap handler for tape... you'd still need the "proper" emulation path for games/whatever that uses a turbotape/fastloader. and the stuff that works with kernal will for the most part work as simple .prg files anyway.
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 »

groepaz wrote:i wouldnt bother with writing a high level kernal-trap handler for tape... you'd still need the "proper" emulation path for games/whatever that uses a turbotape/fastloader. and the stuff that works with kernal will for the most part work as simple .prg files anyway.
There's no question of the proper emulation path ever going away, it'd just be nice if those things which do use the ROM could be speedily loaded, even if it's no more complicated than spotting entry into the LOAD command, determining the parameters, doing a quick host-side parsing of pulses and installation of the next matching PRG file, leaving the tape appropriately located and forcing an RTS. Which at least means figuring out the on-tape format. But I have to do that anyway if I want T64 files to work.

Though I think I understand that a PRG file on tape is still just a PRG file — two bytes of load address, which the LOAD command may or may not have told you to honour, then the data, which on a tape is long and short pulses as measured between downward zero crossings. There also appears to be some lead-in. And all data is stored twice. I'm sure that, even if I can't find explicit documentation, I can figure out whether there's parity, start and/or stop bits, whether a short pulse is a one or a zero, etc, probably very trivially.

I'm aware I could also use the combination of motor control, tape position, CA1 interrupt bit to trigger a no-holds-barred period of execution at maximum emulable speed. Which is a neater and more compact solution, but probably not so speedy. At least if you've otherwise as little regard to date for optimisation as I seem to. So I may just be talking about the wrong remedy to a problem of my own creation.

... and I'm also aware that using an emulator to load from tape seems to be an unpopular option, but if I'm going to support it then I might as well do the best version I can.
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 »

T64 are just simple container files, they are not related to "tape format" in any way :)

and sure, prg files on tape are just that... you can relatively easy decode the .tap into raw binaries (there are a couple of tools that do it already, some also came with source so you can look at it)
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 »

groepaz wrote:T64 are just simple container files, they are not related to "tape format" in any way :)
Yeah, it also looks like it's not seriously used, even restricting myself to Vic tape images. So maybe I'll ignore it. But then again it might be more appropriate to feed RAM-targeting PRG files to the emulated machines as though on tape so that I'm not concerning myself with the vagaries of squirting things into RAM, in which case it's negligibly more work to support T64.

EDIT: and it has struck me very shortly after posting, that if I want a turbo load mode for the ROM then all I probably need to do is find either the spot at which the CPU is set up to load and is waiting for a VIA interrupt, then run just the VIA and tape until either interrupt signal occurs, then switch back to emulating the whole machine. So no need for anything like byte decoding, just an ability accurately to spot the initial state and then to fast forward time for only a subset of components.

EDIT2: implemented as stated, in about five lines of code, more or less:

Code: Select all

if(should use fast loading hack && 6502 sync line is active && bus address is $f92f)
{
	while(!userPortVIA.get_interrupt_line() && !keyboardVIA.get_interrupt_line())
	{
		run VIAs and tape for one cycle
	}
}
That f92f appeared to be consistent across NTSC and PAL versions of the ROM, and those listed as being from the Danish, Swedish and Japanese machines.

The net effect is noticeably faster, although still not exactly speedy. But it currently feels like a nice place to be on effort versus reward.

I also realised that my NMIs weren't actually firing, being an omission from my 6502 core that was awaiting test material. So all the Imagic titles work now. Though I still need to implement NMI subversion of BRK.

EDIT3: I guess I'll throw up a new binary when I'm back at my development machine; primary changes have been to introduce some unit tests on the 6502 interrupt behaviour — none of the standard test suites manage it for completely understandable reasons — and thereby to discover that I was inadvertently dropping two cycles on the cost of entering an interrupt. Whoops! I also diagnosed the dark-area bug but then made only the most temporary fix by bumping up the size of a buffer, and in profiling discovered that my particular OpenGL driver has the very nasty habit of performing a busy loop if I wait on a fence sync. Adjusting my logic to avoid that brings overall processing cost down to "only" about 2.5–3.0 times as much as Vice. You know, bearing in mind that I've been very much doing the semantically easiest thing, not the fastest thing. I think I can eke more out without having to jump through any loops. Honestly, if mine were 50% as fast as Vice I'd be happy. I'm probably even happy with 33% but I might as well try.
Attachments
Clock Signal.zip
(1.81 MiB) Downloaded 233 times
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 »

Well, I've thrown caution to the wind and started on a serial bus and 1540 emulation despite not yet even having a PAL mode or support for more than the base RAM configuration. It's not doing much so far. The Vic asserts the attention line and pumps out a single bit, then there's no further activity. Issuing a LOAD"",8,1 results in no further bus activity but no error message (which is distinct from if I don't attempt to emulate the bus at all, in which case I get the expected error, but still clearly incorrect).

My 6522 emulation is at fault, almost certainly. I think the machine is supposed to pump out a whole byte at a time, including at boot after asserting attention? I've considered that it might be a race condition because my 1540 powers on at exactly the same time as my Vic and obviously there's no access control on the bus lines but decided the 6522 angle is more likely. I guess I need to have a quick look at the Vic ROM and figure out what it's expecting, write an appropriate unit test and debug.

Despite the knowledge clearly being out there, documentation seems to be slender and occasionally incorrect so I'll endeavour to contribute to that once I have the ability.

(sample piece of misleading documentation: http://ist.uwaterloo.ca/~schepers/MJK/ascii/1541map.txt asserts that the attention input is wired to CB2; I don't know why I didn't think to get that information first from the official schematic but it isn't — it's wired to CA1, which gels with http://sta.c64.org/cbm1541mem.html's belief that reading from port A acknowledges the relevant interrupt, at least)

Update on this: it was a surprising result that caused quite a while of head scratching that most of the serial bus connections are inverted but the Vic-side inputs aren't (though the outputs are). At least, that's what the ROM disassembly appears to imply and that appears to cause my emulated 1540 to spin up, then eventually signal an error when sync never happens. Being a tedious person about perceived accuracy, next step is to try to model an appropriate PLL for data from the disk. You can definitely ignore the issue if supporting only D64 but I think not for G64 — it'd be hard to model a mid-window weak bit in that format but you probably could with the speed zones, and it's trivial to model a long period without transitions that should cause at least synchronisation loss.
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 »

A holiday interceded but attached is a new version of the emulator; added is a read-only implementation of the 1540, with support for G64 and D64 file formats.

I guess now I should think about supporting PAL mode and expanded systems.

The emulator remains heavyweight in the intended derogatory sense of the word: without a 1540 the processing burden weighs in at about 27% of a core, with a 1540 attached it's more like 30% while the disk is static and 40%-or-so while it is spinning. So there's work to do there, too.
Attachments
Clock Signal 02-08-16.zip
(1.84 MiB) Downloaded 237 times
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: A heavyweight Vic-20 emulator with twists

Post by Mike »

I found this update only as you wrote your last post:
Tom wrote:Update on this: it was a surprising result that caused quite a while of head scratching that most of the serial bus connections are inverted but the Vic-side inputs aren't (though the outputs are). At least, that's what the ROM disassembly appears to imply [...]
Spot on! A sharp peek into the schematics confirms this. :)

Actually, this causes a lot of confusion in many disassemblies for both computer (VIC-20, C64, etc.) and drives. Unless they strictly differentiate between intended 'logic' levels and the actual electrical logic levels on the bus, they meander around and then make up their own stories, as described aptly in "Data Becker, Das große Floppybuch zur C1570/71", to quote from there (pp. 181-183):
Dabei fällt auf, daß für ein und dieselbe Busleitung zwei verschiedene Bits des Ein-/Ausgabeports verwendet werden. Das eine Bit dient zur Ausgabe der Daten und das andere Bit ist als Eingang geschaltet. Um zu verstehen, was hinter dieser merkwürdigen Belegung steckt, müssen Sie den Schaltplan der Buslogik zu Rate ziehen.

Wie Sie sehen, werden die beiden Anschlü[ss]e des Ein-/Ausgabe-Bausteins über zwei Inverter mit der Busleitung verbunden. Der Inverter gibt immer genau den entgegengesetzten Pegel aus, wie am Eingang des Inverters anliegt. Auf diese Weise haben Pegel auf den Leitungen des seriellen Busses immer den entgegengesetzten Wert wie das Bit im Ein-/Ausgabe-Register.

Der Grund dafür ist elektrotechnischer Natur. Es ist nämlich nicht möglich, auf eine Leitung den 0-Pegel zu setzen und dann die Leitung durch einen anderen Ausgang, beispielsweise am Peripheriegerät, mit dem Wert 1 anzusteuern. Die Leitung würde nie den Zustand 1 annehmen, da der Null-Pegel wie ein Kurzschluß wirkt.

Also muß die ganze Handhabung der Signale invertiert werden. [...]

Im Grunde genommen ist diese spezielle Hardware-Organisation für die Programmierung nicht interessant, da die Elektronik durch die Inverter immer wieder die richtigen logischen Werte herstellt. Doch es ist gibt leider eine Ausnahme. Dies ist der Eingang am Rechner, [dem VC-20,] dem C64 oder dem C128. Dieser Eingang hat keinen Inverter vorgeschaltet.

Der Sachverhalt, daß die physikalischen Pegel im Gegensatz zu den logischen Werten invertiert sind, führt besonders in ROM-Listings immer wieder zu Verwirrungen. [...] Dies führt dann zu einem munteren Kommentar-Wirrwarr, das mit den eigentlichen Vorgängen am seriellen Bus nichts mehr zu tun hat.
translated:

It is apparent, that the bus lines each use two different bits on the I/O-ports. One bit is used for output, the other one for input. You need to take a look into the schematics to understand why this is done:

As you see, the two pins of the I/O chip are connected to the bus line over two inverters. The inverter inverts the logic level. That means, the levels on the serial bus are inverted relative to the I/O ports.

The reasons for this comes from electrical engineering: it is not possible to set a line to low level, and then (try to) control the line with another output (for example, of a peripheral device) to achieve a high level. The signal line would never assume high level, because the null/low level acts as short circuit.

That means it's sensible to invert all signals [...]

All in all this arrangement of hardware wouldn't be of major interest with regard to programming, as the electronics restores the correct logic levels with the inverters - with one exception: the inputs at the computer, i.e. VIC-20 [...] have no preceding inverter.

The fact, that the physical levels are inverted compared with the logic levels frequently leads to confusion in ROM listings [...] This results in a cheerful tangle in the comments, which however has no relation anymore to what happens on the serial bus.


...


The engineers at Commodore just wanted to save a few cents by leaving out those inverters. :lol:
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 »

Apologies for the conversation break; I've been working on PAL, memory expansion support and PRG->tape conversion, hoping to get to PRG Starter-type logic being all that's left. Attached is a PAL shot. I've yet to implement any of the findings of the recent thread on this so fetch-time noise is missing and the various intensities are probably off but just implementing phase inversion every line but not every frame seems to give a fairly convincing effect. So I thought I'd post.

Immediate mystery is why my PRGs as tapes (i.e. those not thought to be ROMs) are failing to load. It'll be something stupid like putting in the wrong amount of gap though, so quite possibly I'll chance upon the correct thing almost immediately. We'll see.
Screen Shot 2016-08-17 at 08.09.12.png
matsondawson
The Most Noble Order of Denial
Posts: 343
Joined: Fri May 01, 2009 4:44 pm

Re: A heavyweight Vic-20 emulator with twists

Post by matsondawson »

If you can read my code it may help. I read CSM and TAP file format and covert to pulse widths.
http://www.mdawson.net/vic20chrome/vic20/tapedrive.js
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 »

matsondawson wrote:If you can read my code it may help. I read CSM and TAP file format and covert to pulse widths.
http://www.mdawson.net/vic20chrome/vic20/tapedrive.js
Yep, that really helped, thanks! Most notable amongst my errors:
  • outputting as header, data, repeat header, repeat data rather than header, repeat header, data, repeat data; and
  • segmenting data into separate 192-byte chunks, having completely misunderstood what the tape buffer is for.
Having fixed those, I was able to load Pooyan, amongst others, and having loaded Pooyan I discovered that my audio code was incorrect for everything except the highest-frequency channel. I then also spotted that there's a 1.6Khz lowpass filter on the audio after it exits the Vic chip, so implemented that. Which is making me wonder whether I could significantly reduce the rate at which I output audio but I'll worry about that later.

So next job is a static analyser, capable of being handed a disk or a tape and saying "this looks like it's for the Vic-20, probably an unexpanded machine, most likely load command is LOAD"",1,1" — PRG Starter-type stuff, though with a different platform set. Then if I've gone ahead and written a consuming parser for disks and tapes, I can probably do a bit more to accelerate loading of the latter.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: A heavyweight Vic-20 emulator with twists

Post by lance.ewing »

Tom, any chance you might convert your emulator to Android? I plan to release my emulator on the Google Play store by the end of the year. I'm going to attempt to encourage other emulator writers to do the same.
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 »

It looks like I stopped posting on this prematurely. The thing has actually been under continuous development in the 18 months I've been absent, but a lot of that work has been on emulating things that aren't the Vic-20. I actually let the Vic-20 go slightly to pasture, so shame on me. I mean, I kept updating it the whole time and ensuring it fits properly within the whole emulator's framework but wasn't testing it very thoroughly. I'm working on it again now, but changes in the interim are:
  • something intending to be equivalent to PRG starter was added, then over-complicated, and now I'm stripping it back. Either way, machine configuration is something the emulator attempts to do for you;
  • proper fast loading from tapes was implemented, which often works;
  • an SDL-based 'kiosk mode' was added. Which is in effect a Linux port; and
  • file-format support grew: if you ever wanted to use HFE disk images or CSW tapes then your wish is granted.
I'm working on the Vic again now, mostly grinding through titles to test, correct and if necessary expand the automatic analysis, and similarly the logic begin the fast tape loading, so wouldn't necessarily recommend a fresh download immediately. But, you know, putting my head back up, this is still ongoing.

Issues with the current build when using the Vic are: the macOS version shows the wrong options; a mistake in fast tape loading can cause a crash for tapes the emulator doesn't recognise properly; the PAL colour choices are probably inaccurate. Nevertheless it's here for the suitably curious, as will be all future releases.

Re: colours, I'm still doing the full composite encode/decode and the internal format for colours is amplitude + phase, since that's how the real VIC does it. But it means not being able to find a definitive statement of correct numbers.

I have the immediate-term plan to polish the machines I have a little further, then I've a via-iOS transition plan hopefully towards reaching a potential Android port. I don't think an iOS version could ever be released but it's a convenient intermediate step because this is still a no-framebuffer straight-to-scans OpenGL outputting emulator, and OpenGL is slightly different on mobile.

EDIT: actually, follow-up on this. Does anybody know whether the TED seeks to use the same palette for the first eight colours? I found formal documentation of its chrominance phases in the 264 hardware specifications and they're remarkably close to the values that I had determined by eyeball — I'm a median of only about 2% off. I guess I'll try chucking those numbers in when I get home, grab some screenshots and see what it looks like.

EDIT2: as per attachments, the TED numbers look correct to me — that's using the angle specified in the 264 specifications as the phase to generate a sine wave as the chrominance part of the video signal, then applying standard decoding maths to that. So I'll stick with them. Luminances remain my best guesses, and the connection is composite only so PAL is the one with the serrated vertical edges.
Attachments
PAL.png
NTSC.png
Tom
Vic 20 Amateur
Posts: 63
Joined: Mon Jun 06, 2016 9:07 am

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

Post by Tom »

Quick minor post: an updated version is available with fixes to the VIC colour palette as above, to the 1.6Khz low-pass audio filter (it was, unwittingly, ineffective), and other minor optimisations.

Most obviously, the emulator now attempts to support S-Video output. So you're no longer stuck with composite-quality video.

Downloads.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

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

Post by Mike »

You should check the timing of the NTSC (and possibly also the PAL) version.

In the first screenshot, the splits of the background register happen at the wrong place (after the first text column), whereas they're supposed to happen just after HSync, at the beginning of the raster. With non-interlaced modes on NTSC, the change of the raster register ($9004) actually happens in the middle(!) of the raster line, not at the start, this is being taken care of by my routines.

The splits also do not honor, that changes of the colour registers on real h/w take effect one hires pixel late w.r.t. half char boundaries.
Tom
Vic 20 Amateur
Posts: 63
Joined: Mon Jun 06, 2016 9:07 am

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

Post by Tom »

Mike wrote:You should check the timing of the NTSC (and possibly also the PAL) version.

In the first screenshot, the splits of the background register happen at the wrong place (after the first text column), whereas they're supposed to happen just after HSync, at the beginning of the raster. With non-interlaced modes on NTSC, the change of the raster register ($9004) actually happens in the middle(!) of the raster line, not at the start, this is being taken care of by my routines.

The splits also do not honor, that changes of the colour registers on real h/w take effect one hires pixel late w.r.t. half char boundaries.
Thanks for the feedback! Whatever the problem turns out to be, I'm sure I can fix it.

The first screenshot is NTSC, the second is PAL; I'm taking it as implicit that you don't see any problems with the PAL?

Although a timing issue is far and away most likely — I similarly see changes just before the visible area in the NTSC version of Atlantis — by what mechanism are you detecting NTSC versus PAL? Just to rule that probably trivial thing. Otherwise an improperly-timed raster change is most likely, despite there being a specific attempt to do that correctly in there.
Post Reply