Zog - A ZPU processor core for the Prop + GNU C, C++ and FORTRAN.Now replaces S

heater

Announcing the start of a new project:

Zog - An implementation of the Zylin CPU core (ZPU) from Zylin Consulting for a Propeller Cog..
opensource.zylin.com/zpudocs.html

I recently stumbled across the ZPU processor core for FPGA's. Why is this interesting?

1) It is billed as the smallest 32 bit CPU core in the world. In terms of FPGA logic cells required.
2) It has a very minimal instruction set, only a handful of op codes.
3) All op codes are 8 bits wide.
4) Zylin has created a branch of the GCC C compiler targeting the ZPU instruction set.

What does this mean?

Due to 1) and 2) above we can implement this CPU architecture in PASM in one COG.
Due to 3) it is a perfect match for our many external RAM solutions, TriBlade, RamBlade, Morpheous etc etc
It is a 32 bit architecture so we can make us of all the external memory for code/data. A vast improvement on ZiCog for example.
There is the lure of being able to use the GCC C compiler to develop code for the Propeller !
With GCC comes the remote posibility of running uCLinux on the propeller. A step up from CP/M [noparse]:)[/noparse]
Don't hold you hopes up though, Zylin state that the ZPU is not quite up to handling uCLinux.
It will run the eCos embedded operating system.

With Bill Henning's idea for a caching external memory controller COG the ZPU could be really neat.

If anyone is interested in all this a few words of encouragement might set me on my way, this is a long time scale deal as I'm pretty busy nowadays.

Edit : By popular request changed project name to CogZ.

Edit: Again, sorry I could not get on with "Cogz" so renamed it "ZOG".


Project Status:
Edit: 09-02-2010 Ground Zero.
Edit: 18-02-2010 v0.2 - runs GCC compiled C for the first time. No I/O yet.
Edit: 19-02-2010 v0.3 - Fixed problem with offsets larger than 15 in LOADSP and STORESP ops.
Edit: 20-02-2010 v0.4 - Added primitive UART output so that the C run time outbyte() works. Zog now prints to the
console.
Added a Makefile to build the C test program into a loadable binary.

Edit: 28-02-2010 v0.5 - The CONFIG instruction is now always emulated,
see emulate code in libgloss crt0.S for why.
Added handling of the SYSCALL instruction via the io_command trap mechainism.
Added fsrwFemto object (inititialization calls commented out for now).

Edit: 18-04-2010 - Attached ZPU in C version v0.8
This C version will be the "spec" for a vastly optimized ZOG in PASM comming soon...

Edit: 18-04-2010 - Attached ZOG v 0.8
This version has all ZPU ops rewritten with optimizations as suggested by Bill Henning.

Edit: 25-04-2010 - Attached ZPU in C version v0.9
Fixed PUSHSP op. Added RC4 test.

Edit: 25-04-2010 - Attached ZOG v0.9
Fixed PUSHSP op. Added RC4 test.


Edit: 08-05-2010 - Attached ZPU in C v0.10
Fixed endianness of code loading to RAM and byte read/write functions.
Fixed ADDSP
Added #ifdefs such that selected ops can be performed by EMULATE

Edit: 09-05-2010 - Attached ZPU in C v0.11
Fixed NEQ and NEG opcodes that were reversed.
Optimized ADDSP a little.
All ops now work without EMULATE !!!
Added helloworld test prog for iprintf

Edit: 09-05-2010 - Attached ZOG v0.11
Fixed NEQ and NEG opcodes that were reversed.
Fixed ADDSP as per ZPU in C
Fixed memory endiannes as per ZPU in C

Edit: 12-05-2010 - Attached ZOG v0.12
ZOG now works !!! Runs dhrystone throught to the end. (OK no timing yet)
The ZPU_EMULATE op now works. If it's ever needed.
Fixed MOD and DIV instructions.
Inlined read/write_byte
read/write_word are EMULLATED for now as their endiannes is not right yet.
ZPU memory is 20K bytes (Until we put SD and VM COG back in)

Edit: 14-05-2010 - Attached ZOG v0.13
Fixed endiannes of the write syscall
Default test is now some RC4 crypto.

Edit: 09-06-2010 - Attached ZOG v0.14
First version to support external RAM on TriBlade (blade #2)
External RAM builds need more testing still.

Edit: 20-06-2010 - Attached ZOG v0.17
This comes with an updated VMCOG.
Now loads ZPU executables from SD card.
Seems to be quite solid runs fibo, RC4, dhrystone etc tests OK

Edit: 23-06-2010 - Attached ZOG v0.18
Various optimizations to the ZPU engine.
Dispatch table is now only 128 bytes in HUB
13% faster running FIBO from HUB.
BEWARE - Has an issue with TriBlade external memory, random incorrect
results running fibo or dhrystone or even crashes. Seems to depend
on the number of working pages in VMCOG.

Edit: 08-07-2010 - Attached ZOG v1.0.
Yes a jump to version 1.0 !
Zog can now take over the entire Prop, no Spin left at all.
Most spin code is removed from zog.spin leaving only the interpreter PASM.
For this release use run_zog.spin as the main module.
run_zog can start Zog and continue with more Spin code OR it can boot Zog
to take over the entire Prop displacing all Spin.
Set the CUCKOO_MODE define to displace Spin.
debug_zog.spin contains the original Spin support/debug code for Zog. It is
broken do not use it now.
This release also includes C++ objects that wrap the PASM parts of
FullDuplexSerial and VMCog. As delivered run_zog runs a test of these
classes. This means you will have to recompile them for different
clockspeeds/pins. See the lib directory for C++ code and Makefile to do this.
This release will not work with external memory.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 7/8/2010 7:45:10 AM GMT

kwinn

Sounds like a really neat idea and a great fit for the prop. I have always liked cpu's with a clean minimalist architecture.

Cluso99

Too busy :-(

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

trodoss

It does sound great!· Using GCC to develop code for the Prop would be wonderful [noparse];)[/noparse]

Other than·setting up an·FPGA that can run the ZPU, are there any other simulators for the ZPU (maybe PC-based) that can be used for reference?·

[noparse][[/noparse]Edit] Saw in the doc's that the Zylin Embedded CDT plugin for Eclipse is supposed to have a simulator(?)· I haven't downloaded it yet, but might be interesting.· http://opensource.zylin.com/embeddedcdt.html

It looks like the git repository contained the java source for a simulator as well.

Keep up the great work!







▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)

Post Edited (trodoss) : 2/3/2010 7:49:01 PM GMT

jazzed

Did they suggest what would keep Zylin from running uCLinux? Will it build uCLinux?
I tried getting the tool-chain, but I don't have "git" and Cygwin setup is broken now.

A platform for ECOS or FreeRTOS would be good - what would it take for Catalina to build it?.
I assume since ECOS was a 90's Cygnus project that inline functions, etc... are used.

ZyCOG and ZiCOG names are confusingly similar to me.

Bill Henning

Very cool!

I've started a VMCOG thread [noparse]:)[/noparse]

heater said...
Announcing the start of a new project:

ZyCog - An implementation of the Zylin CPU core (ZPU) from Zylin Consulting for the Propeller.
opensource.zylin.com/zpudocs.html

I recently stumbled across the ZPU processor core for FPGA's. Why is this interesting?

1) It is billed as the smallest 32 bit CPU core in the world. In terms of FPGA logic cells required.
2) It has a very minimal instruction set, only a handful of op codes.
3) All op codes are 8 bits wide.
4) Zylin has created a branch of the GCC C compiler targeting the ZPU instruction set.

What does this mean?

Due to 1) and 2) above we may be able to implement this CPU architecture in PASM in one COG.
Due to 3) it is a perfect match for our many external RAM solutions, TriBlade, RamBlade, Morpheous etc etc
It is a 32 bit architecture so we can make us of all the external memory for code/data. A vast improvement on ZiCog for example.
There is the lure of being able to use the GCC C compiler to develop code for the Propeller !
With GCC comes the remote posibility of running uCLinux on the propeller. A step up from CP/M [noparse]:)[/noparse]
Don't hold you hopes up though, Zylin state that the ZPU is not quite up to handling uCLinux.
It will run the eCos embedded operating system.

Project Status: Ground Zero.

So far I only have an idea, no code, nothing, zilch, nada. I have only just managed to get the GCC to compile hello.c into ZPU instructions which has spurred me on a bit.

With Bill Henning's idea for a caching external memory controller COG the ZPU could be really neat.

If anyone is interested in all this a few words of encouragement might set me on my way, this is a long time scale deal as I'm pretty busy nowadays.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system

heater

Jazzed: There is no reason given for suspecting that ZPU can't run uCLinux. I have no idea about compiling uCLinux yet.

ZyCog and ZiCog names are confusingly similar. Oh yes [noparse]:)[/noparse]

Here in Finland the "Zy" would be pronounced more like "Zoo" in English and the "Zi" would pronounced more like "Zee".

My Finnish is almost non-existent but I've been here long enough that I didn't really think about the confusion.

I think I'll kick off with a ZPU implementation in Spin just to be sure I understand the instruction set correctly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed

heater said...
ZyCog and ZiCog names are confusingly similar. Oh yes [noparse]:)[/noparse]

You're just trying to trap me [noparse]:)[/noparse]

Bill Henning

I hate to admit it, I find the names too similar too; and I am afraid it will lead to confusion among new users.

ZpuCog has a nice ring to it

heater said...
Jazzed: There is no reason given for suspecting that ZPU can't run uCLinux. I have no idea about compiling uCLinux yet.

ZyCog and ZiCog names are confusingly similar. Oh yes [noparse]:)[/noparse]

Here in Finland the "Zy" would be pronounced more like "Zoo" in English and the "Zi" would pronounced more like "Zee".

My Finnish is almost non-existent but I've been here long enough that I didn't really think about the confusion.

I think I'll kick off with a ZPU implementation in Spin just to be sure I understand the instruction set correctly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system

heater

OK, OK, I'll think about the name issue.

I just knocked up a C version of a ZPU core. That was prompted by noticing that Zylin have included very C like descriptions of the ops in their documentation.

Compiled with GCC for x86 it comes to an object size of about 2K bytes or an assembler file of about 600 instructions.

So it looks like ZPU may well be doable in PASM in one COG, perhaps with a few overlays.

I might have to delve into the VHDL or Verilog implementations of ZPU to determine some of the ops details.

Interestingly they have defined a "FLIP" instruction which is a reversal of all the bits in 32 bit word. Perfect for the Prop.

Bill: Any chance of WORD and LONG access commands for your virtual memory system? ZPU needs a lot of that so it would be nice to minimize the amount exchanges between ZPU and the memory COG.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Bill Henning

Very cool about the C version!

You could compile that with Catalina for an initial version...

heater said...
Bill: Any chance of WORD and LONG access commands for your virtual memory system? ZPU needs a lot of that so it would be nice to minimize the amount exchanges between ZPU and the memory COG.

VMCOG will support word and long access (as mentioned in my possibly over-verbose posts in my thread) [noparse]:)[/noparse]

Initially only word aligned word accesses and long aligned long accesses will be supported, but once the basic byte/word/long access is debugged I will add code for unaligned accesses.

Why will I initially have this limit?

Unaligned accesses can cross page boundaries. I WILL support them, but it will take a few days after the initial version is running - I want to debug the simpler accesses before I have to debug accesses that potentially can cause two page faults.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system

heater

What I was thinking is that no matter what the underlying mechanisms are doing there could just be WORD and LONG commands in the interface that use the lower level byte access routines. Just so that ZPU, or whatever, issues one command for a LONG rather than 4. Then we have to think about ENDIANness.

Still a "few days" is much quicker than I'm going to be with ZPU.

I did think about compiling that ZPM with Catalina. Seems a bit cheeky as the whole plan here is use GCC on the Prop.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Bill Henning

Here is how VMCOG will work (Real Soon Now (tm))

You wait for vmcommand to become 0 (in case the cog is busy swapping a page in or out, or processing your last command)

- you write vmaddr with the virtual address you want to access (long)
- you write 1/2/4 into vmbytes (short)
- if you are going to write to the VM, you put your byte/short/long into vmdata (long)
- you write VMWRITE or VMREAD into the vmcommand location (short)

if you were doing a VMREAD, you wait for vmcommand to become 0 before reading vmdata

NOTE:

If you leave 1 in vmbytes, then only short/long accesses need to write 2/4 into it; and if they write 1 when they are done, the most common access (byte) will not have to write to vmbytes

The temporary abberation of not allowing unaligned access is just that - temporary [noparse]:)[/noparse] - and it is only needed to simplify debugging the initial version.

heater said...
What I was thinking is that no matter what the underlying mechanisms are doing there could just be WORD and LONG commands in the interface that use the lower level byte access routines. Just so that ZPU, or whatever, issues one command for a LONG rather than 4. Then we have to think about ENDIANness.

Still a "few days" is much quicker than I'm going to be with ZPU.

I did think about compiling that ZPM with Catalina. Seems a bit cheeky as the whole plan here is use GCC on the Prop.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system

Post Edited (Bill Henning) : 2/4/2010 10:00:09 PM GMT

Chris Micro

heater said...

I just knocked up a C version of a ZPU core.

Hi heater,

is it open Source? I was thinking about to to it myself but probably your version is more elegant.

trodoss

@Chris,

I was thinking the same thing [noparse];)[/noparse]

I had pulled down the Java code for the simulator on their site, and contemplated converting that, but then I saw heter's post.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)

heater

The ZPU implementations for FPGA etc are BSD licensed. So if anyone is interested I'll post ny C version here under BSD as well. I won't be optimized for speed or elegance I'm just using it to explore the ZPU opcodes.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Chris Micro

Yes, I'm very interested. Do you have some small assembler test programs to run on the ZPU too?

heater

Chris: The attached ZIP has a C version of fibo and the resulting ZPU assembler output (fibo.s)

You can compile into assembler output using the GCC for ZPU like so:

.../..whatever_path../install/bin/zpu-elf-gcc -phi -S -o fibo.s fibo.c

Or compile to a ZPU executable like so:

.../..whatever_path../install/bin/zpu-elf-gcc -phi -o fibo fibo.c

Adding optimisation option (-Os) to these commands pretty much halves the code size.

Not sure how to get the raw binary out of this for loading into RAM and running yet. Must be possible with
zpu-elf-objdump somehow.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater

I've just realized something fundamental about the ZPU.

The basic ZPU only has 11 instructions !

All the rest of the ops I've been looking at in the architecture document and generated by GCC can be, optionally, emulated by the basic 11 ops.

The way this works is that 1 of the basic ops is EMULATE. EMULATE works like a kind of software interrupt and vectors off into a table of emulation routines that perform the required instruction. The ZPU assembler code required to do the emulations is provided.

This is an excellent discovery because:

1) For sure we can fit the basic ZPU into a single COG in PASM and hence run GCC compiled code on the PROP.
2) As things progress the emulated (by ZPU asm) ops can be replaced by PASM implementations. Until the COG is full.
3) If there is room we can add other emulated instructions for PROP specific features. Perhaps for accessing timers or locks or adding IO directly to pins etc.

I should have spotted this earlier but it is not immediately obvious from the document I'm reading which is a real ZPU op and which is an emulated op.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Toby Seckshund

Probably a very simplitic view but, is it a bit like forth in that there a a few primitives and the extras are built up, and up, from those ?

As it was, aparently, a comment from me that got you onto this thread, can I be given that cedit "Based on an original idea by ...". Even if I still have no idea how, what or why ... (situation normal)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

heater

Toby you are quite right.

The ZPU processor architecture has no registers apart from the Program Counter and Stack Pointer. It is a stack based machine just like the lowest level of primitives in Forth. Only the ZPU is intended to be implemented that way at the hardware level in an FPGA or whatever rather than being a stack based kernel running on a "normal " processor.

I'm not so familiar with Forth but I guess the ZPU's EMULATE instruction is something of a departure from the Forth model. Perhaps that is only an implementation detail.

The wonderful thing about the ZPU is that ZyLin have taken the trouble to get GCC to compile C code down to that stack based architecture so we have all the tools we need ready made. I think this will also allow C++ on the Prop !

The other thing I love about this is that all ops are byte wide. This is a perfect fit for our current external RAM solutions.
Catalina and ImageCraft C compilers are basically compiling down to PASM instructions so every op requires fetching 4 bytes from external memory. ZPU only has to fetch one.

Balanced against this is the fact that it has no registers so every op is having to read and write to the external memory which slows it down quite a bit.

It will be interesting to see how the ZPU in PASM running GCC compiled code stacks up against Catalina and ImageCraft when used with external memory.

P.S. Happy to put your name at the top of the credits list. By the way, can you link me to the post where this all started? I've already forgotten how I came to be here.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Toby Seckshund

Heater

I'm only kidding. Work, bored ...

It was ALE's fpga Bd thread.

I was promised a rack mount VGA screen assy to play with. I got all excited, thinking that it would be a dual,triple or even a quad but it has just·turned out to be a 15" single with swivel brackets. Still it works, so I really should be grateful (cue Muttly type snarls).


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

Post Edited (Toby Seckshund) : 2/5/2010 1:19:50 PM GMT

trodoss

@heater,
I tried downloading the fibo.zip It seems like the archive is empty, other than the /fibo folder.

I saw in the code the emulate() proc in the Java simulator, but *completlely missed* that is how actually worked. I was thinking in terms of other CPU emulation code where you are skipping certian opcodes.

@Toby,
Where I work we have been begging to get new rack mount KVM's. All the new servers we get use USB and the one we have now still uses PS/2 and VGA. If I held my breath I would be long gone by now...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)

heater

@Toby. OK I found that post of yours that kicked this off. There is no escape, the resulting collapse of my work and social life is all your fault [noparse]:)[/noparse]

@trodos: Oops. sorry I'll fix that zip when I get back from work tonight.

That's a neat feature of the ZPU. Any op-code with 001 in the three high bits is an EMULATE instruction. Then the five lower bits are used as an offset into table to which gets you into the emulation (in ZPU asm) of what ever op you want it to be.

BUT if your implementation happens to implement the logic for those ops in hardware then they get executed directly instead. The base implementation does not need have those ops in hardware as the ZPU asm equivalent sequences are supplied by the C compiler in the C run time support.

On the Prop replace "hardware" with "PASM" in the above description. Get's confusing as to what is emulating what here.

Re: The name, would anyone mind if I renamed this project to just "ZOG" for Zylin core in a Cog ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 2/5/2010 5:11:06 PM GMT

Chris Micro

Hi heater,

thank you posting the code. But it seems to be empty, it has 0 bytes.

chris

Cluso99

ZOG does not have a ring to it. BTW neither does ZPUCog. And I agree it cannot be ZyCog either. :-(
How about Z_Cog, SoftCog (since it is sort of a soft cog), ZPCog. Nothing sounds as good as ZiCog & MoCog.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

wjsteele

You know... this is really cool. Now, on top of all the other projects I'm working on, I have one more. My mind keeps racing at the possibilities.

Thanks a bunch! (No really, thanks!)

Bill

(Bill mumbling to self.... dang it... just what I needed... something else to feed my ADHD.)

Toby Seckshund

Heater

If you are expecting sympathy, tough ! Try turning your imagination down to a background simmer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

Bill Henning

Zu? (pronounced zoo)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system

heater

Sorry all for the dud ZIP. Here's that ZPU asm again.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Bill Henning

I just had an interesting idea while working on the Spin API for VMCOG...

Why don't you implement a Spin version of the basic 11 instructions?

Combined with the VM debugger I am working on, it would make a good debugger for ZPU!

I will be updating my thread with the Spin interface to VMCOG shortly, it is VERY easy...

heater said...
Sorry all for the dud ZIP. Here's that ZPU asm again.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system