Hi all,
As I stated in another thread; I am also a curious soul who wanted to get an FP-301D CW IDer working; although I took the different route of reverse engineering the basic format. Then I found that Randy/W7CPA got the Japanese manual with the programming table. It verified what I'd figured out with the exception of giving me bit lengths to work with.?I am planning on writing a small simple utility in Python (or some other language possibly) that will generate the binary data you need to write to an EPROM/EEPROM that should work with some logic level circuitry. There's also no reason this same data wouldn't be useful on the original style PROM. Data is data...you flip addresses on and you get data out. Everything else is just TTL vs CMOS and open collector vs tri-state.?
Thus far, I've made a table of letters and numbers that contain the bits needed:?
I also...using my own list...worked out "de nq4t" by hand:
75 10 1D D7 15 1C 70 00
Yes, that's all in hex. This the first thing I have to figure out the best way to handle. All the numbers and letters are varying bit-lengths and due to being time-code, you can't really just pad things between letters. You could, sure. The only real limitation you have is 8 bits of "0" triggers it to reset the ID circuit. Even the sheets say you can use fewer or more blanks between letters/words as long as you remember that rule. I think there might be a better way of doing it...because at this point I haven't even written any software...all the binary and hex I'm producing was figured out in my head.?
011101010001000000011101000111011101011100010101010111000111
This is the binary string I came up with originally. So I just broke that down in to 1-byte (8-bit) chunks:
01110101
00010000
00011101
00011101
11010111
00010101
01011100
0111
As you can see we actually came up with 7 bytes and a nibble. So what I'll need to do is have my software do is just pad everything out to fit evenly in bytes.
With a pre-defined table it's mostly just a case of text processing. That's not easy to do in Python so it'll take me some free time to figure it out.
I have also considered modding things to replace the 74188 and 74151 with just something like a 28256 EPROM. This would be rather easy to do by tying the address lines for the 74151 to the lower address bits and use the 74188's as the higher address bits. There's more than enough space to waste in a 256kbit EPROM; it would just make programming a LOT more difficult since rather than storing time code as bytes...you'd have to store them as specific addressing. It might be easier to just outright replace all the logic (keyer and clock) with a microcontroller too.
But I'll still get some imaging creating software done since I'll need it for my development/hacks.
73,
Jay/NQ4T