nesdev.com
http://forums.nesdev.com/

Dealing with only X, Y, and Direct Page.
http://forums.nesdev.com/viewtopic.php?f=12&t=16614
Page 2 of 2

Author:  TOUKO [ Thu Oct 26, 2017 2:55 am ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

Quote:
how did they get the SA-1 to run at 10MHz? Was it built using a smaller manufacturing process? (It doesn't have a fan, or even a heat sink.) The 5A22 in the SNES can't be that underclocked.

If i remember correctly, the 65816 was at start intended to run at this clock,and quickly pushed to 14mhz,and don't forget the C64's super CPU released in 1996 which run at 20mhz .

I don't think that the snes's CPU frequency was a manufacturing problem, but a memory requirement problem.
Nintendo wanted to sold the cheapest system, and knew that the CPU could be easily upgraded, this is why IMO it was so weak .

Author:  tepples [ Thu Oct 26, 2017 5:57 am ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

It sounds like 93143 has 68000 envy. Blast processing much?

Take it a step further and you have Thumb.

Author:  TOUKO [ Thu Oct 26, 2017 6:00 am ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

tepples wrote:
It sounds like 93143 has 68000 envy. Blast processing much?

Take it a step further and you have Thumb.

The 68K even in 90 was expensive and not customisable (not allowed by motorola).
For me The 65816 was a good choise, but not at 2.68 mhz, a SA-1 like(even more limited in features) would have been really nice and powerful .

Author:  psycopathicteen [ Thu Oct 26, 2017 12:11 pm ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

How expensive was the 68000 anyway in the early 90s anyway?

Author:  TOUKO [ Fri Oct 27, 2017 3:00 am ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

psycopathicteen wrote:
How expensive was the 68000 anyway in the early 90s anyway?

Really it's hard to tell,it's not easy to find prices of that erea,but i think the MD's price when the snes came out speak for himself,snes's VRAM,PPUs,And audio part was more expensive than her MD's counterpart,and the snes's launch price was inferior,the couple M68K + Z80 was not cheap IMO .

Author:  psycopathicteen [ Fri Oct 27, 2017 11:34 am ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

I'm confused, Wikipedia says they both cost $200 at launch, but the Genesis was $150 when the SNES launched.

Author:  TOUKO [ Fri Oct 27, 2017 11:41 am ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

psycopathicteen wrote:
I'm confused, Wikipedia says they both cost $200 at launch, but the Genesis was $150 when the SNES launched.

ah yeah, i kept in mind the european price :?
but the Md was at 150$ in 1992, not at the snes launch,but at the european snes launch .
here the snes was at the same price (150$ after conversion) but with a game(SF2 or SMW for 129$) and 2 pads,and 99$ alone with 1 pad .

to sumarise the both was at the same price for two years, the snes's chipset was more expensive to produce than the Md one,plus snes has more expensive VRAM(not sure here), and more expensive audio RAM (64k ,100ns SRAM) .

Author:  Oziphantom [ Sat Oct 28, 2017 9:08 am ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

Set the Data Bank Register to $7F ( or 7E if you want)

now
DP relative hits your 256 bytes of "registers" in 00:XXXX
16 bit ABS hits 64K of WRAM in 7F:XXXX
if you need to read from another bank or ROM
24bit ABS will read from wherever, give you have 16 bit index registers you can do
LDX #address in bank
LDA $820000,x ; reads the byte you want

or use a 24bit pointer in the DP and do direct indirect indexed long or direct indirect long modes to pull data from ROM/other RAM.

Thus you have 256 registers, 64K of RAM to play with and can access anywhere in RAM or ROM for a slight penalty.

Unless the SNES MMU mucks up the DBR and makes it also follow the lower shadow rule, but you then still get 32K+8K to play with.

Author:  HihiDanni [ Sat Oct 28, 2017 9:38 am ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

Oziphantom wrote:
Set the Data Bank Register to $7F ( or 7E if you want)

now
DP relative hits your 256 bytes of "registers" in 00:XXXX

I would not recommend this, because even though the DP access only takes 3 cycles, they're slow cycles because you're hitting RAM. One of the keys to performance on the SNES is to minimize excessive RAM reads/writes.

Oziphantom wrote:
if you need to read from another bank or ROM
24bit ABS will read from wherever, give you have 16 bit index registers you can do
LDX #address in bank
LDA $820000,x ; reads the byte you want

This is alright for one-off reads, but if you're accessing lots of values out of a different bank, better to set the data bank register and use absolutes.

Oziphantom wrote:
or use a 24bit pointer in the DP and do direct indirect indexed long or direct indirect long modes to pull data from ROM/other RAM.

This is an interesting idea, but would probably need some values pre-stored during scene initialization, or else it'd be slower than absolute long.

You don't really need 256 fake registers. My take is set program and data bank to 80, and set data bank inside of, or before calling into, routines where you want to use data from elsewhere (but only when you need to).

You're not going to want to use a data bank like 7e or 7f as a general purpose thing if it's going to prevent you from accessing ROM via absolute addressing, which means harder access to read-only data structures and lookup tables that you can access with fast cycles (assuming you're using FastROM).

So yeah, I'd basically just take a "set it when you need it" approach to SNES programming. The whole bank thing definitely creates some mental barriers, but once you become more familiar with the addressing modes, and you know how to work the data bank register, it'll become a lot more tangible.

Author:  psycopathicteen [ Sat Oct 28, 2017 11:25 am ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

I use $80 as my default bank, but I occasionally use $7e and sometimes $7f, but I only change banks at the beginning and end of routines, because the bank register isn't easy to change.

Author:  lidnariq [ Sat Oct 28, 2017 11:58 am ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

HihiDanni wrote:
Oziphantom wrote:
Set the Data Bank Register to $7F ( or 7E if you want)

now
DP relative hits your 256 bytes of "registers" in 00:XXXX
I would not recommend this, because even though the DP access only takes 3 cycles, they're slow cycles because you're hitting RAM. One of the keys to performance on the SNES is to minimize excessive RAM reads/writes.
But... 1-only the cycles that actually access "slow" speed memory are slow. 2-the only way you can get fast DP accesses are by setting them to something in the range of 0x2000-0x3FFF/0x4200-0x5FFF, because you can't move DP out of bank 0 anyway.

Author:  Drew Sebastino [ Sat Oct 28, 2017 6:13 pm ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

I have no clue what we're even talking about anymore, but I've come to the conclusion that my object table will be offset by Direct Page (again... :roll:). I figure that having to fit the object table in 6 or so KB shouldn't be too bad, especially considering that many of the variables I have are 1 or 3 bytes, and they had to be 2 and 4 bytes due to having a table per attribute. The only real bummer is that it is slower to increment Direct Page, but I figure if each object I have is 32 bytes, I'm also saving a cycle every 8 objects.

Author:  93143 [ Sun Oct 29, 2017 12:01 pm ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

Espozo wrote:
I have no clue what we're even talking about anymore

Sorry 'bout that.

Author:  psycopathicteen [ Sun Oct 29, 2017 3:15 pm ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

@93143

How does the SuperFX's cache work anyway?

Author:  93143 [ Sun Oct 29, 2017 5:54 pm ]
Post subject:  Re: Dealing with only X, Y, and Direct Page.

There's a CACHE opcode. When the Super FX hits that opcode, it sets the cache base register to the address after CACHE (but with the bottom nibble zeroed), and loads your code into the cache in 16-byte chunks as it executes it from ROM or RAM. Subsequent loops over that code are one cycle per byte, as long as it fits in the cache.

The CBR doesn't store any bank information, so LJMP is treated the same as CACHE.

You cannot store data in the cache. It's only for code. The S-CPU can write directly into the cache, but I'm not sure what the point is, since even DMA is slower than just letting the Super FX load it...

Page 2 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/