Project Logs

Collapse

• CalcHack V3 in development

  Sean Dylan Goff • 12/15/2015 at 14:20 • 0 comments

  I know it has been a long time, but I just wanted to give a quick update.

  CalcHack V2 has proven too expensive for mass production, and getting all the hardware abstracted is too big of a task. It has thus been abandoned...

  BUT it has been succeeded by CalcHack V3, where functionality has been reduced (sorry) down to:

  - WiFi (Chat, file down/upload)

  - 2D/3D graphics (much easier to use 3D-Engine)

  - 3MB File System (SPIFFS)

  - C-Interpreter (not certain yet)

  with the main advantage of being much cheaper. More updates to follow ASAP let's just hope V3 is the final version ;)

• PCB Problems - why isn`t all running yet?

  Sean Dylan Goff • 08/19/2014 at 22:02 • 0 comments

  Just a quick one:

  Many functions aren`t available yet (in fact most of them, the demos that already work are a very, very small part of what`s coming!) and this is why:

  A few weeks ago I got the first batch of PCBs for CalcHack. Before that I only did basic testing with half of a link cable connecting a STM32F3, later an STM32F4 discovery board to the calculator. When I den soldered together my first CalcHack PCB it didn`t work at all, in fact it just pulled about 700mA without doing anything. I quickly realized, that there was a short on the output side of the switching regulator. Also, the regulator got quite hot. Because I designed this PCB completely myself, and haven`t done many switching regulator designs before I was worried that my design is bad. 

  It took me very long to find the problem, and it was a very, very ugly one: Sometimes EAGLE (the layout editor I use) seems to make overlapping polygons. I haven`t found out why, but normally this isn`t a big problem because it generates DRC errors. But this time I missed this error, because I had known (ignorable) DRC errors nearby. In fact it was really just an 8mm (!) piece of copper connecting GND to 3V3 OUT.

  After fixing this by cutting the trace I had another problem: the main CPU got hot. After some searching I found out, that it wasn`t the CPU but the MEMS oscillator a few millimeters besides it. I really just connected GND and VCC backwards...

  I then fixed this too (by taking out the oscillator, it isn`t really needed except for precision and overclocking) but somewhere in this process the STM32F4 must have broken. I haven`t gotten the chance to replace it yet, and this is why all demos run on the coprocessor or externally on a discovery board.

• Routers

  Sean Dylan Goff • 08/18/2014 at 21:06 • 0 comments

  For routers the same hardware as in CalcHack will be used, optionally a better antenna.

  Even though it isn`t a mesh network every CalcHack client can be set up as a basic router allowing clients in a radius of at about 200 meters to connect to it and send data peer to peer.

  For accessing online resources (downloading apps, maybe even a wikipedia parser) there will be a Lan to CalcHack bridge needed, which for example could consist of a RPi connected to the router (CalcHack PCB) through the extension port. The RPi then preprocesses the data to make it easier to transfer and parse within the CalcHack network. For example a wikipedia article gets broken down into plain text and bitmaps.

  Of course direct P2P transmissions are also possible, to say establish a single voice or video link between two calculators (think teacher to student screencapture, or a little help during difficult to communicate situations...) without blocking all the routers bandwidth.

• Apps? Store? How will THAT work?

  Sean Dylan Goff • 08/18/2014 at 20:55 • 0 comments

  Well, it isn`t implemented yet, but there will be a very simple app system:

  Apps are going to be ARM hex files with custom endings stored on the internal SD card (there is a SD card holder, the user may choose the appropriate size).

  There will be a very simple file management system that each app has a unique folder (say sdcard/appdata/myawesomeapp/) where the app itself is contained, an icon and all data the app brings or adds at runtime (in a game this could be level data and highscores for example)

  When you start CalcHack you will be able to choose an app by name and Icon, and then the corresponding ARM hex file is loaded into RAM and executed. Because apps will run from the fast CCM (core coupled memory) in the STM32F4 app size is limited to 64kb. As many libraries and engines are preloaded into the 1mb Flash this will be enough  for most applications. Bigger apps can be split into parts and the parts run one after the other (say a game that does`t fit because there are many quests might have an executable for each quest run one after the other - load times with SD cards connected to SDIO are quite fast after all)

  For simplicity, efficiency and flexibility there will not be a real OS running in the background when an app is open, but only a settings / app choose program in the beginning (and upon quitting an app, of course)

  For getting the apps there will be more than one way:

  - You might just download them from the internet and save them to the SD card using a PC

  - You can get them from others in the same network as a payload in a messenger

  - The final plan is to make a simple website based "Store" (this is an open project, every app will be free of course)  allowing the router to download apps for a client and then transfer it to the client in the local CalcHack network.

• Z80 ASM program: calculator "OS"

  Sean Dylan Goff • 08/18/2014 at 19:59 • 0 comments

  The client program running on the builtin Z80 which receives frame data and transmits keystrokes is written in Z80 Assembler.

  Even though it only consists of just about 150 commands ant compiles to < 500 bytes it was a really big part of the project for me out of a few reasons:

  - I always programmed in C and treated ASM as something I won`t ever do. This changed when I saw that ASM was the only way to solve this problem, because I only have a 6mHz Z80 CPU and wanted greyscale --> very fast update rate (I managed to get as high as 38 FPS but in the demos it`s about half because of using one instead of two processors working together to feed frame data into the Z80.)

  - The TI-82 STATS doesn`t have native ASM support which makes development very painful, and I didn`t even have a link cable which means one crash - rewrite (because I can`t backup the code). Quite a bit was done in HEX ASM (ouch!), but then I decided to take time to search for a compiler (most don`t run on modern computers - clrhome.com/asm is the perfect solution, if you know about it which I didn`t) and also build my own data cable (STM32F4 discovery + cut in half calc to calc cable = hacky, unstable but working method to transfer files to the calculator) which made development much easier.

  - To be stealthy the program must delete all evidence (lastentry, commands typed on screen) but also itself on closing, preferably very fast (panic/teacher button...). This is still work in progress, as deleting the lastentry doesn`t work if not isolated from the rest of the OS - unusable, but I`ll find a way.

  The code is located @

  https://github.com/CalcHack/firmware/blob/master/os/os.z80

• How it all began and who I want to thank

  Sean Dylan Goff • 08/18/2014 at 19:11 • 0 comments

  A few years ago I saw project WICHTIG on mosfetkiller.de which is essentially a very simple version of CalcHack. It was made for the TI Voyage 200, and would only allow sending texts using a small TI-Basic program. I liked it, but at that time I only heard of graphical calculators, but never seen or used them, so it was just another nice website to look at for me.

  About 15 months ago I was first introduced to graphical calculators. At first I was impressed with it, but then I started to realize that projects I did at that time were - from a speed point of view very superior, which kind of made the platform lame in my opinion, still, I kept it in mind. After summer holidays (exactly 1 year ago) when I changed school I had my second contact with TI calculators, but this time it was that our teacher told us we were going to get them in half a year. This is when I knew, I`m going to use this calculators for at least a few years, so I wanted to make the best out of it. 

  I hated these 6 months, because I had no hardware (calculator) yet, but got more Ideas what I could do with it all the time. I asked colleagues what they thought of chats and 3D-Engines in calculators, and because everybody liked the idea I was sure I was going to develop at least a wireless messenger once we get them. Also, I broke a friends TI-30 in the desperate attempt to hack it to at least play reaction type of games (TI-30 is completely ASIC which only leaves eavesdropping on control lines, which kind of worked until it fell of my table and broke).

  When I finally got my own TI-82 STATS, about 6 months from the initial Idea many things have changed, most obvious one being me switching from AVR to ARM (STM32). This made building on WICHTIG hard, so I decided to start from scratch.

  I worked from time to time on CalcHack and added any feature I could. In fact I perhaps worked on it 2-3 times per week, but it was just when I was writing core linkport code for CalcHack when I felt like browsing youtube. As I got there, I saw that just 20 minutes ago Dave Jones (EEVBlog) uploaded a video on the Hackaday Prize. I then saw, that my project fit perfectly and decided to take part.

  My thanks go to:

  - Dave Jones for giving me the right information just when I needed it (a contest I think, is also a great motivation)

  -  Paul Wilhelm at mosfetkiller.de for showing me it`s possible, and oven though our solutions couldn`t be more different it inspired me. I also stole about 20 very elegant lines of code from him ;)

View all 6 project logs