Slashdot Mirror

Having worked so much on my personal pages, and having seen others that are really great, it's a bit distubing to hear an attitude like "all of the best of the Internet ... NO porn or personal websites".

There certainly are a lot of cases of personal sites that are arguably better than a good portion of their commercial counterparts. Phil's Photo.net comes easily to mind. Jakob Nielsen's Useit.com is probably another well known example. How about mp3projects.com, which is hosted on freeservers.com.

So I'm wondering what is it, exactly, that makes a personal website, well, a personal site that they're above indexing?

• Contact info for the author, instead of a generic webmaster@ ??
• Having the tilde ("~") in the URL?
• Authored by a real person who cared instead of a by-the-hour web consulting firm?
• Not selling any products?
• Not being a company or institution (w/ a logo)?
• A main page lacking over-done graphical design and/or flash-based intro?
• Black-n-Yellow "Under Construction" signs?

Still, the attitude expressed about personal websites is a bit disturbing. You'd think folks building an index of the net would know a bit more about some the truely great personal sites.

A couple months ago, slashdot linked to my site, at this page, from this slashdot article. I actually had a few emails back and forth with Rob (CmdrTaco) in the week before the link, and I asked him to avoid linking until I could get all the images over to a faster vitual hosted site, and I was still putting a lot of work into overhauling the page and writing the latest info (I had just finished a new board design for the player).

Well, the slashdot effect was indeed mighty, and my poor little site served up about 40000 hits, which appears to have been less than 1 in every 5 attempts, perhaps even less, I'll never know.

A couple people posted links to the google cached page, which was actually this older version of the project... not at all the same thing, and certainly not the one that the slashdot article was about.

So based on my real experience, a sample of one, the google cache was not only ineffective, but it did more harm than good. Rob linked to the page right after new content was posted (a common scenario of a news site), and the google cache had an older (totally different) version that led many readers to find material older, but similar enough that they could not tell the difference.

A couple months ago, slashdot linked to my site, at this page, from this slashdot article. I actually had a few emails back and forth with Rob (CmdrTaco) in the week before the link, and I asked him to avoid linking until I could get all the images over to a faster vitual hosted site, and I was still putting a lot of work into overhauling the page and writing the latest info (I had just finished a new board design for the player).

Well, the slashdot effect was indeed mighty, and my poor little site served up about 40000 hits, which appears to have been less than 1 in every 5 attempts, perhaps even less, I'll never know.

A couple people posted links to the google cached page, which was actually this older version of the project... not at all the same thing, and certainly not the one that the slashdot article was about.

So based on my real experience, a sample of one, the google cache was not only ineffective, but it did more harm than good. Rob linked to the page right after new content was posted (a common scenario of a news site), and the google cache had an older (totally different) version that led many readers to find material older, but similar enough that they could not tell the difference.

Probably about the time macrovision came into widespread use and VCR manufacturers adjusted the time constants in their VCR's AGC circuits to avoid recording signals with the macrovision pulses in them. Ok, that's hardly the exact time that technology came into use that presumed the user to be a pirate... I remember all sort of very interesting floppy-based copy protection on the Apple ][ software. FWIW, strong floppy-based copy protection did ultimately turn out to be a pointless war, but macrovision is here to stay.

The thing I can't figure out about SDMI is what happens if rouge hardware manufacturers make players that don't check for the watermarks. For example, I'll never put any code in my little MP3 player to check for watermarks. I guess my little project doesn't matter in the grand scheme of things... but if there's a market for non-SDMI players, I'm sure there are lots of folks who will provide them in the interest of making a buck. There just isn't any security in CDDA format, other than watermarks, and watermarks will only work if other devices check for them.

Back in the old days before SDRAM, DRAM memory speed was usually discussed in terms of the access time, which improved from about 150 ns in the Apple2 days to about 60 or even 50 ns when EDO DRAM was the most commonly sold. Even this access time spec was a bit misleading. Access time is the time from the beginning of any access (assering the RAS signal) until the data pins have valid data on them, and it doesn't tell the whole story about how rapidly you can really go about getting what you need.

Nowadays, SDRAM is the standard memory type, and all of a sudden, out of nowhere, the spec went from 60 ns to 10 ns! What did not happen is a six fold increase. The SDRAM "ns" spec is the period of the clock, to which all the other waveforms are sync'd. To access a SDRAM, you need to spend at least one clock giving it the row address (just like the RAS and row row addr for async DRAMs). Then you need to wait either 2 or 3 clocks (it's always 3 when used at the maximum clock) to get the data. This 2 or 3 delay is what's called the CAS latency, and many PC BIOS config let you change it.

SDRAM certainly is fast, but to say that the latency is 10ns is absolutely false. What is so good about SDRAMs is that the signals are sync'd to the master clock, and that the chips have interleaved banks that work together with the page mode accesses. I'll ramble on about that in a moment, but first a tiny bit of background...

All DRAM is arranged with the memory cells in rows and columns. An 8Mbit chip may have 1024 rows, 1024 columns, where each cell is 8 bits. To read or write any part of the chip, you first select the row, then select the column, and then go about your business. DRAM cells store information as charge on tiny capacitors. These capacitors slowly lose their charge, so they have to be recharged regularily, or the information will be lost. This process is knows as DRAM refresh.

DRAM memory reads are always destructive. When a row is selected, all the data from that row is transfered to a buffer. The tiny capacitors and the single transistor that's built with each one drive a fairly long column wire, which ultimately connects to a sense amplifier, and those amplifiers load the data into the buffer. At this point, all the memory cells in that row have lost their data, but that data is located in the buffer.

The second step to access DRAM is to select the column. With async dram, the CAS signal strobes the address pins (which had better have the desired column address). With SDRAM, the address pins are expected to have a valid column address before the next clock (setup time). For reading, the chip connects to portion of the row buffer to the data bus, and for writing whatever's on the bus is written into the portion of the row buffer that corresponds to whatever column address is selected. After you've made all your column accesses (all within the row you originally selected), you deassert the control signals, and the chip stores the buffer back into the correct row. This is known as the "precharge time", and it takes almost as long as the access time. For a 60 ns EDO DRAM, this would be about 45 ns... so for random reads (not the same row), you'd only be able to do one every 105 ns!

Fast page mode DRAM (were there ever any DRAMs that didn't do this?) allows you to perform multiple operations on the same row, by deasserting the CAS signal to end the current operation and then reasserting it again for the next. EDO DRAM is basically the same thing as FPM, but they made a minor change so that when reading, the bus would remain driven even after CAS was deasserted. This allowed DRAM controllers to deassert the signal (necessary before reasserting it) before getting the data from the DRAM. There was a lot of hype about EDO, and it did indeed have higher system bandwidth, but in truth it's just a very minor change in the design.

SDRAM works more or less the same way, but with a clocked interface. Like a lot of technologies, there's been a lot of misleading marketing hype about how great SDRAM is, but it really is just a new front end (with some advantages) on top of the same old DRAM technology. Not having designed a working SDRAM controller (yet), I'm speaking from less experience... mostly just reading data sheet and app notes. To access the memory, you assert RAS and deliver the row address on the first clock (everything is setup and hold relative to the master clock). You deliver the CAS and column in the next clock, and then wait either 2 or 3 cycles for the data. Just like all other DRAMs, you can access mulitple columns in within the same row. This page mode access is what's really fast about SDRAM.

SDRAM chips have either 2 or 4 banks of memory, and they support an interleaved access mode, where you can read from alternating banks on each clock cycle. This is what allows a SDRAM to actually deliver data every 10ns. A 4 bank SDRAM is actually 4 banks, each allowed to take 40 ns for each column, but the system can read a new column every 10 ns! DIMMs are 64 bits wide (usually 8 chips each 8 bits wide), so you're getting a lot of data very rapidly... but only from within a small block (one row), and only after you spent some time selecting the row, and don't forget that when you're done within that row, you'll have to wait through the precharge time before you can select another row.

The interleaving trick was possible with older FPM DRAM chips, where you'd select a row from two SIMMs, and then read columns alternately from each one. I recall the Apple did this in some of their (then) high-end Macs. EDO doesn't allow this, unless you have two separate data busses, because the EDO "tweak" is to keep the output drivers turned on after CAS is deasserted, until the entire row access is over (RS deasserted).

So, dear reader, if you've read through all this long winded posting (which is actually a rough draft for a part of a web page about the DRAM controller in my little mp3 player project), the main point is that DRAM is arranged in rows and columns, and to access the DRAM, the DRAM controller has to go though a few steps. The really fast data rates one typically hears about are only the special case where you're accessing multiple columns within a single row, and that row selection and precharge time are important, even if they're not the specs commonly mentioned.

The really fast page modes (all DRAM types, particularily SDRAM) are really quite useful for modern computers, because the CPU never really accesses the DRAM... it always communicates with a fast cache memory, and the DRAM controller's job is to fill and flush cache lines (groups of bytes) from/to the DRAM, which always results in accessing consecutive columns within a row.

So to finish up and bring it around full-circle, Dave Zarzycki's comment not only mistakes the SDRAM clock period for latency, but also ignores the fact that the SDRAM or ROM will only be accessed for cache misses. For a large ROM (like the linux kernel being discussed in this thread), cache misses will be an important factor. Nonetheless, it's not valid to simply compare the single marketing-published (unrelated) numbers for chips and not consider their interactions with the system and its cache.

I'm finally getting around to reading through the comments, after a long day of (trying in vain) to deal with the slashdot effect, getting people's boards ready, and answering hundreds of emails.

I've spent many many hours designing this player to make is affordable. I originally wanted to make it under $100, and I might have been able to get close to that without the power supply and DRAM controller. It's been a tough project with a lot of little twists and turns, which you can read about (more or less) on my web site's history page, linked at the bottom of the recent news page.

It's a bit disturbing to see a project that I've poured all my free time and energy (and a lot of money), as well as accumulated vacation time from work, described as a $450 gizmo. I can see how, to you, it's a "gizmo", but it's certainly not $450. We're selling the assembled boards for $150. Now, admittedly you need to add stuff. There are a large number of people who have or have access to obsolete computers with SIMMs, hard drives and power supplies. If you're in that group, you'll be able to get it going without spending anything more. The board currently doesn't use the SIMM, and laptop drives start at about $140 for the smaller capacities. Standard drives are often available for about $80, and it's possible to use a standard drive, admittedly with an external power supply, which also is readily available in the PC component marketplace at low cost. Sure, you can buy the 80 gig drive, but saying something looks cool (or uber pimp, as the case may be) because it can go up to 80 gigs is a long ways off from "rubbing it in your face" (at the highest possible price). I'm amazed you can see Rob's posting in this light. I suspect viewpoints like this come from spending one's creative energy hating successful people rather than directing it into activities that might make you a success as well.

Also, Rob and Slashdot do not get a commission. There is no kickback. We're far too small to even be able to make a meaningful kickback. I like a good conspiracy, but there just isn't one here. Several days ago I offered to send a free board to Rob for eval, but he declined, even when I offered to send it with a pre-loaded hard drive, power supply and speakers. Rob's a really busy guy!

I'm finally getting around to reading through the comments, after a long day of (trying in vain) to deal with the slashdot effect, getting people's boards ready, and answering hundreds of emails.

I've spent many many hours designing this player to make is affordable. I originally wanted to make it under $100, and I might have been able to get close to that without the power supply and DRAM controller. It's been a tough project with a lot of little twists and turns, which you can read about (more or less) on my web site's history page, linked at the bottom of the recent news page.

It's a bit disturbing to see a project that I've poured all my free time and energy (and a lot of money), as well as accumulated vacation time from work, described as a $450 gizmo. I can see how, to you, it's a "gizmo", but it's certainly not $450. We're selling the assembled boards for $150. Now, admittedly you need to add stuff. There are a large number of people who have or have access to obsolete computers with SIMMs, hard drives and power supplies. If you're in that group, you'll be able to get it going without spending anything more. The board currently doesn't use the SIMM, and laptop drives start at about $140 for the smaller capacities. Standard drives are often available for about $80, and it's possible to use a standard drive, admittedly with an external power supply, which also is readily available in the PC component marketplace at low cost. Sure, you can buy the 80 gig drive, but saying something looks cool (or uber pimp, as the case may be) because it can go up to 80 gigs is a long ways off from "rubbing it in your face" (at the highest possible price). I'm amazed you can see Rob's posting in this light. I suspect viewpoints like this come from spending one's creative energy hating successful people rather than directing it into activities that might make you a success as well.

Also, Rob and Slashdot do not get a commission. There is no kickback. We're far too small to even be able to make a meaningful kickback. I like a good conspiracy, but there just isn't one here. Several days ago I offered to send a free board to Rob for eval, but he declined, even when I offered to send it with a pre-loaded hard drive, power supply and speakers. Rob's a really busy guy!

For a player that fits into the world envisioned by Thomson & Fraunhofer IIS-A, it's really not that expensive to make a cool MP3 player...
<shameless plug>
...like this one that I've been working on lately.
</shameless plug>

When I get the DRAM controller integrated with the rest of the design, I'm expecting to get at least 6 hours from four AA size NiMH batteries, perhaps more... I think 10 hours will turn out to be the upper limit I could get from my design. My testing is based on the NiMH 1500 mAH rated batteries that are available from Radio Shack.

The really cool part is that the DRAM controller is implemented in a firmware configured FPGA chip, so a no-buffering board can be flash upgraded to have a hardware based DRAM controller and high speed DMA (req'd to minimize the time the drive is sucking 5 watts from the batteries).

I have a fractional T1 service... but "fractional" can mean a lot of different speeds, and in my case it's only 128 kbps. It is expensive to set up a T1 service, but at least in Portland Oregon, it's not quite as bad as you make it out to be.

The most expensive part is the upstream service from an ISP. Most ISPs are quite expensive. I did quite a bit of searching in my area, and I found two with competitive prices. I went with Internet Arena, because the other was some christian place with filtering at their router, and we've all heard about how well filtering software works.

Not far behind the ISP is the telco. In my area, it's GTE. A year ago their prices were lower... it seems strange that they're increased. Unlike the ISP, at least where I live, you're stuck with your local telco. The service is Frame Relay. In Oregon, and probably in many other places, there's no room for a bargain, since the rates are set by a utility commission.

Of course, you then need equipment. I wanted a low cost Linux based solution. At the time, the only real option was Sangoma. They sell a card that goes in your PC that more or less does everything you need. The mounting bracket has one 8 pin jack (same size and shape as an 10baseT ethernet connector) but it's for a T1 line. Like ethernet, only four wires are used, a pair for transmit and a pair for receive. I'll give more details about the wiring below. You can always email me if you're trying to set it up and have a question.

Indeed it is expensive. I don't recall all the costs down to the penny, but here's more or less how it worked out:

• Setup: Samgoma card, $950
• Setup: Telco install fee, $350
• Reoccur: Telco, $123
• Reoccur: ISP, $150

Now I could go on about why I decided to spring for an expensive T1 service, but that's really getting off-topic from and already slightly off-topic post. The main point of this post was to respond with the actual costs of setting up a low speed fractional T1 service.... or at least the actual costs in my area, as they were about a year ago. A secondary purpose was to give a little bit of info about how to do it. To that end, I'll ramble on just a bit more about the setup.

I called both the ISP and the telco and asked about how to set things up. My experience was that it's better and easier to deal with the ISP. Finding a cool ISP is not easy, but they're out there. Dave at Internet Arena is a great guy, so if you're in the Portland area, I'd suggest you give Dave a call. He's got a bunch of other really high speed/moderate cost options for certain areas, using leased T1 lines instead of the telco. Anyway, the point is to talk with ISPs and make a visit to any you want to do business with.

Often times the ISP will call the telco for you to set up all the details, but you can get involved if you want. I did. Each T1 line has a circuit ID number. Your new service will get a number. When you hear your new number, be sure to write it down and don't lose it. You may never need it again, but it's a pain to find someone at the telco who knows enough to look it up if you ever have a problem with the line.

Frame Relay is a protocol, much like the ethernet 802.3 frames. Like IPv4 gives 32 bit IP addresses, frame relay provides DLCI numbers. Unlike IP, a DLCI number is a short integer which is unique only on your line. The phone company establishes Permanent Virtual Connections (PVC) through the frame relay network, by adding routes and doing who knows what else. Ultimately, the PVC will link a DLCI number (short integer) on your your circuit ID (big long number) to a DLCI number on the ISP's circuit ID. You'll probably never use the circuit ID number, but you do need to know the DLCI number to set up the sangoma card.

Since I bought my card, Sangoma has made some major improvements in the setup process (I set up another card for someone a couple months ago). The installer looks a lot like RedHat's text based installation program. It will ask you about for various bit of information, and it'll want to know about each DLCI you have. You'd probably only establish one PVC to your ISP, but it's possible to have lots of PVC to other people, all running on the same line. After the installation, each PVC will appear as an interface. I named mine "fr16", and it looks like this when I run ifconfig:

fr16 Link encap:Frame Relay DLCI HWaddr 4096
inet addr:207.149.244.8 P-t-P:207.149.244.1 Mask:255.255.255.224
UP POINTOPOINT RUNNING MTU:1500 Metric:1
RX packets:4889031 errors:0 dropped:12 overruns:0 frame:0
TX packets:7655668 errors:136874 dropped:51 overruns:0 carrier:0
collisions:0 txqueuelen:10
Interrupt:7 Base address:0x360 Memory:c00de000-c00dffff

From here it's just the usual linux routing things.

Well, that's probably enough rambling on. If anyone reading this is looking to set up a T1 service on linux, on a budget, hopefully this has helped a bit instead of just creating more confusion. It's not cheap, but also not as bad as some people make it out to be.

It's really not a big deal to make your own chip. When I was doing grad school part time several years ago, I made this little chip, together with a small group of other students. The whole thing only took a couple months to design. I learned a lot and since then I've had a much better perspective about how ICs are designed, which has been helpful designing at the board level.

The CNN article is remarkable vauge about what Microsoft's chip actually does.... it may be a CPU, or maybe just "glue logic". Whatever it is, it's common to design ASICs for high volume products. Unfortunately, it also common to make a big deal out of nothing.

About how windoze sucks... last night I installed a removable drive bay, and put the IDE drive into my machine. My computer has no other IDE devices, the disk and cdrom are both SCSI. Windows pops up a blue screen saying that it's going to have to switch to "compatibility mode", only because I just installed an IDE disk drive! Compatibility mode means everything is running 16 bit drivers, as I understand it. Well, the next couple boots both crashed, for no apparant reason. I finally did get it to boot, opened a DOS window and ran FDISK and FORMAT on the new drive. Somewhere near the end of FORMAT, the machine completely crashed, with some sort of message about the system being "halted" for some reason. I did finally get the drive formated by creating a "startup disk", booting the computer with that. Under this config, the drive letters were reversed from their appearance in windows... another thing that isn't a problem in linux. Fortunately I noticed the drive sizes before formatting "D:" and losing my existing windows installation.

Even after I removed the IDE drive and attached it to my hardware, Windows is really messed up. It's still in compability mode, and how to fix that is a good questions.... at least not without using linux.

In the last year or so, I've been using Linux to make backups of my windows partition. I have another machine that runs linux 24/7 and exports some shares with samba. I always save my work to "F:", so "C:" only has the system, software, and other non-data files. Many windows programs always default to saving stuff on "C:", often in their own installation directories, which seems like a bad idea to me, but it's only a minor annoyance compared to windows crashing.

Anyways, to back up my windows partition, I type something along the lines of:

cat /dev/sda3 | bzip2 -9 - > /tmp/sda3_windoze_backup.bz2

and then later on, when windows gets itself all messed up in a state which is more or less not recoverable, I just "cat" that image file back onto the /dev/sda3, and just like magic windows is back in a previously working state, completely reinstalled, and with only one reboot.

Actually, before I do the backup, I type "cat /dev/zero > /dos/dummy.bin" to fill the unused space with zeros, and then delete the file, so that the backup image will compress well.

I'm glad that you don't have any problems with Windows, and I wish my experience was the same. Right now, my windows partition is really messed up, and I need to find the CDR that I burned that big .bz2 backup file onto.

At the risk of getting moderated down for blantent self promotion, here's a link to my little MP3 player project, which is the reason I needed to temporarily add an IDE drive to my machine, and why Windows went south.

Writing your own player firmware is not easy. I bought a copy of ISO 11172-3 (the MPEG1 audio spec), and it's quite complicated. There are lots of open source players, but they all use floating point math, because it's so much easier and runs fine on any modern PC. Maybe I'll write this someday. If I do, I'll GPL it.

For now, I'm not using this EP7209 chip right now, mainly because it's in a 208 pin high density surface mount package, and one of the goals of my homebrew MP3 player project is to offer a design and components that an average electronics hobbist can build.

Of course, it'll be a challenge to make the existing decoder chips (MAS35077D and STA013) SDMI compliant, since they don't interact with the user, so they could only see the trigger and perhaps tell the microcontroller chip to prompt the user. Since these chips lack non-volatile memory (and probably always will), any player like mine that is open source will allow the user to interact with the chip however they like.

I doubt they'll manage to make these chips SDMI compliant in any meaningful way, but it's still a very scary thought... this guy's obviously in bed with the RIAA and maybe he's just speculating, or maybe he knows something?

Most MP3 players (including my homebrew design) use the MAS3507D or STA013 chips.

If these chips were to start checking for the SDMI phase 2 watermark, it could be game-over for most of the portable players. Of course, these chips are firmware upgradable, and they have no interaction with the user interface, so it's hard to see what they could do with them.

That wouldn't agree with the uniform licensing requirement that they agreed to when they submitted the codec to ISO for the MPEG standard.

They've already allowed royalty-free use for free desktop software players that are obtained by internet download, which was a smart move, as it has created demand for non-free licensed hardware decoders, and non-free encoders. The hardware decoder chips sold by Micronas and (suprise) SGS Thompson already have price committments to the manufacturers of players. Maybe that's just wishful thinking on my part, as I'm about to order a couple hundred chips for my open-source hardware-based player. (ok, that was a shameless plug, but it really is open source and the code is available on the web site right now).

As I recall, the patent was issued in 1989, so even if the RIAA could lean on Thompson, it would only last six or nine more years. The USA patent was issued in 1996, but somehow I suspect the ISO 11172-3 standard, published in 1988, could probably be considered prior art.

<shameless plug>
I'm in the process of setting up on-line ordering on my website right now. Most of the website is technical resources for building electronic projects using embedded processors. A recent addition, that we expect to need the on-line ordering for, is the open source MP3 player, which today is a primitive first generation design, but hopefully soon I'll have a nicely redesigned version.
</shameless plug>

Fortunately, my partner is an accountant, which has really helped. She set up a proper visa merchant account with our bank. It cost $100 up front. They take $0.65 per sale, plus approx 3%. There's a minimum $15 monthly charge, so hopefully we'll actually sell at least $500/month. The visa charges are entered using a touch-tone phone, so we didn't have to buy any equipment. They offer a terminal, for (I think) $450. With the terminal, we would get a per-sale charge of $0.07, and a little lower percentage of the sale, about 2.5% as I recall. They let you buy and add the terminal anytime you want.

It looks like there's a free software package called CCVS - Credit Card Verification System which allows your linux (or unix) box to emulate a terminal (requires a dedicated modem)... but there's a catch. It needs to be loaded with an encryption key. Redhat sells these keys for approx $1000. If anyone knows someone who can provide a key for CCVS for less, please contact me. Robin found a similar windoze based program, where they wanted a monthly charge and some percentage of the sale, on top of the percentage taken by the bank! Not cool, but I wouldn't run a windows server even if it was affordable.

Setting up the SSL stuff on the webserver is relatively easy, but you need a cert. VeriSign charges $350, so we went with Thawte, who only wanted $125 (even though they're now owned by Verisign). Again, robin did most of the work there. I generated the CSR from the server software, and she faxed them copies of our LLC papers and other business stuff. About a week later we got the cert. The cert lasts for only one year, you it looks like we have to pay $125 every year. I hope they don't jack their price up to Verisign's level!

Robin ran a test charge onto her credit card a couple days ago, and it seems to be working very nicely. The merchant appears as "PJRC.COM, LLC", which I think is much cooler than "ibill...some number".

For the on-line shopping cart, I looked at a couple of them, but they didn't have that look and feel that I want for my website, so I've been rolling my own. It's turned out to be a bit more coding than I originally thought, but still not too bad, and I'm really happy with the results. When the order is confirmed, the code just sends Robin and I an email, and makes sure the data stored in our database really matches what they filled out on the form.

I'm putting the final finishing touches on the cgi scripts right now, and hopefully it'll be on-line later tonight!

<shameless plug>
I'm in the process of setting up on-line ordering on my website right now. Most of the website is technical resources for building electronic projects using embedded processors. A recent addition, that we expect to need the on-line ordering for, is the open source MP3 player, which today is a primitive first generation design, but hopefully soon I'll have a nicely redesigned version.
</shameless plug>

Fortunately, my partner is an accountant, which has really helped. She set up a proper visa merchant account with our bank. It cost $100 up front. They take $0.65 per sale, plus approx 3%. There's a minimum $15 monthly charge, so hopefully we'll actually sell at least $500/month. The visa charges are entered using a touch-tone phone, so we didn't have to buy any equipment. They offer a terminal, for (I think) $450. With the terminal, we would get a per-sale charge of $0.07, and a little lower percentage of the sale, about 2.5% as I recall. They let you buy and add the terminal anytime you want.

It looks like there's a free software package called CCVS - Credit Card Verification System which allows your linux (or unix) box to emulate a terminal (requires a dedicated modem)... but there's a catch. It needs to be loaded with an encryption key. Redhat sells these keys for approx $1000. If anyone knows someone who can provide a key for CCVS for less, please contact me. Robin found a similar windoze based program, where they wanted a monthly charge and some percentage of the sale, on top of the percentage taken by the bank! Not cool, but I wouldn't run a windows server even if it was affordable.

Setting up the SSL stuff on the webserver is relatively easy, but you need a cert. VeriSign charges $350, so we went with Thawte, who only wanted $125 (even though they're now owned by Verisign). Again, robin did most of the work there. I generated the CSR from the server software, and she faxed them copies of our LLC papers and other business stuff. About a week later we got the cert. The cert lasts for only one year, you it looks like we have to pay $125 every year. I hope they don't jack their price up to Verisign's level!

Robin ran a test charge onto her credit card a couple days ago, and it seems to be working very nicely. The merchant appears as "PJRC.COM, LLC", which I think is much cooler than "ibill...some number".

For the on-line shopping cart, I looked at a couple of them, but they didn't have that look and feel that I want for my website, so I've been rolling my own. It's turned out to be a bit more coding than I originally thought, but still not too bad, and I'm really happy with the results. When the order is confirmed, the code just sends Robin and I an email, and makes sure the data stored in our database really matches what they filled out on the form.

I'm putting the final finishing touches on the cgi scripts right now, and hopefully it'll be on-line later tonight!

<shameless plug>
I'm in the process of setting up on-line ordering on my website right now. Most of the website is technical resources for building electronic projects using embedded processors. A recent addition, that we expect to need the on-line ordering for, is the open source MP3 player, which today is a primitive first generation design, but hopefully soon I'll have a nicely redesigned version.
</shameless plug>

Fortunately, my partner is an accountant, which has really helped. She set up a proper visa merchant account with our bank. It cost $100 up front. They take $0.65 per sale, plus approx 3%. There's a minimum $15 monthly charge, so hopefully we'll actually sell at least $500/month. The visa charges are entered using a touch-tone phone, so we didn't have to buy any equipment. They offer a terminal, for (I think) $450. With the terminal, we would get a per-sale charge of $0.07, and a little lower percentage of the sale, about 2.5% as I recall. They let you buy and add the terminal anytime you want.

It looks like there's a free software package called CCVS - Credit Card Verification System which allows your linux (or unix) box to emulate a terminal (requires a dedicated modem)... but there's a catch. It needs to be loaded with an encryption key. Redhat sells these keys for approx $1000. If anyone knows someone who can provide a key for CCVS for less, please contact me. Robin found a similar windoze based program, where they wanted a monthly charge and some percentage of the sale, on top of the percentage taken by the bank! Not cool, but I wouldn't run a windows server even if it was affordable.

Setting up the SSL stuff on the webserver is relatively easy, but you need a cert. VeriSign charges $350, so we went with Thawte, who only wanted $125 (even though they're now owned by Verisign). Again, robin did most of the work there. I generated the CSR from the server software, and she faxed them copies of our LLC papers and other business stuff. About a week later we got the cert. The cert lasts for only one year, you it looks like we have to pay $125 every year. I hope they don't jack their price up to Verisign's level!

Robin ran a test charge onto her credit card a couple days ago, and it seems to be working very nicely. The merchant appears as "PJRC.COM, LLC", which I think is much cooler than "ibill...some number".

For the on-line shopping cart, I looked at a couple of them, but they didn't have that look and feel that I want for my website, so I've been rolling my own. It's turned out to be a bit more coding than I originally thought, but still not too bad, and I'm really happy with the results. When the order is confirmed, the code just sends Robin and I an email, and makes sure the data stored in our database really matches what they filled out on the form.

I'm putting the final finishing touches on the cgi scripts right now, and hopefully it'll be on-line later tonight!

My website runs through a 128 kpbs frame relay line, so apache's sluggish pre-forking architecture is just fine. Even at full T-1 speed (which really is only about the same as a single-speed CDROM), apache is still plenty fast enough.

For four years, my web site was hosted by the Oregon State University Electrical Engineering Webserver, at this url that was widely linked and in all the search engines' first result page for a number of keywords.

Well, all good things (actually their server was not very reliable) come to an end, and the university was under a big scare, supposedly because of some lawsuit somewhere, regarding old accounts from former students. I got a message that I would need to move my site.

I did indeed move the page, to it's new and permanent location, but even after over a year, the old site still gets lots of hits. Forunately, they have been nice enough to keep my redirector page in place all this time.

At first, I did what seemed like the obvious thing and I set the HTTP-EQUIV meta tag to redirect, in zero seconds. Seemed like a good idea. It was actually like that for months, and I was totally unaware of the problem. I finally got an angry e-mail from someone who was upset that I messed with his back button, but as far as I could tell, nothing on my site would do that. Indeed, nothing on my site was doing anything with the back button.... by that time I hardly gave any though to the old urls anymore, so it didn't even occur to me at the time to try going to the old url and then seeing if the back button still worked. Even if I'd typed the old URL, to experience what an ordinary web surfer got, I would have had to find my url from a link (not hard, since the search engines don't update well anymore, even if you fill out their forms to rescan your url).

Well, several weeks later, I learned what had happened while reading Jokob Nielsen's Alertbox Column, Top Ten New Mistakes of Web Design. Breaking the back button was his number 1 offense, and I was guilty... and until that moment I didn't even know it.

My point in all this, dear reader (and you're still reading after all this rambling), is that it's easy to need to redirect users, because old URLs don't stop getting hits, even after a year.

Some people have said that the web design should use a location redirect in the HTTP header. I tried this, but the browsers generally don't honor that from within the HTTP-EQUIV meta tag (even though they should), and I have no control over the configuration of the server itself, only the html content.

It's easy to say the commercial companies are different, since their web servers are for their corporate missing (whatever that is), but I can easily see how the "web designer" only has control over the content within the html file itself, and not the web server config... often times controlled by an admin who isn't helpful, or a third party hosting company.

I've seen a number of comments above where the poster has lept to the conclusion that this thing is comparable to a "real" web server, such as apache running on a unix platform.

The most important limitation that I can see in the code is that it only remembers information from the previously received packet, and it can only send a packet in response to receiving one, but can't retransmit on a timeout not having received an ACK. Calling this TCP is a streatch at best. It's certainly a long way from RFC-1122.

For example, consider the case where two clients attempt to access this little web server at the same time, which is not unlikely running the data pipe at 19200 baud, and having CTS inhibiting data flow in between every received byte, and during all data transmission. The remote IP address is overwritten as the second packet is received, causing all knowledge of the first connection to be lost. Most of that information will be regained when the first host sends another packet, but the point is that this little web server isn't going to work well with multiple connections at the same time, and probably won't work at all if the TCP retransmit is require because of any packet loss.

It is a neat project, and doing even this minimal tx follows rx without pre-connection state is some impressive code for such a small chip. Neat as it is, it just isn't a viable web server for any application where multiple clients may use it. It probably won't do well on networks that have packet loss, duplicated packet and the other not-so-common problems that come with the best-effort (but unreliable) IP datagram service.

And now for a shameless plug.... for the posters above who were talking about connecting a disk drive, here's a little project I did that connects a IDE hard drive to a 8051 microcontroller. Maybe it could be used with a PIC? My code is public domain, so it could be combined with a GPL'd project, like this little web server.

Someday (hopefully within a couple months) I may have to deal with the slashdot effect, with my Homebrew MP3 player project, which is open source, but at the moment only in a just barely working state.

My question, specifically from your recent experience, is how should one deal with the slashdot effect, knowing that is coming.

Of course, then there are issues of user interface, playlists, low power consumption, etc. Still, if I can put something together by myself in just a couple weeks, it makes me wonder why all the commercial vendors are so late to market.

Maybe if there is some interest, I'll make some improvements to the design and arrange to make the assembled/tested circuit boards available at a reasonable price... see the bottom of the page for more info.

Paul

Of course, then there are issues of user interface, playlists, low power consumption, etc. Still, if I can put something together by myself in just a couple weeks, it makes me wonder why all the commercial vendors are so late to market.

Maybe if there is some interest, I'll make some improvements to the design and arrange to make the assembled/tested circuit boards available at a reasonable price... see the bottom of the page for more info.

Paul