Hi! thank you very much, I'm glad you like it. Actually I'm making a better layout of the source code because I would like to put on www.c3emulation.com site. As you already have understood this should work as a tutorial/support.
So I hope you will be patient
Concerning the interface, it is not a separate spin library since I'm implementing the strict necessary modules for my future emulator. But I'm seriously thinking to create a spin library you can use for other applications. Of course it will require more work to do. Don't worry I have put it in my TODO list
however this project will be free, and the final version will be available for download on c3emulation site and on my www.sc-3000.com site.
Very nice work. Doing what you are doing is how I started writing different graphics drivers. Taking something that works (but doesn't fit your needs) tear it down, learn from it, build new. The Spintris driver is actually pretty good for that because it isn't overly complex, so it makes it easy to examine, and is a good way to get into multicog graphics programming. And even tho the program does not show it in use, I beleive it also has sprites built in. The TV driver (which was perfected by Baggers) can do both NTSC and PAL with a simple switch.
Very nice work. Doing what you are doing is how I started writing different graphics drivers. Taking something that works (but doesn't fit your needs) tear it down, learn from it, build new. The Spintris driver is actually pretty good for that because it isn't overly complex, so it makes it easy to examine, and is a good way to get into multicog graphics programming. And even tho the program does not show it in use, I beleive it also has sprites built in. The TV driver (which was perfected by Baggers) can do both NTSC and PAL with a simple switch.
Hi! Thank you very much!
Yes I had to start from something, and I found it familiar. I had to have some test so this driver let me do the interface.
I believe that for the emulator I should write a new driver, and make it as simple as possible. The TV driver must have the strict necessary, and the graphic driver need to be fast to render also sprites.
I'm not sure I will use 2 cogs for scanline rendering... now the video part takes 4 cogs, and the other 4 would be taken from main app, sound, z80, and spi... I will probably need one free for input/output handling.
I think the TV driver should be since it is 256x192 pixels, which I believe is what the SG-1000 is rendered at. Since the graphics tiles are 1 or 2 bpp and the sprites are 1-bpp, the graphics driver maybe doable in 2 cogs, and 1 cog for the TV. But I would doubt you could go any lower than that.
I think the TV driver should be since it is 256x192 pixels, which I believe is what the SG-1000 is rendered at. Since the graphics tiles are 1 or 2 bpp and the sprites are 1-bpp, the graphics driver maybe doable in 2 cogs, and 1 cog for the TV. But I would doubt you could go any lower than that.
Yes you are right, the main resolution is 256x192... and video mode 2 has 2 colors each group of 8 pixels, foreground and background so 1bpp, but each tile ( 8 x 8 ) can have different color combinations each row of 8 pixels, I mean something like this:
where each hex nibble is a color code ( 0 ~ 15 ) of TMS9928 for each pixel of the tile:
0 0 1 1 0 0 1 1 ' in a row of 8 pixel I can have only two colors from the 16 color fixed palette
2 2 0 0 2 2 0 0
3 3 5 5 3 3 5 5
...
F F 3 3 F F 3 3
Sprites are 32 of 1 bpp: foreground color and transparent, but 4 max. at once in a scanline.
Probably it should be better to give 1 cog to background and 1 to sprites...
This rendering mode is not so difficult, I've already emulated it, of course in propeller is another thing but I don't think it's an impossible mission
The most common route is to combine a tile/sprite driver into one cog and then replicate that cog X number of times. The theory is that you have each COG rendering a different scanline and buffer them up. It makes it easy to scale too, if your graphics routines takes a long time time to render, set it to use more COGs. If your graphics routines are pretty quick, set it to run less COGs. The nice thing is that since you have a separate TV driver, you don't have to worry about the timing being exact. If you don't dedicate enough COGs and it isn't fast enough to keep up, the screen will just looked stretched vertically.
The most common route is to combine a tile/sprite driver into one cog and then replicate that cog X number of times. The theory is that you have each COG rendering a different scanline and buffer them up. It makes it easy to scale too, if your graphics routines takes a long time time to render, set it to use more COGs. If your graphics routines are pretty quick, set it to run less COGs. The nice thing is that since you have a separate TV driver, you don't have to worry about the timing being exact. If you don't dedicate enough COGs and it isn't fast enough to keep up, the screen will just looked stretched vertically.
Yes I saw it from your engine, and it's really good... I was trying to setup only one cog but graphic seems not to like it It seems to divide the whole frame in two half and interlace them together... Of course it was made to run with at least 2 cogs, but I'm curious and I tried to play with parameters
A weird thing happens when you set cog number to, for example 4, and total cog to 6
cog_total := 4
cog_number := 2
In theory there are 2 cogs rendering, but scanlines seem to be calculated in a different way, this is not a criticism, I'm just figuring out the dynamic of a multi cog renderer.
Hi! I was having some "rest" from the developing of VDP gfx II video mode ( I still have to implement the color table parsing ), when I decided to create a possible main menu.
The VDP driver starts with a tiny version of the JTCook Spintris tv driver, ( I decided to have a low resolution of just 160 pixel to fit in one cog ) . I've assigned a fixed cog number to run each tv driver: GFXII, Text and multicolor JTC drivers. The VDP switches them according to its registers combination.
The boot menu starts by reading graphic tiles from SD card, and reads also a tile table to show the main screen. The thumbnails of games are stored as binary raw files on SD card, and have their sequential code. The same code has been given to txt ASCII files that contain game names.
So when you scroll games, the boot menu loads from SD thumbnail and text of each game.
In this demo when you select a game, a VRAM dump is loaded and the VDP is configured to read proper VRAM locations. So the GFX II mode can show game a title screen, and the BASIC Level III can show main screen.
When you go back to the menu, the main graphic file is loaded again, and the video mode is swiched back.
Thank you guys, in the to-do list there are still several things to build:
the cpu, the SRAM to CPU interface, and the color table handling for the VDP.
But little by little it's nice to see this project growing up
Some time has passed after my last update... Actually I'm planning and studying some possibilities for the emulation.
I'm studying also if there's a way to take advantages from the C3 core, and add some expansion board with peripheral on it ( SEGA Joysticks, Tape Jacks, and a real Cartridge slot ). This requires a lot of time! In this process I've found really, REALLY useful, the PARALLAX Logic Analyzer I've got.
Its amazing in this process because what you know about some hardware, it takes a shape in front of you! So I've opened the SEGA SC-3000 I have, and I could visualize how the Z80 works, ( INTERRUPTS, M1 fetch cycle... ) the VDP signals, DRAM use... I mean... If you are looking for a solution for your emulator or whatever, you have a great help with that!
So, the project is still going on
Well, after a "little" time I made a step ahead on TMS9928 emulation for the SEGA SC-3000 PROPC3 emulator.
Since I'm doing some demos, I've completed te tile engine for graphic mode 0 ( text ), and Graphic mode 2...
fully working but without sprites right now....
Actualy VRAM is on shared memory and the emulation takes 2 cogs:
one for the chip driver ( latch and table calculator ) and the second for the tv driver that handles both video modes.
I will update soon with some news for C3 !!!
These screens are rendered by the driver from VRAM dumps taken from emulators.
I almost thought that you had abondon the project.
uh, no no... II had to make some work, hopefully I can build a demo of the emulator soon.
Now I've just implemented the video mode 1, even if there are really few SG-1000 games that uses it.
So to summarize these video modes are now supported in one cog:
- Video mode 0, text mode, 40x24 characters of 6x8 pixels, 2 color on a screen ( background, foreground )
- Video mode 1, gfx mode 1, 32x24 tiles of 8x8 pixels, 2 color each tile ( background, foreground )
- Video mode 2, gfx mode 2, 32x24 tiles of 8x8 pixels, 16 color each tile, 2 for each row of 8 pixels
Hi,
working on sprites now... I've just updated the main structure of the driver so that it has two cogs that can render two half of the screen to leave space for sprites.
Rendering is made on a double line buffer that is flipped every row read from the tv driver so that the two renderers work in advance for the tv driver. This will leave also time for the Sprites section on the two renderer.
Basically 4 sprites are allowed for each row, according to TMS9928 specs. Actually the TMS9928 emulation will starts the TV driver that handles two dfferent resolutions, one for video mode 0, and one fr Gfx I and II. Then according to the video mode one or two renderers are started.
Three COGS total... The main interface that drives the latch for accessng VDP registers is handled by the main COG.
I will update you soon.
After that I need to "adapt" ZiCOG or QZ80 and hopefully everything should work
I'm eagerly waiting to play some SC-3000 games on my C3. Keep up the good work.
I thought that a really optimized driver would fit sprites and background graphics in one cog. Well it's easier with a 8bpp driver i guess !?!
Well, I could fit in one cog, but no time left for sprites...
The problem is exactly that the relation between tiles and pixel in a 8bpp driver is "1:1", so each byte read from tile table is exactly a pixel, and the waitvid instruction has the "color long" with exactly the bytes read sequentially from the tiletable.
The TMS9928 works differently... In a scanline it has groups of 8 pixels represented by 0 and 1. So that in memory it only needs one byte for 8 pixels. Each bit tells the chip what color use from a palette of 2 ones ( 0, 1 drive foreground and background colors ).
For text mode pixels can be 1: foreground, 0:background taken from color register 7 of VDP. So No need of complex calculations, a byte can be easily transformed in a quaternary value for waitvid instruction dynamic. Then for the "color long" it's the value calculated by the VDP with only two bytes corresponding to the position %%0 and %%1.
Text mode 0 is fast and easy to implement.
For gfx mode 2 things are different and more comlex because each group of 8 pixel has its own palette of two colors, so for each "pixel byte" it's needed to read a byte from a color table. This byte represents 2 colors from the TMS 16 colors palette $[0~F][0~F], high nibble for foreground, low nibble for background.
So there are a lot of steps to reach the "color long" used by waitvid *, #%%3210 instruction.
However, I'm trying my way and hopefully I can implement 32 sprites rendering
Do you have enough time in the output driver for another RDLONG per WAITVID? Then you could have two line buffers - one for background and the other for sprites. Then you combine them before the WAITVID.
Another option is to use COG RAM for a line buffer. There might even be enough cycles during hsync to blit it from HUBRAM.
Thanks for suggestions, actually I has some limits to respect due to the way I decided to follow, so theTV driver of emulated TMS9928 just set video timings and reads the scanline buffer.Two cogs start rendering tiles of background two scanlies in advance respect to TV driver, one render left half the other the right one.
Then the sprites renderer cog just renders sprites over background scanline after the two background renderers go ahead to the next scanline. After the sprites are done the TV driver just read the scanline.The buffer is 4 lines wide ( 1024 byte ).
The two renderers and the tv driver don't interfer each other... When the tile driver is rendering on the next scanline of buffer, sprites are rendered over the previous scanline rendered, then after that the tv driver reads the complete line.This dynamic is driven by the lower 2 bits of the scanline number sent to a renderer 00,01,10,11...the trick is in starting this in advance using three different counters for renderers. Simple.:)
The driver is almost done, sprites are now supported and support MAG1/0 ( pixel with doubled ), Size 8/16 ( resolution of sprite ) Early clock flag ( left shift for horizontal wrapping ), wrapping system on vertical position ( Y alignment ), 4 sprites in a line only, transparent color, $D0 code terminator.Video modes supported are 0: text , 1:Gfx 1, 2: Gfx2 ( multicolor is not supported because almost no game uses that ).
VDP can be programmed by the latching system if you want a microprocessor approach, but if you want to use it in spin, you can directly access to VRAM, where you put it.
Soon I will release this with some news for C3, for now two pictures !
The Propeller TMS9928 emulation driver is becoming stable... needs some optimization but results are really promising.
I've tested this driver with other VRAM dumps...
I've taken two of the most beautiful games written for MSX 1: King's Valley II and Nemesis 2.
These two games are by Konami and use a special sound chip present in the cartridge, the SCC, very simple but nice PSG which can be programmed with some waveforms for its channels... Not so complicated actually. I could emulate it in my actionscrit MSX emulator.
This Chip in addition of AY3910 ( present in MSX ) and a graphic like that make these 8bit games really amazing!
They are really colorful and seems that the VDP has been pushed to maximum performances. Nemesis of course has a lot of sprites compared to King's Valley, and in my tests the driver need to be optimized a bit on sprites rendering. However things are really promising, not only for SEGA SC-3000 emulator but also for other platforms such as MSX, Colecovision and other ones.
Here there are two photos taken from C3 showing VRAM dumps taken from BlueMSX emulator.
Soon it will be the time for Z80 and see all of this in action
Well, I already "knew" that you would be able to pull this off.
We have seen the NES being emulated on the Propeller, so any "lesser" system should be possible to emulate.
The C64 however, even though it's mostly a lesser system in the graphics department, is an overall more complex system than the NES and would be very hard to get to work on the Propeller.
(I didn't say impossible.... )
Incredible... There's bunch of us who suspected that the Propeller could pull this off, but you've actually done it!
Looking forward to seeing this on one of my screens.
OBC
Thanks... the point is that I want to do it because i want to create an emulator, so no way, it has to be done
well everything should finally be tested with a real emulation... but if you want to drive it in SPIN to give Propeller a retro gaming graphic engine, no problems... You can use it anyway and faster by directly accessing the VRAM instead of use the data latch system.
Well, I already "knew" that you would be able to pull this off.
We have seen the NES being emulated on the Propeller, so any "lesser" system should be possible to emulate.
The C64 however, even though it's mostly a lesser system in the graphics department, is an overall more complex system than the NES and would be very hard to get to work on the Propeller.
(I didn't say impossible.... )
/Johannes
So, should be promising... thanks.
I have found this video made by one of BlueMSX emulator authors that explains some features of the TMS9928/9918.
All of these features are implemented in my driver.
Very impressive I can't wait to play with this SC-3000 when its all done!
Andre'
It's time!
Believe or not the SEGA SC-3000 emulation is running on PropC3 board equipped with C3Synapse!
I couldn't wait to show you some video captures from the W.I.P. version of the emulator running three games
Zoom909, Champion Boxing, Othello ( Reversi )
In the next days I will prepare a more detailed video, but now enjoy these short vdeos!
The emulated hardware eats a lot of memory. Since the C3Synapse has been released things are really better for this emulation
Think that 16kb of HUB memory are used by the TMS9928, the qz80 of Pullmoll has been customized for driving the C3Synapse and has been reduced a bit to save space.
Now the code of the PSG has to be reduced more to fit in the emulator program.
Then I have decided to split the IO handler in different little interfaces embedded on each emulated device. So the emulator hasn't any cog that handles the IO, in fact each emulated chip has it's own asm interface to handle access.
Comments
Hi! thank you very much, I'm glad you like it. Actually I'm making a better layout of the source code because I would like to put on www.c3emulation.com site. As you already have understood this should work as a tutorial/support.
So I hope you will be patient
Concerning the interface, it is not a separate spin library since I'm implementing the strict necessary modules for my future emulator. But I'm seriously thinking to create a spin library you can use for other applications. Of course it will require more work to do. Don't worry I have put it in my TODO list
however this project will be free, and the final version will be available for download on c3emulation site and on my www.sc-3000.com site.
Hi! Thank you very much!
Yes I had to start from something, and I found it familiar. I had to have some test so this driver let me do the interface.
I believe that for the emulator I should write a new driver, and make it as simple as possible. The TV driver must have the strict necessary, and the graphic driver need to be fast to render also sprites.
I'm not sure I will use 2 cogs for scanline rendering... now the video part takes 4 cogs, and the other 4 would be taken from main app, sound, z80, and spi... I will probably need one free for input/output handling.
Anyway, thank you for your comments
Sprites are 32 of 1 bpp: foreground color and transparent, but 4 max. at once in a scanline.
Probably it should be better to give 1 cog to background and 1 to sprites...
This rendering mode is not so difficult, I've already emulated it, of course in propeller is another thing but I don't think it's an impossible mission
Yes I saw it from your engine, and it's really good... I was trying to setup only one cog but graphic seems not to like it
A weird thing happens when you set cog number to, for example 4, and total cog to 6 In theory there are 2 cogs rendering, but scanlines seem to be calculated in a different way, this is not a criticism, I'm just figuring out the dynamic of a multi cog renderer.
The VDP driver starts with a tiny version of the JTCook Spintris tv driver, ( I decided to have a low resolution of just 160 pixel to fit in one cog ) . I've assigned a fixed cog number to run each tv driver: GFXII, Text and multicolor JTC drivers. The VDP switches them according to its registers combination.
The boot menu starts by reading graphic tiles from SD card, and reads also a tile table to show the main screen. The thumbnails of games are stored as binary raw files on SD card, and have their sequential code. The same code has been given to txt ASCII files that contain game names.
So when you scroll games, the boot menu loads from SD thumbnail and text of each game.
In this demo when you select a game, a VRAM dump is loaded and the VDP is configured to read proper VRAM locations. So the GFX II mode can show game a title screen, and the BASIC Level III can show main screen.
When you go back to the menu, the main graphic file is loaded again, and the video mode is swiched back.
Andre'
Thank you guys, in the to-do list there are still several things to build:
the cpu, the SRAM to CPU interface, and the color table handling for the VDP.
But little by little it's nice to see this project growing up
I'm studying also if there's a way to take advantages from the C3 core, and add some expansion board with peripheral on it ( SEGA Joysticks, Tape Jacks, and a real Cartridge slot ). This requires a lot of time!
In this process I've found really, REALLY useful, the PARALLAX Logic Analyzer I've got.
Its amazing in this process because what you know about some hardware, it takes a shape in front of you! So I've opened the SEGA SC-3000 I have, and I could visualize how the Z80 works, ( INTERRUPTS, M1 fetch cycle... ) the VDP signals, DRAM use... I mean... If you are looking for a solution for your emulator or whatever, you have a great help with that!
So, the project is still going on
Well, after a "little" time I made a step ahead on TMS9928 emulation for the SEGA SC-3000 PROPC3 emulator.
Since I'm doing some demos, I've completed te tile engine for graphic mode 0 ( text ), and Graphic mode 2...
fully working but without sprites right now....
Actualy VRAM is on shared memory and the emulation takes 2 cogs:
one for the chip driver ( latch and table calculator ) and the second for the tv driver that handles both video modes.
I will update soon with some news for C3 !!!
These screens are rendered by the driver from VRAM dumps taken from emulators.
I almost thought that you had abondon the project.
Nice progress btw!
/Johannes
uh, no no...
Now I've just implemented the video mode 1, even if there are really few SG-1000 games that uses it.
So to summarize these video modes are now supported in one cog:
- Video mode 0, text mode, 40x24 characters of 6x8 pixels, 2 color on a screen ( background, foreground )
- Video mode 1, gfx mode 1, 32x24 tiles of 8x8 pixels, 2 color each tile ( background, foreground )
- Video mode 2, gfx mode 2, 32x24 tiles of 8x8 pixels, 16 color each tile, 2 for each row of 8 pixels
Sprites are not supported yet...
Thank you very much!
I should also make a special version of Z80 to work with this emulator...
I will update you !
working on sprites now... I've just updated the main structure of the driver so that it has two cogs that can render two half of the screen to leave space for sprites.
Rendering is made on a double line buffer that is flipped every row read from the tv driver so that the two renderers work in advance for the tv driver. This will leave also time for the Sprites section on the two renderer.
Basically 4 sprites are allowed for each row, according to TMS9928 specs. Actually the TMS9928 emulation will starts the TV driver that handles two dfferent resolutions, one for video mode 0, and one fr Gfx I and II. Then according to the video mode one or two renderers are started.
Three COGS total... The main interface that drives the latch for accessng VDP registers is handled by the main COG.
I will update you soon.
After that I need to "adapt" ZiCOG or QZ80 and hopefully everything should work
I thought that a really optimized driver would fit sprites and background graphics in one cog. Well it's easier with a 8bpp driver i guess !?!
/Johannes
The problem is exactly that the relation between tiles and pixel in a 8bpp driver is "1:1", so each byte read from tile table is exactly a pixel, and the waitvid instruction has the "color long" with exactly the bytes read sequentially from the tiletable.
The TMS9928 works differently... In a scanline it has groups of 8 pixels represented by 0 and 1. So that in memory it only needs one byte for 8 pixels. Each bit tells the chip what color use from a palette of 2 ones ( 0, 1 drive foreground and background colors ).
For text mode pixels can be 1: foreground, 0:background taken from color register 7 of VDP. So No need of complex calculations, a byte can be easily transformed in a quaternary value for waitvid instruction dynamic. Then for the "color long" it's the value calculated by the VDP with only two bytes corresponding to the position %%0 and %%1.
Text mode 0 is fast and easy to implement.
For gfx mode 2 things are different and more comlex because each group of 8 pixel has its own palette of two colors, so for each "pixel byte" it's needed to read a byte from a color table. This byte represents 2 colors from the TMS 16 colors palette $[0~F][0~F], high nibble for foreground, low nibble for background.
So there are a lot of steps to reach the "color long" used by waitvid *, #%%3210 instruction.
However, I'm trying my way and hopefully I can implement 32 sprites rendering
Another option is to use COG RAM for a line buffer. There might even be enough cycles during hsync to blit it from HUBRAM.
Then the sprites renderer cog just renders sprites over background scanline after the two background renderers go ahead to the next scanline. After the sprites are done the TV driver just read the scanline.The buffer is 4 lines wide ( 1024 byte ).
The two renderers and the tv driver don't interfer each other... When the tile driver is rendering on the next scanline of buffer, sprites are rendered over the previous scanline rendered, then after that the tv driver reads the complete line.This dynamic is driven by the lower 2 bits of the scanline number sent to a renderer 00,01,10,11...the trick is in starting this in advance using three different counters for renderers. Simple.:)
The driver is almost done, sprites are now supported and support MAG1/0 ( pixel with doubled ), Size 8/16 ( resolution of sprite ) Early clock flag ( left shift for horizontal wrapping ), wrapping system on vertical position ( Y alignment ), 4 sprites in a line only, transparent color, $D0 code terminator.Video modes supported are 0: text , 1:Gfx 1, 2: Gfx2 ( multicolor is not supported because almost no game uses that ).
VDP can be programmed by the latching system if you want a microprocessor approach, but if you want to use it in spin, you can directly access to VRAM, where you put it.
Soon I will release this with some news for C3, for now two pictures !
I've tested this driver with other VRAM dumps...
I've taken two of the most beautiful games written for MSX 1: King's Valley II and Nemesis 2.
These two games are by Konami and use a special sound chip present in the cartridge, the SCC, very simple but nice PSG which can be programmed with some waveforms for its channels... Not so complicated actually. I could emulate it in my actionscrit MSX emulator.
This Chip in addition of AY3910 ( present in MSX ) and a graphic like that make these 8bit games really amazing!
They are really colorful and seems that the VDP has been pushed to maximum performances. Nemesis of course has a lot of sprites compared to King's Valley, and in my tests the driver need to be optimized a bit on sprites rendering. However things are really promising, not only for SEGA SC-3000 emulator but also for other platforms such as MSX, Colecovision and other ones.
Here there are two photos taken from C3 showing VRAM dumps taken from BlueMSX emulator.
Soon it will be the time for Z80 and see all of this in action
Looking forward to seeing this on one of my screens.
OBC
We have seen the NES being emulated on the Propeller, so any "lesser" system should be possible to emulate.
The C64 however, even though it's mostly a lesser system in the graphics department, is an overall more complex system than the NES and would be very hard to get to work on the Propeller.
(I didn't say impossible....
/Johannes
Thanks... the point is that I want to do it because i want to create an emulator, so no way, it has to be done
well everything should finally be tested with a real emulation... but if you want to drive it in SPIN to give Propeller a retro gaming graphic engine, no problems... You can use it anyway and faster by directly accessing the VRAM instead of use the data latch system.
So, should be promising... thanks.
I have found this video made by one of BlueMSX emulator authors that explains some features of the TMS9928/9918.
All of these features are implemented in my driver.
[video=dailymotion;x2vj3m]http://www.dailymotion.com/embed/video/x2vj3m[/video]
And here a very interesting documentation on this CHIP
http://www.nouspikel.com/ti99
It's time!
Believe or not the SEGA SC-3000 emulation is running on PropC3 board equipped with C3Synapse!
I couldn't wait to show you some video captures from the W.I.P. version of the emulator running three games
Zoom909, Champion Boxing, Othello ( Reversi )
In the next days I will prepare a more detailed video, but now enjoy these short vdeos!
[video=youtube_share;x6KDIgjXP8M]
[video=youtube_share;MtyiGAF38L8]
[video=youtube_share;V7yjaeorwfU]
Try doing that on ANY non arm equipped microcontroller!
Where is the sound?
The emulated hardware eats a lot of memory. Since the C3Synapse has been released things are really better for this emulation
Think that 16kb of HUB memory are used by the TMS9928, the qz80 of Pullmoll has been customized for driving the C3Synapse and has been reduced a bit to save space.
Now the code of the PSG has to be reduced more to fit in the emulator program.
Then I have decided to split the IO handler in different little interfaces embedded on each emulated device. So the emulator hasn't any cog that handles the IO, in fact each emulated chip has it's own asm interface to handle access.
I will post a more detailed video very soon.