How big is your object table? (addressing problems)

[Drew Sebastino]

Are you talking about shmups or run'n'guns?

shmups. I thought I said that, but maybe I didn't. A run and gun would be next to impossible to make with one person because of all the animation and general complexity involved. Shmups are generally a lot less varied, or at least they can get away with it better. Hell, most don't even have BG collision. I'm actually trying to make something else actually that shouldn't be so CPU intensive, but I'm just curious. Really, a shmup could probably be a lot more hardcoded. Animation is next to none, objects are typically only comprised of a couple of sprites, there's often no BG collision, and objects are generally fairly dumb. What counteracts this is that there's a lot of stuff.

Banks $00 and $80 are physically identical on (nearly) all cartridges. That is, you can put your vectors at $80FFE4+ and they will be mirrored to $00FFE4. The only difference is that bank $80 is accessed faster when FastROM is enabled.

Cool. I actually have a dumb English paper I have to write, but after that (probably not today) I'll see how much of an improvement FastROM is. I probably won't hardcode metasprites for what I'm trying to do now (doesn't involve even close to 128 objects) but I might at some other point. I thought about how me trying to hardcode in metasprites would ultimately be me either creating new code for every frame (impractical) or basically me just copying over the code from my metasprite routine (which would probably even be slower).

[Drew Sebastino]

I must have done something wrong, because it's not any faster at all. Here's what I did to try and make it work:

Code: Select all

.proc Main

  sei		;Disable interrupts
  clc		;Clear carry, used by XCE
  xce		;Set 65816 native mode
  jml $800000+MainFastROM	;Needed to set K (bank of PC) properly if MODE 21 is ever used;
							;see official SNES developers docs, "Programming Cautions"
.endproc		

;=========================================================================================
;=========================================================================================

.proc MainFastROM
  lda #$01
  sta a:$420D
  phk		;Push K (PC bank)
  plb		;Pull B (data bank, i.e. data bank now equals PC bank)

Code: Select all

ROMSPEED_120NS = $10
  .byte MAPPER_LOROM|ROMSPEED_120NS

I thought I was going crazy and didn't implement it, but somehow, this doesn't make it crash:

Code: Select all

  phk
  pla
  cmp #$80
  beq infinite_loop
  stp

Because everything gets mirrored, I didn't bother messing with the file I posted earlier that defined where the banks were.

[Nicole]

A few problems here:

If your segment is already set to be bank $80, you don't need to write jml $800000+MainFastROM, just jml MainFastROM is sufficient, because ca65 will assemble that as a long jump to bank $80.

Come to think of it, it's even possible that you adding $800000 is putting you in bank $00, because if MainFastROM is already $801234, adding $800000 would make it overflow to $001234. Not sure if that's exactly how ca65 behaves, but it's possible, in which case you'll get no speedup at all.

The other problem is that you're trying to set $420D to #$01 way too early.

For starters, you haven't set the processor flags. I don't know if A is guaranteed to be 8-bit after switching to native mode after startup, but if not, you risk crashing almost immediately, because if A is 16-bit, the CPU will attempt to read an extra byte for lda, causing it and every instruction after it to be completely misinterpreted.

Secondly, you need to set $420D after setting the data bank, not before. If the data bank is uninitialized, it could potentially be one of $40-$7f, or $c0-ff, where the system area doesn't exist. That would mean $420D doesn't get set at all, because it would try to write somewhere like $50420D.

[tepples]

If you write to $80420D or f:$420D, it'll use absolute long mode, which doesn't depend on the current data bank.

Also make sure the init code isn't writing to $420D later on.

[Drew Sebastino]

Also make sure the init code isn't writing to $420D later on.

Apparently, it was being zeroed latter... It works fine now, so thanks everybody.

If your segment is already set to be bank $80

No. It's all in bank $00.

So now, I'm using 3/8 the screen instead of 1/2. It's better at least.

[Nicole]

No. It's all in bank $00.

That's a problem. You want the segment to be in bank $80, otherwise if you need to long jump to a label in that segment later, you'll end up back in bank $00. You'd end up being forced to add $800000 manually every single time for no good reason to avoid ending up back in slow ROM. Just make it bank $80, and do jml MainFastROM instead of jml $800000+MainFastROM.

[Drew Sebastino]

Just make it bank $80

I don't know how. I tried editing the earlier file I posted to where "ROM0" was at $808000, but it freaked out.

[Nicole]

"Freaked out" in what way?

[Drew Sebastino]

It didn't assemble. It said that it was "too low", if I remember correctly.

[Nicole]

...You're gonna have to be more helpful than that, but as a guess, this:

Code: Select all

  SNESHEADER: load = ROM0, start = $ffc0;

might need to be this:

Code: Select all

  SNESHEADER: load = ROM0, start = $80ffc0;

[Drew Sebastino]

Yeah, that was the problem. I haven't been able to work on this in a while, so I hadn't been able to check what the deal was. I never thought about it, but it kind of sucks that I have to write ".LOWORD" for everything now.

[TOUKO]

Was 120ns the rom speed needed for snes's fast rom ???

[93143]

Yes. 200 ns for SlowROM, 120 ns for FastROM. As I understand it, the 5A22 used the classic 65xx half-cycle strobe with 6 master clocks per internal cycle and on-die wait state behaviour, so for a slow cycle (8 master clocks), phi1 would take an internal half-cycle (3 master clocks, or ~140 ns) and phi2 would take the rest of the cycle (5 master clocks, or ~230 ns). Fast cycles (6 master clocks) left just 3 master clocks for phi2 rather than 5, hence the dramatic difference in the speed requirement.

[Drew Sebastino]

I don't know how, but I I'm still having the SNES crash, and I found out that it's doing it on "jml [LongJumpLocation]", even though it worked perfectly before.

Code: Select all

.proc object_identifier
  rep #$20
  lda .LOWORD(ObjectTable)
  sta a:ObjectTableOffset

object_identifier_loop:
  tcd
  lda ObjectSlot::Identity
  beq next_object
  sta a:LongJumpLocation
  lda ObjectSlot::Identity+1
  sta a:LongJumpLocation+1
  jml [LongJumpLocation]
next_object:
  lda a:ObjectTableOffset			;says how many objects have been identified
  clc
  adc #ObjectSlotSize
  sta a:ObjectTableOffset		;store the result for the next time we go through the loop
  cmp .LOWORD(ObjectTable)+ObjectTableSize
  bne object_identifier_loop		;if so, quit searching
  rts
.endproc

Just incase I did something wrong in creating the memory map, here it is:

Code: Select all

# ca65 linker config for 256 KiB (2 Mbit) sfc file

# Physical areas of memory
MEMORY {
  ZEROPAGE:   start =  $000000, size =  $0100;   # $0000-00ff -- zero page
                                                 # $0100-01ff -- stack
  BSS:        start =  $000200, size =  $1e00;   # $0200-1fff -- RAM
  BSS7E:      start =  $7e2000, size =  $e000;   # SNES work RAM, $7e2000-7effff
  BSS7F:      start =  $7f0000, size = $10000;   # SNES work RAM, $7f0000-$7ffff
  ROM0:       start =  $808000, size =  $8000, fill = yes;
  ROM1:       start =  $818000, size =  $8000, fill = yes;
  ROM2:       start =  $828000, size =  $8000, fill = yes;
  ROM3:       start =  $838000, size =  $8000, fill = yes;
  ROM4:       start =  $848000, size =  $8000, fill = yes;
  ROM5:       start =  $858000, size =  $8000, fill = yes;
  ROM6:       start =  $868000, size =  $8000, fill = yes;
  ROM7:       start =  $878000, size =  $8000, fill = yes;
}

# Logical areas code/data can be put into.
SEGMENTS {
  CODE:       load = ROM0, align =  $100;
  RODATA:     load = ROM0, align =  $100;
  SNESHEADER: load = ROM0, start = $80ffc0;
  CODE1:      load = ROM1, align =  $100, optional = yes;
  RODATA1:    load = ROM1, align =  $100, optional = yes;
  CODE2:      load = ROM2, align =  $100, optional = yes;
  RODATA2:    load = ROM2, align =  $100, optional = yes;
  CODE3:      load = ROM3, align =  $100, optional = yes;
  RODATA3:    load = ROM3, align =  $100, optional = yes;
  CODE4:      load = ROM4, align =  $100, optional = yes;
  RODATA4:    load = ROM4, align =  $100, optional = yes;
  CODE5:      load = ROM5, align =  $100, optional = yes;
  RODATA5:    load = ROM5, align =  $100, optional = yes;
  CODE6:      load = ROM6, align =  $100, optional = yes;
  RODATA6:    load = ROM6, align =  $100, optional = yes;
  CODE7:      load = ROM7, align =  $100, optional = yes;
  RODATA7:    load = ROM7, align =  $100, optional = yes;

  ZEROPAGE:   load = ZEROPAGE, type = zp;
  BSS:        load = BSS,   type = bss, align = $100, optional = yes;
  BSS7E:      load = BSS7E, type = bss, align = $100, optional = yes;
  BSS7F:      load = BSS7F, type = bss, align = $100, optional = yes;
}

[TOUKO]

Yes. 200 ns for SlowROM, 120 ns for FastROM. As I understand it, the 5A22 used the classic 65xx half-cycle strobe with 6 master clocks per internal cycle and on-die wait state behaviour, so for a slow cycle (8 master clocks), phi1 would take an internal half-cycle (3 master clocks, or ~140 ns) and phi2 would take the rest of the cycle (5 master clocks, or ~230 ns). Fast cycles (6 master clocks) left just 3 master clocks for phi2 rather than 5, hence the dramatic difference in the speed requirement.

i understand now why the snes's CPU was only clocked to 2,68 mhz ..
It's a shame that nintendo(ricoh in fact) has kept this half cycle access for memory, unlike hudson did for his HU6280 .