Vega ARM SOC?

edited October 2015 in Vega
I read that the core of the new Vega was an ARM SOC. I thought it would have been an FPGA. But it seems it's an ARM running an emulator. Anyone know if that's true? Or better yet, what ARM chip was used?
Post edited by rich_chandler on
«1

Comments

  • Update

    Yeah it is emulated. Would love to know the exact chip used.
  • Chris Smth, who wrote the ZX Spectrum ULA book, designed it. From what I've read his original intention was an FPGA or similar implementation but it was cheaper to use an ARM in the small numbers they were looking to make. I'm sure the story is told in his latest book on the design of the Vega.
  • Oh I didn't know he had a new book.
  • Yep, it's an ARM. Which is better, especially given what I want to do with it :)

    D.
  • edited October 2015
    BTW, I just bought his book on making the Vega.

    Yeah, I'm actually a little surprised that he used an ARM for that. But I never really priced anything at scale which I know is a complete different ballgame than a few prototypes being built.

    Anyway, that'a a little exciting as well. Wanting to build a ZX Spectrum clone myself that is.

    So I assume that ARM is doing the Z80 / ULA emulation along with creating both NTSC and PAL signals. Must be a pretty beefy chip to do all that.

    Does anyone know if the Vega can be used as an outright ZX clone? Assuming one could attach a keyboard that is.


    ** BTW **

    I'm not sure how I posted this message in Updates. I did it on my phone but I thought I was under the hardware section.
    Post edited by cbmeeks on
  • The Vega's emulation is extremely accurate - so assuming that you could feed the keyboard to the appropriate ports in the emulated speccy, it would do just fine.

    Compared to a 3.5MHz Z80, this is indeed a powerful ARM.

    D.
  • OK, so someone needs to add a Bluetooth adapter to it so that we can use it with the Spectrum Recreated keyboard. :-)

  • edited October 2015
    cbmeeks wrote: »
    So I assume that ARM is doing the Z80 / ULA emulation along with creating both NTSC and PAL signals. Must be a pretty beefy chip to do all that.
    Well, ARM System-on-Chip means ARM cpu + any number of included peripherals. Which may include stuff to help generate a video signal. Say, a framebuffer for example. Which would make generating video easy, and leave the cpu to focus on emulating the ZX. But yes it would be nice to know the exact SoC used.

    And that's of course a modern, pipelined cpu with 32 bit internal registers, (presumably) plenty of flash memory + RAM included, and much higher clock rate (up to 80~100 MHz ARMs is cheapo hobbyist gear these days, much much faster is available).

    If only they include:
    a) The ability to re-program the ARM cpu. And flash memory! (if included, that is: game images not in a mask ROM).
    b) The ability to hook up a keyboard - as mentioned by quite a few others.
    c) (optional) Open source the included emulator code (if not derived from some other open source emulator).

    a) and b) combined would make it a very nice hackable device, useful for many jobs other than ZX Spectrum emulation.
    c) Would make for much better/easier community support in terms of fixing bugs / adding features.
    Post edited by RetroTechie on
  • I agree with all of that. It's a shame that such an official product is so great but doesn't give much room for expanding it.

    Honestly, I don't even care about the joystick part of it. What I want is a modern day ZX Spectrum. Something that is open source and can be built with off the shelf component. Put that in a nice case and connect to a TV or VGA monitor.

    Of course, a keyboard adapter is a must. Would be really cool if it allowed both legacy membrane keyboards and USB as well.

    But, the VEGA was made for a cost and mass production. Much different than hobbyist projects.

    I actually received the Making of the VEGA book last night. I read Chris's chapter in about 10 minutes. lol

    He said that the original design was all on FPGA but the problem was getting it produced in an ASIC chip is insanely expensive.

    This is really why I am trying to design my own ZX Spectrum clone. My goal would be to use all off-the-shelf components that are still made today.

    Including a real Z80, real SRAM and a microcontroller (or two) for video/audio/IO.

    But cloning the Speccy is no trivial task. Many people mistake its "simple" design as being easy to clone. But to get bizarre timings right is challenging.

    Oh, and I don't personally want to use FPGA for my first revision. Mainly because I want hobbyists to be able to breadboard it and use easy tool chains.

    My initial design would be to have a small box with a motherboard in it and USB hookups for keyboard and joypads.

    An added bonus would be to figure out how to get Bluetooth installed so we could use the ZX Spectrum Recreated keyboard. That would be the perfect system for me.

    Anyway, sorry about the long rant. lol
  • Originally, Chris wanted to do the Vega using an ASIC (application-specific IC, basically, having a custom chip manufactured - a Speccy on a chip). His prototype (Spectrastick) was on an FPGA but designed to be fabricated on silicon as an ASIC. However, the risks were too high. The thing with an ASIC is the cost of making the first one is about 3 million quid, even if it costs only pennies to make the following million. So you have to be guaranteed to sell *a lot* or the bank will be reposessing your home and you will be bankrupt, having lost everything. Selling a large number of Spectrum clones is unlikely, unfortunately.

    The other option considered earlier was to actually sell a FPGA based design, which can be done easily in lower quantities. However, the hardware would have been quite expensive - an FPGA suitable to implement the design is about £20 per chip even bought in 1000 quantities.

    The ARM SOC is vastly cheaper than this, and makes the development a bit easier (since you can put some of the things outside of the Z80 core, and write them in C with a nice flat memory model). The emulation running on the Vega's ARM SOC is actually a bare metal emulation - there is *NO* operating system as such - everything was to run on the bare SoC and it's effectively a hard realtime system. This is essentially how we did home computers in the 1980s, so the Vega is very true to the original Spectrum in this regard even if it's emulating Z80 instructions rather than having a Z80 core in an FPGA or ASIC.

    I think the crowd funding turned out to exceed all expectations, I suspect the FPGA route might have been taken if they knew they were going to hit funding goals in less than 24 hours.
  • You're spot on. I read pretty much the exact same thing.

    I do wish that they would open source the FPGA files, ARM source, etc.
    Heck, I'd like to even know what ARM MCU they used. The book doesn't tell you that. If anyone owns one, I'd love to know (assuming you're OK with taking the cover off).

    I also get the impressions that the markings might be scratched off the chip. Maybe not by the VEGA team, though. Just seems like there is some secrecy about the specs of the hardware and the code.

    I get they are trying to recoup expenses, make a profit, etc.

    But Chris, if you're reading this...show us the code! :-D
  • cbmeeks wrote: »
    What I want is a modern day ZX Spectrum. Something that is open source and can be built with off the shelf component. Put that in a nice case and connect to a TV or VGA monitor.

    So a harlequin then ;)
    My rubbish website including the redrawn Amstrad schematics and the new home of the Sinclair FAQ wiki.
  • lol. Yeah, I knew about that one. What I should have said was something that isn't $200+. :-)

    Last time I looked, it was pretty pricey to get a board made.
  • well if you design one with a CPLD instead of all the logic chips and use surface mount z80, ram, and a flash rom, you would get the size of the board required down :)
    My rubbish website including the redrawn Amstrad schematics and the new home of the Sinclair FAQ wiki.
  • That's my goal...other than CPLD or FPGA. Too hard and expensive to get into. Plus I want my project to be hobbyist friendly.
  • Well if you don't use a CPLD then you need a huge board full of logic chips so your PCB is expensive :)
    Xilinx offer a free version of their development tools, I don't know about the other brands.
    My rubbish website including the redrawn Amstrad schematics and the new home of the Sinclair FAQ wiki.
  • I have an FPGA board. I lost interest when I couldn't get the 28 GIGS of development tools to work.
  • Just speccy 128k
    This seller was also selling just the PCB earlier in the year. New old stock 128k ULA chips are still available (not cheap mind).
    Facebook page

    Mark
  • edited October 2015
    cbmeeks wrote: »
    I do wish that they would open source the FPGA files, ARM source, etc.

    The ZX Uno FPGA is based off the same body of work (basically, the ULA Book is the root of both the Vega and the Uno, as well as the FPGA design and CPLD ULA replacement that Chris worked on). The Uno FPGA is open source, and there is a Spectrum ULA by the same guy (Miguel Ángel Rodríguez Jódar) freely downloadable at OpenCores. I think the ULA includes the ULA+ too.

    Miguel Ángel has also prototyped a ULA+ plug-in ULA replacement, but doing his doctorate got in the way of that a bit. I've seen it demonstrated at RetroMadrid a couple of years ago. It's on a very thin PCB so it'll actually fit in a 48K case!

    Post edited by Winston on
  • cbmeeks wrote: »
    What I want is a modern day ZX Spectrum. Something that is open source and can be built with off the shelf component. Put that in a nice case and connect to a TV or VGA monitor.

    Of course, a keyboard adapter is a must.

    All of this has long existed in exUSSR: clones on the basis of DIP, the clones on the basis of CPLD, the clones on the basis of FPGA, and even hardware and software emulators on the ATMEGA.
  • edited December 2015
    Winston wrote: »
    I think the crowd funding turned out to exceed all expectations, I suspect the FPGA route might have been taken if they knew they were going to hit funding goals in less than 24 hours.
    So we expect :)
    BTW: the SoC inside the ZX Vega is made by Freescale. It's funny how a company that ended up adquiring the CPU division of Motorola, now does a SoC that is used to build a modern ZX Spectrum.
    The SoC is called i.MX23 Applications Processor. It's pretty documented ;) I've alredy got the datasheets of all components of the Vega.
    Post edited by mcleod_ideafix on
  • Dunny wrote: »
    The Vega's emulation is extremely accurate - so assuming that you could feed the keyboard to the appropriate ports in the emulated speccy, it would do just fine.
    Not that easy. Emulation takes almost all the CPU power from the SoC. Allowing both a matrix keyboard AND the current Vega pad to be used as the emulated Spectrum keyboard has its caveats: there might be not enough time to read all the involved GPIOs and form a suitable 5-bit data to feed to the Z80 via (emulated) port $FE.

    As for the accuracy of the emulation, I have to say that I tried some demos (Shock Megademo being the most well known maybe) and the second part (the famous multicolour border+paper effect) fails miserabiliy on the Vega. Tried both 48K and 128K timings with no success. Actually, tried a few demos:

    AEON: works well. No issues at all. If anything, the music sounds a bit different than in an original 128K machine (a fast arpeggio line seems to sound louder in the Vega). If you use the Vega with a big screen, download and play it (configure it for 128K) for some eye-candy :).

    Back 2 the Gemba: the initial logo drawing takes a lot of time than the original, and instead of music, there is a series of short noises. The white courtain effect only shows the border. The digitized voice sounds ok. Everything else works fine.

    Mescaline: horrible. Also it slows down emulation speed a lot. If I try to bring up the system menu (key M) the OSD takes ages to show up and the key pad is almost unresponsible. Seems that everything that involves changing screen pages (Mescaline does this on every frame to get multicolor effects) needs a lot of ARM power.
    mescanline_en_vega.jpg

    Paralactika: (this is the fixed version that runs on a 128K heatsink/+2 grey fine). It uses the same effects that Mescaline (not by chance: this demo is from the same demogroup -DeMarche- that released Mescaline), so it executes as horrible as Mescaline.

    Shock Megademo: (tried in 48K mode). Everything fine except the mulitcolor part. Even the Mat part (the infinite bobs) runs fine, as I recall he didn't use dual screen pages, so that this part could work in a 48K machine.
    shock_megamo_en_vega.jpg

    Vibrations: slows down during the first effect (snow screen, then eyes scrolling up, then the phrase "GET DOWN" scrolling down). This also happen in a regular 128K machine, as this part needs no contention. What is also different is that the bitmap with the eyes has some garbage on it, which didn't happen in the 128K.

    Mercenary 3: The Melange Defender. This was a entry to the ZX Graphics compo for the Chaos Constructions 2013. I think it was the winner entry. It features a remarkable screen that uses not only the paper area, but the border as well, featuring a borderless picture of about 384x304 pixels. The player supports 48K, 128K, +2A/+3, Pentagon and Scorpion. The 48K is the one I tested and doesn't look well.
    mercenario_en_vega.jpg

    Tried also a little program I made to demonstrate the split screen capabilities of the 128K Spectrum, and it also failed. The screen page is not changed when I toggle bit 3 of port $7FFD, but the next frame following that. I don't know what the code I wrote does to the emulation core, but everytime I try to get the OSD in, the emulator slows down so much that the music doesn't play smooth any longer. Here it is:
    http://www.atc.us.es/~rodriguj/dualplane.zip (try dualpmusica.tap and rename it to have the Vega load it as a 128K program)

    ULAplus palette changes does not happen the moment the palette register is changed, but also on the next frame following the change. So HAM256 modes don't work in the Vega.

    As you see, emulation comes with compromises, and in the case of the Vega, the SoC seems to be not enough powerfull for a 100% accurate emulator if it has to take into account too much things that happens at the same time in the original machine. All in all, it's accurate enough for the vast majority of games it can run, which I guess it's the goal.

    But, please, don't misunderstand me. I really enjoy playing with the Vega. I'm not a pro, and have only managed to finish one, or maybe two games in my life (Bruce Lee being one of them), but when I'm in the mood for some retroplaying, the Vega is called for duty.
  • Except for border effects, all problems you mentioned seem to affect gigascreen only, not multicolor. The Vega distribution includes several multicolor games, that seem to work correctly.
    Creator of ZXDB, BIFROST/NIRVANA, ZX7/RCS, etc. I don't frequent this forum anymore, please look for me elsewhere.
  • @mcleod_ideafix,

    What is that last screen? That looks amazing.
    As for the accuracy of the emulation, I have to say that I tried some demos (Shock Megademo being the most well known maybe) and the second part (the famous multicolour border+paper effect) fails miserabiliy on the Vega.

    Can you talk a little about the "famous multicolor border+paper effect"? I'm new to Speccy games but I'm always curious to understand how programmers pushed hardware (on any platform) beyond the specs.

    Thanks!
  • edited December 2015
    cbmeeks wrote: »
    @mcleod_ideafix,

    What is that last screen? That looks amazing.

    A picture that uses timing techniques to change the border colour at specific times so it makes the impression that it has more pixels than you can normally use.
    cbmeeks wrote: »
    Can you talk a little about the "famous multicolor border+paper effect"? I'm new to Speccy games but I'm always curious to understand how programmers pushed hardware (on any platform) beyond the specs.

    Thanks!

    The key to most effects is precise timing. The time each Z80 instruction spends on every instruction is documented. From several years ago, the relationship between the ULA and how it affects timings in the Z80 is known, so one can write a program that, say, changes the border color every 224 T-states (a T-state is a CPU clock cycle, about 290ns). 224 T-states is also the amount of time needed to scan one line on the TV. As the ULA repeatly reads the value of port $FE to find out what colour the border must have during the next 8 pixels of border, changing the colour every 224 T-states (or every 64 microseconds) will get the effect that the border is composed by multiple lines of different colours each.

    A quick and dirty test of such a program with precise timings to achieve a rainbow effect with the border (assemble with pasmo --tapbas to get a nice TAP file to load into your 48K Spectrum or emulator):
                      org 33000
    
    Main              halt  ;wait until interrupt
                      ld bc,1000    ;10T
    WaitUntilScreen   dec bc        ;6T
                      ld a,b        ;4T
                      or c          ;4T
                      jr nz,WaitUntilScreen  ;12/7T
                      ;10+999*(6+4+4+12)+6+4+4+7=26005T from interrupt
    
                      ld a,(16384)   ;an operation that generates contention
    
                      ld a,81h
                      ld i,a
                      im 2
                      ld bc,00FEh    ;port FEh
                      ld a,0         ;initial border color
                      ld d,7         ;mask
                      ld hl,NewFrame
                      halt           ;wait until interrupt, which will lead us to...
    
                      org 81FFh
                      dw Interrupt
    
    Interrupt         di               ;here!
                      rept 32
                        nop
                      endm           ;we want to start at the beginning of the left border
    NewFrame          rept 311        ;unroll this code for the next 311 scanlines (change by 310 for 128K)
                        out (c),a    ;12T
                        inc a        ;4T
                        and d        ;4T
                        rept 51      ;(change by 52 for 128K)
                          nop        ;51*4=204T (52*4=208T)
                        endm
                      endm
                      ;Last scanline has different timings because we have to insert a JP instruction to
                      ;start all over again
                      out (c),a
                      inc a
                      and d
                      rept 50
                        nop
                      endm
                      jp (hl)  ;4T
    
                                     ;Total: 12+4+4+204=224T (12+4+4+208=228T for 128K) each repetition.
                                     ;312*224T = 69888T per frame (311*228T = 70908T per frame on 128K)
                                     
                      end Main
    
    Post edited by mcleod_ideafix on
  • A similar effect, but this time using the ULAplus palette register to change the color or both the border and the paper, achieving a full screen multicolour effect.
    ULAPLUSADDR       equ 0BFh
    ULAPLUSDATA       equ 0FFh
    ZXIPORT           equ 3Bh
    
                      org 33000
    
    Main              xor a
                      out (254),a
                      ld hl,22528
                      ld de,22529
                      ld bc,767
                      ld (hl),a
                      ldir
    
                      ld c,ZXIPORT
                      ld b,ULAPLUSADDR
                      ld a,64
                      out (c),a
                      ld b,ULAPLUSDATA
                      ld a,1
                      out (c),a
                      ld b,ULAPLUSADDR
                      ld a,8    ;border 0 or paper 0
                      out (c),a
                      ld b,ULAPLUSDATA
    
                      halt  ;wait until interrupt
                      ld hl,1000    ;10T
    WaitUntilScreen   dec hl        ;6T
                      ld a,h        ;4T
                      or l          ;4T
                      jr nz,WaitUntilScreen  ;12/7T
                      ;10+999*(6+4+4+12)+6+4+4+7=26005T from interrupt
    
                      ld a,(16384)   ;an operation that generates contention
    
                      ld a,81h
                      ld i,a
                      im 2
                      ld a,0         ;initial border color
                      ld hl,NewFrame
                      halt           ;wait until interrupt, which will lead us to...
    
                      org 81FFh
                      dw Interrupt
    
    Interrupt         di               ;here!
                      rept 32
                        nop
                      endm
    
    NewFrame          rept 311
                        out (c),a
                        inc a
                        rept 52
                          nop
                        endm
                      endm
                      ;Last scanline has different timings because we have to insert a JP instruction to
                      ;start all over again
                      out (c),a
                      inc a
                      rept 50
                        nop
                      endm
                      xor a
                      jp (hl)  ;4T
    
                                     ;Total: 12+4+4+204=224T (12+4+4+208=228T for 128K) each repetition.
                                     ;312*224T = 69888T per frame (311*228T = 70908T per frame on 128K)
    
                      end Main
    

    UNfortunately, thsi won't work in the Vega, as it currently does not support changing palette registers while it is reading the graphics buffer. Only between frames.
  • UNfortunately, thsi won't work in the Vega, as it currently does not support changing palette registers while it is reading the graphics buffer. Only between frames.

    This is very helpful!

    I've been trying to design a ZX Spectrum compatible computer but I wanted to reproduce the graphic effects as much as possible. So I've been trying to devise a way to allow the CPU access to the pixel/attribute data on the current scanline (using a microcontroller).

    Anyway, the fact that you're saying the Vega doesn't allow changing palette registers while reading the graphics buffer makes me think that it's halting the CPU and grabbing the pixel/attribute data for the next scanline. So, any cycle counting is rendered worthless because when the raster gets on the scanline, it already has the data for it. So altering it during the hblank doesn't have any effect.

    This is my theory, anyway.


  • cbmeeks wrote: »
    Anyway, the fact that you're saying the Vega doesn't allow changing palette registers while reading the graphics buffer makes me think that it's halting the CPU and grabbing the pixel/attribute data for the next scanline.
    I don't think that's the issue. If it would were the issue, then things like the Nirvana engine, which allows multicolour tiles, wouldn't work, and they actually work.

    The emulator inside the Vega is designed to recognize a write made to the (emulated) screen buffer and reflect that change onto the real screen buffer, so these multicolour effects work. The same with the border port: it recognizes writes to the port $FE and update the current colour border accordingly.

    BUT the problem is that changing a palette register doesn't involve writting to any emulated screen buffer address, even when changing a palette register may alter the colour of many pixels in both paper and border areas.

    It seems that the emulator does not just have enough time to listen to changes on memory, port $FE and palette registers, and Chris chose to listen to palette changes only between frames, as there are more games and utilities that alter port $FE and screen memory on the fly, than those that alter palette registers on the fly.
  • AH, I think I see what you're saying.

    In the real system, the ULA used a latch to hold color data for each pixel (or maybe it was pixel..can't remember) while the pixel data went to a shift register. I may have that wrong, but bottom line, some IC's to enable the ULA to read both color and pixel data in a much shorter timeframe...WHILE the raster was drawing the pixels.

    But, the emulator simply does not have the bandwidth (or perhaps the SRAM doesn't) to allow reading from those two addresses nearly the same time.

    So, as a sacrifice, Chris chose to slow the color reads down to each frame to allow more time for the pixels and port $FE.

    Hope I understand that correctly.

    Thanks.
  • cbmeeks wrote: »
    But, the emulator simply does not have the bandwidth (or perhaps the SRAM doesn't) to allow reading from those two addresses nearly the same time.

    So, as a sacrifice, Chris chose to slow the color reads down to each frame to allow more time for the pixels and port $FE.

    We don't know for certain what happens inside the Vega. I don't think it's a problem of SRAM bandwidth (actually, SDRAM in the Vega), but with the fact that real hardware does many things at the same time, while in an emulator, all these things must be sequenced to be executed one after another. Seems that the SoC is not fast enough to keep the illusion of several things happening at the same time if there are too much events to be aware of, so Chris had to choose a subset of these events (writes to the screen buffer and writes to port $FE), which would be attended much more frequently than others (writes to palette registers or writes to bit 3 of port $7FFD), which are only attended on the vertical retrace.
Sign In or Register to comment.