From nick@ucc.gu.uwa.edu.au Sun Aug 3 12:12:44 2003 From: nick@ucc.gu.uwa.edu.au (Nick Bannon) Date: Sun, 3 Aug 2003 20:12:44 +0800 Subject: [Opendispense] List ownership Message-ID: <20030803121243.GG496873@morwong.ucc.gu.uwa.edu.au> If you put your hand up (and possibly if you don't ) I'd like to add more list owners/moderators to make sure posts do not get delayed unnecessarily. The list has been updated from the older standard list admin password to the current one. It should perhaps be renamed to "openvend" while it's young, I created opendispense largely because it had once existed in the past. There's no problem with sending mail to the list from any other address - you can resubscribe as your favourite address, or you can be added to the whitelist. Unfortunately I can't find the Mailman interface to view or add to the whitelist, so I can only do this to messages that are sitting pending moderator approval. Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal From nick@ucc.gu.uwa.edu.au Sun Aug 3 12:20:51 2003 From: nick@ucc.gu.uwa.edu.au (Nick Bannon) Date: Sun, 3 Aug 2003 20:20:51 +0800 Subject: [Opendispense] Large FPGAs In-Reply-To: <20030803092945.GC104140@morwong.ucc.gu.uwa.edu.au> References: <20030802153712.1a8da04f.harrymc@ucc.gu.uwa.edu.au> <20030803092945.GC104140@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030803122051.GH496873@morwong.ucc.gu.uwa.edu.au> On Sun, Aug 03, 2003 at 05:29:46PM +0800, Adrian Chadd wrote: > On Sat, Aug 02, 2003, Harry McNally wrote: > > After the discussion about comms alternatives, I'd like to find out [...] > How big an FPGA can you mount? > > Say, an XCV1000E or two? Those are the ones: Xilinx Virtex XCV1000E FG860, 8C ; http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=4663&item=2545447811 Monumental overkill for our application, of course, but it goes to show that it can sometimes be affordable to get our hands on FPGAs with a million gates as opposed to 128... Of course, I have nil experience with working with any device of that type. Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal From dagobah@ucc.gu.uwa.edu.au Sun Aug 3 12:30:42 2003 From: dagobah@ucc.gu.uwa.edu.au (Bernard Blackham) Date: Sun, 3 Aug 2003 20:30:42 +0800 Subject: [Opendispense] List ownership In-Reply-To: <20030803121243.GG496873@morwong.ucc.gu.uwa.edu.au> References: <20030803121243.GG496873@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030803123042.GE12993@ucc.gu.uwa.edu.au> On Sun, Aug 03, 2003 at 08:12:44PM +0800, Nick Bannon wrote: > If you put your hand up (and possibly if you don't ) I'd > like to add more list owners/moderators to make sure posts do not get > delayed unnecessarily. I'll be happy to. > It should perhaps be renamed to "openvend" while it's young, I created > opendispense largely because it had once existed in the past. And its 33% shorter :) Regards, Bernard. From nick@ucc.gu.uwa.edu.au Sun Aug 3 12:42:56 2003 From: nick@ucc.gu.uwa.edu.au (Nick Bannon) Date: Sun, 3 Aug 2003 20:42:56 +0800 Subject: [Opendispense] List ownership In-Reply-To: <20030803123042.GE12993@ucc.gu.uwa.edu.au> References: <20030803121243.GG496873@morwong.ucc.gu.uwa.edu.au> <20030803123042.GE12993@ucc.gu.uwa.edu.au> Message-ID: <20030803124256.GJ496873@morwong.ucc.gu.uwa.edu.au> On Sun, Aug 03, 2003 at 08:30:42PM +0800, Bernard Blackham wrote: [recruiting more listowners!] > I'll be happy to. Done! [opendispense -> openvend] > And its 33% shorter :) Exactly! Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal From harrymc@ucc.gu.uwa.edu.au Sun Aug 3 14:10:22 2003 From: harrymc@ucc.gu.uwa.edu.au (Harry McNally) Date: Sun, 3 Aug 2003 22:10:22 +0800 Subject: [Opendispense] Large FPGAs In-Reply-To: <20030803122051.GH496873@morwong.ucc.gu.uwa.edu.au> References: <20030802153712.1a8da04f.harrymc@ucc.gu.uwa.edu.au> <20030803092945.GC104140@morwong.ucc.gu.uwa.edu.au> <20030803122051.GH496873@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030803221022.5d9a4cba.harrymc@ucc.gu.uwa.edu.au> On Sun, 3 Aug 2003 20:20:51 +0800 Nick Bannon wrote: > On Sun, Aug 03, 2003 at 05:29:46PM +0800, Adrian Chadd wrote: > > On Sat, Aug 02, 2003, Harry McNally wrote: > > > After the discussion about comms alternatives, I'd like to find out > [...] > > How big an FPGA can you mount? > > > > Say, an XCV1000E or two? > > Those are the ones: Xilinx Virtex XCV1000E FG860, 8C ; > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=4663&item=2545447811 > > Monumental overkill for our application, of course, Not so :) Given the clock speed of our HC11 I have been thinking of some cunning plans. I spoke to Nick about the idea of also coding a serial port in the FPGA because the HC11 serial is being used. With a device of this size we can design a DMA scheme that cycle steals access to the static RAM on the daughter board and just advises the micro when a SLIP packet has arrived and the buffer address of the packet. This means a buffer allocator needs to feed the SLIP state machine a stream of buffers so why not include a buffer allocator state machine in the FPGA as well? I think it would be possible. If we want to have some secure comms to the accounting system we could build a hardware encryption engine too to avoid loading the HC11. There are all sorts of opportunities with a large FPGA limited by skill and imagination mainly :-) > but it goes to show > that it can sometimes be affordable to get our hands on FPGAs with a > million gates as opposed to 128... Of course, I have nil experience > with working with any device of that type. Well, me too, but the concept is the same FLW :) The difficulty is where high speed circuits have timing contraints that depend on layout. We don't need to run fast, we just need room for logic so I think we could stumble on a solution. I need to look at the free version of the MAXplus tools from Altera to see if it supports these devices. I'd like to use tools that are free so other can play without needing the $$$ toolset. comes back .. ok I've just looked at the MAXplus 10.2 Baseline I have on a PC here and it doesn't look like it is supported in this version. It's been a while since I updated so there may be a more recent version with support. What are MUGWA using for development? Are there GPL tools for these sorts of densities? Harry -- linux.conf.au 2004 The Australian Linux Technical Conference http://lca2004.linux.org.au/ 12-17 January 2004, Adelaide, South Australia Are you a computer angel? http://www.computerangels.org.au/ From harrymc@decisions-and-designs.com.au Sun Aug 3 14:09:56 2003 From: harrymc@decisions-and-designs.com.au (Harry McNally) Date: Sun, 3 Aug 2003 22:09:56 +0800 Subject: [Opendispense] Large FPGAs In-Reply-To: <20030803122051.GH496873@morwong.ucc.gu.uwa.edu.au> References: <20030802153712.1a8da04f.harrymc@ucc.gu.uwa.edu.au> <20030803092945.GC104140@morwong.ucc.gu.uwa.edu.au> <20030803122051.GH496873@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030803220956.4a59c8d4.harrymc@decisions-and-designs.com.au> On Sun, 3 Aug 2003 20:20:51 +0800 Nick Bannon wrote: > On Sun, Aug 03, 2003 at 05:29:46PM +0800, Adrian Chadd wrote: > > On Sat, Aug 02, 2003, Harry McNally wrote: > > > After the discussion about comms alternatives, I'd like to find out > [...] > > How big an FPGA can you mount? > > > > Say, an XCV1000E or two? > > Those are the ones: Xilinx Virtex XCV1000E FG860, 8C ; > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=4663&item=2545447811 > > Monumental overkill for our application, of course, Not so :) Given the clock speed of our HC11 I have been thinking of some cunning plans. I spoke to Nick about the idea of also coding a serial port in the FPGA because the HC11 serial is being used. With a device of this size we can design a DMA scheme that cycle steals access to the static RAM on the daughter board and just advises the micro when a SLIP packet has arrived and the buffer address of the packet. This means a buffer allocator needs to feed the SLIP state machine a stream of buffers so why not include a buffer allocator state machine in the FPGA as well? I think it would be possible. If we want to have some secure comms to the accounting system we could build a hardware encryption engine too to avoid loading the HC11. There are all sorts of opportunities with a large FPGA limited by skill and imagination mainly :-) > but it goes to show > that it can sometimes be affordable to get our hands on FPGAs with a > million gates as opposed to 128... Of course, I have nil experience > with working with any device of that type. Well, me too, but the concept is the same FLW :) The difficulty is where high speed circuits have timing contraints that depend on layout. We don't need to run fast, we just need room for logic so I think we could stumble on a solution. I need to look at the free version of the MAXplus tools from Altera to see if it supports these devices. I'd like to use tools that are free so other can play without needing the $$$ toolset. comes back .. ok I've just looked at the MAXplus 10.2 Baseline I have on a PC here and it doesn't look like it is supported in this version. It's been a while since I updated so there may be a more recent version with support. What are MUGWA using for development? Are there GPL tools for these sorts of densities? Harry -- linux.conf.au 2004 The Australian Linux Technical Conference http://lca2004.linux.org.au/ 12-17 January 2004, Adelaide, South Australia Are you a computer angel? http://www.computerangels.org.au/ From harrymc@ucc.gu.uwa.edu.au Sun Aug 3 14:23:26 2003 From: harrymc@ucc.gu.uwa.edu.au (Harry McNally) Date: Sun, 3 Aug 2003 22:23:26 +0800 Subject: [Opendispense] Large FPGAs In-Reply-To: <20030803220956.4a59c8d4.harrymc@decisions-and-designs.com.au> References: <20030802153712.1a8da04f.harrymc@ucc.gu.uwa.edu.au> <20030803092945.GC104140@morwong.ucc.gu.uwa.edu.au> <20030803122051.GH496873@morwong.ucc.gu.uwa.edu.au> <20030803220956.4a59c8d4.harrymc@decisions-and-designs.com.au> Message-ID: <20030803222326.0cd3b4c5.harrymc@ucc.gu.uwa.edu.au> On Sun, 3 Aug 2003 22:09:56 +0800 Harry McNally wrote: Oops. Sorry about the double posts. Thanks Nick for white listing my DnD address. I read that advice too late and resent my message :) From harrymc@ucc.gu.uwa.edu.au Sun Aug 3 14:32:51 2003 From: harrymc@ucc.gu.uwa.edu.au (Harry McNally) Date: Sun, 3 Aug 2003 22:32:51 +0800 Subject: [Opendispense] Latest additions In-Reply-To: <20030803111443.GB12993@ucc.gu.uwa.edu.au> References: <20030802141938.GA10131@ucc.gu.uwa.edu.au> <20030803185933.66707186.harrymc@ucc.gu.uwa.edu.au> <20030803111443.GB12993@ucc.gu.uwa.edu.au> Message-ID: <20030803223251.545d8ad6.harrymc@ucc.gu.uwa.edu.au> On Sun, 3 Aug 2003 19:14:43 +0800 dagobah@ucc.gu.uwa.edu.au (Bernard Blackham) wrote: > > What I can't work out (yet) is that there is another circuit that > > uses an optoisolator (U24). This _appears_ to sense when the motor > > voltage droops by extinguishing the opto led and allowing > > PE1 (pin 18) to rise high. > > From what I make of it, I was under the impression it extinguishes the > LED when the motor voltage gets too high (above 25.4ish volts) I was thinking this way but I thought the only way that could happen is if there is a back EMF when the drivers turn off but it occured to me just now that it _may_ indicate that the motor 24V regulator has fried (Q1) and the motors are being fed 24VUN(regulated). We should measure the nominal 24VUN voltage to see if that is >25.4 volts. > > So if you find anything sensing those two pins, it may be related > > to motor overcurrent sensing. I am just puzzled why there are two > > circuits sensing motor state in different ways. > > There's also another circuit attached to PE3 which puts the pin high if > the 24VUN (unregulated?) drops below 20ish volts. Still tracking down > where they're used. I think I'm currently on a roll with the coin mech :) I think this may sense that mains power has been lost. The switch mode regulator that provides 5 volts will hold up for a while as the 24VUN collapses so the micro may have time to finish any nonvolatile RAM writes and maintain system sanity for when power returns. I was chatting to Nick about using that for our own system preservation on power fail. cu Harry -- linux.conf.au 2004 The Australian Linux Technical Conference http://lca2004.linux.org.au/ 12-17 January 2004, Adelaide, South Australia Are you a computer angel? http://www.computerangels.org.au/ From dagobah@ucc.gu.uwa.edu.au Sun Aug 3 16:11:47 2003 From: dagobah@ucc.gu.uwa.edu.au (Bernard Blackham) Date: Mon, 4 Aug 2003 00:11:47 +0800 Subject: [Opendispense] large numbers on a hc11 Message-ID: <20030803161147.GH12993@ucc.gu.uwa.edu.au> Greetings, So I was just about to send the following question, and as I laid out the numbers, the answer jumped out at me. But I thought some people might be interested so here it is anyway :) --- Just uncovered in the disassembly what I want to claim is a division function for large numbers (>65535). What I can't for the life of me figure out is how large numbers are represented internally. It seems to use a mantissa, but to some mysterious base. Here are some numbers and their expected meanings: 0x2710 paired with 0 (0x00) to make 10,000 <- 0x2710 = 10000 0x86a0 paired with 1 (0x01) to make 100,000 0x4240 paired with 15 (0x0f) to make 1,000,000 0x9680 paired with 152 (0x98) to make 10,000,000 Can anybody see a relationship that will get c from a & b? --- Well the answer is to put b with a, then unhex it. eg, 0x86a0 and 0x01 become 0x0186a0 which is 100000, and so on. Hopefully our compiler will do something smart like this for us too :) Progress =) Bernard. From dagobah@ucc.gu.uwa.edu.au Sun Aug 3 17:05:10 2003 From: dagobah@ucc.gu.uwa.edu.au (Bernard Blackham) Date: Mon, 4 Aug 2003 01:05:10 +0800 Subject: [Opendispense] Latest additions In-Reply-To: <20030803223251.545d8ad6.harrymc@ucc.gu.uwa.edu.au> References: <20030802141938.GA10131@ucc.gu.uwa.edu.au> <20030803185933.66707186.harrymc@ucc.gu.uwa.edu.au> <20030803111443.GB12993@ucc.gu.uwa.edu.au> <20030803223251.545d8ad6.harrymc@ucc.gu.uwa.edu.au> Message-ID: <20030803170510.GI12993@ucc.gu.uwa.edu.au> On Sun, Aug 03, 2003 at 10:32:51PM +0800, Harry McNally wrote: > > There's also another circuit attached to PE3 which puts the pin high if > > the 24VUN (unregulated?) drops below 20ish volts. Still tracking down > > where they're used. I think I'm currently on a roll with the coin mech :) > > I think this may sense that mains power has been lost. The switch > mode regulator that provides 5 volts will hold up for a while as the > 24VUN collapses so the micro may have time to finish any nonvolatile > RAM writes and maintain system sanity for when power returns. I > was chatting to Nick about using that for our own system preservation > on power fail. The only reference I can find to the PE3 pin with this circuitry on it is in the following snippet of assembly in the main loop, which it seems holds the reset line of the changer high until 24V power is restored. Perhaps it's a power-saving technique? Or stops the changer from dropping out coins just because the powers flaky? (the corresponding lines are active low). Or I could just be way off track altogether :) Baffled and sleepy but making more progress. Bernard. From harrymc@ucc.gu.uwa.edu.au Mon Aug 4 02:28:11 2003 From: harrymc@ucc.gu.uwa.edu.au (Harry McNally) Date: Mon, 4 Aug 2003 10:28:11 +0800 Subject: [Opendispense] Latest additions In-Reply-To: <20030803170510.GI12993@ucc.gu.uwa.edu.au> References: <20030802141938.GA10131@ucc.gu.uwa.edu.au> <20030803185933.66707186.harrymc@ucc.gu.uwa.edu.au> <20030803111443.GB12993@ucc.gu.uwa.edu.au> <20030803223251.545d8ad6.harrymc@ucc.gu.uwa.edu.au> <20030803170510.GI12993@ucc.gu.uwa.edu.au> Message-ID: <20030804102811.5db80796.harrymc@ucc.gu.uwa.edu.au> On Mon, 4 Aug 2003 01:05:10 +0800 dagobah@ucc.gu.uwa.edu.au (Bernard Blackham) wrote: > On Sun, Aug 03, 2003 at 10:32:51PM +0800, Harry McNally wrote: > > > There's also another circuit attached to PE3 which puts the pin high if > > > the 24VUN (unregulated?) drops below 20ish volts. Still tracking down > > > where they're used. I think I'm currently on a roll with the coin mech :) > > > > I think this may sense that mains power has been lost. The switch > > mode regulator that provides 5 volts will hold up for a while as the > > 24VUN collapses so the micro may have time to finish any nonvolatile > > RAM writes and maintain system sanity for when power returns. I > > was chatting to Nick about using that for our own system preservation > > on power fail. > > The only reference I can find to the PE3 pin with this circuitry on it > is in the following snippet of assembly in the main loop, which it seems > holds the reset line of the changer high until 24V power is restored. > > Perhaps it's a power-saving technique? Or stops the changer from > dropping out coins just because the powers flaky? I'd say the latter Bernard. If we have/can get the datasheet for the coin mech it may specify holding off operation below a certain supply voltage. I'm surprised that is the only reference. The Dallas battery backed RAM will cease responding to control signals when Vcc drops below say 4.5 volts (or so) but I would have thought some protection would be needed from partial updates of the sales and price data in the RAM. There you go. Harry -- linux.conf.au 2004 The Australian Linux Technical Conference http://lca2004.linux.org.au/ 12-17 January 2004, Adelaide, South Australia Are you a computer angel? http://www.computerangels.org.au/ From bernard@blackham.com.au Tue Aug 5 15:27:47 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Tue, 5 Aug 2003 23:27:47 +0800 Subject: [Opendispense] beginnings of code Message-ID: <20030805152747.GA31999@amidala> I think I've gone a little insane pulling apart HC11 assembly so I decided to start pulling some C code together. From what can be ascertained from the disassembly, we can drive the display, chime, motors and keypad (though the motors & chime could do with some more exploration). What's really left to figure is the coin mech, but I've had enough of the disassembly for now. The coin mech is not a "Changer", nor is it a "Dumb Mech" (as per the options in the manual or on the vending machine). The manual only ever refers to it as a "European Dumb Coin Mechanism" and it is infact enabled by selecting "Link Master", and hence the code I was previously looking at was useless to us. Strangely enough, it also claims that this is incompatible with the other credit items (eg bill acceptors, card readers), but I want to say this is partially a software limitation. Though what does seem interesting is the fact that it seems the serial line appears to be in some ways, like a bus (certain parts of the SCI interrupt code only respond to certain bit patterns in the first byte of a packet) - and with the spare connector hanging out of the coin mechanism, it's one potential way to get real-world interfacing going without hacking the main board. The alternative, is the Bill Acceptor connector P4 - curious why we needed one, I unplugged P4 today and the machine ran perfectly fine without it. So we could possibly hook something up to that. Meanwhile, if anybody wants to checkout cvs directory ROM2 and comment on the little C code that's gone in so far, please do :) Furthermore, if anybody could shed some light on how this is going to link to a 32KB ROM image with code, data, interrupt vectors et al in the right place, I'd be even more thrilled =) Regards, Bernard. -- Bernard Blackham bernard at blackham dot com dot au From bernard@blackham.com.au Tue Aug 5 15:33:43 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Tue, 5 Aug 2003 23:33:43 +0800 Subject: [Opendispense] beginnings of code In-Reply-To: <20030805152747.GA31999@amidala> References: <20030805152747.GA31999@amidala> Message-ID: <20030805153343.GA32164@amidala> On Tue, Aug 05, 2003 at 11:27:47PM +0800, Bernard Blackham wrote: > Furthermore, if anybody could shed some light on how this is going > to link to a 32KB ROM image with code, data, interrupt vectors et al > in the right place, I'd be even more thrilled =) To answer my own question, see /usr/share/doc/gcc-m68hc1x/example.tar.gz They make it look trivial :) For the morning. Sleep. Bernard. -- Bernard Blackham bernard at blackham dot com dot au From bernard@blackham.com.au Wed Aug 6 15:36:03 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Wed, 6 Aug 2003 23:36:03 +0800 Subject: [Opendispense] UI design Message-ID: <20030806153603.GA3991@amidala> Greetings, Here's a brain dump of my plans for the UI. Please rip it to pieces. :) Main menu: - Coins inserted: - Take a selection number & act like a normal vending machine. Drinks may be dispensed for $1. The door may not be dispensed, no matter how much is put in :) - 5-digit UID entered: - Say "Welcome . Enter PIN." Verify PIN number. - If money is dropped in, display the value and wait for either: 0 to be pressed - credit the account. RESET or the coin return lever - refund the money. - If a selection is entered, dispense it. A selection can be: * row/column of vending machine item * special numbers denoting door, drinks, or money (withdrawl) - Door opened: - Read in a selection number, a price and/or a count for setting the levels of stock in the database. And return to the main menu after any of these operations (so people with have to authenticate several times to do multiple transactions) - bad thing? Can anybody pick any holes in this interface, or anything else they'd like to see in it? The machine will need to talk to the server (mermaid) for the following reasons: - authenticate a user (send username/pin, receive ACK/NACK). - obtain price of a slot (send slot number, receive price). - send a dispense request (send slot number/cash amount, receive ACK/No Money/Not authorised). - receive a dispense request (receive a slot number/cash amount to drop out, send back amount of cash actually dropped out (in case of no cash)) - entering stock counts/prices from the vending machine panel to update the database within the server - notification of motors failing or some other hardware fault So a server side program will be required to chat with dispense itself, and authenticate/validate all requests that happen. It is then the server's responsibility to send the command to the appropriate device (vending machine, coke machine, door). Taking this approach does leave a fair bit of spare RAM on the board, and I'll understand if people call it the wimpy way out to do most things server-side :) Regards, Bernard. -- Bernard Blackham bernard at blackham dot com dot au From nick@ucc.gu.uwa.edu.au Thu Aug 7 13:22:47 2003 From: nick@ucc.gu.uwa.edu.au (Nick Bannon) Date: Thu, 7 Aug 2003 21:22:47 +0800 Subject: [Opendispense] UI design In-Reply-To: <20030806153603.GA3991@amidala> References: <20030806153603.GA3991@amidala> Message-ID: <20030807132247.GC496873@morwong.ucc.gu.uwa.edu.au> On Wed, Aug 06, 2003 at 11:36:03PM +0800, Bernard Blackham wrote: > Greetings, > > Here's a brain dump of my plans for the UI. Please rip it to pieces. :) Well, there is a risk that we're UI overloading the poor little keypad and display... I wonder about a flexible keyboard, or capacitive sensors behind the glass, or... Still, in the meantime what we've got is what we've got. ::-) > Main menu: > - Coins inserted: > - Take a selection number & act like a normal vending machine. > Drinks may be dispensed for $1. Some drinks can be more, but I guess this price can be fetched like any other (and rounded up to the nearest 5 cents). Unused selection prefixes include 00, 22, 55, 88, 99. 00 sounds good for drinks - 000, 001, 002, 003, 004, 005 and the quad slot 006. 007 as a synonym for the quad slot (coke!) sounds good. (There's some potential inconsistency here. You could number the slots 1-7 which would make 007 come naturally and leave 000 free. The coke brain firmware, and dispense, calls them 0-6. The sticker inside the drink machine calls them 7-1. (ie 1 is the quad slot) Hmmm. ) > The door may not be dispensed, no matter how much is put in :) > > - 5-digit UID entered: > - Say "Welcome . Enter PIN." > Verify PIN number. Perhaps that needn't be necessary for adding money to an account. [...] > - If a selection is entered, dispense it. A selection can be: > * row/column of vending machine item > * special numbers denoting door, drinks, or money (withdrawl) We may not want to allow withdrawls, this should perhaps be a deprecated, manual action by a cashbox keyholder in all cases. We have given people credit on occasion that we'd prefer the didn't withdraw in cash and there is of course the chance someone could find a bug or vulnerability and fill up their account. Still, it's a reasonable request for people to make... [...] > And return to the main menu after any of these operations (so people > with have to authenticate several times to do multiple > transactions) - bad thing? [...] "Press 1 to follow-on . . . "? The rest of the interface should have a (longer) timeout, too, of course. I think a flowchart for documentation and a foolproof, bug-free, state machine is called for. Naturally, you shouldn't listen to anyone (e.g. me ::-) ) who seems to want to make it _more_ complex. Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal From bernard@blackham.com.au Thu Aug 7 15:11:17 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Thu, 7 Aug 2003 23:11:17 +0800 Subject: [Opendispense] UI design In-Reply-To: <20030807132247.GC496873@morwong.ucc.gu.uwa.edu.au> References: <20030806153603.GA3991@amidala> <20030807132247.GC496873@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030807151117.GA16112@amidala> On Thu, Aug 07, 2003 at 09:22:47PM +0800, Nick Bannon wrote: > > Here's a brain dump of my plans for the UI. Please rip it to pieces. :) > > Well, there is a risk that we're UI overloading the poor little keypad > and display... I wonder about a flexible keyboard, or capacitive > sensors behind the glass, or... Still, in the meantime what we've got > is what we've got. ::-) Not overloading. Consider it maximising its utility :) > Unused selection prefixes include 00, 22, 55, 88, 99. 00 > sounds good for drinks - 000, 001, 002, 003, 004, 005 and the quad slot > 006. 007 as a synonym for the quad slot (coke!) sounds good. All of row 5 is available. The original ROM has what seems like a "is valid slot" function which returns invalid slots numbers. And given there's only 40 dispensable items in the vending machine and it supports at most 80, it still does leave a large selection of double digit items. > (There's some potential inconsistency here. You could number the slots > 1-7 which would make 007 come naturally and leave 000 free. The coke > brain firmware, and dispense, calls them 0-6. The sticker inside the > drink machine calls them 7-1. (ie 1 is the quad slot) Hmmm. ) I was thinking of assigning them 50 - 56. But always changable. > > - 5-digit UID entered: > > - Say "Welcome . Enter PIN." > > Verify PIN number. > > Perhaps that needn't be necessary for adding money to an account. Complicates the UI, but feasible. :) > We may not want to allow withdrawls, this should perhaps be a > deprecated, manual action by a cashbox keyholder in all cases. We have > given people credit on occasion that we'd prefer the didn't withdraw in > cash and there is of course the chance someone could find a bug or > vulnerability and fill up their account. Hmmmm, if we limit withdrawls to $1 a time, and at most $3 a day (or something) I think it's convenience would outweight the security issues. > [...] > > And return to the main menu after any of these operations (so people > > with have to authenticate several times to do multiple > > transactions) - bad thing? > [...] > > "Press 1 to follow-on . . . "? I plan to make it so that pressing Reset twice, no matter where you are in the menu, will log you out - I think people will catch on. In addition to having a 20s timeout. > I think a flowchart for documentation and a foolproof, bug-free, state > machine is called for. Naturally, you shouldn't listen to anyone (e.g. > me ::-) ) who seems to want to make it _more_ complex. Well if it does what people would intuitively expect it to do then complex shouldn't be a problem. What I am rethinking though, is taking wimpier ways out - to allow the interface to be as flexible as possible, make the vending machine as dumb as possible (just a display, keypad, set of motors and coin mech), and have the interface driven from mermaid. Hence keypresses would travel to mermaid and display updates back to the machine. It might seem a little laggy even over a 9600bps link, but this way we only need to flash the ROM as few times as possible. Though I know Harry probably won't like this suggestion :) Bernard. -- Bernard Blackham bernard at blackham dot com dot au From matt@ucc.asn.au Thu Aug 7 15:29:10 2003 From: matt@ucc.asn.au (Matt Johnston) Date: Thu, 7 Aug 2003 23:29:10 +0800 Subject: [Opendispense] UI design In-Reply-To: <20030807151117.GA16112@amidala> References: <20030806153603.GA3991@amidala> <20030807132247.GC496873@morwong.ucc.gu.uwa.edu.au> <20030807151117.GA16112@amidala> Message-ID: <20030807152910.GA504353@morwong.ucc.gu.uwa.edu.au> In general, the plan sounds good, as Nick says, a flowchart is good. Perhaps also on the front of the snack machine when it's done? (or at least parts of it) A few comments. On Thu, Aug 07, 2003 at 11:11:17PM +0800, Bernard Blackham wrote: > On Thu, Aug 07, 2003 at 09:22:47PM +0800, Nick Bannon wrote: > > > Here's a brain dump of my plans for the UI. Please rip it to pieces. :) > Hmmmm, if we limit withdrawls to $1 a time, and at most $3 a day (or > something) I think it's convenience would outweight the security > issues. It it's limited and we keep track if there's abuse, then it should be OK. We should also be wary of accepting too much deposited money, as that could be abused likewise. > I plan to make it so that pressing Reset twice, no matter where you > are in the menu, will log you out - I think people will catch on. In > addition to having a 20s timeout. Sensible. > What I am rethinking though, is taking wimpier ways out - to allow > the interface to be as flexible as possible, make the vending > machine as dumb as possible (just a display, keypad, set of motors > and coin mech), and have the interface driven from mermaid. Hence > keypresses would travel to mermaid and display updates back to the > machine. It might seem a little laggy even over a 9600bps link, but > this way we only need to flash the ROM as few times as possible. This is a good idea. If it's difficult to change/improve stuff, things will be left brokenish. Of course there is then scope for breaking stuff on mermaid, but at least that is easier to fix. Also swapping ROMs about lots isn't really the best for the board I would assume. Matt From harrymc@ucc.gu.uwa.edu.au Thu Aug 7 15:39:05 2003 From: harrymc@ucc.gu.uwa.edu.au (Harry McNally) Date: Thu, 7 Aug 2003 23:39:05 +0800 Subject: [Opendispense] UI design In-Reply-To: <20030807151117.GA16112@amidala> References: <20030806153603.GA3991@amidala> <20030807132247.GC496873@morwong.ucc.gu.uwa.edu.au> <20030807151117.GA16112@amidala> Message-ID: <20030807233905.7b636327.harrymc@ucc.gu.uwa.edu.au> On Thu, 7 Aug 2003 23:11:17 +0800 Bernard Blackham wrote: > Though I know Harry probably won't like this suggestion :) Hell no :) Why make something simple when you can feature bloat ? Thanks for your ideas about how to interact with openvend; wherever the intelligent clock cycles occur ;) I was going to explain the concept I've seen used in UI amd MMI design called 'storyboarding' (like in films etc) but I'm too tired to keep typing. I'll explain tomorrow night how I'd like to interact with the interface by writing a storyboard for your comments. It is similar to your approach .. with some differences. I could storyboard in person since UCC is tomorrow. Jacqueline explained she can always spot me on UCC cam. I'm the one waving my arms about. More of that tomorrow then ! :-D cu Harry -- linux.conf.au 2004 The Australian Linux Technical Conference http://lca2004.linux.org.au/ 12-17 January 2004, Adelaide, South Australia Are you a computer angel? http://www.computerangels.org.au/ From nick@ucc.gu.uwa.edu.au Thu Aug 7 16:41:15 2003 From: nick@ucc.gu.uwa.edu.au (Nick Bannon) Date: Fri, 8 Aug 2003 00:41:15 +0800 Subject: [Opendispense] UI design In-Reply-To: <20030807151117.GA16112@amidala> References: <20030806153603.GA3991@amidala> <20030807132247.GC496873@morwong.ucc.gu.uwa.edu.au> <20030807151117.GA16112@amidala> Message-ID: <20030807164115.GD496873@morwong.ucc.gu.uwa.edu.au> On Thu, Aug 07, 2003 at 11:11:17PM +0800, Bernard Blackham wrote: [...] > I was thinking of assigning them 50 - 56. But always changable. Ah, but the columns are labelled first, so 5x codes are in use (but not x5). [...] > Hmmmm, if we limit withdrawls to $1 a time, and at most $3 a day (or > something) I think it's convenience would outweight the security > issues. True. It'd be nice to have a bus ticket's worth of change to hand. We'd have to refill the change often, or it'll spent its time showing "EXACT CHANGE ONLY (OR COKECREDIT)" . ::-) [...] > What I am rethinking though, is taking wimpier ways out - to allow > the interface to be as flexible as possible, make the vending > machine as dumb as possible (just a display, keypad, set of motors > and coin mech), and have the interface driven from mermaid. Hence > keypresses would travel to mermaid and display updates back to the > machine. Good idea. That's definitely a good milestone if nothing else - that functionality is necessary and sufficient, if not exhaustive. > It might seem a little laggy even over a 9600bps link, but > this way we only need to flash the ROM as few times as possible. 9600bps is ten times what we'd need - if it's laggy, we're doing it wrong. "Wrong" includes, for example, using SOAP to interface with the thing. ::-) Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal From bernard@blackham.com.au Thu Aug 7 16:46:59 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Fri, 8 Aug 2003 00:46:59 +0800 Subject: [Opendispense] UI design In-Reply-To: <20030807164115.GD496873@morwong.ucc.gu.uwa.edu.au> References: <20030806153603.GA3991@amidala> <20030807132247.GC496873@morwong.ucc.gu.uwa.edu.au> <20030807151117.GA16112@amidala> <20030807164115.GD496873@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030807164659.GA17233@amidala> On Fri, Aug 08, 2003 at 12:41:15AM +0800, Nick Bannon wrote: > > I was thinking of assigning them 50 - 56. But always changable. > > Ah, but the columns are labelled first, so 5x codes are in use (but > not x5). Hmmm, true. Maybe 3 digit entries might be a good idea? I'll get the hardware code written first, then worry about the UI :) > It'd be nice to have a bus ticket's worth of change to hand. > We'd have to refill the change often, or it'll spent its time showing > "EXACT CHANGE ONLY (OR COKECREDIT)" . ::-) Probably no more often than is currently being done. If people use the machine to credit their coke accounts then it should be self-refilling. Counted two bags today with about $5.00 of 10c and 5c pieces... > > It might seem a little laggy even over a 9600bps link, but > > this way we only need to flash the ROM as few times as possible. > > 9600bps is ten times what we'd need - if it's laggy, we're doing it > wrong. "Wrong" includes, for example, using SOAP to interface with the > thing. ::-) So we're not letting Adrian near it? (he's started using soap i hear :) Bernard, currently reading/writing motor code. Display & keypad & chime code is written, not closely checked though. And someday I'll figure out the coin mech. -- Bernard Blackham bernard at blackham dot com dot au From bernard@blackham.com.au Thu Aug 7 17:53:02 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Fri, 8 Aug 2003 01:53:02 +0800 Subject: [Opendispense] Coinage progress Message-ID: <20030807175302.GA17693@amidala> It's 2am, but I'm finally getting to grips with the SCI Interrupt handler and the coin mechanism. It appears that the coin mech speaks on a serial bus, where the first 3 MSBs are an identifier - the coin mech uses 001. The next bit denotes something I haven't figured out yet. And then the last 4 bits contain data. So data is actually transferred in nibbles. And I believe that the data is the value of money currently in the coin mech in cents (to be confirmed), and not individual counts of coins inserted. Which means... we teach our server program on mermaid to speak the same protocol using a different ID and we can differentiate between them. It'd either require a tiny box to breakout the serial lines to mermaid, or alternately, there might be something already like that on that unconnected cable coming out of the coin mech. I'm just hoping this still makes sense when I wake up in the morning. =) Nite. Bernard. -- Bernard Blackham bernard at blackham dot com dot au From bernard@blackham.com.au Sat Aug 9 09:53:35 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Sat, 9 Aug 2003 17:53:35 +0800 Subject: [Opendispense] Coinage progress In-Reply-To: <20030807175302.GA17693@amidala> References: <20030807175302.GA17693@amidala> Message-ID: <20030809095334.GA9139@amidala> More braindumps. Spent most of Friday on the vending machine. Pulled together a little circuit with a pair of optoisolators and a MAX232 to connect/sniff the lines between the coin mech and the controller board. I can read the packets going to/from the coin mech and I can even make sense of them. But I can't yet talk to the coin mech directly with my laptop. After much head-bashing between me, Harry and a few others, we decided that the circuit wasn't providing enough drive current for the opto-isolator on the TX side. So next opportunity I get (Monday) I'll stick a buffer in there as a current sink. Otherwise, I'm pretty sure I know how the coin mech speaks, and it'll exclude some options. When the coinmech is idle, it sends 0x31 which is ack'd by replying to it with 0x00. Without this, the coin mech will not accept coins (and they fall through to the return slot). Every time the balance changes (or maybe when an 0xff is sent to the mech), the coin mech sends a packet: (columns are byte number, date, hex, ascii, binary) 004a [Fri Aug 8 18:37:19 2003] | 38 8 00111000 004b [Fri Aug 8 18:37:19 2003] | 24 $ 00100100 004c [Fri Aug 8 18:37:19 2003] | 20 . 00100000 004d [Fri Aug 8 18:37:19 2003] | 20 . 00100000 004e [Fri Aug 8 18:37:19 2003] | 20 . 00100000 004f [Fri Aug 8 18:37:19 2003] | 25 % 00100101 0050 [Fri Aug 8 18:37:19 2003] | 20 . 00100000 0051 [Fri Aug 8 18:37:19 2003] | 24 $ 00100100 0052 [Fri Aug 8 18:37:19 2003] | 20 . 00100000 0053 [Fri Aug 8 18:37:19 2003] | 39 9 00111001 The first 3 bits are always 001, saying this comes from the coin mech. The 4th bit is 1 for a control byte, and 0 for a data byte. Hence the first 0x38, is a "start of packet" byte. The next 8 bytes are data bytes, so you only look at the lower nibble for data. The next four bytes, and the following two after that denote two numbers which you multiply together to get the value in the mechanism. The second is an 8-bit number which I assume is the smallest possible denomination (in all cases we have, 5c). The first number is a 16-bit number which is the number of the above denominations. eg, above we have (reading most-significant-nibbles last), 0000000000000100 = 4. and 00000101 = 5. 4*5 = 20 - so there was 20c in the mech (a 20c coin namely, but the logic doesn't know that). The next byte (0x24 here) seems to be the mantissa of the number to convert to dollars. The firmware uses it to decide where to stick a decimal point on the display. So here 0100 (read in binary) means the decimal point is two places in. The last data byte (0x20 here) is for whether there are coins in the machine. Firmware only looks at the last bit - if it is set, it displays "EXACT COINS ONLY". Finally there's the "end of packet" byte, 0x39. A packet is sent every time the balance of the machine changes, (and possibly when an 0xff is sent - need to test this). When change is given, what occurs is the controller board sends to the machine a byte which is the number of "smallest denominations" that the item cost. Eg, a $1.10 packet of chips is 22x5c. So the logic board sends decimal 22 to the coin mech, and out pops 90c change. Which means unless there's more to the protocol which doesn't occur in normal conversations, there's no real way we can just "drop out change". Even if we hook into the buttons on the side of the coin mech that dispense money, we don't really have any reliable way to know if there really is money in there or not to drop out. The other problem noticed, is that the coin mechanism will respond to any character written on the serial line, so the idea of using the serial bus is somewhat defeated. (The manual says that using a coin mechanism excludes other devices such as a bill changer or card reader, and I presume this might be why). Which means we may resort to putting a UART on a daughterboard after all. Thanks for listening :) Bernard. PS, will commit notes to CVS when mussel comes back (down for machine room shuffling). -- Bernard Blackham bernard at blackham dot com dot au From bernard@blackham.com.au Mon Aug 11 04:50:14 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Mon, 11 Aug 2003 12:50:14 +0800 Subject: [Opendispense] Questions - new memory map Message-ID: <20030811045013.GA31794@amidala> Greetings, Just some questions & notes I'd like to get answered... To get an extra UART onto the board, the ideas are to put a riser board from the EPROM socket. The socket only has A14-A0, and is enabled when A15 is high (ie, $8000-$FFFF). So as I see it, to put anything else along-side this EPROM would either involve: - dividing the usable EPROM in half, assigning $C000-$FFFF for the EPROM and addresses between $8000-$BFFF for our extras (the UART). This gives us 16k of usable EPROM (still heaps), but limits our options for putting in extra RAM and such. Though if we're acting as merely an interface (which I hope this first try is) this is not a problem. - or, a bit of logic to map certain addresses out of EPROM space, so we lose a smaller power of 2 of the EPROM, and extra memory that may be installed in the future. :) We also have the problem of the RW' line requiring to be low (R) to access the EPROM and hence riser board. We'd need to hack the board and cut some tracks to get around this, which wouldn't be so nice. I'd be happy for somebody more versed in computer architecture to point out some other ways :) As to which UART to choose, are there any pros/cons between them? If I start writing some code to chat with a 16550A UART, will it be overkill? Regards, Bernard. -- Bernard Blackham bernard at blackham dot com dot au From adrian@ucc.gu.uwa.edu.au Mon Aug 11 04:53:23 2003 From: adrian@ucc.gu.uwa.edu.au (Adrian Chadd) Date: Mon, 11 Aug 2003 12:53:23 +0800 Subject: [Opendispense] Questions - new memory map In-Reply-To: <20030811045013.GA31794@amidala> References: <20030811045013.GA31794@amidala> Message-ID: <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> On Mon, Aug 11, 2003, Bernard Blackham wrote: > We also have the problem of the RW' line requiring to be low (R) to > access the EPROM and hence riser board. We'd need to hack the board > and cut some tracks to get around this, which wouldn't be so nice. > > I'd be happy for somebody more versed in computer architecture to > point out some other ways :) > > As to which UART to choose, are there any pros/cons between them? If > I start writing some code to chat with a 16550A UART, will it be > overkill? If you can make it small enough, no. Is the CPU socketed? How is it mounted on the board? You do realise there's nothing _really_ wrong with soldering a bunch of little wires to make up the rest of the riser board interface.. (ie R/W, A15, etc.) I don't see why you need to cut tracks. Adrian From harrymc@decisions-and-designs.com.au Mon Aug 11 07:04:35 2003 From: harrymc@decisions-and-designs.com.au (Harry McNally) Date: Mon, 11 Aug 2003 15:04:35 +0800 Subject: [Opendispense] Questions - new memory map In-Reply-To: <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> References: <20030811045013.GA31794@amidala> <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030811150435.291a4b57.harrymc@decisions-and-designs.com.au> On Mon, 11 Aug 2003 12:53:23 +0800 Adrian Chadd wrote: > On Mon, Aug 11, 2003, Bernard Blackham wrote: > > > We also have the problem of the RW' line requiring to be low (R) to > > access the EPROM and hence riser board. We'd need to hack the board > > and cut some tracks to get around this, which wouldn't be so nice. > > > > I'd be happy for somebody more versed in computer architecture to > > point out some other ways :) > > > > As to which UART to choose, are there any pros/cons between them? If > > I start writing some code to chat with a 16550A UART, will it be > > overkill? > > If you can make it small enough, no. > > Is the CPU socketed? How is it mounted on the board? > You do realise there's nothing _really_ wrong with soldering a bunch > of little wires to make up the rest of the riser board interface.. > (ie R/W, A15, etc.) I don't see why you need to cut tracks. Hi Bernard and Adrian I had a cunning plan to install a 32 pin machine pin socket to replace the 28 pin EPROM socket. We could then run four more signals up on to the mezzanine board through the extra pins but the mezzanine can still be removed and replaced easily (even restore the original EPROM if necessary). If you look at the scan of the top of the board (top.PDF or top.JPG) which I think is on CVS there, the following mods were what I had in mind: - Remove the EPROM and socket. - Remove C29 and R81. Wick out the holes and reinstall these parts on the other side of the board. Trim back excess lead so it is flush with the top copper prior to resoldering. - Trim the legs on pins 15, 16, 17, and 18 on a 32 pin machine pin socket. - Solder wire wrap pigtails on the legless socket buckets. - Insert a cut down 40 pin WrapID (tm) wire wrap marker on the machine pin socket as an insulating spacer. - Install the socket as normal on the remaining 28 pins. - Terminate the four wire wrap pitails on signals needed for read and write and full addressing (A15) onto the PCB. - For now, reinstall EPROM. If you look at 1 o'clock to the EPROM there is an unused mounting hole. We can use this to support the mezzinine board with a threaded nylon standoff and nylon screws. I've used this trick before and it was a tidy solution. It almost looked like a bought one :) If you like, we could do a rework session and snap a few images of the steps for the web records. cu Harry -- linux.conf.au 2004 The Australian Linux Technical Conference http://lca2004.linux.org.au/ 12-17 January 2004, Adelaide, South Australia Are you a computer angel? http://www.computerangels.org.au/ From harrymc@ucc.gu.uwa.edu.au Mon Aug 11 07:10:50 2003 From: harrymc@ucc.gu.uwa.edu.au (Harry McNally) Date: Mon, 11 Aug 2003 15:10:50 +0800 Subject: [Opendispense] Questions - new memory map In-Reply-To: <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> References: <20030811045013.GA31794@amidala> <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030811151050.5150e717.harrymc@ucc.gu.uwa.edu.au> On Mon, 11 Aug 2003 12:53:23 +0800 Adrian Chadd wrote: > On Mon, Aug 11, 2003, Bernard Blackham wrote: > > > We also have the problem of the RW' line requiring to be low (R) to > > access the EPROM and hence riser board. We'd need to hack the board > > and cut some tracks to get around this, which wouldn't be so nice. > > > > I'd be happy for somebody more versed in computer architecture to > > point out some other ways :) > > > > As to which UART to choose, are there any pros/cons between them? If > > I start writing some code to chat with a 16550A UART, will it be > > overkill? > > If you can make it small enough, no. > > Is the CPU socketed? How is it mounted on the board? > You do realise there's nothing _really_ wrong with soldering a bunch > of little wires to make up the rest of the riser board interface.. > (ie R/W, A15, etc.) I don't see why you need to cut tracks. Hi Bernard and Adrian I had a cunning plan to install a 32 pin machine pin socket to replace the 28 pin EPROM socket. We could then run four more signals up on to the mezzanine board through the extra pins but the mezzanine can still be removed and replaced easily (even restore the original EPROM if necessary). If you look at the scan of the top of the board (top.PDF or top.JPG) which I think is on CVS there, the following mods were what I had in mind: - Remove the EPROM and socket. - Remove C29 and R81. Wick out the holes and reinstall these parts on the other side of the board. Trim back excess lead so it is flush with the top copper prior to resoldering. - Trim the legs on pins 15, 16, 17, and 18 on a 32 pin machine pin socket. - Solder wire wrap pigtails on the legless socket buckets. - Insert a cut down 40 pin WrapID (tm) wire wrap marker on the machine pin socket as an insulating spacer. - Install the socket as normal on the remaining 28 pins. - Terminate the four wire wrap pitails on signals needed for read and write and full addressing (A15) onto the PCB. - For now, reinstall EPROM. If you look at 1 o'clock to the EPROM there is an unused mounting hole. We can use this to support the mezzinine board with a threaded nylon standoff and nylon screws. I've used this trick before and it was a tidy solution. It almost looked like a bought one :) If you like, we could do a rework session and snap a few images of the steps for the web records. cu Harry -- linux.conf.au 2004 The Australian Linux Technical Conference http://lca2004.linux.org.au/ 12-17 January 2004, Adelaide, South Australia Are you a computer angel? http://www.computerangels.org.au/ From bernard@blackham.com.au Mon Aug 11 08:47:24 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Mon, 11 Aug 2003 16:47:24 +0800 Subject: [Opendispense] Questions - new memory map In-Reply-To: <20030811151050.5150e717.harrymc@ucc.gu.uwa.edu.au> References: <20030811045013.GA31794@amidala> <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> <20030811151050.5150e717.harrymc@ucc.gu.uwa.edu.au> Message-ID: <20030811084724.GB1733@amidala> On Mon, 11 Aug 2003 12:53:23 +0800 Adrian Chadd wrote: > Is the CPU socketed? How is it mounted on the board? Nope. Soldered straight in. On Mon, Aug 11, 2003 at 03:10:50PM +0800, Harry McNally wrote: > Hi Bernard and Adrian > > I had a cunning plan to install a 32 pin machine pin socket to replace > the 28 pin EPROM socket. We could then run four more signals up on to the > mezzanine board through the extra pins but the mezzanine can still be > removed and replaced easily (even restore the original EPROM if necessary). > > If you look at the scan of the top of the board (top.PDF or top.JPG) which > I think is on CVS there, the following mods were what I had in mind: Sounds very feasible! (and ingenious :) > I've used this trick before and it was a tidy solution. It almost looked > like a bought one :) So does anybody object? :) > If you like, we could do a rework session and snap a few images of the > steps for the web records. Probably not enough time to do it in a night - how are weekends for people? Regards, Bernard. -- Bernard Blackham bernard at blackham dot com dot au From bernard@blackham.com.au Tue Aug 12 08:20:09 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Tue, 12 Aug 2003 16:20:09 +0800 Subject: [Opendispense] UART 16550 code Message-ID: <20030812082009.GA12534@amidala> Hi all, I think I've more or less put in place all the code necessary for talking to the coin mech, the motors, display and keypad. Albeit, all of it is untested, and could do with some thorough checking before we burn it (I will soon). Meanwhile, I've been thinking of how to go about using a 16550 on the board. Before I go out writing the code to drive it, does anybody have experience along these lines? Or any GPL'd code that could be copied across (eg, drivers/char/serial.c from a linux source tree, but much simpler)? >From the looks of it, it wouldn't be too hard to write a driver from scratch, but seems like it'd be reinventing the wheel. Regards, Bernard. -- Bernard Blackham bernard at blackham dot com dot au From nick@ucc.gu.uwa.edu.au Tue Aug 12 08:35:36 2003 From: nick@ucc.gu.uwa.edu.au (Nick Bannon) Date: Tue, 12 Aug 2003 16:35:36 +0800 Subject: [Opendispense] UART 16550 code In-Reply-To: <20030812082009.GA12534@amidala> References: <20030812082009.GA12534@amidala> Message-ID: <20030812083535.GK3981@morwong.ucc.gu.uwa.edu.au> On Tue, Aug 12, 2003 at 04:20:09PM +0800, Bernard Blackham wrote: [...] > Meanwhile, I've been thinking of how to go about using a 16550 on > the board. Before I go out writing the code to drive it, does > anybody have experience along these lines? Or any GPL'd code that > could be copied across (eg, drivers/char/serial.c from a linux > source tree, but much simpler)? [...] There must be a few options... Perhaps looking at the serial driver Linux 2.0.0 or 0.99.3 or something would be simpler. Or perhaps not. Maybe NetBSD? Here's code for a 16550 UART emulator: http://dosemu.sourceforge.net/docs/README-tech/1.1.3.7/x2372.html It makes references to the FOSSIL drivers that DOS BBS'es used to use, if there's a free one of those then that might be a good option. Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal From adrian@ucc.gu.uwa.edu.au Tue Aug 12 09:07:38 2003 From: adrian@ucc.gu.uwa.edu.au (Adrian Chadd) Date: Tue, 12 Aug 2003 17:07:38 +0800 Subject: [Opendispense] UART 16550 code In-Reply-To: <20030812083535.GK3981@morwong.ucc.gu.uwa.edu.au> References: <20030812082009.GA12534@amidala> <20030812083535.GK3981@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030812090738.GD108377@morwong.ucc.gu.uwa.edu.au> On Tue, Aug 12, 2003, Nick Bannon wrote: > On Tue, Aug 12, 2003 at 04:20:09PM +0800, Bernard Blackham wrote: > [...] > > Meanwhile, I've been thinking of how to go about using a 16550 on > > the board. Before I go out writing the code to drive it, does > > anybody have experience along these lines? Or any GPL'd code that > > could be copied across (eg, drivers/char/serial.c from a linux > > source tree, but much simpler)? > [...] > > There must be a few options... Perhaps looking at the serial driver > Linux 2.0.0 or 0.99.3 or something would be simpler. Or perhaps not. > Maybe NetBSD? Its preetty simple, actually. Try the serial code from FreeBSD, but look at the _console_ code right down the bottom. Its damned simple. I used it to write an 8250 driver for a DOS project (the touchscreen stuff) last month. adrian From davidb-7654@rcpt.to Tue Aug 12 10:55:19 2003 From: davidb-7654@rcpt.to (David Basden) Date: Tue, 12 Aug 2003 20:55:19 +1000 Subject: [Opendispense] UART 16550 code In-Reply-To: <20030812082009.GA12534@amidala> References: <20030812082009.GA12534@amidala> Message-ID: <20030812105519.GD18308@misato.xware.cx> I've written code to talk to a 16550 under Linux, which probably isn't the same thing. As for the 16550 itself, it seems pretty easy to drive, or at least firmly annoying. As for simple code, try looking at Minix, which is designed to teach. Once you've done that, write your own because Minix tries to look like UNIX, and therefore all terminal handling is forever fucked in the head. Maybe from some public domain DOS apps? David On Tue, Aug 12, 2003 at 04:20:09PM +0800, Bernard Blackham wrote: > Hi all, > > I think I've more or less put in place all the code necessary for > talking to the coin mech, the motors, display and keypad. Albeit, > all of it is untested, and could do with some thorough checking > before we burn it (I will soon). > > Meanwhile, I've been thinking of how to go about using a 16550 on > the board. Before I go out writing the code to drive it, does > anybody have experience along these lines? Or any GPL'd code that > could be copied across (eg, drivers/char/serial.c from a linux > source tree, but much simpler)? > > >From the looks of it, it wouldn't be too hard to write a driver from > scratch, but seems like it'd be reinventing the wheel. > > Regards, > > Bernard. > > -- > Bernard Blackham > bernard at blackham dot com dot au > > _______________________________________________ > Opendispense mailing list > Opendispense@ucc.gu.uwa.edu.au > http://lists.ucc.gu.uwa.edu.au/mailman/listinfo/opendispense > From bernard@blackham.com.au Tue Aug 12 15:49:43 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Tue, 12 Aug 2003 23:49:43 +0800 Subject: [Opendispense] UART 16550 code In-Reply-To: <20030812105519.GD18308@misato.xware.cx> References: <20030812082009.GA12534@amidala> <20030812105519.GD18308@misato.xware.cx> Message-ID: <20030812154943.GA20528@amidala> On Tue, Aug 12, 2003 at 08:55:19PM +1000, David Basden wrote: > As for simple code, try looking at Minix, which is designed to teach. > Once you've done that, write your own because Minix tries to look like > UNIX, and therefore all terminal handling is forever fucked in the head. Danke! Well both the serial driver from Minix and linux-1.0 look pretty simple and clean. Though the Minix driver doesn't support the 16550, only the 16450, which probably isn't a huge drawback. I'll probably write code for a 16450 anyhow - it seems simpler, does the speeds we need, and the 16550 (at least the one I have in mind) enters 16450-compatible mode on reset. I'll start writing my version some time tomorrow or Thursday. And hopefully we'll have something resembling a ROM image ready to burn before the weekend is over. =) Bernard. -- Bernard Blackham bernard at blackham dot com dot au From adrian@ucc.gu.uwa.edu.au Wed Aug 13 01:50:24 2003 From: adrian@ucc.gu.uwa.edu.au (Adrian Chadd) Date: Wed, 13 Aug 2003 09:50:24 +0800 Subject: [Opendispense] UART 16550 code In-Reply-To: <20030812154943.GA20528@amidala> References: <20030812082009.GA12534@amidala> <20030812105519.GD18308@misato.xware.cx> <20030812154943.GA20528@amidala> Message-ID: <20030813015024.GF108377@morwong.ucc.gu.uwa.edu.au> On Tue, Aug 12, 2003, Bernard Blackham wrote: > On Tue, Aug 12, 2003 at 08:55:19PM +1000, David Basden wrote: > > As for simple code, try looking at Minix, which is designed to teach. > > Once you've done that, write your own because Minix tries to look like > > UNIX, and therefore all terminal handling is forever fucked in the head. > > Danke! Well both the serial driver from Minix and linux-1.0 look > pretty simple and clean. Though the Minix driver doesn't support the > 16550, only the 16450, which probably isn't a huge drawback. I'll > probably write code for a 16450 anyhow - it seems simpler, does the > speeds we need, and the 16550 (at least the one I have in mind) > enters 16450-compatible mode on reset. 16550 == 16450 w/ a few bytes of FIFO 16450 == 8250 which can do >9600 reliably Adrian From bernard@blackham.com.au Wed Aug 13 15:49:44 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Wed, 13 Aug 2003 23:49:44 +0800 Subject: [Opendispense] Questions - new memory map In-Reply-To: <20030811151050.5150e717.harrymc@ucc.gu.uwa.edu.au> References: <20030811045013.GA31794@amidala> <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> <20030811151050.5150e717.harrymc@ucc.gu.uwa.edu.au> Message-ID: <20030813154944.GA32273@amidala> On Mon, Aug 11, 2003 at 03:10:50PM +0800, Harry McNally wrote: > - Terminate the four wire wrap pitails on signals needed for read and > write and full addressing (A15) onto the PCB. So the questions remain, which 4 lines do we want to run up? Almost necessarily - A15, R/W, Enable. This leaves one more to choose from: - Interrupt line, possibly the most useful - but could use polling instead. - Clock - running this line up here saves us a crystal on the daughterboard for the UART. Though, we can probably afford another crystal on the board. - Reset - to reset the state of the UART with the CPU. needed? I'm leaning towards the interrupt line because it appears to make the serial comms that much more reliable. Any strong reasons for any of the others? Regards, Bernard. -- Bernard Blackham bernard at blackham dot com dot au From adrian@ucc.gu.uwa.edu.au Wed Aug 13 17:06:14 2003 From: adrian@ucc.gu.uwa.edu.au (Adrian Chadd) Date: Thu, 14 Aug 2003 01:06:14 +0800 Subject: [Opendispense] Questions - new memory map In-Reply-To: <20030813154944.GA32273@amidala> References: <20030811045013.GA31794@amidala> <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> <20030811151050.5150e717.harrymc@ucc.gu.uwa.edu.au> <20030813154944.GA32273@amidala> Message-ID: <20030813170614.GB8474@morwong.ucc.gu.uwa.edu.au> On Wed, Aug 13, 2003, Bernard Blackham wrote: > On Mon, Aug 11, 2003 at 03:10:50PM +0800, Harry McNally wrote: > > - Terminate the four wire wrap pitails on signals needed for read and > > write and full addressing (A15) onto the PCB. > > So the questions remain, which 4 lines do we want to run up? Almost > necessarily - A15, R/W, Enable. This leaves one more to choose from: > > - Interrupt line, possibly the most useful - but could use polling > instead. > > - Clock - running this line up here saves us a crystal on the > daughterboard for the UART. Though, we can probably afford > another crystal on the board. > > - Reset - to reset the state of the UART with the CPU. needed? > > I'm leaning towards the interrupt line because it appears to make > the serial comms that much more reliable. Any strong reasons for any > of the others? Depends how the software is written. Whats the current interrupt handler doing? Why can't you have em all? Adrian From bernard@blackham.com.au Wed Aug 13 17:27:08 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Thu, 14 Aug 2003 01:27:08 +0800 Subject: [Opendispense] Questions - new memory map In-Reply-To: <20030813170614.GB8474@morwong.ucc.gu.uwa.edu.au> References: <20030811045013.GA31794@amidala> <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> <20030811151050.5150e717.harrymc@ucc.gu.uwa.edu.au> <20030813154944.GA32273@amidala> <20030813170614.GB8474@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030813172708.GA1715@amidala> On Thu, Aug 14, 2003 at 01:06:14AM +0800, Adrian Chadd wrote: > > I'm leaning towards the interrupt line because it appears to make > > the serial comms that much more reliable. Any strong reasons for any > > of the others? > > Depends how the software is written. Whats the current interrupt handler > doing? The interrupt handler will only be used for the daughterboard & UART. The logic board alone has it tied high. > Why can't you have em all? We can only fit 4 extra pins in and still have it neat & tidy, and keeping the ROM's easily interchangable. Sure we can drag some more lines across to the board, but it's not quite so elegant :) Bernard. -- Bernard Blackham bernard at blackham dot com dot au From adrian@ucc.gu.uwa.edu.au Thu Aug 14 01:22:43 2003 From: adrian@ucc.gu.uwa.edu.au (Adrian Chadd) Date: Thu, 14 Aug 2003 09:22:43 +0800 Subject: [Opendispense] Questions - new memory map In-Reply-To: <20030813172708.GA1715@amidala> References: <20030811045013.GA31794@amidala> <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> <20030811151050.5150e717.harrymc@ucc.gu.uwa.edu.au> <20030813154944.GA32273@amidala> <20030813170614.GB8474@morwong.ucc.gu.uwa.edu.au> <20030813172708.GA1715@amidala> Message-ID: <20030814012243.GC8474@morwong.ucc.gu.uwa.edu.au> On Thu, Aug 14, 2003, Bernard Blackham wrote: > On Thu, Aug 14, 2003 at 01:06:14AM +0800, Adrian Chadd wrote: > > > I'm leaning towards the interrupt line because it appears to make > > > the serial comms that much more reliable. Any strong reasons for any > > > of the others? > > > > Depends how the software is written. Whats the current interrupt handler > > doing? > > The interrupt handler will only be used for the daughterboard & > UART. The logic board alone has it tied high. Ok. If you use an interrupt handler you'll have to code up the interrupt routine and some enqueue/dequeue code. Find out how long each loop takes to run, see if you can sneak in that extra UART and support code. Which you may need to do anyway, if the existing code is already tight timewise.. Adrian From bernard@blackham.com.au Thu Aug 14 02:16:01 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Thu, 14 Aug 2003 10:16:01 +0800 Subject: [Opendispense] Questions - new memory map In-Reply-To: <20030814012243.GC8474@morwong.ucc.gu.uwa.edu.au> References: <20030811045013.GA31794@amidala> <20030811045323.GB61232@morwong.ucc.gu.uwa.edu.au> <20030811151050.5150e717.harrymc@ucc.gu.uwa.edu.au> <20030813154944.GA32273@amidala> <20030813170614.GB8474@morwong.ucc.gu.uwa.edu.au> <20030813172708.GA1715@amidala> <20030814012243.GC8474@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030814021600.GA2977@amidala> On Thu, Aug 14, 2003 at 09:22:43AM +0800, Adrian Chadd wrote: > > > Depends how the software is written. Whats the current interrupt handler > > > doing? > > > > The interrupt handler will only be used for the daughterboard & > > UART. The logic board alone has it tied high. > > Ok. If you use an interrupt handler you'll have to code up the interrupt routine > and some enqueue/dequeue code. Find out how long each loop takes to run, > see if you can sneak in that extra UART and support code. Already nearly done. > Which you may need to do anyway, if the existing code is already tight > timewise.. I believe the main loop of the code is pretty tight - faster than the main loop of the original ROM at least. Given that keypresses are polled for, it can't be too long. Bernard. -- Bernard Blackham bernard at blackham dot com dot au From bernard@blackham.com.au Sat Aug 16 16:22:46 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Sun, 17 Aug 2003 00:22:46 +0800 Subject: [Opendispense] Status update Message-ID: <20030816162246.GA5197@amidala> *** Hmm... I never received this message from the list last night. Apologies if it's a double. Hi all, Just a quick status update from tonight. I've finished writing the first go at the new ROM image. It's in CVS under openvend/ROM2. I still want to go over it all a couple of times to make sure it makes sense before we burn it. Some fresh eyes on it would also be handy too :) The board modifications didn't happen tonight - rescheduled for next week. Meanwhile, Harry will try and source a PC16550D UART, and the other odd-ball pieces for both the initial modification, and the daughterboard. The other code that needs to be written is the server backend. This backend will control the display & keypad, will probably run on mermaid (or whichever machine has a spare serial port). This will allow people to vend stuff from their coke accounts using the keypad. I'm not sure of the best way to interface it with dispense though (short of rewriting it from scratch :), and being able to type "dispense atomic tomato" from any terminal. This really is where the dispense-rewrite comes into play. If nobody has any better suggestions, I'll happily pick up my previous attempt based upon a PostgreSQL backend. Regards, Bernard. -- Bernard Blackham bernard at blackham dot com dot au From adrian@ucc.gu.uwa.edu.au Sat Aug 16 16:31:16 2003 From: adrian@ucc.gu.uwa.edu.au (Adrian Chadd) Date: Sun, 17 Aug 2003 00:31:16 +0800 Subject: [Opendispense] Status update In-Reply-To: <20030816162246.GA5197@amidala> References: <20030816162246.GA5197@amidala> Message-ID: <20030816163116.GA9075@morwong.ucc.gu.uwa.edu.au> On Sun, Aug 17, 2003, Bernard Blackham wrote: > > The board modifications didn't happen tonight - rescheduled for next > week. Meanwhile, Harry will try and source a PC16550D UART, and the > other odd-ball pieces for both the initial modification, and the > daughterboard. I have a couple. are you using the fifo's? if not, scab a 16450 off one of the serial boards in ucc. > I'm not sure of the best way to interface it with dispense though > (short of rewriting it from scratch :), and being able to type > "dispense atomic tomato" from any terminal. This really is where the > dispense-rewrite comes into play. If nobody has any better > suggestions, I'll happily pick up my previous attempt based upon a > PostgreSQL backend. Please. Check it into CVS? From bernard@blackham.com.au Sat Aug 16 16:42:41 2003 From: bernard@blackham.com.au (Bernard Blackham) Date: Sun, 17 Aug 2003 00:42:41 +0800 Subject: [Opendispense] Status update In-Reply-To: <20030816163116.GA9075@morwong.ucc.gu.uwa.edu.au> References: <20030816162246.GA5197@amidala> <20030816163116.GA9075@morwong.ucc.gu.uwa.edu.au> Message-ID: <20030816164241.GA5682@amidala> On Sun, Aug 17, 2003 at 12:31:16AM +0800, Adrian Chadd wrote: > I have a couple. are you using the fifo's? if not, scab a 16450 off one > of the serial boards in ucc. Current code uses the FIFOs to make life easy. It could be rewritten without it, but if we can source a 16550, then life is easy :) > > suggestions, I'll happily pick up my previous attempt based upon a > > PostgreSQL backend. > > Please. Check it into CVS? Already there - under dispence. Bernard. -- Bernard Blackham bernard at blackham dot com dot au From harrymc@ucc.gu.uwa.edu.au Mon Sep 1 04:53:09 2003 From: harrymc@ucc.gu.uwa.edu.au (Harry McNally) Date: Mon, 1 Sep 2003 12:53:09 +0800 Subject: [Opendispense] CPLD/FPGA Message-ID: <20030901125309.687a4621.harrymc@ucc.gu.uwa.edu.au> Hello open vendors A quick update on Altera parts. I spoke to Alan Taylor at Braemac (the Altera agent in Perth) and he suggested not using the 7512AE or 3512A because the higher density CPLDs are not cost effective compared to a sea-of-gates FPGA like the ACEX1K10 (10K gates) or ACEX1K30 (30K gates). The difference with these is that they are RAM based (take a 100mS or so to load the configuration from an external serial EEPROM or flash device). This isn't an issue providing the serial device can also be programmed on-board through a JTAG port. So, prices: ACEX1K10 100pin $14.70 ACEX1K10 144pin $20 ACEX1K30 144pin $24.50 We can explain our project and ask for a "paid for samples" which means we can buy a few pieces rather than a whole tray. Free design tools are available by downloading the Quartus tools (which have a diffeent UI to learn but has the same functionality). In the meantime, I can get over to see my contact that has some EPM7192 parts I used in a design for them. These are 192 macrocell and 5V and can be used for my prototyping board to try some ideas out. These are all PQFP (plastic quad flat pack) packages so we can use a QFP to PGA adapter board from RS Components to get the part onto wire wrap pins. See RS catalogue page 912, eg P/N 285-4641 100pin 0.5mm pitch $70.79 All for now Harry -- linux.conf.au 2004 The Australian Linux Technical Conference http://lca2004.linux.org.au/ 12-17 January 2004, Adelaide, South Australia Are you a computer angel? http://www.computerangels.org.au/ From harrymc@ucc.gu.uwa.edu.au Wed Sep 3 12:46:34 2003 From: harrymc@ucc.gu.uwa.edu.au (Harry McNally) Date: Wed, 3 Sep 2003 20:46:34 +0800 Subject: [Opendispense] CPLD/FPGA In-Reply-To: <20030901125309.687a4621.harrymc@ucc.gu.uwa.edu.au> References: <20030901125309.687a4621.harrymc@ucc.gu.uwa.edu.au> Message-ID: <20030903204634.5152a57e.harrymc@ucc.gu.uwa.edu.au> On Mon, 1 Sep 2003 12:53:09 +0800 Harry McNally wrote: > In the meantime, I can get over to see my contact that has some EPM7192 > parts I used in a design for them. These are 192 macrocell and 5V and can > be used for my prototyping board to try some ideas out. I now have six EPM7192 parts for project fun :-) All the best Harry -- linux.conf.au 2004 The Australian Linux Technical Conference http://lca2004.linux.org.au/ 12-17 January 2004, Adelaide, South Australia Are you a computer angel? http://www.computerangels.org.au/ From nick@ucc.gu.uwa.edu.au Mon Sep 29 11:31:45 2003 From: nick@ucc.gu.uwa.edu.au (Nick Bannon) Date: Mon, 29 Sep 2003 19:31:45 +0800 Subject: [Opendispense] FPGA Message-ID: <20030929113145.GU162819@morwong.ucc.gu.uwa.edu.au> I'm sure our current design is fine, but I felt the need to mention that in the latest http://www.rockby.com.au/ surplus catalogue there's "PCI Compliant FPGA"'s for $9.50 each. Device: XC4005E PC84 Package: PLCC-84 Xilinx with data sheet available Stock #29761 Looks like it might be a 5000 gate array: http://www.piclist.com/techref/xilinx/fpgacomp.htm There's also a bunch of other stuff: 8K DIP-28 SRAMs for $2.50, 4M 512Kx8 Flash (PLCC-32) for $2.80, 100Base-FX tranceivers for $49... Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal From nick@ucc.gu.uwa.edu.au Mon Sep 29 11:50:41 2003 From: nick@ucc.gu.uwa.edu.au (Nick Bannon) Date: Mon, 29 Sep 2003 19:50:41 +0800 Subject: [Opendispense] Device programmer Message-ID: <20030929115041.GV162819@morwong.ucc.gu.uwa.edu.au> In the August 2003 Circuit Cellar I found a couple of interesting things - an 802.11b microcontroller based system incorporating a TCP/IP stack and a bitbanged PCMCIA interface and... an ad for a USD$333 GALEP-4 pocket universal programmer. I've seen the programmer before, it's a cool idea, it's a parallel port device with a FPGA and a ZIF socket on top. You download a definition to it and it can provide arbitary voltages to arbitary pins, to program EPROMs, flash, PICs, AVRs, ... http://www.conitec.net/hardware/epages/galep4.htm http://www.conitec.net/hardware/epages/artlist.htm http://www.smartcom.co.uk/galep-4.html http://www.smartcom.co.uk/price_list.html Extra PLCC adaptors et al. aren't that cheap - USD$111 and up on the Conitec pricelist, not sure what the going rate for other brands is. It's battery powered, which means it runs fine off a notebook. The problem was that it needs Windows software to run, which might be fine, but if the company dissapeared or gave out no new updates it could end up somewhat limiting, like whatever DOS or Win3.1 programs needed to drive the other two non-functioning EPROM programmers hanging around the UCC. However! They've now got alpha quality Linux software, which makes me a whole lot happier that they're actually happy with going cross platform and not leaving us with a $500 dead-end doorstop. http://www.conitec.net/hardware/xpages/down.htm I think we should get one, and thought I might run it by youse all first. Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig@rcpt.to | I lack the time to make it shorter." - Pascal