Fignition Reloaded?

[Ken Boak]

Hi All,

I have recently created a new board, WiNode 5, around an Amega1284P - which is the same AVR core as the ATmega168/328  but with 16kbytes RAM and 128kbytes of Flash. 

Additionally, compared to the '328 it has a complete, extra 8-bit GPIO port, a 2nd UART, an extra timer and an extra interrupt line.  

It is also available in an easy to use 40pin DIL package.   For some time I have been thinking that this IC would make an excellent upgrade for Fignition.

So I have designed a new pcb around the '1284 with the following additions:

External 23K256 SRAM - but battery backed so that it's non volatile

MicroSDcard socket - for removable program storage,

Real time clock, with alarm/wakeup function 

USB to serial connection based around the economical CH340G converter, 

Boost converter power supply - so that you can run it from a LiPo (or even alkaline) battery.

Low power wireless tranceiver - to communicate with other devices

ESP8266  WiFi module

Arduino compatible expansion headers

The new board can work as a stand alone, battery powered controller or datalogger however it has really been designed to be the microcontroller section of a 2 board stack. The other companion board, known as Evita is a video generation board capable of creating 1024x768 65Hz 24 bit full colour XGA video - for displaying on either a wide screen monitor/TV or alternatively a colour LCD touchscreen. Evita is based around the FT812 Embedded Video Engine  (EVE) chip from FTDI.  In addition to video, Evita supports PS/2 keyboard and mouse, Wii Nunchuck controller and audio output (it has an onchip synthesiser) and a 2nd microSD card.  Evita can also display jpgs images and mpeg coded videos for full speed playback.

Evita has been developed in conjunction with James Bowman, who has produced GameDuino and GameDuino2  - the Arduino Games platforms.  James is experienced in video generation and has really pushed the EVE IC to it's limits to achieve such spectacular results.  James designs Forth processors running on FPGAs and is an expert in the combination of high speed digital systems controlled by and running Forth.

WiNode 5 and Evita are both open source projects, and samples will be available in the next few weeks.

In the meantime there is some more detail on my blog.  http://sustburbia.blogspot.co.uk/2016/02/fignition-revisited.html

Ken

  

[David Buckley]

Ken

Sounds interesting, very interesting.

David

--
You received this message because you are subscribed to the Google Groups "FIGnition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fignition+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dylan Distasio]

Ken-

I would be interested in a sample of the boards if they become available.  This looks interesting!

Best,
Dylan

[Ken Boak]

David,

Thanks for your interest.

The Evita boards are working well - tested with Arduino and other platforms that have Arduino pin headers.

The WiNode 5 pcbs should be back by the end of next week.

If all goes well, I'm going to explore the options to have these professionally manufactured and distributed.

Unfortunately, the world has moved on a bit since 2011 - when I created my first "all-through-hole" DIY solderable kit - for a combined Arduino with ethernet.

I also found that many people (especially in the US)  did not want the hassle of having to make something for themselves - so clearly I misjudge my market.

The extra complexity of these designs means that they are predominately built using surface mount devices , making home manufacture no longer a practical option.

There will be some beta test boards available soon - which I should like to get into the Fignition community.

regards

Ken

--
You received this message because you are subscribed to a topic in the Google Groups "FIGnition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fignition/FHyfUlveXdY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fignition+...@googlegroups.com.

[Ken Boak]

Dylan,

Thanks for your interest.

I hope to make the design available within the next few weeks. There will be some prototype boards made available to those early adopters who wish to integrate the Fignition code and port across to the EVE graphics engine.

The EVE chip really makes spectacular video available, without burdening the poor AVR with a lot of video timing overheads. It was really designed to act as a GUI controller for small LCD touchscreens, but with the help of James Bowman's expertise with GameDuino and GameDuino2  we have made it produce a stunning stable picture on any wide TV or monitor with a VGA video connector.

James has written a Forth driver for the EVE chip, and we hope to incorporate this with Fignition, in the near future.

This 20MHz AVR microcomputer is likely to be the first of a series of educational projects I am involved with.   I have been tinkering with Forth ever since I bought a Forth ROM for my ZX81 during my college days in 1983.

I am currently investigating ways to get Forth to run on a number of different platforms - including a DIY ARM board with a 216MHz Cortex M7 STM32F746 - as used in the DISCO F7 dev board, and also a dedicated Forth processor implemented in a FPGA  - James Bowman's  J1b Forth processor - which originally powered the first GameDuino.

regards

Ken

--
You received this message because you are subscribed to a topic in the Google Groups "FIGnition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fignition/FHyfUlveXdY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fignition+...@googlegroups.com.

[Julian Skidmore]

Dear ken,

You're the guy who created the nanode, an arduino with a built-in Ethernet port?

Thanks for chatting at the oggcamp. However, I don't really recall you buying a kit at the time. Apart from a reply on my blog (which you've deleted) your first interaction is to use this forum to announce a competitor product.

If you really believed in the FIGnition concept why didn't you support it earlier? If you felt sorry for the poor avr having to bitbang all the video why didn't you make an add-on board for FIGnition that supported the ft800 chip, since FIGnition already has an spi driver which can support multiple spi devices?

You must have sold over £60,000 worth of nanode kits, wasn't that enough?

-best regards from Julz

[Ken Boak]

Julian,

I am sorry if my postings appear purely competitive - that was not my intention at all.

In fact I am perfectly willing to work with you at any level to jointly develop an upgraded product, as I believe there is a demand for a no-nonsense 8-bit platform.  I think the combination of the FT812 video device, plus an AVR with considerably more RAM, and fignition Forth underpinning it could be a winner.

Perhaps we could have the opportunity to discuss this in full, before I cause any more un-intended offence.

Regarding Nanode,  I had perhaps 2000 sales, and  some 400 of the WiNode.  I wound the operation down in late 2012 as the world had moved on to the likes of Raspberry Pi, and I could no longer compete with cheap Chinese imported ethernet hardware

regards

Ken.

[Julian Skidmore]

Hi Ken,

I didn’t mean to be mean, There’s nothing wrong with building your own version of FIGnition, using a AtMega128P if you feel like doing so. It looks like you’ve already made some effort to do that.

It’s just that it does (from my perspective) come across as though you just wanted to use the forum in order to sell your product. You can see how it looks to me, you haven’t done anything to support the existing version of FIGnition beforehand, nor have you discussed anything about your ideas, nor do you know what my ideas would be. You could have, for example, designed an ethernet add-on for FIGnition at any point after we had met up, or even when Nanode wound down in 2012. In fact FIGnition has a Forth-level SPI driver in its ROM, it could well be possible to interface directly to the microchip you used (it could even do that if it has an I2C interface). That would have been great - it would still be great, since one of the many things people have asked is whether it’s possible to get FIGnition on the internet. From my viewpoint, a uIP type stack in Forth would be great fun.

IMO, the real place one needs to start at when thinking about improving FIGnition is to know what it’s true purpose is. OK, so FIGnition is a self-hosted computer with a built-in language; video out and built-in input, but what’s the purpose of it?

The purpose really is to build a computer that’s truly understandable. It’s obvious of course that any low-end computing device: an arduino, a gameduino or FIGnition can be enhanced by making it more powerful: one can add a more powerful CPU with much better graphics (or a GPU); more memory; audio capabilities; connectivity and storage. This can proceed indefinitely to the point where your product is at the peak of what the technology can deliver for the cost or format of the device. And that's essentially the history of computing, with notable bumps when a new technology is introduced (e.g. the introduction of mini, micro or hand-held computers in the 60s, 70s and 90s).

If you work in IT of any form, this computing-opera story is played out almost every day whenever you hear someone talking about how computers have moved on in leaps and bounds. “Gosh, who ever thought you’d get 1Tb on an SD card?”, “Gosh, 8-Core CPU, I remember the old, dark Pentium 3 days”, “Gosh, 4K Displays!”, “Gosh, no-one ever thought we’d need more than 4Gb of memory”, “Gosh, a digital watch has more power than the computers that took man to the moon.” “Gosh, USB 3 - how things have gotten so much better since the days of parallel ports.”.

In the 90s it was the same conversations with smaller numbers: “Gosh, who’d ever thought you’d get 20Mb on a Syquest cartridge?”, “Gosh, a clock-doubled 486, I remember the old, dark 80286 days”, “Gosh, 16-colour VGA, and I used to think 80 column text was astounding”, “Gosh, no-one every thought we’d need more than 640Kb of memory or 32Mb of Hard Disk”, “Gosh a digital watch has more power than the computers on the Apollo spacecraft”, “Gosh, PS/2 keyboards and mice - and to think we used to use those rubbish keyboards with DIN connectors.”

Largely we take this for granted though there are sub-cultures in the computing world that like to tinker with retro-technology, or targeted technology. But by-and-large it holds true so that the Raspberry PI has now been enhanced with 2x? 4x? the RAM a 1GHz CPU and more GPIOs. Therefore it must surely be at least twice as capable of getting kids to program as it was 4 years ago.

And in a sense, that was the ‘problem' with the Nanode, as you say “the world has moved on”. But in my opinion this is not an improvement - because from an understanding viewpoint the Nanode is better than an off-the-shelf Ethernet/WiFi unit that does everything with barely any configuration - kids won’t learn anything that your normal WiFi broadband router hasn’t already taught them. I was impressed by the way the machine managed to cram a DIL based implementation into the size of a normal arduino!

So, back to the central point: Understanding, which is my purpose for FIGnition. I believe understanding is key because the increasing complexity of technology means that, generally, kids and adult programmers are getting worse at understanding what a computer is really doing. They ‘feel’ powerful because of the ease they can plug software and hardware together, but their understanding is shockingly bad. This is partly why the company I currently work for found it challenging to recruit decent ‘C’ programmers, people that know what pointers even are!

Consider:

http://www.usborne.com/catalogue/feature-page/computer-and-coding-books.aspx

Usborne has released a bunch of computing books from the 80s as free PDFs. Which do you think will teach kids more about algorithms and computers: Scratch for beginners or their older Machine Code For Beginners? Today M/C is a super-advanced subject ;-) !

FIGnition can be improved, IMHO, mostly if it can be made more understandable - but going down the route of making it more powerful will lead us, inevitably, to a Raspberry PI. That’s where the ideology and in the currently climate the popularity, like it or not, takes us.

The alternative, really, is a degree of activism. Activism to shift how we measure ‘better’ when it comes to educational technology. For example, I’ve heard of the FT812, but it can’t be soldered by 10 year olds. The Activism approach would lead us to campaign to FTDI to release a small pin-count standard DIL version. Note: the FT812 has 256Kb of serial RAM and an internal MCU, it makes a viable computer in and of itself!

The Activism approach would campaign for hobby-level HDMI connectors, ones that will connect easily to stripboard. Activism takes us in the direction of campaigning for hobby-level HDMI standards too - ie. an HDMI mode where you can just SPI video (at hobby level resolutions and colour) directly to the system. It would take almost no silicon to do that. Activism would lead us to campaign to truly open up PAL, CPLD and low-end FPGAs. That would be good.

The alternative, like the acquisition of Atmel by Microchip is an increasing squeeze on the choices hobbyists have. We treat the industry as though we have to go along with the industry trends, but from an industry view, we ARE the customers and a market in itself and the customer is always right.

-cheers from Julz

[Julz]

Addendum:

We can see that some of your thinking is based on a "more power=better" motif. For example FIGnition "reloaded", employs a gun analogy to convey the idea of more power; the use of SD cards is motivated by the idea of far greater storage (stream mpegs!) And you're excited about being able to deliver gameduino graphics on FIGnition. Note, I've left out the increased RAM, some FIGnitions already have 32K bytes of ram.

yet I don't think the motivation for your project is entirely based on the idea that more powerful=better. For example, it's laudible that you want to connect a FIGnition-like device to hdmi or a separate tft lcd, since composite video support on TVs is decreasing.

You've said you want to collaborate, rather than compete. OK, I think there are a few steps involved.

Firstly, show some good faith by buying a real FIGnition: you can buy one from RS components, since I sold my last one, this week.

Secondly, all fignitions have 'fire' related names, not weapon-related names, such as "fuze" or "flint". We would need to suggest a suitable one, though I would veto ones I've had conceptual ideas about. Then it would be part of the family.

Thirdly, I would get a stake in any of the proceeds, even for no additional work. This is because I've put 4 years of effort into FIGnition and you would be leveraging that. That sounds have to be negotiated.

How does this sound?

-cheers Julz

[Julz]

[Ken Boak]

Hi Julz,

Thankyou for putting your position across,   here's what I can suggest. 

The FT812 embedded video engine is mounted on a  50x50mm pcb with Arduino shield pinouts which carries the FT812 with VGA connector, and sockets for PS/2 keyboard and mouse.

This board was developed over Christmas, so it's very new - and is really only being offered for beta testing.   I would be delighted to make some samples available free of charge to you and other Fignition users so that they can be evaluated in full.

It will however need level converters on the SPI MOSI and SCLK outputs as the FT812 is a 3V3 device.

If it's 1024 x 768  high res XGA graphics capability is deemed to be an attractive addition to Fignition, it would be perfectly possible to re-lay most of the circuitry using through-hole components, with only the surface mount FT812 being mounted on a small carrier pcb (DIL 40 possibly) which could be plugged in to a socket. The Arduino headers would be shifted to allow a direct match with Fignition. This would make it practical for home construction and it could be offered as a Fignition colour graphics and keyboard/mouse  shield.

This design would be offered under the Fignition brand as a colour video / keyboard shield with what ever brand name you choose to use.

Secondly, I have a ATmega1284 board,  also which could be re-layed to utilise primarily through hole construction, or even be put forward as a strip board design.

Fignition could be ported across to the '1284 and take advantage of the 16K on chip RAM, yet retain the fundamentals of the SPI connected 23K236 and the Amic SPI flash.

The 1284 has a whole extra port, which could be used extend the SPI bus connected peripherals strategy with additional device select signals.   This would allow a relatively easy expansion route to allow for other modules such as microSD card,  colour graphics,  accelerometers & other sensors, ethernet controller, wireless modules - such as ESP8266 WiFi, BLE etc.  This opens up a wide range of peripheral options which makes the Fignition very attractive in the current educational platform market.

The 1284 has an extra UART - and this can be utilised to provide a second serial port, or for connection to serial based peripheral modules - such as the ESP8266-01 WiFi

There is no reason why the ethernet controller hardware used in Nanode could not be incorporated into the '1284 design - however these days it is cheaper to buy the ethernet controller and mag-jack on a pre-assembled module from China rather than attempt to build oneself from components bought in the UK.

Regarding HDMI - having to deal with the issues surrounding this - including tiny connectors,  licencing and just the video rates involved is generally avoided by sticking with the VGA approach. I am in favour of openFPGAs, softcore Forth cpus etc - but I suspect this is the subject  of another discussion.

If you are interested,  please let me know how we can best proceed to make some or all of this work.

BTW  - my Fignition from RS arrives early next week!

Regards

Ken

[Stuart Taylor]

Julz,

many, many thanks for sharing the link to the 80's books, wow, got me very misty eyed.

Thanks,

Stuart

[Si Brindley]

Yes - the books are great. I had quite a few of those as a kid and spent hours and hours with them. The illustrations are instantly familiar to me.

[Julz]

Hi ken,

Thanks for buying a kit :-) also if you send me a PayPal amount for a figkeys, I'll send you a kit for that too.

You may find the manuals here useful:

https://sites.google.com/site/libby8dev/fignition/fuze/usermanual

There's a pretty comprehensive hardware guide; a description of the commands and a tutorial. FIGnition forth, as you know is much like Jupiter ace-ified fig-forth.

The v1.01 implementation contains a lot of assembler (the VM, fp-lib, scan line generation and blitter for example) as well as code in 'C' (keypad, text out, spi support, video field generation, boot) and code in forth (e.g. the compiler, text editor and flash disk driver.

A couple of observations from your last reply:

1. Why 1024 x 768 xga resolution rather than, say 320 x 200 VGA? I ask because it seems to me that an AVR running forth will struggle to update text usably on a 128x96 character grid and won't be able to utilize the screen at its graphics resolution.

2. On FIGnition it's assumed that everything uses the same SPI port, but with different /Ss signals to manage multiple devices. Would multiple SPI ports really give us much? To clarify, I mean this: FIGnition forth has an SPI driver, which is simple and works because it manages multiple devices (as multiple /Ss pins) over one SPI.

3. There is no file system in FIGnition forth. supporting SD cards would mean adding a FAT or exFAT based OS. I think that would add quite a bit of effort if done properly. Is that what you were thinking of?

-cheers Julz

[Ken Boak]

Hi Julz,

The 1024 x 768 is purely the maximum resolution that the FT812 can produce. It's Hsync and Vsync are software controlled - so in theory any resolution below that is possible.  The FT812 is a sophisticated graphics controller, which allows objects to be drawn on the screen at given locations.  Sending high resolution text to it is more akin to printing characters to a serial terminal, or BASIC's print at, than having to push pixels around in a frame buffer.  Text strings are sent to it over the SPI interface.  Even a low resource microcontroller like the ATmega can generate quite sophisticated graphics and sound from the FT812 - and is much less burdened than if it had to produce the video timing signals and address a character generator.

What I meant here was that there is a complete additional 8 bit port available on the ATmega1284. It could be used for additional SPI device select lines, scanning a larger keyboard, general purpose user I/O etc.  I meant that these slave select lines could be used with the existing SPI port.

A simple file system (perhaps one similar to that used on Project Oberon) could be used.  It does not have to be based on FAT - see copy of email copied below.

Finally there are some larger SPI SRAMS available  23LV1024 (128K x 8) which can be addressed using a quad SPI technique.  See Microchip App Note AN1791.  This could potentially increase the bandwidth between SRAM and mcu - perhaps by up to a factor of 4 - when used in streaming mode.  There are also fairly low cost SPI FRAM devices in 32K x 8 which would make for a non-volatile store. 

Ken

Oberon File System

I've been asked a couple of questions about the RISC.img SD-Card image
downloadable from http://projectoberon.com for the FPGA RISC5 Oberon
systems.  (If you can, please post questions publically rather than
emailing me privately - otherwise I have to assume it's a private matter
which is more time-consuming to deal with - if I can ever get to it - and
doesn't benefit others.)

The RISC Oberon system boots from an SD-Card and uses it as its file
system.  This filesystem is much simpler than common contemporary
filesystems such as FAT, FAT32, NTFS, exFAT, EXT4 etc. and is not in any
way compatible.  (On the original Ceres, the backup floppy disk format was
very close to the FAT12 format, but with an altered directory to cope with
long filenames, which were not in those days supported on FAT).

It would have been easy to make the RISC5 Oberon filesystem (including its
reserved area for the bootfile) begin at offset 0 from the beginning of
the SD-Card.  This would have dedicated the SD-Card to Oberon use, but
simplified the bootloader.

Or alternatively, the Oberon filesystem could have perhaps been stored as
a file in the FAT filesystem on the SD-Card, making it much more
accessible to utilities running on other computers.  But this convenience
would have come at a high cost: it would have made the bootloader much
more complicated, and given many more possibilities for distracting
problems in development.

In the end, it was decided to place the Oberon filesystem at a fixed
offset from the beginning of the disk.  This was a trivial change to the
bootloader, keeping it easily-understandable and within one block ram
(BRAM) of the FPGA.

This meant that FAT-compatible data structures, and a reasonable-size and
perhaps useful (256MB) FAT partition could still exist at the beginning of
the disk.  If this FAT partition has nothing in it, it compresses very
well and therefore does not significantly increase the RISC.img download
time.

The MBR partition id for the Oberon filesystem was chosen as 0FFh, because
the ids are historically rather a free-for-all and the filesystem is not
exactly the same format as any that have gone before, even the ETH
PC-based Oberon filesystems.  0FFh is clearly an arbitrary value, and also
was only used by others for private data structures rather than for
filesystems which were interoperable amongst systems.

Note that a lot of the motivation for this was defensive.  For example it
makes it more difficult for the Oberon filesystem to be destroyed when the
SD-Card is inserted in a Windows system.

When submitting some early additions to Peter de Wachter's RISC emulator

https://github.com/pdewacht/oberon-risc-emu

for emulated RS232 file transfer which he kindly incorporated, I also
included a quick check on startup which allows the use of a disk image
which only contains the Oberon file system (called .OBERON.FS in the
Windows binary distribution of the emulator which I put on
http://projectoberon.com).

This check is for the magic number 9B1EA38DH (FileDir.DirMark) which is at
the beginning of the root directory sector.  Oberon uses a "parity" scheme
for sector numbers, making all of them divisible by 29, so the first
usable Oberon sector, number 29, begins at SD-Card sector offset 80002H.
This slightly odd value comes from the fact that SD-Cards have 512-byte
sectors, but Oberon uses two of these (1K) for each Oberon sector, and
that sector 0 is not used.

So if you are using a nice operating system and you know what you are
doing (because it allows dangerous commands such as dd) you can extract
the Oberon file system from the image with a command like (262145 = 40001H
= 80002H * 512 DIV 1024)

  dd if=RISC.img of=.OBERON.FS  obs=1024 ibs=1024 skip=262145

and you can even (sudo) write it directly back to a real SD-Card with
something like

  dd if=.OBERON.FS of=/dev/disk1 obs=1024 ibs=1024 seek=262145

The name .OBERON.FS was chosen to make it look like a system file, which
would be totally destroyed if someone opened it and saved it with a text
editor, for example.

Hope that's useful!
Cheers,
Paul Reed

[Julz]

Hi ken,

Interesting that you mention Oberon, I've been looking into it recently as I think more about safety-critical systems.

-cheers Julz

[Juergen Pintaske]

Ken, has this discussion gone any further on a direct basis?
Pretty quiet here, It seems I have done the only posting in 2017.
I hope to have a Fignition soon - and just try to understand, if this project is on hold, neglected as of other priorities or other.
But I like the idea of an independent solution like Fignition. I assume a small ST board might be able to achieve the same - or an Arduino?
I want to include Fignition in the next eBook after having tried it.