Before he went to sleep I think he said something about it being 1000 times faster. Maybe it was 10,000 times? I'm not sure... *quickly ducks flying tomatoes*
A makefile is an input to the make utility - this utility can be configured to understand dependencies between source files, and allows you to specify rules about how to turn these files into programs. It is handy for building complex programs, but is unlikely to be much better for most Catalina programs than a simple batch file. I use both in Catalina - the main downside of batch files is that I have to write two versions of them - e.g. build_all.bat for Windows and build_all for Linux. With a makefile you can use the same file on both systems (usually with only very minor differences).
The make utility is pretty standard in Linux. For Windows you can install it as part of the MinGW/MSYS utilities - but it can take a while to learn to use it effectively - see http://www.gnu.org/software/make/manual/make.html for details.
This xbasic program looks to be a bit beyond me for the moment. The .cat file almost looks like another language to learn. I was hoping to get the keyboard bit working for David while he was asleep but this compilation looks immensely complicated.
A make file is like a batch file in that it contains the commands used to build your program. But it is much more in that it also contains rules to decide what is built.
Consider, if you have a C file that includes a header file (.h) you might like to have the C file recompiled if the header file changes but not otherwise. This can save a lot of recompile time on a large project with hundreds of files. The rules in the make file tell what depends on what and hence what should be recompiled or relinked when small changes are made.
A rule looks like
x : Y
command x y
where x depends on y and command makes an x from a y.
This xbasic program looks to be a bit beyond me for the moment. The .cat file almost looks like another language to learn. I was hoping to get the keyboard bit working for David while he was asleep but this compilation looks immensely complicated.
Is there any command line option I need to specify to get PS2 keyboard support? I'm currently just using -DDRACBLADE and -DHIRES_VGA. Should that be sufficient to get keyboard support?
Is there any command line option I need to specify to get PS2 keyboard support? I'm currently just using -DDRACBLADE and -DHIRES_VGA. Should that be sufficient to get keyboard support?
Yes - the keyboard support is built into the HIRES_VGA HMI.
How is the C3 flash support coming? Is there anything I can do to help with that?
It's a bit slow, but it's coming along. I had a bit of a hiccup today because I wasn't updating the cache when I wrote new data to the Flash chip - I couldn't figure out why the write didn't appear to be working. It finally dawned on me that it was working, but the previous Flash data had been cached - so I just kept re-reading that - D'oh!
Now I discard the Flash cache on any Flash erase or write operation.
Unfortunately, finding that took up a lot of the afternoon. Tomorrow I have some commitments, but I may get a chance to do some more. If there's anything you can help out with I'll let you know. I'm off to bed now!
It's a bit slow, but it's coming along. I had a bit of a hiccup today because I wasn't updating the cache when I wrote new data to the Flash chip - I couldn't figure out why the write didn't appear to be working. It finally dawned on me that it was working, but the previous Flash data had been cached - so I just kept re-reading that - D'oh!
Now I discard the Flash cache on any Flash erase or write operation.
Unfortunately, finding that took up a lot of the afternoon. Tomorrow I have some commitments, but I may get a chance to do some more. If there's anything you can help out with I'll let you know. I'm off to bed now!
Ross.
It seems like you're making the job harder than it has to be. In my zogload program I use a separate path into the cache driver to write the flash since the flash is only ever written during a download and never during the running of a program. Couldn't you just use that "write flash block" function and leave the flash cache code alone during a download? Also, I'm pretty sure that zogload is quite a bit faster than payload. I'm wondering how hard it would be to modify zogload to load Catalina programs.
It seems like I must have a fried Propeller chip. There isn't much in the PS2 circuit that could be bad. Only a few resistors and the jack itself.
As I said, there are only a few resistors and the jack itself. What could go wrong? Well, the resistors connecting the SCL and SDA lines to the Propeller were 1k instead of 100 ohm resistors. Replacing them with the correct values made the keyboard start working. I guess I need to be more careful in checking my parts before soldering them in!
It seems like you're making the job harder than it has to be. In my zogload program I use a separate path into the cache driver to write the flash since the flash is only ever written during a download and never during the running of a program. Couldn't you just use that "write flash block" function and leave the flash cache code alone during a download? Also, I'm pretty sure that zogload is quite a bit faster than payload. I'm wondering how hard it would be to modify zogload to load Catalina programs.
Quite possibly. My original intention was to do just what you suggest, but I changed my mind halfway through. The upside is that I now understand the caching driver much better than when I started - but the downside is that I haven't made as much progress as expected with the loader!
I know that payload can be speeded up - e.g. it's also significantly slower than the Parallax loader - but as long as it functions reliably, performance enhancements can wait. There's too much else to do!
Does zogload run on both Windows and Linux? That was my main design criteria for payload. If zogload does the same I may take a look at it and see if I can use it (or use its techniques to improve payload).
As I said, there are only a few resistors and the jack itself. What could go wrong? Well, the resistors connecting the SCL and SDA lines to the Propeller were 1k instead of 100 ohm resistors. Replacing them with the correct values made the keyboard start working. I guess I need to be more careful in checking my parts before soldering them in!
Glad you sorted it out.
Ross.
P.S. I guess you'd better put Heater out of his misery - is the Catalina version 10,000 times faster than the Zog version, or is it only 9,999 times faster?
Does zogload run on both Windows and Linux? That was my main design criteria for payload. If zogload does the same I may take a look at it and see if I can use it (or use its techniques to improve payload).
Yes, it runs under both Windows and Linux and could probably be made to run under Mac OS X as well. The code is a bit of a mess though. I added lots of stuff in a fairly short period of time. Also, zogload has "helper" programs like XMM.binary built into it so you don't have to keep track of those binary files separately. It currently has helpers for the C3, for Steve's SDRAM board and for Dracblade but more could be added. It uses CRC for error checking and on of the things I did to speed it up was to move the packet driver to PASM including the CRC code.
P.S. I guess you'd better put Heater out of his misery - is the Catalina version 10,000 times faster than the Zog version, or is it only 9,999 times faster?
I can't tell yet. I doubt it's that big a factor. I'm currently fighting with console I/O. I don't understand how getchar() works in Catalina. It seems like it buffers up a line before returning anything but it doesn't seem to allow line editing with backspace or delete. Also, the VGA output doesn't seem to handle the backspace character correctly. Instead of backing up the cursor it prints a funny triangle symbol.
I'm currently fighting with console I/O. I don't understand how getchar() works in Catalina. It seems like it buffers up a line before returning anything but it doesn't seem to allow line editing with backspace or delete. Also, the VGA output doesn't seem to handle the backspace character correctly. Instead of backing up the cursor it prints a funny triangle symbol.
Yes - such things are difficult. Their behaviour is platform dependent, and the Catalina driver doesn't handle them at all - you must intercept them and do so yourself. Also, you are using the streams library which adds another layer of complexity (since it does buffer characters).
Oh - so only 100 times faster? Heater will be pleased!
Yes - such things are difficult. Their behaviour is platform dependent, and the Catalina driver doesn't handle them at all - you must intercept them and do so yourself. Also, you are using the streams library which adds another layer of complexity (since it does buffer characters).
Ross.
So do you recommend that I just call the low level keyboard and VGA driver directly?
Thanks for the code. It looks like I have to handle the backspaces myself by using the t_setpos function. It seems like Catalina would be much easier to use if we made the interface between getchar and putchar smooth over all of the differences between the way the raw Propeller drivers work and the way a standard C program expects things to work. Can you give me some idea how the interface between your HMI functions and the standard C runtime library works? In ZOG, that interface is through the read and write functions where the file number argument is 0, 1, or 2. Does Catalina handle things the same way? I just added the code to my console_read and console_write functions to do the appropriate translations of character codes (like \n) and also to supply the line editing that is normally supplied by the Linux TTY driver. If you point me to where that code would go in Catalina I'll try to add it myself.
Thanks for the code. It looks like I have to handle the backspaces myself by using the t_setpos function. It seems like Catalina would be much easier to use if we made the interface between getchar and putchar smooth over all of the differences between the way the raw Propeller drivers work and the way a standard C program expects things to work. Can you give me some idea how the interface between your HMI functions and the standard C runtime library works? In ZOG, that interface is through the read and write functions where the file number argument is 0, 1, or 2. Does Catalina handle things the same way? I just added the code to my console_read and console_write functions to do the appropriate translations of character codes (like \n) and also to supply the line editing that is normally supplied by the Linux TTY driver. If you point me to where that code would go in Catalina I'll try to add it myself.
Thanks,
David
Yes, Catalina works the same way. All I/O to stdin, stdout & stderr (for devices 0, 1 & 2) go through catalina_getc() and catalina_putc() - which just call the appropriate low level HMI functions. These are "minimally compliant" implementations - i.e. they implement the functionality required to be there by the ANSI standard (such as the ability to push a character back to the input stream) and nothing more.
You can modify the catalina_getc and catalina_putc functions to suit your own needs and rebuild the libraries if you wish. The main problem with this approach is that any code that depends on particular behaviour by these functions may end up being platform dependent in a non-obvious way - and therefore harder to maintain and port. That's why an OS specific module (such as the one implemented in xvi) is often preferred - that way the parts of the code that are platform dependent are self-documenting and easy to port.
The terminal drivers are the correct place to handle things like backspace characters. I did add some special character handling - this is actually one of the reasons for having the HMI plugins (i.e. to make all the various terminal drivers behave identically) but I had to stop when I ran out of space and I never got back to it. I'll have a look at adding a trivial backspace handler - I imagine that's the one you most urgently need.
Yes, Catalina works the same way. All I/O to stdin, stdout & stderr (for devices 0, 1 & 2) go through catalina_getc() and catalina_putc() - which just call the appropriate low level HMI functions. These are "minimally compliant" implementations - i.e. they implement the functionality required to be there by the ANSI standard (such as the ability to push a character back to the input stream) and nothing more.
You can modify the catalina_getc and catalina_putc functions to suit your own needs and rebuild the libraries if you wish. The main problem with this approach is that any code that depends on particular behaviour by these functions may end up being platform dependent in a non-obvious way - and therefore harder to maintain and port. That's why an OS specific module (such as the one implemented in xvi) is often preferred - that way the parts of the code that are platform dependent are self-documenting and easy to port.
The terminal drivers are the correct place to handle things like backspace characters. I did add some special character handling - this is actually one of the reasons for having the HMI plugins (i.e. to make all the various terminal drivers behave identically) but I had to stop when I ran out of space and I never got back to it. I'll have a look at adding a trivial backspace handler - I imagine that's the one you most urgently need.
Ross.
I'm not sure I understand your comment about "end up being platform dependent". It seems like the opposite of what I'm suggesting. Programs ported from other systems assume a standard behavior for the console I/O functions at least when in "cooked" mode as Unix called it. All lines end in \n and input from stdin provides basic line editing. This would be the same on all platforms but the code to implement it might differ. I looked further into your plugins and I'm wondering why you chose to implement the higher level behavior like translating \n to \r\n in the PASM code. Wouldn't it be easier to implement that in the C part of the library and just let the PASM code handle the simple "put this character at this location" functions? I guess you'd want the PASM code to handle scrolling since it would probably be too slow in C but any character translation or line editing would be more easily handled in the C code I think.
By the way, thanks for mention the push back requirement. I had forgotten about that when I did the console input for ZOG. I'll have to look into adding that. Does ANSI really require more than one character of push back?
I'm not sure I understand your comment about "end up being platform dependent". It seems like the opposite of what I'm suggesting. Programs ported from other systems assume a standard behavior for the console I/O functions at least when in "cooked" mode as Unix called it. All lines end in \n and input from stdin provides basic line editing. This would be the same on all platforms but the code to implement it might differ. I looked further into your plugins and I'm wondering why you chose to implement the higher level behavior like translating \n to \r\n in the PASM code. Wouldn't it be easier to implement that in the C part of the library and just let the PASM code handle the simple "put this character at this location" functions? I guess you'd want the PASM code to handle scrolling since it would probably be too slow in C but any character translation or line editing would be more easily handled in the C code I think.
By the way, thanks for mention the push back requirement. I had forgotten about that when I did the console input for ZOG. I'll have to look into adding that. Does ANSI really require more than one character of push back?
For output processing, the only functionality you can count on in C is defined in section 2.2.2 of the ANSI spec ("Character display semantics"). It mentions "alert", "backspace", "form feed" "new line" "carriage return" "horizontal tab" and "vertical tab". You shouldn't count on anything else if you are trying to write portable C code.
On the input side, there is no requirement to support any line editing or control character processing at all - so this is always platform (and driver) dependent - anything you depend on here is definitely going to make your program non-portable. Unix attempts to provide an insulating layer (i.e. the termcap/ncurses terminal emulation libraries), and this is sometimes percieved to be a "standard" of sorts - but almost no non-Unix operating systems (including Windows) support this, so it is not really a useful standard outside the world of Unix. Most embedded platforms I have worked on provide nothing at all and you have to do it all yourself.
I implemented support for the required characters in the various HMI drivers as I needed them, but the only HMI plugin that currently implements them all is the PROPTERMINAL plugin (I can't remember why this is the case - maybe it was simply that I started with this one and then ran out of space on the others). I always intended to go back and tidy them up. At the very least (as I mentioned) I should add backspace support to all of them, since this is the one function that cannot be emulated in C for some terminal types (e.g. how do you do it for a PC HMI?).
The main reason I had to implement CR & LF translation at the driver level is that some of the HMI options implemented specific semantics which wasn't easy to change, so I tried to make all others do the same at the driver level so that I wouldn't have to know the terminal type in C (which violates the idea of having a Hardware Abstraction Layer). Maybe that was the wrong decision - I could just as easily have implemented a function that allowed you to query the HMI type, and then let you compensate yourself for different behaviour of the various options - this is more like what Unix does in its terminal emulation layer. I'll have a think about this - I suppose I could do both.
On the issue of "ungetc", C only requires one character - anything beyond that is platform dependent.
No idea what the flashing LEDs could mean. Maybe Dr_Acula might be able to offer some help tomorrow.
*in Maxwell Smart accent* Ah yes, the old flashing leds on the keyboard problem. Sounds like someone from Kaos has substituted the 100 ohm resistors with 1k resistors.
Instead of backing up the cursor it prints a funny triangle symbol.
I can confirm the same response with this BCX code
Line Input "Enter a string: ",Mystring$
which gets translated to this
printf("%s","Enter a string: ");
gets(Mystring);
There are workarounds. Kyedos has a very simple terminal program for both VGA and for a 20x4 LCD display that can handle CR, LF and Backspace. So reading in keys individually may be an option? Maybe port the VT100 spin code over to C?
*in Maxwell Smart accent* Ah yes, the old flashing leds on the keyboard problem. Sounds like someone from Kaos has substituted the 100 ohm resistors with 1k resistors.
That's the second time I've fallen for that this week!
Yes, and you can easily simulate a backspace for any given terminal type - but unfortunately you can't do it for all terminal types. That requires backspace to be implemented in the driver. Which I will do for the next release.
Comments
I'll try something simpler tomorrow. You may be stuck at work but I'm headed off to bed. :-)
By how much?
Is that with data/stack in HUB in both cases or what?
Before he went to sleep I think he said something about it being 1000 times faster. Maybe it was 10,000 times? I'm not sure... *quickly ducks flying tomatoes*
Can you please explain how the makefile.cat works?
I compile programs with this batch file:
What do I do with the makefile.cat?
Hi Dr_A,
A makefile is an input to the make utility - this utility can be configured to understand dependencies between source files, and allows you to specify rules about how to turn these files into programs. It is handy for building complex programs, but is unlikely to be much better for most Catalina programs than a simple batch file. I use both in Catalina - the main downside of batch files is that I have to write two versions of them - e.g. build_all.bat for Windows and build_all for Linux. With a makefile you can use the same file on both systems (usually with only very minor differences).
The make utility is pretty standard in Linux. For Windows you can install it as part of the MinGW/MSYS utilities - but it can take a while to learn to use it effectively - see http://www.gnu.org/software/make/manual/make.html for details.
Ross.
This xbasic program looks to be a bit beyond me for the moment. The .cat file almost looks like another language to learn. I was hoping to get the keyboard bit working for David while he was asleep but this compilation looks immensely complicated.
I presume it won't compile with this
Consider, if you have a C file that includes a header file (.h) you might like to have the C file recompiled if the header file changes but not otherwise. This can save a lot of recompile time on a large project with hundreds of files. The rules in the make file tell what depends on what and hence what should be recompiled or relinked when small changes are made.
A rule looks like
x : Y command x ywhere x depends on y and command makes an x from a y.
N.B. The indentation in a rule must be a tab.
No, that won't do it. But David's problem is hardware-related - my PS/2 keyboard works fine with xbasic on the DRACBLADE.
Ross.
Can you try another keyboard? - some PS2 keyboards are known to have timing issues.
Ross.
I just tried a different PS2 keyboard and it doesn't work either but it does exhibit an odd behavior. All of the LEDs flash on and off constantly.
Yes - the keyboard support is built into the HIRES_VGA HMI.
No idea what the flashing LEDs could mean. Maybe Dr_Acula might be able to offer some help tomorrow.
Ross.
Now I discard the Flash cache on any Flash erase or write operation.
Unfortunately, finding that took up a lot of the afternoon. Tomorrow I have some commitments, but I may get a chance to do some more. If there's anything you can help out with I'll let you know. I'm off to bed now!
Ross.
It seems like you're making the job harder than it has to be. In my zogload program I use a separate path into the cache driver to write the flash since the flash is only ever written during a download and never during the running of a program. Couldn't you just use that "write flash block" function and leave the flash cache code alone during a download? Also, I'm pretty sure that zogload is quite a bit faster than payload. I'm wondering how hard it would be to modify zogload to load Catalina programs.
Quite possibly. My original intention was to do just what you suggest, but I changed my mind halfway through. The upside is that I now understand the caching driver much better than when I started - but the downside is that I haven't made as much progress as expected with the loader!
I know that payload can be speeded up - e.g. it's also significantly slower than the Parallax loader - but as long as it functions reliably, performance enhancements can wait. There's too much else to do!
Does zogload run on both Windows and Linux? That was my main design criteria for payload. If zogload does the same I may take a look at it and see if I can use it (or use its techniques to improve payload).
Ross.
Glad you sorted it out.
Ross.
P.S. I guess you'd better put Heater out of his misery - is the Catalina version 10,000 times faster than the Zog version, or is it only 9,999 times faster?
Oh - so only 100 times faster? Heater will be pleased!
Yes - such things are difficult. Their behaviour is platform dependent, and the Catalina driver doesn't handle them at all - you must intercept them and do so yourself. Also, you are using the streams library which adds another layer of complexity (since it does buffer characters).
Ross.
So do you recommend that I just call the low level keyboard and VGA driver directly?
I don't know what you need - but if you want terminal capabilities, then you may have to.
I have attached the I/O module I wrote for the xvi editor (this is also available in the Catalyst source tree of release 2.9). This might help.
Ross.
Thanks,
David
Yes, Catalina works the same way. All I/O to stdin, stdout & stderr (for devices 0, 1 & 2) go through catalina_getc() and catalina_putc() - which just call the appropriate low level HMI functions. These are "minimally compliant" implementations - i.e. they implement the functionality required to be there by the ANSI standard (such as the ability to push a character back to the input stream) and nothing more.
You can modify the catalina_getc and catalina_putc functions to suit your own needs and rebuild the libraries if you wish. The main problem with this approach is that any code that depends on particular behaviour by these functions may end up being platform dependent in a non-obvious way - and therefore harder to maintain and port. That's why an OS specific module (such as the one implemented in xvi) is often preferred - that way the parts of the code that are platform dependent are self-documenting and easy to port.
The terminal drivers are the correct place to handle things like backspace characters. I did add some special character handling - this is actually one of the reasons for having the HMI plugins (i.e. to make all the various terminal drivers behave identically) but I had to stop when I ran out of space and I never got back to it. I'll have a look at adding a trivial backspace handler - I imagine that's the one you most urgently need.
Ross.
I'm not sure I understand your comment about "end up being platform dependent". It seems like the opposite of what I'm suggesting. Programs ported from other systems assume a standard behavior for the console I/O functions at least when in "cooked" mode as Unix called it. All lines end in \n and input from stdin provides basic line editing. This would be the same on all platforms but the code to implement it might differ. I looked further into your plugins and I'm wondering why you chose to implement the higher level behavior like translating \n to \r\n in the PASM code. Wouldn't it be easier to implement that in the C part of the library and just let the PASM code handle the simple "put this character at this location" functions? I guess you'd want the PASM code to handle scrolling since it would probably be too slow in C but any character translation or line editing would be more easily handled in the C code I think.
By the way, thanks for mention the push back requirement. I had forgotten about that when I did the console input for ZOG. I'll have to look into adding that. Does ANSI really require more than one character of push back?
For output processing, the only functionality you can count on in C is defined in section 2.2.2 of the ANSI spec ("Character display semantics"). It mentions "alert", "backspace", "form feed" "new line" "carriage return" "horizontal tab" and "vertical tab". You shouldn't count on anything else if you are trying to write portable C code.
On the input side, there is no requirement to support any line editing or control character processing at all - so this is always platform (and driver) dependent - anything you depend on here is definitely going to make your program non-portable. Unix attempts to provide an insulating layer (i.e. the termcap/ncurses terminal emulation libraries), and this is sometimes percieved to be a "standard" of sorts - but almost no non-Unix operating systems (including Windows) support this, so it is not really a useful standard outside the world of Unix. Most embedded platforms I have worked on provide nothing at all and you have to do it all yourself.
I implemented support for the required characters in the various HMI drivers as I needed them, but the only HMI plugin that currently implements them all is the PROPTERMINAL plugin (I can't remember why this is the case - maybe it was simply that I started with this one and then ran out of space on the others). I always intended to go back and tidy them up. At the very least (as I mentioned) I should add backspace support to all of them, since this is the one function that cannot be emulated in C for some terminal types (e.g. how do you do it for a PC HMI?).
The main reason I had to implement CR & LF translation at the driver level is that some of the HMI options implemented specific semantics which wasn't easy to change, so I tried to make all others do the same at the driver level so that I wouldn't have to know the terminal type in C (which violates the idea of having a Hardware Abstraction Layer). Maybe that was the wrong decision - I could just as easily have implemented a function that allowed you to query the HMI type, and then let you compensate yourself for different behaviour of the various options - this is more like what Unix does in its terminal emulation layer. I'll have a think about this - I suppose I could do both.
On the issue of "ungetc", C only requires one character - anything beyond that is platform dependent.
Ross.
*in Maxwell Smart accent* Ah yes, the old flashing leds on the keyboard problem. Sounds like someone from Kaos has substituted the 100 ohm resistors with 1k resistors.
I can confirm the same response with this BCX code
which gets translated to this
printf("%s","Enter a string: "); gets(Mystring);There are workarounds. Kyedos has a very simple terminal program for both VGA and for a 20x4 LCD display that can handle CR, LF and Backspace. So reading in keys individually may be an option? Maybe port the VT100 spin code over to C?
Yes, and you can easily simulate a backspace for any given terminal type - but unfortunately you can't do it for all terminal types. That requires backspace to be implemented in the driver. Which I will do for the next release.
Ross.