Sometimes when looking for a software problem... one finds a hardware issue.
Unfortunately I ran into this today; I was convinced it was VMCOG misbehaving - when in fact it looks like the culprit is either a bad dip8 socket or a poor solder joint on the PropCade prototype. I did all of my testing for the SPI routines on IC2 & IC3, IC1 seems to have an issue, and it is not the chip.
The problem turned out to be not initializing IC1 correctly! - software issue, NOT a hardware problem. Duh.
The good news is that VMCOG v0.87 seems to do the initial loading of the working set correctly.
The bad news is that tomorrow I have a number of family obligations to take care of, so it is likely that a fully functional VMCOG v0.90 will not happen this weekend.
I am so close I can taste it!
I've updated the first post with a current snapshot - v0.87
I need to catch up on progress on this thread. Ok, I think the idea at the beginning was that rather than having a large amount of parallel ram, which uses up many pins, just use a couple of pins for serial SPI ram. Is that correct?
Then I think your idea was to buffer blocks of ram in hub ram, so that most of the time you use the local cache in hub rather than loading bytes from SPI. When you say it is close to working, is this the thing that is close?
ZiCog, qZ80, etc could also use it for situations where a slower emulation is acceptable as long as you still have a lot of free pins to use for other goodies.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Indeed, heater. Pullmoll is so close with MP/M, and one thing you could do with MP/M is trade some speed in return for lots of serial ports. A server for CP/M Net?
Also, SPI ram has the potential to halve the board size (which means a beer coaster sized board, or in the hands of Cluso, something the size of a match head)
Yes, the idea is that for applications there are not enough pins to support a parallel memory interface, SPI memory in combination with a VM manager may be fast enough.
It is actually more than just a buffer, it is an implementation for old mainframe-style virtual memory for the Propeller, with a mailbox for memory access requests.
Yep, this is that thing [noparse]:)[/noparse]
Heater:
I totally agree. VMCOG should be more than fast enough for a lot of applications - "business logic code", emulations of older computers etc.
Weather it is fast enough, that is the question.
That will depend on the size of the working set, and the number of page faults per second.
Dr_Acula:
I suspect that Z80 emulations will run at 50%-90% of the speed they run at with parallel memory - the range is so large because it will depend on the size of the working set, and the memory access patterns of the CP/M application
It really does save on board space! Take a look at how tiny FlexMem is (that's my add-on 4 bit bus board), and how little space the six memory sockets take on PropCade!
As for small boards - if money is not an issue, it is possible to buy a 256KB TDFN SPI FRAM chip from RAMTRON... 256KB in a tiny package. Unfortunately, they are extremely expensive.
- Bug squished! It turned out that the first SPI ram was not being initialized properly.
- Added VMACCESS download to the first post, it has sample (not yet tested) PASM code for reading/writing the VM from another cog
- I've tested SPI ram chips in all six sockets, they all work properly - so a 192KB VM is theoretically possible
Heater asked for the sample code in the ZOG thread.
- I uploaded v0.88 which fixes the initialization problem
- I found a bug in VMACCESS, please use +8 offset for the data long in the mailbox until I change VMCOG
- in order to have better performance, I am changing from write-through to delayed write strategy
- as ZOG does not require it, I will not implement non-aligned word/long access yet, first I'll get the aligned code 100% working
I have not been able to get vmcog 0.88 to work.· I write aabbccdd to address 0, but cannot read it back.· Test system is Professional Development Board.· CS = 1, CLK = 2.·MOSI = 4, MISO = 8, HOLD = +3.3V.· First I show VM page and get garbage, OK.· Then I write aabbccdd to·address 0.· Then I show the VM page and get all 0s.· Then I read the long at address 0 and get $00007c00.· I have attached a copy of the output.
Thanks for the bug report. 0.88 is not yet functional, it is just the first version that actually pages the working set in on startup.
I am currently finishing some boards for a customer, and sending in some prototype PCB's so I get them back in plenty of time for UPEW.
I expect to resume working on VMCOG next week. Sorry for the delays!
John Abshier said...
I have not been able to get vmcog 0.88 to work. I write aabbccdd to address 0, but cannot read it back. Test system is Professional Development Board. CS = 1, CLK = 2. MOSI = 4, MISO = 8, HOLD = +3.3V. First I show VM page and get garbage, OK. Then I write aabbccdd to address 0. Then I show the VM page and get all 0s. Then I read the long at address 0 and get $00007c00. I have attached a copy of the output.
Ok, it took a bit more than a week, but I have resumed working on VMCOG. I've uploaded v0.89 to the first post.
This is a bug fix release that:
- fixes dirty bit display in VMDEBUG.Spin
- fixes (aligned) word and long write in VMCOG.Spin
- reversed internal initial allocation of working set pages to allow (in near future) using lock() to reserve video buffers
I am working on:
- getting dirty pages flushing to the SPI sram's when targeted for eviction
As ZOG does not do unaligned word/long accesses, I may leave implementing those until after UPEW.
(delay was due to submitting *16* printed circuit boards for prototype production, and working for clients)
No time to check now, just off to work, but does this still work with no actual external RAM present?
Zog now has a working EMULATE instruction so actually it can run with only LONG accesses. At least saves having to worry about endianess issues for now.
Looks like it's time for Zog to take VMCog into use. Load VM from a ZPU binary on SD card then start ZOG.
Do we have a version that uses ext RAM? Currently I only have TriBlade to play with. So either VMCog has to support the 512K RAM on Blade #2 or I tack your SPI RAM solution on to Blade #3 that will also need an an SD card.
I've been trying to figure out how to link and locate ZPU binaries such that we can put code in ext RAM with stack and data in HUB. Or which ever way round we like. The GNU linker scripts are a pain to get my head around but I think I'm starting to see the light.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just for you, just today, on special, I added some #defines and #ifdef's so that it will run without external memory.
I have been meaning to add ifdef's, in order to support multiple platforms.
Currently VMCOG's built-in driver is for PropCade, however all memory access code is isolated into three routines:
BREAD - transfer 512 bytes from vmaddr to hubptr
BWRITE - transfer 512 bytes from hubptr to vmaddr
BSTART - used by BREAD/BWRITE to set up addressing for the memory
Re/ linker...
Ideally, it should allow setting vm/hub for each of code/data/stack segments, to tune memory usage.
I will be posting a newer version later today [noparse]:)[/noparse]
MAJOR UPDATE: VMCOG v0.92 uploaded - this is the ALPHA release
This release is the first release that appears to function correctly - but I only tested with VMDEBUG.
This release features:
- VMDEBUG to help debugging VMCOG
- 512 byte pages
- 128 entry TLB
- 64KB virtual memory
- 21 bit access counter for every active page
- user-configurable number of pages in the working set
Still missing:
- page hit / miss statistics
- sacrificial page algorithm tuning
- scaling hit counts when a count wraps
- optional 1K pages for 128KB vm
- lock()/unlock() implementation
- unaligned word/long access
I would appreciate it if you guys tested the heck out of it, and sent me bug reports.
I would also appreciate it if some of you would port it to platforms I don't have - DracBlade, TriBlade and MemBlade. Please see the ifdef's in VMCOG.Spin. Only BREAD/BWRITE/BSTART need to be modified to support other platforms, and please send your new BREAD/BWRITE/BSTART code to me for inclusion in the official sources.
ENJOY!
(I am uploading the new archive into the first post right after I post this message)
Attached is my first attempt at adding TriBlade blade #2 support to VMCOG.
I may be posting this prematurely but I'm a little bit chuffed as it worked first time after cutting, pasting and modifying the memory access code from ZiCog.
vmdebug is not changed except for configuring clock and baud for my TriBlade and a little test code I added which shows up a bug in VMCOG. See below.
vmcog.spin has now got a whole bunch of new "#ifdef FLEXMEM", "#ifdef MORPHEUS_SPI", etc in the B* functions.
I changed "TRIBLADE" to "TRIBLADE_2" so as to indicate the blade number it works on. A different driver may emerge for blade #1
There are only two longs left in the VM cog!
The bug
I added the following code just after vm.start in the main function of vmdebug:
waitcnt(clkfreq*1 + cnt)
v := 255
repeat ad from 0 to 255
vm.wrvbyte(ad, v)
v := v - 1
The idea being to initialize some memory before starting up the menu.
Problem is if one removes the waitcnt it crashes or at least does not write what it should.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I was able to integrate a driver running in a second COG with your code.
This allows me to just "plug in" something rather than "port in" a device.
A confusing point is the version number in the comments is not 0.92.
I ended up downloading the .zip twice last night because of that [noparse]:)[/noparse]
The biggest hurdle I had believe it or not was the size of mailbox ... the
size declaration does not match the usage and that confused me quite a bit [noparse]:)[/noparse]
I was also a little confused that vmaddr actually is used in BREAD/BWRITE to
reference the physical address. Don't know what I would do without my debugger[noparse]:)[/noparse]
I find the following ... please correct me if I'm wrong:
BSTART is only necessary for devices that may not do their own paging.
I had to add PROPCADE ifdef in several places to get rid of the code.
The PROPCADE should probably be used instead of EXTMEM in BSTART/BREAD/BWRITE.
BUSERR is necessary for any ext. mem. device and ifdef EXTMEM makes sense there.
It would be nice if there was a read-only attribute per page for devices such as flash/eeprom etc....
Now, I'll see if I can integrate a JVM that uses VMCOG with my old style EDO DRAM device [noparse]:)[/noparse]
Jazzed, oh good it's not just me. Why is vmaddr actually the physical RAM address?
I actually used BSTART setting up addr, ptr, count and a couple of lines of TriBlade access code that was executed only once on ZiCog start up. Perhaps that could be done away with but with only two longs left it won't fit just now.
I added #ifdef PROPCADE among others in the B* functions.
No, "#ifdef PROPCADE" should not be used instead of "#ifdef EXTMEM". As EXTMEM is a big switch that turns on/off external RAM usage on all platforms. Perhaps just for test purposes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Nice! I am glad you got it working with TriBlade#2 easily!
I will look for the bug.
I am considering re-organizing the code a bit to make it easier to add more targets.
heater said...
Attached is my first attempt at adding TriBlade blade #2 support to VMCOG.
I may be posting this prematurely but I'm a little bit chuffed as it worked first time after cutting, pasting and modifying the memory access code from ZiCog.
vmdebug is not changed except for configuring clock and baud for my TriBlade and a little test code I added which shows up a bug in VMCOG. See below.
vmcog.spin has now got a whole bunch of new "#ifdef FLEXMEM", "#ifdef MORPHEUS_SPI", etc in the B* functions.
I changed "TRIBLADE" to "TRIBLADE_2" so as to indicate the blade number it works on. A different driver may emerge for blade #1
There are only two longs left in the VM cog!
The bug
I added the following code just after vm.start in the main function of vmdebug:
waitcnt(clkfreq*1 + cnt)
v := 255
repeat ad from 0 to 255
vm.wrvbyte(ad, v)
v := v - 1
The idea being to initialize some memory before starting up the menu.
Problem is if one removes the waitcnt it crashes or at least does not write what it should.
Ah, don't worry, I was up to v0.93 as of last night [noparse]:)[/noparse]
I will clean up declarations etc soon.
I will check out the vmaddr issue. BREAD/BWRITE are supposed to take two arguments:
vmaddr - the virtual address of the page, low 9 bits 0'd
hubaddr - the physical location for the page in the working set, low 9 bits 0'd
If in my frenzy to get it running I busted that simple scheme, I will fix it [noparse]:)[/noparse]
I *LIKE* the idea of read-only pages!
The original concept was that only BREAD/BWRITE are exposed, BSTART came later to save cog space for code common to BREAD/BWRITE.
EXTMEM is appropriate for BREAD/BWRITE as if external memory is turned of, one cannot page [noparse]:)[/noparse]
More later...
jazzed said...
Hi Bill,
I was able to integrate a driver running in a second COG with your code.
This allows me to just "plug in" something rather than "port in" a device.
A confusing point is the version number in the comments is not 0.92.
I ended up downloading the .zip twice last night because of that [noparse]:)[/noparse]
The biggest hurdle I had believe it or not was the size of mailbox ... the
size declaration does not match the usage and that confused me quite a bit [noparse]:)[/noparse]
I was also a little confused that vmaddr actually is used in BREAD/BWRITE to
reference the physical address. Don't know what I would do without my debugger[noparse]:)[/noparse]
I find the following ... please correct me if I'm wrong:
BSTART is only necessary for devices that may not do their own paging.
I had to add PROPCADE ifdef in several places to get rid of the code.
The PROPCADE should probably be used instead of EXTMEM in BSTART/BREAD/BWRITE.
BUSERR is necessary for any ext. mem. device and ifdef EXTMEM makes sense there.
It would be nice if there was a read-only attribute per page for devices such as flash/eeprom etc....
Now, I'll see if I can integrate a JVM that uses VMCOG with my old style EDO DRAM device [noparse]:)[/noparse]
I think vmaddr changed due to working on the code around 5am a few times [noparse]:)[/noparse]
I will re-factor to the original intent, and make it easier to port.
heater said...
Jazzed, oh good it's not just me. Why is vmaddr actually the physical RAM address?
I actually used BSTART setting up addr, ptr, count and a couple of lines of TriBlade access code that was executed only once on ZiCog start up. Perhaps that could be done away with but with only two longs left it won't fit just now.
I added #ifdef PROPCADE among others in the B* functions.
No, "#ifdef PROPCADE" should not be used instead of "#ifdef EXTMEM". As EXTMEM is a big switch that turns on/off external RAM usage on all platforms. Perhaps just for test purposes.
There's nothing wrong with BSTART as long as the intention of it is perfectly clear. It makes sense to have for I2C devices and would also be used for a faster read-only EEPROM fetch.
It's fine to keep EXTMEM though the version I was using would throw a warning if not defined. Having seen some of the v093 now, it makes sense to have that not defined if not using external memory ... which I suppose is good for testing.
I like the idea of breaking up the source. I really despise having to wade through a plethora if ifdef/endifs more than once to read code. Using #includes for platform specific code is just fine. ... BTW vmplatform.spin is clearer than vmpage.spin but I'll take what ever you specify I guess i'll have to see an example to understand the vmpage intention.
I need one ifdef/endif at vmcog init to set pointers for inter-cog communications. I doubt if my EDO DRAM code from 2.5 years ago would fit in vmcog even if I optimized it. BTW I see you didn't ifdef the PROPCADE specific code there.
If you find a good "freeze point", I'll need to add my code so I don't have to re-code for every new version produced.
Cheers,
--Steve
Bill Henning said...
Hi Steve,
Ah, don't worry, I was up to v0.93 as of last night [noparse]:)[/noparse]
I will clean up declarations etc soon.
I will check out the vmaddr issue. BREAD/BWRITE are supposed to take two arguments:
vmaddr - the virtual address of the page, low 9 bits 0'd
hubaddr - the physical location for the page in the working set, low 9 bits 0'd
If in my frenzy to get it running I busted that simple scheme, I will fix it [noparse]:)[/noparse]
I *LIKE* the idea of read-only pages!
The original concept was that only BREAD/BWRITE are exposed, BSTART came later to save cog space for code common to BREAD/BWRITE.
EXTMEM is appropriate for BREAD/BWRITE as if external memory is turned of, one cannot page [noparse]:)[/noparse]
I will add a BINIT section at the top, note how the initialization code area is re-used for TLB entries, so I don't want to make it a subroutine.
I am refactoring the code a bit... BSTART is no longer required, the only interface between VMCOG and the external memory that will be required is BINIT/BREAD/BWRITE
I throw a warning so people don't forget to turn on the external access (except when testing basic functionality).
Now I just have to get BradC to add #include to BST...
There is more space than you think - I had a "FIT 360" at the end so your EDO code should fit!
I see what you mean about vmpager. Perhaps I will change it to "vmhardware.spin".
jazzed said...
Bill,
There's nothing wrong with BSTART as long as the intention of it is perfectly clear. It makes sense to have for I2C devices and would also be used for a faster read-only EEPROM fetch.
It's fine to keep EXTMEM though the version I was using would throw a warning if not defined. Having seen some of the v093 now, it makes sense to have that not defined if not using external memory ... which I suppose is good for testing.
I like the idea of breaking up the source. I really despise having to wade through a plethora if ifdef/endifs more than once to read code. Using #includes for platform specific code is just fine. ... BTW vmplatform.spin is clearer than vmpage.spin but I'll take what ever you specify I guess i'll have to see an example to understand the vmpage intention.
I need one ifdef/endif at vmcog init to set pointers for inter-cog communications. I doubt if my EDO DRAM code from 2.5 years ago would fit in vmcog even if I optimized it. BTW I see you didn't ifdef the PROPCADE specific code there.
If you find a good "freeze point", I'll need to add my code so I don't have to re-code for every new version produced.
Cheers,
--Steve
Bill Henning said...
Hi Steve,
Ah, don't worry, I was up to v0.93 as of last night [noparse]:)[/noparse]
I will clean up declarations etc soon.
I will check out the vmaddr issue. BREAD/BWRITE are supposed to take two arguments:
vmaddr - the virtual address of the page, low 9 bits 0'd
hubaddr - the physical location for the page in the working set, low 9 bits 0'd
If in my frenzy to get it running I busted that simple scheme, I will fix it [noparse]:)[/noparse]
I *LIKE* the idea of read-only pages!
The original concept was that only BREAD/BWRITE are exposed, BSTART came later to save cog space for code common to BREAD/BWRITE.
EXTMEM is appropriate for BREAD/BWRITE as if external memory is turned of, one cannot page [noparse]:)[/noparse]
- moves to three digits following decimal for version numbers [noparse]:)[/noparse]
- integrates TriBlade_2 code from heater
- some cleanup
- ifdef PROPCADE on rest of PROPCADE specific code
- added BINIT section at the top
- preliminary shr_hits code, not debugged
I am attaching it here; I will update p.1 after I check out the vmaddr/hubaddr behavior in BREAD/BWRITE
I'm having a little trouble with write/reads. I set number of pages to 1 at startup and force pages
to swap by simply reading writing between $0 and $200. Sometimes after a swap data is 0 if I
read the address, but seems to be there when I dump the page and on another read.
Thought I would try non EXTMEM mode to see if that works, but can't get more than one page going.
I'll look at this more later ... I have other commitments now.
jazzed said...
I'm having a little trouble with write/reads. I set number of pages to 1 at startup and force pages
to swap by simply reading writing between $0 and $200. Sometimes after a swap data is 0 if I
read the address, but seems to be there when I dump the page and on another read.
Thought I would try non EXTMEM mode to see if that works, but can't get more than one page going.
I'll look at this more later ... I have other commitments now.
Comments
Unfortunately I ran into this today; I was convinced it was VMCOG misbehaving - when in fact it looks like the culprit is either a bad dip8 socket or a poor solder joint on the PropCade prototype. I did all of my testing for the SPI routines on IC2 & IC3, IC1 seems to have an issue, and it is not the chip.
The problem turned out to be not initializing IC1 correctly! - software issue, NOT a hardware problem. Duh.
The good news is that VMCOG v0.87 seems to do the initial loading of the working set correctly.
The bad news is that tomorrow I have a number of family obligations to take care of, so it is likely that a fully functional VMCOG v0.90 will not happen this weekend.
I am so close I can taste it!
I've updated the first post with a current snapshot - v0.87
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 4/18/2010 5:48:48 PM GMT
Then I think your idea was to buffer blocks of ram in hub ram, so that most of the time you use the local cache in hub rather than loading bytes from SPI. When you say it is close to working, is this the thing that is close?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
ZiCog, qZ80, etc could also use it for situations where a slower emulation is acceptable as long as you still have a lot of free pins to use for other goodies.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Also, SPI ram has the potential to halve the board size (which means a beer coaster sized board, or in the hands of Cluso, something the size of a match head)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Yes, the idea is that for applications there are not enough pins to support a parallel memory interface, SPI memory in combination with a VM manager may be fast enough.
It is actually more than just a buffer, it is an implementation for old mainframe-style virtual memory for the Propeller, with a mailbox for memory access requests.
Yep, this is that thing [noparse]:)[/noparse]
Heater:
I totally agree. VMCOG should be more than fast enough for a lot of applications - "business logic code", emulations of older computers etc.
Weather it is fast enough, that is the question.
That will depend on the size of the working set, and the number of page faults per second.
Dr_Acula:
I suspect that Z80 emulations will run at 50%-90% of the speed they run at with parallel memory - the range is so large because it will depend on the size of the working set, and the memory access patterns of the CP/M application
It really does save on board space! Take a look at how tiny FlexMem is (that's my add-on 4 bit bus board), and how little space the six memory sockets take on PropCade!
As for small boards - if money is not an issue, it is possible to buy a 256KB TDFN SPI FRAM chip from RAMTRON... 256KB in a tiny package. Unfortunately, they are extremely expensive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 4/18/2010 5:49:24 PM GMT
- Bug squished! It turned out that the first SPI ram was not being initialized properly.
- Added VMACCESS download to the first post, it has sample (not yet tested) PASM code for reading/writing the VM from another cog
- I've tested SPI ram chips in all six sockets, they all work properly - so a 192KB VM is theoretically possible
Heater asked for the sample code in the ZOG thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 uploaded v0.88 which fixes the initialization problem
- I found a bug in VMACCESS, please use +8 offset for the data long in the mailbox until I change VMCOG
- in order to have better performance, I am changing from write-through to delayed write strategy
- as ZOG does not require it, I will not implement non-aligned word/long access yet, first I'll get the aligned code 100% working
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
John Abshier
Thanks for the bug report. 0.88 is not yet functional, it is just the first version that actually pages the working set in on startup.
I am currently finishing some boards for a customer, and sending in some prototype PCB's so I get them back in plenty of time for UPEW.
I expect to resume working on VMCOG next week. Sorry for the delays!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Ok, it took a bit more than a week, but I have resumed working on VMCOG. I've uploaded v0.89 to the first post.
This is a bug fix release that:
- fixes dirty bit display in VMDEBUG.Spin
- fixes (aligned) word and long write in VMCOG.Spin
- reversed internal initial allocation of working set pages to allow (in near future) using lock() to reserve video buffers
I am working on:
- getting dirty pages flushing to the SPI sram's when targeted for eviction
As ZOG does not do unaligned word/long accesses, I may leave implementing those until after UPEW.
(delay was due to submitting *16* printed circuit boards for prototype production, and working for clients)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.smarthome.viviti.com/propeller
No time to check now, just off to work, but does this still work with no actual external RAM present?
Zog now has a working EMULATE instruction so actually it can run with only LONG accesses. At least saves having to worry about endianess issues for now.
Looks like it's time for Zog to take VMCog into use. Load VM from a ZPU binary on SD card then start ZOG.
Do we have a version that uses ext RAM? Currently I only have TriBlade to play with. So either VMCog has to support the 512K RAM on Blade #2 or I tack your SPI RAM solution on to Blade #3 that will also need an an SD card.
I've been trying to figure out how to link and locate ZPU binaries such that we can put code in ext RAM with stack and data in HUB. Or which ever way round we like. The GNU linker scripts are a pain to get my head around but I think I'm starting to see the light.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater:
Just for you, just today, on special, I added some #defines and #ifdef's so that it will run without external memory.
I have been meaning to add ifdef's, in order to support multiple platforms.
Currently VMCOG's built-in driver is for PropCade, however all memory access code is isolated into three routines:
BREAD - transfer 512 bytes from vmaddr to hubptr
BWRITE - transfer 512 bytes from hubptr to vmaddr
BSTART - used by BREAD/BWRITE to set up addressing for the memory
Re/ linker...
Ideally, it should allow setting vm/hub for each of code/data/stack segments, to tune memory usage.
I will be posting a newer version later today [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
This release is the first release that appears to function correctly - but I only tested with VMDEBUG.
This release features:
- VMDEBUG to help debugging VMCOG
- 512 byte pages
- 128 entry TLB
- 64KB virtual memory
- 21 bit access counter for every active page
- user-configurable number of pages in the working set
Still missing:
- page hit / miss statistics
- sacrificial page algorithm tuning
- scaling hit counts when a count wraps
- optional 1K pages for 128KB vm
- lock()/unlock() implementation
- unaligned word/long access
I would appreciate it if you guys tested the heck out of it, and sent me bug reports.
I would also appreciate it if some of you would port it to platforms I don't have - DracBlade, TriBlade and MemBlade. Please see the ifdef's in VMCOG.Spin. Only BREAD/BWRITE/BSTART need to be modified to support other platforms, and please send your new BREAD/BWRITE/BSTART code to me for inclusion in the official sources.
ENJOY!
(I am uploading the new archive into the first post right after I post this message)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/4/2010 9:04:56 PM GMT
I may be posting this prematurely but I'm a little bit chuffed as it worked first time after cutting, pasting and modifying the memory access code from ZiCog.
vmdebug is not changed except for configuring clock and baud for my TriBlade and a little test code I added which shows up a bug in VMCOG. See below.
vmcog.spin has now got a whole bunch of new "#ifdef FLEXMEM", "#ifdef MORPHEUS_SPI", etc in the B* functions.
I changed "TRIBLADE" to "TRIBLADE_2" so as to indicate the blade number it works on. A different driver may emerge for blade #1
There are only two longs left in the VM cog!
The bug
I added the following code just after vm.start in the main function of vmdebug:
waitcnt(clkfreq*1 + cnt) v := 255 repeat ad from 0 to 255 vm.wrvbyte(ad, v) v := v - 1The idea being to initialize some memory before starting up the menu.
Problem is if one removes the waitcnt it crashes or at least does not write what it should.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I was able to integrate a driver running in a second COG with your code.
This allows me to just "plug in" something rather than "port in" a device.
A confusing point is the version number in the comments is not 0.92.
I ended up downloading the .zip twice last night because of that [noparse]:)[/noparse]
The biggest hurdle I had believe it or not was the size of mailbox ... the
size declaration does not match the usage and that confused me quite a bit [noparse]:)[/noparse]
I was also a little confused that vmaddr actually is used in BREAD/BWRITE to
reference the physical address. Don't know what I would do without my debugger[noparse]:)[/noparse]
I find the following ... please correct me if I'm wrong:
- BSTART is only necessary for devices that may not do their own paging.
- I had to add PROPCADE ifdef in several places to get rid of the code.
- The PROPCADE should probably be used instead of EXTMEM in BSTART/BREAD/BWRITE.
- BUSERR is necessary for any ext. mem. device and ifdef EXTMEM makes sense there.
It would be nice if there was a read-only attribute per page for devices such as flash/eeprom etc....Now, I'll see if I can integrate a JVM that uses VMCOG with my old style EDO DRAM device [noparse]:)[/noparse]
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I actually used BSTART setting up addr, ptr, count and a couple of lines of TriBlade access code that was executed only once on ZiCog start up. Perhaps that could be done away with but with only two longs left it won't fit just now.
I added #ifdef PROPCADE among others in the B* functions.
No, "#ifdef PROPCADE" should not be used instead of "#ifdef EXTMEM". As EXTMEM is a big switch that turns on/off external RAM usage on all platforms. Perhaps just for test purposes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Nice! I am glad you got it working with TriBlade#2 easily!
I will look for the bug.
I am considering re-organizing the code a bit to make it easier to add more targets.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Ah, don't worry, I was up to v0.93 as of last night [noparse]:)[/noparse]
I will clean up declarations etc soon.
I will check out the vmaddr issue. BREAD/BWRITE are supposed to take two arguments:
vmaddr - the virtual address of the page, low 9 bits 0'd
hubaddr - the physical location for the page in the working set, low 9 bits 0'd
If in my frenzy to get it running I busted that simple scheme, I will fix it [noparse]:)[/noparse]
I *LIKE* the idea of read-only pages!
The original concept was that only BREAD/BWRITE are exposed, BSTART came later to save cog space for code common to BREAD/BWRITE.
EXTMEM is appropriate for BREAD/BWRITE as if external memory is turned of, one cannot page [noparse]:)[/noparse]
More later...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/5/2010 7:04:17 PM GMT
I will re-factor to the original intent, and make it easier to port.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Thanks for the feedback!!!
I will do some cleanup and re-organization today, to go back to my original intention. Then I will find that pesky startup bug [noparse]:)[/noparse]
I will go back to the absolute minimal interface for BREAD and BWRITE:
vmaddr = virtual memory address, low 9 bits must be 0
hubaddr = hub resident page address, low bits must be 0
BSTART is only a suggestion, in case some code can be shared between BREAD and BWRITE.
I edited out an earlier suggestion about include files - BST does not support them yet. Pity.
Your thoughts?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/5/2010 7:36:18 PM 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
There's nothing wrong with BSTART as long as the intention of it is perfectly clear. It makes sense to have for I2C devices and would also be used for a faster read-only EEPROM fetch.
It's fine to keep EXTMEM though the version I was using would throw a warning if not defined. Having seen some of the v093 now, it makes sense to have that not defined if not using external memory ... which I suppose is good for testing.
I like the idea of breaking up the source. I really despise having to wade through a plethora if ifdef/endifs more than once to read code. Using #includes for platform specific code is just fine. ... BTW vmplatform.spin is clearer than vmpage.spin but I'll take what ever you specify I guess i'll have to see an example to understand the vmpage intention.
I need one ifdef/endif at vmcog init to set pointers for inter-cog communications. I doubt if my EDO DRAM code from 2.5 years ago would fit in vmcog even if I optimized it. BTW I see you didn't ifdef the PROPCADE specific code there.
If you find a good "freeze point", I'll need to add my code so I don't have to re-code for every new version produced.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Post Edited (jazzed) : 6/5/2010 7:51:02 PM GMT
I will add a BINIT section at the top, note how the initialization code area is re-used for TLB entries, so I don't want to make it a subroutine.
I am refactoring the code a bit... BSTART is no longer required, the only interface between VMCOG and the external memory that will be required is BINIT/BREAD/BWRITE
I throw a warning so people don't forget to turn on the external access (except when testing basic functionality).
Now I just have to get BradC to add #include to BST...
There is more space than you think - I had a "FIT 360" at the end so your EDO code should fit!
I see what you mean about vmpager. Perhaps I will change it to "vmhardware.spin".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
- moves to three digits following decimal for version numbers [noparse]:)[/noparse]
- integrates TriBlade_2 code from heater
- some cleanup
- ifdef PROPCADE on rest of PROPCADE specific code
- added BINIT section at the top
- preliminary shr_hits code, not debugged
I am attaching it here; I will update p.1 after I check out the vmaddr/hubaddr behavior in BREAD/BWRITE
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/5/2010 8:43:10 PM GMT
It does not stand up to more than a cursory test. Do I have the start parameters right?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
to swap by simply reading writing between $0 and $200. Sometimes after a swap data is 0 if I
read the address, but seems to be there when I dump the page and on another read.
Thought I would try non EXTMEM mode to see if that works, but can't get more than one page going.
I'll look at this more later ... I have other commitments now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I traced the code from waitcmd on - BREAD/BWRITE are getting their parameters correctly from what I can see.
vmaddr = virtual address
hubptr = hub address
I added a line to the TriBlade code to clear the low address bits, that may have been the problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/5/2010 11:13:11 PM 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