18 July 2017, 12:42 | #201 | |
Registered User
Join Date: Jun 2016
Location: UK
Posts: 428
|
Quote:
The unreleased PC Engine port is an interesting example. 2MB RAM and a more powerful tile/sprite engine than the Amiga. The CPU is 8 bit, but most of the instructions are one or two cycles and it runs at around 7MHz IIRC so for that kind of game it's probably faster than a similar speed 68000. The 68000 is really a workstation CPU. It's powerful and good for running C code, but because every instruction takes multiple clock cycles and the max clock speed isn't that high, for games a CPU that has a much higher IPC (instructions per clock) is better. For comparison, at 8MHz a 68000 is about 1.4 MIPS, while a 65C02 is about 3.44 MIPS. Plus the 65C02 instruction words are shorter so less memory bandwidth is needed just for instruction fetching. 68k instructions can do more, but for games that's not necessarily that useful. |
|
18 July 2017, 13:03 | #202 | ||
Amiga warrior
Join Date: Jul 2017
Location: Australia
Posts: 64
|
Quote:
Quote:
I would have loved to have seen arcade perfect Strider conversion with full 50fps parallex scrolling and sprites. I don't see what is so bad about making games for OCS/ECS to take advantage of extra fastRAM? The Atari guys are doing it with 4MB RAM board after all. It's not stock. And 12MB... for that money you could afford an A1200 back in 1992, so there's no point using 12MB UNLESS Amiga ports can also use 8MB fastram. |
||
18 July 2017, 13:13 | #203 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,357
|
|
18 July 2017, 13:29 | #204 | |||
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,157
|
Quote:
Quote:
Quote:
There are exceptions, though - Zeewolf 2, for example, is much improved on a machine with true Fast RAM. |
|||
18 July 2017, 13:41 | #205 | |
Amiga warrior
Join Date: Jul 2017
Location: Australia
Posts: 64
|
Quote:
EDIT and about Amiga chips not accessing all of RAM, as has been discussed previously in the thread there are solutions to that, copying data between chipram and fast ram, keeping the executable outside of chipram, only holding data in chipram that the chipset needs to work on. You have 2MB to play with, it's plenty. |
|
18 July 2017, 13:47 | #206 | ||
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,157
|
Quote:
Quote:
|
||
18 July 2017, 14:01 | #207 | |
Amiga warrior
Join Date: Jul 2017
Location: Australia
Posts: 64
|
Quote:
Also, some Amiga ram board accepted SIMM's also |
|
18 July 2017, 14:51 | #208 | |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
Quote:
There's some debate whether it can be split level by level down to 4 meg of RAM. It might require buffering as I mentioned in my post. Your possible choices are a) caching to chip + frequent loading screens whilst data is buffered from fast b) drawing all masked graphics with the CPU c) Buffering data dynamically between fast and chip a might not be feasible depending on how the assets are used. b is going to be hideously slow versus using a blitter (8x slower than the STe?) c is going to be 2.5 to 3x slower clock for clock than the ST version I'll be explicit here. Fast RAM *cannot* be accessed via the custom chips on the Amiga. The blitter can't access it. The only chip in the Amiga capable of accessing the full addressing range is the 68k. A 68000 can't draw sprites efficiently. It requires preshifting. Preshifting requires an extra column for each sprite and 16 copies of the sprite/mask data. On the ST both the blitter and the CPU can access everything in the 24 bit range. Ie all 16 meg of it including RAM, ROM, Alt ram above 4 meg and memory mapped IO address space. |
|
18 July 2017, 15:21 | #209 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
Since Amiga have blitter is better to use it for drawing bob, and left cpu doing cpu staff. I remember when I add A590 to my Amiga, the whole seems to run 2x faster!
|
18 July 2017, 15:28 | #210 | |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
Quote:
It was retrofitted to original ST machines. It's supposed to act like a 68000 on the bus. A combined fast RAM blitter card would be cool. Crazy but cool The other option is someone clones the Amiga one and makes it a proper bus master. Make it available with a fast RAM card. That would open up the 500 to all the games possible with this technology. Would be great for Workbench too. Fonts and background patterns could be stored in fast RAM. The Amiga port of EmuTOS could use either one for the VDI interface. I'd pay money for either option! |
|
18 July 2017, 15:32 | #211 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
In my opinio OCS chip set was an unfinished project.
|
18 July 2017, 15:46 | #212 |
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,157
|
I'd have to disagree there - given the limitations of technology, memory speed and cost at the time, and compared with everything else of the same era, the OCS chipset is remarkable. It should certainly have been developed further, but it was largely a victim of its own success - the whole system was designed and integrated very tightly, so making incremental improvements is very difficult.
I do seem to remember reading somewhere that the chipset was originally intended to have a YUV mode, though - and that's what HAM mode was originally intended for. YUV was scrapped but HAM remained. I can't find any reference to this now, though - was I imagining it? |
18 July 2017, 16:25 | #213 | |||
Amiga warrior
Join Date: Jul 2017
Location: Australia
Posts: 64
|
Quote:
Are you really sure that's true?? It really seems amazing to me if it's true..... and doesn't explain why Amiga games are so much better than ST Quote:
Quote:
|
|||
18 July 2017, 16:27 | #214 | |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
Quote:
|
|
18 July 2017, 17:14 | #215 |
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,157
|
32K of fast RAM would have been great - or even better, making the trapdoor slot into real fast RAM - but I don't think even that would have opened up enough DMA slots to do hires HAM6.
|
18 July 2017, 17:46 | #216 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,438
|
Quote:
Quote:
And after transfer, you'd obviously not use the CPU for drawing. It would be relatively easy to transfer from fast to chip at a much slower rate than the peak, just enough to satisfy what is needed in the for the current frame and the near future. The total memory requirement would not change, obviously, but you don't have to transfer all data across all the time. As a quick back-of-the-envelope kind of thing: The maximum number of tiles you'd need to transfer the definition of at any time would be roughly 30 (assuming 8x8 tiles). At 16 colours, that is all of 960 bytes and that is assuming there are no tiles at all available in chipmemory at the time that can satisfy the new tiles that need to be drawn (which is exceedingly unlikely). The maximum number of sprite frames is harder to estimate, but a single sprite frame (assuming 32x32 and 16 colours) is roughly 512 bytes. Assuming 8 new sprite frames are needed every frame (which I again, find exceedingly unlikely), you are looking at transfering 4096 bytes of data. So in a scenario that most likely will never actually happen, you still only need roughly 5K of bandwidth. Transfering that would cost (effectively) 1.280 CPU cycles / 640 DMA cycles. That is, it would take more from the CPU's point of view, but only 1.280 CPU cycles actually touch chipmemory, the rest is all in fastmemory - meaning that running such a transfer can largely be done while other DMA is running in chipmemory. And again, that does make assumptions that may not be true. In reality, if tiles are 8 pixels in size, you basically have multiple frames to transfer them. For sprites, you only need to transfer what is needed newly - and that's not going to be hundreds of frames of data. Most of the animations don't seem to actually show a new image every frame, lowering the required bandwidth further. Now, I'll admit that there may be rough patches in which much more must suddenly be done in a frame and that implementation of this is awfully Amiga specific and not as easy as writing about it is, but the overall picture doesn't feel like it's impossibly hard to satisfy. Hard to implement, probably. But surely not impossible. Quote:
The amount by which it is increased is open to debate, but I'd guess a low-end game engine might use 10% of the available raster time, while a more high-end one could clock in at somewhere near say 25-30%. That is a pretty big chunk of CPU time you're getting back for Blitter use - or for other purposes, such as transfering memory from fastram to chipram, without impacting apparent Blitter speed compared to a normal non-fastram Amiga. Especially when you consider that the impact on chipram bandwidth is limited to only those memory accesses that do the final write, during the rest of the time other DMA can keep going at full speed. However, to be clear: this kind of full CPU/Blitter concurrency would only work if you can fit enough data in fastram and actually have fastram available. Plus, it would need to be coded specifically for the Amiga. Last edited by roondar; 18 July 2017 at 17:48. Reason: Some spelling errors fixed |
|||
18 July 2017, 17:48 | #217 | |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
Quote:
I gave you the cycle and DMA tick counts for buffering in my post. I'm very familiar with the ST and Amiga hardware. I'm not 100% sure if you grasp the difference between chip and fast RAM. It might be an idea for you to read the Amiga HRM. It's fairly accessible. If you need more than that amount of memory the STe likely wins. Anima's technique for avoid masking is more or less as fast as the Amiga 3 source $CA method. Introducing fast to chip RAM buffering to the mix and the results will be .... slowwwwww |
|
18 July 2017, 17:49 | #218 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,357
|
|
18 July 2017, 17:50 | #219 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
|
18 July 2017, 17:55 | #220 | ||||||||
CaptainM68K-SPS France
|
Quote:
the 14 mb of ram is due to the way the program is organized. Quote:
Quote:
a GNG sprite (not the bosses!) is mostly 80kb in size (facing left and right). if you have 4 or 5 different on screen, count 800kb of sprites in ram. And then you have the tilemap of the level. let's say 300-400kb, that's around 1,2mb of assets to blit. the main code is around 350kb (wet finger), and with the AI splitted for each sprite and for each level, in fast ram, It's ok But all this is speculation until the whole code can be splitted in parts. Quote:
Quote:
Basically, the Amiga strength relies in the fact that when the CPU loads/send the assets to the chipset, it has more power under the foot to process other things. The STe blitter is less faster than the Amiga one. Quote:
with this way, the CPU and blitter can work in parallel without blocking each other. Quote:
Quote:
|
||||||||
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 |
|
|