From bernard@blackham.com.au Wed Jun 16 13:37:25 2004 From: bernard@blackham.com.au (Bernard Blackham) Date: Wed, 16 Jun 2004 21:37:25 +0800 Subject: [Opendispense] It beeps! Message-ID: <20040616133725.GD4647@blackham.com.au> mtearle and I tried burning my new version of the ROM tonight, and about 7 tries later, we can get it to beep! I moved the beeping code into the on-boot assembly instead of the C code. I have a suspicion that the reason it doesn't do much else, is that I can't setup the stack correctly. I've never had much success in programs that set up or move the stack reliably. If anybody wants to checkout the code from CVS and look if I'm doing anything silly? - reset vector (in vectors.s) goes to _start. _start does some fiddling of registers, sets up the stack by: lds _stack where _stack is declared in memory.x to be 0x007f - 1 (copied from another project). Should this be all that's needed to tell jsr where to put it's return addresses? I'll look into it more after exams in 5 days, but if anybody feels bored in the meantime, there's a starting point. The next thing I'd like to get working is writing to the display - this should make debugging *much* easier. S'all for now. Bernard. -- Bernard Blackham From harrymc@decisions-and-designs.com.au Wed Jun 16 14:22:45 2004 From: harrymc@decisions-and-designs.com.au (Harry) Date: Wed, 16 Jun 2004 22:22:45 +0800 Subject: [Opendispense] It beeps! In-Reply-To: <20040616133725.GD4647@blackham.com.au> References: <20040616133725.GD4647@blackham.com.au> Message-ID: <20040616222245.0706f421.harrymc@decisions-and-designs.com.au> On Wed, 16 Jun 2004 21:37:25 +0800 Bernard Blackham wrote: > mtearle and I tried burning my new version of the ROM tonight, and > about 7 tries later, we can get it to beep! Great progress ! Aren't you studing for exams Mr B ? ;-) > I'll look into it more after exams in 5 days, but if anybody feels > bored in the meantime, there's a starting point. Eep. I've made the crazy plan to start a sarge distro for Computer Angels. > The next thing I'd like to get working is writing to the display - > this should make debugging *much* easier. Let me know, post exams, when you'll be looking at it again. I can come and do some back seat coding if you'd like :-) cu Harry -- Are you a computer angel? http://www.computerangels.org.au/ From bernard@blackham.com.au Wed Jun 16 14:43:37 2004 From: bernard@blackham.com.au (Bernard Blackham) Date: Wed, 16 Jun 2004 22:43:37 +0800 Subject: [Opendispense] It beeps! In-Reply-To: <20040616222245.0706f421.harrymc@decisions-and-designs.com.au> References: <20040616133725.GD4647@blackham.com.au> <20040616222245.0706f421.harrymc@decisions-and-designs.com.au> Message-ID: <20040616144336.GE4647@blackham.com.au> On Wed, Jun 16, 2004 at 10:22:45PM +0800, Harry wrote: > On Wed, 16 Jun 2004 21:37:25 +0800 Bernard Blackham wrote: > > mtearle and I tried burning my new version of the ROM tonight, and > > about 7 tries later, we can get it to beep! > > Great progress ! Aren't you studing for exams Mr B ? ;-) Uhhh, yep ;) > > I'll look into it more after exams in 5 days, but if anybody feels > > bored in the meantime, there's a starting point. > > Eep. I've made the crazy plan to start a sarge distro for Computer Angels. I've just solved it. Firstly I discovered the very useful m68hc1x-sim! : $ m68hc11-gdb rom2.elf GNU gdb 6.0 [...] (gdb) target sim Connected to the simulator. (gdb) load rom2.elf Loading section .page0, size 0x8 lma 0x0 Loading section .text, size 0xd5d lma 0x8000 Loading section .rodata, size 0x85 lma 0x8d5d Loading section .vectors, size 0x40 lma 0xffc0 Start address 0x8cf4 Transfer rate: 29008 bits in <1 sec. (gdb) b _start Breakpoint 1 at 0x8cf4 (gdb) run Starting program: /home/wheel/dagobah/vendstuff/cvs/openvend/openvend/ROM2/rom2.elf Breakpoint 1, 0x00008cf4 in _start () (gdb) and so on. Very funky! And it told me that I was setting the stack pointer to a pointer, not an immediate value (again, silliness on my part). Using #_stack instead of _stack, and now gdb enters main. Hurrah! > > The next thing I'd like to get working is writing to the display - > > this should make debugging *much* easier. > > Let me know, post exams, when you'll be looking at it again. I can come > and do some back seat coding if you'd like :-) I'm currently doing it when I get bored of studying - ie, it happens quite sporadically and randomly. I'd like to do some more sanity checking of the code before I burn another ROM. I've been burnt by a few too many silly mistakes tonight for my liking (eg, not putting 0x for hex values when cutting & pasting code from the disassembly (which didn't prefix hex values with 0x)). Anyway, will keep the list updated on progress :) Bernard. -- Bernard Blackham From bernard@blackham.com.au Thu Jun 17 22:50:45 2004 From: bernard@blackham.com.au (Bernard Blackham) Date: Fri, 18 Jun 2004 06:50:45 +0800 Subject: [Opendispense] more vending machine hacking Message-ID: <20040617225045.GL4647@blackham.com.au> It's calling me... I've fixed a lot of silly bugs in the code with the help of the simulator and I'm going to burn another ROM this morning around 8:30am, which should, in theory, write to the display, spin a motor, and beep several times. In practise, it'll probably just beep and hopefully show something on the display. Will see... Then I plan to study. Bernard. -- Bernard Blackham From bernard@blackham.com.au Sat Jun 19 15:23:35 2004 From: bernard@blackham.com.au (Bernard Blackham) Date: Sat, 19 Jun 2004 23:23:35 +0800 Subject: [Opendispense] more progress Message-ID: <20040619152335.GF2242@blackham.com.au> - First thing it said today it said "DLROWOLLEH" :) - And it now says "HELLO CRUEL WORLD" ... - Door events are noticed. - It reads keys 1 and 9 (first key in both rows) - I think I know the problem, but won't get time to test until monday night. - Motors still haven't moved. - Serial port I expect to take about 10 lines of code - also for Monday. - Harry has been super kind and lent me his eprom eraser, so the compile-burn-test cycle won't stall quite so often. :) That's all for now. Bernard. -- Bernard Blackham From bernard@blackham.com.au Sun Jun 20 12:38:45 2004 From: bernard@blackham.com.au (Bernard Blackham) Date: Sun, 20 Jun 2004 20:38:45 +0800 Subject: [Opendispense] A vending machine that vends? Never! In-Reply-To: <20040619152335.GF2242@blackham.com.au> References: <20040619152335.GF2242@blackham.com.au> Message-ID: <20040620123845.GG2242@blackham.com.au> On Sat, Jun 19, 2004 at 11:23:35PM +0800, Bernard Blackham wrote: > - It reads keys 1 and 9 (first key in both rows) - I think I know > the problem, but won't get time to test until monday night. Evil gcc optimising the usefulness out of code. Fixed. All keys are now detected. > - Motors still haven't moved. The motors now move (= Home sensors need to be used to tell it where to stop correctly. (Code is there, but not used yet). Despite this however, there is now a fairly functional ROM in the machine that will drop stuff out. Note the contents of the machine is a couple of months out of code. :) So all that's left is the home sensors, a serial keypad and the rest is icing! Bernard. -- Bernard Blackham From bernard@blackham.com.au Mon Jun 21 17:56:57 2004 From: bernard@blackham.com.au (Bernard Blackham) Date: Tue, 22 Jun 2004 01:56:57 +0800 Subject: [Opendispense] Tonight's work. Message-ID: <20040621175657.GA2245@blackham.com.au> Well, tonight we had the motors spinning and listening to the home sensors to tell it where to stop. Unfortunately I haven't been thinking straight, perpetually messing up the logic and we've yet to burn a ROM that does the right thing. I believe I have one now and I'll burn it tomorrow arvo and see. It now speaks on the serial port, but isn't listen to commands. I can't see why - gdb's simulator hooks up the serial port to stdin/stdout and it works fine. Perhaps it's not recognising the carriage return (\r vs \n). I've made it recognise both. Failing that, I'll look at it with the CRO tomorrow to see what, if anything, is going through. Bernard. -- Bernard Blackham From bernard@blackham.com.au Tue Jun 22 19:14:55 2004 From: bernard@blackham.com.au (Bernard Blackham) Date: Wed, 23 Jun 2004 03:14:55 +0800 Subject: [Opendispense] It lives. Message-ID: <20040622191455.GC2494@blackham.com.au> Another braindump. All the peripherals are more or less well behaved and talkative. mtearle suggested that we embed the source code into the ROM so that it won't be lost in 20 years time. I've done so, and even better, the ROM has a (yet untested) feature to download the source via xmodem out the serial line :) The ROM features helpful help screens, computer & human parseable responses, amongst other strange oddities :) All keys, switches and buttons are read, and notification is directly sent to the serial console. There is a 'standalone mode' when you flip one of the DIP switches that allows the vending machine to operate without a computer (with a dead coin mech, this means everything is free). The problem of the motors claiming the home sensors was failing occasionally was actually not a bug in the motors code at all. It was a bug in my assembly delay routine - the delay time (in ms) would always be one less than specified, so a delay of 1ms was actually no delay at all. Hence the motors never had time to get away. I haven't confirmed this yet, but will do so tomorrow. Need to get writing dispense2. Finally, I'm about to call for ideas for authentication on the ucc list... Bernard. -- Bernard Blackham From bernard@blackham.com.au Wed Jun 23 19:10:47 2004 From: bernard@blackham.com.au (Bernard Blackham) Date: Thu, 24 Jun 2004 03:10:47 +0800 Subject: [Opendispense] Re: [ucc] Vending machine authentication ideas? In-Reply-To: <20040622192343.GD2494@blackham.com.au> References: <20040622192343.GD2494@blackham.com.au> Message-ID: <20040623191047.GA2187@blackham.com.au> On Wed, Jun 23, 2004 at 03:23:44AM +0800, Bernard Blackham wrote: > Can anybody suggest something suitable? With all the suggestions, I've gone for the following: Snack machine stores a 16-character key, and an increasing sequence in NVRAM. If the overriding dip switch isn't set, it presents a challenge to the client if they wish to vend something. The client must compute CRC16(challenge + secret + message) and attach it to the message, and the snack machine does similarly. This seems sufficient to be a deterrent, though given enough time a determined individual could probably crack it. Thanks for all the suggestions :) I'm also at the point where I believe the ROM is about as full and packed with features as needed (and will fit!). It even contains it's own source code downloadable via xmodem, should it be lost in 10 years time. There are also commands to peek and poke random bytes of memory so that extra code can be tried out without burning another EPROM. (eg, for testing peripherals when they come). Bernard. -- Bernard Blackham From bernard@blackham.com.au Sat Jun 26 16:39:43 2004 From: bernard@blackham.com.au (Bernard Blackham) Date: Sun, 27 Jun 2004 00:39:43 +0800 Subject: [Opendispense] Vending Machine again! Message-ID: <20040626163943.GM2187@blackham.com.au> You can now use the vending machine to dispense drinks and open the door ... it's running of the current dispense system, hence items from the vending machine itself are not yet charged for (though there's nothing of value yet). Expect things to break until the dispense rewrite is complete and running. I'm working on it still, but less often at the moment. The gist for using the vending machine: Create a file in your UCC homedir called .pin. In this, put a 4-digit number, and ensure the file is readable only by you - otherwise you won't be able to use it. Find out your userid by typing 'id' when logged into any UCC machine (should be a 5-digit number for most people, like 11002). Wander up the the vending machine. Type your 5-digit UID (left-pad with zeroes if yours is shorter). Then enter your 4-digit PIN. Then if all is well, you can: - open the door by typing '55' - dispense drinks by typing 'X8', where X is the slot number in the coke machine - vend a snack (currently free, if there are any) - hit reset to log out. There are a couple of bugs with the current code, in that you have to type slowly (wait a second between keypresses), else it doesn't quite work as expected. This should be fixed shortly though. And all of the above is subject to change too :) Bernard. -- Bernard Blackham