nesdev.com

If you want to try to implement KCS in csound, it's really simple:

The 1200 baud variant is 1200 baud 8N2 serial, where 1 bits (including stop) are 2 full cycles of 2400Hz, and 0 bits (including start) is 1 full cycle of 1200 Hz. Microcomputers often use a 1-bit ADC, so their implementation is almost always just limited to "count the amount of time between zero-crossings, and see if it's two 833µs periods or four 417µs periods". I don't know how much more sophisticated you could get using a greater-depth ADC.

... Also, the source for the kcs08 program (KCS.SCR) is hilariously awful in that it doesn't have line endings, the entire thing is just a 64-column textmap.

Perhaps this might be an opportunity to get out of the FSK that is KCS/CUTS and into MFM or (0,2)RLL or QPSK, which would drastically increase the data rate. The first step in implementing these would involve some sort of equalization pass to correct phase errors at the decoder.

I've been tempted to try to write a RLL(2,7) encoder-decoder for maximal data rate, except that I have no place where I'd actually use it.
For an audio system that can reliably record 2400Hz-and-lower square waves, it would just break down to counting whether it's been (3..7)÷3×417µs since the last zero-crossing.

Tepples: I am uncertain whether QPSK could be decoded using just a 1-bit ADC?

Yes, as QPSK is just 0011, 0110, 1100, or 1001 from the ADC. A greater-depth ADC primarily helps with the higher data rates as it allows finding more precise transition times with cubic interpolation. But in this case, MFM or some other advanced RLL is probably the better choice.

OK. I could try.

Forth programs are often stored like that; the source-code is split into pages each of which has a fixed number of rows and columns, so line-endings need not be stored because they are implied.

_________________
.

We're going to include TapeDump in a second printing of the Streemerz bundle. Any objections?

I like this idea, please say yes

Perhaps include a small program to LOAD code over the controller ports as well? (into ram)

edit: Does the cart use chr ram? That would make this idea even more interesting because you could actually load graphics. Could lead to a fun "minigame competition" platform to strive for.

edit2: I have a strange sense of deja vu...did we discuss this before?

edit3: I'm apparently smoking crack, I typed usb instead of controller!

What USB ports?


It doesn't matter whether this cart uses CHR-RAM or CHR-ROM, once you swap carts the CHR you have access to is the one in the cart being dumped. If it's RAM, you can indeed upload some patterns from main RAM (the code/data decated to this should be minimal though, since there's only 2KB of RAM and most of it should be dedicated to dumping, not graphics), but there's nothing you can do if the new cart uses CHR-ROM.

Woops...fixed that little error.

The chr ram would be for the LOAD feature I suggested, not for tapedump of course. (presumably the load feature would load a chunk of code into the 2kb internal ram)

Ah, controller ports. Well, the EXACT opposite of what TapeDump does would be to use the Famicom microphone to load programs...! Too bad the NES doesn't have one. Anyway, what would the other end of the cable connect to? Hopefully not something that makes the cable hard to build for those not very experienced with building hardware.


Ah, I see. So, minigames under 2KB? Sounds cool, specially considering you can use self-modifying code (and you can use .db for initializing variables, saving you the space of a few LDAs/STAs). You could even decompress tiles to VRAM and then decompress the game program to occupy the space that was previously used by compressed graphics.

If someone were to figure out exactly what sort of filtering the Zapper's demodulator circuit is doing, it'd become possible to load data in through an LED and a Zapper.

Would it be possible to dump to a tape and then use the tape port on the keyboard to load data?

_________________
.

That should be possible (after all its what the tape drive port on the keyboard was for). However this would mean that people without a keyboard are out of luck. (and they'd need some way to hook it up to a ntsc/pal NES). It's probably easier to aquire a keyboard than building your own custom controller cable though.

I like tepples's zapper idea, this would really match the tapedump program. And it is very accesible, anyone with a crt tv and a zapper should be able to get it working. (if we do it right, any device with a controllable light should work if it can match the right frequencies)

edit: before this gets out of hand. Split?

I see two problems with the use of a CRT TV:

1- It would be slow as hell! Since the picture is updated at 60Hz (NTSC) and the only information you can convey through the zapper is light/dark, you'll only be able to transfer 60 bits per second. That would mean 4 1/2 minutes to transfer a measly 2KB of data, not considering extra control and error correction data!

2- How are you going to get the information to show up on the TV? You can generate a video on the PC and put it in a thumb drive or a DVD and play it on your DVD player, but that's hardly efficient. Because of the low popularity of CRT TVs these days we can hardly find video cards that can output composite/s-video, so we really don't have many options.

It wouldn't exactly be practical, but I don't think that was the point of this in the first place.

Granted, other methods would stil be apreciated. Dammit nes, y u no haz tape port!z

Controller port is stil an option of course.