It is currently Fri Oct 20, 2017 8:23 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 51 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Thu Sep 01, 2016 4:07 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
psycopathicteen wrote:
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.

Revenant wrote:
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).


Top
 Profile  
 
PostPosted: Sat Sep 03, 2016 10:20 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
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:
.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:
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:
  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.


Top
 Profile  
 
PostPosted: Sun Sep 04, 2016 12:40 am 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 137
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.


Top
 Profile  
 
PostPosted: Sun Sep 04, 2016 8:27 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun Sep 04, 2016 9:40 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
tepples wrote:
Also make sure the init code isn't writing to $420D later on.

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

Nicole wrote:
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. :lol:


Top
 Profile  
 
PostPosted: Sun Sep 04, 2016 1:12 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 137
Espozo wrote:
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.


Top
 Profile  
 
PostPosted: Sun Sep 04, 2016 1:58 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
Nicole wrote:
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.


Top
 Profile  
 
PostPosted: Sun Sep 04, 2016 2:57 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 137
"Freaked out" in what way?


Top
 Profile  
 
PostPosted: Sun Sep 04, 2016 3:30 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
It didn't assemble. It said that it was "too low", if I remember correctly.


Top
 Profile  
 
PostPosted: Sun Sep 04, 2016 8:47 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 137
...You're gonna have to be more helpful than that, but as a guess, this:
Code:
  SNESHEADER: load = ROM0, start = $ffc0;

might need to be this:
Code:
  SNESHEADER: load = ROM0, start = $80ffc0;


Top
 Profile  
 
PostPosted: Wed Sep 07, 2016 9:42 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
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.


Top
 Profile  
 
PostPosted: Thu Sep 08, 2016 1:42 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 177
Was 120ns the rom speed needed for snes's fast rom ??? :shock:


Top
 Profile  
 
PostPosted: Thu Sep 08, 2016 2:30 am 
Online

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 787
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.


Top
 Profile  
 
PostPosted: Thu Sep 08, 2016 6:37 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
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:
.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:
# 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;
}


Top
 Profile  
 
PostPosted: Sat Sep 10, 2016 4:01 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 177
93143 wrote:
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 .


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 51 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: 93143, tepples and 7 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