09 June 2017, 14:53 | #41 | |
CaptainM68K-SPS France
|
Quote:
CPS games use unified programs and graphic assets, since everything is accessible at the same time during execution. And of course, the original hardware stores everything in ROM, the RAM is specific and used as cache ram to speed up the whole thing. 192kb of "graphic tile metadata ram" is huge. This means more than 192000 words can be stored in this ram. A tile in the CPS system is always coded on word boundaries likes "12FF". The tiles metadata indicates in the specific ram the X and Y of the tile to display by the graphics chip. That's how the printing of a tile on screen is done. the roms containing the graphic tiles is in fact used as a big database. that's what i discovered when i got my hands inside the arcade program of Final Fight when i helped in the making of Final Fight AGA. That's how i discovered that the CPS1 hardware had a custom assistance for the program operations, as well as the hardware/tiles operations, those including the ability to perform rudimentary rotations in hardware. Damnd, the 1st boss of Final Fight has no sprite frames when he is rolling on screen. The CPS1 hardware performs rotations on a specific frames per 90°, and is propulsing the sprites during this event on the whole screen. one of the undocumented registers is responsible for that, since there is no sprite frame built from tiles for that inside the graphic roms. In fact, the Code/data repartition inside the program is like 250kb of code and the remaining is game data (read tiles metadatas). The way the tile metadatas are organised show that the game code use a specific "parser" (in adventure games, a parser is used in a game to recognize specific patterns of events to process, but it can be used too in such games) to process the chained sprites, each with its position in X and Y, his own color palette, and the tile metadata to send to the graphic chips for display. That's how i discovered that Haggar in the coin-op use 80 frames, the bad cop Edie.E use 43 frames, And Damnd something like 45. |
|
09 June 2017, 17:06 | #42 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
In my opinion Amiga 500 or ocs had small unleft things that would done with few costs:
16-32k fast mem for 68000 68000 8 mhz ocs 8 mhz clock enough dma slots to have ham6 in hires asynchronous copper |
09 June 2017, 17:30 | #43 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,357
|
I don't think you can get any more DMA than already available "with few costs".
Regarding 8 MHz 68000, how can the ST have an 8 MHz processor while still generating a colour TV picture? Does it have a separate clock for graphics? |
09 June 2017, 17:58 | #44 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,437
|
Quote:
Which as we know usually uses only half the bus cycles, so it doesn't lose cycles during display DMA. |
|
09 June 2017, 19:03 | #45 | |||
Banned
Join Date: Jan 2012
Location: Serbia
Posts: 275
|
Quote:
Quote:
What about Amiga 500 and chip RAM? MC68000 also can read/write 4MB/s if there is no contention from custom chips on bus/ram? Is speed also 4MB/s? And what is speed of (real) FAST RAM in Amiga 500? Quote:
But, what prohibit in ST design to have e.g. 32colors (5 bitplanes)? There is enough bandwidth for this... |
|||
09 June 2017, 21:53 | #46 | ||
CaptainM68K-SPS France
|
Quote:
On the amiga, the trick is to use the chipset to process all the things that are not related to the CPU role, and by this free the 68000. You can then have a better game logic on the Amiga or do more things with the 68000 while the chipset take care of the graphics and sound. This is why the CPU clocking is "not important" on Amiga, as well as the bandwith. Quote:
They show 40-50 colors at the same time on screen, but you have then 8 frames only per seconds as compromise. that's why even the best programmed games on ST shows visible limitations on screen. (and i'm not specifically talking about Beast....). Just pick Enchanted Lands, or any other game using the ST..... |
||
09 June 2017, 22:42 | #47 |
Registered User
Join Date: Jun 2016
Location: UK
Posts: 428
|
The tile bitmaps are planar, but it's not really relevant... They are generated by software on an X68000 and stored in ROM. The CPU never touches it, and there is no frame buffer or anything like that.
|
09 June 2017, 22:45 | #48 |
Registered User
Join Date: Jun 2016
Location: UK
Posts: 428
|
I think the thing that would really have helped the Amiga would have been better sprites.
|
10 June 2017, 15:21 | #49 | |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,357
|
Quote:
|
|
10 June 2017, 15:23 | #50 | |
Banned
Join Date: Jan 2012
Location: Serbia
Posts: 275
|
Quote:
"A picture is displayed 50 times a second in 50Hz mode (or 60 times in 60Hz). The ST generates 313 lines per picture at 50Hz (263 at 60Hz). In theory, it should generate 312.5 lines, (obtained by successively displaying 312 and 313 lines). It therefore assumes the monitor can tolerate displaying a picture at 49,92Hz instead of 50Hz. This also explains why the ST cannot have a real interlace mode such as that of the Amiga. Each line takes a constant time to be transmitted: otherwise the picture would be distorted. This time is calculated using the following formula: 1 ------------------------------------------------------------- (Number of pictures per second * number of lines per picture) For "Number of pictures per second"=50 and "Number of lines per picture"=312.5, we get 64 microseconds. But some will wonder how come there are 313 lines, if I only see 200 on the screen? The other lines are used by the upper and lower borders, and by the vertical synchronization signal which tells the monitor where the top of the screen starts. Overscan is the process of converting the lines used to make up the borders into lines able to display a picture loaded from memory. I will call "useable screen" that part of the screen not occupied by borders." |
|
13 June 2017, 13:19 | #51 | ||||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,437
|
Quote:
Quote:
Amiga memory speed is more complicated. Up to 4 bitplanes in lowres / 2 bitplanes in hires the CPU is, like the Atari, not slowed down (except on non-4 cycle multiples instructions). Since its clock speed is ~7MHz, the speed is then somewhere near 3.5MB/s. When more bitplanes are used, memory speed goes down (5 BPL=75% speed, 6 BPL = 50%, hires 3 BPL = 50%, hires 4 BPL = 0%), but only during the time bitplane DMA is used. So a 5 BPL 320x256 scrolling screen has the CPU running at ~75% speed of each visible scan line and at 100% for the remainder, or roughly 80% overall. Memory speed for the CPU is further impacted by Audio, Disk, Copper, Sprite and Blitter DMA. Which I haven't included for clarity. Quote:
Quote:
My guess is that Atari didn't want to spend the time and money needed to create a better graphics chip - the one they had was significantly better than the 8 bit chips and consumer level PC hardware as it was and the Amiga wasn't on the market yet. |
||||
13 June 2017, 17:03 | #52 |
Registered User
Join Date: Jun 2016
Location: UK
Posts: 428
|
Thanks for the great explanation roondar.
I think this shows why hardwaresprites are so great. Any kind of blitter object or CPU soft sprite uses lots of scarce memory bandwidth. Save the background bitmap if needed, read the sprite bitmap, write the sprite bitmap, then next frame restore the background. Masses of copying and register programming. With hardware sprites you write a few registers and that's it. You loose some memory access cycles for sprite DMA, but only a fraction as many as blitter/soft sprites. Amiga hardware sprites are quite limited. Games try to make use of them anyway... For example, in Sidewinder the player's bullets are all one sprite, re-used over and over since they can't overlap vertically. A few copper instructions and 68k memory writes instead of multiple blitter operations. I don't know if it even uses sprite DMA... Since the bullets are the same for ever scan line, sprite DMA could be turned off and the buffer registers pre-loaded. |
19 June 2017, 12:40 | #53 | ||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,437
|
Quote:
Hardware sprites are awesome to have (for the time). Systems having hardware sprites vastly outperformed those without just about all the time. Sometimes even beating systems that where released years later (but without sprite hardware). Something like the humble C64 (1982, <1Mhz CPU) kept being relevant all the way to the early 90's, in large part due to it's sprite and scrolling hardware allowing it to do games quite well and without any of the slowdown usually seen on homecomputers. A lot of C64 games clearly run better than their Atari ST/Amiga counterparts (mainly because those tended to be straight ST games, not using Amiga sprite/bob hardware). The same can be seen in the PC-Engine: on paper it should be trounced by the Amiga (much slower CPU, less colours, etc). But it's hardware sprites meant it could compete or outperform the Amiga fairly easily. Quote:
They are also much, much quicker than the Blitter is. Basically, when programming an Amiga game, it always pays to check if you can't use sprites instead of bobs for objects. It's basically a 'free' performance boost. |
||
19 June 2017, 17:09 | #54 | |||
Registered User
Join Date: Jun 2016
Location: UK
Posts: 428
|
Quote:
It's actually very competitive with the 68000 for games. It has the fast zero-page so lots of "registers". The PC-Engine design reduces contention between the CPU and other hardware for memory access slots. The main thing it lacks is multiplication hardware, although the 68000's isn't particularly fast either. But for most 2D games that doesn't really matter, they tend not to use multiply instructions much. But yeah, having those sprites makes it very competitive. Quote:
Or I guess you could re-use a single sprite on a scanline if the bullets are spaced far enough apart and you can sacrifice the copper cycles. Quote:
|
|||
28 June 2017, 09:51 | #55 |
Registered User
Join Date: Jun 2016
Location: UK
Posts: 428
|
Video of the ST port posted:
[ Show youtube player ] Can someone explain how this is possible? I don't know a huge amount about the ST, but there seems to be a lot of sprites and movement on screen at once there. |
28 June 2017, 09:54 | #56 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
|
28 June 2017, 09:54 | #57 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 233
|
|
28 June 2017, 09:55 | #58 |
CaptainM68K-SPS France
|
OK, basically, Anima explained that this is just a test with sprites and background.
But the actual specs are just too high : 32mhz clocked CPU + 14mb of ram. This even in 16 colors ! his goal is to make the game fits with 4mb of ram and 8mhz CPU clock. |
28 June 2017, 09:56 | #59 |
CaptainM68K-SPS France
|
|
28 June 2017, 15:05 | #60 |
Registered User
Join Date: Jun 2016
Location: UK
Posts: 428
|
In 16 colours it might be possible on Amiga, yeah... Ideally with more RAM and a faster CPU as well. I think fast RAM will be necessary just to get enough CPU cycles to run the arcade logic code.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Japanese Console/Computer RPG discussions | Retro-Nerd | Retrogaming General Discussion | 2 | 02 April 2009 01:32 |
Given the recent Scanlines discussions... | DamienD | request.UAE Wishlist | 26 | 26 April 2007 17:36 |
Wii Virtual Console / Xbox Live Arcade? | killergorilla | HOL suggestions and feedback | 2 | 06 March 2007 17:20 |
Landover's Amiga Arcade Conversion Contest | Frog | News | 1 | 28 January 2005 23:41 |
|
|