It is currently Sun Oct 22, 2017 10:33 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Mon Nov 03, 2014 4:47 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2295
At first glance it might seem like the Neo Geo can update "all of them," but today I realized that the Neo Geo's oam is 48kB, and that it would take a long time to update all of them. I don't know if the Neo Geo has DMA or not, nor if I know if you can write during active display, but now I realize that this could be a bottleneck to the system.


Top
 Profile  
 
PostPosted: Mon Nov 03, 2014 5:18 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Note: I know jack squat about the NeoGeo (and there are multiple system types, some which have capabilities/hardware others might not).

Skimming http://wiki.neogeodev.org/ turns up some interesting things:

1. DMA is available but only on systems that have CD drives, I guess the LC8953 chip. DMA cannot be done outside of VBlank, so anything timing-sensitive would need to be done entirely in software during HBlank. No idea if you can write to VRAM when the GPU is actively drawing or not, but the system does appear to have a native interrupt timer that can fire at specific intervals allowing for precise scanline effects (not sure if mid-scanline or not), but has many caveats.
2. The native CPU (68000) can push, according to the DMA wiki page, around 2MBytes/second using repeated MOVE.L instructions (that's a 32-bit move).
3. How sprites work on this system is quite different from anything else I've worked on, but I'm not all that surprised since it's mainly arcade-quality stuff rather than (less expensive) consumer hardware (don't ask me about the NeoGeo AES).

References for all of this:

https://wiki.neogeodev.org/index.php?ti ... _rendering
https://wiki.neogeodev.org/index.php?title=DMA
https://wiki.neogeodev.org/index.php?title=Sprites
https://wiki.neogeodev.org/index.php?ti ... ics_format
https://wiki.neogeodev.org/index.php?ti ... ne_effects
https://wiki.neogeodev.org/index.php?ti ... interrupts
https://wiki.neogeodev.org/index.php?ti ... n_pitfalls

And here's the memory-mapped register doc:

https://wiki.neogeodev.org/index.php?ti ... _registers


Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 9:41 am 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1306
Fortunately, working with the AES and the MVS is the exact same deal. There is a minor difference in how sprite data is retrieved from the cartridge, mainly that a part that is usually on-board the MVS is expected to be in the AES for serialization of tiles (this also affects the tables for sprite shrinking).

I don't think there's a lot available especially to facilitate sprite attribute updating itself, but the system has a very powerful mechanism for chaining sprites together, as well as auto-animating tiles. The arrangement of a sprite's tiles in VRAM are reminiscient of the Genesis / Mega Drive - the tiles progress in vertical stripes from top to bottom. Look at this article on the "Sticky bit".

What I'd really love to see is something like the Mega Drive - oriented SGDK, but targeting the Neo-Geo. The attraction is the completeness of the toolchain and relative ease of setup.

Koitsu, I thought the 68000's longword moves were performed as two 16-bit word moves with an auto-increment. Is there really a substantial speed difference?


Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 10:44 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
As I understand it (I have looked at ARM7TDMI timing charts but not 68K), the savings come from the von Neumann architecture, which interleaves fetching of instructions and data. Move 32 bits in one instruction and you need not fetch another instruction to move the other 16 bits. Move 256 bits in one instruction (LDMIA/STMIA on ARM or MOVEM.L on 68K) and you save even more time.


Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 12:05 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
mikejmoffitt wrote:
Koitsu, I thought the 68000's longword moves were performed as two 16-bit word moves with an auto-increment. Is there really a substantial speed difference?

Don't know -- I know jack squat about the 68000. All I did was read some documentation/web pages describing the move opcode: http://mrjester.hapisan.com/04_MC68/Sec ... Index.html

How I interpret the information shown there: .b uses bytes (8 bits), .w uses words (16 bits), and .l uses "long word" (32 bits). How this is implemented internally (e.g. move.l might move two 16-bit words (high word, then low word)) is irrelevant to me because the end result would be the same (32 bits of data got moved). Is that not correct?


Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 1:01 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2295
From what I read in another document, the VRAM port can be written to every 12th cycle and is 16 bits wide. 12 just happens to also be the number of cycles it takes to move a word with the 68000, so there that means it can update 33kb per frame, but 5kb during vblank.


Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 5:37 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 915
Location: Japan
I dunno about the timing of everything, but just by observing games you can see what a lot of them do.

Sengoku 2 changes sprite X-scale values in HBlank, allowing for a "perspective" effect. So, HBlank (mid-screen) sprite RAM writing is valid and possible.

Many games, if you watch near the top of the screen, have a shearing effect on objects, meaning there wasn't enough time to update sprites in VBlank, and it's spilling into the screen. No glitches beyond that.

_________________
http://www.chrismcovell.com


Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 7:10 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1306
ccovell wrote:
I dunno about the timing of everything, but just by observing games you can see what a lot of them do.

Sengoku 2 changes sprite X-scale values in HBlank, allowing for a "perspective" effect. So, HBlank (mid-screen) sprite RAM writing is valid and possible.

Many games, if you watch near the top of the screen, have a shearing effect on objects, meaning there wasn't enough time to update sprites in VBlank, and it's spilling into the screen. No glitches beyond that.


I've never seen this on any games, but I don't own a lot of Neo-Geo games. Which ones in particular have this shearing problem?


Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 8:19 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
mikejmoffitt wrote:
Koitsu, I thought the 68000's longword moves were performed as two 16-bit word moves with an auto-increment. Is there really a substantial speed difference?

By general rule it just increases the instruction duration by 4 cycles (every access to memory takes up 4 cycles, no exception), regardless of what addressing mode is being used. So yes, it's pretty much guaranteed to be faster than discrete move accesses.

Also trivia of the day: the Super A'can has a system similar to the Neo Geo in that sprites are their own tilemaps (or at least that's what I can gather from the little that's emulated in MESS).


Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 10:58 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1306
Sik wrote:
mikejmoffitt wrote:
Koitsu, I thought the 68000's longword moves were performed as two 16-bit word moves with an auto-increment. Is there really a substantial speed difference?

By general rule it just increases the instruction duration by 4 cycles (every access to memory takes up 4 cycles, no exception), regardless of what addressing mode is being used. So yes, it's pretty much guaranteed to be faster than discrete move accesses.

Also trivia of the day: the Super A'can has a system similar to the Neo Geo in that sprites are their own tilemaps (or at least that's what I can gather from the little that's emulated in MESS).


Whoa, 68000 with a little 6502 buddy! You don't see that every day.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group