Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II » A new emulator
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
A new emulator [message #367793] Wed, 16 May 2018 09:15 Go to next message
Anonymous
Karma:
Originally posted by: Thomas Harte

I refrain yet to call it "a good emulator" but I've been writing a new II/+ emulator and it's reached the stage where it arguably isn't "a terrible emulator". Skip to the final paragraph for a link.

It's a cycle-exact execution model, in which the 6502 performs each memory access one-by-one, video is scanned accordingly, and if you've got a magical golden ear then you might even be able to pick up the stretched cycles in the audio output (I doubt it, but they are there). The Disk II is emulated by running through its state machine ROM while tracking a spinning platter, so be warned that loading is entirely in real time. The video is run through an NTSC decoder that has no Apple-specific knowledge whatsoever.

It comes in two flavours: the Mac version is a fully-native Cocoa application. Launch arbitrarily many Apple IIs, in arbitrarily many windows, size them however you want, put them into tabs, however you like to do it. There's also an SDL version which works under most UNIXes that operates more as a kiosk, taking a file to launch as a parameter and then operating a single window. The intention is that you connect it up as the handler for appropriate file types in your preferred file manager, then just double-click a DSK to play.

There's support for WOZ, DSK and an attempt at NIBs, even though they're terrible.

A whole bunch of things work really well, and others just seemingly never load. So it's early days. I most definitely need to add a drive activity indicator.

Also my CRT is unrealistic in one obvious sense: it responds to the presence or absence of a colour burst directly on the affected line, allowing any mix of lines across the screen. So you'll get really clear text in mixed mode.

Eventual IIe support is not improbable, but I really want to figure out what's going on with the problem titles on the II+ first. I'm 80% confident that I don't just lack patience. I was giving serious consideration to offering the fictional emulator convenience of capturing calls to RWTS and performing them in effectively zero time, but I'm on the fence about that.

Support for tapes will also come.

Mac binaries and demarcated release source bundles are at https://github.com/tomharte/clk/releases but as the URL suggests, the whole thing is being developed entirely in the open so if you're building at home then you can grab it whenever.
Re: A new emulator [message #367807 is a reply to message #367793] Wed, 16 May 2018 09:45 Go to previous messageGo to next message
zellyn is currently offline  zellyn
Messages: 173
Registered: April 2013
Karma: 0
Senior Member
On Wednesday, May 16, 2018 at 9:15:54 AM UTC-4, Thomas Harte wrote:
> I refrain yet to call it "a good emulator" but I've been writing a new II/+ emulator and it's reached the stage where it arguably isn't "a terrible emulator". Skip to the final paragraph for a link.

Wow. Very cool. It's not every day that a brand new emulator shows up, and with a real NTSC decoder, no less!! (I'm more interested than usual in NTSC emulation, since I just finished porting OpenEmulator's NTSC decoder to webgl last night! https://zellyn.github.io/apple2shader/)

Looking forward to where this goes. btw, if you already have real NTSC, the IIe's double-hires modes aren't very hard: you just shift things left 7 half-pixels. You might find my a2audit routines useful for that: https://github.com/zellyn/a2audit/

And it also does a whole bunch of other computer emulations. Amazing!

Zellyn
Re: A new emulator [message #367808 is a reply to message #367807] Wed, 16 May 2018 10:03 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Harte

> Wow. Very cool. It's not every day that a brand new emulator shows up, and with a real NTSC decoder, no less!! (I'm more interested than usual in NTSC emulation, since I just finished porting OpenEmulator's NTSC decoder to webgl last night! https://zellyn.github.io/apple2shader/)

It's technically on something like its third. Right now luma/chroma separation is (essentially) a comb, with the input signal scaled and position to be an integral division of in-phase — four samples per colour cycle because the CCIR standards seemed to recommend that for digital preservation of real analogue material so I figured it must therefore be good enough for an emulator; most previously it had been a standard FIR with no colour-cycle bucketing but that just meant the GPU having to sample quite a lot more data.

> Looking forward to where this goes. btw, if you already have real NTSC, the IIe's double-hires modes aren't very hard: you just shift things left 7 half-pixels. You might find my a2audit routines useful for that: https://github.com/zellyn/a2audit/

I had that in mind when writing the little class that produces Apple video. Given that the colour decoding is entirely separate, it just sends a double-high-res fidelity bit stream over to the GPU. For ordinary high-resolution graphics it doubles the pixels up and maintains an inter-byte carry to deal with the potentially 90-degree offset that may or may not flow onward. Low-res mode just dumps its bit pattern directly, text mode reverses the content of the ROM and doubles it up. Double high-res would just have to load its values directly, I hope.

I used A2audit to test my language card! Suffice to say, it was initially wrong but probably isn't now (other than that it doesn't impose the autostart ROM onto an original Apple II).
Re: A new emulator [message #367812 is a reply to message #367807] Wed, 16 May 2018 12:00 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
Congrats Thomas, that is cool!
Thank you,
antoine
Re: A new emulator [message #368150 is a reply to message #367812] Thu, 24 May 2018 22:21 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Harte

On Wednesday, 16 May 2018 12:00:30 UTC-4, Antoine Vignau wrote:
> Congrats Thomas, that is cool!
> Thank you,
> antoine

A minor update is now available in which DSK and WOZ files are writeable. There's presently a performance penalty whenever the disk is in use, whether to read or write, but that's intended to be temporary. I just need to do a little more work.

As before, downloads are at https://github.com/TomHarte/CLK/releases
Re: A new emulator [message #368199 is a reply to message #368150] Sun, 27 May 2018 12:25 Go to previous messageGo to next message
cybernesto is currently offline  cybernesto
Messages: 78
Registered: June 2013
Karma: 0
Member
Hi Tom, I downloaded the 2018-05-24 release from GitHub and I'm using it under Mac OS 10.11.6. The display does not really show very accurate colors. I tried it in full screen and windowed mode with the same issue. OpenEmulator shows color fringes just as my real Apple II does, but CLK just shows very blocky off-colored pixels. Is this a known issue? Would a screenshot help you figure out what is going on?
Re: A new emulator [message #368222 is a reply to message #368199] Mon, 28 May 2018 12:08 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Harte

On Sunday, 27 May 2018 12:25:44 UTC-4, cybernesto wrote:
> Hi Tom, I downloaded the 2018-05-24 release from GitHub and I'm using it under Mac OS 10.11.6. The display does not really show very accurate colors.. I tried it in full screen and windowed mode with the same issue. OpenEmulator shows color fringes just as my real Apple II does, but CLK just shows very blocky off-colored pixels. Is this a known issue? Would a screenshot help you figure out what is going on?

Yes please. Relevant observations:

I'm using a comb filter*, which works quite differently than the one employed by OpenEmulator so you'd expect a difference in output. The NTSC standard is about mandating signal content, so that's not inaccurate. But blocky off-coloured pixels are.

So a screenshot will help me to distinguish between implementation error (i..e. yours looks different from mine) and inappropriate algorithm selection (i.e. they look the same, and I'm failing at objectivity and/or recollection).

I actually switched only a year ago or so. The idea was to reduce GPU memory bandwidth requirements. Switching back wouldn't necessarily be problematic; I'm not sure the change has been entirely positive anyway because it introduces issues with the means of interpolation.

I've not yet captured the Apple II but here are videos of a couple of other in-phase NTSC machines, in case it helps to confirm/deny that my machine acts like yours: https://www.youtube.com/watch?v=zq4Z_XSMfUw (the MSX); and https://www.youtube.com/watch?v=BLFcb1dJpLU (the ColecoVision). Both the same video chip, but I thought two examples might be more helpful than one.

So potential outcomes: (i) it's currently meant to look like that, I'll fix it; (ii) it's not meant to look like that, I'll fix it.
Re: A new emulator [message #368226 is a reply to message #368222] Mon, 28 May 2018 15:10 Go to previous messageGo to next message
cybernesto is currently offline  cybernesto
Messages: 78
Registered: June 2013
Karma: 0
Member
Thanks for looking into this. I created an issue on GitHub with a screenshot of both emulators side by side. We can continue the discussion over there if you like. I hope we can figure it out. CLK is a really good candidate to become my main emulator.
Re: A new emulator [message #368228 is a reply to message #368226] Mon, 28 May 2018 16:35 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Harte

On Monday, 28 May 2018 15:10:07 UTC-4, cybernesto wrote:
> Thanks for looking into this. I created an issue on GitHub with a screenshot of both emulators side by side. We can continue the discussion over there if you like. I hope we can figure it out. CLK is a really good candidate to become my main emulator.

Definitely, fantastic, thanks! I think it should be an 'easy' fix either way, and I should probably just stomach the extra GPU work. The more OpenEmulator-esque fragment shader survives in the code anyway for RGB output** so all I should need to do is undo some work that maps an input signal to an NTSC[/PAL]-relative clock then use a different intermediate stage. Umm, hopefully.

* having missed the asterisk from the first message: a filter like that in OpenEmulator samples a whole bunch of source pixels around the output and computes a weighted average of them. The weights have been selected by one of various ways of performing a finite transform from the frequency domain to the time domain and the net effect is [usually] intended to be a low-pass filtering of the input, to eliminate all the frequencies introduced by the colour subcarrier. Then you can separate the colour subcarrier by simple subtraction.

A comb filter starts with the assumption that you've got a luminance signal and a colour subcarrier at exactly n Mhz. Pretending that the colour subcarrier is a perfect sine wave and that luminance changes very slowly then because sin(a) = -sin(a+180) you can get the real luminance at any sample by just averaging it with the sample 180 degrees ago. That's like ((l + sin(a)) + (l + sin(a - 180)))/2 = 2l/2 = l.

But in my case I think the discrete realities of the way I'm sampling might be producing big solid artefacts. Which I could probably resolve on its own, but I'm turning off the idea because other machine map poorly to in-phase adjustment in pure bucketing terms.

** not relevant to the Apple II because I don't support any RGB cards, or the IIGS but even RGB monitors have a maximum bandwidth, so I low-pass filter even RGB signals. It's actually also a function of your computer's output size, to try to reduce aliasing, in one direction at least.

But, anyway, that means the more generic low-pass shader is right there.
Re: A new emulator [message #368239 is a reply to message #368228] Tue, 29 May 2018 09:50 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Harte

On Monday, 28 May 2018 16:35:05 UTC-4, Thomas Harte wrote:
> On Monday, 28 May 2018 15:10:07 UTC-4, cybernesto wrote:
>> Thanks for looking into this. I created an issue on GitHub with a screenshot of both emulators side by side. We can continue the discussion over there if you like. I hope we can figure it out. CLK is a really good candidate to become my main emulator.
>
> Definitely, fantastic, thanks! I think it should be an 'easy' fix either way, and I should probably just stomach the extra GPU work. ...

As it cuts to the desirability of the emulator, be warned: the bug report has shown (i) that I've been far too optimistic about precision on the GPU; and (ii) I've made an error somewhere in trying to tabularise my handling of high-resolution graphics, causing purple and green to be swapped. Specifically, I suspect the whole thing is 180 degrees out of phase and I'm treating the half-pixel delay/90-degree shift as shifting in the wrong direction.

I'll get it fixed for the next release. At least until then, my emulator is probably not a desirable choice.
Re: A new emulator [message #368508 is a reply to message #368239] Sun, 03 June 2018 08:26 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Harte

On Tuesday, 29 May 2018 09:50:18 UTC-4, Thomas Harte wrote:
> I'll get it fixed for the next release. At least until then, my emulator is probably not a desirable choice.

Update on this: all colouring issues are now believed fixed, and a new release has been made. https://github.com/TomHarte/CLK/releases as usual.

My guess as to the cause was incorrect, for the record. It turned out that my code, which treats NTSC as a subset of PAL, was inadvertently treating NTSC lines as if they were the alternate lines. So in terms of decoding YIQ, they were obtaining -Q. That with the Apple II's in-phase clock explains why two colours were swapped but two were correct.

The precision issue was real, alas. The easy fix was just to submit one byte per pixel to the GPU rather than the two bytes per seven pixels that I was sending. So there's a bit of a cost there, but in order to guarantee the correct result rather than potentially get an incorrect one. So worth it.
Re: A new emulator [message #368527 is a reply to message #368508] Sun, 03 June 2018 11:53 Go to previous messageGo to next message
zellyn is currently offline  zellyn
Messages: 173
Registered: April 2013
Karma: 0
Senior Member
On Sunday, June 3, 2018 at 8:26:10 AM UTC-4, Thomas Harte wrote:
> That with the Apple II's in-phase clock explains why two colours were swapped but two were correct.

Would a2audit have helped you catch this if you were paying attention to the words between colored screens, or did I miss the colors that would have shown the problem for you?

I think I need to add generalized GR/HGR/DHGR test images to a2audit, and have it print out links to see the equivalent online images: that would be good for quickly diagnosing color issues.

Zellyn
Re: A new emulator [message #368540 is a reply to message #368527] Sun, 03 June 2018 13:40 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Harte

On Sunday, 3 June 2018 11:53:12 UTC-4, Zellyn wrote:
> On Sunday, June 3, 2018 at 8:26:10 AM UTC-4, Thomas Harte wrote:
>> That with the Apple II's in-phase clock explains why two colours were swapped but two were correct.
>
> Would a2audit have helped you catch this if you were paying attention to the words between colored screens, or did I miss the colors that would have shown the problem for you?

Unambiguously, yes. The whole episode speaks very poorly of me and the quality of software I hope to achieve. I'm very embarrassed.

But to reiterate, because my confidence is shaken: it's a cycle-level emulation, including of the Disk II directly via its original state machine P6 ROM, with an NTSC decoder that is blind as to the machine feeding it. So although it's very fresh software, so likely plenty more issues will occur, the foundations are solid enough that diagnosing should be a lot more difficult than solving.
Re: A new emulator [message #368544 is a reply to message #368540] Sun, 03 June 2018 14:41 Go to previous messageGo to next message
zellyn is currently offline  zellyn
Messages: 173
Registered: April 2013
Karma: 0
Senior Member
On Sunday, June 3, 2018 at 1:40:46 PM UTC-4, Thomas Harte wrote:
\> Unambiguously, yes. The whole episode speaks very poorly of me and the quality of software I hope to achieve. I'm very embarrassed.

Oh no worries. This is a hobby for (almost?) all of us :-)

I did try booting up the latest Clock Signal against JKM's Dos 3.3 Master .woz file: it seemed to boot more or less correctly (although very slowly). But when I tried PR#6 to reboot, it did nothing or considered it a syntax error (depending on whether I held the shift key while typing: the characters on the screen were always uppercase). Does Clock Signal put the drive controller somewhere other than slot 6?

Zellyn
Re: A new emulator [message #368554 is a reply to message #368544] Sun, 03 June 2018 16:46 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Harte

On Sunday, 3 June 2018 14:41:05 UTC-4, Zellyn wrote:
> On Sunday, June 3, 2018 at 1:40:46 PM UTC-4, Thomas Harte wrote:
> \> Unambiguously, yes. The whole episode speaks very poorly of me and the quality of software I hope to achieve. I'm very embarrassed.
>
> Oh no worries. This is a hobby for (almost?) all of us :-)
>
> I did try booting up the latest Clock Signal against JKM's Dos 3.3 Master .woz file: it seemed to boot more or less correctly (although very slowly).. But when I tried PR#6 to reboot, it did nothing or considered it a syntax error (depending on whether I held the shift key while typing: the characters on the screen were always uppercase). Does Clock Signal put the drive controller somewhere other than slot 6?
>
> Zellyn

It's in #6; if I hit command+n to generate a new machine, select an Apple II and a sixteen-sector disk controller, then drag and drop any DSK onto the machine and type esc, ctrl-b, enter, pr#6, the image boots. Eventually.

Re: speed; I'm ticking the Disk II state machine twice for every CPU clock cycle, spinning the disk image at 300RPM and posting the flux transitions as they arise. That's the full extent of code I've implemented.

I find that entering PR#6 always again from Integer BASIC; if in Applesoft I normally CALL -151 and C600G. Both seemed to work.

So re: loading speed, if you're absolutely sure it's slower than a real Apple II and not just slower than old-fashioned emulators that just spool the next byte immediately upon a CPU read from the shift register, I guess maybe there's something wrong with my stepper, and DOS is spending time dealing with unexpected navigations? I'll have to explore.

I reason: It can't be the case that I'm clocking the Disk II at the wrong rate because then saving wouldn't work. It can't be the case that I'm spinning the disk at a substantially wrong rate or the state machine's PLL would accumulate incorrect shift contents. So track location is really all that's left.
Re: A new emulator [message #368557 is a reply to message #368554] Sun, 03 June 2018 20:25 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Harte

On Sunday, 3 June 2018 16:46:30 UTC-4, Thomas Harte wrote:
> I reason: It can't be the case that I'm clocking the Disk II at the wrong rate because then saving wouldn't work. It can't be the case that I'm spinning the disk at a substantially wrong rate or the state machine's PLL would accumulate incorrect shift contents. So track location is really all that's left.

A further afternoon's worth of tests and: catching RWTS, observing which track is requested, then observing which track the head moves to reveals no issues.

I also tested data repetition speed — how often the disk realises it needs to repeat the track contents. That was the 5 a second you'd expect to make 300 RPM.

The DOS 3.3 distribution disk seemed to take approximately a second between calls to RWTS.

The only surprising behaviour was from the boot ROM which seemed to issue around 80 stepper pulses to ensure it is on track zero, sensibly enough, then wait about 3/5ths of a second, step out to track two, do something for about four seconds, step in to track one, do something for about 16 seconds, then step back in to track zero and actually boot, the first recognised call to RWTS being about six seconds after reaching track zero.

I guess I should look at a disassembly of that to try to determine why it's stepping out to two and then in again with a period on track one before booting.

One other potentially interesting tidbit about my emulation: I'm actually testing it against two machines. As you may or may not be aware, Pravetz — the Bulgarian cloners of the Apple II — also cloned the Oric but decided to pair it up with the Disk II. So I'm testing my Disk II against both the Apple DOSes and the Pravetz 8DOS.
Re: A new emulator [message #369492 is a reply to message #368557] Sun, 24 June 2018 12:16 Go to previous message
Anonymous
Karma:
Originally posted by: Thomas Harte

Minor update: a new version is available. https://github.com/TomHarte/CLK/releases as usual.

Primary improvements:
* joysticks are now emulated;
* there's an experimental attempt at providing DOS 3.3 acceleration;
* users of the SDL version can use their actual joysticks;
* users of the Mac version can switch their keyboards to virtual joysticks for now;
* Mac users will also see drive activity lights; and
* inter-frame blending has been reined in.

For the curious, via Youtube here is:

The emulator showing the Crazy Cycles vapour lock demo: https://www.youtube.com/watch?v=83StdqLaNe4
The emulator running the S.A.M. speech synthesiser: https://www.youtube.com/watch?v=IIejqWEV_8w

It wasn't specifically tested against either thing, both just worked.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Need help with a damage archive
Next Topic: Debugging Z80 code?
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 06:41:52 EDT 2024

Total time taken to generate the page: 0.07822 seconds