Help with setting FM patch values

For anything related to sound (YM2612, PSG, Z80, PCM...)

Moderator: BigEvilCorporation

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Thu Jan 30, 2014 9:44 am

You can even save / load FAT16 files from a standard Everdrive, there is an API for that :
http://code.google.com/p/sgdk/source/br ... de/fat16.h

It is included in SGDK but you can use it in standalone without any problem.

MrD
Very interested
Posts: 70
Joined: Sun Jan 26, 2014 4:29 pm

Post by MrD » Sun Feb 02, 2014 4:04 pm

I'm still getting a garbled display on my own PAL Mega Drive 1 when loading the instmaker from my custom EEPROM-based PCB. I'm fairly sure it's not a problem with my hardware as UWOL The Quest for Money runs flawlessly from it, as does Gigasoft MD Music Demo 1.

I'm getting a screen of garbage characters with the '[' character repeated across large chunks of the display (so the text tile graphics are being loaded into VRAM correctly?). The logic of the software seems to be intact as I can still activate the note and cancel it with the C and Start buttons... I guess I'm not initialising the display correctly? Regen, Fusion and MESS are all happy with my code, which is pointing me towards not intialising something right (the hardware wouldn't zero things on startup, the emulators tend to zero everything... what does the Everdrive do when it switches execution from its own menu to the loaded ROM?)

Does this sort of error sound familiar to anyone? Does anybody have a different type of flash cart that they could use to test my program?

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Feb 02, 2014 11:55 pm

The DMA uses a COMPLETELY different timing than the CPU - far faster. The old SEGA docs used to tell you to copy data from the rom into the work ram before using the DMA as the OLD carts used roms too slow for the DMA. Sounds like your custom cart is having a similar problem - too slow for DMA, which is why code runs while DMA from rom to vram is garbled.

And most folks here have at least one kind of MD flash cart. I've got three: the MD-Pro64, the MD Myth, and the MegaED.

MrD
Very interested
Posts: 70
Joined: Sun Jan 26, 2014 4:29 pm

Post by MrD » Mon Feb 03, 2014 12:10 am

My code doesn't use DMA; I don't know how to use it yet. :)

If you look at my code, the tiles in fact are copied excrutiatingly slowly to the VDP because I have to manually swizzle each byte on the 68000 as I retrieve it from the ROM (I'm using the exporter from the Usenti bitmap editor, it's for GBA graphics so the nibbles aren't SMD format).

Aly James
Very interested
Posts: 74
Joined: Sun Mar 31, 2013 11:34 pm
Location: FRANCE
Contact:

Post by Aly James » Mon Feb 03, 2014 4:52 am

garbled display...probably not your custom card.
As previously stated it runs fine on my early model 1 (PAL, don't remember which VA but probably early one with external joy port and high-def graphics mention).
On another PAL MD later revision (with TMSS and no High def mention)
I have the garbled display. but also on a MD1 US version (Genesis) HighDef. VA2 PCB.

One thing worth mentioning, on my PAL working model 1 if I turn off the
HARD RESET option on the Everdrive, I got the garbled display too.
with Hard Reset ON it displays fine.

I think it is definitely related to your .img formating/loading process...
Hope that helps.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Mon Feb 03, 2014 6:20 am

RAM and registers are loaded with garbage on startup, you need to do some setup on those. TMSS units do some of that cleanup.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Aly James
Very interested
Posts: 74
Joined: Sun Mar 31, 2013 11:34 pm
Location: FRANCE
Contact:

Post by Aly James » Mon Feb 03, 2014 8:26 am

TmEE co.(TM) wrote:RAM and registers are loaded with garbage on startup, you need to do some setup on those. TMSS units do some of that cleanup.
So in that case, why my early non TMSS loads fine and the TMSS not?
+ the Hard reset option on the Everdrive should clean system registers b4 game starts.
http://krikzz.com/pub/support/everdrive ... nglish.pdf

So what do you think could lead to this results?:
Early Model 1 non TMSS + EVDrive Hard Reset option ON = OK
Later Model 1 TMSS + EVDrive Hard Reset option ON = Garbled Display
Emulator = OK

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Mon Feb 03, 2014 8:35 am

The problem is always not initialising something and assuming it is what is expected.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Aly James
Very interested
Posts: 74
Joined: Sun Mar 31, 2013 11:34 pm
Location: FRANCE
Contact:

Post by Aly James » Mon Feb 03, 2014 8:41 am

Thanks for confirming Tiido :)
My ASM instructions reading is not that good, I'll wait on MrD side to check it out!

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Mon Feb 03, 2014 9:28 pm

It's probably an issue with the VDP register settings. Power-on defaults for the VDP are all registers initialized to 0. If you have a bios or other piece of code running before your code starts, chances are, the VDP is going to have some registers already set to particular values.

MrD
Very interested
Posts: 70
Joined: Sun Jan 26, 2014 4:29 pm

Post by MrD » Mon Feb 03, 2014 10:13 pm

Thanks everyone, I'll have a look through my VDP setting routine and make sure I'm setting everything to some value once.

I think I'm setting everything except the DMA registers to a good value. I didn't think these were read from unless DMA was enabled in $01 - Mode Register 2. Is it safe to set these DMA registers to zero?

I'm also not touching the following:
$06 - Sprite Pattern Generator Base Address
$08 - Unused
$09 - Unused
$0E - Nametable Pattern Generator Base Address

Should I set these to zero too?

MrD
Very interested
Posts: 70
Joined: Sun Jan 26, 2014 4:29 pm

Post by MrD » Mon Feb 17, 2014 6:36 am

Settings the unused registers to zero had no effect on hardware. I'm bamboozled.

The pattern of the garbage shapes on screen makes me think that my VDP memory area assignments are wrong, but Regen's VDP debugger is showing me the VDP is interpreting the addresses correctly.

Code: Select all

        lea     (MM_VDP_CONTROL),a6
        move.w  #(VDP_REGISTER_PLANE_A_NAME_TABLE_LOCATION|%00000000),(a6)            ; NT A = $0000-$1000
        move.w  #(VDP_REGISTER_WINDOW_NAME_TABLE_LOCATION|%00000100),(a6)             ; W B  = $1000-$2000
        move.w  #(VDP_REGISTER_PLANE_B_NAME_TABLE_LOCATION|%00000001),(a6)            ; NT B = $2000-$3000
        move.w  #(VDP_REGISTER_HORIZONTAL_SCROLL_DATA_LOCATION|%00001100),(a6)        ; HS   = $3000-$3400
        move.w  #(VDP_REGISTER_SPRITE_TABLE_LOCATION|%00011010),(a6)                  ; ST   = $3400-$3680
I'm putting everything together at the beginning of VRAM, loading my patterns into the next available RAM from $36A0 onwards. $3680-$36A0 is left blank for blank tile, I'm clearing VRAM Plane A (setting tile index to $01B4 (== $3680/$20)) and using VRAM Plane B to display the background graphic.

The only think I can think that I've done is messed up the Window plane, but I'm setting both those registers to zero.

Could somebody look through game.68k.asm and see if I'm initialising the system right? The label initialise_megadrive: sets up the VDP and clears all the VRAM, CRAM and RAM. I'm not doing anything unusual as far as I can see.

One thing I've noticed that other code does that mine doesn't is that my code never drops from supervisor privilege into user privilege. Is this necessary? I just rely on the 68000 reading the stack pointer position from the header and working from there.

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Mon Feb 17, 2014 10:39 am

The problem is that you're exclusively only writing the first word of the VDP command longword to the control port. This only works if the other bits that aren't being set are already initialized with some known value. If I change the control port write in vdp_clear_all_cram to a longword, the display is no longer garbled on my Mega Everdrive equipped Model 2.

Incidentally I get a completely blank screen in BlastEm. A14 and A15 are getting retained from their autoincremented values after the tiles are written. This causes the tile maps to get written to the wrong address; however, this does not occur on the real hardware. I'm guessing this means there's a separate address register that retains the last value explicitly written rather than the value as modified by autoincrement and it's that unmodified copy that A14 and A15 are pulled from when you do a partial control port write. I'll have to test to confirm.

EDIT: I also noticed you're not initializing VSRAM. You can probably get away with it since it's unlike a menu/TMSS will set wonky scroll values, but it's probably best to play it safe.

MrD
Very interested
Posts: 70
Joined: Sun Jan 26, 2014 4:29 pm

Post by MrD » Mon Feb 17, 2014 1:26 pm

Right, that makes sense! I must have assumed that the last write was to an address with all VRAM high address bits zero. All my VRAM tile index entry writes for the interface work off that assumption. Thank you very much for seeing that.

You're dead right about the VSRAM. I'm not used to there being so many distinct locations for this stuff, when I wrote the VRAM clear I assumed it was amongst the main VRAM area like the H-Scroll table.

MrD
Very interested
Posts: 70
Joined: Sun Jan 26, 2014 4:29 pm

Post by MrD » Mon Feb 17, 2014 7:14 pm

This version has VSRAM clearing, unused VDP register zeroing, and full VRAM address zeroing. Yet to be tested on my hardware, but I'm hopeful. :)

http://www.mrdictionary.net/stuff/2014/ ... tmaker.zip

Post Reply