chipmusic.org is an online community in respect and relation to chip music, art and its parallels.
You are not logged in. Please login or register.
There's me being ignorant. I didn't think about the joy port not being able to send data out xD
But the expansion port would be easy to use for MIDI clock I bet!
Check out the thread at NESDev about an ethernet adapter for the expansion port. Sounded like the expansion port would be able to do that and more!
Cool!
Now we 'only' need someone willing to design a midi interface!
Neil- What mapper is this supposed to run on? I want to have my cart design worked out before you release. 
Neil- What mapper is this supposed to run on? I want to have my cart design worked out before you release.
I second that, I want to make sure arfink is ready to make me a cart before you release heehhee
It's currently on MMC1. Here's my iNES header from the source code;
; iNES header
; iNES identifier
.byte "NES",$1a
; Number of PRG-ROM blocks
.byte $04
; Number of CHR-ROM blocks
.byte $02
; ROM control bytes: Horizontal mirroring, SRAM
; No trainer, Mapper #0
;.byte $00, $00
.byte %00010010, %00000000 ;MMC1 with SRAM
; Filler
.byte $00,$00,$00,$00,$00,$00,$00,$00 Shit, dudes, this is getting exciting!
Extra effort on my part to get back on track after my little redesign. It's progressing OK at the moment, adding a new editor mode always takes a while.
I've also come up with yet another editing mode which will make things even better. Can't decide whether to do that now while I'm in that frame of mind or put it at the bottom of the list. LOL
I'm so glad I did the redesign to fit in the Song "Master Track". Having the ability to use repeat/jump commands has meant there's not so much pressure on maxing out the space for patterns.
neailbaldwin I am very happy to hear of this project.
As a further bonus I'm even happier that your such a enthusiastic individual to be working on such a great project. 
Is this the MMC1 with the battery backup? Thanks!
EDIT: read the header again, now I know. D'oh!
Last edited by arfink (Jan 13, 2010 3:46 am)
This is very exciting, I much prefer tracking with the hardware directly, even if it is not the "best" way. This is so rad.
So amazing! Now I am so in the market for a powerpak + NES. Shame that will cost me so much money - but man, just LOOK at that, amazing work. I'm a total affectionate of live-hardware stuff. Really excited about live potential.
Last edited by Beverage (Jan 13, 2010 2:45 am)
me also needing one (or two) powerpaks. keep up the great work comrade.
Yus. I went a picked up a couple of MMC1 carts of various configurations for hacking. SNROM board is looking the most promising. In the mean time, I'll be able to run a translated copy of Sweet Home on it.
EDIT: Ick. SNROM is going to be a pain. Time to track down a SKROM board.
So, Neil, tell me if this is right:
You need 128k of PRG ROM, 64k CHR ROM, 8k SRAM, and an MMC1, right? Not CHR RAM, correct?
EDIT2: found some possible donor carts, now to track some down. (crappy) games like:
Al Unser Racing
Baseball Simulator 1000
Baseball Stars
Faria
Ghost Lion
Heroes of the Lance
Pirates
Also, I believe most of the Ultima games would work... need to check that.
Last edited by arfink (Jan 13, 2010 4:16 am)
@arfink
Yes, that's the current configuration.
I don't envisage it changing and if it does it will most likely be an increase in PRG ROM size (another bank maybe).
Please just bear that in mind before spending money on carts etc.
Until I have the core features locked I can't consolidate/optimise ROM layout etc plus I'd want some ROM overhead for future expansion.
Actually, gentlemen, I could do with some input.
While on the subject of speed tables, I have a quandary. As far as I know there are only two methods of doing "tempo" on a fixed refresh rate system (i.e. NTSC being 60fps, constantly).
Method one is using a frame counter. So your "tempo" is the number of frames in between each tick.
Method two utilises arithmetic overflow. You keep adding the "tempo" setting to an internal counter. When the resulting number exceeds 256 (8 bits), the carry flag is set. This is when you do your next tick.
Method one offers the most stable timing as it's always based on a factor of 60fps e.g. a "tempo" of 3 would have a delay of 180 frames between each tick. However, this means that you have little in the way of tempo resolution as the smallest difference between one tempo and the next is 60 frames.
Method two offers you more resolution (I won't get into why) but is less stable because, depending on the speed, every X ticks, it will miss an update. This shows up as tiny fluctuations in your song tempo.
So the question is, which one to use for NTRQ? You've all probably more experience of trackers than me so I'd value any input.
Dare I say I've thought of a way of maybe having both. Maybe... but forget I said that for the time being
(Oh, alternatively, if any of you are programming-minded, is there a better way of doing method 2? I've heard some people doing the same thing but with a 16-bit counter instead but I can't see how this would improve the stability?)
edit: ignore me, I didn't read it properly.
Last edited by ant1 (Jan 13, 2010 11:12 am)