June 19, 2013, 11:58:34 pm
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
It's not that obvious in fact...I know it's strange but that's what they did.I'm not really clear on what your point is. I do understand how it works under the hood (I think). I was simply stating that palette RAM, in particular, is memory used for video that is accessed via the PPU address/data lines. My understanding of a "bus" might not be 100% accurate, so I'll give you the benefit of the doubt and assume that I'm technically wrong, because who really cares? We're talking about a VWF, not palette RAM.
1) If a dialog is very small and uses less than 8 letters per line, a VWF can be made with spritesNumber one seems far to restrictive to be practical. I guess it could be used for menus or something. Number two is actually pretty clever, in a Rube Goldberg sort of way. Kudos to you if you get something like that up and running in an actual game, and if it suits you, why not? I'd personally sooner convert a game to use CHR RAM if possible.
2) If a dialog uses the entire screen width and that the main game uses only a single nametable, and that the total VWF area (not including whitespaces) is not more than 30 pixels in heighth, it is doable with CHR-ROM and raster timing. By having a 4k CHR-ROM page where each tile is simply it's number shown in graphics (I'm not sure how to tell this, tile #0 would be blank, tile #1 would have only a single white pixel, and tile #255 would have a entiere horizontal line), it's possible to draw arbitrary graphics by changing the vertical scroll every line.
Another optional VRAM is the 4-screen additional VRAM
OAM and pallete are normally not considered part of VRAM in Nintendo's systems.
Actually CHR-ROM is suitable for VWF but it's quite complex and would require to pull off some dirty trick of the NES to make it work.
By the way Snarf, is the video you posted a Let's Play or you gave it a few tries before recording? If it's your first time, I can say it's quite amazing that you got that far. Hats off. The only thing that sucks with Contra video recordings is how the bullets flicker and therefore not always appear in the recording frame. It means you are always seeing only part of the total bullets on screen and it's visually annoying...
Mods =/= Staff. Very different things.
The Standard Weapon (white bullets) and the F Weapon can now have 8 bullets on screen at any given timeI like this change very much.
Oh, and more good news. I found a way to expand the ROM successfully, and with minimal change to the original code.Good news indeed.
Home
Help
Login
Register
; Switch bg to CHR bank 9
lda #$09
sta $7801
sta $7802
sta $7803
rts
;Play Tourian theme (simple :)
jmp TourianMusic
;(You can insert a different song in its place to allow two songs in an area); Draw an object on the screen if the player has at least 1 full e-tank
; (Requires the code below to be added to the general code file)
; Exit if player doesn't have any full tanks
lda HealthHi
and #$F0
bne +
rts
*
; Load ptr to data and draw it
ldx #<ObjectData
ldy #>ObjectData
jmp ExtraRoomData
ObjectData:
; xy type pal end
.db $88, $08, $01, $FF; This is required by the above example.
; This would be placed in the general code file.
; ----------------------------
; ExtraRoomData
; ----------------------------
; Draws additional objects to a screen. Call in screen-load
; routine. This is a modified version of a similar routine in
; the original game.
; Parameters:
; x - low byte of object data
; y - high byte of object data
ExtraRoomData:
stx RoomPtr ; Store data address
sty RoomPtr + 1
ldy #$00 ; Point to first byte
lda (RoomPtr),Y ; Read it
DrawExtraObject:
sta $0E ;Store object position byte(%yyyyxxxx).
lda CartRAMPtr ;
sta CartRAMWorkPtr ;Set the working pointer equal to the room pointer-->
lda CartRAMPtr+1 ;(start at beginning of the room).
sta CartRAMWorkPtr+1 ;
lda $0E ;Reload object position byte.
jsr Adiv16 ;($C2BF)/16. Lower nibble contains object y position.-->
tax ;Transfer it to X, prepare for loop.
beq +++ ;Skip y position calculation loop as y position=0 and-->
;does not need to be calculated.
* lda CartRAMWorkPtr ;LoW byte of pointer working in room RAM.
clc ;
adc #$40 ;Advance two rows in room RAM(one y unit).
sta CartRAMWorkPtr ;
bcc + ;If carry occurred, increment high byte of pointer-->
inc CartRAMWorkPtr+1 ;in room RAM.
* dex ;
bne -- ;Repeat until at desired y position(X=0).
* lda $0E ;Reload object position byte.
and #$0F ;Remove y position upper nibble.
asl ;Each x unit is 2 tiles.
adc CartRAMWorkPtr ;
sta CartRAMWorkPtr ;Add x position to room RAM work pointer.
bcc + ;If carry occurred, increment high byte of room RAM work-->
inc CartRAMWorkPtr+1 ;pointer, else branch to draw object.
;CartRAMWorkPtr now points to the object's starting location (upper left corner)
;on the room RAM which will eventually be loaded into a name table.
* iny ;Move to the next byte of room data which is-->
lda (RoomPtr),y ;the index into the structure pointer table.
tax ;Transfer structure pointer index into X.
iny ;Move to the next byte of room data which is-->
lda (RoomPtr),y ;the attrib table info for the structure.
sta ObjectPal ;Save attribute table info.
txa ;Restore structure pointer to A.
asl ;*2. Structure pointers are two bytes in size.
tay ;
lda (StructPtrTable),y ;Low byte of 16-bit structure ptr.
sta StructPtr ;
iny ;
lda (StructPtrTable),y ;High byte of 16-bit structure ptr.
sta StructPtr+1 ;
jsr DrawStruct ;($EF8C)Draw one structure.
; Next Object
lda #$03 ;Move to next set of structure data.
jsr AddToRoomPtr ;($EAC0)Add A to room data pointer.
ldy #$00 ;Zero index.
lda (RoomPtr),y ;Load byte of room data.-->
cmp #$FF ;Is it #$FF(end-of-room)?-->
beq + ;If so, branch to exit.
jmp DrawExtraObject
* rts
>
Shin Zelda Densetsu doesn't seem to save for me. If I die and choose "save", I can continue from that save as long as I don't power off, but if I turn off the game and come back to it later, the save is gone.
Loading D:\Emu\Hacks\Shin Zelda Densetsu.nes...
PRG ROM: 8 x 16KiB
CHR ROM: 0 x 8KiB
ROM CRC32: 0x47fcb674
ROM MD5: 0x36724d3dbcb91401ab962693950ddca6
Mapper #: 1
Mapper name: MMC1
Mirroring: Horizontal
Battery-backed: Yes
Trained: No
Any thoughts about adding ROM/ISO info that's missing to Public Maintenance?While it would be nice to have, if the info's not there in the first place, where are you going to get it? Realistically, I think the current approach is the best solution, provided submitters (and approvers) abide by the guidelines.
I fail to see how you could NOT BOTHER having to repeat the same thing again and again.