unsubscribe

[Kuba Tyszko]

Good bye Kuba Tyszko  :-(
You are now unsubscribed



-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PilMCU status

[Kuba Tyszko]

Hi Geo,

Wow, this is so cool, we all thought you went completely missing but it seems 
you’ve been putting a ton of work into this, including a whole PCB 
“motherboard” (I remember your original prototype was simply using an Altera 
dev board).

I haven’t finished watching the video but gotten up to 20 minute mark where you 
typed (+ 1 2 3 4 5) - so the machine works.

Awesome job!

Thanks

> On Apr 12, 2017, at 5:45 PM, George Orais  wrote:
> 
> Hi List!
> 
> 
> At last here is the link for the demo video of PilMCU in action!
> 
> https://youtu.be/mMgIvITAMBc
> 
> I hope you will enjoy the show :)
> 
> Again, my special thanks to Alex for his great idea and support on this 
> project.
> 
> Let's see how it goes and will keep you all posted.
> 
> 
> BR,
> Geo
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: aix + netbsd

[Kuba Tyszko]

I’m sure we could arrange a server access for you if that’s necessary,

Cheers

> On Oct 12, 2015, at 4:44 PM, Mike Pechkin  wrote:
> 
> 
> 
> On Mon, Oct 12, 2015 at 11:13 AM, George Orais  > wrote:
> Nice! Thanks Mike! Btw, any chance for IRIX? :)
> 
> 
> ​status unknown.
> is non-root account ​available ?
> 
> Mike
> 
> 

Re: PilMCU is dead - Long live PilOS!

[Kuba Tyszko]

Hi Geo,

How about ready-made code to support sdram on altera?:

https://github.com/stffrdhrn/sdram-controller

This was written by my buddy Stafford Horne

Give it a try and let me know how it goes...

Cheers


Sent from my iPhone

 On Jun 21, 2015, at 20:36, George Orais gpor...@yahoo.com wrote:
 
 Hi Alex,
 I see! That's indeed great, thanks! This is really good stuff Alex.
 
 Hi Kuba,
 Sorry the progress was so slow because crazy schedule at work.. for pilMCU 
 I'm stuck with mobile DDR SDRAM interface, it's not as straight forward as 
 SRAM so tentatively i'm planning to fabricate a FPGA board with Cypress Async 
 SRAM to be more near from our original implementation. I can share you the 
 planned schematics if you want to help.
 BR,geo
 
 
 
 
 
 On Sunday, June 21, 2015 10:06 AM, Kuba Tyszko k...@lbl.pl wrote:
 
 
 Great stuff,
 I was just going to ask Geo whether this means to end of Picolisp on fpga.=
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PilMCU is dead - Long live PilOS!

[Kuba Tyszko]

Great stuff,

I was just going to ask Geo whether this means to end of Picolisp on fpga...

I just tried PilOS - works on my qemu, will try on my actual PC later and 
report back.

Cheers

 On Jun 21, 2015, at 12:15 AM, George Orais gpor...@yahoo.com wrote:
 
 This is great! Will try it soon, thanks!
 
 I'm really sorry about pilMCU, actually I'm still pursuing to build it but as 
 of the moment time is not on my side... but still hoping someday soon... btw, 
 if ever pilMCU is implemented, will PilOS work immediately over it?
 
 
 
 On Saturday, June 20, 2015 6:35 AM, Jakob Eriksson ja...@aurorasystems.eu 
 wrote:
 
 
 
 Thank you!
 
 
 
 On 19/06/15 22:16, Alexander Burger wrote:
  Hi all,
 
  I'm happy to announce PilOS - The PicoLisp Operating System!
 
  It is a modification of the infamous PilMCU, which unfortunately doesn't
  seem to get off the ground. So in order not to have wasted all that
  effort, I decided to let it run on standard PC hardware, basically
  directly off the BIOS.
 
  In the future, we might think of utilizing it in embedded systems.
 
  I release it free to the public. It is currently just a toy project,
  which gave me lots of fun during the last two weeks.
 
  You can read more about it, watch a demo video, and download all at
 
 http://picolisp.com/wiki/?PilOS http://picolisp.com/wiki/?PilOS
 
  ♪♫ Alex
 
 -- 
 UNSUBSCRIBE: mailto:picolisp@software-lab.de 
 mailto:picolisp@software-lab.de?subject=Unsubscribe
 
 

Re: pilMCU on STM32F4-discovery

[Kuba Tyszko]

On Nov 26, 2014, at 4:10 PM, Alexander Burger a...@software-lab.de wrote:

 Hi Kuba,
 
 ..and I just got to the same exact point, compiled minipicolisp for 
 stm32f4-discovery,
 (same modifications, reduced allocation size, removed argc/argv etc).
 
 Great :)
 
 
 gdb session:
 ...
 GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs
 ...
 First impression - it's very slow, resembles a 1200bps terminal ;) but that 
 was fun.
 
 Yes, I noticed that too. I also tried direct Telnet instead of GDB, but
 it is the same. I think it has to do with how stdio is handled over the
 USB link. The speed of PicoLisp itself is all right.
 

It is a debugging link afterall, meant rather for register access not a 
regular console interface.

It's not very difficult to initialize proper STM32F4's UART and modify pil 
functions to direct its IO there - that should yield pretty decent console.

I might do that someday when I find time.


 ♪♫ Alex
 -- 
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: pilMCU progress (slowed)

[Kuba Tyszko]

Hey,

On Nov 26, 2014, at 12:09 AM, George Orais gpor...@yahoo.com wrote:

 Hi Kuba!
 
 I see that Jakob and Alex already covered most of your inquiry, but i'll just 
 answer you too ;)
 
 
  First of all, great progress with the pilMCU so far, I hope the EEPROM 
  continues to work and you can move on to the next step.
 
 Thanks!! and yes, i utilized one push button so that every time i press it it 
 will increment the PC counter then it will fetch from EEPROM the stored 
 bytecode :) now i'm a bit busy with work coz of the coming CES :( but don't 
 worry, the I2C hurdle was done so EEPROM write should be already done, just 
 need to properly align the state machine inside ;)
 
 
  A small suggestion - please put big image files on some site (imgur etc) 
  and attach - it would be easier, downloading large email file takes time (I 
  don't use webmails like gmail).
 
 Oh! sorry about that and actually Jakob already called out on this, sorry 
 everyone i this will not happen again, either i change to smaller resolution 
 or use an external link as Kuba suggested

Cool, I use old school IMAP account with an actual quota (believe it or not ;) )

 
 
  Further, I have a couple questions on the implementation, 
  you said you had an emulator running picolisp already - 
 
 yes, we still got it ;)
 
 
  is this actually the whole picolisp converted somehow to a dedicated CPU 
  running on FPGA, or is that an actual CPU emulated (say some kind of ARM), 
  and picolisp compiled for that CPU ?
 
 as Jkob said, its a new 64bit CPU :)

Some kind of derivative of this : http://software-lab.de/doc64/asm ?

Cool design of the 64bit version that allows to create a completely custom CPU 
or at the very least easy translation to pretty much any architecture.

 
 
  I'm just trying to have a sense of what the pilMCU will become - will it be 
  running on some kind of microcontroller, or will it actually run on a FPGA 
  with a dedicated CPU, or maybe will it be some kind of ARM or MIPS core 
  running on FPGA running the picolisp ?
 
 As of the moment, its the will it actually run on a FPGA with a dedicated 
 CPU. This is just considered as prototype stage? And once we got this 
 running and able to get the funding we need? we will proceed of doing it to 
 ASIC? or even better but expensive, fabricate it to an actual standalone 
 microchip? this would be the ultimate goal, but does ASIC version has the 
 same purpose correct? but yes, the goal is to have a pilMCU chip on its own 
 development board in which would look like RPi, or TI BB or other 
 microcontroller kits these days that are capable of running Linux? once we 
 got this running Alex already started implementing an OS which is now stored 
 on an SD card :)
 
 
  Think for example of micropython or armpit-scheme - those are able to run 
  on many microtrollers, I personally run them on a STM32F4 that's quite 
  powerful (1MB flash, 200KB RAM) - pretty good for a mictrocontroller
 
 ah yes i think i read it somewhere? but hmm the difference is this still is 
 not considered as bare metal running of python or scheme, they still rely on 
 a small vm inside the microcontroller correct? or do you mean python and 
 scheme is used as programming syntax but then it is compiled to a STMicro 
 binary?

micropython running on an MCU is simply compiled (C source with a little ASM) 
for ARM-cortex core with whatever additions required to initialize and use 
uControllers peripherals (just like minipicolisp that Alexander and me ported), 
I don't think there's any VM in between

same applies to armpit-scheme, it's all in ARM assembly.

Technically both could be considered bare-metal environments running on generic 
ARM cores.

 
 As mentioned by Alex, there is the miniPicolisp, im not sure on which MCU it 
 was run, something like Arduino maybe? Give it a try if you have time ;)

I didn't really have time but I did give it a try and got it to work on my 
STM32F4 - didn't take very long ;)

 
 
 BR,
 geo
 
 
 On Tuesday, November 25, 2014 10:14 PM, Alexander Burger 
 a...@software-lab.de wrote:
 
 
 Hi Kuba,
 
 in addition to what Jakob said:
 
  Think for example of micropython or armpit-scheme - those are able to
  run on many microtrollers, I personally run them on a STM32F4 that's
  quite powerful (1MB flash, 200KB RAM) - pretty good for a
  mictrocontroller
 
 
 I compiled miniPicoLisp here on an STM32F4-Discovery. Works almost
 without changes, basically I removed only the command line parsing
 stuff, and decreased the allocation size from 1 MB to 32 kB.
 
 As miniPicoLisp now can compile Lisp expressions to C code (see also
 http://picolisp.com/wiki/?miniCodeROM), you can incrementally test Lisp
 functions in the 196 kB of RAM and then move them to ROM
 
 ♪♫ Alex
 -- 
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
 
 
 

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: pilMCU progress (slowed)

[Kuba Tyszko]

Hi Geo,

First of all, great progress with the pilMCU so far, I hope the EEPROM 
continues to work and you can move on to the next step.

A small suggestion - please put big image files on some site (imgur etc) and 
attach - it would be easier, downloading large email file takes time (I don't 
use webmails like gmail).


Further, I have a couple questions on the implementation, 
you said you had an emulator running picolisp already - 

is this actually the whole picolisp converted somehow to a dedicated CPU 
running on FPGA, or is that an actual CPU emulated (say some kind of ARM), and 
picolisp compiled for that CPU ?

I'm just trying to have a sense of what the pilMCU will become - will it be 
running on some kind of microcontroller, or will it actually run on a FPGA with 
a dedicated CPU, or maybe will it be some kind of ARM or MIPS core running on 
FPGA running the picolisp ?

If the picolisp were to run on a real FPGA, there has to be a CPU somewhere..., 
I just wonder whether you're trying (or already have) to develop a CPU that 
runs picolisp itself, or will that be some kind of generic CPU.
This could determine how popular picolisp could become - if it's able to run on 
generic (not only FPGA) hardware.

Think for example of micropython or armpit-scheme - those are able to run on 
many microtrollers, I personally run them on a STM32F4 that's quite powerful 
(1MB flash, 200KB RAM) - pretty good for a mictrocontroller


Cheers

On Oct 17, 2014, at 8:33 PM, gpor...@yahoo.com wrote:

 Hi List,
 
 Just want to inform that progress will be a bit slow coz I’m going home 
 tomorrow and be able to get back on this after 10 days, but im bringing my 
 laptop with me and see how it goes there 
 
 I’m still stuck with EEPROM coz it’s using I2C bus in which is serial, on my 
 simulated version we use a parallel one so it was easy to handle. But no 
 worries I already almost near to make it work, I just need to take a close 
 look on how my I2C master perform esp the signals.
 
 Will keep you posted, bis bald!
 
 BR,
 Geo
 
 
 Sent from Windows Mail

pilMCU on STM32F4-discovery

[Kuba Tyszko]

..and I just got to the same exact point, compiled minipicolisp for 
stm32f4-discovery,
(same modifications, reduced allocation size, removed argc/argv etc).

semihosting output redirection:


Open On-Chip Debugger 0.8.0 (2014-11-25-23:38)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.907884
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 
Info : device id = 0x10016413
Info : flash size = 1024kbytes
semihosting is enabled
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x0100 pc: 0x08010788 msp: 0x2002, semihosting
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x0100 pc: 0x08010788 msp: 0x2002, semihosting
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x6100 pc: 0x2042 msp: 0x2002, semihosting
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet 
not sent! (2433). Workaround: increase set remotetimeout in GDB
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x0100 pc: 0x08010754 msp: 0x2002, semihosting
Minipicolisp says Hello!
: hello
- hello
: (+ 4 5 6 7)
- 22
:  




gdb session:


GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as --host=x86_64-apple-darwin10 
--target=arm-none-eabi.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
0x080100be in ?? ()
semihosting is enabled
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x0100 pc: 0x08010788 msp: 0x2002, semihosting
Reading symbols from /Volumes/MAIN/DEVEL/miniPicoLisp_/bin/picolisp...done.
(gdb) load
Loading section .isr_vector, size 0x188 lma 0x800
Loading section .text, size 0x1b5e0 lma 0x8000188
Loading section .ARM, size 0x8 lma 0x801b768
Loading section .init_array, size 0x8 lma 0x801b770
Loading section .fini_array, size 0x4 lma 0x801b778
Loading section .data, size 0x1540 lma 0x801b77c
Loading section .jcr, size 0x4 lma 0x801ccbc
Start address 0x8010754, load size 117952
Transfer rate: 23 KB/sec, 7863 bytes/write.
(gdb) c
Continuing.


First impression - it's very slow, resembles a 1200bps terminal ;) but that was 
fun.



Cheers

On Nov 25, 2014, at 11:07 PM, Alexander Burger a...@software-lab.de wrote:

 Hi Kuba,
 
 in addition to what Jakob said:
 
 Think for example of micropython or armpit-scheme - those are able to
 run on many microtrollers, I personally run them on a STM32F4 that's
 quite powerful (1MB flash, 200KB RAM) - pretty good for a
 mictrocontroller
 
 I compiled miniPicoLisp here on an STM32F4-Discovery. Works almost
 without changes, basically I removed only the command line parsing
 stuff, and decreased the allocation size from 1 MB to 32 kB.
 
 As miniPicoLisp now can compile Lisp expressions to C code (see also
 http://picolisp.com/wiki/?miniCodeROM), you can incrementally test Lisp
 functions in the 196 kB of RAM and then move them to ROM.
 
 ♪♫ Alex
 -- 
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Programming environment for PilMCU

[Kuba Tyszko]

Holding my pants tight ;-)
The dream of an actual lisp machine may be coming true.

This is an amazing project and I know there were a few attempts in the past 
(basic lisp on another fpga but that never picked up).
I really hope this works out.

What's interesting is that database bundled with picolisp - this could allow 
for actually useful hardware devices based on the Mcu.

Not sure if you guys know there are other language+database solutions like KX 
systems' Q / KDB (very! Popular in banking).
There's also ODRA - object oriented database with great stack-based language - 
actually my masters thesis was tightly dependent on ODRA.

I totally support lisp and the bundled database and I'm very curious what 
happens next.


 On Sep 22, 2014, at 20:41, George Orais gpor...@yahoo.com wrote:
 
 Hi Thorsten,
 
 The pilMCU is the PicoLisp interpreter itself :) To interact with it, as of 
 the moment we will use UART and use a PC as terminal. But later we plan to 
 add PS/2 and VGA as the means to interact with the hardware interpreter, i 
 hope this answer your inquiry? Thanks!
 
 
 BR,
 Geo
 
 
 
 
 On Monday, September 22, 2014 5:29 PM, Thorsten Jolitz tjol...@gmail.com 
 wrote:
 
 
 Alexander Burger a...@software-lab.de writes:
 
 Hi Alex,
 
  Assuming PilMCU hardware exists and someone wants to use or program
  it, how
  would that look like? Where would one type the commands to manage the
  file system (whats the PilCMU terminal/console?), how would one interact
  with the PicoLisp REPL?
 
  You saw the copy/pasted session in my first post? That's exactly how you
  interact with it.
 
 yes, but I wondered what would be the device the PicoLisp REPL runs on
 in this case. 
 
  We have two I/O ports defined as TTY in- and output. On the real
  hardware you connect a terminal(program).
 
 ok
 
  The SSD images contain a database, with a simple file system implemented
  in external symbols. These images are generated with a normal PicoLisp
  running on a standard PC, and then transferred to the SSDs.
 
 ok
 
  I made the images so far by copying normal *.l files from standard
  PicoLisp to an init/ directory, and edited the files so that they were
  the way we need them for PilMCU.
 
 thanks for the info!
 
 -- 
 cheers,
 Thorsten
 
 -- 
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe