VMCOG runs nice only on PropCade - and ZOG on VMCOG is coming along nicely! Running Java and CP/M hopefully will also be possible in the near future.
I should have the revised prototype PCB's within a couple of days. The only difference is a slightly larger form factor (6.6" wide) needed to accommodate the second RJ45 that was added to make daisy chaining the RS485 network easy.
I just got localroger's PropCMD running on PropCade - it took all of 2 minutes, including changing pin definitions.
This *should* let me write a quick VM loader for ZOG executables.
I wonder if I can get Sphinx running on top of it? Hmmm....
When I tried to get FemtoBasic running, it could not detect the keyboard; I think I'll try it with the combo driver from PropCMD, as that one works fine with the Parallax mini keyboard I am using.
I have a later version of PropCmd on my RamBlade thread (at the end IIRC). It has a few extra commands such as "?" to list the commands and "RUN" as well as "SPIN". (attached here)
My latest SphinxOS is v0.15 and was a version I was working on was for RamBlade. (attached here) Hence, it most likely has the 1pin drivers which you may need to change. If you want the other drivers I will dig them out. (I will look in a minute and attach here too). Both 1pin drivers·will work with standard hardware (TV 3 pin and keyboard 2pin).
SphinxOS requires 2 changes and obviously a recompile of the extras...
Reorder the rendezvous locations for the "_HUBTOP" parameter
The SD drivers require replacement (mpark says there is a bug and 3 cogs is not workable)
We also need to agree to a rendezvous layout
Note: Sphinx0·may contain older drivers that v0.15
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
- got rid of the keyboard and aigeneric objects
- added SimpleSerial for a serial console
- removed some commands (ie dump etc)
- renamed the remaining commands to be unix style
- changed ls to default to wide mode
- changed options to ls to use '-' instead of '/'
And all of a sudden, there is now 24KB available!
Even if we keep 0.5KB on the top for the Spin stack, that leaves 23.5KB for transient programs... or a VMCOG working set.
Right now I am looking into how much work would be required to make two more changes:
- add a mailbox for communicating with sdspiFemto.spin
- modifying FullDuplexSerial to be a mailbox based STDIO (that later can be replaced with kb+vga, or kb+tv)
After that worked, the next step would be to remove the remaining built-in commands, and make them external spin binaries for now.
The next logical step after that would be to process MODULES and launch specified cogs.
Then replace the Spin bootloader with the binary specified in INIT.D ... freeing up even more hub memory, because all desired drivers would be loaded by that time!
INIT.D would launch Minos.bin - which would basically be a 4KB image as described earlier, which would launch mash.zog!
At this point, we would have a working Minos prototype.
Mash would support:
- launching mailbox aware Spin binaries up to 28KB in size - which would actually allow larger programs than a stand-alone prop due to drivers already being loaded & initialized.
- launching full 32KB eeprom images (I suggest .IMG for these)
- launching ZOG binaries up to 64KB in size (512KB after I have a chance to finish the enhanced TLB)
We would still need a FAT fs running within ZOG that used the sdspiFemto server cog before we had file system access for ZOG
@Bill: There is already a Serial object in Sphinx that uses the 2 rendezvous locations (stdin & stdout). There are already seperate commands in Sphinx. IMHO, Sphinx is a better place to start, and just fix the SD driver(s).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Bill: "We would still need a FAT fs running within ZOG that used the sdspiFemto server cog before we had file system access for ZOG"
Not so. Zog has the ZPU SYSCALL instruction implemented, with this all file open, close, read, write etc syscalls are passed through to Spin for handling. This currently only works for reads and writes to STDIN and STOUT. It should be easy enough to pass those through to whatever FS Spin code one wants to use.
So if you happen to be using a FAT system in Spin anyway it is no necessary to have one in C.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
anyone said...
I will write a nice easy to use MCP23S17.spin object for Obex
Did you wrote it now? I'll try to use the same chip on my propeller. Its connected directly to four IO Pins, but it wouldn't be a problem to change #CS to a 74138 (connected the same way as dracblade).
CS = 20 ' chip select
SCK = 21 ' clock
SI = 22 ' in
SO = 23 ' out
I want do exactly the same like you, connect 2 Joysticks, but i didn't get it working. Now i've changed to 2 x PCF8474 (8bit).
If you need help, this page is great: http://www.ermicro.com/blog/?p=1050
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
some say the devil is dead... ...tish army!
For a possible FAT file system for Zog I just succeeded in compiling this for the ZPU www.robs-projects.com/filelib.html FAT32, multiple open files, long file names and all.
It's a bit big at 170KB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
As PropCade have posibility to run mixed RAM/Flash IC's on MEM area. If possible write all that PARTS of ZOG programs Type that one You mention - FAT file system to have possibility to RUN from Flash/VMCOG and use only if possible RAM's as Variable DATA storage. That can give possibility to run much biger programs in ZOG.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha: Yes indeed that would be great. I'm still trying to get the ZPU's GCC linker script to locate code into a ROM section. All my experiments so far have failed. If there is any GCC linker script guru out there who could advise that would be much appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
After all that it looks like we should be able to move ZPU code into HUB address space without touching the linker scripts, just add an option to the compile:
.....-Wl,--section-start=.hub=0x10000
I also discovered one can link binary blobs into the build by simply converting them to proper object files with objcopy first:
Which means we can now compile binary COG blobs with BSTC -c and have them included in the final Zog executable. With that in place Zog can load and start COGS just like Spin.
So we are just a few steps away from a tool chain which allows C for ZPU and PASM to replace Spin/PASM entirely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cluso99 said...
@Bill: There is already a Serial object in Sphinx that uses the 2 rendezvous locations (stdin & stdout). There are already seperate commands in Sphinx. IMHO, Sphinx is a better place to start, and just fix the SD driver(s).
We will start with the Spin version - but I have visions of letting VMCOG manage the memory used to implement the FS, thus reducing the hub footprint.
heater said...
Bill: "We would still need a FAT fs running within ZOG that used the sdspiFemto server cog before we had file system access for ZOG"
Not so. Zog has the ZPU SYSCALL instruction implemented, with this all file open, close, read, write etc syscalls are passed through to Spin for handling. This currently only works for reads and writes to STDIN and STOUT. It should be easy enough to pass those through to whatever FS Spin code one wants to use.
So if you happen to be using a FAT system in Spin anyway it is no necessary to have one in C.
I have not had time to finish it, I've been concentrating on getting VMCOG working [noparse]:)[/noparse]
bazi said...
anyone said...
I will write a nice easy to use MCP23S17.spin object for Obex
Did you wrote it now? I'll try to use the same chip on my propeller. Its connected directly to four IO Pins, but it wouldn't be a problem to change #CS to a 74138 (connected the same way as dracblade).
CS = 20 ' chip select
SCK = 21 ' clock
SI = 22 ' in
SO = 23 ' out
I want do exactly the same like you, connect 2 Joysticks, but i didn't get it working. Now i've changed to 2 x PCF8474 (8bit).
If you need help, this page is great: http://www.ermicro.com/blog/?p=1050
That is big.. but as Sapieha replied to you, PropCade supports mixed ram/fram/flash
One configuration I like (because it is inexpensive) is 160KB of ram (5x 23K256) and 1MB of flash (W25X80)
All it needs is a fancier loader, and a bit of code in VMCOG to be able to program/erase flash. And I have flash code in my Largos project [noparse]:)[/noparse]
Did you optimize that build? I remember other binaries shrinking 75% when you optimized them...
heater said...
For a possible FAT file system for Zog I just succeeded in compiling this for the ZPU www.robs-projects.com/filelib.html FAT32, multiple open files, long file names and all.
I wonder if this would also work for putting all the binary blobs at the end say at $E000, for later re-use of the vm space?
heater said...
After all that it looks like we should be able to move ZPU code into HUB address space without touching the linker scripts, just add an option to the compile:
.....-Wl,--section-start=.hub=0x10000
I also discovered one can link binary blobs into the build by simply converting them to proper object files with objcopy first:
Which means we can now compile binary COG blobs with BSTC -c and have them included in the final Zog executable. With that in place Zog can load and start COGS just like Spin.
So we are just a few steps away from a tool chain which allows C for ZPU and PASM to replace Spin/PASM entirely.
heater said...
Jazzed: The default linker script used by the ZPU tool chain is attached.
Wow
Linker scripts don't have to be that complicated, but certain symbols must be supported for the tool chain.
A very simple default script supporting only .data, .bss, and .text just for clarity might be like this:
In the example .data goes from 0 to 0xffff and .text (usually read-only code) starts at 0x10000.
Normally a .bss section is also defined and I think it's ok to put it just after .data .
The reason your image is > 64K is because of the . = 0x10000; before .hub ... but you know that by now.
I'm not sure why you're using a special .hub section though.
Thanks Jazzed. I had a feeling that linker script was a bit OTT and we could get away with a lot less. It's probably like that to cater for all supported languages and keeping GDB happy etc.
The reason I was playing with a .hub section is that for the cost of a test in the memory access paths of ZPU one could put code at various different virtual addresses. So for example code accessed from $00000 to $0FFFF would be fetched from VMCog and code accessed from $10000 upwards would be fetched from HUB memory (or a subset of HUB memory). Idea being to be able to run some code faster from HUB. Alternatively if Bill or anyone puts together a VMCog with RAM and FLASH it will be necessary to locate code at some different FLASH location.
Anyway I'm going to drop that idea for now and be content with being able to get access to the HUB memory (inc ROM). This does not really require any linker script changes.
My Zog has not moved on much from the last posting. I'm going to fit it out with mailbox control and get the ext RAM loaded from SD card when I have some time to play.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That's a nice FAQ ... I kind of wish this community and/or Parallax was FAQ inclined.
I took a class on AVR assembly and have tinkered with C there some with Kanda/WinAVR.
The skip and indirect instructions are great, but I can't stand using the EOR mnemonic.
I know! My PCB manufacturer let me down; I still don't have the revised boards!
Out of the 16 PCB's I sent in so I could show them at UPEW, only 12 have arrived - and five of those only came in around 5pm today. I'm NOT happy.
I will bring the first run prototypes, which are almost identical to the new revision (just .6" wider, to add the second RJ45, and an RS485 fix) so that people can at least see it.
And I was going to have a UPEW special on them too...
Right now it looks like I'll have the new PropCade proto's around June 30th. If they test out (and they should), I can have a production run by end of July.
Cluso99 said...
Bill & Sapieha: The PropCade looks great! It's a shame you will not have them for sale at UPEW.
Comments
The revised PropCade PCB is going in for a prototype run today [noparse]:)[/noparse]
Due to the second RJ45 connector, the PCB is a bit larger now - new dimensions are 6.6"x2.8"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
VMCOG runs nice only on PropCade - and ZOG on VMCOG is coming along nicely! Running Java and CP/M hopefully will also be possible in the near future.
I should have the revised prototype PCB's within a couple of days. The only difference is a slightly larger form factor (6.6" wide) needed to accommodate the second RJ45 that was added to make daisy chaining the RS485 network easy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I know UPEW is a two day event, but is there going to be any time left for the others after you present all your new, abundent, and wonderfull toys.
Batman 1989
Quote "The Joker: Where does he get those wonderful toys?"
Jim
...kidding, normal length, quick overview of the neatest stuff, then everyone can bug me at my table
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I just got localroger's PropCMD running on PropCade - it took all of 2 minutes, including changing pin definitions.
This *should* let me write a quick VM loader for ZOG executables.
I wonder if I can get Sphinx running on top of it? Hmmm....
When I tried to get FemtoBasic running, it could not detect the keyboard; I think I'll try it with the combo driver from PropCMD, as that one works fine with the Parallax mini keyboard I am using.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I have a later version of PropCmd on my RamBlade thread (at the end IIRC). It has a few extra commands such as "?" to list the commands and "RUN" as well as "SPIN". (attached here)
My latest SphinxOS is v0.15 and was a version I was working on was for RamBlade. (attached here) Hence, it most likely has the 1pin drivers which you may need to change. If you want the other drivers I will dig them out. (I will look in a minute and attach here too). Both 1pin drivers·will work with standard hardware (TV 3 pin and keyboard 2pin).
SphinxOS requires 2 changes and obviously a recompile of the extras...
- Reorder the rendezvous locations for the "_HUBTOP" parameter
- The SD drivers require replacement (mpark says there is a bug and 3 cogs is not workable)
- We also need to agree to a rendezvous layout
Note: Sphinx0·may contain older drivers that v0.15▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 6/13/2010 3:58:21 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
- got rid of the keyboard and aigeneric objects
- added SimpleSerial for a serial console
- removed some commands (ie dump etc)
- renamed the remaining commands to be unix style
- changed ls to default to wide mode
- changed options to ls to use '-' instead of '/'
And all of a sudden, there is now 24KB available!
Even if we keep 0.5KB on the top for the Spin stack, that leaves 23.5KB for transient programs... or a VMCOG working set.
Right now I am looking into how much work would be required to make two more changes:
- add a mailbox for communicating with sdspiFemto.spin
- modifying FullDuplexSerial to be a mailbox based STDIO (that later can be replaced with kb+vga, or kb+tv)
After that worked, the next step would be to remove the remaining built-in commands, and make them external spin binaries for now.
The next logical step after that would be to process MODULES and launch specified cogs.
Then replace the Spin bootloader with the binary specified in INIT.D ... freeing up even more hub memory, because all desired drivers would be loaded by that time!
INIT.D would launch Minos.bin - which would basically be a 4KB image as described earlier, which would launch mash.zog!
At this point, we would have a working Minos prototype.
Mash would support:
- launching mailbox aware Spin binaries up to 28KB in size - which would actually allow larger programs than a stand-alone prop due to drivers already being loaded & initialized.
- launching full 32KB eeprom images (I suggest .IMG for these)
- launching ZOG binaries up to 64KB in size (512KB after I have a chance to finish the enhanced TLB)
We would still need a FAT fs running within ZOG that used the sdspiFemto server cog before we had file system access for ZOG
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 6/13/2010 4:41:48 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Not so. Zog has the ZPU SYSCALL instruction implemented, with this all file open, close, read, write etc syscalls are passed through to Spin for handling. This currently only works for reads and writes to STDIN and STOUT. It should be easy enough to pass those through to whatever FS Spin code one wants to use.
So if you happen to be using a FAT system in Spin anyway it is no necessary to have one in C.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I want do exactly the same like you, connect 2 Joysticks, but i didn't get it working. Now i've changed to 2 x PCF8474 (8bit).
If you need help, this page is great: http://www.ermicro.com/blog/?p=1050
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
some say the devil is dead... ...tish army!
It's a bit big at 170KB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
As PropCade have posibility to run mixed RAM/Flash IC's on MEM area. If possible write all that PARTS of ZOG programs Type that one You mention - FAT file system to have possibility to RUN from Flash/VMCOG and use only if possible RAM's as Variable DATA storage. That can give possibility to run much biger programs in ZOG.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Well actually that is the default with my latest attempt at locating a .hub section tacked on near the end.
I create the .hub section in C with something like:
void func_in_hub (void) __attribute__ ((section (".hub"))); void func_in_hub (void) { bla bla bla; }Actually this is the first time I have seen a .hub section showing up in the list file output like so:
Haven't figured out why it sits at $ff0000 or how to change it yet.
By the way, the FAT fs used in Catalina compiles to only 37KB.
Edit: Seems a simple ". = 0x10000;" seems to do the trick:
. = 0x10000; .hub : { *(.hub ) }Edit: Except my binary which was 18K is now bigger than 64K !!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 6/14/2010 8:40:22 AM GMT
.....-Wl,--section-start=.hub=0x10000
I also discovered one can link binary blobs into the build by simply converting them to proper object files with objcopy first:
# zpu..objcopy -I binary -O elf32-zpu foo.bin foo.o
Which means we can now compile binary COG blobs with BSTC -c and have them included in the final Zog executable. With that in place Zog can load and start COGS just like Spin.
So we are just a few steps away from a tool chain which allows C for ZPU and PASM to replace Spin/PASM entirely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
One configuration I like (because it is inexpensive) is 160KB of ram (5x 23K256) and 1MB of flash (W25X80)
All it needs is a fancier loader, and a bit of code in VMCOG to be able to program/erase flash. And I have flash code in my Largos project [noparse]:)[/noparse]
Did you optimize that build? I remember other binaries shrinking 75% when you optimized them...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I wonder if this would also work for putting all the binary blobs at the end say at $E000, for later re-use of the vm space?
Very interesting...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Linker scripts don't have to be that complicated, but certain symbols must be supported for the tool chain.
A very simple default script supporting only .data, .bss, and .text just for clarity might be like this:
SECTIONS { .data 0x0 : { *(.data) } .bss : { *(.bss) *(COMMON) } .text 0x10000 : { *(.text) } }In the example .data goes from 0 to 0xffff and .text (usually read-only code) starts at 0x10000.
Normally a .bss section is also defined and I think it's ok to put it just after .data .
The reason your image is > 64K is because of the . = 0x10000; before .hub ... but you know that by now.
I'm not sure why you're using a special .hub section though.
Is your latest ZOG posted?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
The reason I was playing with a .hub section is that for the cost of a test in the memory access paths of ZPU one could put code at various different virtual addresses. So for example code accessed from $00000 to $0FFFF would be fetched from VMCog and code accessed from $10000 upwards would be fetched from HUB memory (or a subset of HUB memory). Idea being to be able to run some code faster from HUB. Alternatively if Bill or anyone puts together a VMCog with RAM and FLASH it will be necessary to locate code at some different FLASH location.
Fortunately the AVR guys that use GCC have been through all this before and have lots of good tips. www.nongnu.org/avr-libc/user-manual/FAQ.html
Anyway I'm going to drop that idea for now and be content with being able to get access to the HUB memory (inc ROM). This does not really require any linker script changes.
My Zog has not moved on much from the last posting. I'm going to fit it out with mailbox control and get the ext RAM loaded from SD card when I have some time to play.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I took a class on AVR assembly and have tinkered with C there some with Kanda/WinAVR.
The skip and indirect instructions are great, but I can't stand using the EOR mnemonic.
If you haven't seen it, a good reference (a Cygnus original?) for .ld is here:
www.math.utah.edu/docs/info/ld_toc.html
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Sapieha has made a really nice 3D rendering of the newer PropCade prototype, so I thought I'd put it up here!
I am still waiting for the PCB. My manufacturer has let me down, they are slower than usual.
Fear not, I will bring the original PropCade to UPEW.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Sapieha's renderings are just as good as seeing the real board! You guys are a pretty good team!
Good luck at UPEW!
Jim
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
@Cluso99 - Thanks!
I know! My PCB manufacturer let me down; I still don't have the revised boards!
Out of the 16 PCB's I sent in so I could show them at UPEW, only 12 have arrived - and five of those only came in around 5pm today. I'm NOT happy.
I will bring the first run prototypes, which are almost identical to the new revision (just .6" wider, to add the second RJ45, and an RS485 fix) so that people can at least see it.
And I was going to have a UPEW special on them too...
Right now it looks like I'll have the new PropCade proto's around June 30th. If they test out (and they should), I can have a production run by end of July.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system