NESdev list excavation - MSG's 1 - 100
compiled by Happy_Dude for The Nintendo Difference
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Mon Apr 12, 1999 5:11 pm
Subject: Re: SNSS Revision Request - Byte Order
> Here's 2 facts that cannot be disputed:
>
> - The NES uses the Intel byte order.
> - 95% of the machines used to emulate the NES use the Intel byte order.
>
> SO CHANGE IT. 95% of emulators should not have to swap byte order because
> 5% have it swapped. Also, the 6502 is Intel byte order!
>
> -- Barubary
If you can convince nesdev of your arguements then I'll switch it. I go
with what the masses tell me to do, and previously the masses said NON-INTEL
BYTE ORDER NOW NOW NOW NOW NOW NOW!!!!!
So...
-David
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Mon Apr 12, 1999 5:33 pm
Subject: Re: SNSS Revision Request - Byte Order
> From: Barubary <barubary@h...>
> Here's 2 facts that cannot be disputed:
>
> - The NES uses the Intel byte order.
> - 95% of the machines used to emulate the NES use the Intel byte order.
Correct.
> SO CHANGE IT. 95% of emulators should not have to swap byte order because
> 5% have it swapped. Also, the 6502 is Intel byte order!
Nope, SNSS should stay in human-readable MSB. We've been over this; SNSS is
there for the convenience of the _user_, not the coder.
Do you realize that byte-order only comes into play when you are
reading/writing 16-bit and 32-bit integers directly to/from the state file
(of which there are precious few)?
And that it takes a 2-line function/macro to handle the byte order swap?
Seriously man, this is *not* rocket science.
Later,
Matt.
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Mon Apr 12, 1999 5:44 pm
Subject: Re: SNSS Revision Request - Byte Order
> And that it takes a 2-line function/macro to handle the byte order swap?
> Seriously man, this is *not* rocket science.
My macros to do just that for whoever wants to use em:
#define EndianSwap32b(A) ((unsigned long) (((A & 0xFF000000) >> 24) |
((A & 0x00FF0000) >> 8) | ((A & 0x0000FF00) << 8) | ((A & 0x000000FF) <<
24)))
#define EndianSwap16b(A) ((LBYTE) (((A & 0xFF00) >> 8) | ((A &
0x00FF) << 8)))
-David
*********************************************************************************
From: "Michel Iwaniec" <bananmos_uv@xxxxxxx.xxxx
Date: Tue Apr 13, 1999 12:23 am
Subject: Re: NES Music Ripping
>>>Yeah PSX mem cards were my answer to the space and cost problems.
>
>>Only 128 kilobytes? (about 8 NSF-files)... how much does each cost?
>
>I can get them for around $9 or so each I believe.
>
>To get around the 128K size, I'm going to use some compression. LZW
will do
>very nicely for the data we are compressing.
that's true...
>Hmmm... I really, really don't want to complicate the format any more
than
>is required. An NTSC/PAL bit is a good idea though.
well, what about just setting the X reg (at calls to the init/play
code) to 0 for NTSC, and 1 for PAL (and having just two tiny words for
both the NTSC and PAL playback rate) ...wouldn't be that much
complicated... :)
>I would be first in line but obviously I don't have a PAL machine or
access
>to one... and I'm not about to pay the outrageous price to get one
either :-/
Yeah... and one would still have to find some game with cool usage of
DPCM (like JTS)
>Hmmm... That would *almost* work. Though the regs at 4000h will
screw you
>up :-/
Well, the thing I wonder about is this: if you were to set up RAM from
0x0000 to 0x8000, and have no PPU connected to the NES CPU, what
registers would be present? probably only 0x4000-0x4017, or really up
to 0x4020, and then mirrored all the way to 0x5000.
But I have this little theory (based on no facts) that *if* there is
RAM where the write-only registers would be, then when writing the
write-only regs, not only would the sound/etc be affected, but also
the connected memory (which is not present in the NES). And likewise,
when the write-only registers are read, the memory content would be
returned, except when reading readable regs, of course... and
mirroring would only occur for the registers (i.e., memory would not
be mirrored)
I have no way to test this though, perhaps you could?
The audio coming from the NES CPU would then be ignored in SID mode,
but the problem with reading 0x4015 and setting bit 7 of 0x4010 high
(=IRQ) would remain...
btw, does anyone know where the 256-byte sprite RAM resides? and if
reg 0x4014 is present even when the CPU is not connected to the PPU?
Anyways, a check on what is real RAM in a NES CPU without any other
peripherals would be great.
>There is a pin on the NES CPU though that is held grounded...
this
>could very well be an enable for those internal regs... >:) One way
to find
>out is to lift it to VCC and see what happens. Someone said it's
really
>an ABORT input, though I highly doubt it. It could also be a /RDY
input
>but I have a sneaky suspicion that it just might disable those
internal
>regs... :-) When I get my hardware NSF player in a better state I
will
>test that hypothesis.
That'd be wonderful! Then all register-related problems would be
solved. Only the "unofficial instructions"-problem of the 6510 would,
remain, as well as the decimal mode one..
Again I ask: has *anyone* on this list verified the lack of decimal
mode on the *real* thing?...
*********************************************************************************
From: JDC <yoshi@xxxxxxxx.xxxx
Date: Tue Apr 13, 1999 2:56 am
Subject: Re: NES Music Ripping
On 04/12/1999 (07:23:16), bananmos_uv@h... wrote:
> btw, does anyone know where the 256-byte sprite RAM resides? and if
> reg 0x4014 is present even when the CPU is not connected to the PPU?
Lesser: It resides internal to the PPU.
Latter: Don't know.
> Again I ask: has *anyone* on this list verified the lack of decimal
> mode on the *real* thing?...
It's been verified view a few professional NES programmers.
--
| Jeremy Chadwick yoshi@d... |
| Parodius Networking yoshi@p... |
| System Administrator/CGI Programmer 650-551-8916 |
*********************************************************************************
From: Neill Corlett <corlett@xxxxx.xxxx.xxxx.xxxx
Date: Tue Apr 13, 1999 2:58 am
Subject: Re: SNSS Revision Request - Byte Order
With all the bickering over which byte order this (hypothetical) format is
going to use... why can't there be a compromise?
I personally suggest PDP byte ordering. ;)
Neill
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Tue Apr 13, 1999 7:36 am
Subject: Re: NES Music Ripping
GO
> From: JDC <yoshi@p...>
> On 04/12/1999 (07:23:16), bananmos_uv@h... wrote:
>
> > Again I ask: has *anyone* on this list verified the lack of decimal
> > mode on the *real* thing?...
>
> It's been verified view a few professional NES programmers.
And the fact that if you emulate decimal mode, several games go absolutely
bonkers (Wizards and Warriors III, Solar Jetman, etc.) just reinforces this.
Later,
Matt.
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Tue Apr 13, 1999 7:37 am
Subject: Re: SNSS Revision Request - Byte Order
> From: Neill Corlett <corlett@e...>
> With all the bickering over which byte order this (hypothetical) format is
> going to use... why can't there be a compromise?
Not a hypothetical format -- working nicely in Nofrendo, loopynes, and
NES4PC.
Will take the prior agreed upon iNES profit money in cash or check, Marat.
=)
Later,
Matt.
*********************************************************************************
From: Barubary <barubary@xxxx.xxxx
Date: Tue Apr 13, 1999 7:43 am
Subject: Re: SNSS Revision Request - Byte Order
>Nope, SNSS should stay in human-readable MSB. We've been over this; SNSS is
>there for the convenience of the _user_, not the coder.
Do you realize that anyone who would look at the file in a hex editor would
already EXPECT Intel byte order?
-- Barubary
*********************************************************************************
From: Mark <mark_k@xxxxx.xxxx
Date: Tue Apr 13, 1999 9:52 am
Subject: Some followups
Re: NES Music Ripping
---------------------
>> One thing I have to know though: are the CPUs in the PAL and NTSC
>> versions of the NES *identical*, so that the DPCM frequencies (as well
The CPUs are not identical. For one thing, the 26M master clock in PAL consoles
is divided by 15 by the CPU, whereas the master clock is divided by 12 in NTSC
consoles.
I can't say I ever noticed differences in the pitch of notes between PAL and
NTSC consoles, but then I'm probably tone deaf...
The most noticeable difference is of course due to the differing frame rates.
Since music is usually timed relative to the frame rate, the tempo speeds up by
20% when a PAL game is played on an NTSC console. Many PAL games have music
which is adjusted to play at the correct speed on PAL consoles. A hardware
player would have to take this into account somehow. Maybe there could be
hardware to trigger an IRQ after a certain time, and the music play routine
would run off that.
Re: NES Music Ripping / PCM / 4011h
-----------------------------------
On 12-Apr-99, Kevin Horton wrote:
> The only thing I haven't checked (and will tomorrow, since I forgot tonight)
> was to see if the DAC holds its value indefinately until it's changed... I'm
> 99.9% certain it does since I didn't see any droop or other artefacts.. just
> some nice clean steps.
>
> I checked this off of pin 2 on the processor (outputs PCM/4011, triangle, and
> noise channels; pin 1 outputs both squares) on my oscilloscope using DC
> coupling.
It would probably be a good idea to check the signal on the NES audio out jack
as well, since that is where the real signal as heard by the player is. The
signal is AC coupled inside the NES, so if you set the DAC to a certain value
you may find the actual audio signal measured at the jack decays towards zero.
Re: Intresting 4017h Stuff Just Discovered
------------------------------------------
On 12-Apr-99, JDC wrote:
> +---------+----------------------------------------------------------+
> | $4017 | Joypad #2/SOFTCLK (RW) |
> | | |
> | | READING: |
> | | D7: Vertical Clock Signal (External) |
> | | 0 = Not occuring |
> | | 1 = Occuring |
> | | D6: Vertical Clock Signal (Internal) |
> | | 0 = Occuring (D6 of $4016 affected) |
> | | 1 = Not occuring (D6 of $4016 untouchable) |
> +---------+----------------------------------------------------------+
>
> Your experience with CV3 is another example. Personally I have
> NO IDEA what a "Vertical Clock Signal" is, but any help would
> make the document more verbose.
"Vertical clock signal" is probably a bad translation of IRQs. So D7 & D6 would
indicate the source of the interrupt, external (e.g. MMC3) or internal (audio).
The IRQ routine could examine these bits and act accordingly.
Re: Color Dreams fix
--------------------
On 12-Apr-99, Barubary wrote:
> Me and loopy came to the conclusion that many Color Dreams' headers are
> corrupt - as a result, ALL mapper 11 games, regardless of header, are
> *VERTICAL* mirroring games.
Perhaps better to say that all mapper 11 games dumped so far use vertical
mirroring. There may be others which don't, so it's not a good idea to
restrict the definition of mapper 11 to only vertical mirroring.
Re: SNSS Revision Request - Byte Order
--------------------------------------
On 12-Apr-99, Matthew Conte wrote:
> Do you realize that byte-order only comes into play when you are
> reading/writing 16-bit and 32-bit integers directly to/from the state file
> (of which there are precious few)?
Not to mention that, if you want your (C) code to be portable, you cannot make
assumptions about how the compiler will align structures, or any alignment
restrictions imposed by the CPU. So you have to read the state file
byte-by-byte anyway. It is simple to use macros for this, and if you're using
macros it's extremely easy to change the byte order.
-- Mark
*********************************************************************************
From: "John Stiles" <stiles@xxxxxxxxx.xxxx
Date: Tue Apr 13, 1999 9:02 am
Subject: Re: SNSS Revision Request - Byte Order
>>Nope, SNSS should stay in human-readable MSB. We've been over this; SNSS is
>>there for the convenience of the _user_, not the coder.
>
> Do you realize that anyone who would look at the file in a hex editor would
> already EXPECT Intel byte order?
Hey, I wouldn't.
*Stiles
*********************************************************************************
From: Nyef <nyef@xxxxxxxx.xxxx
Date: Tue Apr 13, 1999 10:11 am
Subject: Re: Some followups
On Mon, 12 Apr 1999, Mark wrote:
> Re: Intresting 4017h Stuff Just Discovered
> ------------------------------------------
> On 12-Apr-99, JDC wrote:
> > +---------+----------------------------------------------------------+
> > | $4017 | Joypad #2/SOFTCLK (RW) |
> > | | |
> > | | READING: |
> > | | D7: Vertical Clock Signal (External) |
> > | | 0 = Not occuring |
> > | | 1 = Occuring |
> > | | D6: Vertical Clock Signal (Internal) |
> > | | 0 = Occuring (D6 of $4016 affected) |
> > | | 1 = Not occuring (D6 of $4016 untouchable) |
> > +---------+----------------------------------------------------------+
> >
> > Your experience with CV3 is another example. Personally I have
> > NO IDEA what a "Vertical Clock Signal" is, but any help would
> > make the document more verbose.
>
> "Vertical clock signal" is probably a bad translation of IRQs. So D7 & D6
would
> indicate the source of the interrupt, external (e.g. MMC3) or internal
(audio).
> The IRQ routine could examine these bits and act accordingly.
Okay, now how about the case of Dragon Quest 1? It sets $4017 to 0x00
(thus enabling internal IRQs), but doesn't use the sound at all as far as
I can tell.
I'm thinking that perhaps I should start monitoring some other ports for
"unusual activity".
---------------------------
One Bill to rule them all, One Bill to find them,
One Bill to bring them all, and using Windows bind them.
In the land of Redmond, where the shadows lie.
---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@s...
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Tue Apr 13, 1999 10:33 am
Subject: Re: Some followups
> From: Nyef <nyef@s...>
> Okay, now how about the case of Dragon Quest 1? It sets $4017 to 0x00
> (thus enabling internal IRQs), but doesn't use the sound at all as far as
> I can tell.
May just be routine practice on the coder's part - note that MMC1 ROMs
without VROM will often clear regs 1 & 2.
Ian Bell's tank demo writes $64 to $4017; of course, it's the only damn line
in the source code without a comment... =)
> I'm thinking that perhaps I should start monitoring some other ports for
> "unusual activity".
You're not going to find much except some stray reads and writes in the
$4020 - $5FFF range. I don't believe Jeremy's conjecture that this area
mirrors $4000-$4017 on 32 byte boundaries. Much more likely is the fact
that writes corresponded to some functionality on the software programmer's
development hardware.
Later,
Matt.
*********************************************************************************
From: Kevin Horton <khorton@xxxxxx.xxxx
Date: (Date Unavailable)
Subject: Re: Some followups & more on 4011h
At 08:11 PM 4/12/99 -0400, you wrote:
From: Nyef <nyef@s...>
>Okay, now how about the case of Dragon Quest 1? It sets $4017 to 0x00
>(thus enabling internal IRQs), but doesn't use the sound at all as far as
>I can tell.
AFAIK this disables interrupts and causes holy hell if you CLI. With 4017h
set to 00h, you will get runaway IRQs if you do a CLI. The second the
IRQ handler finishes and performs the RTI, it will invoke another IRQ.
This is the problem I had on my hardware .NSF player. I believe the upper
two bits correspond to interrupt sources. 1=on, 0=off. If both are off then
you have the afore-mentioned interrupt problem.
--------
Speaking of the .NSF player here's a minor update. After some minor tweaking
I got the counter/timer I designed into the FPGA working today. It is composed
of a counter off of the main system clock, divided by two running into a 16
bit binary counter.
There's another 16 bit register which is the terminal count. When the counter
equals the terminal count, the counter is reset and the interrupt latch is set,
which issues an IRQ to the processor. The IRQ handler then resets the
interrupt latch.
This gives me a nice way to generate the desired VBL interrupt frequency
(60Hz for NTSC, 50Hz for PAL) or any arbitrary frequency from 12Hz or so all the
way to greater than 40Khz :-) Some code will tranform the 1/100000th of a
second spec in the NSF file to the proper value to be loaded into the player's
counter reg.
Got bankswitch and the rest of the address decoding to test yet, as well as
inputs from pushbuttons.
--------
4011h stuff
Got the final info for this done. The output is indeed a DC offset level.
Also of note is that 4015h does *not* affect it! 4011h is always "on"
reguardless of the bits in 4015h. I don't know if this was known or not, so
I thought I would mention it in any event.
>
>I'm thinking that perhaps I should start monitoring some other ports for
>"unusual activity".
>
>---------------------------
>One Bill to rule them all, One Bill to find them,
>One Bill to bring them all, and using Windows bind them.
>In the land of Redmond, where the shadows lie.
>---------------------------
>All programming can be viewed as an exercise.
>---------------------------
>Alastair Bridgewater
>e-mail: nyef@s...
>
>
>------------------------------------------------------------------------
>You can now easily share photos and documents with your fellow list members
>http://www.ONElist.com
>Check out our homepage for details on how to use our new shared files feature!
>
>
*********************************************************************************
From: Kevin Horton <khorton@xxxxxx.xxxx
Date: (Date Unavailable)
Subject: Re: Some followups
At 08:33 PM 4/12/99 -0400, you wrote:
>From: "Matthew Conte" <itsbroke@c...>
>
>> From: Nyef <nyef@s...>
>
>> Okay, now how about the case of Dragon Quest 1? It sets $4017 to 0x00
>> (thus enabling internal IRQs), but doesn't use the sound at all as far as
>> I can tell.
>
>May just be routine practice on the coder's part - note that MMC1 ROMs
>without VROM will often clear regs 1 & 2.
>
>Ian Bell's tank demo writes $64 to $4017; of course, it's the only damn line
>in the source code without a comment... =)
As long as you do not use the IRQ, the value written doesn't really matter
too much.
>> I'm thinking that perhaps I should start monitoring some other ports for
>> "unusual activity".
>
>You're not going to find much except some stray reads and writes in the
>$4020 - $5FFF range. I don't believe Jeremy's conjecture that this area
>mirrors $4000-$4017 on 32 byte boundaries. Much more likely is the fact
I don't believe it either... The main reason I don't is because these addresses
are decoded internally on the processor itself, and only 5 pins emerge.
(these are: reading 4016h, reading 4017h (these are piped to the latches for
the controllers), and bits 2-0 of 4016h when it is written to). usually they
will do a full decode on internal regs because it doesn't cost anything and
makes life alot easier if you wish to use this space for stuff. Also, I've seen
writes to 4100h on somari. This of course would screw with the sound reg
located at 4000h if mirroring were in effect, but obviously it doesn't.
I will do some testing tomorrow to see what happens when areas are read from
or written to in the 4000-4fffh area. BTW I know that 5000-5fffh is free since
this is where my control EPROM maps :-) I didn't want to use 4000-4fff due to
stray writes possibly screwing things up.
>that writes corresponded to some functionality on the software programmer's
>development hardware.
I would tend to believe this one... good case on that is somari. It writes
various things to 4100h all over the code for apparently no reason. Also I
heard that the FDS puts some of its own regs in the 4018-4100h space and saw
same on super mario bros. 2j. So if they were mirrors this would fuck things
up royally :-)
Speaking of mirroring, 2000-3fffh is mirrored because the address decoding for
the PPU is performed externally by a 74139 dual 2 to 4 line decoder.
The PPU only has a few address lines on it, and they are tied to the lowest
address lines on the processor. (hence the mirroring) The 4000h stuff, however
is *not* decoded by an external address decoder, but is decoded internally
by the processor.
*********************************************************************************
From: Lavos999@xxx.xxx
Date: Tue Apr 13, 1999 1:15 pm
Subject: Re: Some followups
In a message dated 4/12/99 7:49:13 PM Pacific Daylight Time,
khorton@i... writes:
> I will do some testing tomorrow to see what happens when areas are read from
> or written to in the 4000-4fffh area. BTW I know that 5000-5fffh is free
> since
> this is where my control EPROM maps :-) I didn't want to use 4000-4fff
due
> to
> stray writes possibly screwing things up.
$5000-$5FFF is also used by MMC5 for registers and EXRAM, I believe.
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Tue Apr 13, 1999 3:08 pm
Subject: Silly Famicom question.
This just occurred to me, and irks me for some reason. Why do some games
like Contra (J) use the PCM channel when the Famicom, from what I've heard,
does not even have a PCM channel?
And didn't goroh say that he did his all of his testing on an NTSC Famicom,
and yet he produced a chart of the PCM frequencies?!? WTF?
Later,
Shady.
*********************************************************************************
From: Lavos999@xxx.xxx
Date: Tue Apr 13, 1999 3:09 pm
Subject: Re: Silly Famicom question.
In a message dated 4/12/99 10:08:31 PM Pacific Daylight Time,
itsbroke@c... writes:
> This just occurred to me, and irks me for some reason. Why do some games
> like Contra (J) use the PCM channel when the Famicom, from what I've heard,
> does not even have a PCM channel?
I suspect that what was meant was that the Famicom doesn't have the DAC
($4011). Obviously the Famicom does have delta modulation, as numerous Konami
titles (TwinBee 3, Contra Japanese, Kid Dracula) use it.
*********************************************************************************
From: "goroh" <goroh_kun@xxxxxxxxx.xx.xxx
Date: Tue Apr 13, 1999 8:16 pm
Subject: Re: Silly Famicom question.
Hi,I'm goroh.
>From: "Matthew Conte" <itsbroke@c...>
>
>This just occurred to me, and irks me for some reason. Why do some games
>like Contra (J) use the PCM channel when the Famicom, from what I've heard,
>does not even have a PCM channel?
>
>And didn't goroh say that he did his all of his testing on an NTSC Famicom,
>and yet he produced a chart of the PCM frequencies?!? WTF?
>
>Later,
>Shady.
Japanese NES(Famicom) has Delta Modulation Channel($4010-$4013)
I don't know what DAC means.
Does American NES have a special device to play Delta Modulation?
CPU of Famicom performs Delta Modulation with own special module.
$4010 AB--ffff
A: if B=0, interrupt occers when finished playing.
B: Play-Mode 0:no-Loop 1:Loop
ffff : frequency
Famicom performs Delta Modulation by reading ROM($c000-$ffff).
,This access occers every some clocks.
ffff clocks 428*8 mean CPU perform 1bit every 428clock,so DMA
occers every 428*8 clock.
0 428*8
1 380*8
2 340*8
3 320*8
4 286*8
5 254*8
6 226*8
7 214*8
8 190*8
9 160*8
10 142*8
11 128*8
12 106*8
13 85*8
14 72*8
15 54*8
$4011 Immediate volume
$4012 Delta Channel DMA Address Register
This register means where CPU starts reading ROM.
Address = $c000+(data<<6)
$4013 Delta Channel Data count Register
This register means how meny data access occer.
AmountofData = data<<4+1
$4015 bit ...Edcba
E: E=1 play sound. E=0 stop sound
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Tue Apr 13, 1999 9:58 pm
Subject: Re: Silly Famicom question.
> From: "goroh" <goroh_kun@g...>
> Hi,I'm goroh.
Hi goroh, I'm Matt. Thanks for your informative posts and experimental
results of the past!
> Japanese NES(Famicom) has Delta Modulation Channel($4010-$4013)
OK, that was my question. =)
> I don't know what DAC means.
Digital to Analog Converter -- this is the "Immediate Volume" you speak of
in register $4011. The DAC translates the 7-bit writes to this register
into DC voltage, and this gets added to the final output waveform. Games
which write to $4011 usually do so for speech samples (Blades of Steel,
Gauntlet 2, etc.), and usually time the outputs based on HBlanks. Thus,
accurate emulation requires synchronization with CPU cycles (can be achieved
through simple timestamping).
> Does American NES have a special device to play Delta Modulation?
> CPU of Famicom performs Delta Modulation with own special module.
No, the CPU of the NES performs the DMA as well.
[...]
> ffff clocks 428*8 mean CPU perform 1bit every 428clock,so DMA
> occers every 428*8 clock.
>
> 0 428*8
You posted a chart some time ago which had the amount of cycles stolen away
from the CPU due to the DMA. Could you explain that again?
> $4011 Immediate volume
This is the DAC.
> $4013 Delta Channel Data count Register
> This register means how meny data access occer.
> AmountofData = data<<4+1
Yes, this reminds me: Jeremy, you should change your description of $4013,
as the length really is (data * 16) + 1 bytes, not (data * 128) + 1 bits.
Later,
Shady.
*********************************************************************************
From: JDC <yoshi@xxxxxxxx.xxxx
Date: Tue Apr 13, 1999 10:11 pm
Subject: Re: Silly Famicom question.
On 04/13/1999 (07:58:56), itsbroke@c... wrote:
> > Japanese NES(Famicom) has Delta Modulation Channel($4010-$4013)
>
> OK, that was my question. =)
So the Japanese NES _DOES_ in fact have DMC (RAW & DMA)
support?
If so, then why did Nintendo add digital output support
to MMC5? I thought that was one of the things that was
added due to the lack-of DMC on the Famicom.
> > $4013 Delta Channel Data count Register
> > This register means how meny data access occer.
> > AmountofData = data<<4+1
>
> Yes, this reminds me: Jeremy, you should change your description of $4013,
> as the length really is (data * 16) + 1 bytes, not (data * 128) + 1 bits.
Semi-ambiguous. "(data*16)+1". Is the *16 representing *16 bits,
or *16 bytes? I just wanna make sure I get the right thing
down.
--
| Jeremy Chadwick yoshi@d... |
| Parodius Networking yoshi@p... |
| System Administrator/CGI Programmer 650-551-8916 |
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Tue Apr 13, 1999 10:26 pm
Subject: Re: Silly Famicom question.
> From: JDC <yoshi@p...>
> So the Japanese NES _DOES_ in fact have DMC (RAW & DMA)
> support?
>
> If so, then why did Nintendo add digital output support
> to MMC5? I thought that was one of the things that was
> added due to the lack-of DMC on the Famicom.
Was MMC5 even used for Japanese games? (Sorry kids, the only MMC5 ROM I
have is CV3)
> Semi-ambiguous. "(data*16)+1". Is the *16 representing *16 bits,
> or *16 bytes? I just wanna make sure I get the right thing
> down.
! Bytes. (data * 16) is a number of bytes. Then tack on an extra byte,
just because the NES sound system has a +1 in just about every aspect of its
sound generation to avoid divide by zero errors.
Later,
Matt.
*********************************************************************************
From: JDC <yoshi@xxxxxxxx.xxxx
Date: Tue Apr 13, 1999 11:31 pm
Subject: Re: Silly Famicom question.
On 04/13/1999 (08:26:27), itsbroke@c... wrote:
> > So the Japanese NES _DOES_ in fact have DMC (RAW & DMA)
> > support?
> >
> > If so, then why did Nintendo add digital output support
> > to MMC5? I thought that was one of the things that was
> > added due to the lack-of DMC on the Famicom.
>
> Was MMC5 even used for Japanese games? (Sorry kids, the only MMC5 ROM I
> have is CV3)
I know of two MMC5 games; CV3(US) and Uncharted Waters. I'm
sure there's a few more, but I've yet to run into them.
> > Semi-ambiguous. "(data*16)+1". Is the *16 representing *16 bits,
> > or *16 bytes? I just wanna make sure I get the right thing
> > down.
>
> ! Bytes. (data * 16) is a number of bytes. Then tack on an extra byte,
> just because the NES sound system has a +1 in just about every aspect of its
> sound generation to avoid divide by zero errors.
So, the value written to $4013 is the length in 16 byte increm-
ents? E.g. $1B would represent a length of 432 bytes?
I just wanna make sure I understand how this works.
--
| Jeremy Chadwick yoshi@d... |
| Parodius Networking yoshi@p... |
| System Administrator/CGI Programmer 650-551-8916 |
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Tue Apr 13, 1999 11:50 pm
Subject: Re: Silly Famicom question.
> From: JDC <yoshi@p...>
> I know of two MMC5 games; CV3(US) and Uncharted Waters. I'm
> sure there's a few more, but I've yet to run into them.
There's a bunch of KOEI games that use MMC5 as well, but I don't know
anything about them (e.g. if they were Japanese or not).
> So, the value written to $4013 is the length in 16 byte increm-
> ents? E.g. $1B would represent a length of 432 bytes?
Plus 1!!!
Write $1B to $4013:
$1B = 27 (dec)
(27 * 16) + 1 = 433 bytes.
Later,
Matt.
*********************************************************************************
From: "goroh" <goroh_kun@xxxxxxxxx.xx.xxx
Date: Wed Apr 14, 1999 1:11 am
Subject: Re: Silly Famicom question.
Hi,I'm goroh
>From: "Matthew Conte" <itsbroke@c...>
>
>> From: JDC <yoshi@p...>
>
>> So the Japanese NES _DOES_ in fact have DMC (RAW & DMA)
>> support?
>>
>> If so, then why did Nintendo add digital output support
>> to MMC5? I thought that was one of the things that was
>> added due to the lack-of DMC on the Famicom.
>
>Was MMC5 even used for Japanese games? (Sorry kids, the only MMC5 ROM I
>have is CV3)
Yes, Japanese mah-jongg game "YAKUMAN TENGOKU" uses MMC5 DMC.
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Wed Apr 14, 1999 1:24 am
Subject: Re: SNSS Revision Request - Byte Order
> With all the bickering over which byte order this (hypothetical) format is
> going to use... why can't there be a compromise?
I don't care. I already implemented the macro, and if i wanna switch back
to LSB, then I simply comment out my current macros and them define them as
the value passed to it and I'm back to where we started. =)
>
> I personally suggest PDP byte ordering. ;)
>
>
> Neill
Dare I ask what da #@!& PDP byte ordering is?
-David
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Wed Apr 14, 1999 1:25 am
Subject: Re: SNSS Revision Request - Byte Order
> >Nope, SNSS should stay in human-readable MSB. We've been over this; SNSS
is
> >there for the convenience of the _user_, not the coder.
>
> Do you realize that anyone who would look at the file in a hex editor
would
> already EXPECT Intel byte order?
If they're dumb enough to check out the file format and forget to read the
"important notes" section they they deserve it.
>
> -- Barubary
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Wed Apr 14, 1999 1:26 am
Subject: Re: SNSS Revision Request - Byte Order
> >>Nope, SNSS should stay in human-readable MSB. We've been over this;
SNSS is
> >>there for the convenience of the _user_, not the coder.
> >
> > Do you realize that anyone who would look at the file in a hex editor
would
> > already EXPECT Intel byte order?
>
> Hey, I wouldn't.
>
> *Stiles
Hehehehe
You tell em, mac-boy. ;)
-David
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Wed Apr 14, 1999 1:28 am
Subject: Re: Some followups
> Okay, now how about the case of Dragon Quest 1? It sets $4017 to 0x00
> (thus enabling internal IRQs), but doesn't use the sound at all as far as
> I can tell.
>
> I'm thinking that perhaps I should start monitoring some other ports for
> "unusual activity".
Well writing to the joypad port also sets the strobe bit. Or are you saying
that in the middle of nowhere it just wrote $00 to $4017 and didn't follow
it up by writing a $01 to it?
-David
*********************************************************************************
From: JDC <yoshi@xxxxxxxx.xxxx
Date: Wed Apr 14, 1999 1:32 am
Subject: Re: Silly Famicom question.
On 04/14/1999 (00:11:29), goroh_kun@g... wrote:
> >> So the Japanese NES _DOES_ in fact have DMC (RAW & DMA)
> >> support?
> >>
> >> If so, then why did Nintendo add digital output support
> >> to MMC5? I thought that was one of the things that was
> >> added due to the lack-of DMC on the Famicom.
> >
> >Was MMC5 even used for Japanese games? (Sorry kids, the only MMC5 ROM I
> >have is CV3)
>
> Yes, Japanese mah-jongg game "YAKUMAN TENGOKU" uses MMC5 DMC.
Then why would MMC5 have DMC if the NES & Famicom both already
have it?
Here we go again, on a long goose-chase. I have a feeling the
Famicom does not have any form of DMC support, which is what
we expected all along. Goroh, if you can actually provide us
with info which says that the Famicom **DOES** have native DMC
support (without MMC5), then all power to ya.
But, if it does, that makes MMC5's digital support nearly
useless. The only use I see for it is to play two digital
samples simultaneously: one via MMC5, and one via DMC. Quite
silly if you ask me, and highly unprobable. Maybe MMC5's digital
output is different... see below.
I figure Gryzor ("Contra Japanese") stores crap to the DMC regs
because Konami planned on releasing it in the US, hence the
programmers might as well make it easy to export. Take note:
Gryzor actually uses Konami's VRC2b mapper. Possibly the mapper
has some kind-of cheap digital output? (Just idealizing).
So, to make it easy on everyone:
1) Does the Famicom have native DMC support?
2) Does MMC5's DMC differ, output-wise, from the native DMC
method used in the NES?
3) If the Famicom does in fact have native DMC, then what is
the point of having DMC in MMC5?
--
| Jeremy Chadwick yoshi@d... |
| Parodius Networking yoshi@p... |
| System Administrator/CGI Programmer 650-551-8916 |
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Wed Apr 14, 1999 1:44 am
Subject: Re: Silly Famicom question.
> From: JDC <yoshi@p...>
> Here we go again, on a long goose-chase. I have a feeling the
> Famicom does not have any form of DMC support, which is what
> we expected all along.
Not to be a dick, but I'd much rather go with goroh's experimental
information (which so far, has all proven to be 100% accurate), than your
'feeling.'
> Goroh, if you can actually provide us
> with info which says that the Famicom **DOES** have native DMC
> support (without MMC5), then all power to ya.
goroh got a bunch of experimental data on the DMC from his famicom! Of
course it has PCM channel!
> But, if it does, that makes MMC5's digital support nearly
> useless. The only use I see for it is to play two digital
Are you even sure that MMC5 *has* a PCM channel on it??? Though I don't
have the CV3 cart, I've looked at goroh's doc, and it seems as though
$5000-5015 are just write-through ports to $4000-4015. I don't see mention
of a separate PCM channel at all.
I think you're getting confused with the mapper hardware used for
CastleVania3 Japanese, which was totally different, and really did have a
sound system on it.
Later,
Matt.
*********************************************************************************
From: JDC <yoshi@xxxxxxxx.xxxx
Date: Wed Apr 14, 1999 2:06 am
Subject: Re: Silly Famicom question.
On 04/13/1999 (11:44:30), itsbroke@c... wrote:
> > Goroh, if you can actually provide us
> > with info which says that the Famicom **DOES** have native DMC
> > support (without MMC5), then all power to ya.
>
> goroh got a bunch of experimental data on the DMC from his famicom! Of
> course it has PCM channel!
> > But, if it does, that makes MMC5's digital support nearly
> > useless. The only use I see for it is to play two digital
>
> Are you even sure that MMC5 *has* a PCM channel on it??? Though I don't
> have the CV3 cart, I've looked at goroh's doc, and it seems as though
> $5000-5015 are just write-through ports to $4000-4015. I don't see mention
> of a separate PCM channel at all.
The information originally came from FanWen, who gets his
information from some guy who worked for either Front Far East
or Nintendo of Japan (I forget which).
Besides, Goroh verified in his previous Email:
"Yes, Japanese mah-jongg game "YAKUMAN TENGOKU" uses MMC5 DMC."
> I think you're getting confused with the mapper hardware used for
> CastleVania3 Japanese, which was totally different, and really did have a
> sound system on it.
CV3j (Akumajo Dracula 3) uses Konami's VRC6. I'm quite aware
of the differences between CV3(US) and CV3j.
What I *AM* confused about is what I posted regarding. If there
is in fact DMC support native to the Famicom, then why is it
I've yet to see any games that use it (if Gryzor even does, for
that matter). And even if games *DON'T* use it, then why is
there DMC support via MMC5?
I already posted these questions, and I don't want to repeat
them again. I just want straight answers, so we can all get
valid info and be done with this beast of a discussion.
--
| Jeremy Chadwick yoshi@d... |
| Parodius Networking yoshi@p... |
| System Administrator/CGI Programmer 650-551-8916 |
*********************************************************************************
From: "goroh" <goroh_kun@xxxxxxxxx.xx.xxx
Date: Wed Apr 14, 1999 2:28 am
Subject: Re: Silly Famicom question.
Hi,I'm goroh.
MMC5 DMC is defferent to Delta Modulation Sound.
MMC5 DMC doesn't use DMA, so you should use program
read/write to MMC5 special register.
I don't know clearly how to operate these register.
MMC5 DMC can play various wave form.
see, US patent 5317714
Delta Modulation Sound use DMA.
And wave form is limited.
"YAKUMAN TENGOKU" uses MMC5 DMC to play human voice more clearly
than Delta Modulation Sound.
> Here we go again, on a long goose-chase. I have a feeling the
> Famicom does not have any form of DMC support, which is what
> we expected all along. Goroh, if you can actually provide us
> with info which says that the Famicom **DOES** have native DMC
> support (without MMC5), then all power to ya.
>
> But, if it does, that makes MMC5's digital support nearly
> useless. The only use I see for it is to play two digital
> samples simultaneously: one via MMC5, and one via DMC. Quite
> silly if you ask me, and highly unprobable. Maybe MMC5's digital
> output is different... see below.
>
> I figure Gryzor ("Contra Japanese") stores crap to the DMC regs
> because Konami planned on releasing it in the US, hence the
> programmers might as well make it easy to export. Take note:
> Gryzor actually uses Konami's VRC2b mapper. Possibly the mapper
> has some kind-of cheap digital output? (Just idealizing).
>
> So, to make it easy on everyone:
>
> 1) Does the Famicom have native DMC support?
native DMC means generate sound by writing $4011 frequently?
If so, It's impossible.
> 2) Does MMC5's DMC differ, output-wise, from the native DMC
> method used in the NES?
> 3) If the Famicom does in fact have native DMC, then what is
> the point of having DMC in MMC5?
>
--goroh
*********************************************************************************
From: "goroh" <goroh_kun@xxxxxxxxx.xx.xxx
Date: Wed Apr 14, 1999 2:30 am
Subject: Re: Silly Famicom question.
Hi,I'm goroh
>> I don't know what DAC means.
>
>Digital to Analog Converter -- this is the "Immediate Volume" you speak of
>in register $4011. The DAC translates the 7-bit writes to this register
>into DC voltage, and this gets added to the final output waveform. Games
>which write to $4011 usually do so for speech samples (Blades of Steel,
>Gauntlet 2, etc.), and usually time the outputs based on HBlanks. Thus,
>accurate emulation requires synchronization with CPU cycles (can be achieved
>through simple timestamping).
>> Does American NES have a special device to play Delta Modulation?
>> CPU of Famicom performs Delta Modulation with own special module.
>
>No, the CPU of the NES performs the DMA as well.
>
OK, I see.
>> $4013 Delta Channel Data count Register
>> This register means how meny data access occer.
>> AmountofData = data<<4+1
>
>Yes, this reminds me: Jeremy, you should change your description of $4013,
>as the length really is (data * 16) + 1 bytes, not (data * 128) + 1 bits.
>
I've mistaken, you right.
Yes, Data length really is (data * 16) +1 bytes.
First 1byte DMA occers immediately, when you write 0x10bit to $4015.
--goroh
*********************************************************************************
From: Fredrik Olsson <flubba@xxxx.xxxxxxxx.xxx
Date: Wed Apr 14, 1999 5:24 am
Subject: Re: Some followups & more on 4011h
On 13-Apr-99, Kevin wrote:
> From: Kevin Horton <khorton@i...>
> At 08:11 PM 4/12/99 -0400, you wrote:
> --------
> 4011h stuff
> Got the final info for this done. The output is indeed a DC offset level.
> Also of note is that 4015h does *not* affect it! 4011h is always "on"
> reguardless of the bits in 4015h. I don't know if this was known or not,
> so I thought I would mention it in any event.
Can you test different samples and check if the samples get distorted (or
flattened out or what you would call it in english ;) when you set the
offset differently.
A friend had an idea how this would work actually.
You have a component of some kind (don't remember it now) and when feed with
zero it starts to lower the dc voltage untill it gets a one (1) then it
raises the dc voltage.
This is with in limited range ofcourse, so if you wanna play some sound that
you know have a long slope (lot of zeros or ones in a row) to begin with
maybe you set the dc offset to compensate for it ?
Regards
--
/Fredrik Olsson aka FluBBa of WarD. http://hem2.passagen.se/flubba/
Author of CoolNESs for Amiga.
*********************************************************************************
From: Lavos999@xxx.xxx
Date: Wed Apr 14, 1999 5:22 am
Subject: Re: Silly Famicom question.
In a message dated 4/13/99 9:05:36 AM Pacific Daylight Time,
yoshi@p... writes:
> What I *AM* confused about is what I posted regarding. If there
> is in fact DMC support native to the Famicom, then why is it
> I've yet to see any games that use it
No offense, but it's because you haven't looked closely enough. Using
NESticle and turning off all the channels except delta modulation, I just
verified that the following Japanese games all use it: Contra Japanese,
Gradius 2, TwinBee 3, and Kid Dracula.
> (if Gryzor even does, for that matter).
It does. Delta modulation is used to play drumbeat-style sounds, which seems
to be a popular use in both U.S. and Japanese games.
> And even if games *DON'T* use it, then why is
> there DMC support via MMC5?
According to goroh's description of MMC5 sound, one of the added channels
seems to be identical to the two built-in pulse wave channels. So it's not
unreasonable to think that the delta modulation channel in MMC5 is also
identical to the built-in one. The more sound channels available, the better.
*********************************************************************************
From: JDC <yoshi@xxxxxxxx.xxxx
Date: Wed Apr 14, 1999 5:53 am
Subject: Re: Silly Famicom question.
On 04/13/1999 (15:22:45), Lavos999@a... wrote:
> From: Lavos999@a...
>
> In a message dated 4/13/99 9:05:36 AM Pacific Daylight Time,
> yoshi@p... writes:
>
> > What I *AM* confused about is what I posted regarding. If there
> > is in fact DMC support native to the Famicom, then why is it
> > I've yet to see any games that use it
>
> No offense, but it's because you haven't looked closely enough. Using
> NESticle and turning off all the channels except delta modulation, I just
> verified that the following Japanese games all use it: Contra Japanese,
> Gradius 2, TwinBee 3, and Kid Dracula.
May I point out something about "turning off the delta modul-
ation channel in NESticle" -- Turning it off doesn't completely
turn it off. Turning it off just disables the DMA method, and
does not disable the RAW method.
> > And even if games *DON'T* use it, then why is
> > there DMC support via MMC5?
>
> According to goroh's description of MMC5 sound, one of the added channels
> seems to be identical to the two built-in pulse wave channels. So it's not
> unreasonable to think that the delta modulation channel in MMC5 is also
> identical to the built-in one. The more sound channels available, the better.
This partially contradicts what I've been told by FanWen,
so IMHO it's still all up in the air.
And again, to point out for a second time, Goroh just stated
that MMC5 does in fact have a DMC channel.
The question I had was: Goroh said the Famicom supported DMA,
but **NOT** the RAW DMC method. I decided to verify this my-
self, since I totally forgot about Twinbee 3 -- a cart I actually
own.
Sure enough, in TB3, when you start the first stage, the speech
"Air Island Stage" is played back. My question was, how was this
speech played? Being a Japanese title and all, and not using
MMC5.
I used NESticle to verify. As I said above, turning off the DMC
channel in NESticle only disables the DMA method. Sure enough,
the audio didn't play. Hooray.
Therefore, I'm convinced of the following 2 things:
* The Famicom contains "partial" DMC support. It supports the
DMA method, but *NOT* the RAW method (writes to $4011).
* There are a few Japanese titles which actually use the
native DMC registers (DMA only) for audio playback.
Now, about MMC5.
Does anyone here actually have detailed information about
what this mapper does/can do? Seems there's a lot of craziness
going around about what it's capabilities are. It's been ver-
ified that it has support for the DMC RAW method, but what's
this about adding support for new waveforms? The only mapper I
have seen which does is this Konami's VRC6.
I was even told it contains a 8-bit accumulator for use by
games, accessable via memory-mapped registers. True?
Goroh, it'd be wonderful if you could list off all the features
and capabilities that Nintendo's MMC5 contains.
Thanks everyone.
--
| Jeremy Chadwick yoshi@d... |
| Parodius Networking yoshi@p... |
| System Administrator/CGI Programmer 650-551-8916 |
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Wed Apr 14, 1999 6:58 am
Subject: Re: Silly Famicom question.
> MMC5 DMC doesn't use DMA, so you should use program
> read/write to MMC5 special register.
What it sounds like this means is that to play audio data, you write the
audio data to a MMC5 register, and then it plays the data in the register,
just as the gameboy plays PCM sound. This would seem to be, in some ways,
better than a DMA method. It would allow software to mix sound samples and
then write the mixed data to the registers. Instead of having fixed PCM
data stuck somewhere in the C000-FFF9 area, you could generate audio data on
the fly. I know most games would simply read PCM data from somewhere in
memory and write it, but it would allow so much more customization of how
sound was played than normal DMA/RAW playing.
-David
*********************************************************************************
From: loopy <zxcvzxcv@xxxxxxx.xxxx
Date: Wed Apr 14, 1999 8:42 am
Subject: the skinny on nes scrolling
---------
the current information on background scrolling is sufficient for most games;
however, there are a few that require a more complete understanding.
here are the related registers:
(v) vram address, a.k.a. 2006 which we all know and love. (16 bits)
(t) another temp vram address (16 bits)
(you can really call them 15 bits, the last isn't used)
(x) tile X offset (3 bits)
the ppu uses the vram address for both reading/writing to vram thru 2007,
and for fetching nametable data to draw the background. as it's drawing the
background, it updates the address to point to the nametable data currently
being drawn. bits 0-11 hold the nametable address (-$2000). bits 12-14 are
the tile Y offset.
---------
stuff that affects register contents:
(sorry for the shorthand logic but i think it's easier to see this way)
2000 write:
t:0000110000000000=d:00000011
2005 first write:
t:0000000000011111=d:11111000
x=d:00000111
2005 second write:
t:0000001111100000=d:11111000
t:0111000000000000=d:00000111
2006 first write:
t:0011111100000000=d:00111111
t:1100000000000000=0
2006 second write:
t:0000000011111111=d:11111111
v=t
scanline start (if background and sprites are enabled):
v:0000010000011111=t:0000010000011111
frame start (line 0) (if background and sprites are enabled):
v=t
note! 2005 and 2006 share the toggle that selects between first/second
writes. reading 2002 will clear it.
note! all of this info agrees with the tests i've run on a real nes. BUT
if there's something you don't agree with, please let me know so i can verify
it.
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download.html
*********************************************************************************
From: Mark <mark_k@xxxxx.xxxx
Date: Wed Apr 14, 1999 7:15 am
Subject: List archives
Hi,
As of yesterday, past postings to the list are accessible to list subscribers
by logging onto the http://www.onelist.com/ web site.
-- Mark
*********************************************************************************
From: Mark <mark_k@xxxxx.xxxx
Date: Wed Apr 14, 1999 7:18 am
Subject: Re: NES Music Ripping
On 11-Apr-99, Kevin Horton wrote:
> Hmmm... That would *almost* work. Though the regs at 4000h will screw you
> up :-/ There is a pin on the NES CPU though that is held grounded... this
> could very well be an enable for those internal regs... >:) One way to find
> out is to lift it to VCC and see what happens. Someone said it's really
> an ABORT input, though I highly doubt it. It could also be a /RDY input
> but I have a sneaky suspicion that it just might disable those internal
> regs... :-) When I get my hardware NSF player in a better state I will
> test that hypothesis.
The official mnemonic for this grounded pin is REDY, if that helps at all...
-- Mark
*********************************************************************************
From: Mark <mark_k@xxxxx.xxxx
Date: Wed Apr 14, 1999 7:57 am
Subject: Re: Some followups
On 13-Apr-99, Nyef wrote:
>> "Vertical clock signal" is probably a bad translation of IRQs. So D7 & D6
>> would indicate the source of the interrupt, external (e.g. MMC3) or internal
>> (audio). The IRQ routine could examine these bits and act accordingly.
>
> Okay, now how about the case of Dragon Quest 1? It sets $4017 to 0x00
> (thus enabling internal IRQs), but doesn't use the sound at all as far as
> I can tell.
The interrupt source bits are (probably) read-only. Writing those bits may do
something else completely.
-- Mark
*********************************************************************************
From: Mark <mark_k@xxxxx.xxxx
Date: Wed Apr 14, 1999 8:09 am
Subject: Re: Silly Famicom question.
On 13-Apr-99, goroh wrote:
>> Was MMC5 even used for Japanese games? (Sorry kids, the only MMC5 ROM I
>> have is CV3)
>
> Yes, Japanese mah-jongg game "YAKUMAN TENGOKU" uses MMC5 DMC.
A little reminder: the MMC5 audio features are covered quite nicely in US
patent #5,317,714. You can view this on http://www.patents.ibm.com/, or I can
upload a 300dpi TIFF file of this patent if anyone is interested.
(The audio function is Famicom-specific, since there are no audio I/O pins on
the NES cart connector.)
On 13-Apr-99, Matthew Conte wrote:
>Are you even sure that MMC5 *has* a PCM channel on it??? Though I don't
>have the CV3 cart, I've looked at goroh's doc, and it seems as though
>$5000-5015 are just write-through ports to $4000-4015. I don't see mention
>of a separate PCM channel at all.
Not sure whether you would call it PCM or not, but the above-mentioned patent
should shed some light on this. The relevant registers are at $5010 (read
only) and $5011 (write only).
If the Famicom does not have *DMA* PCM support but does have raw support, that
may explain the existence of the MMC5 audio feature, which "assists" sample
playing but is not DMA.
As I understand it, after setting things up appropriately, with the MCM5 audio
you can do something like:
LDA #val1
LDA #val2
LDA #val3
... etc...
instead of
LDA #val1
STA $4011
LDA #val2
STA $4011
LDA #val3
STA $4011
... etc...
-- Mark
*********************************************************************************
From: loopy <zxcvzxcv@n...>
Date: Wed Apr 14, 1999 9:48 am
Subject: Re: the skinny on nes scrolling
(more notes on ppu logic)
you can think of bits 0,1,2,3,4 of the vram address as the "x scroll"(*8)
that the ppu increments as it draws. as it wraps from 31 to 0, bit 10 is
switched. you should see how this causes horizontal wrapping between name
tables (0,1) and (2,3).
you can think of bits 5,6,7,8,9 as the "y scroll"(*8). this functions
slightly different from the X. it wraps to 0 and bit 11 is switched when
it's incremented from _29_ instead of 31. there are some odd side effects
from this.. if you manually set the value above 29 (from either 2005 or
2006), the wrapping from 29 obviously won't happen, and attrib data will be
used as name table data. the "y scroll" still wraps to 0 from 31, but
without switching bit 11. this explains why writing 240+ to 'Y' in 2005
appeared as a negative scroll value.
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download.html
*********************************************************************************
From: Lavos999@xxx.xxx
Date: Wed Apr 14, 1999 10:02 am
Subject: Re: Silly Famicom question.
In a message dated 4/13/99 4:28:42 PM Pacific Daylight Time, mark_k@i...
writes:
> If the Famicom does not have *DMA* PCM support but does have raw support
Other way around. Several games use delta modulation, but apparently the
Famicom lacks raw PCM.
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Wed Apr 14, 1999 10:06 am
Subject: Re: the skinny on nes scrolling
> 2000 write:
> t:0000110000000000=d:00000011
> 2005 first write:
> t:0000000000011111=d:11111000
> x=d:00000111
> 2005 second write:
> t:0000001111100000=d:11111000
> t:0111000000000000=d:00000111
> 2006 first write:
> t:0011111100000000=d:00111111
> t:1100000000000000=0
> 2006 second write:
> t:0000000011111111=d:11111111
> v=t
> scanline start (if background and sprites are enabled):
> v:0000010000011111=t:0000010000011111
> frame start (line 0) (if background and sprites are enabled):
> v=t
OK, I am _SO_ lost. Can you explain this any other way, or at least
describe what's happening here like in assembly terms and then the contents
of each of those 3 variables you're talking about after each
write/read/watever? =)
-David
*********************************************************************************
From: Kevin Horton <khorton@xxxxxx.xxxx
Date: (Date Unavailable)
Subject: Re: NES Music Ripping
At 09:18 PM 4/13/99 +0000, you wrote:
>From: Mark <mark_k@i...>
>
>On 11-Apr-99, Kevin Horton wrote:
>> out is to lift it to VCC and see what happens. Someone said it's really
>> an ABORT input, though I highly doubt it. It could also be a /RDY input
>> but I have a sneaky suspicion that it just might disable those internal
>> regs... :-) When I get my hardware NSF player in a better state I will
>> test that hypothesis.
>
>The official mnemonic for this grounded pin is REDY, if that helps at all...
If that's the case, then it's just a simple ready line. low=run, high=stop.
I will still verify it when I get a chance however. (BTW I noted something
sorta intresting on the 5 output pins of the processor chip- pins 35-39.
When you reset the unit, they all go tristate and stay tristated until reset
goes high again. (and /RST has a weak pullup too to boot :-)).
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Wed Apr 14, 1999 12:31 pm
Subject: Re: NES Music Ripping
> If that's the case, then it's just a simple ready line. low=run,
high=stop.
> I will still verify it when I get a chance however. (BTW I noted
something
> sorta intresting on the 5 output pins of the processor chip- pins 35-39.
> When you reset the unit, they all go tristate and stay tristated until
reset
> goes high again. (and /RST has a weak pullup too to boot :-)).
For the un-electronic-engineering-savvy (me me me!!), please define
tristate. =)
-David
*********************************************************************************
From: Tennessee Carmel-Veilleux <veilleux@xxxxx.xxxx
Date: Wed Apr 14, 1999 12:50 pm
Subject: Re: NES Music Ripping
On Tue, 13 Apr 1999, David de Regt wrote:
> > If that's the case, then it's just a simple ready line. low=run,
> high=stop.
> > I will still verify it when I get a chance however. (BTW I noted
> something
> > sorta intresting on the 5 output pins of the processor chip- pins 35-39.
> > When you reset the unit, they all go tristate and stay tristated until
> reset
> > goes high again. (and /RST has a weak pullup too to boot :-)).
> For the un-electronic-engineering-savvy (me me me!!), please define
> tristate. =)
>
Tri-state is easy, it's the solution to bus conflicting all accross the world
:) On a "regular" logic, the output it EITHER 1 (+VCC) or 0 (GND). However,
sometimes you don't want signals to mix on a bus, you want only the SELECTED
circuit to send information. Tri-state logic is the solution. You can put
tri-state logic (as the name implies) in a "third" state, which is neither 1
or 0 (often called "off mode", "hi-z" or "high impedance"). It puts the chip
in high impedance state (high impedance meaning HIGH (extremely high, almost
infinite) resistance, thus "shielding" the output and simulating a floating,
un-connected pin (something which doesn't give any current can't fuck-up your
bus, can it ? :) Whilst the chip is in high impedance mode, it still works
internally.
Regards,
--
Tennessee Carmel-Veilleux (Coordonator of Digital Meltdown)
veilleux@a... (www.ameth.org/~veilleux) ICQ ID : 8604827
Support Linux ! (www.linux.org;www.gnu.org) 1.99$ CD->(www.cheapbytes.com)
||*|| This message was written in Canada / Ce message a ete ecrit au Canada
*********************************************************************************
rom: Kevin Horton <khorton@xxxxxx.xxxx
Date: (Date Unavailable)
Subject: More NESM rips in .NSF and .NES format
Here's the complete set of rips I have done so far to date. Note some of the
files are .NES only. This is because they are still being worked on, or they
use bankswitching. I have finally worked out my bankswitching arrangement so
these will be taken care of here shortly.
The files are here:
http://www.iquest.net/~khorton/nesmus.zip
---------
Player progress:
I added a 2 line by 20 character display to my player so I can test out more
functionality. Got the bankswitching working as well as testing out the
address decoding. All seems well. I just need to add the PSX memory card
interface and some other things. For fun, I ripped off the little circuit
board on the front of an old CDROM drive. It has the audio amp, volume control,
and headphone jack portions. I hooked that up to the processor's audio pins.
Still need to try out some music on the thing; this is going to be difficult
since I only have 4K worth of space to store the music for loading; it will
take me several iterations to load one song in for playing.
If anyone wants me to try out some stuff on the NES processor lemme know. I've
got the display programmed up so I can write hex numbers to it directly. I'm
going to do a little poking around with the "decimal" mode to see if it does
anything funny when I SED.
*********************************************************************************
From: Chris Covell <ccovell@xxxxxx.xxx
Date: Wed Apr 14, 1999 5:34 pm
Subject: Re: More NESM rips in .NSF and .NES format
On 13-Apr-99, Kevin Horton wrote:
> From: Kevin Horton <khorton@i...>
> Here's the complete set of rips I have done so far to date. Note some of
the
> files are .NES only. This is because they are still being worked on, or
they
> use bankswitching. I have finally worked out my bankswitching arrangement
so
> these will be taken care of here shortly.
Speaking of which, I am almost done fixing up and making NSF files for the
games which I already mentioned. I have fixed the samples for Batman and
Journey to Silius, and am in the process of ordering the songs into indexes
for the rest of the Capcom games that I ripped. If anybody wants either the
.NES or .NSF files when I have finished, let me know.
--
Chris Covell (ccovell@d...)
http://www.sfu.ca/~ccovell/
Powered by Amiga!
*********************************************************************************
From: Fredrik Olsson <flubba@xxxx.xxxxxxxx.xxx
Date: Thu Apr 15, 1999 2:53 am
Subject: Re: Some followups (PAL/NTSC)
On 13-Apr-99, Mark wrote:
> From: Mark <mark_k@i...>
> Re: NES Music Ripping
> ---------------------
>>> One thing I have to know though: are the CPUs in the PAL and NTSC
>>> versions of the NES *identical*, so that the DPCM frequencies (as well
> The CPUs are not identical. For one thing, the 26M master clock in PAL
> consoles is divided by 15 by the CPU, whereas the master clock is divided
> by 12 in NTSC consoles.
> I can't say I ever noticed differences in the pitch of notes between PAL
> and NTSC consoles, but then I'm probably tone deaf...
Don't know about your hearing but check out James Bond JR, there are two
versions of the game. One is for PAL and the other for NTSC (well ;) , and
both have different speed and pitch =))
I don't actually know if there is a difference in the pitch between the
PAL/NTSC NES.
If somebody can make a smal wave-file from Metroid I can make one too (as I
have the NTSC version of the game but a PAL console =)
Regards
--
Fredrik Olsson aka FluBBa of WarD. http://hem2.passagen.se/flubba/
Author of CoolNESs for Amiga.
*********************************************************************************
From: Fredrik Olsson <flubba@xxxx.xxxxxxxx.xxx
Date: Thu Apr 15, 1999 5:57 am
Subject: Ian Bell's Tank game
I just read through the source for Ian Bell's Tank game and found some
interesting stuff.
In the definitions it says something about Joystick _and_ DMA port for $4016
& $4017.
It seems quite clear that he uses the PCM DMA to start IRQ's, according to
the source (if I'm right) 3 (!) times during a frame.
There is also a lot of info regarding timing and cycle counting.
You can find it at:
http://people.netcom.co.uk/i.bell/nestank
Regards
--
Fredrik Olsson aka FluBBa of WarD. http://hem2.passagen.se/flubba/
Author of CoolNESs for Amiga.
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Thu Apr 15, 1999 6:05 am
Subject: Re: Ian Bell's Tank game
> From: Fredrik Olsson <flubba@h...>
> It seems quite clear that he uses the PCM DMA to start IRQ's, according to
> the source (if I'm right) 3 (!) times during a frame.
He uses empty PCM samples to trigger precisely-timed IRQs.
"OK. First let me say, with apologies, that my notes file accompanying
the images is incomplete. I forgot to mention one aspect which may, in
fact, be a problem:
The use of the audio chip DMA transfer as a timing mechanism.
Intention: to maintain a repeating IRQ coinciding with (to as high an
accracy as possible) a given PPU raster position.
(only attempted to row resolution, ie. want IRQ at a given scanline) "
> There is also a lot of info regarding timing and cycle counting.
Which seems to be largely incorrect, or at least taken from a perspective
that I don't quite understand.
Later,
Matt.
*********************************************************************************
From: Nyef <nyef@xxxxxxxx.xxxx
Date: Thu Apr 15, 1999 10:00 am
Subject: Re: Some followups
On Tue, 13 Apr 1999, David de Regt wrote:
> From: "David de Regt" <akilla@e...>
>
> > Okay, now how about the case of Dragon Quest 1? It sets $4017 to 0x00
> > (thus enabling internal IRQs), but doesn't use the sound at all as far as
> > I can tell.
> >
> > I'm thinking that perhaps I should start monitoring some other ports for
> > "unusual activity".
>
> Well writing to the joypad port also sets the strobe bit. Or are you saying
> that in the middle of nowhere it just wrote $00 to $4017 and didn't follow
> it up by writing a $01 to it?
>
> -David
No, I'm saying that during initialization it wrote 0x00 to $4017, and
doesn't touch it afterwards. Being a 1-player game, this isn't suprising.
---------------------------
One N to rule them all, One N to find them,
One N to bring them all, and using the IDSA bind them.
In the land of Redmond, where the shadows lie.
---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@s...
*********************************************************************************
From: Kevin Horton <khorton@xxxxxx.xxxx
Date: (Date Unavailable)
Subject: Re: Some followups
At 08:00 PM 4/14/99 -0400, you wrote:
>From: Nyef <nyef@s...>
>
>On Tue, 13 Apr 1999, David de Regt wrote:
>
>> From: "David de Regt" <akilla@e...>
>>
>> > Okay, now how about the case of Dragon Quest 1? It sets $4017 to 0x00
>> > (thus enabling internal IRQs), but doesn't use the sound at all as far as
>> > I can tell.
>> >
>> > I'm thinking that perhaps I should start monitoring some other ports for
>> > "unusual activity".
>>
>> Well writing to the joypad port also sets the strobe bit. Or are you saying
>> that in the middle of nowhere it just wrote $00 to $4017 and didn't follow
>> it up by writing a $01 to it?
>>
>> -David
>
>No, I'm saying that during initialization it wrote 0x00 to $4017, and
>doesn't touch it afterwards. Being a 1-player game, this isn't suprising.
Remember: Writing 1 then 0 to 4016h will strobe *both* controllers!!!
Re: 4016/4017
Writing and reading to/from 4016 and 4017 are totally different from each other,
and the bits between the read and write of a single register have no bearing
on each other.
During reading of 4016 or 4017, the processor is *not* involved at all other
than to decode the actual register addresses. The data bits retrieved are
actually put on the bus by two 74HC386's. These are hex inverting tristate
buffers. Note that bits 6 and 7 will be undefined, since they do not have
a corresponding buffer. (the expansion port can have its own buffer to provide
4 extra bits, 2 for each 4016 and 4017 if so desired)
During writing, the processor is totally involved. There are no external
control signals given for any write to 4016 or 4017. They only affect internal
registers, and the 3 bit output port.
The 3 bit output port was pressed into service to strobe both controllers'
latch lines ("locks in" the 8 button readings, getting it ready to shift the
data out). 2 bits are not used, and pass onto the bottom expansion port.
The 3 bits correspond to bits 2-0 on 4016 (write). Only bit 0 is used to
strobe the controllers; bits 1 and 2 are there, but they do not go anywhere
at all (other than the useless exp. port). Bits 7-4 are unknowns.
4017 (write) seems to be a "processor control register" of some form. It does
perform some interrupt control, and possibly some other function. It has no
known controller function as far as I can see.
-------------
NSF/NESM player update: I got the thing to actually play music today! Played
both Megaman 2 and Snake's Revenge. Both sounded perfect. (including the
PCM sound) I need to implement the PSX memory card stuff now.
*********************************************************************************
From: Barubary <barubary@xxxx.xxxx
Date: Thu Apr 15, 1999 3:00 pm
Subject: Re: Silly Famicom question.
>This just occurred to me, and irks me for some reason. Why do some games
>like Contra (J) use the PCM channel when the Famicom, from what I've heard,
>does not even have a PCM channel?
>
>And didn't goroh say that he did his all of his testing on an NTSC Famicom,
>and yet he produced a chart of the PCM frequencies?!? WTF?
As the PCM channel address of the Famicom is unassigned, and the Famicom
allows mixing sound from the cart, I would think many Famicom games just
add their own PCM channel at the same addresses used on the NES.
-- Barubary
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Thu Apr 15, 1999 3:13 pm
Subject: Re: Some followups
> > Well writing to the joypad port also sets the strobe bit. Or are you
saying
> > that in the middle of nowhere it just wrote $00 to $4017 and didn't
follow
> > it up by writing a $01 to it?
> >
> > -David
>
> No, I'm saying that during initialization it wrote 0x00 to $4017, and
> doesn't touch it afterwards. Being a 1-player game, this isn't suprising.
Eeew.... Uhm heh... Woops. =)
So what's the verdict on what Nesdev's current best guess to D6-7 of $4017
are?
-David
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Thu Apr 15, 1999 3:39 pm
Subject: Bit order
Barubary's rantings have made me propose a new bit order for 32-bit
variables. Zero to the letter V are the bits in order:
6AFG-B251 CIKL-J3DT 9PO4-0KJL 5MN8-S9RE
I call it GG-Endian, for Game Genie-Endian
-David de Regt
*********************************************************************************
From: Kevin Horton <khorton@xxxxxx.xxxx
Date: (Date Unavailable)
Subject: bankswitched .NSF files
Note: this supercedes all previous messages about .NSF bankswitching and is
the final word on it. (since I have it working properly)
Well I've got the bankswitch format for .NSF files all figured out and tested.
Here's a quick description of how it works.
Offsets 70h-77h in the .NSF file specify the starting bank assignments.
Each bank is 4K in size, and there are 8 of them from 8000h-ffffh.
8000-8fff, 9000-9fff, a000-afff, etc. all the way to f000-ffff. The .NSF
file is internally composed up of a number of 4K banks. Every 4K from the
start of the actual data is a bank. Banks are numbered starting at 0.
(Just like on any other mapper).
To determine if your .NSF file is bankswitched or not, check out those bytes
at 70-77h. if they are all 00h then the tune is *not* bankswitched and you
load and run it as usual.
However, if one or more of those bytes contains a non-zero value, then load
the bankswitch registers with those 8 values. The bankswitch registers are
located at 5ff8h through 5fffh.
Each of the 8 bankswitch registers at 5ff8h through 5fffh correspond to one
of the main sections at 8000h-ffffh, each 4K in size (As discussed above).
5ff8h controls what data you see at 8000-8fffh
5ff9h controls what data you see at 9000-9fffh
.
.
.
5fffh controls what data you see at f000-ffffh
Note that NSF files cannot be bigger than 64K (this is hardly a problem.
Kirby's Adventure (a monster of a bankswitched tune set) is a bit over 36K).
Speaking of, here's how Kirby's Adventure works the bankswitch. You can
follow along by snagging the file at:
http://www.iquest.net/~khorton/kirbymus.nsf
OK, check out 70h-77h in the file. It is:
00h 01h 02h 03h 08h 08h 08h 08h
Since at least one of the bytes is not 00h then we know it's bankswitched.
And right away we can see how the data is to be loaded in at start.
8000-8fff gets the first 4K of the file,
9000-9fff gets the second 4K
a000-afff gets the third 4K and
b000-bfff gets the fourth 4K.
Now things get tricky. Notice that the last four all have 08h spec'd as
their bank. This is not a mistake. c000-efff was not used in this particular
tune so their value is inconsequental. I chose to set them to the last bank
for the fun of it.
Note that banks 4,5,6, and 7 are not specified anywhere in the above. This is
because the music player code will perform its own bankswitching. Check out
8130h or thereabouts in the player code (offset 0130h into the stored music
data of the .NSF file) and you will see where the banks are being changed,
and check out the LDA 8Axx,X to see where the bank info is coming from.
Well that's it. Not too tough eh? :-)
--------
PAL/NTSC bits.
I've thought about this for awhile and I think it's a worthy addition.
Shouldn't be too tough to add. Offset 078h will be the PAL/NTSC byte. It is
bitwise:
bit 0 is the PAL/NTSC bit. Set to 0 for NTSC, 1 for PAL
bit 1 is the "dual PAL/NTSC" bit. Set to 1 for dual mode
note: To select PAL/NTSC, load the X register with 0 (NTSC) or 1 (PAL) when
running the music's init routine.
bits 2-7 are not used and must be set to 0
Offsets 79h and 7ah are used to store the PAL playback rate if dual NTSC/PAL
mode is selected. It works the same as the NTSC rate.
The PAL/NTSC bit actually selects the clock frequency for the processor; either
PAL frequency (PAL colourburst * 6 / 15) or NTSC frequency
(NTSC colourburst * 6 / 12).
The dual bit tells if this music has both PAL and NTSC players/musics stored
in the same file, and the stored music data must make the switch depending on
the X register. (though the clock frequency will obviously change depending on
PAL/NTSC mode).
*********************************************************************************
From: Barubary <barubary@xxxx.xxxx
Date: Thu Apr 15, 1999 4:50 pm
Subject: Problems with SNSS
SNSS is by far too vague in its description of many of the bytes. I
already see several holes in his MMC3 description that could be used to
show how SNSS sucks. I haven't made an example program to demonstrate how
to glitch the save state system, however.
Here's something I HAVE done: a little example of ambiguity in the document.
This is from revision 5, mapper 1 description.
0-3 The 4 finished registers
4 Holding Register (the one that stores the bits until it gets 5)
5 Which bit the holding register is on
Bytes 4 and 5 are not clearly described - they are very much open to
interpretation. Below is an example of an interpretation that follows the
document's wording but is wrong.
Bytes 4 and 5 start at 0. When you write a bit to the MMC1, the bit of 4
with the bit number stored in 5 gets written, then 5 is incremented.
This is the real way SNSS is (according to akilla):
Bytes 4 and 5 start at 0. When you write a bit to the MMC1, byte 4 is
shifted left by 1 with the written bit carried in, and byte 5 is
incremented. (This results in a backwards written value BTW.)
Both match the verbal description, and both methods can be used in the
actual emulation of MMC1 - they both mean the same thing with regard to the
MMC1's current state. HOWEVER, they are not compatible at all between
different emulators.
What needs to happen is a very precisely defined SNSS format so that no
problems caused by ambiguity of the tech docs occurs, much like nestech is
(much less now, but still is.)
-- Barubary
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Thu Apr 15, 1999 5:05 pm
Subject: Re: Problems with SNSS
> SNSS is by far too vague in its description of many of the bytes. I
> already see several holes in his MMC3 description that could be used to
> show how SNSS sucks. I haven't made an example program to demonstrate how
> to glitch the save state system, however.
>
> Here's something I HAVE done: a little example of ambiguity in the
document.
>
> This is from revision 5, mapper 1 description.
>
> 0-3 The 4 finished registers
> 4 Holding Register (the one that stores the bits until it gets 5)
> 5 Which bit the holding register is on
>
> Bytes 4 and 5 are not clearly described - they are very much open to
> interpretation. Below is an example of an interpretation that follows the
> document's wording but is wrong.
So it's a little ambigious. I'll change it. Notice it's still in beta for
exactly these purposes.
>
> ...
> This is the real way SNSS is (according to akilla):
>
> Bytes 4 and 5 start at 0. When you write a bit to the MMC1, byte 4 is
> shifted left by 1 with the written bit carried in, and byte 5 is
> incremented. (This results in a backwards written value BTW.)
I never said which way it's shifted or anything. Don't put words in my
mouth.
>
> ...
>
> What needs to happen is a very precisely defined SNSS format so that no
> problems caused by ambiguity of the tech docs occurs, much like nestech is
> (much less now, but still is.)
>
> -- Barubary
It sounds like you're saying "SNSS sucks! It's MMC1 description's a little
vague! Let's go make a new one because of it!" If you have something to
bitch about other than a little vagueness in MMC1 then state it, otherwise
go away. I'm not gonna have something I've spent hours and hours writing
and that three emulator authors have spent hours implementing trashed by a
neurotic skript kiddie that feels like rewriting a whole doc over again.
While you're at it, add a glossary in the back for terms like "bit", "byte",
and "NES". Heck throw in "RAM" while you're at it, that's a little vague.
If you have problems with SNSS, list them to Nesdev if you'd like to show
off how you waste your free time or email them to me alone and I'll probably
fix them. I don't care how, just don't post to Nesdev hoping to rally
support against me by stretching a minor complaint into a multi-page email.
Ick, you're reminding me of Kenneth Star.
-David
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Thu Apr 15, 1999 5:10 pm
Subject: Re: Problems with SNSS
> SNSS is by far too vague in its description of many of the bytes. I
> already see several holes in his MMC3 description that could be used to
> show how SNSS sucks. I haven't made an example program to demonstrate how
> to glitch the save state system, however.
Hey buddy, by all means point out problem areas, but don't be a raging
blankety-blank about it. Let's see _your_ awesome state format.
SNSS needs some work, but the block concept is a much better deal than the
fixed length system used in NESticle and just about every other NES
emulator. I like the way that state files can end up being in the 7-14kB
range.
> This is from revision 5, mapper 1 description.
>
> 0-3 The 4 finished registers
> 4 Holding Register (the one that stores the bits until it gets 5)
> 5 Which bit the holding register is on
[...]
I agree that this needs to be clarified. The way I interpreted it was:
4 -- latch register. Filled in from D0 - D4, i.e. xxxx1 -> xxx11 -> xx111,
etc.
5 -- after a bit has been added to the latch, increments. If it hits 5,
it's reset and the latch is transferred into the finished register.
Other ambiguities exist -- especially in the mirroring section, but
hopefully David will have these problems resolved soon.
Later,
Matt.
*********************************************************************************
From: "Michel Iwaniec" <bananmos_uv@xxxxxxx.xxxx
Date: Fri Apr 16, 1999 11:21 am
Subject: Re: bankswitched .NSF files
>Note that NSF files cannot be bigger than 64K (this is hardly a
problem.
>Kirby's Adventure (a monster of a bankswitched tune set) is a bit
over 36K).
I really hate to be the one who always complains - but I disagree. :)
...I plan to do a music disk for the NES (before I try to do a real
demo) and I will definitly have tunes well beyond that limit...
probably gonna use up to 32k of DPCM samples just for speech in some
tune or two, since no one will really care about it taking up 256-512k
or so...
I know that no games we know of will require a bigger filesize, but I
can promise you that my future stuff (if I get it done that is :) will
not be convertible to NSF if that limit doesn't increase, and it would
be nice if it were...
- but! from your description of the bankswitching, I fail too see how
it would impose a 64k limit. 256*4k is a meg too me, and if I ever use
tunes bigger than that, do feel free to shoot me. :>
>The dual bit tells if this music has both PAL and NTSC players/musics
stored
>in the same file, and the stored music data must make the switch
depending on
>the X register.
thanks for this one! :P
Btw, my NSF player seems to work better now. I've fixed the SB sound
(now works for nearly everyone who's tried it) and switched to
Nesticle's 6502 emulator... it *should* work w/out problems now (yeah,
right... have I uttered those words before?.. ;)
same rules apply though: ULTRASND/BLASTER environment var must be set
correctly, don't run with too much stuff in the background (it could
crash)... and don't run on a too slow compu (I've tested it on a p100
in pure dos and 233mmx in Winblows95)... still only gives 22khz on
SB...
and the "can't find ULTRASND var.." is still present for SB users...
:>
some bugs also remain. envelopes and freq sweeps don't work and give
mostly silence when used. And the DPCM in SMB3 and CV2 is screwed, but
it works ok in SMB2 and Journey To Silius though... Snake's revenge
doesn't work at all...
download at http://www.erols.com/cyberj23/playnsf.zip - thanks to
CricketNE for the webspace!
btw Kevin, what *is* Somarims? Is it really Sonic for the NES?! :P
l8er
*********************************************************************************
From: Kevin Horton <khorton@xxxxxx.xxxx
Date: (Date Unavailable)
Subject: Re: bankswitched .NSF files
At 06:21 PM 4/15/99 PDT, you wrote:
>From: "Michel Iwaniec" <bananmos_uv@h...>
>
>>Note that NSF files cannot be bigger than 64K (this is hardly a
>
>I really hate to be the one who always complains - but I disagree. :)
>...I plan to do a music disk for the NES (before I try to do a real
>demo) and I will definitly have tunes well beyond that limit...
>I know that no games we know of will require a bigger filesize, but I
>can promise you that my future stuff (if I get it done that is :) will
>not be convertible to NSF if that limit doesn't increase, and it would
>be nice if it were...
Well the limit comes about because of my hardware. :-) I have 128K of RAM
on it, with 64K dedicated for the NSF data and 64K of everything else.
(0000-1fff, 5f80-5fef, and 6000-7fff all draw from this). Though I don't see
why I couldn't slap a 512K pseudoSRAM on there instead. (this is a dynamic RAM
chip with a static-ram-like interface... no refreshing required. They are very
nifty). Though the limit would be 512K-32K then (32K since that's all the
space required for the 0000-7fff junk)
So would you be happy with 480K maximum song size? IMO if your songs are
bigger than this I will shoot ya. ;-) I still want this to be an easily
doable hardware project for someone with as few chips as possible.
>Btw, my NSF player seems to work better now. I've fixed the SB sound
>(now works for nearly everyone who's tried it) and switched to
Yeah it sounds very cool... I was suprised to hear good PCM coming out
of SMB2! :-)
>same rules apply though: ULTRASND/BLASTER environment var must be set
>correctly, don't run with too much stuff in the background (it could
>crash)... and don't run on a too slow compu (I've tested it on a p100
>in pure dos and 233mmx in Winblows95)... still only gives 22khz on
>SB...
It continues playing perfectly when I switch back to a windows task in
the background... cool.
>some bugs also remain. envelopes and freq sweeps don't work and give
>mostly silence when used. And the DPCM in SMB3 and CV2 is screwed, but
>it works ok in SMB2 and Journey To Silius though... Snake's revenge
>doesn't work at all...
Lemme check snake's. it may be a bad NSF (since I previously had no way
of testing them until yesterday and today)
>btw Kevin, what *is* Somarims? Is it really Sonic for the NES?! :P
It's from a game called "Somari". Some little HK ripoff of Sonic for the
nintendo. Only instead of Sonic, you play as Mario!! It's pretty amusing.
Search for "somari" and you will find some links to it for download.
Note that it is very crash-prone, and after seeing the code I can see why.
(just try following the music code. I sure couldn't! It's a grade-A mess
and appears to almost be compiled C code or something).
*********************************************************************************
From: Chris Covell <ccovell@xxxxxx.xxx
Date: Fri Apr 16, 1999 1:35 pm
Subject: Re: bankswitched .NSF files
On 15-Apr-99, Michel Iwaniec wrote:
> Btw, my NSF player seems to work better now. I've fixed the SB sound
> (now works for nearly everyone who's tried it) and switched to
> Nesticle's 6502 emulator... it *should* work w/out problems now (yeah,
> right... have I uttered those words before?.. ;)
Hey, it works on my computer now! There are some problems with the
file-playing though. I think you are misinterpreting the "total songs" byte
in the file. On a file that has 20 songs in it, for instance, which has as
its "total songs" byte 14h, the player goes up only to song 19. It's one
of those classic "off-by-one" errors. The player should play what would be
either songs 1-20d, or 0-19d. The former being what the user would want to
see;the latter being what the Accumulator would want to see.
Also, might you want to assign the key for increasing the song also to "=", as
well as "+", for those of us without extended keyboards? Otherwise I have to
press the shift button in conjunction with the "=" key. Good job!
> btw Kevin, what *is* Somarims? Is it really Sonic for the NES?! :P
Yes, it is "Sonic". Pretty funny, but even the Master System and Game Gear
versions are much, much better.
--
Chris Covell (ccovell@d...)
http://www.sfu.ca/~ccovell/
Powered by Amiga!
*********************************************************************************
From: Chris Covell <ccovell@xxxxxx.xxx
Date: Fri Apr 16, 1999 7:37 pm
Subject: NES Music Rips
Hi, folks. I have fixed up a bunch of rips of NES music, and so I have them
posted in NESM format and in regular NES ROMs on my homepage. As far as I
know, they seem to work (mostly) fine in Michael's NESM player.
Amongst the files you will find fixed versions of rips already out there. I
ordered all the songs in these files for more convenient listening; I fixed
the rip for Mega Man and made the .NSF and .NES files for it smaller; and I
corrected the "bad" rip of Mega Man 2. (Kevin: it was just one incorrect
byte! Funny, huh?) I also filled in the composer credits as far as I could.
You can find the files here (for now):
http://www.sfu.ca/~ccovell/data/NESM_Tunes01.zip
http://www.sfu.ca/~ccovell/data/NES_Tunes01.zip
Oh, well. Enjoy!
--
Chris Covell (ccovell@d...)
http://www.sfu.ca/~ccovell/
Powered by Amiga!
*********************************************************************************
From: "Michel Iwaniec" <bananmos_uv@xxxxxxx.xxxx
Date: Fri Apr 16, 1999 10:36 pm
Subject: Re: bankswitched .NSF files
>Well the limit comes about because of my hardware. :-) I have 128K
of RAM
>on it, with 64K dedicated for the NSF data and 64K of everything
else.
>(0000-1fff, 5f80-5fef, and 6000-7fff all draw from this). Though I
don't see
>why I couldn't slap a 512K pseudoSRAM on there instead. (this is a
dynamic RAM
>chip with a static-ram-like interface... no refreshing required.
They are very
>nifty). Though the limit would be 512K-32K then (32K since that's
all the
>space required for the 0000-7fff junk)
>
>So would you be happy with 480K maximum song size? IMO if your songs
are
>bigger than this I will shoot ya. ;-) I still want this to be an
easily
>doable hardware project for someone with as few chips as possible.
oh sorry! we misunderstood each other. :) of course I don't demand
that you to build a RAM-monster of a hardware-player, I just got the
impression that you were saying the *format itself* would not let
files be >64k, and not only did that sound stupid, but I also couldn't
figure out *why* that would be, he... :>
btw, there's another thing I thought of - what about sample IRQs? Even
though it'not so likely, a program could use the sample IRQ in it's
music routine. I think you should add it in the form of an address
that gets called when sample IRQ goes off.
also, a thing that does not matter at all technically but would be
pretty nice is this: why not put the 0x1A byte in the format *after*
all the text info instead of after the initial NESM-string? so one
could type it out at the dos prompt/use a text display prog that quits
reading at 0x1A to display:
NESM: "Name of song"
"Artist"
"Copyright Holder"
with CRs in between the strings of course, though this would require a
total redesign of the header. It's not something really important,
but a nice feature. :)
btw, what's the use of the copyright holder-string? NESM's are as
illegal as regular ROMs anyway...
could you please give me the schematic for your hardware-SID-player
(if you have any). And maybe your hardware NESM-player if you've got
that done too?
>Yeah it sounds very cool... I was suprised to hear good PCM coming
out
>of SMB2! :-)
me too, I never realized it had them! but it seems to use them *alot*,
especially for sfx. I'm very eager to rip them for use with
NerdTracker2... :]
>It continues playing perfectly when I switch back to a windows task
in
>the background... cool.
yeah, but a music player is one prog that I agree is not too great in
DOS-only. I'm gonna try to follow the recommendation of making a
winamp-plugin of it (will be my first Winblows proggy ever, wish me
luck :>
But I'll still keep a DOS-version for all us oldskool people... (would
be stupid not too, as it's the same code that is used with NerdTracker
with just a 6502 emulator added to it)
*********************************************************************************
From: "Michel Iwaniec" <bananmos_uv@xxxxxxx.xxxx
Date: Fri Apr 16, 1999 10:45 pm
Subject: Re: NES Music Rips
>Hi, folks. I have fixed up a bunch of rips of NES music, and so I
have them
>posted in NESM format and in regular NES ROMs on my homepage. As far
as I
>know, they seem to work (mostly) fine in Michael's NESM player.
>
>Amongst the files you will find fixed versions of rips already out
there. I
>ordered all the songs in these files for more convenient listening; I
fixed
>the rip for Mega Man and made the .NSF and .NES files for it smaller;
and I
>corrected the "bad" rip of Mega Man 2. (Kevin: it was just one
incorrect
>byte! Funny, huh?)
thanks! it was driving me nuts that the ending tune (the last one in
you megaman2-rip) was screwing up. All along, I thought there was
something wrong with my emulation or something... :)
btw, what *was* the fault with it? the "bad" file apparantly worked on
my PAL NES without problems...
>I also filled in the composer credits as far as I
>could.
That's something I've been far to lazy to do... :]
*********************************************************************************
From: Chris Covell <ccovell@xxxxxx.xxx
Date: Sat Apr 17, 1999 2:55 am
Subject: Re: NES Music Rips
On 16-Apr-99, Michel Iwaniec wrote:
> btw, what *was* the fault with it? the "bad" file apparantly worked on
> my PAL NES without problems...
I used Marat's program BDIFF to find out the differences between the .NSF made
by Kevin, and the .NSF made by me, and one byte somewhere was like FC when it
correctly should be FF. Something small like that. Unfortunately the way we
call music right now in programs or emulators, if one song screws up, it
usually makes all songs after that song screw up as well. I might suggest to
NESM-coders (although it is a trivial matter) to clear all of $4000-$4013
before every init of a song. This should isolate a bad song, and also stop
DMC samples from playing as soon as a song is changed, instead of having it
continue to play until it is at the end of its data length. Is this a good or
bad idea?
>> I also filled in the composer credits as far as I
>> could.
> That's something I've been far to lazy to do... :]
I think it is important to credit composers of music. Not only does it make
it so that it is harder to 'rip off' somebody's music and say that it is their
own, it also lets listeners know who made the music that they like. They
might recognize the same composer in several games and be driven to look up
other music done by the composer. SIDs, for example, are mostly sorted
according to the music composer, and not the game company or game genre. This
shows where we place the talent in game music.
--
Chris Covell (ccovell@d...)
http://www.sfu.ca/~ccovell/
Powered by Amiga!
*********************************************************************************
From: Chris Covell <ccovell@xxxxxx.xxx
Date: Sat Apr 17, 1999 6:58 am
Subject: New NES Demo
Hey, folks. I have quickly made up another NES demo. This one shows how it
is possible to display a bitmap of 256x128 pixels on the NES without using
mid-screen pattern changes or anything. The only drawback is that the image
is in 1 bitplane. You should check it out anyway! It is available on my
webpage at
http://www.sfu.ca/~ccovell/data/MacOS.zip
Let me know what you think!
--
Chris Covell (ccovell@d...)
http://www.sfu.ca/~ccovell/
Powered by Amiga!
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Sat Apr 17, 1999 7:27 am
Subject: VRAM Address Mid-Frame
Is there any way to stop the VRAM address from being incremented mid-frame?
Would clearing the background/sprite display bits in the ppu control
register do it?
-David
*********************************************************************************
From: "Michel Iwaniec" <bananmos_uv@xxxxxxx.xxxx
Date: Sat Apr 17, 1999 7:50 am
Subject: Re: New NES Demo
>Hey, folks. I have quickly made up another NES demo. This one shows
how it
>is possible to display a bitmap of 256x128 pixels on the NES without
using
>mid-screen pattern changes or anything. The only drawback is that
the image
>is in 1 bitplane.
Well, this ain't really news. :) ..on more advanced machines, the
technique has also been used in palette gfx modes for the effect
called "cross-fading", i.e. fading between two pictures. You use a
certain number of bits for one image, and the remaining bits for the
other - for example 4 for both pics giving two 16-color pictures.
Then you fade between them by changing the palette, looks quite cool.
:)
btw, Elite apparently uses the technique to implement a form of
page-flipping.
*********************************************************************************
From: Barubary <barubary@xxxx.xxxx
Date: Sat Apr 17, 1999 7:54 am
Subject: Re: VRAM Address Mid-Frame
>Is there any way to stop the VRAM address from being incremented mid-frame?
>Would clearing the background/sprite display bits in the ppu control
>register do it?
Yep. BOTH bits have to be set to off though. You can also do it during
hblank, but this takes damn good timing.
-- Barubary
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Sat Apr 17, 1999 7:21 am
Subject: Re: New NES Demo
> Hey, folks. I have quickly made up another NES demo. This one shows how
it
> is possible to display a bitmap of 256x128 pixels on the NES without using
> mid-screen pattern changes or anything. The only drawback is that the
image
> is in 1 bitplane. You should check it out anyway! It is available on my
> webpage at
I gather it's done by having each tile have the first bit as the first half
of the image and the second bit as the second half of the image, and the
attribute tables for the left half of the image pointing to a palette area
that's XOX (black white black) and the right side being a palette area
that's OXX (black white white) and then just stick the same tiles on both
halfs?
-David
*********************************************************************************
From: Barubary <barubary@xxxx.xxxx
Date: Sat Apr 17, 1999 8:23 am
Subject: Re: New NES Demo
>I gather it's done by having each tile have the first bit as the first half
>of the image and the second bit as the second half of the image, and the
>attribute tables for the left half of the image pointing to a palette area
>that's XOX (black white black) and the right side being a palette area
>that's OXX (black white white) and then just stick the same tiles on both
>halfs?
Yep. Go look at Elite, which is a damn good example of this being used.
-- Barubary
*********************************************************************************
From: "Michel Iwaniec" <bananmos_uv@xxxxxxx.xxxx
Date: Sat Apr 17, 1999 8:46 am
Subject: Re: NES Music Rips
> Unfortunately
the way we
>call music right now in programs or emulators, if one song screws up,
it
>usually makes all songs after that song screw up as well. I might
suggest to
>NESM-coders (although it is a trivial matter) to clear all of
$4000-$4013
>before every init of a song. This should isolate a bad song, and
also stop
>DMC samples from playing as soon as a song is changed, instead of
having it
>continue to play until it is at the end of its data length. Is this
a good or
>bad idea?
not at all, I think it's really necessary... though I've only been
writing 0 to $4015 so far... I also clear all the RAM (though I'm not
sure if this is really necessary...)
>I think it is important to credit composers of music. Not only does
it make
>it so that it is harder to 'rip off' somebody's music and say that it
is their
>own, it also lets listeners know who made the music that they like.
They
>might recognize the same composer in several games and be driven to
look up
>other music done by the composer. SIDs, for example, are mostly
sorted
>according to the music composer, and not the game company or game
genre. This
>shows where we place the talent in game music.
Well, the tunes I made NSFs of were just made so I could play them and
not really something I'd distribute too much... writing it down
requires that one knows the company/composer/etc, and then you have to
1) have the ROM in question
2) complete it and watch the ending sequence - and I'm already short
on free time. :)
besides, I still view NSF as a beta format which could still change,
so I reckon these initial files that exist don't matter too much, but
it's nice that you're already typing in all the information that
should be there. Whenever you distribute a song with complete info, I
do copy it over my old one. :)
l8er
*********************************************************************************
From: Kevin Horton <khorton@xxxxxx.xxxx
Date: (Date Unavailable)
Subject: Re: NES Music Rips
At 03:46 PM 4/16/99 PDT, you wrote:
>From: "Michel Iwaniec" <bananmos_uv@h...>
>not at all, I think it's really necessary... though I've only been
>writing 0 to $4015 so far... I also clear all the RAM (though I'm not
>sure if this is really necessary...)
Yes, I've forgot to mention the "manditory setup rules". They are as follows:
1) clear all of RAM (0000-07ff)
2) clear all sound registers: 00h->4000h thru 4013h
3) load in the tune
4) set bankswitching (if appropriate)
5) set 4015h to 0fh
The last is pretty important since many tunes do not do this in their
init routines. (If the tunes don't I try to add this anyway) Note that
you should only do the above before loading the tune. Changing songs on
the tune should not require the clearing and re-loading of RAM. Only when
you load a new tune in should you clear RAM.
>>I think it is important to credit composers of music. Not only does
>it make
>>it so that it is harder to 'rip off' somebody's music and say that it
>is their
>>own, it also lets listeners know who made the music that they like.
Agreed. I didn't credit any composers since I didn't know who did the
music. (Except when the game told who wrote it, then I did obviously :-)
Though for most Japanese games like Megaman 2 and such I have no kloo
who did what.
>Well, the tunes I made NSFs of were just made so I could play them and
>not really something I'd distribute too much... writing it down
>requires that one knows the company/composer/etc, and then you have to
>1) have the ROM in question
>2) complete it and watch the ending sequence - and I'm already short
> on free time. :)
>besides, I still view NSF as a beta format which could still change,
>so I reckon these initial files that exist don't matter too much, but
>it's nice that you're already typing in all the information that
>should be there. Whenever you distribute a song with complete info, I
>do copy it over my old one. :)
Yeah The accuracy of the song/composer/copyright stuff is very manditory.
If it does not get corrected early on, it makes a big hassle later. Take
the .SID file archive guys as an example. They're still battling bad
credits on rips.
*********************************************************************************
From: Fx3 <gyfay@xxxxxx.xxx.xxx
Date: Sun Apr 18, 1999 3:10 am
Subject: Re: VRAM Address Mid-Frame
Hi,
How this stuff works exactly?
-Fx3
Barubary wrote:
> From: Barubary <barubary@h...>
>
> >Is there any way to stop the VRAM address from being incremented mid-frame?
> >Would clearing the background/sprite display bits in the ppu control
> >register do it?
>
> Yep. BOTH bits have to be set to off though. You can also do it during
> hblank, but this takes damn good timing.
>
> -- Barubary
>
> ------------------------------------------------------------------------
> Has ONElist changed your life?
> http://www.ONElist.com
> Visit our homepage and share with us your experiences at ONElist of the Week!
*********************************************************************************
From: "Michel Iwaniec" <bananmos_uv@xxxxxxx.xxxx
Date: Sun Apr 18, 1999 6:43 am
Subject: Re: NES Music Rips
>4) set bankswitching (if appropriate)
speaking of bankswitching, kirbymus.nsf is bugging me. to begin with,
the ROM-size is 37143 bytes (doesn't divide into an even count of 4k
pages).
also, the init address is 0xFFEF and the play address is 0xFFF7, and
you said that this particular tune does not use the banks at
0xC000-0xFFFF??
and the data at 0xFF7 and 0xFEF of bank 8 (which is the one that
should be switched into 0xF000?) seems to be 0x00/0xFF and stuff... to
me, the whole file looks pretty corrupt... :(
you also didn't answer two questions very important to me... :)
1) what about the sample IRQ? an address should be added for it in
the header.
2) do you have schematic of your hardware SID/NSF player??? I won't be
able to make any similar hacks all by myself! :\
// Michel
*********************************************************************************
From: Kevin Horton <khorton@xxxxxx.xxxx
Date: (Date Unavailable)
Subject: Re: NES Music Rips
At 01:43 PM 4/17/99 PDT, you wrote:
>From: "Michel Iwaniec" <bananmos_uv@h...>
>speaking of bankswitching, kirbymus.nsf is bugging me. to begin with,
>the ROM-size is 37143 bytes (doesn't divide into an even count of 4k
>pages).
>
>also, the init address is 0xFFEF and the play address is 0xFFF7, and
>you said that this particular tune does not use the banks at
>0xC000-0xFFFF??
>
>and the data at 0xFF7 and 0xFEF of bank 8 (which is the one that
>should be switched into 0xF000?) seems to be 0x00/0xFF and stuff... to
>me, the whole file looks pretty corrupt... :(
Nope it's not corrupt. It works perfectly on my hardware player :-)
I forgot to mention that the last bank does not have to be a full 4K.
It can be 1 byte to 4096 bytes. And if that's what I said, I screwed up.
I meant to say that C000-EFFFh was not used. The F000-FFFF *is* used. It
holds the PCM samples and the init/play "stubs" which do the proper setup
for this tune.
>you also didn't answer two questions very important to me... :)
>
>1) what about the sample IRQ? an address should be added for it in
> the header.
Hmmmm. I've had this happen once on Ultimate Stuntman. To fix it, I
converted the samples to PCM format and used a 4010-4013 style player for it.
It worked pretty darned good too. I suspect that most nintendo-sanctioned
tunes will not use sample-IRQs, only 3rd party games would.
Let's wait on adding this unless it's really required.
>2) do you have schematic of your hardware SID/NSF player??? I won't be
> able to make any similar hacks all by myself! :\
I never make schematics for my projects. They wouldn't be much value to
me so I don't make them. I don't have a good way of making large ones anyway
other than pencil/paper and that takes far too long to be any good for me.
What I do generate are block diagrams and little pieces of schematic. I keep
a file (as in paper, in a filing cabinet :-) on every project I do.
Having a schematic wouldn't be much use since the SID player has 4
microprocessors, one EEPROM and one EPROM that need to be programmed. The
schematic for it is the easy part. Doing all the hand-wiring is the hard
part. :-) (yes, all my projects like this are hand-wired. I start out with
a bare board with a .1*.1 inch grid on it with solder pads around each hole
and hook everything up with telephone wire. It works pretty good)
I will try to get some pictures of the SID player placed up on my page when I
get a chance. I need to borrow a decent digital camera since there's alot of
detail I need to resolve so it may take awhile.
*********************************************************************************
From: "Michel Iwaniec" <bananmos_uv@xxxxxxx.xxxx
Date: Sun Apr 18, 1999 12:11 pm
Subject: Small PLAYNSF update
Ok, here's a small update of my NSF player. Bankswitching now works,
and DPCM works fine in all tunes except for SMB3 and Crystals (though
there are pops in it in some other tunes...)
Snake's revenge still doesn't work though... :/
get it at http://www.iquest.net/~khorton/playnsf.zip
Bad news for NESamp: I intended to convert the Winamp plugin example
(a plain .raw player) little by little until it was turned into an NSF
player, but the example won't work (just stops when you try to play
the waveform). :'(
I've never coded for Windows before, so perhaps someone here knows (or
knows somebody who knows :) something about Winamp plugins?
any help is appreciated.
*********************************************************************************
From: JDC <yoshi@xxxxxxxx.xxxx
Date: Sun Apr 18, 1999 12:59 pm
Subject: Re: Small PLAYNSF update
On 04/17/1999 (19:11:07), bananmos_uv@h... wrote:
> I've never coded for Windows before, so perhaps someone here knows (or
> knows somebody who knows :) something about Winamp plugins?
You may want to contact "_Demo_" of ZSNES fame, as he
wrote the Winamp plugin which plays SPC (SNES) audio
files.
--
| Jeremy Chadwick yoshi@d... |
| Parodius Networking yoshi@p... |
| System Administrator/CGI Programmer 650-551-8916 |
*********************************************************************************
From: Fx3 <gyfay@xxxxxx.xxx.xxx
Date: Sun Apr 18, 1999 3:09 pm
Subject: VS Unisystem
Hi,
Anybody know if the original ROM sets for VS uinisystem games (for example,
CastleVania) *should* be the same PRG or CHR data in the NES format (like
mds-cv.nes)? The original CastleVania has just 1 file named prg.u7 and with
size 131072 bytes. I did an easy look into the NES and .u7 formats: i
couldn´t see same opcodes...
Any help?
-Fx3
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Sun Apr 18, 1999 5:43 pm
Subject: Re: VRAM Address Mid-Frame
Just in the middle of the frame you disable both display bits of the ppu
control register...
-David
----- Original Message -----
From: Fx3 <gyfay@c...>
To: <nesdev@onelist.com>
Sent: Saturday, April 17, 1999 10:10 AM
Subject: [nesdev] Re: VRAM Address Mid-Frame
> From: Fx3 <gyfay@c...>
>
> Hi,
>
> How this stuff works exactly?
>
> -Fx3
>
> Barubary wrote:
>
> > From: Barubary <barubary@h...>
> >
> > >Is there any way to stop the VRAM address from being incremented
mid-frame?
> > >Would clearing the background/sprite display bits in the ppu control
> > >register do it?
> >
> > Yep. BOTH bits have to be set to off though. You can also do it during
> > hblank, but this takes damn good timing.
> >
> > -- Barubary
> >
> > ------------------------------------------------------------------------
> > Has ONElist changed your life?
> > http://www.ONElist.com
> > Visit our homepage and share with us your experiences at ONElist of the
Week!
>
>
> ------------------------------------------------------------------------
> You can now easily share photos and documents with your fellow list
members
> http://www.ONElist.com
> Check out our homepage for details on how to use our new shared files
feature!
>
*********************************************************************************
From: "Michel Iwaniec" <bananmos_uv@xxxxxxx.xxxx
Date: Mon Apr 19, 1999 7:18 am
Subject: Re: Small PLAYNSF update
>> I've never coded for Windows before, so perhaps someone here knows
(or
>> knows somebody who knows :) something about Winamp plugins?
>
> You may want to contact "_Demo_" of ZSNES fame, as he
> wrote the Winamp plugin which plays SPC (SNES) audio
> files.
I've talked to him now... seems his SPCamp was based on that .raw
player, but he claims it has always worked for him. And his plugin
works fine for me... :/
Maybe it's some weird compiler-setting I haven't used? Anyone with
Visual C++ is encouraged to try and compile the plugin example! :)
(it can be found in the plugin developer's section at the Winamp site,
in_minisdk.zip is it's name)
Big hugs to anyone who can help me make it work.
*********************************************************************************
From: Fx3 <gyfay@xxxxxx.xxx.xxx
Date: Mon Apr 19, 1999 7:36 am
Subject: Re: VS Unisystem
Hello,
It´s easy: the ROMs are encrypted.
> From: Fx3 <gyfay@c...>
>
> Hi,
>
> Anybody know if the original ROM sets for VS uinisystem games (for example,
> CastleVania) *should* be the same PRG or CHR data in the NES format (like
> mds-cv.nes)? The original CastleVania has just 1 file named prg.u7 and with
> size 131072 bytes. I did an easy look into the NES and .u7 formats: i
> couldn´t see same opcodes...
>
> Any help?
>
> -Fx3
>
> ------------------------------------------------------------------------
> To unsubscribe from this mailing list, or to change your subscription
> to digest, go to the ONElist web site, at http://www.onelist.com and
> select the Member Center link from the menu bar on the left.
*********************************************************************************
From: "Matthew Conte" <itsbroke@xxxxxxxxxxxxx.xxxx
Date: Mon Apr 19, 1999 1:28 pm
Subject: New version of SNSS specification
Hello. David de Regt recently orphaned the SNSS specification to loopy and
I. Here's the first new revision, based on ideas that zxcvzxcv and I had.
Please launch all gripes at us, keeping in mind that we both have it working
like butter.
Later,
Matt.
______________________________
Matthew Conte [matt@c...]
Vertically Challenged Software
Nofrendo : http://nofrendo.org
-- snss-tff.txt (15,708 bytes) --
============================================
Standardized NES Save State
Tagged File Format (SNSS-TFF)
v0.10 -- 04/18/1999
Contact the authors at: matt@c... -and-
zxcvzxcv@n...
============================================
Sections
--------
1. Changes
2. Basic Issues
3. File Structure
4. Block Structure
5. Block Types
6. MMCData Specifics
7. Controller Types
8. Credits
+----------+
|1. Changes|
+----------+
Version 0.10:
* Now maintained by Matt Conte (matt@c...) and
loopy (zxcvzxcv@n...)
* Cosmetic changes
* Removed past revision history
* Changed version numbering to major.minor
* Documentation changes / fixes
* Rewrite of section 2 for clarity
* MEMR block rolled into BASR
* Added note about SRAM
+---------------+
|2. Basic Issues|
+---------------+
To keep the NES hardware in sync, the state should *only* be loaded /
saved at the beginning of the frame -- directly before scanline zero
occurs.
Byte ordering is MSB-->LSB, to keep the state files as human-readable
as possible. For example, the number 4 would be represented by a 32 bit
integer in the SNSS format as 00 00 00 04.
Blocks are *not* inherently padded to any kind of boundary other than
8 bits, so take care in reading / writing the state files.
Since the purpose of the format is to be as standardized as possible,
the state filename should be <romname>.SS?, where <romname> is the name
of the ROM image minus the .NES extension, and ? represents a number from
0 to 9. Hence, even systems crippled by 8.3 filename conventions can
still natively support 10 state slots.
+-----------------+
|3. File Structure|
+-----------------+
Offset Description
----------------------------
0-3 "SNSS"
4-7 Total # of blocks in the file
8-EOF State Blocks
+------------------+
|4. Block Structure|
+------------------+
Offset Description
----------------------------
0-3 Block Signature (String)
4-7 Block Version
8-11 Size of Block Data (in bytes)
12-EOB Block Data (See section 5 for what all the blocks are)
+--------------+
|5. Block Types|
+--------------+
Key:
+----+----------------------------------------------------------------+
|Sig |Description |
+---++----------------------------------------------------------------+
|Ver| |
+---+-+-----+---------------------------------------------------------+
|From |Len |Contains |
|From |Len |Contains |
+-----+-----+---------------------------------------------------------+
|Other Info |
+---------------------------------------------------------------------+
Sig = 4 character signature identifier string
Ver = Version
From/Len = Starting position and length of this block item (in Hex)
+----+----------------------------------------------------------------+
|BASR|Base Registers |
+---++----------------------------------------------------------------+
|1 | |
+---+-+-----+---------------------------------------------------------+
|$0 |$1 |Accumulator |
|$1 |$1 |X-Register |
|$2 |$1 |Y-Register |
|$3 |$1 |Processor Status Register |
|$4 |$1 |Stack Pointer |
|$5 |$2 |Program Counter |
|$7 |$1 |$2000 in CPU Memory (PPU Control Register #1) |
|$8 |$1 |$2001 in CPU Memory (PPU Control Register #2) |
|$9 |$800 |$0000-$07FF of CPU Memory (RAM) |
|$809 |$100 |SPR-RAM |
|$909 |$1000|$2000-$2FFF of PPU Memory (Name Tables/Attribute Tables) |
|$1909|$20 |$3F00-$3F1F of PPU Memory (Palette) |
|$1929|$4 |Current Mirroring Setup - See Footnote A |
|$192D|$2 |VRAM Address |
|$192F|$1 |OAM (SPR-RAM) Address |
|$1930|$1 |Background Scrolling X Value |
|$1931|$1 |Background Scrolling Y Value |
+-----+-----+---------------------------------------------------------+
|This block is absolutely *required* for an SNSS state. Removal of |
|this block will assure a non-functional state file. |
| |
|A. Examples so you see how it works: |
| Horizontal: 0,0,1,1 |
| Vertical: 0,1,0,1 |
| 4-Screen: 0,1,2,3 |
| All $2000: 0,0,0,0 |
| All $2400: 1,1,1,1 |
+---------------------------------------------------------------------+
+----+----------------------------------------------------------------+
|VRAM|VRAM |
+---++----------------------------------------------------------------+
|1 | |
+---+-+-----+---------------------------------------------------------+
|$0 |$x000|VRAM |
+-----+-----+---------------------------------------------------------+
|The $x000 is because this block consists of an array of 8k VRAM |
|blocks. Most games only have 8k of VRAM, but some games like |
|Videomation have 16k of VRAM. Figure out how many blocks there are |
|by reading the length portion of the header atom. |
|Only write this block to the file if there is VRAM present in the |
|game. If there is only VROM, do not write this block to the file. |
+---------------------------------------------------------------------+
+----+----------------------------------------------------------------+
|SRAM|SRAM |
+---++----------------------------------------------------------------+
|1 | |
+---+-+-----+---------------------------------------------------------+
|$0 |$1 |If SRAM is currently writeable (0=no, >0=yes) |
|$1 |$x000|SRAM |
+-----+-----+---------------------------------------------------------+
|If SRAM/Expanded WRAM is present*, write this block, otherwise don't.|
|The $x000 is for paged SRAM. You can figure out how many pages |
|there are by looking at the length part of the header atom. |
| |
|*Note that some games (Super Mario Brothers 3, Metroid, Kid Icarus) |
|contain SRAM at $6000-7FFF, but do not have battery backup. The |
|safest thing to do is to check to see if this region has been written|
|to, and if it has, dump the SRAM block to the state file. |
+---------------------------------------------------------------------+
+----+----------------------------------------------------------------+
|MPRD|Mapper Data |
+---++----------------------------------------------------------------+
|1 | |
+---+-+-----+---------------------------------------------------------+
|$0 |$8 |8k PRG Page numbers currently in $8/A/C/E000 |
|$8 |$10 |1k CHR Page numbers currently in $0/4/8/C/10/14/18/1C00 |
|$18 |$80 |Mapper-specific state data - See section 6 |
+-----+-----+---------------------------------------------------------+
|Find the mapper-specific info for the $80 array in section 6. |
|If the mapper is 0, don't write this block. Otherwise write it. |
| |
|Note that the page numbers are each 16-bit numbers. |
+---------------------------------------------------------------------+
+----+----------------------------------------------------------------+
|CNTR|Controllers |
+---++----------------------------------------------------------------+
|1 | |
+---+-+-----+---------------------------------------------------------+
|$0 |$1 |Controller 1 Controller Type - See section 7 |
|$1 |$1 |Controller 2 Controller Type - See section 7 |
|$2 |$4 |Controller 1 Bit array of 24 bits |
|$6 |$4 |Controller 2 Bit array of 24 bits |
|$A |$1 |Controller 1 Bit number next to be read |
|$B |$1 |Controller 2 Bit number next to be read |
|$C |$1 |Controller 1 Strobe Bit |
|$D |$1 |Controller 2 Strobe Bit |
|$E |$1 |Paddle: Button Pressed (0=no, >0=yes) |
|$F |$1 |Paddle: Numeric Position |
|$10 |$1 |Zapper: Button Pressed (0=no, >0=yes) |
|$11 |$1 |VS System: Coin Being Inserted (0=no, >0=yes) |
|$12 |$1 |VS System: DIP Switches |
+-----+-----+---------------------------------------------------------+
|This block is not required, but is recommended. |
+---------------------------------------------------------------------+
+----+----------------------------------------------------------------+
|SOUN|Sound |
+---++----------------------------------------------------------------+
|1 | |
+---+-+-----+---------------------------------------------------------+
|$0 |$16 |$4000-$4015 Sound Registers, and don't use $4014 |
+-----+-----+---------------------------------------------------------+
|This block is not required, but is recommended. |
+---------------------------------------------------------------------+
+--------------------+
|6. MMCData Specifics|
+--------------------+
This section needs to be far more complete. For now it has the most
basic mappers covered, enough so that games are functional. Please contact
the authors if you have additional information on new mappers, or mappers
that already appear in this document.
Mapper x
--------
Byte(s) What go in them
Additional Notes
Mapper 0
--------
[None used]
Mapper 1
--------
0-3 The last values written to each of the 4 registers
4 Latch register
5 Number of bits (0-4) that have been written to the current
unfinished register
The last two bytes are merely precautionary, but added for completeness.
MMC1 registers are 5 bits wide, and are written 1 bit at a time. Byte 5
holds the number of bits that have been written only if a register has not
been completed yet, otherwise it will reset to zero. The latch register
gets filled in from D0 to D4 -- it is written from the low bit to the high
bit.
Mapper 2
--------
None
Mapper 3
--------
[None used]
Mapper 4
--------
0 IRQ Counter
1 IRQ Latch Counter
2 (boolean) IRQ Counter Enabled
3 Last value written to $8000
Mapper 5
--------
0-1 Values last written to $5103-$5104
[incomplete]
Mapper 6
--------
0 IRQ Counter
1 IRQ Latch Counter
2 (boolean) IRQ Counter Enabled
3 Value last written to $43FE
4 Value last written to $4500
[incomplete]
Mapper 7
--------
[None used]
Mapper 8
--------
[None used]
Mapper 9
-------
0-1 The two latch registers
2-5 Last values written to the B/C/D/E000 registers
Mapper 10
---------
0-1 The two latch registers
2-5 Last values written to the B/C/D/E000 registers
Mapper 11
---------
[None used]
Mapper 15
---------
[None used]
Mapper 16
---------
0 Low byte of IRQ Counter
1 High byte of IRQ Counter
2 (boolean) IRQ Counter Enabled
Mapper 17
---------
0 Low byte of IRQ Counter
1 High byte of IRQ Counter
2 (boolean) IRQ Counter Enabled
Mapper 18
---------
0 Low byte of IRQ Counter
1 High byte of IRQ Counter
2 (boolean) IRQ Counter Enabled
Mapper 19
---------
0 Low byte of IRQ Counter
1 High byte of IRQ Counter
2 (boolean) IRQ Counter Enabled
Mapper 21
---------
0 IRQ Counter
1 (boolean) IRQ Counter Enabled
Mapper 22
---------
[None used]
Mapper 23
---------
[None used]
Mapper 24
---------
0 IRQ Counter
1 (boolean) IRQ Counter Enabled
Mapper 32
---------
[None used]
Mapper 33
---------
[None used]
Mapper 34
---------
[None used]
Mapper 64
---------
[None used]
Mapper 65
---------
[None used]
Mapper 66
---------
[None used]
Mapper 68
---------
[None used]
Mapper 69
---------
0 Low byte of IRQ Counter
1 High byte of IRQ Counter
2 (boolean) IRQ Counter Enabled
Mapper 71
---------
[None used]
Mapper 78
---------
[None used]
Mapper 90
---------
0 IRQ Counter
1 IRQ Latch Register
2 (boolean) IRQ Counter Enabled
Mapper 91
---------
[None used]
Mapper 224
----------
0 (boolean) CHR-RAM writeable
Mapper 225
----------
0 PRG Page Size
1-4 The four 4-bit registers
Mapper 226
----------
0 (boolean) CHR-RAM writeable
Mapper 228
----------
0 PRG Chip Selected
Mapper 230
----------
0 Number of Resets so far (MODed with 5)
Mapper 231
----------
[None used]
+-------------------+
|7. Controller Types|
+-------------------+
#define jpJoypad 0
#define jpPaddle 1
#define jpZapper 2
#define jpQuadJoypad 3
#define jpRobot 4
#define jpPowerPad 5
jpRobot is the ROB. If quad controllers are connected, set both
controllers
to jpQuadJoypad.
+----------+
|8. Credits|
+----------+
David de Regt First draft, most of the formatting
Mark Knibbs Positive feedback
nesdev mailing list Feedback
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Mon Apr 19, 1999 11:54 am
Subject: Re: VS Unisystem
Are your multiple personalities fighting again? =)
-David
> From: Fx3 <gyfay@c...>
>
> Hello,
>
> It´s easy: the ROMs are encrypted.
>
> > From: Fx3 <gyfay@c...>
> >
> > Hi,
> >
> > Anybody know if the original ROM sets for VS uinisystem games (for
example,
> > CastleVania) *should* be the same PRG or CHR data in the NES format
(like
> > mds-cv.nes)? The original CastleVania has just 1 file named prg.u7 and
with
> > size 131072 bytes. I did an easy look into the NES and .u7 formats: i
> > couldn´t see same opcodes...
> >
> > Any help?
> >
> > -Fx3
> >
> > ------------------------------------------------------------------------
> > To unsubscribe from this mailing list, or to change your subscription
> > to digest, go to the ONElist web site, at http://www.onelist.com and
> > select the Member Center link from the menu bar on the left.
>
>
> ------------------------------------------------------------------------
> To unsubscribe from this mailing list, or to change your subscription
> to digest, go to the ONElist web site, at http://www.onelist.com and
> select the Member Center link from the menu bar on the left.
>
*********************************************************************************
From: Fredrik Olsson <flubba@xxxx.xxxxxxxx.xxx
Date: Tue Apr 20, 1999 6:09 am
Subject: Re: New version of SNSS specification
Nice working boys =)
I will release a new version of my emu and then I will begin implementing
this cool feature.
I hope you have some savestates over for me, so I can test my implementation
later on.
Regards
--
Fredrik Olsson aka FluBBa of WarD. http://hem2.passagen.se/flubba/
Author of CoolNESs for Amiga.
*********************************************************************************
From: "Memblers" <5010.0951@xxxx.xxxx
Date: Tue Apr 20, 1999 9:31 am
Subject: NES music author list
I started compiling a list of NES game music authors so someone
who rips it shouldn't have to rediscover something that someone else
already knows. There isn't much info on the list, yet. It's at
http://www.oocities.org/Athens/Olympus/2077/nes/authors.txt
Memblers
-- Arachne V1.48;beta, NON-COMMERCIAL copy, http://home.arachne.cz/
*********************************************************************************
From: Chris Covell <ccovell@xxxxxx.xxx
Date: Tue Apr 20, 1999 4:06 pm
Subject: New NES demo
Hey, folks. Following Mark K's request, I have made a new NES demo that
displays 5 shades of grey, not including black and white, nor dithering. It
also cycles through some other colours just to be interesting. This demo
really shows off the deficiencies of the palettes of many emulators. A real
NES should show all the levels of grey used by this demo.
The demo is available from my videogames page at:
http://www.sfu.ca/~ccovell/data/atomic.zip
I'd love to hear your comments or criticisms.
--
Chris Covell (ccovell@d...)
http://www.sfu.ca/~ccovell/
Powered by Amiga!
*********************************************************************************
From: Chris Covell <ccovell@xxxxxx.xxx
Date: Tue Apr 20, 1999 4:16 pm
Subject: Re: NES music author list
On 19-Apr-99, Memblers wrote:
> I started compiling a list of NES game music authors so someone
> who rips it shouldn't have to rediscover something that someone else
> already knows. There isn't much info on the list, yet. It's at
> http://www.oocities.org/Athens/Olympus/2077/nes/authors.txt
Hey, good idea. If anybody has ripped music and is looking for the names of
the authors, you don't have to play the game through! Just look up in a hex
editor that searches for text strings or encoded text. Hexposure for the PC
is one, and ROMSearcher (by me) for multi-platform is another. Just search
for text that would typically be in the ending, like "PROGRAM" or "ROGRAM" or
"SOUND" or "OUND", etc...
BTW, I think the composer of Zelda was Koji Kondo, but that's just off the top
of my head.
--
Chris Covell (ccovell@d...)
http://www.sfu.ca/~ccovell/
Powered by Amiga!
*********************************************************************************
From: "Memblers" <5010.0951@xxxx.xxxx
Date: Wed Apr 21, 1999 5:37 am
Subject: Re: NES music author list
On Mon, 19 Apr 1999 23:16:36 -0700, Chris Covell wrote:
> From: Chris Covell <ccovell@d...>
> Hey, good idea. If anybody has ripped music and is looking for the names of
> the authors, you don't have to play the game through! Just look up in a hex
> editor that searches for text strings or encoded text. Hexposure for the PC
> is one, and ROMSearcher (by me) for multi-platform is another. Just search
> for text that would typically be in the ending, like "PROGRAM" or "ROGRAM" or
> "SOUND" or "OUND", etc...
I can't use Hexposure because my computer doesn't have enough memory,
and I can't run the Win9X version of ROMSearcher because I don't have
Win9x.. I spent last night trying to compile it with DJGPP, but since I
don't know a damn thing about C I haven't had any luck. Could someone
who uses C++ do me a big favor and compile a dos version of ROMSearcher?
I can't remember the url to Chris's page, but it's linked on the 'Home
pages' section of http://nesdev.cjb.net
Sorry to whine on the count of me having crappy hardware.. I'm wanting
to get the author's names for the NSF's on my page as soon as I can.
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Thu Apr 22, 1999 5:04 am
Subject: Re: NES music author list
> I can't use Hexposure because my computer doesn't have enough memory,
> and I can't run the Win9X version of ROMSearcher because I don't have
> Win9x.. I spent last night trying to compile it with DJGPP, but since I
> don't know a damn thing about C I haven't had any luck. Could someone
> who uses C++ do me a big favor and compile a dos version of ROMSearcher?
> I can't remember the url to Chris's page, but it's linked on the 'Home
> pages' section of http://nesdev.cjb.net
Uhm... Compile a dos version? You have to understand that there's a huge
difference between interfaces in dos and in windows. It'd take hours and
hours to rewrite the interface in DOS, because windows' controls are, well,
windows's controls'. You can't really just compile a dos version because
you wouldn't have access to the GUI controls that it uses.
> Sorry to whine on the count of me having crappy hardware.. I'm wanting
> to get the author's names for the NSF's on my page as soon as I can.
What is your computer anyway? =)
-David
*********************************************************************************
From: "Michel Iwaniec" <bananmos_uv@xxxxxxx.xxxx
Date: Thu Apr 22, 1999 7:42 am
Subject: Re: NES music author list
>Uhm... Compile a dos version? You have to understand that there's a
huge
>difference between interfaces in dos and in windows. It'd take hours
and
>hours to rewrite the interface in DOS, because windows' controls are,
well,
>windows's controls'. You can't really just compile a dos version
because
>you wouldn't have access to the GUI controls that it uses.
Hey man, ever heard of ANSI-C and completely text-based progs?! :)
>What is your computer anyway? =)
A 486 20Mhz (poor guy :)
// Michel
*********************************************************************************
From: "David de Regt" <akilla@xxxxxxxxx.xxxx
Date: Thu Apr 22, 1999 7:51 am
Subject: Re: NES music author list
> >Uhm... Compile a dos version? You have to understand that there's a
> huge
> >difference between interfaces in dos and in windows. It'd take hours
> and
> >hours to rewrite the interface in DOS, because windows' controls are,
> well,
> >windows's controls'. You can't really just compile a dos version
> because
> >you wouldn't have access to the GUI controls that it uses.
>
> Hey man, ever heard of ANSI-C and completely text-based progs?! :)
Yes, but the program probably wasn't written in ANSI-C since it's win9x. =)
And also, like I said, it's written for windows controls, and so you'd still
need to rewrite any interface there involving the graphical controls.
>
>
> >What is your computer anyway? =)
>
> A 486 20Mhz (poor guy :)
Oh gawd. I installed Win3.1 on a 286 with 1 meg of ram once. Booted up
really fast too.
-David
*********************************************************************************
From: Chris Covell <ccovell@xxxxxx.xxx
Date: Thu Apr 22, 1999 4:15 pm
Subject: Re: NES music author list
On 21-Apr-99, David de Regt wrote:
>>
>> Hey man, ever heard of ANSI-C and completely text-based progs?! :)
> Yes, but the program probably wasn't written in ANSI-C since it's win9x. =)
> And also, like I said, it's written for windows controls, and so you'd still
> need to rewrite any interface there involving the graphical controls.
Actually, I did write it as a completely text-based program. So a DOS version
is completely feasible. The executables I have for ROMSearcher are currently
for the Amiga and Win95. But, yeah, a DOS-only version would be useful, since
the supposed "Win95" executable runs in a DOS window anyway. Can somebody
tell me the logic behind this? (Aside from memory protection, etc.)
Again, I would welcome compiled executables of my program for any platform.
Still waiting for Mac, Linux, Be, and a Windows (in a *window*, not *DOS*)
versions of my program.
And, don't fret about your slow computer. ROMSearcher works nicely even on my
Amiga 500 :-).
--
Chris Covell (ccovell@d...)
http://www.sfu.ca/~ccovell/
Powered by Amiga!
*********************************************************************************
From: Chris Covell <ccovell@xxxxxx.xxx
Date: Thu Apr 22, 1999 6:43 pm
Subject: New NES Demo (again!)
Hi, folks. I'm sure you're tired of hearing this, but I have put up another
new NES demo on my homepage. This time, I am showing a bitmap image of
256x480 pixels in 1 bitplane using a few tricks. You can check it out at
http://www.sfu.ca/~ccovell/data/moby.zip
I have also included another interlacing ROM in the zip file of my Interlacing
demos. That one is an attempt to do horizontal interlacing (eg. greater
apparent horizontal resolution).
Comments and criticism are always welcome, of course.
--
Chris Covell (ccovell@d...)
http://www.sfu.ca/~ccovell/
Powered by Amiga!
*********************************************************************************
From: "Memblers" <5010.0951@xxxx.xxxx
Date: Thu Apr 22, 1999 2:07 pm
Subject: Re: NES music author list
I updated the author list already. The URL is
http://www.oocities.org/Athens/Olympus/2077/nes/authors.txt
There's now info for about 37 games that haven't been ripped, and I've
been through about half of my 1.44 floppy rom collection. I won't be
posting any more messages to the list about it unless there's something
really important, so just keep an eye on that file and watch it grow.
It's kind of funny how many times you see the word "directer" instead of
"director" in the credits of these games.
later,
Memblers
-- Arachne V1.48;beta, NON-COMMERCIAL copy, http://home.arachne.cz/
********************************************************************************