Progress with the Mac GUI application for Minipro (GUMP) : Use a TL866 programmer to program ROM chips

The passage of time is frightening. I see that it has been three years since I first posted about GUMP. I had expected a greater response. 

In the mean time I've continued to use my GUI wrapper for minipro when burning ROM chips with my TL866 clone because that has been far friendlier than using the command line. It takes away the need to remember the switches or type the path to the binary.

I've used one or two other of my apps in conjunction with GUMP - Peep for 'hexeditor'-style viewing of the data read from a chip or checking the binary to be written. And a makeshift script for taking one file (or a blank file padded with FF or 00) and incorporating a smaller file at a given start address. 

This has all been very clunky and disjointed. Plus there are some other features that I wanted. For example, a lookup for the supported device names and a list of 'favourites' to save having to keep a note of which device name I last used for the chips that I burn regularly.

A new version

So I've been doing the work to roll all of this together and add the new features. The result is a new version of GUMP. I'm still testing and developing, but it's now in a state where I can call it 'beta' and unleash it on anyone who wants to try it.  [update 22 Jul 24] Now released as a free beta

Above the tabbed area is the 'device' field. You can type the name of your chip if you know it, or press the search button, type a partial string, see results and choose the one you want. 

Once selected you can add it to your 'favourites' which are available in a drop-down list at any time.

Below that is the tabbed area. The 'Read' tab obviously allows you to read the chip and see the data in a 'hexeditor' style viewer. You can export this to a file if you want. The 'combine' checkbox allows you to use the data read from the chip as the starting point to build the output data.

Below that is a console area which relays the minipro output. This has minimal value but at least tells you whether the operation succeeded or failed, and sometimes why.

The 'Write/Verify' tab displays the data that you'll be writing to the chip. You can open a binary file, specify a start address, optionally combine this with the data read in from the chip and padd it to a certain size (although a switch allows you to suppress the error from minipro if it's shorter than the capacity of your chip). You can edit this byte by byte. 

There are a few useful switches presented as checkboxes. 

The Prefs window allows you to specify the location of minipro. This must be installed separately but if you use homebrew that's as simple as brew install minipro You can specify the full path here if minipro isn't in your search path.

[update 22 Jul 24] Now released as a free beta

Structured Data in Scrutiny Scans

Back in April we launched version 12 of Scrutiny (skipping 11). 

Since then the topic of structured data has been raised by users. 

Scrutiny has long collected Twitter and open graph meta data, and has displayed those fields in its SEO > Meta Data table. But not structured data provided via json-ld. 

It's easy to collect this but not so easy to display it en masse as it has a 'tree' structure.

Here are some first steps. I'm open to discussion on where to go from here. The following is all possible with the current version of Scrutiny, 12.5.0

The json-ld is collected from each page and parsed. Perhaps the most important pieces of information are the @types. Like headings there may be multiple, and at different levels, so like headings they can be displayed in the table, in a single column using a separator and in the order that they appear.

The column can be switched on using the Columns selector above the SEO > Meta Data table

That allows you to see at a glance what pages have the structured data and what type(s) are used.

For more detail on a particular page, a double click in this table opens the Page Inspector:

This is the Meta data > json-ld tab of the Page Inspector. Note that we're not seeing the original json string from the page. It has been parsed and formatted. It's the way that a machine would read it, and if Scrutiny can't read the json, then there will be an error message here. (You can see that I've used @graph here in order to display both the software application and the breadcrumb list  within the same chunk of json-ld. If there are multiple chunks of json-ld on the page then they'll be amalgamated here.)

Also in the same inspector is a Twitter Card viewer. This will display information from the Twitter meta data if present, and fall back on Open Graph (og:) fields, as Twitter does. This doesn't look exactly the way that Twitter would display the information - Twitter also draws on info from the Twitter account referenced.

Milestone for MIDISID

 

MIDISID has two SID chips (modern SID replacements, SwinSID Nanos) driven by a Pi Pico. It has MIDI in and audio out.

I'd hoped that this version of the boards (above) would be the final 'release' version. There are some very minor tweaks to make but I'll be building 5 of these - one for myself and four for people interested in an 'earlybird' deal. I'll try a black version too.

The firmware has taken many many hours, and it's clear that there will always be new features on the horizon. If it sells then I look forward to the ongoing development.

It's working very well, see the video below, in which it is in 'General MIDI' mode, I'm playing in the MIDI files for the DOOM levels. 

Picoterm v1.1 released, choice of colours and Turbo Pascal 3

A user reported that when using Turbo Pascal 3 on his RC2014, scrolling within the source code editor wasn't working.

My way of investigating issues with escape codes is to load up a modified version of PicoTerm which prints every character as a number. I also had the RC2014 connected to a terminal on my Mac, so I could still use TP3.

Investigating these numbers showed that the scroll up / scroll down (and also the scrolls that happen when you cursor to the top or bottom of the window) all rely on two escape codes that PicoTerm didn't support:

<esc>[1L

and

<esc>[1M

These are not listed on the Wikipedia ANSI escape code page, which has been my main reference. PicoTerm didn't support them before today. (And neither did PiGFX as far as I can see.) But they do work within minicom and Teraterm, so it seems that they're reasonably 'standard'.

It appears that these codes mean 'insert a line at the cursor position, scrolling everything down'  and 'delete a line at the cursor position, scrolling everything up'.  I have assumed that the number is the number of lines to scroll, although I can't be sure about this until I find some documentation.

Picoterm is built with scrolling in mind - each line of text is a structure, and the display buffer is an array of pointers to these structures, so scrolling is no more than switching 30 pointers around, and clearing a line.

So adding support for these escape codes was straightforward. Each is a variation on the scroll that is already used when the cursor reaches the bottom of the screen.

Here is a quick demo, first showing another new feature of the textmode (mono) version of PicoTerm - the ability to switch colour on startup, according to button A, B or C being held on power-up. White, Green or Amber. 

Then a quick demo of the scrolling up and down within Turbo Pascal 3's editor.

More information about PicoTerm generally, and downloads, are here.

Clock, temperature and humidity display using Badger2040

 The Badger2040 is a RP2040 with e-ink display. Or possibly an e-ink display with a RP2040 on the back:

It has other goodies like 2Mb of flash ram, some buttons and lots of connectors such as a battery connector, stemma/qwiic socket and breakout pads for various serial connections. And USB-C for programming and serial in/out.

I've added an Adafruit temperature / humitity sensor using the stemma connector. This particular sensor is AHT20. The only negative thing about that for this project is that it has a fixed i2c address, and I would have liked to hook up two, one for indoor and one for outdoor temperature. I'll have to buy another which is a different type and has a different address.

For now my program is reading the data from the one sensor and displaying the temp and humidity. This took me some time because the libraries for this sensor (that I could find) were either circuit python or arduino.  If you want to use either of those things, you only need to write a couple of lines of code. For C (or in this case C++)  I had to write my own code starting with i2c_write_blocking() and i2c_read_blocking() and referring to the AHT20 data sheet and the Arduino library. An annoying bug (on my part) meant that I spent more hours than I should have on that.

With that done it was a breeze to print the stuff to the screen (using the Badger C++ example code). I wrote the clock from scratch using the time.h functions within the Pi Pico C SDK to access and process the hardware timer - get_absolute_time(), to_ms_since_boot() etc.  I've got the up and down buttons adjusting the hours or minutes up or down, with buttons A and B switching between adjusting hours and minutes. 

It looks great. The e-ink display is very easy to read in any light and uses no power, except when updating.  I've got the screen updating every 30s or if you push a button to adjust the time.  Another curious thing about this type of display is that it keeps displaying its contents even with power disconnected. Meaning if you wear it as an actual badge, you don't need to power it once it's displaying what you want!

The battery pack that comes with the Badger is a bit chunky (two AAAs inside). I don't know how long that lasts, but I might use a small lithium battery instead, that can be stowed more easily on the back.

UPDATE

I've now got it running off my first found-free-in-the-street  battery. This is a relatively small one compared to the 500+ mAh ones Big Clive has been finding but it is nice and flat and it has been powering another pico project of mine and showed no signs of flagging. I'll be fascinated to see how long it runs the Badger!

Another improvement I've made today is to make the clock periodically write some details to the flash memory, so that if power is removed, it'll start up displaying the same time as it did when disconnected. That saves a lot of button-pressing after a battery change.

I've been struggling with writing to the flash memory on the Pico and on this device, but today I solved my issue. Basically don't have USB stdio enabled while trying to write to the flash.

Milestone for Scrutiny - v12

Last year we spent many months rewriting our website crawling engine, the reasons are here. 

Since then, Integrity went through a beta period and eventually Integrity, Integrity Plus and Pro version 12 were released. 

There have been many updates, those apps are becoming mature, the problems found are now increasingly obscure. 

As well as fixing issues with the new Integrity, Scrutiny has been catching up. 

It's now based on Integrity. That approach comes with some compromises (see notes below) but the benefits for all of us are great. 

It also means a totally different interface. Or rather reverting, because up until version 4 Scrutiny had the open, tabbed Integrity-like interface. The move away from that wasn't popular and Scrutiny's UI has been its weak point. 

Notes: (also in the release notes within the .dmg)

There will be no autosaved data for a site until you've run a scan. Your previous scans will only be visible in the previous version. V12 requires new scans before autosaved data is available. This is due to the format of some of the data changing a little, 

V12 isn't document-based. This is part of consolidating Scrutiny & Integrity. Being document-based requires a different architecture within the app, introduces the need for all sorts of complexity and workarounds. The compromise is that it's no longer possible to run multiple scans at the same time. Until there's a 'queueing' system built into Scrutiny 12, you'll need to make sure that any scheduled scans don't overlap time-wise. 

V12 doesn't have monitoring or orphan check.  I don't think either of these features will be missed, and if there is a call for the monitoring functionality, it should be in a separate app. 

The layout is different. I should say 'reverted' because until version 4, Scrutiny shared the Integrity-style interface, and the move away from that wasn't popular. Scrutiny's UI for managing websites hasn't been very user-friendly and had come in for some criticism. It also made it impossible for Voiceover to work (requires visible tabs).

Automatic ftp of sitemaps is no longer available. Scrutiny saves the xml sitemap, you must transfer it yourself.  ftp and ftp+SSL (ftps) has been fine but sftp (which in my experience is now more common) has been problematic

French localisation is unfortunately no longer available. I'm grateful to French-speaking paying customers and people who have offered to help with the translation. The problem isn't paying for translation, but the fact that any new feature or change to the interface (which are happening all the time) requires an interaction with the translator and I prefer a much more agile process. The apps haven't been noticeably more popular in French-speaking countries than without the localisation.

Having got so far with the MIDI SID project, I had this real mess of wires and boards. Then I started to add to the carnage with knobs and a display.  

The problem was that if something stopped working I couldn't be sure whether it was because I'd got something wrong, or had just jogged a connection.

Happily, prototype boards are so cheap that you can order something without worrying about the cost. This isn't even really a prototype yet, not all of the components are on the board. I just wanted the Pico, two SIDs (in this case swinsids) and the MIDI in circuit soldered firmly in place so that I could experiment with knobs, buttons and displays, and develop the software without fear of breaking it by jogging the desk!

To get you up-to-date if you haven't seen my ramblings about this, I'd love a box with MIDI input, SID chips inside, audio out, and simple controls. I'd like to be able to play a .mid file into it, or plug in a keyboard, with options for polyphonic or monophonic output. (I've done some of this using a C64 and MIDI cartridge, but it'll be good to have a standalone box.)  I'd like to try a larger version with enough SIDs to be able to map each midi channel to a voice. Maybe in time I could add the components needed to support real SIDs, but being able to use ARMSIDs would be good as they're a great replacement. (I'm not sure that it's ethical to encourage anyone to use precious real SIDs in something like this.

Quick demo of the thing working (just one channel in, one voice playing). I've got Logic Pro playing a simple tune, with a USB-MIDI converter allowing me to plug that into this board. 

If you're interested in the project, I'm going to use the hashtag #MIDISID on Twitter.