archive.worldofdragon.org

Quick Update:

There is a rudimentary BASIC editor and you can inject a BASIC program listing from the editor directly into the emulator and back: get the listing from emulator into the editor. (Currently only with Dragon 32)

Now it runs CoCo with Extended Color Basic v1.1 looks like this:


Transfer BASIC listing between editor and Emulator works also with CoCo, now.

Today, DragonPy is runnable with Python 2 and 3... (and pypy2 and pypy3)
commits: https://github.com/jedie/DragonPy/compa ... 43...2and3

And i add a simple benchmark with https://github.com/jedie/DragonPy/commi ... 2f6a333905

Usage, e.g.: Current values on my machine:
CPython 2.7.1: ~870.000 CPU cycles/sec
CPython 3.4.1: ~800.000 CPU cycles/sec
PyPy2 v2.3.1: ~8.500.000 CPU cycles/sec
PyPy3 v2.3.1: ~8.380.000 CPU cycles/sec

Wow!

Does PyPy run your emulator 10 times faster?

Yes, because of PyPy has a JIT: http://en.wikipedia.org/wiki/Just-in-time_compilation

I have refactor the threading stuff. With https://github.com/jedie/DragonPy/commi ... 64bb3660e9 i used only Tkinter after() and recalculate the CPU burst count dynamiclly.

Seems that's this is a better solution than before and much simpler. The benchmark cycles/sec values are nearly the same as with the complete GUI. So the GUI didn't produce much overhead in the current implementation

With PyPy2 it looks like this:


PyPy does 750.000 Ops from 6809 CPU in 0.1 Sec
If i calculate the 35 Mio cycles/sec with the 6.2 Mio. Ops/sec, than i came to avg. 5,6 MPU Cycles pro Op... Seems to be possible if i looked into the 6809 Instruction set table, isn't it?

I retest the PyPy Benchmark with different loops, because PyPy needs a few loops to optimize the JIT:

--loops 1 -> 2,4 Mio CPU Cycles/sec - duration 0,60 Sec
--loops 2 -> 4,2 Mio CPU Cycles/sec - duration 0,70 Sec
--loops 5 -> 8,7 Mio CPU Cycles/sec - duration 0,85 Sec
--loops 10 -> 14 Mio CPU Cycles/sec - duration 1,0 Sec
--loops 20 -> 20 Mio CPU Cycles/sec - duration 1,5 Sec
--loops 50 -> 28 Mio CPU Cycles/sec - duration 2,6 Sec
--loops 100 -> 33 Mio CPU Cycles/sec - duration 4,5 Sec
--loops 250 -> 35 Mio CPU Cycles/sec - duration 10 Sec
--loops 500 -> 37 Mio CPU Cycles/sec - duration 19 Sec
--loops 1000 -> 38 Mio CPU Cycles/sec - duration 39 Sec

I have done some simple performance optimization...

I Implement pause/resume, hard-/soft-reset 6809 in GUI and improve a little the GUI/Editor stuff:




It's runs on my PC with a i4790K CPU with CPython near realtime. That's more than i have expected... Maybe there are a few optimizing tricks for CPython, but the most are results in more and more Boilerplate-Code... Any for what? If i can just use PyPy

I work to release the v0.1.0 today on PyPi

Cool!

Keep up the good work!

I add a "config" menu (Currently the values are not load/save)... Now you can limit the speed:





I also add a IRQ callback function. It's not really "realtime" possible, because the target cycles/sec does varies very much...

I started reimplementing Multicomp6809 (Grant Searle's Multicomp FPGA project, see: http://searle.hostei.com/grant/Multicomp/ )

You can start it with: or with the shell script:
Looks currently like this:



It needs some love to make it more usable. e.g.: Activate the BASIC editor here, too. Better copy&paste etc...