What's with some games by Tony Oakden on the Electron?

[0xC0DE]

My emulator has gotten to the point that it can faithfully emulate 99.9% of Electron games. Especially now that I've implemented all undocumented 6502 opcodes as well.

The fun part is getting the remaining 0.1% to work! Like a few games by Tony Oakden. Specifically Camelot and Cyborg Warriors. There is something about the keyboard handling in these games that my emulator can't handle for some reason. Has anybody ever encountered this or any idea what it could be?

Also, Camelot produces a persistent high pitched sound while playing. I've noticed that in at least one other Elk emulator as well. Any ideas?

[jms2]

Does your emulator support direct reading of the keyboard hardware (ie, finding the keyboard status by paging in ROM 10 I think)? That might be a possible cause.

[0xC0DE]

Does your emulator support direct reading of the keyboard hardware (ie, finding the keyboard status by paging in ROM 10 I think)? That might be a possible cause.

Yes, that's ROM 8/9 paged in. I'm pretty sure that's working fine because more games use direct keyboard scanning. I must be missing something. A possible clue: if I keep backspace pressed while playing Camelot the other keys function properly!

[Kecske Bak]

I don't know if this helps but Tony Oakden wrote a couple of articles for The Micro User about techniques he used in his games. Vol 8. Number 10 December 1990 on Pages 80-81 talks about his keyboard handling routines.

[0xC0DE]

Thank you! I downloaded the magazine from here. The article (speeding up the Electron) is very interesting. It explains the difference between software and hardware keyboard scanning, among other speed tricks. Both of these are supported by my emulator but I still seem to have this keyboard problem with games like Camelot.

I am going to find the keyboard routines in Camelot and debug my emulator. Other ideas to investigate are still welcome of course. And I'm still stumped by this persistent high pitched noise in Camelot. Tony surely must have used all the tricks in the book as it is definitely testing my emulator thoroughly!

[Pernod]

And I'm still stumped by this persistent high pitched noise in Camelot.

I'm also interested in what you find out about this as MAME has the same problem.

[Kecske Bak]

I'm sure you've already found it but there's another article in the November 1990 issue (pages 78-79) which talk about the interrupts he uses to shrink the screen and hide the screen memory etc. Tony Oakden seemed to know the Electron inside out - his games do all sorts of interesting things.

[0xC0DE]

For those interested: this is the November issue.
These tricks are used by many Electron games. Very interesting to read.

If I find anything noteworthy while reverse engineering Camelot, I will definitely report back here. First step: trying Camelot in MAME/Elkulator/Electrem

[davidb]

Making a guess about the sound, it could be related to handling of FE07 to change the screen mode, momentarily causing the communications mode to select sound generation. Elkulator also makes a very high pitched sound while playing Camelot, but it could be that all these emulators reproduce sounds that the circuitry in real Electrons would filter out.

[0xC0DE]

OK, that was an interesting trip down the rabbit hole
I have fixed the way my Electron emulator handles hardware keyboard scanning and I have discovered a 'mistake' (I think!) in three of Tony Oakden's games.
I have also compared how 4 Electron emulators handle Tony Oakden's Camelot, Cyborg Warriors, Quest and Star Port.
This may get a bit technical but it might be interesting for future reference and for other emulator coders.

Fixing hardware keyboard scanning in my emulator
I was trapping reads from the well known addresses in ROM 8/9 (keyboard), like 0x9FFF, 0xAFFF, 0xB7FF, ..., 0xBFFB, 0xBFFD, 0xBFFE. My mistake was that I was only checking these exact fixed addresses and also doing it only one at a time (exclusively). Just a big case-statement really. This works 99.9% of the time. I fixed my emulator by realizing that I should check each of the 14 bits of the address line. Basically checking all zeroes in the lower 14 bits of the address. A bunch of consecutive if-statements really. Now Camelot, Cyborg Warriors and Star Port are playable in my emulator! Quest's keyboard handling is different and was fine all along.

Discovering a 'mistake' in Camelot, Cyborg Warriors and Star Port
I think I have discovered a 'mistake' in these 3 games. It doesn't ruin these games of course but it creates some side effects. For instance, in Camelot and Cyborg Warriors you may notice that SPACE is the official key for firing. But, DELETE also works for firing! Similarly, COPY is the offical key for pausing the game, but CURSOR DOWN also works! You can easily check this in Elkulator, for instance.
This is because Tony Oakden is using all the correct addresses in his hardware keyboard scanning routines, except for one. Where he should be using 0xBFFE, he uses 0xBFFC instead. Some examples:

Table with keyboard addresses and bit masks from Camelot:

This table starts at $0CD3 (and comes from the file QUEST22). You may recognize several keyboard addresses, followed by a bitmask. For instance, at address $0CD6 is keyboard address 0xBFFD with bitmask 4. This is used to check for the RETURN (=jump) key. Now check addresses $0CD3 and $0CDC. These contain keyboard address 0xBFFC, which should be 0xBFFE. Using 0xBFFC causes 0xBFFD and 0xBFFE both to trigger, which explains why two keys perform the same function in games like Camelot.
Patching Camelot is easy. Change $FC at $0CD3 to $FE. And the same for the byte at $0CDC.

Another example. One part of the keyboard handling code in Cyborg Warriors:

cyborg.png (24.1 KiB) Viewed 7843 times

Again, all the addresses are correct except for the use of 0xBFFC. Patching Cyborg Warriors is easy by putting $FE at addresses $12FC, $141B, $22B4 and $2304. The same can be done for Star Port by patching addresses $0177, $3160, $31A0 and $340D.

Comparing 4 Electron emulators with 4 of Tony Oakden's games
My emulator now handles Quest, Camelot, Cyborg Warriors and Star Port beautifully. How about 3 other Electron emulators? I have tested Electrem, Elkulator and MAME.
MAME and Elkulator handle all 4 games correctly, except for producing that horrible high pitched noise in Camelot and Star Port which my own emulator suffers from as well. More on that in a next post (hopefully).
Electrem is having big problems. Only Quest works fine. The other three games don't do much at all. I believe the way Electrem is handling hardware keyboard scanning is the culprit and should be easy to fix.

How about a real Electron?
I haven't got a working Electron at the moment so could someone please test the following:
1. Whether Camelot and Star Port produce high pitched noise during gameplay (I don't expect they will!)
2. Whether Camelot, Cyborg Warriors and Star Port process more keys than they should. Specifically: does DELETE work for firing just like SPACE? And does CURSOR DOWN work for pausing the game just like COPY?

[0xC0DE]

Making a guess about the sound, it could be related to handling of FE07 to change the screen mode, momentarily causing the communications mode to select sound generation. Elkulator also makes a very high pitched sound while playing Camelot, but it could be that all these emulators reproduce sounds that the circuitry in real Electrons would filter out.

You are quite right! I have reverse engineered the relevant parts of Camelot and discovered the cause of the high pitched noise during gameplay. I expect Star Port to be very similar, just like gameplay in Star Port is very similar to Camelot. These games can be patched to fix the problem but I have implemented a different solution in my Electron emulator, simply because I believe it is more faithful to the real hardware. Let's dig in.

Camelot uses MODE 1 and employs many of the speed tricks that Tony Oakden himself has written about in his articles listed above. One of these is to temporarily switch to MODE 6 at every VSYNC. You can clearly see this in this code snippet from his IRQ1V ($0204) handler (which starts at $3773):

Code: Select all

        ...
        LDA     #$18
        STA     $FE05
        STA     $F4
        LDA     #$B2
        STA     $FE07 ; set MODE 6 and sound=ON
        LDA     #$FF
        STA     $FE08 ; set color palette to black
        STA     $FE09
        ...

Side effect of this approach is that sound generation is continuously switched ON, no matter what frequency is programmed in $FE06. A little bit later in his IRQ1V handler you will find the following code snippet:

Code: Select all

        ...
        LDA     $C5
        STA     $FE06 ; set sound frequency ($00=highest, $ff=lowest)
        LDA     #$00
        STA     $C5
        LDX     #$11
.delay
        DEX
        BNE     delay
        ...

As you can see the value in $C5 is continuously being fed into $FE06. Camelot sets $C5 (and therefore $FE06) to zero when no sound is needed in the game. This is the root of the problem with the horrible high pitched sound during gameplay. Writing 0 to $FE06 does NOT mean NO SOUND. It actually means: set the HIGHEST frequency possible, which is 31.25KHz (= 1MHz / 16 / 2).

These higher frequencies are most likely not audible on a real Electron (can someone test this?). The Advanced User Guide (chapter "14.1 The ULA and its registers", section "SHEILA &FE06 - The counter") states: "Frequencies from 244Hz up to 62.5kHz can be generated, but you won’t be able to hear the really high frequencies!". But they are certainly audible on modern hardware in every Electron emulator!

My solution is to filter out the really high frequencies. I feel this is more accurately emulating the real hardware. I can finally play Camelot and Star Port without damaging my ears

This should be easy to implement in other Electron emulators, like Elkulator, Electrem and MAME.

[1024MAK]

Adults progressively loose the ability to hear higher frequencies, so I suspect it is not 31.25kHz that is being heard (this is outside the human range anyway), but a lower frequency harmonic. For example, most people aged 40 to 50 or more can’t hear an 16kHz audio tone.

What could be happening, is there may be an interaction between the 31.25kHz and another frequency. The mixing of two frequencies will produce a third frequency that is the difference.

And yes, any high frequency will be filtered out by the hardware in a real Electron.

Mark

[Pernod]

Writing 0 to $FE06 does NOT mean NO SOUND. It actually means: set the HIGHEST frequency possible, which is 31.25KHz (= 1MHz / 16 / 2).

These higher frequencies are most likely not audible on a real Electron (can someone test this?). The Advanced User Guide (chapter "14.1 The ULA and its registers", section "SHEILA &FE06 - The counter") states: "Frequencies from 244Hz up to 62.5kHz can be generated, but you won’t be able to hear the really high frequencies!". But they are certainly audible on modern hardware in every Electron emulator!

My solution is to filter out the really high frequencies. I feel this is more accurately emulating the real hardware. I can finally play Camelot and Star Port without damaging my ears

So what is the correct formula for the frequency, the AUG states 1 MHz / [16 * (S + 1)], and MAME currently uses 1 MHz / [32 * (S + 1)]. I've never found a satisfactory explanation for this.

At what frequency are you filtering/disabling the sound? Just when S = 0?

[davidb]

It's probably more realistic to look at the circuit diagram and try and simplify it to a filter that can be implemented in an emulator. It's what I would expect ThomasHarte to have done with Clock Signal. Are you reading this, Thomas?

[0xC0DE]

So what is the correct formula for the frequency, the AUG states 1 MHz / [16 * (S + 1)], and MAME currently uses 1 MHz / [32 * (S + 1)]. I've never found a satisfactory explanation for this.

At what frequency are you filtering/disabling the sound? Just when S = 0?

I don't have a definitive answer for you. I remember reading conflicting information back when I implemented the sound system. The AUG of course, but also:
https://web.archive.org/web/20060206155 ... o.htm#fe_6
https://www.mups.co.uk/post/2017/11/not ... f-the-80s/
http://mdfs.net/Docs/Comp/Electron/Techinfo.htm

I'm using the same formula as you are. Because the original formula clearly sounds wrong. Some insight from the actual circuit diagram by someone would be highly appreciated.
At the moment I'm simply disabling sound output above a certain frequency (15kHz), i.e. when either 0 or 1 is written to $FE06. An upper limit of 31kHz also works (i.e. writing 0 to $FE06).
Please note, this may introduce problems with very specialized applications. One example is the 1-bit speech sample from Exile. But my emulator couldn't handle that anway

[Deleted User 9295]

But they are certainly audible on modern hardware in every Electron emulator!

Just to support somebody else's comments, 31.25 kHz is highly unlikely to be audible to any human, even a child. What you are probably hearing is a sampling artefact (probably aliasing); if the final audio output is being sampled at 44.1 kHz, with a Nyquist limit of 22.05 kHz, feeding it 31.25 kHz would result in an alias frequency of 12.85 kHz which would be easily audible. If instead it's being sampled at 48 kHz then the equivalent alias frequency would be 16.75 kHz, which it's unlikely I would be able to hear but somebody younger might.

[0xC0DE]

31.25 kHz is highly unlikely to be audible to any human, even a child.

Of course you are right. I should have expressed myself more clearly
Given the (adjusted) formula above my Electron emulator, and presumably others, feed the resulting frequency into their sound emulation code. For instance, I'm using the sound module in Allegro 5. Depending on the inner workings of the sound system a pretty high frequency sound (but nowhere near 31kHz ) is output by the emulators I tested. Just try Camelot or Star Port in Elkulator or MAME and you will know exactly what I'm talking about.

[ThomasHarte]

I'll give both of those a spin in Clock Signal when I get a chance, to see whether it suffers the same audio fate. But for the record, specifics on this drift a little every now and again but right now it's: point sample the output audio at 500Khz and then apply a Kaiser Bessel filter to try as best it can to eliminate any frequencies above half your computer's output rate, then point sample to your output rate. Although not exactly that way around in implementation, but the same as that.

ElectrEm at least attempts to handle the keyboard as a combination of individual selections — see here — so likely there's another issue afoot. I'll check that on Clock Signal too, which attempts to do exactly the same thing.

On divide by 16 versus divide by 32, the AUG describes the output frequency as 1 Mhz / (16 * (S + 1)), which Clock Signal adheres to by flipping its output toggle every 1 Mhz / (32 * (S + 1))th of a second — each full wave is two transitions. I haven't looked at the MAME code, but could similar logic be at play?

Aside observation: this may actually be an AUG error in any case; it's possible they really mean 1/16 as the rate at which the output toggles. I've been trying to persuade myself one way or the other by listening to Youtube videos of the startup beep. Would recommend the same.

Good further tests for a new emulator:

• Exile's sampled speech during its loading process;
• for separate reasons, proper hiding of data and display of graphics in Joe Blade and Southern Belle;
• Firetrack's scrolling;
• that Way of the Exploding Fist loads from tape at all;
• that Stryker's Run is appropriately really, really slow.

EDIT: confirmed that in Clock Signal no noise is present during play of Camelot. I found that (i) audio is enabled; and (ii) the divider is set to 0. So even if everything else were perfect you would expect an inaudibly high frequency to be produced.

EDIT2: also, test against this five-line BASIC loop, which because it is BASIC code will properly test your clock rate transitions when dealing with adjacent ROM/RAM accesses. ElectrEm has an off-by-one error in 2Mhz -> 1Mhz bus transitions that makes all its numbers too small but Clock Signal gets the same results as the real Electron so there's nothing unknown going on at least.

[0xC0DE]

Thank you for your detailed response. I'm pretty sure that CLK is much more accurate (cycle-wise and audio-wise) than my emulator. Your approach to sound sampling and filtering sounds great.
Now that my real Electron is up and running again I can't wait to test my emulator against the real hardware!

Exile's sampled speech is not working in my emulator. I'm afraid that the sound module in Allegro 5 is just not fast enough. I will do further tests but this is no top priority for me. Firetrack is working but not perfectly. That's because my emulator is not cycle perfect. Mode and palette switches anywhere on the screen work pretty well in most games. I can get Joe Blade 1 and 2 to work by manually triggering a cassette interrupt (if I remember correctly) but I need to look into this some more. I might be back with some questions for you
It has been great fun (and still is) getting the remaining 0.01% of games to work

BTW, I was surprised that (the loader of) Repton wouldn't work until I implemented undocumented 6502 opcodes.

For those interested, see the link to my YouTube channel in my signature for some games running in my emulator.

[ThomasHarte]

Alas I discovered that I've broken loading of Way of the Exploding Fist at some point, so I've still got a distance to go. That one's interesting because it goes straight to the hardware rather than using the normal ROM routines for loading, unlike 99.99% of titles. So it tests both your tape hardware implementation and your file format support. Right now in CLK it gets about a third of the way through its custom-format title screen then declares a data error, and I've never added a rewind key so for the user that's the end of that.

I saw that you seem to have something of a debugger in one of your videos, so you're well ahead of me on that. I just keep dithering.

I don't really know that much about Allegro 5, but if it helps at all then ElectrEm had a bit of a hack in it — unwittingly, because I didn't really understand audio at the time, but a hack nonetheless — where off is level 0, normal tone alternates between 0 and 1, and any tone too high to be heard is a constant 0.5. Point sampling that at 44kHz reproduces the Exile voice as it's really just exploiting the fact the transition between on and off can be heard when a really high frequency is set even though both are individually inaudible. Honestly, the 0.5 is even probably a bit silly, it'll just mean that anything using that trick is half as loud as everything else.

Another repressed memory has returned, I'm pretty sure Qwak is another title that prefers to set the beeper to an inaudibly high frequency rather than to off in order to put silence between sound effects. So that might be worth a poke.

Also, now that you have a real one, if you could figure out definitively whether a real Electron sounds an octave lower than the AUG implies it should, I'd be your biggest fan. Alas it's been years since I had one, and I'm in New York nowadays so I've not got the space, or an appropriate display, or a power converter, excuses, excuses, etc.

All I remember re: unofficial opcodes is that E-Type scales its sprites using them, and Exile uses them during its loading. I think both of those didn't run correctly for the first year or so of ElectrEm.

[0xC0DE]

How about a real Electron?
I haven't got a working Electron at the moment so could someone please test the following:
1. Whether Camelot and Star Port produce high pitched noise during gameplay (I don't expect they will!)
2. Whether Camelot, Cyborg Warriors and Star Port process more keys than they should. Specifically: does DELETE work for firing just like SPACE? And does CURSOR DOWN work for pausing the game just like COPY?

I can now answer my own questions on my real Electron
1. No audible high pitched sound on a real Electron (tested Camelot)
2. Yes, those 'extra' keys also work on a real Electron (testing Camelot). Which I believe is a small mistake in the code of an otherwise brilliant game.

[0xC0DE]

EDIT2: also, test against this five-line BASIC loop

Yes, this confirms what I already knew about my emulator. The numbers are way off. I execute a fixed number of cycles in MODE 0-3 and another (higher) fixed number of cycles in MODE 4-6. This works great but is not very accurate.

BTW, running the little test program on my real Electron (German version, issue 1, which I believe is similar to an issue 6 UK version):
0: 14.73s
1: 14.76s
2: 14.91s
3: 11.95s
4: 7.08s
5: 7.09s
6: 7.08s

[0xC0DE]

Also, now that you have a real one, if you could figure out definitively whether a real Electron sounds an octave lower than the AUG implies it should, I'd be your biggest fan.

Sound comparison of a real Elk with 4 emulators: viewtopic.php?f=4&t=16902

The Elk startup beep (the same as pressing CTRL-G) is generated by writing 0x3A (58) to the COUNTER register ($FE06). I just checked this in my debugger. So, according to the formula in the EAUG, this should produce a tone of 1000000/(16*59) ~ 1059Hz.
That sounds like this:

square1059hz.zip

(68.24 KiB) Downloaded 57 times

Or listen to it online: https://www.wolframalpha.com/input/?i=p ... quare+wave


This is definitely not the sound produced by a real Elk or any emulator.
The adjusted formula, used by most emulators (and apparently the real Elk!), suggests a tone of 1000000/(32*59) ~ 530Hz.
Which sounds like this:

square530hz.zip

(64.37 KiB) Downloaded 57 times

Or listen to it online: https://www.wolframalpha.com/input/?i=p ... quare+wave


And that definitely sounds like an Electron! Even though a real Elk doesn't output a square wave but a much 'richer' sound like this:

Edit: added links to WolframAlpha

[0xC0DE]

All I remember re: unofficial opcodes is that E-Type scales its sprites using them, and Exile uses them during its loading. I think both of those didn't run correctly for the first year or so of ElectrEm.

The Electron versions of E-type and Exile that I've tested don't use undocumented opcodes. Very few games do. Some examples: Repton and Stairway to Hell. My emulator/debugger sets a special flag in the monitor window as soon as an undocumented opcode is executed

[ThomasHarte]

It's a twenty-year old memory, I'm sure I'm in error. I was pretty sure that shift-left and OR was the culprit in E-Type's case, but clearly not, and if I had to guess about what led to my false Exile memory, possibly it's just getting the flags right? I'm pretty sure I had overflow wrong for a while there at the start.

[0xC0DE]

In my experience, the hardest instructions to get 100% accurate are the ADC and SBC instructions. Especially the status of the flags after addition or subtraction which do not always behave as expected, especially in decimal mode.

This helped me a lot to get it right: http://www.6502.org/tutorials/decimal_mode.html#A

[ThomasHarte]

Yes, I'm confident that I didn't really know what overflow was for the first half a year or so. Nowadays I am now entirely dependent upon unit tests: for the 6502 I apply those by Wolfgang Lorenz, those by Klaus Dormann, the AllSuiteA tests, the BCD-specific tests produced by hoglet right here on this forum (BCDTEST_beeb isn't actually BBC specific, output is all via the MOS), and some custom timing and interrupt process tests.

For comparison, right now I'm in the middle of putting together an emulation of the 68000 and haven't been able to find any third-party sets of unit tests whatsoever. So it's proving to be a grind.

[0xC0DE]

I have only tested my emulator with the Dormann test before. I will certainly try the other tests. Thanks!

[Kecske Bak]

I've just found an article I downloaded as a PDF from Electron User, August 1986 Pages 41-43. It's by the author of Citadel, Michael Jakobsen, and talks about methods he used to make the Electron version of Citadel faster. It may be of interest to OxC0DE.

[0xC0DE]

Yes, I found that earlier. Very interesting. I have now created a framework that works on BBC and Electron that allows me to take over the entire machine, all RAM, all speed, no MOS. Useful for cross platform demos and games.