Jump to content
IGNORED

FPGA Based Videogame System


kevtris

Interest in an FPGA Videogame System  

682 members have voted

  1. 1. I would pay....

  2. 2. I Would Like Support for...

  3. 3. Games Should Run From...

    • SD Card / USB Memory Sticks
    • Original Cartridges
    • Hopes and Dreams
  4. 4. The Video Inteface Should be...


  • Please sign in to vote in this poll.

Recommended Posts

HDMI v-sync is 60Hz.

 

And console games of old had their framerate linked to the v-sync as the only way to handle tearing and a horde of other nasty gfx glitches if you don't.

 

Modern games likely use a buffer and decouple the game frame rate generation from video refresh rate, although it works much better when they are in sync.

Link to comment
Share on other sites

Hi guys,

really cool forum! I registered to be able to talk here :)

regarding poll options: what's "Blip"? :)

 

Several thoughts on this project.

 

You probably want a lot of power (AND ram) left for graphical processing to make the image "crt-like". RAM is nice to have anyways, and 8 and 16 bit games don't use a lot of it. You probably want to be able to hold 2-3 or even 6 frames worth in the buffer for slightly more advanced processing. The HQ2X resampling is cool, but it would be cool to have some distortion, noise, striping, leakage, etc that could be applied at will. Those things tend to make the display more interesting.

 

A lot of people are fine with the digital audio output, but some will not be. They would like to have the ability to expand at some point with a board that contains the original sound chips (POKEY, genesis, etc). Such a board would need not only to control the chips but an ADC to put the audio into HDMI.

 

Regarding audio: you tout that there's no noise etc. But often the noise is part of the sound and it actually makes the sound better, not worse.

 

You probably want USB stick because sd cards suck ass. Really, who wants to fuck around with that. I use sd cards every day and i wish to myself "gee, i wish i didn't have to do that".

 

Ethernet: leave it in, even if it's just an unpopulated footprint. On the one hand, people are working on ethernet expansions for old consoles (there's ethernet for the famicom being worked on). Homebrew games will be able to connect to the internet! Fairly exciting. On the other hand, maybe you can then get roms from a network share (if someone is so inclined to write support for that). Finally, people who want to use this as a dev board will be able to do this.

 

I would welcome bluetooth. New controllers do bluetooth and I bet some people would like to be able to use new ones rather than old wired ones.

 

I bet some people will want basic digital I/O, for example to emulate switches, LEDs, or connect the original pads. This could work via your expansion ports. The same goes for peripherals that use the consoles' expansion ports. You seem to want full support for those - does this include Sega CD or the Famicom Disk System?

 

Since you're going for supporting SNES and all its peripherals, would you consider doing Satellaview support WITH being able to play the radio show's audio? I think this would be the first time someone will be able to play BS Zelda on hardware, other than "back in the day". Just this alone could differentiate your system enough to bring in a lot of orders and keep the board very cheap. Also I don't think there are even any software emu's that can play Satellaview roms + the radio show.

 

Regarding the radio show, see here: http://bszelda.zeldalegends.net/bszelda.shtml

 

 

E, Live Voice

BS Zelda's implementation of Live Voice was significantly different to that in BS Zelda: Inishie no Sekiban. When the clock hit certain times the game would pause and display Japanese writing onscreen (that apparently reads "listen"), and the player would hear a narrator (apparently playing the part of the Old Man, and allegedly the same voice actor as Sahasrahla) give a hint or suggestion. Under emulation the pauses are about two to three minutes long, which seems rather long winded and could be a result of faulty emulation (but it's hard to tell really). After that time the text disappears and gameplay resumes as before.

 

 

It would be really cool if your cores supported saving and loading states. This is one thing where emulators still have hardware beat. This is another way in which you could differentiate and make more people interested.

 

Being able to launch a hex editor to edit ram would be cool too.

 

Also, given how well understood the system seems to be, surprised you're not going for the ps1. And after all, it was supposed to just be a SNES peripheral anyways...

 

Edit: I just noticed my gravatar looks like Bodybuilder Mickey. -.-

Edited by cheater
Link to comment
Share on other sites

really cool forum! I registered to be able to talk here :)

 

Same boat here :P

 

You probably want a lot of power (AND ram) left for graphical processing to make the image "crt-like"

 

While I would love that as well, I'm very sure that would result in the costs going sky high, but more importantly, the part you mention next:

 

You probably want to be able to hold 2-3 or even 6 frames worth in the buffer for slightly more advanced processing

 

Yeah, that. Don't PCs already do that? And maybe Raspberry Pi? I wouldn't know about RPi since I don't use that, but I think such features would mean that the Zimba 3000 would be basically a PC, which defeats the purpose of accurate response times, which is the whole point of the Zimba 3000.

Link to comment
Share on other sites

 

 

"You probably want a lot of power (AND ram) left for graphical processing"

 

I'm very sure that would result in the costs going sky high

 

I don't think that's necessary. ram comes in gigabyte sizes now. We're talking about ~ 20-40 MB (edit: was 100, forgot to divide once.. 1920*1080*24 bit color*6 frames/1024/1024 for mega /8 for bytes = 35.6 MB). Plus the additional RAM could, in the future, allow for more advanced consoles and stuff like that. Only kev can figure out how much this would cost.

 

"You probably want to be able to hold 2-3 or even 6 frames worth in the buffer for slightly more advanced processing"

 

Yeah, that. Don't PCs already do that? And maybe Raspberry Pi? I wouldn't know about RPi since I don't use that, but I think such features would mean that the Zimba 3000 would be basically a PC, which defeats the purpose of accurate response times, which is the whole point of the Zimba 3000.

 

No, this is not related at all. Note I said "store frames in buffer" not "buffer output by". The reason games on PCs and modern consoles lag is that their processing is not deterministic, so a single frame might take longer or shorter to render. On average you'll get 60 fps, but sometimes it'll take much longer than 1/60 second to render a frame. If you output frames as soon as they're done, the output is be really jerky and it's terrible. That's why frames need to be buffered. The buffering makes the output less jerky, trading it for a constant amount of lag. However in this case, visual output processing only uses previous frames *as reference* for when outputting the current scanline. For example, to emulate the persistence of phosphor, you need to hold the current unprocessed pixel being output by the core, and a "phosphor state" frame which is updated according to the incoming raw frames, and how phosphor behaves. Basically imagine each pixel is a soap bubble hung up in the air. It'll drop down on the ground on its own slowly (i.e. become black), and if the incoming pixel is bright, it gets blown upwards so it is higher again (i.e. brighter). For each pixel on screen you need one soap bubble. That means you need to hold as many pixels in state as there are on the screen (i.e. one frame). However, each pixel gets updated immediately as soon as the raw pixel comes in, so there is literally zero delay. Similar things hold for blurred margins (which is a really cool way to make a 4:3 image look good on a 16:9 display), or for pincushion distortion, etc. The fact you're holding frames for your algorithm to process doesn't immediately mean delay.

Edited by cheater
Link to comment
Share on other sites

What if you made it fit inside a GameBoy Classic? It strikes me that just the prototype is fairly small already, and I assume a future revision could be even smaller. If you fit that thing inside a GBC, I'm sure a lot of people would be ecstatic. I've seen a really cool mod that puts a raspberry pi in the GB, adds X and Y buttons, and R/L buttons on the back.

 

Here it is:

 

I don't know what the power consumption of an FPGA is, so I can't comment on that, but it seems to me like a lot of space would be left for multiple mobile phone batteries.

  • Like 1
Link to comment
Share on other sites

I'll also have a much nicer font and menu system- that one was severely limited by the amount of RAM available on the FPGA, or lack thereof. The entire font had to fit into 1K, and the entire nametable is 1K also.

 

I believe some early terminals used fonts where they reused parts of letters for other letters. This kept the font size low and detail high.

Link to comment
Share on other sites

 

They were emulated internally but all the emulator commands were statically recompiled to C. It behaves exactly as an emulator would, but without there being any actual emulation code in the shipped product. We believe emulation is the best approach for republishing NES games, but clients kept telling us that we weren't allowed to emulate a Nintendo system (which is bunk), so we came up with a solution that did the exact same thing but with no "emulation" on the user end.

 

So the systems were 'pre-emulated' and there's no original ROMs on the disc, just the resulting 'emulated' commands native to each platform?

Link to comment
Share on other sites

The fact you're holding frames for your algorithm to process doesn't immediately mean delay.

Ahhhhh, I see, this is something I've never heard about, mainly because I'm not a programmer :P

Well, again, i'm all for an HD CRT-like filter. I actually spend a lot of time sometimes creating mock up screenshots of how a CRT filter would look like Basically something like this: http://i.picpar.com/6gFb.png

or like this for rounded screens, though this has like 2 scanlines per pixel lines.: https://marketplacecdn.yoyogames.com/images/assets/701/screenshots/1808_original.png?1410907348

 

(I didn't make these, obviously)

Edited by veelk55
Link to comment
Share on other sites

i'm all for an HD CRT-like filter. I actually spend a lot of time sometimes creating mock up screenshots of how a CRT filter would look like Basically something like this: http://i.picpar.com/6gFb.png

or like this for rounded screens, though this has like 2 scanlines per pixel lines.: https://marketplacecdn.yoyogames.com/images/assets/701/screenshots/1808_original.png?1410907348

 

(I didn't make these, obviously)

 

You're missing a lot of stuff there. Basically your pixels are solid and contiguous lines, which is not how it works on a real CRT. you're also missing fading, noise, etc.

 

Look at this video:

 

 

Just look at one of the stills.. It's at 2:08. Make sure to click it to see it in full screen mode.

 

KoUWw3e.png

 

The background is done like you would have done it. They took a raw emulator image (some sort of cave), and scaled it up using a simple scaler. Blah. Boring.

The insert is an actual photo of a CRT running I believe Metal Slug. See how much more detailed this is. Notice how every pixel is a small dot in its own right, and the pixels that are less bright are actually smaller. Each pixel is fuzzy. Each pixel, as you look at it, "sizzles" a little because it rapidly changes shape due to noise. The brightness of the pixels changes a little, it "blooms" due to the inefficiencies of the power supply of the CRT. This imperfection actually makes the display more vivid, because suddenly instead of say 16 colours you have an infinite amount of colours because the colour of the physical pixel is somewhere between where it should be, and between where the last pixel was. Then there's the fact that you're scaling up pixels as a whole, instead of scaling the components. On a CRT, you'd have a red pixel, then a green, then a blue pixel, or some similar pattern, but this is easiest. To scale a bit more faithfully, you'd resize them one by one, that is, you'd have a few red-only pixels, then a few green-only pixels, then a few blue-only pixels, and those three groups would make up one pixel of the original unscaled image.

 

Then you have things like leakage (i.e. one pixel affecting further ones). You have noise. You have errors in colour transport. Stuff like that seems like "omg crappy imperfect stuff" but really it adds a lot to the character of the display and at least imo was a large part of the appeal. But as you see there's much more to it than just scaling up pixels to be larger solid rectangles, and adding a blank purple line between the existing lines every now and then.

Edited by cheater
  • Like 1
Link to comment
Share on other sites

Oh yeah, those pics are indeed missing a lot CRT details :D

I had no better examples to show, but I've seen better being done for an emulation project I saw once.

There's a complication with this though...

To be able to satisfy everyone, one would need to create about 3 different filter for each system since the NES didn't have the same artifacts as a Genesis, or the SNES.

And each one looks different depending on the type of cable you use. An NES and an SNES would also not look the same even with the same cable!

I wouldn't dare asking for something like that. But Nestopia has a nice NTSC filter that makes it look almost like my TV with the NES.

I'd like options like that with saved profiles for different cables / systems.

 

Another thing is that maybe, just maybe, 1080p might not enough to truly bring a filter like this to justice.

 

This is one of the mockup screenshots I created:
https://s5.postimg.org/dwipl45fr/snakeman.png

 

It's not complete, and it's not meant to look as dirty as the original system (Which would be cool if I could do that as easily as I created that screenshot), but in here you begin to see something I wanted to replicate in an HD CRT look, I don't know the name of this but do you notice where the white pixels have some red to the sides? Something like that.

 

When I load an image with that filter on my phone, it looks exactly like the type of filter I would wish to have :D (Looks similar to a 3DS top screen, but a little bit more like a TV)

Edited by veelk55
Link to comment
Share on other sites

There's a complication with this though...

To be able to satisfy everyone, one would need to create about 3 different filter for each system since the NES didn't have the same artifacts as a Genesis, or the SNES.

And each one looks different depending on the type of cable you use. An NES and an SNES would also not look the same even with the same cable!

I wouldn't dare asking for something like that. But Nestopia has a nice NTSC filter that makes it look almost like my TV with the NES.

I'd like options like that with saved profiles for different cables / systems.

 

You're overthinking this.

Any such filters are by definition configurable.

They don't have to reflect any specific cable or output stage. They just have to look cool. And if you don't like them, turn them off or change parameters.

 

 

 

 

Another thing is that maybe, just maybe, 1080p might not enough to truly bring a filter like this to justice.

This is one of the mockup screenshots I created:
It's not complete, and it's not meant to look as dirty as the original system (Which would be cool if I could do that as easily as I created that screenshot), but in here you begin to see something I wanted to replicate in an HD CRT look, I don't know the name of this but do you notice where the white pixels have some red to the sides? Something like that.

 

No, 1080p is enough. Even for the pixel component filter you had there. That's what I was talking about earlier, scaling up separate components. That is what i meant.

 

PS if you don't quote my post, I won't know you replied to me, because then I don't get email notification.

Link to comment
Share on other sites

You're overthinking this.

Any such filters are by definition configurable.

They don't have to reflect any specific cable or output stage. They just have to look cool. And if you don't like them, turn them off or change parameters.

 

Lol yeah... I tend to overthink. Yeah, if it was configurable it would be ideal! I wouldn't know since I haven't used filters like these.

 

You're right about 1080p, as long as it's scaled to an exact 5x, then cropped a few lines vertically, since TVs generally cropped these as well :P hadnt realized that it was that close!

 

Do you have a screenshot with a CRT-like filter you'd like to use?

Edited by veelk55
Link to comment
Share on other sites

 

Lol yeah... I tend to overthink. Yeah, if it was configurable it would be ideal! I wouldn't know since I haven't used filters like these.

 

You're right about 1080p, as long as it's scaled to an exact 5x, then cropped a few lines vertically, since TVs generally cropped these as well :P hadnt realized that it was that close!

 

Do you have a screenshot with a CRT-like filter you'd like to use?

 

You can do 4.5x directly by using jitter, averaging, or using different scanline arrangements.

 

I don't have a good screenshot but what you posted is the first step in the right direction:

 

snakeman.png

 

https://s5.postimg.org/dwipl45fr/snakeman.png

 

First of all, you'd need to make darker pixels smaller

 

Second off, doing RGB directly isn't great. You need the brightness to modulate the colour hue and saturation, like on a physical display. I don't know what the curve is, but the relationship isn't linear. Something for kevtris to figure out. I think the brightest spots are the least saturated, and also I believe the different pixel components (R, G, B) have a slightly non-linear relationship to the input and they differ because of different phosphor. Something like for example R_out = R_in^0.8 * 0.95 where R = 0...1, then G_out = G_in^0.85 * 0.95 and B_out=B_in^0.65 * 1.2, I'm only guessing those numbers, they're probably wildly incorrect and the curves are more complex than quadratic, actual measurement with a monitor calibration sensor is necessary. I bet someone has measured a CRT at some point (e.g. one of the sony professional video monitors or broadcast video monitors in the RGB 204 video I linked to earlier) and there are curves in a document somewhere out there.

 

Then you need persistence and that is one thing that requires a lot of ram.

 

Then you need fading and blooming. In a CRT, there's an electron beam that comes out of a single power supply. That is a single signal that is modulated to make brighter and darker pixels. So if you have an RGB raster then if R is very bright and G is supposed to be very dark, then G will not be as dark as it should be. This all depends on the frequency response of the power supply voltage modulation scheme. If the modulation is very fast (= large bandwidth), then the picture is going to be very good. If the modulation is slow, the brightness will smear so that makes colours tend towards white (the center of the colour wheel) and away from the extremes of the colour wheel. If the frequency response near DC is bad, because you have e.g. leaky capacitors (which they were even if new) you'll have fading, which means if a system tries to be bright for a very long time, it'll be bright at first but then it'll die down a bit towards a slight bit darker.

 

The way this signal is modulated comes from the signals you supply. So the RGB or YPbPr or composite or RF. This has some issues too. RF has the largest issues with bandwidth, composite less but still a lot. This means the issues i described above with bandwidth can come from the cable type used as well. Another issue is: when demodulating the signals, at some point they will pick up noise or go through non-linearities that all change how the colours show up in the end. In specific noise adds a lot to how "real" the signal seems by giving it a texture and animation, whereas non-linearities make the colours richer and less "plasticky".

 

Another issue is, if you have an impedance mismatch somewhere in the signal path your signal will bounce around in a cable. This is called a partial reflection. This gives you ghosting.

 

You can understand reflections by watching this video, he explains the effect about 14 minutes in and goes on for about 10 minutes:

 

 

All of those things can be simulated in real time as look-up tables or IIR filters or FIR. All of those effects mean that, unintentionally, a system that only outputs 16 colours will, through analogue imperfections, end up displaying millions of colours. That makes a very big difference. These effects were used by game designers who made things look good on a CRT, taking into account the effects. A basic example is the "transparent" waterfall in Sonic. It's not transparent, it's just stripes of colour:

 

9RkDX4u.png

 

http://i.imgur.com/9RkDX4u.png

 

On a CRT this looks like real transparency because the low bandwidth of the electron beam means it can't jump from blue (i.e. the water overlay) to whatever colour you have on the next pixel (e.g. the green of the grass "behind" the water). It mushes them up a bit and it looks pretty good.

 

Bear in mind you might want to try out different pixel component arrangements.

 

Pixel_geometry_01_Pengo.jpg

Edited by cheater
  • Like 2
Link to comment
Share on other sites

HDMI v-sync is 60Hz.

 

And console games of old had their framerate linked to the v-sync as the only way to handle tearing and a horde of other nasty gfx glitches if you don't.

 

Modern games likely use a buffer and decouple the game frame rate generation from video refresh rate, although it works much better when they are in sync.

Oops, I meant 'Adaptive V-Sync', so the fpga console can pick any refresh rate needed for the emulated console.
Link to comment
Share on other sites

Oops, I meant 'Adaptive V-Sync', so the fpga console can pick any refresh rate needed for the emulated console.

HDMI does not support it, as such if you want to decouple the 2 (console refresh from actual screen refresh) you end up with a buffer -> lag (if the console is slower than 60Hz there's not a complete image at the end of the current frame to display hence it needs to be buffered first and be displayed in its entirety on the next frame)

Depending on how different the frequencies are you also end up having to duplicate/remove a frame here and there not unlike the 3:2 pulldown of DVD players for NTSC ... although more like a 60:59 or alike.

 

Hence the small speedup of the console clock seems acceptable.

Link to comment
Share on other sites

 

Do you have a screenshot with a CRT-like filter you'd like to use?

 

This thing has a nice CRT emulation:

 

 

Also check out the "TV simulation modes" here. The video is long but it's the first thing they talk about after the intro:

 

Edited by cheater
Link to comment
Share on other sites

 

You can do 4.5x directly by using jitter, averaging, or using different scanline arrangements.

 

I don't have a good screenshot but what you posted is the first step in the right direction:

 

snakeman.png

 

https://s5.postimg.org/dwipl45fr/snakeman.png

That screengrab is gorgeous. Is this a crop from 1080p image?

  • Like 1
Link to comment
Share on other sites

I don't have a good screenshot but what you posted is the first step in the right direction:

Ahh I'm glad to hear this!!

 

 

First of all, you'd need to make darker pixels smaller

This might be possible through coding. There are a lot of things people do with coding that I can't just do in photoshop, like how one pixel affects the other, and depending on its color, etc. Pretty much everything you explained about how a CRT works :P

 

 

That screengrab is gorgeous. Is this a crop from 1080p image?

Thanks! And no, it was somewhere above 1300 pixels.
That's before I realized that it could be done in 1080p almost the same way with little or no problems.
This is just a photoshop mockup picture I did as an experiment to see how a CRT filter would look in HD TVs and on smartphones.
I just realized this needs some further adjustments too but sadly none of what 'cheater' suggested due to this being just simple photoshop.
Basically my goal is just to paste a screenshot of a game under a bunch of layers without doing anything to it so I dont have to manually alter each picture.

 

If I may, what was the advantage to go that route?

Didn't they explain that emulating Nintendo on non Nintendo hardware was not acceptable?

And also I'm assuming that this way it would also prevent people from exploiting it to run NES games.

I would really not want anyone exploiting MegaMan Legacy Collection just to play Battletoads >__> but that's my opinion.

 

Unless there were any other possible routes to do this collection that doesn't involve really making the games again from the ground up.

 

 

Edited by veelk55
  • Like 1
Link to comment
Share on other sites

Ahh I'm glad to hear this!!

 

 

This might be possible through coding. There are a lot of things people do with coding that I can't just do in photoshop, like how one pixel affects the other, and depending on its color, etc. Pretty much everything you explained about how a CRT works :P

 

 

Thanks! And no, it was somewhere above 1300 pixels.
That's before I realized that it could be done in 1080p almost the same way with little or no problems.
This is just a photoshop mockup picture I did as an experiment to see how a CRT filter would look in HD TVs and on smartphones.
I just realized this needs some further adjustments too but sadly none of what 'cheater' suggested due to this being just simple photoshop.
Basically my goal is just to paste a screenshot of a game under a bunch of layers without doing anything to it so I dont have to manually alter each picture.

 

The 5x6 aspect mode in 1080p would be perfect for this. The rgb mask would fit exactly twice per pixel horizontally and you'd have space for roughly three bright two dark on the scanlines, or one dark, one half bright, two full bright, one half...

 

One issue with emulating a true CRT mask is that the image becomes ultimately 1/3 of full brightness for the display using discrete color domains. Somehow you managed to overcome this with your filters. Another issue with CRT mask would be driving a modern 4k OLED screen like this would ultimately result in a yellow honeycomb effect due to uneven wear of blue pixels. Uneven burn in could be mitigated somewhat by alternating even/odd scanlines and cycling the positions of the RGB domains.

Link to comment
Share on other sites

One issue with emulating a true CRT mask is that the image becomes ultimately 1/3 of full brightness for the display using discrete color domains. Somehow you managed to overcome this with your filters. Another issue with CRT mask would be driving a modern 4k OLED screen like this would ultimately result in a yellow honeycomb effect due to uneven wear of blue pixels. Uneven burn in could be mitigated somewhat by alternating even/odd scanlines and cycling the positions of the RGB domains.

 

Loool yes, I made it as bright as I could because originally the results were too dark. Thing is, it's not just a simple mask sadly. Im using a few Photoshop unique features in that filter that manipulate colors behind the "mask".

In the end though, say something like this was possible and already working in the FPGA system, but it looked dark. I wouldn't mind turning up the brightness :P I've done this for some things. But that would be impractical for almost everyone else.

 

Oh wow is OLED that bad for this? Had no idea.

I'm not sure I've had much experience with OLED screens besides my model 1 Vita, and I hate that screen. At least in the way that Sony made it work with the Vita. The lowest brightness is just not dim enough and I can only play it in a very bright environment, or it's gonna hurt me.

Link to comment
Share on other sites

 

Loool yes, I made it as bright as I could because originally the results were too dark. Thing is, it's not just a simple mask sadly. Im using a few Photoshop unique features in that filter that manipulate colors behind the "mask".

In the end though, say something like this was possible and already working in the FPGA system, but it looked dark. I wouldn't mind turning up the brightness :P I've done this for some things. But that would be impractical for almost everyone else.

 

Oh wow is OLED that bad for this? Had no idea.

I'm not sure I've had much experience with OLED screens besides my model 1 Vita, and I hate that screen. At least in the way that Sony made it work with the Vita. The lowest brightness is just not dim enough and I can only play it in a very bright environment, or it's gonna hurt me.

I don't own any OLED display devices, but have only heard horror stories of ruined screens on various smart devices and HDTVs. It was bad enough that Sony switched back to LCD on subsequent Vita models. A big issue with HDTVs is watching pillarboxed or letterboxed content over time will lead to a picture with different tint in the center as opposed to the borders. I am extremely sensitive to colors so any defect like this would become immediately apparent.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...