Zog needs: 1. Access to COG special registers by name (DIRA, etc...) and 2. Delay functions.
I propose these be a part of the propeller library since they would be common to all platforms. zog.spin defines COG register base address access as $10008000 (Heater, I was hoping we could move this so zog can read the ROM tables).
In any event, we can add register names by address in propeller.h for example:
While I appreciate your enthusiasm for linker scripts, they are typically only used for things like code and data segments. I'm not sure how others feel about using linker scripts, but normally that is the very last place I want to go to add a feature.
I figured that GCC might generate better code for direct memory references rather than indirect references through constant pointers. That may not be true though. I put stuff in my linker script because I had to have a custom script to handle placing code in flash memory. I guess I could have done that with a command line switch to the linker though. Maybe I'll try that next.
I figured that GCC might generate better code for direct memory references rather than indirect references through constant pointers. That may not be true though. I put stuff in my linker script because I had to have a custom script to handle placing code in flash memory. I guess I could have done that with a command line switch to the linker though. Maybe I'll try that next.
I understand David. If performance improvements are significant, then that justifies a closer look. It's just that every linker script I've ever seen is "set and forget" ... maybe that's why they're so mysterious. I was amazed that ZOG's original linker script had more than 20 lines.
I wonder if it is possible to have multiple linker scripts built into zpu-elf-gcc and selected by a command line option? It would be nice to not have to explicitly include one every time I link a program for the C3. Also, that would mean that it wouldn't be so important how long it was since it would be hidden by gcc.
I wonder if it is possible to have multiple linker scripts built into zpu-elf-gcc and selected by a command line option?
You can always change the makefile to use an explicit linker command after compiling.
Also -T <script> seems to be available in zpu-elf-gcc.
-T script
Use script as the linker script. This option is supported by most systems
using the GNU linker. On some targets, such as bare-board targets without an
operating system, the -T option may be required when linking to avoid
references to undefined symbols.
Yeah, I know you can select an alternate linker script with a command line option. I guess I'm always trying to make things easier. I'd like the script to be built into gcc so I don't have to keep track of the script file along with my source code. The script doesn't change. It is the same for every program I write for the C3 so it seems like it should be in some common place rather than having to be maintained with the program source code.
The script doesn't change. It is the same for every program I write for the C3 so it seems like it should be in some common place rather than having to be maintained with the program source code.
This confuses me badly. If you don't need a TV driver for example in your current setup would your linker script still have the TV data structure allocated in the linker?
The linker script doesn't have any information about which drivers are loaded. It just describes the memory layout of the processor on which the program is running. This includes where the RAM is and where the flash is as well as where the hub and COG memory are located. The only thing I added to that is where the registers are located in COG memory. Those should all be common to any program that runs on the C3 and most are common to any ZOG program regardless of platform. The only thing that should change is the layout of external memory. In the case of SdramCache, that is 32mb starting at location zero. In the case of the C3, it is 64kb of RAM starting at zero and 1mb of flash starting at 0x00100000. Maybe we could even adopt a common memory map for all ZOG programs where some parts might be missing for some platforms (flash for instance).
The linker script doesn't have any information about which drivers are loaded.
I misunderstood. Sorry about that.
Yes, I would like to have a common code base.
Here are some things to consider for a common code base:
In propeller.h:
1) serial_driver is not always common.
2) 8192 fixed size for cache/vm is too big in some cases.
3) To add more drivers, more things get defined - #ifdef soup.
4) how does one resolve change difference conflicts in a common code base with that?
The propeller.h #defines really belong in a different header file like platform.h.
It seems the propeller library should be for propeller only things.
The way to handle different platforms in linux/cygwin is to use symbolic links:
make c3 - links c3_platform.h to include/platform.h
make sdram - links sdram_platform.h to include/platform.h
make triblade - links triblade_platform.h to include/platform.h
make morph - links morph_platform.h to include/platform.h
make userplatform ... ad nauseum.
It occured to me that ZOG today can't really serve windows users without cygwin or mingw.
This seems to be a problem. Catalina seems to fill this void.
I'm now convinced your static allocation approach is the way to go. The main reason I believe this is that any dynamic allocation will waste memory, and we don't have that luxury with Propeller's 32K HUB. Let's see if we can combine resources into one source tree.
1) serial_driver is not always common.
2) 8192 fixed size for cache/vm is too big in some cases.
3) To add more drivers, more things get defined - #ifdef soup.
4) how does one resolve change difference conflicts in a common code base with that?
My idea was to have a statically allocated 128 byte structure at the top of hub memory. This would contain the VM mailbox as well as the sizes of the other sections. That should allow the runtime to find those structures dynamically rather than relying on fixed defines like I'm currently using for my 8k cache. The only reason I put the serial structure in that upper 128 bytes is that there was room left there. It could just as easily be placed using the hub memory section statically.
The propeller.h #defines really belong in a different header file like platform.h.
It seems the propeller library should be for propeller only things.
I agree with that.
The way to handle different platforms in linux/cygwin is to use symbolic links:
make c3 - links c3_platform.h to include/platform.h
make sdram - links sdram_platform.h to include/platform.h
make triblade - links triblade_platform.h to include/platform.h
make morph - links morph_platform.h to include/platform.h
make userplatform ... ad nauseum.
This forces the use of more GNU tools. I was kind of hoping it would be possible to just use the stuff that is in the zpu bin directory from a standard Windows command window and possibly using batch files. I think there are people who won't be comfortable using a Unix-like shell.
It occured to me that ZOG today can't really serve windows users without cygwin or mingw.
This seems to be a problem. Catalina seems to fill this void.
I used the zpu tools without cygwin when I first installed them. I made a few .BAT files to run the compiler and linker. I think all you really need is the cygwin DLL.
It's just as easy to copy a file as using symbolic links - the problem is in managing change.
I suppose that is true.
Using make is efficient when properly implemented and is not just a GNU thing.
Surely a generic windows make program still exists.
I like make and use it myself. I've just met resistence from people who use my programs. To be honest, the same people usually don't like any command line tools and want some sort of GUI.
Can you describe your ideas on a more generic directory structure?
I prefer separate bin, lib, demo or test, spin, tools, and include.
I've already setup my environment with bin, lib, and include. For the moment, I've placed the spin files in with the C code that uses them. I also have a 'c3load' directory with my loader code (still not completely working).
Finally got my C3 loader working so I guess I'm ready to try to work out the details for a common code base. Unfortunately, a different linker script will be needed for code running from RAM (code starts at location $00000000) and code running from flash (code currently starting at $00100000). I'm willing to move the flash code base address to somewhere else if necessary to achieve a common memory map but the linker script will have to know to place the .text section in flash rather than in RAM. I guess we could have a separate linker script for each memory configuration. Unfortunately, none of has all of the platforms as far as I know. I know I don't have anything other than the C3 and my hacked Hydra. This should be made to work on jazzed's SDRAM board and on Bill Henning's various boards (Morpheus and PropCade at least). I guess we'll have to find testers that have these boards to verify that a unified memory model is really going to work on all of the platforms. Any idea how we should start this project?
It makes sense for platform specific directories to be used for build management and binaries.
The demo or test application source directories can still be kept.
I would like to see all the common stuff in one place though instead of scattered in each application's make.
Why don't you write up a paper describing your ideas for a non-make based build system, and contributors can review/provide feedback.
I can see using batch scripts on Windows and shell scripts on Linux. Using make would be soooo much easier though. The problem is that trying to support lots of platforms even with make can spawn an eventual nightmare that your friend who despises make won't have to maintain.
Why don't you write up a paper describing your ideas for a non-make based build system, and contributors can review/provide feedback.
I can see using batch scripts on Windows and shell scripts on Linux. Using make would be soooo much easier though. The problem is that trying to support lots of platforms even with make can spawn an eventual nightmare that your friend who despises make won't have to maintain.
I don't think it is necessary to eliminate make for all builds. I just think there should be a fairly simple option for those who just want to compile a C program with one or a handful of source files that doesn't require using make. The compiler and the libraries should certainly use make. Any novice user won't be rebuilding the compiler or libraries.
I don't think it is necessary to eliminate make for all builds. I just think there should be a fairly simple option for those who just want to compile a C program ....
Ok, lets go with makefiles, etc... (and maybe a build/install script) for platform/library stuff, and batch/shell scripts only for application demos. If someone needs a new library, they can ask for one or build it themselves based on examples. I have another ZOG demo to do before migrating to a new tree.
There is exactly 1 all-in-one SDRAM TV board on GadgetGangster right now if you want it.
Thanks for letting me know but it looks like I missed it. The GadgetGangster site says it is sold out again. In any case, I think I've exhausted my Propeller board buying budget for the near term. I guess you'll probably handle testing on the SDRAM platform for now anyway.
jazzed: have you changed the mailbox interface that your cache driver uses? I'm wondering if my C3 loader program would work just as well with your SDRAM board as long as the SPI flash download option isn't used.
jazzed: have you changed the mailbox interface that your cache driver uses? I'm wondering if my C3 loader program would work just as well with your SDRAM board as long as the SPI flash download option isn't used.
I haven't changed the cache interface API in a while since we discussed the read command bit.
A command is non-zero (bit 1 = 1), and read is flagged with bit 0 = 1.
Are you loading straight to external memory? That would save on wear leveling
Shoot me some code and I'll test it.
The SDRAM all-in-one board is still available as far as I can tell.
jazzed: I just took a look at your loader and I guess I took another approach. Your loader seems just to provide a way to write files to the SD card from the PC. I've bundled that with the ability to run the programs as well. My loader can:
1) Write a file from the PC to the SD card
2) Write a file from the PC to the flash (on the C3)
3) Write a file from the PC to RAM (SPI SRAM on the C3, SDRAM on your board, etc. )
4) Load an SD card file into flash (on the C3)
5) Load an SD card file into RAM (SPI SRAM on the C3, SDRAM on your board, etc.)
6) Run the program currently loaded into flash (on the C3)
7) Run the program currently loaded into RAM (SPI SRAM on the C3, SDRAM on your board, etc.)
It has a built-in Spin helper program for the C3. Helper programs could be added for other platforms as necessary and selected by some sort of command line switch.
It can also load into either hub memory or EEPROM any xxx.binary program you want to use as a helper program. Of course that program has to support my download protocol.
The result is that you can write 'hello.zbn' to the SD card, load it into flash, and run it on the C3 using this command:
c3load -p12 -ws hello.zbn -lf -r
Just loading a program into RAM and running it could be done like this:
c3load -p12 -wr hello.zbn -r
I had a simple terminal emulator built in (command line switch -t) but it only works when I compile with Visual C++ Express since it uses the conio.h functions _kbhit, etc and those don't seem to be available in cygwin. Otherwise, it will compile and run under cygwin as well.
Also, if you tell me what pin is used for video on your SDRAM/Propeller Platform system I'll add a helper program that should work with SdramCache. I'm using TvText to display progress messages on the TV while a program is loading. I could comment that out if you don't think it's a good idea to assume a TV is available. I mostly did it for debugging purposes.
Also, if you tell me what pin is used for video on your SDRAM/Propeller Platform system I'll add a helper program that should work with SdramCache. I'm using TvText to display progress messages on the TV while a program is loading. I could comment that out if you don't think it's a good idea to assume a TV is available. I mostly did it for debugging purposes.
The SDRAM all-in-one board TV DAC starts on P20. The SDcard starts on P16. Are you using userdefs.spin for your SPIN helper loader?
Short term, it's OK to leave TvText there. Longer term, devices used should be configured for the target platform by the build. Even assuming cache is used may not be safe because for LMM or maybe some parallel SRAM solutions, a cache could be optional. As long as there is a platform infrastructure, it doesn't matter what is included longer term.
The next board with SDRAM will use a special driver for video to communicate with a separate Propeller-VGA controller. Of course the only board available now that can be used with ZOG practically is the all-in-one board with TV. This will change shortly.
The conion module will work with the console on Linux/Cygwin. I guess the #ifdef LINUX should read #ifndef WIN32.
I used userdefs.spin for everything except the TV pins. I wasn't sure if I should add those to userdefs.spin because it is a part of the standard ZOG distribution and that doesn't require the TV pin definitions.
The TV driver is only used for the loader helper program. That COG is shut down before the C program is started. The only driver that continues to run when ZOG is started is the VM driver so there should be six free COGs when ZOG is running. I guess if there was a parallel SRAM platform (like RamBlade maybe) then the VM COG would also not be used and there would be seven free COGs.
Thanks for the conion code. I'll integrate it with my loader to enable my dumb terminal mode under cygwin. This should run under Linux too but I don't currently have a Linux system setup to test with.
Yes. userdefs.spin has minimal info in it and should probably stay that way. It's nice to have a single place to go for setting clock, etc....
The biggest concern I have with having TV in a generic loader is that I've seen my SDCARD get totally wiped out with TV signals on P16.... I was quite annoyed that day. Maybe timeshare loader with serial IO is better.
Well, if I put in a special helper program for your SDRAM card then it will use the correct pin for TV. I suppose it will only work with the TV variants of your board though. The bare SDRAM card or the one with VGA output won't work. I can certainly look into sending the logging output back over the serial connection along with the ACK/NAK characters that are currently sent to acknowledge transfer packets. Obviously, the serial port has to work since that is what is being used for the downloads.
Comments
I propose these be a part of the propeller library since they would be common to all platforms. zog.spin defines COG register base address access as $10008000 (Heater, I was hoping we could move this so zog can read the ROM tables).
In any event, we can add register names by address in propeller.h for example:
#define COGregBase 0x10008000 /** * define cog registers for C. * since registers are 32 bits, we have to shift them */ enum COGregAddrs_en { _PAR = COGregBase + (0x1f0<<2), _CNT = COGregBase + (0x1f1<<2), _INA = COGregBase + (0x1f2<<2), _INB = COGregBase + (0x1f3<<2), _OUTA = COGregBase + (0x1f4<<2), _OUTB = COGregBase + (0x1f5<<2), _DIRA = COGregBase + (0x1f6<<2), _DIRB = COGregBase + (0x1f7<<2), _CTRA = COGregBase + (0x1f8<<2), _CTRB = COGregBase + (0x1f9<<2), _FRQA = COGregBase + (0x1fa<<2), _FRQB = COGregBase + (0x1fb<<2), _PHSA = COGregBase + (0x1fc<<2), _PHSB = COGregBase + (0x1fd<<2), _VCFG = COGregBase + (0x1fe<<2), _VSCL = COGregBase + (0x1ff<<2) }; #define PAR (*(uint32_t*)_PAR) #define CNT (*(uint32_t*)_CNT) #define INA (*(uint32_t*)_INA) #define INB (*(uint32_t*)_INB) #define OUTA (*(uint32_t*)_OUTA) #define OUTB (*(uint32_t*)_OUTB) #define DIRA (*(uint32_t*)_DIRA) #define DIRB (*(uint32_t*)_DIRB) #define FRQA (*(uint32_t*)_FRQA) #define FRQB (*(uint32_t*)_FRQB) #define PHSA (*(uint32_t*)_PHSA) #define PHSB (*(uint32_t*)_PHSB) #define VCFG (*(uint32_t*)_VCFG) #define VSCL (*(uint32_t*)_VSCL) #define CLKFREQ (*(uint32_t*) 0x10000000)Delay functions can be implemented as:
/* * gclkperiod is in ns with 1ns precision */ static int gclkperiod = 0; static inline int clkperiod(void) { if(gclkperiod) return gclkperiod; if(!CLKFREQ) return 0; // oops, someone wrote 0 to clkfreq! gclkperiod = 1000000/(CLKFREQ/1000); return gclkperiod; } void msleep(int ms) { int target; int period = clkperiod(); if(!period) return; // oops, someone wrote 0 to clkfreq! target = period*ms*1000; target+= CNT; while(CNT < target) ; } void sleep(int sec) { while(--sec > -1) msleep(1000); }It's been my experience that any microsecond sleep function takes more that 1us on Propeller (except for PASM). Hopefully msleep is actually useful
Code compiles, but is not tested yet.
OUTPUT_FORMAT("elf32-zpu", "elf32-zpu", "elf32-zpu") OUTPUT_ARCH(zpu) SEARCH_DIR(.); ENTRY(_start) SEARCH_DIR("/home/dbetz/zpugcc/toolchain/build/../install/zpu-elf/lib"); RAMSIZE = 64 * 1024; ROMSIZE = 1 * 1024 * 1024; MEMORY { ram : ORIGIN = 0x00000000, LENGTH = 64K rom : ORIGIN = 0x00100000, LENGTH = 1M hub : ORIGIN = 0x10000000, LENGTH = 64K cog : ORIGIN = 0x10008000, LENGTH = 2K-64 par_reg : ORIGIN = 0x100087c0, LENGTH = 4 cnt_reg : ORIGIN = 0x100087c4, LENGTH = 4 ina_reg : ORIGIN = 0x100087c8, LENGTH = 4 inb_reg : ORIGIN = 0x100087cc, LENGTH = 4 outa_reg : ORIGIN = 0x100087d0, LENGTH = 4 outb_reg : ORIGIN = 0x100087d4, LENGTH = 4 dira_reg : ORIGIN = 0x100087d8, LENGTH = 4 dirb_reg : ORIGIN = 0x100087dc, LENGTH = 4 ctra_reg : ORIGIN = 0x100087e0, LENGTH = 4 ctrb_reg : ORIGIN = 0x100087e4, LENGTH = 4 frqa_reg : ORIGIN = 0x100087e8, LENGTH = 4 frqb_reg : ORIGIN = 0x100087ec, LENGTH = 4 phsa_reg : ORIGIN = 0x100087f0, LENGTH = 4 phsb_reg : ORIGIN = 0x100087f4, LENGTH = 4 vcfg_reg : ORIGIN = 0x100087f8, LENGTH = 4 vscl_reg : ORIGIN = 0x100087fc, LENGTH = 4 io : ORIGIN = 0x10008800, LENGTH = 1K } SECTIONS { .text : { LONG(_start) LONG(_data_image) LONG(_data_start) LONG(_data_end) LONG(_bss_start) LONG(_bss_end) KEEP(*(.fixed_vectors)) KEEP(*(.init)) *(.text) *(.text.*) KEEP(*(.fini)) *(.rodata) *(.rodata.*) . = ALIGN(4); _data_image = .; } >rom .data : { _data_start = .; PROVIDE(_memreg = .); LONG(0) LONG(0) LONG(0) LONG(0) *(.data) *(.data.*) . = ALIGN(4); } >ram AT>rom .ctors : { ___ctors = .; KEEP (*crtbegin*.o(.ctors)) KEEP (*(EXCLUDE_FILE (*crtend*.o ) .ctors)) KEEP (*(SORT(.ctors.*))) KEEP (*(.ctors)) ___ctors_end = .; } >ram AT>rom .dtors : { ___dtors = .; KEEP (*crtbegin*.o(.dtors)) KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors)) KEEP (*(SORT(.dtors.*))) KEEP (*(.dtors)) ___dtors_end = .; _data_end = .; } >ram AT>rom .bss : { _bss_start = .; *(.bss) *(.bss.*) . = ALIGN(4); _bss_end = .; _end = .; } >ram .stack RAMSIZE - 0x1000 : { _stack = .; *(.stack) } >ram .hub : { _hub_start = .; *(.clkfreq) *(.hub) _hub_end = .; } >hub .cog : { *(.cog) } >cog .par_reg : { *(.par_reg) } >par_reg .cnt_reg : { *(.cnt_reg) } >cnt_reg .ina_reg : { *(.ina_reg) } >ina_reg .inb_reg : { *(.inb_reg) } >inb_reg .outa_reg : { *(.outa_reg) } >outa_reg .outb_reg : { *(.outb_reg) } >outb_reg .dira_reg : { *(.dira_reg) } >dira_reg .dirb_reg : { *(.dirb_reg) } >dirb_reg .ctra_reg : { *(.ctra_reg) } >ctra_reg .ctrb_reg : { *(.ctrb_reg) } >ctrb_reg .frqa_reg : { *(.frqa_reg) } >frqa_reg .frqb_reg : { *(.frqb_reg) } >frqb_reg .phsa_reg : { *(.phsa_reg) } >phsa_reg .phsb_reg : { *(.phsb_reg) } >phsb_reg .vcfg_reg : { *(.vcfg_reg) } >vcfg_reg .vscl_reg : { *(.vscl_reg) } >vscl_reg .io : { *(.io) } >io }They are declared in propeller.c.volatile __attribute__ ((section(".clkfreq"))) uint32_t CLKFREQ; volatile __attribute__ ((section(".par_reg"))) uint32_t PAR; volatile __attribute__ ((section(".cnt_reg"))) uint32_t CNT; volatile __attribute__ ((section(".ina_reg"))) uint32_t INA; volatile __attribute__ ((section(".inb_reg"))) uint32_t INB; volatile __attribute__ ((section(".outa_reg"))) uint32_t OUTA; volatile __attribute__ ((section(".outb_reg"))) uint32_t OUTB; volatile __attribute__ ((section(".dira_reg"))) uint32_t DIRA; volatile __attribute__ ((section(".dirb_reg"))) uint32_t DIRB; volatile __attribute__ ((section(".ctra_reg"))) uint32_t CTRA; volatile __attribute__ ((section(".ctrb_reg"))) uint32_t CTRB; volatile __attribute__ ((section(".frqa_reg"))) uint32_t FRQA; volatile __attribute__ ((section(".frqb_reg"))) uint32_t FRQB; volatile __attribute__ ((section(".phsa_reg"))) uint32_t PHSA; volatile __attribute__ ((section(".phsb_reg"))) uint32_t PHSB; volatile __attribute__ ((section(".vcfg_reg"))) uint32_t VCFG; volatile __attribute__ ((section(".vscl_reg"))) uint32_t VSCL;I then added extern definitions of them to the propeller.h file.While I appreciate your enthusiasm for linker scripts, they are typically only used for things like code and data segments. I'm not sure how others feel about using linker scripts, but normally that is the very last place I want to go to add a feature.
Sincerely,
--Steve
Also -T <script> seems to be available in zpu-elf-gcc.
-T script Use script as the linker script. This option is supported by most systems using the GNU linker. On some targets, such as bare-board targets without an operating system, the -T option may be required when linking to avoid references to undefined symbols.Yes, I would like to have a common code base.
Here are some things to consider for a common code base:
In propeller.h:
1) serial_driver is not always common.
2) 8192 fixed size for cache/vm is too big in some cases.
3) To add more drivers, more things get defined - #ifdef soup.
4) how does one resolve change difference conflicts in a common code base with that?
The propeller.h #defines really belong in a different header file like platform.h.
It seems the propeller library should be for propeller only things.
The way to handle different platforms in linux/cygwin is to use symbolic links:
make c3 - links c3_platform.h to include/platform.h
make sdram - links sdram_platform.h to include/platform.h
make triblade - links triblade_platform.h to include/platform.h
make morph - links morph_platform.h to include/platform.h
make userplatform ... ad nauseum.
It occured to me that ZOG today can't really serve windows users without cygwin or mingw.
This seems to be a problem. Catalina seems to fill this void.
I'm now convinced your static allocation approach is the way to go. The main reason I believe this is that any dynamic allocation will waste memory, and we don't have that luxury with Propeller's 32K HUB. Let's see if we can combine resources into one source tree.
I agree with that. This forces the use of more GNU tools. I was kind of hoping it would be possible to just use the stuff that is in the zpu bin directory from a standard Windows command window and possibly using batch files. I think there are people who won't be comfortable using a Unix-like shell. I used the zpu tools without cygwin when I first installed them. I made a few .BAT files to run the compiler and linker. I think all you really need is the cygwin DLL.
Using make is efficient when properly implemented and is not just a GNU thing.
Surely a generic windows make program still exists.
Can you describe your ideas on a more generic directory structure?
I prefer separate bin, lib, demo or test, spin, tools, and include.
There is nothing wrong with having a separate linker file per platform. It can get complicated without make though. An IDE can hide make
There is exactly 1 all-in-one SDRAM TV board on GadgetGangster right now if you want it.
I'll be getting a C3 for general purpose hacking and add-on development.
I'm supposed to have a PropCade coming. My Morpheus PCB is bare.
Surely Bill would want to test on Morpheus. Same for other platform providers no?
All we need is commitment
It makes sense for platform specific directories to be used for build management and binaries.
The demo or test application source directories can still be kept.
I would like to see all the common stuff in one place though instead of scattered in each application's make.
Why don't you write up a paper describing your ideas for a non-make based build system, and contributors can review/provide feedback.
I can see using batch scripts on Windows and shell scripts on Linux. Using make would be soooo much easier though. The problem is that trying to support lots of platforms even with make can spawn an eventual nightmare that your friend who despises make won't have to maintain.
I haven't changed the cache interface API in a while since we discussed the read command bit.
A command is non-zero (bit 1 = 1), and read is flagged with bit 0 = 1.
Are you loading straight to external memory? That would save on wear leveling
Shoot me some code and I'll test it.
The SDRAM all-in-one board is still available as far as I can tell.
1) Write a file from the PC to the SD card
2) Write a file from the PC to the flash (on the C3)
3) Write a file from the PC to RAM (SPI SRAM on the C3, SDRAM on your board, etc. )
4) Load an SD card file into flash (on the C3)
5) Load an SD card file into RAM (SPI SRAM on the C3, SDRAM on your board, etc.)
6) Run the program currently loaded into flash (on the C3)
7) Run the program currently loaded into RAM (SPI SRAM on the C3, SDRAM on your board, etc.)
It has a built-in Spin helper program for the C3. Helper programs could be added for other platforms as necessary and selected by some sort of command line switch.
It can also load into either hub memory or EEPROM any xxx.binary program you want to use as a helper program. Of course that program has to support my download protocol.
The result is that you can write 'hello.zbn' to the SD card, load it into flash, and run it on the C3 using this command: Just loading a program into RAM and running it could be done like this: I had a simple terminal emulator built in (command line switch -t) but it only works when I compile with Visual C++ Express since it uses the conio.h functions _kbhit, etc and those don't seem to be available in cygwin. Otherwise, it will compile and run under cygwin as well.
As far as conio goes, I made a module called "conion" for David's SpinSimulator which emulates kbhit and getch. See attached.
The SDRAM all-in-one board TV DAC starts on P20. The SDcard starts on P16. Are you using userdefs.spin for your SPIN helper loader?
Short term, it's OK to leave TvText there. Longer term, devices used should be configured for the target platform by the build. Even assuming cache is used may not be safe because for LMM or maybe some parallel SRAM solutions, a cache could be optional. As long as there is a platform infrastructure, it doesn't matter what is included longer term.
The next board with SDRAM will use a special driver for video to communicate with a separate Propeller-VGA controller. Of course the only board available now that can be used with ZOG practically is the all-in-one board with TV. This will change shortly.
The conion module will work with the console on Linux/Cygwin. I guess the #ifdef LINUX should read #ifndef WIN32.
The TV driver is only used for the loader helper program. That COG is shut down before the C program is started. The only driver that continues to run when ZOG is started is the VM driver so there should be six free COGs when ZOG is running. I guess if there was a parallel SRAM platform (like RamBlade maybe) then the VM COG would also not be used and there would be seven free COGs.
Thanks for the conion code. I'll integrate it with my loader to enable my dumb terminal mode under cygwin. This should run under Linux too but I don't currently have a Linux system setup to test with.
The biggest concern I have with having TV in a generic loader is that I've seen my SDCARD get totally wiped out with TV signals on P16.... I was quite annoyed that day. Maybe timeshare loader with serial IO is better.