Does the speed-up affect the global emulator state, or just the CPU?

The VICE emulators, for example, will speed everything up globally. So while the CPU may turn into a 200MHz power-house, the VIC-II timing also turns into a 200MHz power-house, and your video refresh rate scales up accordingly. Therefore, your game which now becomes unplayably fast, still honestly thinks it's playing at 1MHz.

If, however, the emulator speeds up only the CPU but not the peripherals, then you can still reference, for example, vertical sync timing as a time-base. This lets the game play at "normal speed," despite the enhanced CPU clock speed.

I don't know anything about the BBC architecture, unfortunately. But, for example, I know the Apple IIgs emulator I sometimes play with warps only the CPU, leaving the peripherals at their native bus clock speeds. So, I can get a 200MHz Apple IIgs that still plays old games just fine (as long as they synchronize against the vertical sync).

KEGS? I set it to infinite cpu speed and it still plays Arkanoid 2 nice.

Spot on! Unfortunately...

I suppose the Elite I'm running would be their first effort, difficult enough without worrying about running correctly on futuristic platforms.

(The Beeb OS has a 100Hz timer, which isn't affected by our acceleration. Not sure what the various emulators do about that, but it's an official timebase so they shouldn't run it fast. There's also a wait-for-vertical-sync call, which again ought not to be anything different from 50Hz (or 60Hz...))

I'd be surprised if the TUBE version had the same trouble, as the second processor is decoupled and they might have anticipated different speed grades - but perhaps not.

Also unfortunate: we were only able to run Elite at 4MHz - at 8MHz the disk reads were unreliable (although of course the i/o access cycles are always slowed to 1MHz - the disk controller should not be aware that there's an 8MHz CPU. But the NMI routines will be running fast - just possibly there's a software problem there. Also possible that our slowdown/speedup which is generally working is in some way not quite right when talking to the 1770 disk interface.)

More debugging needed!

This completely depends on the goal of the emulation warp. If the warp is to speed up long-running programs, you might be right. But, if the warp is to also speed up long-running I/O operations (remember, the Commodore serial bus transfers data at the break-neck speed of around 3Kbps!), then you want to scale the peripheral frequencies by the same rate, so the relative CPU/peripheral timing remains intact, while the real-time aspect is accelerated.

An interesting case!

I would think in most cases interaction with the outside world (in the case of a game, the player) would want to proceed at a 1:1 pace.

But yes, it depends on what is meant by emulating a machine at an accelerated rate - an emulator might even offer a choice of modes, if there was demand.

Edit: replaced flippancy with content

I know there are interesting reasons for that.

On a similar theme, I found today that the serial performance of my accelerated beeb was much much better than at original speed.

I found that loading an srecord at 19200 I was only getting about 1400 bits per second (counting 10 bits per byte) - but in accelerated mode I got more like 12000. Pretty similar timings for a BASIC srecord loader and for a machine code one.

I wonder if the OS's buffer management is quite costly. Or perhaps there's a non-linear effect depending on how much the RTS/CTS flow control has to be used. (The original docs recommend against running the link as fast as 19200 but I always took that to be a concern about the electrical or timing aspects.)

Perhaps an IRQ latency-related issue...?

I mean, it may not take a *huge* amount of time to respond to something wiggling its IRQ line, but the OS has to work out whether it's dealing with a BRK or an IRQ, work out what's doing the wiggling of the IRQ line, get the received byte from the ACIA, and drop said byte into the relevant input buffer.

Upping the performance of the CPU (and main RAM) should allow the CPU to "keep up" with a higher receive rate without having to resort to a serial controller that's got built-in transmit and receive buffers.

Just my 2p's-worth...

--Martin

_________________
Martin Penny

.sig in beta - full release to follow.

What initially comes to mind is just the computer's speed to do something with the info. It may take only a small percentage of its computing time to keep up with the serial link, but doing something with that info may be another matter, so it has to keep telling the other end to wait because it's not ready for more.

As for the interrupts though, you should poll for the highest-urgency possibility first, and you should only be polling for interrupt sources that are enabled. Most possible interrupt sources will be disabled at any given time, and you should not be wasting time polling for those. As for BRK, I haven't used it since I was in school in the early 80's, so I never poll for it.

There's a set of disassemblies of the BBC OS here - I refer to it quite often, and it might be a useful crib to anyone else bringing up hardware.

It does check for the serial device very early in the IRQ handler (the disk is dealt with in the NMI handler, so serial is the most urgent case)

Because both my BASIC and machine code srecord loaders have the same behaviour, I thought it not likely that my handling of the input was critical. However, I am using an OSWORD to read a whole line of input: perhaps that's quite expensive. Certainly it batches up the work instead of spreading it out per-character.

But I'm still surprised: a rate of 140 Bps at 2MHz is 14000 clocks per byte - that's a lot of instructions.

I should correct my speculation. It turns out there are several recommended ways to wire up a serial cable for a beeb, but in ignorance of that I'd done the simple and obvious thing of just crossing RTS and CTS for flow control.

richarde had followed this recipe, and he finds he can shift data at an intermediate rate, at both original host CPU speed and accelerated to 11MHz. So, we get approx

~1400bps - simple cable, stock 2MHz CPU
~4600bps - beeb-specific cable, CPU at 2MHz or 11MHz
~12000bps - simple cable, 13MHz CPU

I found I needed to adjust the OS buffer policy to avoid overrun:

Wow, that is a gross misinterpretation of the EIA-232 standard. Does the BBC have any rationale for its perverted wiring? Yikes!

At least it works though.

I don't think any of those sites say in what way a normal cable doesn't work - for me, in fact it did work, but with poor throughput which in some way was a function of CPU speed. I still don't know exactly what's happening - nor do I know why those weird cable designs work any better than a normal one.

(BTW, the machine is by Acorn, but bears the BBC name because the BBC chose it and adopted it for the national computer literacy scheme. The machine was therefore massively successful, which was great for Acorn.)

I'm sure I read somewhere (can't remember exactly where ATM - one one the manuals, or one of the old Acorn-specific mags that had an article on serial I/O) that Acorn looked at the various serial specs, looked at the 6850 pinout, and came up with some sort of compromise, aiming at something simple-but-workable.

--Martin

_________________
Martin Penny

.sig in beta - full release to follow.

It's an EIA-423 device...

I seem to recall EIA-423 differing from -232 primarily in signal representation (5V swing with higher drive current instead of 12V) and link speed. The flow control protocols, however, were the same.