I already have 1024 x 424 on my gfx9000s 
I already have 1024 x 424 on my gfx9000s
What software do you run in this mode? Imagine PACMAN and LOADRUNNER at this resolution
Right now on Procyon the maximum tested thing is 1280x1024 24bpp, and this seems to be the limit for a moment. The problem is that it will take ages to draw a line in this mode for Z80 with memory mapped VRAM access. So, some sort of object oriented GFX language should be used between the card and Z80, IMHO.
Ooooh... just found this precious thread. I want one! Need one!
The problem is that it will take ages to draw a line in this mode for Z80 with memory mapped VRAM access. So, some sort of object oriented GFX language should be used between the card and Z80, IMHO.
Hi maxis, i fully agree, sometimes the memory mapped question pop up in more discussion like a one-solution-to-all-problems.
The real issue is that for a 8 bit CPU a screen like v9938 screen 5 is already big to manage. So a kind of hw assistance is what is needed, not the always mentioned direct VRAM access. The lack of direct VRAM access is somewhat over-estimated but pretty decent speccy ports, that are CPU-VRAM intensive, prove that is not so bottleneck as people say.
In my wish list there is a V9938/58 full core replacement, but i see that you have put also the Sega SMS vdp core in your roadmap, so i think the SMS have the priority over the V99x8 core. I'm right?
The lack of direct VRAM access is somewhat over-estimated but pretty decent speccy ports, that are CPU-VRAM intensive, prove that is not so bottleneck as people say.
Yes, I do agree, and "via port" access method could be very efficient too with the tile/sprite graphics. The video RAM is overcharged already with the display bandwidth, so having a separate program RAM is the advantage, especially for the LOW RES.
And, IMHO, the balanced continuation of the MSX-1 video platform is SMS for many reasons. And the best part of it is the color clash free tile/sprite graphics with H/V pixel scrolling. IMHO, ASCII pushed YAMAHA towards business graphics, however YAMAHA seemed always to have a recipe of how to build the most optimal video processor (personal opinion).
Hence, I'd like to understand better the design details and its evolution. The best way to learn it is to build it. So - after the full 9918 functionality (actually this is the command engine free 9958), try to design SMS/GameGear.
Also, do really miss PoP port badly on MSX. Will be lots of fun if works correctly.
And, IMHO, the balanced continuation of the MSX-1 video platform is SMS for many reasons..
I think this evolution is only a "removal of limitations" in the original TMS9918. they recognized the most limiting factor of 9918 TMS:
- Lack of hw scroll
- Extremely limited sprites
- Colour Clash
They improved/removed the weak points. Nothing more.
keep in mind that sega pushed VDP versus game features. Effectively on SMS vdp you cannot have a full screen bitmap on multicolored tiles due to lack of memory. A thing that on monochrome screen 2 the TMS is able to do. But on the game perpective this is not a big limit.
The true way was the V9938/58 (bitmap gfx) as done by Yamaha as the future taught. Look at amiga/atari. they have stunning gfx and they do not have tiled modes.
But having a true bitmap force also to have a very FAST blitter. Unfortunately this was * not * the case of V9938.
Also the lack of hw scroll registers on v9938 does not help...
Pratically Yamaha made the things only at half.
There are ( to me ) some obscure points in V9938. Some things (like screen 4, a screen 2 with enhanced sprites) and the missing hw scroll register made me think that v9938 is a pre-release of what should have been the msx2 vdp: the v9958.
Later, IMHO, they completed the original design adding some features, mostly the 19000 colour mode and the ability to execute blitter commands on non bitmapped screen + the cpu wait feature.
The true way was the V9938/58 (bitmap gfx) as done by Yamaha as the future taught. Look at amiga/atari. they have stunning gfx and they do not have tiled modes.
Interesting. IMHO, it is really difficult to say definitely about Amiga trend and its future success. Thinking of A1000 this is the indigenous and super price/performance optimized machine to do just the video games. Why having tiles, if we can reload video DMA by the copper every 32 pixels (just one step further from Atari 800 display list and tiles/sprites)? Also planar graphics is the thing, which started the Amiga success, and IMHO, killed AGA/AAA chunky emulation performance. The original Amiga was based on the precise multiplex of a single port 16 bit RAM for all the needs.
Purely looking at the VRAM bus, IMHO, neither 9938 nor 9958 were really meant to be the gaming superstar. Both are lacking the bandwidth very badly, resulting in no throughput for the BLITter.
SMS, on the other hand, has the fast bandwidth due to the 16 bit memory organization and the full random access instead of the fast page mode on 9938 8 bit VRAM bus. This is the strategical decision, which ASCII made to imitate a PC like business machine but on cheap(private opinion).
But also, an interesting thing is that SEGA GENESIS video subsystem (designed in 88 by YAMAHA) is a step forward from SMS and 9958. Also despite the slow dot clock, the memory bandwidth is 4x faster thanks to the real dual-port VRAM (well before 9990)! Tile based graphics was killed by 3D gaming, but then processors could transfer the data at 20M DWords/s to the VRAM memory at QVGA resolution (not our case).
That's the point, tile based gfx are like hw sprites. They are a trade off used when the hw simply could not manage a large amount of memory in a single frame. Despite the 'fans' of tiled gfx & hw sprites there are a lot of limitations, compared (if a hw can afford) with a high speed blitter and vram planar/chunked memory . Think about a common game scenario. You have a SMS like HW and you need to implement a smoothly moving big end-boss. Alternatives:
- Sprites. Not feasible. you run out of resources because of the big monster or you get into the flicker nightmare.
- Tiles: you can use them, but forget smoothness. Also tiles are somewhat a limited resource in number...
In the end you cannot do a good tradeoff. With true bitmap gfx + fast hw acceleration you can do a more flexible trade off. Say. the game run smoothly at 60fps except for the big end boss? OK. I tradeoff the speed, lowering to 30fps for the ability to display a big monster or i can make all sw sprites @60FPS except the big monster @20fps for example. Gfx quality is the same, no blocky scroll or flickering. I'm just using in a MORE FLEXIBLE way, allowed by software, what is the overall power of my hw.
For example think about some ZX spectrum arcade ports. speccy does not have HW sprites or tiles, the main CPU has to do all the job ( bad! ) resulting often in low framerate (because of lack of power). But having the ability to manage gfx without sprites+tiles allow me to reproduce the main charater more like the original arcade (sure in B/W, but is the concept that matters here.). By contrast, C64 is LIMITED with its 24x21 size. And if i need a 50x10 size? Then i need two sprites, leaving ONLY 6 sprites left. please take into account that a 24x21 and 50x10 size are almost equivalent if we consider the amount of bytes to blit...
Last a question about V9990. Yamaha engineers choose to remove sprites support in not tiles mode. this allowed the blitter to accelerate a lot ( the command speed is very low in tiled modes ). Effectively, one can do a game in non-tiled modes by using only blitters and scroll registers+sw sprites. You gain color, details and THE FREEDOM to manage every single drop of power.
Also AMIGA engineers recognized this, as proved by the sprites implementation of amiga. They flavoured the blitter instead of the hw sprites in terms of size, number, and color abilities.
Karl Guttag ( creator of TMS9918 ) also recognized this and moved to sw implemented sprites with hw assistance
With true bitmap gfx + fast hw acceleration you can do a more flexible trade off
Yes, exactly. This is my vision also, however the one would have to develop the SW for it.
But since your question was about the roadmap, my first goal is simple - attempt to make a bridge into a different universe (SMS/Spectrum/CPC/Z80 arcades, etc) and bring the gaming scene onto the MSX platform (also test the card performance to the limit). This is already brilliantly done by SUPERSONIQS for SMS, however, I'd like to add the HDMI touch to it and see what can be done on top of that.
For instance, we say - SPRITE FLICKER - so, in fact with the huge memory bandwidth it is possible to put all the sprites on the same scan line and have them all visible. Would this improve anyhow the game? Why not to test it. And the additional SW is almost not needed in this case. Also GAMEGEAR has a very low res. What if to upsample the image and add a gaussian filter, would it be less squary?
The same with SPECCY port. Instead of doing SMS, could knock off a SPECTRUM128 clone(goes together with Z80 inside the card). However, in this case, TRDOS emulation of some sort must be developed (requires more time).
But, honestly, I would prefer to concentrate on the YAMAHA based products first.
Do you have any other suggestions what would be the best possible emulation (preferably Z80 based), maybe the arcade platform of some sort?
no, suggestions. my first wish is to have something like F18A (see http://codehackcreate.com/archives/30 ) replacement (in cartridge) but for V9938/58 core, with few enhancements like you said (blitter speed, a lot of sprites), but with the main requirement how being extremely hw accurate to the original chip when used in old "vintage mode".
Another interesting thing i would add is a screen 4 tiled mode with tiles made up of screen5 bitmaps. this should allow to convert existing screen4 games by working with tiles but instead with no colour clash tiles... from a sw point of view the work would be only to change the tiles and the game stay the same.
About VRAM access model there is a work already done to know how vdp accesses VRAM and the timings of blitter state machine. have you checked http://www.msx.org/news/en/v9938-vram-access-reverse-engineered and http://openmsx.sourceforge.net/vdp-vram-timing/vdp-timing.html ?
