You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
(6) |
Mar
(41) |
Apr
(23) |
May
(11) |
Jun
(2) |
Jul
|
Aug
|
Sep
(9) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2008 |
Jan
(6) |
Feb
(1) |
Mar
(23) |
Apr
(18) |
May
(21) |
Jun
(13) |
Jul
(34) |
Aug
(5) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(4) |
2009 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(10) |
May
(1) |
Jun
(11) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
(13) |
2010 |
Jan
(10) |
Feb
(4) |
Mar
(28) |
Apr
(3) |
May
(38) |
Jun
(22) |
Jul
(92) |
Aug
(154) |
Sep
(218) |
Oct
(45) |
Nov
(20) |
Dec
(1) |
2011 |
Jan
(33) |
Feb
(15) |
Mar
(32) |
Apr
(33) |
May
(48) |
Jun
(35) |
Jul
(7) |
Aug
|
Sep
(11) |
Oct
(5) |
Nov
|
Dec
(7) |
2012 |
Jan
(56) |
Feb
(11) |
Mar
(6) |
Apr
|
May
(128) |
Jun
(59) |
Jul
(21) |
Aug
(16) |
Sep
(24) |
Oct
(39) |
Nov
(12) |
Dec
(12) |
2013 |
Jan
(14) |
Feb
(61) |
Mar
(97) |
Apr
(46) |
May
(13) |
Jun
(23) |
Jul
(12) |
Aug
(25) |
Sep
(9) |
Oct
(81) |
Nov
(73) |
Dec
(45) |
2014 |
Jan
(36) |
Feb
(57) |
Mar
(20) |
Apr
(41) |
May
(43) |
Jun
(11) |
Jul
(14) |
Aug
(32) |
Sep
(9) |
Oct
(27) |
Nov
(21) |
Dec
(6) |
2015 |
Jan
(14) |
Feb
(23) |
Mar
(1) |
Apr
(19) |
May
(40) |
Jun
(11) |
Jul
(1) |
Aug
(2) |
Sep
(14) |
Oct
(10) |
Nov
(9) |
Dec
(13) |
2016 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
|
May
(4) |
Jun
(13) |
Jul
(8) |
Aug
(3) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
2017 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(7) |
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(9) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(3) |
Jul
(6) |
Aug
|
Sep
(2) |
Oct
(54) |
Nov
(47) |
Dec
(53) |
2019 |
Jan
(23) |
Feb
(24) |
Mar
(19) |
Apr
(15) |
May
(5) |
Jun
(34) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(7) |
Apr
(7) |
May
(5) |
Jun
(15) |
Jul
(22) |
Aug
(28) |
Sep
(13) |
Oct
(9) |
Nov
(17) |
Dec
(13) |
2021 |
Jan
(5) |
Feb
(1) |
Mar
(1) |
Apr
(9) |
May
(21) |
Jun
(9) |
Jul
|
Aug
(6) |
Sep
(16) |
Oct
|
Nov
(1) |
Dec
(6) |
2022 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(21) |
Oct
(5) |
Nov
(1) |
Dec
(1) |
2024 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Matthias T. <mt...@we...> - 2008-04-05 18:51:55
|
Hi, I just made a new release of amforth. The most notable changes are a better ans94 conformance (stack order of double cell values) and the assembler from Lubos Pekny (www.forth.cz). The assembler may emit a warning like Appnotes\m169def.inc(1199): warning: Register r31 (and r30) already defined by the .DEF directive this is harmless and can be ignored. The downloadable package contains now every file to make it easier to use. Have fun with it Matthias |
From: Matthias T. <mt...@we...> - 2008-03-24 15:25:34
|
Klaus Zerbe wrote: > @Matt: If possible, try also another controller since Atmega8 ist a > little bit small for amforth anyway. For the records: I just put an amforth from repository trunk on an atmega8 with an external 12MHz quartz and everything worked as expected. amforth 2.7 ATmega8 > unused cells decimal u. 2298 ok > The fuses are as follows MCU=atmega168 LFUSE=0xee HFUSE=0xdf EFUSE=0xf9 MCU=atmega8 LFUSE=0xee HFUSE=0xd9 Bye Matthias |
From: Matthias T. <mt...@we...> - 2008-03-23 09:09:14
|
Hi, > are there yet any ideas on how the Block commands will be done? I guess > the > biggest problem is memory as the normal 1024 byte block size would be far > to big. I've implemented some words for the I2C EEPROM with the native block sizes of the chips (around 32 or 64 bytes per block). One approach to implement full block buffers could be a virtualization. But this will be difficult since the normal memory access words have to be used to access the block buffer. A word set like b@/b! to access (virtual) block memory would certainly work, but does not help porting code from other forth's . In older forth version a word b/blk was defined to give the size of a block buffer in bytes. The value can be different for each block device (EEPROM, SD-Card etc). A total different solution would be: full block buffer sizes but only on systems that have enough memory (internal or external). All solution should provide some kind of an abstraction layer, since there are far too many different block devices available. That layer can work with native block sizes. Bye Matthias |
From: Christian B. <cas...@ca...> - 2008-03-22 18:26:10
|
Servus, (=bavarian for hello and goodbye) are there yet any ideas on how the Block commands will be done? I guess the biggest problem is memory as the normal 1024 byte block size would be far to big. Servus Casandro |
From: Matthias T. <mt...@we...> - 2008-03-13 20:24:29
|
Christian Berger wrote: > Ohh I was able to get it from therw. It seems like you did preety much what I > did. I think from what I have seen the only point where I could claim my code > to be better is in the vsync area, but that's largely irrelevant. Ohh and my > clock doesn't need an additional quartz. > > Anyhow, are you interrested in getting some FM-Synthesis sound routines for > your application? I'm collecting everything and publish all I'm allowed to do. But the TV application is not mine. Bye Matthias |
From: Christian B. <cas...@ca...> - 2008-03-13 20:11:43
|
Am Donnerstag 13 März 2008 20:57:57 schrieb Matthias Trute: > Erich Waelde wrote: > > Hello, > > > > Christian Berger wrote: > >> Am Mittwoch 12 März 2008 20:43:16 schrieb Erich Waelde: > >>> not sure whether this helps: You did look at the application > >>> in amforth/appl/tv, did you? > >> > >> No, but that sounds interresting. What is it and where do I find it? I > >> don't have an appl directory. > > > > You need to look at the svn sources directly: > > http://amforth.svn.sourceforge.net/viewvc/amforth/appl/tv/ > > I'm sorry to tell, that the link does not work any more... Ohh I was able to get it from therw. It seems like you did preety much what I did. I think from what I have seen the only point where I could claim my code to be better is in the vsync area, but that's largely irrelevant. Ohh and my clock doesn't need an additional quartz. Anyhow, are you interrested in getting some FM-Synthesis sound routines for your application? Servus Casandro |
From: Matthias T. <mt...@we...> - 2008-03-13 19:57:55
|
Erich Waelde wrote: > Hello, > > Christian Berger wrote: >> Am Mittwoch 12 März 2008 20:43:16 schrieb Erich Waelde: >>> not sure whether this helps: You did look at the application >>> in amforth/appl/tv, did you? >> No, but that sounds interresting. What is it and where do I find it? I don't >> have an appl directory. > > You need to look at the svn sources directly: > http://amforth.svn.sourceforge.net/viewvc/amforth/appl/tv/ I'm sorry to tell, that the link does not work any more... The reason is simple: a reorganization of the repository structure. It is not yet fully finished but I think it won't change a lot again, since I use the new structure internally for quite some time. The only thing thats left is around applications that I cannot work with, like the tv application. The actual link for them is http://amforth.svn.sourceforge.net/viewvc/amforth/applications/ All new code is now in trunk, regardless of core or library or (my) applications. Matthias |
From: Erich W. <ew....@on...> - 2008-03-13 19:14:10
|
Hello, Christian Berger wrote: > Am Mittwoch 12 März 2008 20:43:16 schrieb Erich Waelde: > > not sure whether this helps: You did look at the application > > in amforth/appl/tv, did you? > > No, but that sounds interresting. What is it and where do I find it? I don't > have an appl directory. You need to look at the svn sources directly: http://amforth.svn.sourceforge.net/viewvc/amforth/appl/tv/ Cheers, Erich |
From: Christian B. <cas...@ca...> - 2008-03-13 08:05:36
|
Servus, I just made the first release of the Forth-Computer, a modified version of amforth with video output and keyboard input. Here's the release note: http://www.mikrocontroller.net/topic/94193 Servus Casandro |
From: Christian B. <cas...@ca...> - 2008-03-12 21:25:40
|
Am Mittwoch 12 März 2008 20:43:16 schrieb Erich Waelde: > Hi, > > not sure whether this helps: You did look at the application > in amforth/appl/tv, did you? No, but that sounds interresting. What is it and where do I find it? I don't have an appl directory. I found the bug now, insteadt of writing .set heap=heap+XSize*YSize+... I wrote .set heap=XSize+YSize+... I am now almoust done, BTW. The only thing missing is shift on the keyboard. > Good luck, > Erich Thank you Christian Berger |
From: Erich W. <ew....@on...> - 2008-03-12 19:44:07
|
Hi, not sure whether this helps: You did look at the application in amforth/appl/tv, did you? Good luck, Erich Christian Berger wrote: > Servus, (=bavarian for hello and goodbye) > > I am trying to add video-terminal code to amforth, and currently it only kinda > works. > > I can enter text and it gets displayed, but whenever I press the enter key it > mostly crashes. > > I suspect that my software and amforth use the same memory areas. > > I am currently using a code like this to allocate space on the heap: > > .dseg > .org heap > keyboard_buffer: .byte 1 > keyboard_shift: .byte 1 > .set heap = heap + 2 > .cseg > > I am not sure if this is correct, but if it is I will also check if I'm not > messing with registers in a way I shouldn't. > > Servus > Casandro > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Amforth-devel mailing list > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: Christian B. <cas...@ca...> - 2008-03-12 12:43:26
|
Servus, (=bavarian for hello and goodbye) I am trying to add video-terminal code to amforth, and currently it only kinda works. I can enter text and it gets displayed, but whenever I press the enter key it mostly crashes. I suspect that my software and amforth use the same memory areas. I am currently using a code like this to allocate space on the heap: .dseg .org heap keyboard_buffer: .byte 1 keyboard_shift: .byte 1 .set heap = heap + 2 .cseg I am not sure if this is correct, but if it is I will also check if I'm not messing with registers in a way I shouldn't. Servus Casandro |
From: Matthias T. <mt...@we...> - 2008-03-09 17:10:55
|
Christian Berger wrote: > Am Freitag 07 März 2008 17:22:08 schrieb Matthias Trute: >> Hi, >> >>> Now my big question is, how do I redirect the output of the forth system >>> to the emit_tv word? >> just do >> >> ' your-emit is emit > > Thanks, that works fine, but how can I change that permanently? similiar: amforth defines a deferred word named turnkey which is executed whever the controller starts up. The default turnkey is defined in the application/words/turnkey.asm file and sets up the serial line, turns the interrupts on and prints the version number. You turnkey action may look like -------------- : my-turnkey ( now your code goes here ) ; ' my-turnkey is turnkey --------------- And the default turnkey action is changed to yours. Be aware that the default turnkey action is not saved, you may need to re-flash the eeprom (turnkey is a EEPROM based DEFER word). >> The IS/DEFER is based upon a forth200x standard see >> >> http://www.forth200x.org/deferred.html for the >> details. > > Unfortunately I know far to little about Forth to understand that. Its a elegant way to do vectored execution. Traditional forth would express it like the first amforth versions: A variable named '<something> and a word named <something> that reads the content of the variable '<something> and executes the XT stored there. ------ old variable 'something : something 'something @ execute ; ' a-word 'someting ! something ------- new RDEFER something ' a-word IS something something --------- afterwards something will execute a-word when called. The RDEFER is used to express that the XT vector is stored in RAM. Other possibilities are EDEFER (for EEPROM) and UDEFER (for the user area). An IDEFER would use a flash cell. The IS is always the same, for all deferred words. Note that the DEFER/IS words are almost lowercase and need to be loaded from the file lib/defer.fs since the core system contains the runtime words only ;=) Bye Matthias |
From: Christian B. <cas...@ca...> - 2008-03-09 12:16:35
|
Am Freitag 07 März 2008 17:22:08 schrieb Matthias Trute: > Hi, > > > Now my big question is, how do I redirect the output of the forth system > > to the emit_tv word? > > just do > > ' your-emit is emit Thanks, that works fine, but how can I change that permanently? In the next step of my project I will loose the serial line, but gain a keyboard, so I'd like to change input and output to those new devices. > The IS/DEFER is based upon a forth200x standard see > > http://www.forth200x.org/deferred.html for the > details. Unfortunately I know far to little about Forth to understand that. > Bye > Matthias Servus Casandro |
From: Matthias T. <mt...@we...> - 2008-03-07 16:22:16
|
Hi, > Now my big question is, how do I redirect the output of the forth system to > the emit_tv word? just do ' your-emit is emit at the prompt or inside a colon definition : 2tv ['] your-emit is emit ; The IS/DEFER is based upon a forth200x standard see http://www.forth200x.org/deferred.html for the details. Bye Matthias |
From: Christian B. <cas...@ca...> - 2008-03-07 15:04:16
|
Servus, (=bavarian for hello and goodbye) I want to make a forth-based home computer. And I already got so far as to write accompanying video routines for it. So I can currently enter something like emit_tv and a character will appear on the monitor. The hardware actually just consists of 2 resistors. :) If you are interested I can upload pictures of the current system somewhere. Now my big question is, how do I redirect the output of the forth system to the emit_tv word? Servus Casandro |
From: Erich W. <ew....@on...> - 2008-03-06 19:54:13
|
Hello, Matthias Trute wrote: > Hi Erich, > > better late than never > > Erich Waelde wrote: > >> In release 2.6 "case" "encase" "of" "endof" were moved into >> lib/case.frt > >> Any ideas? > > I took the code from the usenet and did not test it. mea culpa. > Another forth-project named flashforth has a different implementation > for it, maybe you can test theirs? > After downloading "flashforth" (for PIC controllers, GPL v3) from flashforth.sourceforge.net, I stole "case.fth" from their code base. With a minimum of changes (change "for ... next" to "?do ... loop") it did work for my tests. In particular, case did work, and the argument is cleaned up properly. I found this implementation easily readable. Kudos to Mikael Nordman and the flashforth folks. Please find below the files I used. Cheers, Erich ------------------------------------------------------------------- flash_case.fs ------------------------------------------------------------------- \ ********************************************************************* \ Case for FlashForth * \ Filename: case.fth * \ Date: 15.1.2008 * \ FF Version: 3.2 * \ Copyright: Mikael Nordman * \ Author: Mikael Nordman * \ ********************************************************************* \ FlashForth is licensed acording to the GNU General Public License* \ ********************************************************************* \ A case implementation posted by Jenny Brien on c.l.f. \ Modified to use for..next instead of do..loop \ Modified for use in amforth, changed for..next back \ to do..loop; Erich Waelde \ -case \ marker -case \ hex ram variable #of : case ( x -- x #of ) #of @ 0 #of ! \ allow nesting ; immediate : of ( -- orig) postpone over postpone = ( copy and test case value) postpone if ( add orig to control flow stack ) postpone drop ( discards case value if = ) ; immediate : endof ( orig1 -- orig2 ) postpone else 1 #of +! ; immediate : endcase ( #of orig1..orign -- ) postpone drop ( discard case value ) #of @ 0 do postpone then loop #of ! ; immediate ------------------------------------------------------------------- test_case.fs \ 2008-02-02 Erich Waelde #include lib/ans94/postpone.frt #include flash_case.fs : checkout ( n -- ) case 0 of ." none" endof 1 of ." once" endof 2 of ." twice" endof ." unknown" endcase ; ------------------------------------------------------------------- |
From: Matthias T. <mt...@we...> - 2008-03-02 20:09:52
|
Hi Erich, better late than never Erich Waelde wrote: > In release 2.6 "case" "encase" "of" "endof" were moved into > lib/case.frt > > Any ideas? I took the code from the usenet and did not test it. mea culpa. Another forth-project named flashforth has a different implementation for it, maybe you can test theirs? Matthias |
From: Matthias T. <mt...@we...> - 2008-03-02 20:07:34
|
Klaus Zerbe wrote: > Hi, > i probably got into the same problems like Matt Eastburn. > > I also used AVStudio 4.13 to compile & link and burned the HEX and EEP > files with AVR Prog 1.4 into an Atmega8L with an external Xtal with > 36864 Mhz. > > I fused for Highsped external Xtal and 2.7V BOD, leaving all other fuses > alone. I found the following website useful when it comes to fuses: http://palmavr.sourceforge.net/cgi-bin/fc.cgi > Like for Matt the resulting controller did not communicate via USART. > Reducing the baudrate didn't help. So I added some Assembler code for > trace output and that worked. I could follow the inner interpreter and > found this running all the time, but seemed not reaching the > "applturnkey" ever. Strange. Did you find out in which word the inner interpreter kept so busy? I've observed this behavior only when I forgot to upload the eeprom bytes. > Finally I stopped this and used an ATmega168 instead. After correcting a > Typo in "atmega168.asm" (The label ADCCaddr was written as ADCaddr) that > compiled and linked fine and after burning that output amforth started > without a problem. It's not exactly a typo but a different name for the same address in different tools. And I prefer the linux based ones ;=) > So maybe something is wrong in "atmega8.asm" when using the Atmega8L ? This and/or the fuses. > @Matt: If possible, try also another controller since Atmega8 ist a > little bit small for amforth anyway. There are only 17% memory free for > your applications. Atmega168 is pincompatible but has 16kb instead 8kb > FlashROM and a built-in far-distance JMP-instruction too ;) at a very deep internal level, amforth uses the far-call instruction even on systems which do not officially support the mnemomic. All my atmega8 run fine with it and have no trouble with it, but maybe not all are such tolerant. Can you please send me a picture of your atmega directly? (the mailling list does not accept attachements) together with your application definition file. Matthias |
From: Klaus Z. <kl...@ze...> - 2008-03-02 17:55:42
|
Hi, i probably got into the same problems like Matt Eastburn. I also used AVStudio 4.13 to compile & link and burned the HEX and EEP files with AVR Prog 1.4 into an Atmega8L with an external Xtal with 36864 Mhz. I fused for Highsped external Xtal and 2.7V BOD, leaving all other fuses alone. @Matt: click on the "Advanced settings button" in AVR prog to access the fuses. Like for Matt the resulting controller did not communicate via USART. Reducing the baudrate didn't help. So I added some Assembler code for trace output and that worked. I could follow the inner interpreter and found this running all the time, but seemed not reaching the "applturnkey" ever. Finally I stopped this and used an ATmega168 instead. After correcting a Typo in "atmega168.asm" (The label ADCCaddr was written as ADCaddr) that compiled and linked fine and after burning that output amforth started without a problem. So maybe something is wrong in "atmega8.asm" when using the Atmega8L ? @developers: Keep up your great work! I've not used Forth since 1986 on Z80 and 8088- systems but remember how much fun that was. Now its even greater being able to explore those cool microcontrollers in direct interaction ! @Matt: If possible, try also another controller since Atmega8 ist a little bit small for amforth anyway. There are only 17% memory free for your applications. Atmega168 is pincompatible but has 16kb instead 8kb FlashROM and a built-in far-distance JMP-instruction too ;) Kind regards Klaus Zerbe |
From: Erich W. <ew....@on...> - 2008-03-02 15:31:28
|
Hi Matt, Matt Eastburn wrote: > > I am using a atmega8L (at 5volts). 8MHz Crystal. 9600baud. > > As mentioned in my first post i get the exact same hardware to work when > compiling C to it. To summarize: 1. you can transfer a program to the controller. I suppose, you use the same tools/programmer for a. the compiled C Programm and b. the "compiled" amforth system. Can you reread the program from the compiler and compare that to the original file? 2. The amforth system depends on a small second file (*.eep.hex). This file is only 12 byte, but it must be transfered into the controllers eeprom. It stores a few important things for internal use of the amforth system. Just to make sure, you did transfer that as well, right? If you did not, the amforth system cannot start. 3. fuse bits. The fact, that you can successfully transfer and run a compiled C program, seems to suggest, that it is not a problem with the fuse bits. I do not use AVR Studio, but I expect that there is some "menu", which says something like "set fuses" or "set fuses/locks". Then I expect a panel with a list of "bits" to select, with strange names like BODLEVEL, BODEN (brown out detection enabled), CKSEL0..3 to select the exact clock source. In theory, a brandnew controller runs on its internal RC oscillator at something like 125 kHz, but again, the fact that your C program works, seems to suggest that the fuses are set ok. > I do unplug the programmer - but it does not help. > > Now as for the fuse bits - this is where i could be going wrong. because I > dont really know how or what to set them to. > > I just use AVR Studio to compile the asm files then program the chip. but > dont know what to set the fuse bits to - or where i can set them. see above. 4. Again, let me recommend to test lower baud rates. Good luck, Erich |
From: Matt E. <mat...@me...> - 2008-03-01 22:50:39
|
Hi Erich, thanks for your help. I will give you some more info on the setup I have. I am using a atmega8L (at 5volts). 8MHz Crystal. 9600baud. As mentioned in my first post i get the exact same hardware to work when compiling C to it. I do unplug the programmer - but it does not help. Now as for the fuse bits - this is where i could be going wrong. because I dont really know how or what to set them to. I just use AVR Studio to compile the asm files then program the chip. but dont know what to set the fuse bits to - or where i can set them. Matt Eastburn |
From: Erich W. <ew....@on...> - 2008-03-01 15:32:17
|
Hello, and "welcome" :-) Matt Eastburn wrote: > I have just set up a basic project to see if I can get something out > of the serial port. > > At this stage can't get it to do anything on the serial port. This could unfortunately be any number of things ... so without more details (exact controller, crystal or internal oscillator, at what speed ...) this is hard to "debug". My suggestions: 1. go to very low speeds on the serial port, maybe 1200 baud, just to see, if bits go across the line. Use an LED with a resistor as a "probe". Just to make sure there are pulses on the cable connections. 2. I had similar problems with an atmega32. They were fixed by using a "baud rate crystal" (11.0592 MHz) and better fuse settings (I had to dig deep in the datasheet: hfuse=0x89, lfuse=0xee). This setting now works reliably with 115200 baud. 3. To make things a little more "obscure", the programmer I used initially, did not release the /Reset line properly. So unplugging the damn thing made much of a difference :-) Good luck! Erich Good luck! |
From: Matt E. <mat...@me...> - 2008-03-01 08:48:57
|
Hi guys, Just found amforth and am pretty excited by it. I have just set up a basic project to see if I can get something out of the serial port. At this stage can't get it to do anything on the serial port. Is there something I am doing wrong. Avr assembler compiles fine. Then programs to the chip fine. I know the hardware works because I can get C to talk on the serial port. Please help me out if you can. Matt Eastburn |
From: Erich W. <ew....@on...> - 2008-02-05 20:55:34
|
Hello, In release 2.6 "case" "encase" "of" "endof" were moved into lib/case.frt I loaded a small amforth (no case) on an atmega32. using the following file ----------------------------------------- #include lib/ans94/postpone.frt #include lib/case.frt : checkout ( n -- ) case 0 of ." none" endof 1 of ." once" endof 2 of ." twice" endof ." unknown" endcase ; ----------------------------------------- for upload with amforth-upload.py produces a reset or hang (!) of the controller after "endcase". Any ideas? The above example used to work with Version 2.5 and included case.asm endcase.asm of.asm endof.asm files, except for a leftover argument. Cheers, Erich --- the gory details -------------------- $ amforth-upload.py -t /dev/ttyUSB0 zz.fs : postpone ok bl word find dup 0< ok if ok drop compile compile , exit ok then ok if ok , exit ok then ok drop ok [ base @ decimal ] -13 [ base ! ] throw ok; immediate ok > 0 constant case ok > : of ok 1+ ok >r ok postpone over postpone = ok postpone if ok postpone drop ok r> ; ok > immediate ok > : endof ok >r ok postpone else ok r> ; ok > immediate ok > : endcase ok postpone drop ok 0 ?do ok postpone then ok loop ; ok > immediate ok > : checkout ok case ok 0 of ." none" endof ok 1 of ." once" endof ok 2 of ." twice" endof ok ." unknown" ok endcase amforth 2.6 ATmega32 > ok > ; amforth 2.6 ATmega32 > Traceback (most recent call last): File "/home/ew/bin/amforth-upload.py", line 232, in ? main(sys.argv[1:]) File "/home/ew/bin/amforth-upload.py", line 228, in main write_file_flow(in_file,tty_dev) File "/home/ew/bin/amforth-upload.py", line 169, in write_file_flow write_line_flow(line,dest) File "/home/ew/bin/amforth-upload.py", line 121, in write_line_flow i = dest.read(1) KeyboardInterrupt $ |