Vega ARM SOC?

2»

Comments

  • That makes sense. This is why it's hard for even 2-4 GHz machines to accurately emulate vintage hardware. Because so many things are happening concurrently. :-)

  • The problem is appears as the HW is really basic. When the CPU can't cope with the basic Spectrum emulation, will not be possible to add things as USB support easily. The USB support in the Raspberry PI induces a 10% CPU load. A USB Bluetooth dongle uses up to near of 30% CPU when a BT mouse is attached. A hard task for Chris, for sure.
  • (actually, SDRAM in the Vega)
    Actually, DDR. 200MHz DDR SDRAM, 8M x 16 bits, to be precise. The ARM CPU has a 16KB code cache, and 16KB data cache. I recall that the maximum allowable frequency is 480MHz, but I don't know if the ARM core is being used at that frequency.

    The ARM core itself is ARM926EJ-S actually. I can't see if this is a pipelined or superpipelined CPU anywhere in the tech docs. I may assume is has a simple pipeline. How fast a CPU should be to provide 100% accurate emulation of a 128K Spectrum? RealSpec claims to be the first 100% accurate emulator, and it was designed for MSDOS, so we can assume it's actually a bare bones emulator. It required a Pentium MMX computer.

    Maybe RealSpec was written in assembler (seems so). I don't know if the Vega firmware is 100% C, or it has some time critical portions written in ARM assembly. In the MSDOS days, emulators like Gerton Lunter's Z80 took advantage of the similarities between the x86 architecture and the Z80 architecture and ran the Z80 core emulation so that a register from the Z80 core was stored in a x86 equivalent register. That allowed a real-time emulation with a relatively slow processor, like my first i386 @33MHz . Most probably, the Vega firmware has not taken any advantage from the vast amount of registers an ARM9 core has (or it has no need to be aware of that the C compiler is smart enough). Maybe Chris hasn't had time to profile the code. Maybe he is not in the need to do that, 'cause the emulator firmware just works.

    In short words: room for improvement surely exists, but that will require an advanced level of fine-tuning code that in turns requires time. And those who have read the "Creating the Vega" book already know that this is not a full-time job for Chris, but something he does in his spare time.
  • RealSpec claims to be the first 100% accurate emulator, and it was designed for MSDOS, so we can assume it's actually a bare bones emulator. It required a Pentium MMX computer.

    Yeah but I could claim that I'm the galactic emperor Xarglespleeg VaaaaarPlrrrrrrt... wouldn't make it true ;)
    My rubbish website including the redrawn Amstrad schematics and the new home of the Sinclair FAQ wiki.
  • guesser wrote: »
    Yeah but I could claim that I'm the galactic emperor Xarglespleeg VaaaaarPlrrrrrrt... wouldn't make it true ;)

    We all know that wouldn't be true because Xarglespleeg was killed during the third Vormac Raid of the Ninth Resistance.

  • In my experience, you need about 300MHz to achieve a proper emulation at full speed in Windows with all the overhead that entails. Let's call it between 150 to 200 MHz for something running on bare silicon with no OS to bog things down (which is what the Vega is).

    RealSpectrum was good, but it was nowhere near the 100% accuracy that it was claimed to be.

    It also depends on what you're going to emulate. Contention actually slows down the emulation which gives you a small amount of headroom, but multicolour eats into that - at significant places in the frame (usually at contention points) you have to update the display. You don't need to update when a write to video memory occurs (though the above usually means that you do), and you can buffer your display updates accordingly. ZXSpin (and SpecEMU) updates the display in batches grouped into portions of a scanline for this. (You can also add a list of flags for "dirty" scanlines which can be used to further reduce the CPU load endured during display updates).

    There are a couple of levels of ULA snow emulation - RealSpec makes a "best guess", ZXSpin is somewhat more accurate but only at a granularity of 4Ts, SpecEMU appears to get it most accurately which requires - when I last looked into it with Woody - a 1Tstate accuracy level, though I suspect Woody has done something awesome that mitigates that. Even then, the snow is still not 100%, but bloody close.

    Achieving 100% snow accuracy alone would push the CPU requirements through the roof.

    D.
  • Yeah, unfortunately, that's the problem with emulation in general. Which is something I'm learning trying to build a compatible ZX Spectrum. It's proving very difficult even with fast micro-controllers. The problem comes down to parallelism. Fast CPU's still only have a few cores max. But a ZX Spectrum and all of its glue logic is performing dozens...maybe hundreds of parallel tasks. So the sequential nature of CPUs must be so incredibly fast that they can execute those tasks in the same amount of time as the slower, but parallel, components.

    Best we can hope for (without FPGA) is to emulate the functionality and proxy the infrastructure so that everything appears to be equal.

  • cbmeeks wrote: »
    Fast CPU's still only have a few cores max. But a ZX Spectrum and all of its glue logic is performing dozens...maybe hundreds of parallel tasks. So the sequential nature of CPUs must be so incredibly fast that they can execute those tasks in the same amount of time as the slower, but parallel, components.

    Even with the required amount of cores, you'd not get an accurate emulation without some real headache-inducing synchronisation that you'd need to replicate the interactions between the various modules in the Speccy. In fact, I'd hazard a guess that a slower single-core CPU (say, about 800MHz) could get very, very close to 100% speed far easier than an octacore running at the same speed but programmed to simulate interactions on each core.

    The great thing about emulating a speccy is that to do a decent job you only have to emulate at 4Ts granularity, and pay attention to the (perfectly predictable) interactions between CPU and peripheral logic. Having one clock to synchronise them all makes it easier to emulate.

    D.
  • FPGA? Why? ARM ? Why? Don!t you have your own genuine stuff like Z80? You are all nerds. Honestly.
  • maiki wrote: »
    FPGA? Why? ARM ? Why? Don!t you have your own genuine stuff like Z80? You are all nerds. Honestly.

    I have nearly 60 "vintage" computers from the 70's - 80's including a genuine ZX Spectrum, ZX81, etc. So I am the king of nerds. :-)


  • maiki wrote: »
    FPGA? Why? ARM ? Why? Don!t you have your own genuine stuff like Z80? You are all nerds. Honestly.

    Bears poo in the woods.

    Of course we're bloody nerds! You have to be a bit of a nerd to even contemplate playing with a long obsolete personal computer! :-)
  • At the moment - Pentium100 is obsolete.
    The ZX Spectrum - is _classic_. :)
    ZX81/ZX Spectrum/Amiga/Atari music: http://yerzmyey.i-demo.pl/
  • maiki wrote: »
    FPGA? Why? ARM ? Why?
    Because we can :D

Sign In or Register to comment.