6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue Nov 12, 2024 3:31 pm

All times are UTC




Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Fri Jan 29, 2010 6:09 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jan 29, 2010 6:52 am 
Offline

Joined: Mon Dec 23, 2002 8:47 pm
Posts: 70
KEGS? I set it to infinite cpu speed and it still plays Arkanoid 2 nice.


Top
 Profile  
Reply with quote  
 Post subject: Re: Beeb at 17MHz
PostPosted: Fri Jan 29, 2010 11:05 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
mdpenny wrote:
BigEd wrote:
Soon we'll find out how Elite runs on a 12MHz 65816 BBC model B!
... unplayably fast!


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!


Top
 Profile  
Reply with quote  
 Post subject: Re: Beeb at 17MHz
PostPosted: Fri Jan 29, 2010 5:03 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
BigEd wrote:
(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...))


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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jan 29, 2010 5:06 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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


Top
 Profile  
Reply with quote  
PostPosted: Sat Jan 30, 2010 8:55 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
kc5tja wrote:
(remember, the Commodore serial bus transfers data at the break-neck speed of around 3Kbps!)


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.)


Top
 Profile  
Reply with quote  
PostPosted: Sat Jan 30, 2010 9:26 pm 
Offline

Joined: Tue Sep 24, 2002 4:56 pm
Posts: 50
Location: Essex, UK
BigEd wrote:
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Jan 31, 2010 2:19 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Jan 31, 2010 9:48 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Mon Feb 01, 2010 6:09 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
BigEd wrote:
I wonder if the (beeb) OS's buffer management is quite costly.


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:
Code:
*FX 203,50,0


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 01, 2010 8:18 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 01, 2010 8:32 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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.)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 01, 2010 10:48 pm 
Offline

Joined: Tue Sep 24, 2002 4:56 pm
Posts: 50
Location: Essex, UK
kc5tja wrote:
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'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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 01, 2010 11:04 pm 
Offline

Joined: Thu Jul 26, 2007 4:46 pm
Posts: 105
kc5tja wrote:
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.


It's an EIA-423 device...


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 02, 2010 6:09 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 13 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: