Tag: Android

Amiga on Fire on Playstore

The latest thing to try. A Cleanto Amiga Forever OS 3.1 install to SD card in the Amazon Fire 7. Is it the way to get a low power portable development system? Put an OS on an SD and save main memory? An efficient OS from times of sub 20 MHz, and 50 MB hard drives.

Is it relevant in the PC age? Yes. All the source code in Pascal or C can be shuffled to PC, and I might even develop some binary prototype apps. Maybe a simple web engine is a good thing to develop. With the low CSS bull and AROS open development for x86 architecture becoming better at making for a good VM sandbox experience with main browsing on a sub flavour of bloat OS 2020. A browser, a router and an Amiga.

Uae4arm is the emulation app available from the Playstore. I’m looking forward to some Aminet greatness. Some mildly irritated coding in free Pascal with objects these days, and a full GCC build chain. Even a licenced set of games will shrink the Android entertainment bloat. A bargain rush for the technical. Don’t worry you ST users, it’s a chance to dream.

Lazarus lives. Or at least Borglaz the great is as it was. Don’t expect to be developing video realtime code or supercomputer forecasts. I hear there is even a python. I wonder if there is some other nice things. GCC and a little GUI redo? It’s not about making replacements for Android apps, more a less bloat but a full do OS with enough test and utility grunt to make. I wonder how pas2js is. There is also AMOS 2.0 to turn AMOS source into nice web apps. It’s not as silly as it seems.

Retro minimalism is more power in the hands of code designers. A bit of flange and boilerplate later and it’s a consumer product option with some character.

So it needs about a 100 MB hard disk file located not on the SD as it needs write access, and some changes of disk later and a boot of a clean install is done. Add the downloads folder as a disk and alter the mouse speed for the plugged in OTG keyboard. Excellent. I’ve got more space and speed than I did in the early 90s and 128 MB of Zorro RAM. Still an AGA A1200 but with a 68040 on its fastest setting.

I’ve a plan to install free Pascal and GCC along with some other tools to take the ultra portable Amiga on the move. The night light on the little keyboard will be good for midnight use. Having a media player in the background will be fun and browser downloads should be easy to load.

I’ve installed total commander on the Android side to help with moving files about. The installed BSD socket library would allow running an old Mosaic browser, or AWeb but both are not really suited to any dynamic content. They would be fast though. In practice Chrome and a download mount is more realistic. It’s time to go Aminet fishing.

It turns out that is is possible to put hard files on the SD card, but they must be placed in the Android app data directory and made by the app for correct permissions. So a 512 MB disk was made for better use of larger development versions. This is good for the Pascal 3.1.1 version.

Onwards to install a good editor such as Black’s Editor and of course LHA and some other goodies such as NewIcons. I’ll delete the LCL alpha units from Pascal as these will not be used by me. I might even get into ARexx or some of the wonderfull things on those CD images from Meeting Pearls or a cover disk archive.

Update: For some reason the SD card hard disk image becomes read locked. The insistent gremlins of the demands of time value money. So it’s 100 MB and a few libraries short of C. Meanwhile Java N-IDE is churning out class files, PipedInputStream has the buffer to stop PipedOutputStream waffling on, filling up memory. Hecl the language is to be hooked into the CLI I’m throwing together. Then some data time streams and some algorithms. I think the interesting bit today was the idea of stream variables. No strings, a minimum would be a stream.

So after building a CLI and adding in some nice commands, maybe even JOGL as the Android graphics? You know the 32 and 64 bit restrictions (both) on the play store though. I wonder if both are pre-built as much of the regular Android development cycle is filled with crap. Flutter looks good, but for mobile CLI tools with some style of bitmap 80’s, it’s just a little too formulaic.

Flutter and Android Development

So after some install minor trouble in IntelliJ due to minor bugs in the Flutter Dart plugin, the system works quite nice. Hot reloads are the best. There are however some issues. Like the following.

  1. The produced files are multi-megabyte resource hogs. This may just be the debug version, but even with building production APK, not having JDK 8 options in pro-guard, a simple 1 page GUI hits 6 MB. (Be careful of libraries).
  2. There is little configure-ability in the default demo project. Things like default used SD card for install and other sensible options, mean trips into the Android base code and XML more often than should be necessary. (I can’t edit my MainActivity.java with source highlights and error locations).
  3. The state-container split is weird, especially as all the sub-containers are in the state. I do like the templating though in IntelliJ. (The documentation on preserving state is scarce).
  4. Generic functions are nice, and so is some of the library support. There are still a few inconsistencies, but these should iron out over time.
  5. I’m about to discover the GC of PaintRecorder panic on my graphical reserves. I assume this is making GL shaders in the background.
//looks different now, ... The package dart:ui has issues!!<br />//and a duplicate Image, Rect, ... classes
  void atlasUsing(SmartCanvas sc) {
    sc.drawRawAtlas(hi, _transforms,
        _getCharacterRect(),
        Int32List colors,
        BlendMode.srcOver,//should check for mixing foreground and background
        CanvasManager.unit,
        sc.normalPaint);
  }

A bit of work later, and the dart analyser does not crash as often. I think it really is important to not go too low level without some knowledge. The classes collide, and it is best to import dart:ui as an as (I picked ‘Hood’ for under the hood), so as to avoid many of the issues. This does mean that I will have to abstract many of the functions of the low level to be easy functions working with high level (non Hood) Paint, Rect and others. But it was a fun journey!

The channel interface to native is quite an interesting journey as well. It has all the memories of Java and switching back from dart, some things are missed. I’m using the Android platform to generate some sound in the current project. There is not too much in the way of basics to play sound files in the Flutter libraries. Custom AudioTrack stuff is a definite return to Java and a MethodChannel.

The next thing is some code to put the sound together, and some code to add in some convenience methods for putting animation on the CanvasWidget I’ve put together. The IntelliJ dart analyser keeps failing but is restartable after a bit of editing. The code is quite simple for many tasks. There is some complexity when dealing with Future<X>, which infects its way up the stack, needing some setState() for eventually filling in the data on the future resolution. You’d have thought that a return await would have resolved and made the async wait for a resolved future. Because, the documentation is unclear on many things.

It’s not a perfect language isn’t dart, but it is quite nice to use. Flutter is actually very good. I’d suggest ScopedModel and quite a few of the better packages to be included in most projects you’d make.