Dealing with only X, Y, and Direct Page.

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
TOUKO
Posts: 288
Joined: Mon Mar 30, 2015 10:14 am

Re: Dealing with only X, Y, and Direct Page.

Post by TOUKO » Thu Oct 26, 2017 2:55 am

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 .

tepples
Posts: 21751
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Dealing with only X, Y, and Direct Page.

Post by tepples » Thu Oct 26, 2017 5:57 am

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

Take it a step further and you have Thumb.

TOUKO
Posts: 288
Joined: Mon Mar 30, 2015 10:14 am

Re: Dealing with only X, Y, and Direct Page.

Post by TOUKO » Thu Oct 26, 2017 6:00 am

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 .

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Dealing with only X, Y, and Direct Page.

Post by psycopathicteen » Thu Oct 26, 2017 12:11 pm

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

TOUKO
Posts: 288
Joined: Mon Mar 30, 2015 10:14 am

Re: Dealing with only X, Y, and Direct Page.

Post by TOUKO » Fri Oct 27, 2017 3:00 am

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 .

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Dealing with only X, Y, and Direct Page.

Post by psycopathicteen » Fri Oct 27, 2017 11:34 am

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

TOUKO
Posts: 288
Joined: Mon Mar 30, 2015 10:14 am

Re: Dealing with only X, Y, and Direct Page.

Post by TOUKO » Fri Oct 27, 2017 11:41 am

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) .

Oziphantom
Posts: 774
Joined: Tue Feb 07, 2017 2:03 am

Re: Dealing with only X, Y, and Direct Page.

Post by Oziphantom » Sat Oct 28, 2017 9:08 am

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.

User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Dealing with only X, Y, and Direct Page.

Post by HihiDanni » Sat Oct 28, 2017 9:38 am

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.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Dealing with only X, Y, and Direct Page.

Post by psycopathicteen » Sat Oct 28, 2017 11:25 am

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.

lidnariq
Posts: 8780
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Dealing with only X, Y, and Direct Page.

Post by lidnariq » Sat Oct 28, 2017 11:58 am

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.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Dealing with only X, Y, and Direct Page.

Post by Drew Sebastino » Sat Oct 28, 2017 6:13 pm

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.

93143
Posts: 1109
Joined: Fri Jul 04, 2014 9:31 pm

Re: Dealing with only X, Y, and Direct Page.

Post by 93143 » Sun Oct 29, 2017 12:01 pm

Espozo wrote:I have no clue what we're even talking about anymore
Sorry 'bout that.

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Dealing with only X, Y, and Direct Page.

Post by psycopathicteen » Sun Oct 29, 2017 3:15 pm

@93143

How does the SuperFX's cache work anyway?

93143
Posts: 1109
Joined: Fri Jul 04, 2014 9:31 pm

Re: Dealing with only X, Y, and Direct Page.

Post by 93143 » Sun Oct 29, 2017 5:54 pm

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...

Post Reply