I may have time to implement READONLY later today; if not, my plan is to change the LUT entries as follows:
' LUT Entry values take the following form:
'
' if 0, page is not present in memory
'
' if not 0, the 32 bits are interpreted as:
'
' CCCCCCCC CCCCCCCC CCCCWDP PPPPPPPP
' where
'
' PPPPPPPPPP = hub address, upper 9 bits of up to 18 bit address, 000xxxxxx on Prop1
'
' D = Dirty bit - This bit is set whenever a write is performed to any byte(s) in the page
'
' L = Locked bit - set whenever the physical memory page is locked into the hub and may not be swapped out
'
' W = Write protected, probably from FLASH / EEPROM, but can be used to write-protect a RAM page as well
'
This does reduce the hit access count to 20 bits, but the (untested) shr_hits routine compensates for this.
This makes a lot of sense. I have wondered though why you did not use bit 31 for some flag since it's so easy to read.
I wish there was an alternative for a smaller block read in the case of slower devices ... I can only dream [noparse]:)[/noparse]
Bill Henning said...
If someone wants to submit some nice, small, fast (but speed tunable for fast/slow eeproms) I2C code for BINIT/BREAD/BWRITE/BDATA there is no reason that there can't be an EEPROM VMCOG - however for such a VMCOG, a write-through strategy makes a lot more sense, so BWRITE would have to take a size: 1/2/4 bytes, and the DIRTY flag would not be maintained.
For a JVM, using hub memory for the stack and heap, but VM for code would be an interesting mix.
This is exactly my plan since I can now map the bytecode above $8000.
There should be no conflicts with any read-only TLB tag changes you make.
As for BWRITE, I will not consider supporting that until read-only tags are available.
I already have some functional EE I2C PASM to incorporate.
For the time being, I will not even try to support multi-master mode since I've never seen that work.
Bill Henning said...
I have a 12 pin CPLD based design that is just waiting for me to have time after UPEW to test and have boards made.
This sounds familiar I've no plans for designing with CPLDs at this point.
I would however really like to get that PSRAM mctrivia started working. Also the Micron 32MB SDRAM needs to work some day
Now if we can just get someone to make such an SDCOG...
Hmm, yes, it actually makes sense to convert all virtual machines to take startup parameters / control via a mailbox.
heater said...
Bill: "...the low-level SD card stuff (initialize, send command, read status, read sector, write sector) needs to be totally split out from the file system and made mailbox based."
That would be excellent. Useful for the Z80, 6502 emulators as well.
By the way shouldn't the Zogs be converted to uses mailboxes as well?
jazzed said...
This makes a lot of sense. I have wondered though why you did not use bit 31 for some flag since it's so easy to read.
I wish there was an alternative for a smaller block read in the case of slower devices ... I can only dream [noparse]:)[/noparse]
I think you see it now... by adding a hitincrement, I can check for carry out, and only call shr_hits when needed [noparse]:)[/noparse]
jazzed said...
Bill Henning said...
If someone wants to submit some nice, small, fast (but speed tunable for fast/slow eeproms) I2C code for BINIT/BREAD/BWRITE/BDATA there is no reason that there can't be an EEPROM VMCOG - however for such a VMCOG, a write-through strategy makes a lot more sense, so BWRITE would have to take a size: 1/2/4 bytes, and the DIRTY flag would not be maintained.
For a JVM, using hub memory for the stack and heap, but VM for code would be an interesting mix.
This is exactly my plan since I can now map the bytecode above $8000.
There should be no conflicts with any read-only TLB tag changes you make.
As for BWRITE, I will not consider supporting that until read-only tags are available.
I already have some functional EE I2C PASM to incorporate.
For the time being, I will not even try to support multi-master mode since I've never seen that work.
jazzed said...
Bill Henning said...
I have a 12 pin CPLD based design that is just waiting for me to have time after UPEW to test and have boards made.
This sounds familiar I've no plans for designing with CPLDs at this point.
LOL... [noparse]:)[/noparse]
I know, lots of people have suggested 12 pin CPLD ram interfaces... however I do believe I've come up with something different/interesting [noparse]:)[/noparse]
Actually, I can do it with a 9 pin interface, but it would be too slow for my uses then.
jazzed said...
I would however really like to get that PSRAM mctrivia started working. Also the Micron 32MB SDRAM needs to work some day
Cheers,
--Steve
I feel bad about mctrivia's Morpheus interface for it - he made a nice 4"x3" board for interfacing it to Morpheus, but I have let him down as I have not had time to tackle it yet. Between some high priority projects for clients, working on the about-to-be-shown new Morpheus versions, and other products for UPEW, I simply have not had time to get it running yet.
It is fairly high on my TODO list, and should work great.
I also agree about those nice 32MBx8 Micron (and other) TSOP-54 SDRAM's... they are also on my list, and I have had 5 samples sitting here for MONTHS.
add a second set of {rd|wr}v{byte|word|long} .. {rd|wr}c{byte|word|long} for code access.
That would give two separate memory spaces of $000000-$7FFFFF - one each for code and data, and the code segment could have the WRITEPROT bit set by default.
I like either option with possibly a #define to disable read-only access.
I usually do not embed #defines in a file, but see value in it sometimes.
--
One of the things I found is if I tried to pass the physical back-store
address to read as $8000 I would get the data from $0000. Can you
look into that? I can't see how except in vflush, but I find that the
requested address is being masked some way.
For the time being I'm just mapping address 0 to $8000 in the driver.
--
Also, for now I'm just leaving the IO pins statically defined as 28/29,
but have a provision for taking them from the user mailbox that costs
several longs.
Can you let us know how the mailbox struct should work for pins, etc... ?
Cannot verify to the end of sequence with Gear, too slow... I really wish it was written in old plain C.
However, the logic probe page·is very useful to have a peek at page activity.
- more hardware drivers!
- ZiCog
- MotoCog
- BigSpin
- as many other emulators as possible!
VMCOG is currently limited to 64KB of virtual memory; this limit will be increased to at least 512KB when I switch to a hub-based "page present" table.
I have just updated the first post with version 0.967, and I now declare VMCOG to be in BETA test [noparse]:)[/noparse]
File XEDODRAM_1M.spin from page 8 .zip package should be included some way maybe in the first post?
Not to nit-pick much, but heater did the Triblade stuff [noparse]:)[/noparse]
' Jun10 v0.966 - merged latest TriBlade_2_0.9 code from jazzed
' Jun10 v0.967 - merged HYDRA HX512 support by Antoine Doinel, moved DAT to platform DAT area
I'll post EERDONLY diffs later when I have the JVM running from vmcog.
Running off to make corrections... will post new zip later (wife is calling).
Funny, I attributed correctly in earlier comments, guess not enough coffee today!
jazzed said...
Bill Henning said...
UPDATE:
I have just updated the first post with version 0.967, and I now declare VMCOG to be in BETA test [noparse]:)[/noparse]
File XEDODRAM_1M.spin from page 8 .zip package should be included some way maybe in the first post?
Not to nit-pick much, but heater did the Triblade stuff [noparse]:)[/noparse]
' Jun10 v0.966 - merged latest TriBlade_2_0.9 code from jazzed
' Jun10 v0.967 - merged HYDRA HX512 support by Antoine Doinel, moved DAT to platform DAT area
I'll post EERDONLY diffs later when I have the JVM running from vmcog.
AntoineDoinel: That trace looks correct. Do try it with SINGLE_STEP undefined, you should get the same output I have posted here before. Great work. Hydra owners will soon be able to run the Z80 and other emulators.
Bill: OK BETA testing away.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Attached is a VMCOG for TriBlade (v0.10) with the optimizations put back in.
The read and write loops are down to 6 and 8 instructions respectively which is the best I can do. Also saves a few LONGs.
Unlike the previous optimization attempt this passes the random fill test in the "heater" test and runs with ZOG.
Sorry it's not quite up to to date with vmcog v0.967.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hi steve, I just noticed I did not fully respond yesterday...
I prefer the address range split, with a #define to turn off the WRPROT flag setting - this would need fewer longs in the cog
I am still looking for it, the only place I mask with $7FFF that I found so far is in an #ifdef PROPCADE block.
jazzed said...
@Bill,
I like either option with possibly a #define to disable read-only access.
I usually do not embed #defines in a file, but see value in it sometimes.
--
One of the things I found is if I tried to pass the physical back-store
address to read as $8000 I would get the data from $0000. Can you
look into that? I can't see how except in vflush, but I find that the
requested address is being masked some way.
For the time being I'm just mapping address 0 to $8000 in the driver.
--
Also, for now I'm just leaving the IO pins statically defined as 28/29,
but have a provision for taking them from the user mailbox that costs
several longs.
Can you let us know how the mailbox struct should work for pins, etc... ?
@Bill, I find that the mailbox command long must contain a non-zero value at vm.start(...) so that when start is done, we know the first flush is finished. Is it possible for start to set the initial value to non-zero?
@heater if you want an EERDONLY diff let me know. You'll have to get rid of the Parallax UTF16 Font junk to use patch though.
I can fetch bytecodes to the JVM, but am still at a loss as to why I can't just give the EEPROM read code address $8000 via vmaddr ....
I owe my wife garden time, so I won't be very active with Propeller stuff the rest of the day.
One of the things I found is if I tried to pass the physical back-store
address to read as $8000 I would get the data from $0000. Can you
look into that? I can't see how except in vflush, but I find that the
requested address is being masked some way.
For the time being I'm just mapping address 0 to $8000 in the driver.
I am trying to track this down - but something just occurred to me:
Is this what you are trying to do?
vm.start(@mailbox,$8000,12) ' start up VMCOG
If so, the problem is that the last valid page address is the start of the page address, so if you want $7E00-$7FFF to be included as the last page in the working set, you should be using:
vm.start(@mailbox,$7E00,12) ' start up VMCOG
jazzed said...
Also, for now I'm just leaving the IO pins statically defined as 28/29,
but have a provision for taking them from the user mailbox that costs
several longs.
Can you let us know how the mailbox struct should work for pins, etc... ?
General format for a mailbox:
mbox[noparse][[/noparse]0]: command in S (bits 0-8), rest is defined by cog
mbox: pointer
mbox: data
mbox: cog dependant <-- perfect place for pins
I changed the definition of start() so it sets cmd to $FFFF0000 before cognew. When initialization is finished, it will be cleared automatically.
I'll post another release tonight or tomorrow morning.
Your vmaddr problem puzzles me, the fill-word test shows that PropCade handles vmaddr $8000-$FFFF just fine...
jazzed said...
@Bill, I find that the mailbox command long must contain a non-zero value at vm.start(...) so that when start is done, we know the first flush is finished. Is it possible for start to set the initial value to non-zero?
@heater if you want an EERDONLY diff let me know. You'll have to get rid of the Parallax UTF16 Font junk to use patch though.
I can fetch bytecodes to the JVM, but am still at a loss as to why I can't just give the EEPROM read code address $8000 via vmaddr ....
I owe my wife garden time, so I won't be very active with Propeller stuff the rest of the day.
Yep, the first prototype run of PropCade worked well (ok one minor RS485 issue, corrected in new rev)
I should get the new revision PCB's with easy RS485 daisy chaining within the next couple of days!
I'd love to get Battlez0ned running on RS485 between two PropCade's, but I don't think I'll have time to do that before UPEW. Ah well, I can always upload a video later...
jazzed said...
Thanks Bill.
Startup in vmdebug for EERDONLY is like normal. I'm puzzled too. Nice to know PROPCADE works [noparse]:)[/noparse]
Bill, over in the "What should a Propeller OS have" thread you stated that "Minos is VMCOG/ZOG/gcc based."
Well, just now we have "Big Zog" that implements all ZPU instructions in PASM and is now cabable of executing ZPU code from HUB or external memory. This is about as fast as we can make it but has the slight inconvenience that it currently requires a dispatch table in HUB.
There is also "Little Zog" which implements only the base set of ZPU instructions in PASM the rest being handled using the ZPU EMULATE feature. Basically like a software interrupt that vectors off to some ZPU code to implement the missing instructions. This is slower but saves a lot of COG space so the dispatch table is in COG. A totally self contained binary blob. There is still room to migrate ops from EMULATE to PASM so we could get a lot of speed back. Perhaps after some profiling to see which would be the most helpful to convert.
So to my question, is the inconvenience of the HUB dispatch table for Big Zog a big problem for Minos? Should I keep hold of Little Zog, which was only a side experiment really, and fit it out with external RAM capability?
Either way I'd like to strip all PASM code of one and/or both Zogs out into a separate stand alone spin files that can be compiled into binary blobs that are just Zog. Hopefully with mailbox interfaces. The Current Spin support code continuing in another module.
Sounds like we want to be able to load HUB/ext RAM with ZPU binary from wherever. Load Zog binary into a COG from where ever and then set it running. As I said before HUB Zog should be able to start and support Ext RAM Zog. There should be no Spin anywhere.
Not sure how to proceed with all this but it's formulating...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
How big is the hub dispatch table? Unless it is HUGE I don't see it as a problem.
We can benchmark it later, but I have a feeling "Big Zog" will be faster, as i suspect the speed penalty for EMULATE is high. The nice thing is with VMCOG the size of the working set can be tuned! I think both approaches should be tried & benchmarket.
I agree - ZOG.COG (LOL) should be dynamically loaded, and a mailbox interface would be ideal.
Suggested initial startup set of mailbox values:
mbox[noparse][[/noparse]0] := Minos system table base address (stdio mbox's etc)
mbox := virtual base address (within vm), also starts running there
mbox := virtual limit (last usable address by zog)
mbox := pointer to command line on entry / return code on exit
What I am thinking is that the initial bootloader would launch the driver cogs, set up a system table (pointing at mailboxes), and launch the program specified by INIT.D
The boot loader would be smart enough to use the right loader (ie .ZOG's are loaded into the vm, then ZOG.COG launched with correct arguments)
If we do this right, the boot loader would (initially at least) be a Spin environment, with fsrw26, that after loading the files specified by MODULES would hand over control to a ZOG shell, which would have a file system written in C.
It would even be possible to build static ZOG libraries, to be loaded at specific virtual addresses, that can be called by loaded apps.
Done correctly I think only 4KB of the hub needs to be reserved for the system. Leaving 28KB as a working set [noparse]:)[/noparse]
Once Lock() and Unlock() work, even frame buffers can be allocated by ZOG.
p.s.
It's actually funny how it came about... DracBlade latches lead me to design VMCOG, which lead me to design PropCade... at the same time you were working on Zog... once I tried that and saw how easily Gcc produced Zog code, it got me thinking of a cut-down Largos, based on Zog and GCC, instead of waiting another year or so to get LMM/Catalina Largos running - think of it as a more advanced prototype of Largos than the shell I showed last year.
Now we are getting there...
p.p.s.
Both Largos and Minos will have command line arguments and a return code [noparse]:)[/noparse]
Big Zog's HUB dispatch table is rather large at 256 WORDS. Built for raw speed.
However 50% of entries are for IM so for the cost of a test for IM on each fetch we could halve that.
Similarly the next 25% of it is LOADSP/STORESP so for anther cost of a couple of tests per fetch we could halve the size again.
Little Zog does this and ends up with a 64 LONG jump table in COG.
Depends were one would like to make the speed/size trade off. Actually handling IM with a PASM test may be quicker than having it the dispatch table as IM is about the most commonly used op code.
Anyway, I'm going to fit out Little Zog with VMCog support, just looked at it again it should be easy enough. Then we can chop and change between them as we see fit.
I still don't have a RAM to get my DracBlade going but it occurs to me it's time to get VMCog using the latched RAM that sits on my TriBlade blade #1.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Bill Henning said...
So I suggest "vi MODULES" followed by "reboot"
That sounds fine with fast boot time. I'm very happy with the modules concept you've presented.
You should really define the minos features somewhere so I don't have to ask more silly questions [noparse]:)[/noparse]
(Today's yard work all done!)
I would like to try building some shell features. So much to do, so little time ....
LOL... trading 512 bytes - one page from the working set - for more interpretation speed is a no brainer!
I don't think the difference between 256 bytes or 512 bytes is worth the loss of interpretation speed, but you are correct on the frequency of IM.
I will be using a 1KB hub table to provide a quick "page present" test in the next version of VMCOG (which will support a 512KB VM)
Hmm... I see I should add #define TRIBLADE_1 tonight.
Yep, I think "mash" will be the name of the shell for Minos...
heater said...
Big Zog's HUB dispatch table is rather large at 256 WORDS. Built for raw speed.
However 50% of entries are for IM so for the cost of a test for IM on each fetch we could halve that.
Similarly the next 25% of it is LOADSP/STORESP so for anther cost of a couple of tests per fetch we could halve the size again.
Little Zog does this and ends up with a 64 LONG jump table in COG.
Depends were one would like to make the speed/size trade off. Actually handling IM with a PASM test may be quicker than having it the dispatch table as IM is about the most commonly used op code.
Anyway, I'm going to fit out Little Zog with VMCog support, just looked at it again it should be easy enough. Then we can chop and change between them as we see fit.
I still don't have a RAM to get my DracBlade going but it occurs to me it's time to get VMCog using the latched RAM that sits on my TriBlade blade #1.
I will make a Minos feature set document soon... I am still working on it.
Basically, SD with fsrw during boot, MODULES and INIT.D, and I suspect mostly .ZOG executables. .COG drivers/vm's.
I desperately need an SD cog, with a mailbox interface, and an fsrw26 modified to use that. Once we have those, work on the boot loader can be started.
Once the bootloader can process MODULES and INIT.D, it is time to write mash.zog
The idea is that small C version of FAT support can be compiled with Gcc to zog code, so it can run from the virtual memory.
Then it is just more mailbox drivers, and utilities. I also want to support spin bytecode executables, but ideally with a "BigSpin" interpreter - OR - they take over the 24KB left after the Minos system area until BigSpinVM exists.
The ideas are gelling in my head... ie what subset of Largos features are needed / feasible.
For "compatibility", I think mash scripts should still have a plain ".sh" extension
And I *REALLY* want to see Sphinx running under Minos. Combined with BigSpinVM it would be a killer combination.
jazzed said...
Bill Henning said...
So I suggest "vi MODULES" followed by "reboot"
That sounds fine with fast boot time. I'm very happy with the modules concept you've presented.
You should really define the minos features somewhere so I don't have to ask more silly questions [noparse]:)[/noparse]
(Today's yard work all done!)
I would like to try building some shell features. So much to do, so little time ....
For the moment, I think a good starting point would be to strip down one of the existing boot loaders - perhaps the one Dr_Acula suggested - and make an eeprom image that has enough of fsrw to load the virtual memory, start full duplex serial, and the ZOG spin system environment.
Then optimize this to use as little space as possible, so the working set can be as large as possible.
Over time, this initial bootloader can be transformed into what I described, in easy managable steps:
- modifying FullDuplexSerial's cog driver to become "serial.cog", and mailbox based. Poof - it can now be loaded from SD, we get back more hub space
- modifying the low-level SD cog image so that it works based on a mailbox, and modifying fsrw to use it. This will actually use a bit more memory.
- get a C based FAT file system running within ZOG, using the SD.COG via the mailbox interface.
Guess what? At this point, after launching serial.cog, sd.cog, vmcog.cog, and zog.cog, the spin cog can be stopped, and the hub memory re-used properly, increasing the size of the working set. Yes, the devil is in the details (the TLB will need to be re-initialized, but the VM contents will be correct) - but this gives us a rough development roadmap.
Comments
I wish there was an alternative for a smaller block read in the case of slower devices ... I can only dream [noparse]:)[/noparse]
This is exactly my plan since I can now map the bytecode above $8000.
There should be no conflicts with any read-only TLB tag changes you make.
As for BWRITE, I will not consider supporting that until read-only tags are available.
I already have some functional EE I2C PASM to incorporate.
For the time being, I will not even try to support multi-master mode since I've never seen that work.
This sounds familiar
I would however really like to get that PSRAM mctrivia started working. Also the Micron 32MB SDRAM needs to work some day
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Hmm, yes, it actually makes sense to convert all virtual machines to take startup parameters / control via a mailbox.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 think you see it now... by adding a hitincrement, I can check for carry out, and only call shr_hits when needed [noparse]:)[/noparse]
LOL... [noparse]:)[/noparse]
I know, lots of people have suggested 12 pin CPLD ram interfaces... however I do believe I've come up with something different/interesting [noparse]:)[/noparse]
Actually, I can do it with a 9 pin interface, but it would be too slow for my uses then.
I feel bad about mctrivia's Morpheus interface for it - he made a nice 4"x3" board for interfacing it to Morpheus, but I have let him down as I have not had time to tackle it yet. Between some high priority projects for clients, working on the about-to-be-shown new Morpheus versions, and other products for UPEW, I simply have not had time to get it running yet.
It is fairly high on my TODO list, and should work great.
I also agree about those nice 32MBx8 Micron (and other) TSOP-54 SDRAM's... they are also on my list, and I have had 5 samples sitting here for MONTHS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Meanwhile here is preliminary dump from EEPROM using vmdebug ... there are 65 longs left for adding writes
Enter HEX Address: 0 Virtual Addr: $00000000 Physical Addr: $3E00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 000: A4 22 01 26 00 2C 03 51 00 B7 00 4B 21 06 00 00 010: 03 D4 21 D0 03 51 00 04 00 00 18 38 00 00 02 00 020: 00 06 C3 00 00 06 08 00 06 D8 00 00 00 02 00 07 030: 32 00 00 02 02 00 07 61 00 00 02 00 00 07 84 00 040: 00 03 51 00 04 00 00 18 38 00 00 02 00 00 07 89 050: 00 00 02 00 00 07 AE 00 00 02 00 00 07 B1 00 00 060: 02 A7 12 04 00 00 18 38 00 00 02 04 00 07 B6 00 070: 00 04 00 00 07 F2 00 00 04 00 00 07 E9 00 00 04 080: 00 00 17 18 00 00 02 00 00 17 26 00 00 02 00 00 090: 17 3C 00 00 02 00 00 17 46 00 00 02 02 00 17 4F 0A0: 00 00 08 10 00 08 09 00 00 06 06 00 08 BE 00 00 0B0: 00 00 00 09 ED 00 00 03 51 04 04 00 00 18 38 00 0C0: 00 02 00 00 09 F2 00 00 02 00 00 09 F4 00 00 04 0D0: 00 00 09 F9 00 00 02 00 00 0A 00 00 00 04 00 00 0E0: 0A 05 00 00 02 02 00 0A 11 00 00 04 06 00 0A 27 0F0: 00 00 04 02 00 0A DD 00 00 04 06 00 0B 0D 00 00 100: 04 06 00 0B 6B 00 00 04 16 00 0B AF 00 00 02 00 110: 00 0C 3F 00 00 04 00 00 0C 49 00 00 04 02 00 0C 120: 52 00 00 04 02 00 0C 80 00 00 03 51 00 04 00 00 130: 18 38 00 00 02 00 00 0C B2 00 00 02 00 00 0C DC 140: 00 00 02 00 00 0C EE 00 00 02 06 00 0D 06 00 00 150: 02 02 00 0D 2D 00 00 04 04 00 0D 3D 00 00 02 06 160: 00 0D 74 00 00 02 00 00 0D CA 00 00 02 00 00 0D 170: D6 00 00 04 00 00 0D E5 00 00 04 00 00 0D F4 00 180: 00 04 00 00 0E 00 00 00 04 00 00 0E 12 00 00 04 190: 00 00 0E 21 00 00 04 00 00 0E 30 00 00 04 00 00 1A0: 0E 3C 00 00 04 00 00 0E 46 00 00 06 00 00 0E 53 1B0: 00 00 06 00 00 0E 60 00 00 06 00 00 0E 6A 00 00 1C0: 06 00 00 0E 7A 00 00 06 00 00 0E 87 00 00 06 00 1D0: 00 0E 94 00 00 06 00 00 0E 9E 00 00 06 00 00 0E 1E0: A8 00 00 08 00 00 0E B5 00 00 08 00 00 0E C2 00 1F0: 00 08 00 00 0E CC 00 00 08 00 00 0E DC 00 00 08 VMDebug Main Menu 1) View Page Table 2) Flush Page Table ... ' output from EEprog32Kplus program ... Read from Next 32K EEPROM 8000: A4 22 01 26 00 2C 03 51 00 B7 00 4B 21 06 00 00 8010: 03 D4 21 D0 03 51 00 04 00 00 18 38 00 00 02 00 8020: 00 06 C3 00 00 06 08 00 06 D8 00 00 00 02 00 07 8030: 32 00 00 02 02 00 07 61 00 00 02 00 00 07 84 00 8040: 00 03 51 00 04 00 00 18 38 00 00 02 00 00 07 89 8050: 00 00 02 00 00 07 AE 00 00 02 00 00 07 B1 00 00 8060: 02 A7 12 04 00 00 18 38 00 00 02 04 00 07 B6 00 8070: 00 04 00 00 07 F2 00 00 04 00 00 07 E9 00 00 04 8080: 00 00 17 18 00 00 02 00 00 17 26 00 00 02 00 00 8090: 17 3C 00 00 02 00 00 17 46 00 00 02 02 00 17 4F 80A0: 00 00 08 10 00 08 09 00 00 06 06 00 08 BE 00 00 80B0: 00 00 00 09 ED 00 00 03 51 04 04 00 00 18 38 00 80C0: 00 02 00 00 09 F2 00 00 02 00 00 09 F4 00 00 04 80D0: 00 00 09 F9 00 00 02 00 00 0A 00 00 00 04 00 00 80E0: 0A 05 00 00 02 02 00 0A 11 00 00 04 06 00 0A 27 80F0: 00 00 04 02 00 0A DD 00 00 04 06 00 0B 0D 00 00 8100: 04 06 00 0B 6B 00 00 04 16 00 0B AF 00 00 02 00 8110: 00 0C 3F 00 00 04 00 00 0C 49 00 00 04 02 00 0C 8120: 52 00 00 04 02 00 0C 80 00 00 03 51 00 04 00 00 8130: 18 38 00 00 02 00 00 0C B2 00 00 02 00 00 0C DC 8140: 00 00 02 00 00 0C EE 00 00 02 06 00 0D 06 00 00 8150: 02 02 00 0D 2D 00 00 04 04 00 0D 3D 00 00 02 06 8160: 00 0D 74 00 00 02 00 00 0D CA 00 00 02 00 00 0D 8170: D6 00 00 04 00 00 0D E5 00 00 04 00 00 0D F4 00 8180: 00 04 00 00 0E 00 00 00 04 00 00 0E 12 00 00 04 8190: 00 00 0E 21 00 00 04 00 00 0E 30 00 00 04 00 00 81A0: 0E 3C 00 00 04 00 00 0E 46 00 00 06 00 00 0E 53 81B0: 00 00 06 00 00 0E 60 00 00 06 00 00 0E 6A 00 00 81C0: 06 00 00 0E 7A 00 00 06 00 00 0E 87 00 00 06 00 81D0: 00 0E 94 00 00 06 00 00 0E 9E 00 00 06 00 00 0E 81E0: A8 00 00 08 00 00 0E B5 00 00 08 00 00 0E C2 00 81F0: 00 08 00 00 0E CC 00 00 08 00 00 0E DC 00 00 08I'll post diffs for you later.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
That looks good!
I see I have a lot of code to pull into VMCOG [noparse]:)[/noparse]
I am considering a small hack. Consider...
The current scheme supports 8MB of virtual memory (max) - so $000000-$7FFFFF is the valid address range.
What if I split that into two areas?
$000000-$3FFFFF = ram, normally not write protected
$400000-$4FFFFF = eeprom/flash/sd code space, normally write protected
OR, assuming enough cog space is left for it...
add a second set of {rd|wr}v{byte|word|long} .. {rd|wr}c{byte|word|long} for code access.
That would give two separate memory spaces of $000000-$7FFFFF - one each for code and data, and the code segment could have the WRITEPROT bit set by default.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 like either option with possibly a #define to disable read-only access.
I usually do not embed #defines in a file, but see value in it sometimes.
--
One of the things I found is if I tried to pass the physical back-store
address to read as $8000 I would get the data from $0000. Can you
look into that? I can't see how except in vflush, but I find that the
requested address is being masked some way.
For the time being I'm just mapping address 0 to $8000 in the driver.
--
Also, for now I'm just leaving the IO pins statically defined as 28/29,
but have a provision for taking them from the user mailbox that costs
several longs.
Can you let us know how the mailbox struct should work for pins, etc... ?
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I fixed two·bugs, and·shaved a few instructions in the Hydra driver.
Now it appear to execute Zog:
Cannot verify to the end of sequence with Gear, too slow... I really wish it was written in old plain C.
However, the logic probe page·is very useful to have a peek at page activity.
I have just updated the first post with version 0.967, and I now declare VMCOG to be in BETA test [noparse]:)[/noparse]
Hardware currently supported by VMCOG:
- PropCade (SPI ram)
- TriBlade_2 (Parallel ram)
- XEDODRAM (dynamic ram)
- Hydra HX512 (cpld driven parallel ram)
Software currently using VMCOG:
- VMDEBUG
- ZOG
Software I would like to see for VMCOG:
- more hardware drivers!
- ZiCog
- MotoCog
- BigSpin
- as many other emulators as possible!
VMCOG is currently limited to 64KB of virtual memory; this limit will be increased to at least 512KB when I switch to a hub-based "page present" 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
Not to nit-pick much, but heater did the Triblade stuff [noparse]:)[/noparse]
I'll post EERDONLY diffs later when I have the JVM running from vmcog.
Cheers [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Running off to make corrections... will post new zip later (wife is calling).
Funny, I attributed correctly in earlier comments, guess not enough coffee today!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/11/2010 2:26:08 AM GMT
Bill: OK BETA testing away.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The read and write loops are down to 6 and 8 instructions respectively which is the best I can do. Also saves a few LONGs.
Unlike the previous optimization attempt this passes the random fill test in the "heater" test and runs with ZOG.
Sorry it's not quite up to to date with vmcog v0.967.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Is that just diff and patch? stephenjungels.com/jungels.net/articles/diff-patch-ten-minutes.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
But yes, he is using diff/patch.
So far, I have been updating the drivers manually; but this weekend I am thinking of automating it.
Just because there is no #include in BST does not mean it could not be pre-processed [noparse]:)[/noparse]
Thanks, I will merge in .10 later today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 prefer the address range split, with a #define to turn off the WRPROT flag setting - this would need fewer longs in the cog
I am still looking for it, the only place I mask with $7FFF that I found so far is in an #ifdef PROPCADE block.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
@heater if you want an EERDONLY diff let me know. You'll have to get rid of the Parallax UTF16 Font junk to use patch though.
I can fetch bytecodes to the JVM, but am still at a loss as to why I can't just give the EEPROM read code address $8000 via vmaddr ....
I owe my wife garden time, so I won't be very active with Propeller stuff the rest of the day.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I am trying to track this down - but something just occurred to me:
Is this what you are trying to do?
If so, the problem is that the last valid page address is the start of the page address, so if you want $7E00-$7FFF to be included as the last page in the working set, you should be using:
General format for a mailbox:
mbox[noparse][[/noparse]0]: command in S (bits 0-8), rest is defined by cog
mbox: pointer
mbox: data
mbox: cog dependant <-- perfect place for pins
Hope this helps!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 changed the definition of start() so it sets cmd to $FFFF0000 before cognew. When initialization is finished, it will be cleared automatically.
I'll post another release tonight or tomorrow morning.
Your vmaddr problem puzzles me, the fill-word test shows that PropCade handles vmaddr $8000-$FFFF just fine...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Startup in vmdebug for EERDONLY is like normal. I'm puzzled too. Nice to know PROPCADE works [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I am sure you will find the issue.
Yep, the first prototype run of PropCade worked well (ok one minor RS485 issue, corrected in new rev)
I should get the new revision PCB's with easy RS485 daisy chaining within the next couple of days!
I'd love to get Battlez0ned running on RS485 between two PropCade's, but I don't think I'll have time to do that before UPEW. Ah well, I can always upload a video 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
Well, just now we have "Big Zog" that implements all ZPU instructions in PASM and is now cabable of executing ZPU code from HUB or external memory. This is about as fast as we can make it but has the slight inconvenience that it currently requires a dispatch table in HUB.
There is also "Little Zog" which implements only the base set of ZPU instructions in PASM the rest being handled using the ZPU EMULATE feature. Basically like a software interrupt that vectors off to some ZPU code to implement the missing instructions. This is slower but saves a lot of COG space so the dispatch table is in COG. A totally self contained binary blob. There is still room to migrate ops from EMULATE to PASM so we could get a lot of speed back. Perhaps after some profiling to see which would be the most helpful to convert.
So to my question, is the inconvenience of the HUB dispatch table for Big Zog a big problem for Minos? Should I keep hold of Little Zog, which was only a side experiment really, and fit it out with external RAM capability?
Either way I'd like to strip all PASM code of one and/or both Zogs out into a separate stand alone spin files that can be compiled into binary blobs that are just Zog. Hopefully with mailbox interfaces. The Current Spin support code continuing in another module.
Sounds like we want to be able to load HUB/ext RAM with ZPU binary from wherever. Load Zog binary into a COG from where ever and then set it running. As I said before HUB Zog should be able to start and support Ext RAM Zog. There should be no Spin anywhere.
Not sure how to proceed with all this but it's formulating...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, it is starting to gell.
How big is the hub dispatch table? Unless it is HUGE I don't see it as a problem.
We can benchmark it later, but I have a feeling "Big Zog" will be faster, as i suspect the speed penalty for EMULATE is high. The nice thing is with VMCOG the size of the working set can be tuned! I think both approaches should be tried & benchmarket.
I agree - ZOG.COG (LOL) should be dynamically loaded, and a mailbox interface would be ideal.
Suggested initial startup set of mailbox values:
mbox[noparse][[/noparse]0] := Minos system table base address (stdio mbox's etc)
mbox := virtual base address (within vm), also starts running there
mbox := virtual limit (last usable address by zog)
mbox := pointer to command line on entry / return code on exit
What I am thinking is that the initial bootloader would launch the driver cogs, set up a system table (pointing at mailboxes), and launch the program specified by INIT.D
The boot loader would be smart enough to use the right loader (ie .ZOG's are loaded into the vm, then ZOG.COG launched with correct arguments)
If we do this right, the boot loader would (initially at least) be a Spin environment, with fsrw26, that after loading the files specified by MODULES would hand over control to a ZOG shell, which would have a file system written in C.
It would even be possible to build static ZOG libraries, to be loaded at specific virtual addresses, that can be called by loaded apps.
Done correctly I think only 4KB of the hub needs to be reserved for the system. Leaving 28KB as a working set [noparse]:)[/noparse]
Once Lock() and Unlock() work, even frame buffers can be allocated by ZOG.
p.s.
It's actually funny how it came about... DracBlade latches lead me to design VMCOG, which lead me to design PropCade... at the same time you were working on Zog... once I tried that and saw how easily Gcc produced Zog code, it got me thinking of a cut-down Largos, based on Zog and GCC, instead of waiting another year or so to get LMM/Catalina Largos running - think of it as a more advanced prototype of Largos than the shell I showed last year.
Now we are getting there...
p.p.s.
Both Largos and Minos will have command line arguments and a return code [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
mash (def.) "minos again shell" ... a fermented variant of bash/ksh [noparse]:)[/noparse]
I hope insmod/lsmod/rmmod can also be implemented with char/stream/ioctl interfaces.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Post Edited (jazzed) : 6/11/2010 9:36:30 PM GMT
and the Largos shell can be ... lash [noparse]:)[/noparse]
For now, I am trying to go for the KISS principle, and devices will be loaded from MODULES at startup.
Later... insmod/lsmod/rmmod would not be so difficult to add.
Consider: When MODULES is parsed, and a cog is started, it could save "<cogid> module.cog" into say "MODS"
Then 'lsmod' is same as 'cat MODS'
Rmmod is same as 'kill <cogid>' - assuming kill does a 'cogstop'
Insmod is same as starting a driver with MODULES
however my intention is that Minos be ... umm ... minimal?
So I suggest "vi MODULES" followed by "reboot"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
However 50% of entries are for IM so for the cost of a test for IM on each fetch we could halve that.
Similarly the next 25% of it is LOADSP/STORESP so for anther cost of a couple of tests per fetch we could halve the size again.
Little Zog does this and ends up with a 64 LONG jump table in COG.
Depends were one would like to make the speed/size trade off. Actually handling IM with a PASM test may be quicker than having it the dispatch table as IM is about the most commonly used op code.
Anyway, I'm going to fit out Little Zog with VMCog support, just looked at it again it should be easy enough. Then we can chop and change between them as we see fit.
I still don't have a RAM to get my DracBlade going but it occurs to me it's time to get VMCog using the latched RAM that sits on my TriBlade blade #1.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
#!/bin/mash
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You should really define the minos features somewhere so I don't have to ask more silly questions [noparse]:)[/noparse]
(Today's yard work all done!)
I would like to try building some shell features. So much to do, so little time ....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I don't think the difference between 256 bytes or 512 bytes is worth the loss of interpretation speed, but you are correct on the frequency of IM.
I will be using a 1KB hub table to provide a quick "page present" test in the next version of VMCOG (which will support a 512KB VM)
Hmm... I see I should add #define TRIBLADE_1 tonight.
Yep, I think "mash" will be the name of the shell for Minos...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Basically, SD with fsrw during boot, MODULES and INIT.D, and I suspect mostly .ZOG executables. .COG drivers/vm's.
I desperately need an SD cog, with a mailbox interface, and an fsrw26 modified to use that. Once we have those, work on the boot loader can be started.
Once the bootloader can process MODULES and INIT.D, it is time to write mash.zog
The idea is that small C version of FAT support can be compiled with Gcc to zog code, so it can run from the virtual memory.
Then it is just more mailbox drivers, and utilities. I also want to support spin bytecode executables, but ideally with a "BigSpin" interpreter - OR - they take over the 24KB left after the Minos system area until BigSpinVM exists.
The ideas are gelling in my head... ie what subset of Largos features are needed / feasible.
For "compatibility", I think mash scripts should still have a plain ".sh" extension
And I *REALLY* want to see Sphinx running under Minos. Combined with BigSpinVM it would be a killer combination.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/11/2010 10:39:17 PM GMT
Then optimize this to use as little space as possible, so the working set can be as large as possible.
Over time, this initial bootloader can be transformed into what I described, in easy managable steps:
- modifying FullDuplexSerial's cog driver to become "serial.cog", and mailbox based. Poof - it can now be loaded from SD, we get back more hub space
- modifying the low-level SD cog image so that it works based on a mailbox, and modifying fsrw to use it. This will actually use a bit more memory.
- get a C based FAT file system running within ZOG, using the SD.COG via the mailbox interface.
Guess what? At this point, after launching serial.cog, sd.cog, vmcog.cog, and zog.cog, the spin cog can be stopped, and the hub memory re-used properly, increasing the size of the working set. Yes, the devil is in the details (the TLB will need to be re-initialized, but the VM contents will be correct) - but this gives us a rough development roadmap.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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