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.
ChipMusic.org / Forums / Posts by BennVenn
Yeah this is only for customers of LSDJ carts which will provide proof prior to shipment. No need to worry about ROM distribution legalities.
Thanks GammaBlaster, I'll check it out today. (I work in Queanbeyan, what are the odds!!)
And Jewel, email me a track or two if you like.
I sell quite a few carts and thought I'd offer to have your .sav file shipped out with my carts. Free exposure for your tracks, often to the inexperienced just starting out in this genre but also the the big players around the world.
Just throwing this out here to see if there is any interest
Pm'd
Haha insane? It has quite a bit. I was thinking of making use of the spare 128k on my carts and have an ROM on there to manage SRAM between the various copies of LSDJ on the cart. Make it easy to backup and move tracks around.
Ahhhhh, I do the exact same thing, reset for a few uS, this is not enough to trigger the page swap, or at least not right after power up (Do you have power control over the cart too?) My Gen2 could remove power and float all the I/O so I could choose either page.
I apply around 100ms pulse to swap the page (this is going from memory, I can dig through my source if you like)
Or... Just toggle the carts reset line. It is how my Joey can switch pages via the PC software... It can only switch from page 1 to 2, you need to cycle power either via removing and inserting the cart, or usb power to get back to page 1
The coolboy carts have all the necessary resources but does not support Neil's unusual choice of mapper. He used this mapper to conveniently address a large amount of WRAM. You could go through his ROM and hook and change all the mapper writes but this would be time consuming! I've emailed him regarding a fork of his source but he is a very busy man and have not heard back from him.
You could build the mapper into a coolboy cart with a few logic IC's and some SRAM, then you could run Pulsar on it.
I could download his other various NES ROM's and test their compatibility...
Jazzmarazz wrote:Or you could click the other products on that very page and choose one of the USB programmers/readers...erm, once they are back in stock.
Good point. I didn't notice that. I must have mentally discarded it before as it's Windows only.
They run under python so any OS is compatible(if you know how to install / use python). There are a few graphical glitches under osx though due to tkinter.
They'll be back in stock as soon as I ship out the last few orders. Tonight hopefully!
Oh and if you are running windows 8.0 or earlier you can use the usb linker cable to transfer save files to PC.
I can't make it down this weekend :-(
I'll be heading up to Pixel Sounds the following weekend though.
This weekend!!!! Who's going?
I'm not sure if that is possible under the MIDI spec... One must be a master?
Would the preference be a USB-Midi input/output or a traditional MIDI I/O?
Does anyone wanna get started on that?
It would need to be heavily moderated to remove all the hate that would no doubt end up in the thread. Are there any non affiliated mods here?
Correct, it is up to the listening device to accept the data as it arrives. Normally triggering an interrupt to process the data or put it in a buffer for later.
If you miss a key off command, you'll know about it.
Midi serial isn't that fast but with one or two bytes added for checksum and correction you begin to add latency, added is the fact that the gb is waiting for the bytes and then needs to process the data. This all happens very quickly until a bit is skipped. Worst case it will request the byte again from the external device etc...
A skipped bit needs to be detected and then the port flushed to resynchronise. This is typically done by switching modes from slave to master and sending a byte. More time wasted.
The GB needs to do all this while still executing its code, gui etc... A rom like this should be built around the serial port rather than having it a serviced subroutine.
The GB's serial port is really not suited to high speed data without corruption. Error detection is required which adds data overheads, latency and if you want it 100% robust then there are penalties.
Carefull matching of clock cycles between the GB and external interface is generally required if you want to maintain high speeds.
The code is opensource so it should be easy enough to find.
I'll work on the midi bugs first. Once I get a reliable data transfer we can assess the latency and see if it is an issue
ChipMusic.org / Forums / Posts by BennVenn