Many readers of this forum will remember the generation of computers that booted to BASIC and had a clock frequency of less than 4MHz.

You could write a monitor program in BASIC, allowing you to poke carefully hand crafted hex into RAM, and spend a whole Sunday afternoon wondering why your code wouldn't run.

Coincidentally, around about the same time, Sophie Wilson and Steve Furber were taking the first steps in simulating the ARM 1 instruction set - written in just 808 lines of BBC BASIC.

As an 18 year old, I bought an "end of line" ZX81 kit, immediately upgraded it to 2K RAM and spent my college days exploring the exciting world of programming with BASIC, Forth and assembly.

I then became a hardware engineer, and left the art of programming to those far more qualified than myself.

As a hobbyist, I tinkered with C in Arduino, and some 5 years ago purchased a Discovery F4 board which was my first introduction to the ARM. It took me a week of online searching and cutting and pasting code to blink my first LED, thereafter I made significantly faster progress - but it was still an uphill struggle. I went back to pcb design and handed the F4 to a work colleague who crafted it skillfully into the heart of a new instrument.

I've since watched the progress of the STM32 range of mcus, and created a few pcbs around them. A couple of years back, I heard about the new H7 range, with a 400MHz clock and available in a relatively easy to use LQFP package. A recent article about emulating the Gigatron computer on an STM32 rekindled my interest:

https://forum.gigatron.io/viewtopic.php?f=4&t=82

So I bought a couple of H7 Nucleo dev-boards to tinker with. Priced around £20 each, they represented a similar investment to what I'd made in 1983 with my ZX81 kit - and despite 35+ years of inflation, they seemed like a worthwhile purchase.

The STM32H7xx is a beast of a processor. It will clock at 400MHz (slow by laptop and Raspberry Pi standards) but it represents probably the fastest cpu that a hobbyist could hope to hand-solder onto a pcb. Compared to my ZX81 - it has 2 or 3 orders of magnitude more processing resources:

Clock 100X
ROM 256X
RAM 1024X

But - there is a major fly in the ointment, it's probably one of the least friendly devices on the planet. The tool-chain to support it is the best part of a gigabyte. It is not yet supported by mBed, and only flakily supported by Arduino. I tried to compile a blink example, which fell over at the linking stage, and required 13KB of binary to flash an LED.

After two disappointing and mostly fruitless afternoons, the Nucleo H743 board is no closer to being tamed, nor flash its first LED.

Seeking solace, I turned to the anycpu forum, and read some interesting posts about the origins of the ARM. I also read about BigEd's foray into programming the Discovery F4 board to emulate a 6502 at 18MHz. So potentially with the 400MHz H7, there's a possibility of a 6502 emulated at about 43MHz or better.

To get over this hump, I will probably just have to download Atollic True Studio, - the official STM IDE, and consume several more Gbytes of my hard drive, just to get this thing to execute code.

I'm probably just having a mid-life "Chuck Moore" moment - There HAS to be a better way......

An interesting situation we find ourselves in! Beware, this has become a meandering post.

For the Raspberry Pi, I think there are two or maybe three bare-metal tutorials. I thought these might be a good way forward, as you're programming in assembly language rather than C, so life could be simpler. But almost certainly you still need a pretty big toolchain, to assemble your code and make a bootable micro-kernel.

And yet, it still might be the answer, to get an ordinary open source toolchain, rather than use some proprietary development SDK? I seem to have 500M of a gcc ARM on this laptop, probably for PiTubeDirect purposes. That is, at least, a lot less than gigabytes.

Where I was going though, was that once you have a simple machine code monitor on your CPU, you're back to loading code from a terminal. Perhaps that would be simpler than building and booting from a kernel? You can then perhaps try to write a mini-assembler, and other debugging tools for the monitor. Perhaps after that, a Forth... or a tiny Basic.

It would be great to write and share an open-source monitor which can accept srecords or similar. That's the one binary people would need to flash onto the device.

Behind what I'm saying is the idea that programming in ARM assembly is easy and natural... this might be debatable. It certainly helps if you only use as many registers as you feel comfortable with. Don't prematurely optimise register use!

All this said, it just might be that the official and huge IDE is the fastest way to a blinking light.

(In the case of the Pi, you can boot RISC OS Pico, which gives you BBC Basic with the built-in assembler. This, to me, is very much the equivalent of the ZX81 or the BBC Micro, but better. So there's another project, see if the known and cast in stone BBC Basic binary could be run on another ARM platform, by providing it with the machine services it needs... or perhaps take Richard Russell's SDL Basic and turn it into a CLI application?)

That H7 chip and dev board do look rather interesting though. There's 1MByte of RAM, but within that is 64k of fast instruction RAM and 128k of fast data RAM. So it might well be a lot faster than the 168MHz F4 I was using - that has some kind of small cache but the flash behind the cache isn't very fast.
Datasheet for the chip: http://www.farnell.com/datasheets/2551152.pdf
Datasheet for the dev board: http://www.farnell.com/datasheets/2339627.pdf

I see they mention a choice of IDE:
• Keil® MDK-ARM(a)
• IAR™ EWARM(a)
• GCC-based IDEs including free SW4STM32 from AC6
• ARM® mbed™ online

Oh, and look: "Up to 164 5 V-tolerant I/Os" - that's quite newsworthy for a fast ARM! Are they available on the dev board?

Hi Ed,

The H743 dev-board will run at up to 400MHz - that's what the H indicates. However, I have heard that even the earlier STM32F405 could be readily overclocked from 168MHz to 225MHz.

The processor fitted is a 144 pin LQFP and has 114 GPIOs - almost all are accessible through 2.54mm pitched connectors - which makes hobbyist tinkering somewhat easier.

There's a TFT LCD controller on chip - with parallel RGB, Hsync and Vsync that could be used to drive a VGA monitor just with a few resistors.

The board is not yet supported by mbed - that was part of the frustration last weekend.

If you can emulate a 6502 on an STM32 - then presumably that offers a possibility of BBC Basic, but I suspect that the Richard Russel route might be less fraught.


regards


Ken

mmm, various routes to Basic on an ARM:
- 6502 emulator, then MSBasic, or EhBasic, or BBC Basic
- write a shim to run Acorn's historical ARM flavour of BBC Basic
- rework RTR's BBC Basic for SDL into a command line version.

Links:
http://www.bbcbasic.co.uk/bbcsdl/index.html
https://github.com/rtrussell/BBCSDL
https://github.com/hoglet67/PiTubeDirec ... WI_Handler

Terminal-BASIC looks like being far more capable than the usual TinyBASICs of the microcontroller universe.

—▷ https://hackaday.io/project/22036-terminal-basic
—▷ https://bitbucket.org/starling13/terminal-basic/src/default

Ed,

I was not aware of Dave Banks (Hoglet67) and others work on the Pi Tube Direct project - thanks for sharing.

Nor did I realise that a Pi Zero could emulate a 65102 at nearly 275MHz.

Given a sufficiently rich instruction set, and a fast enough clock, I suppose that any classic architecture can be emulated, with the performance gain over the original that you might expect after 35+ years of progress.


regards,


Ken

Might be worth noting that the very fast 65102 emulation is done in very highly tuned ARM code. The other CPUs offered by PiTubeDirect are written in C and show rather more modest performance.

Hi All,

In early February I posted about my unsuccessful attempts to get the 400MHz STM32H743 dev board running from within the Arduino IDE.

With the help of a friend and a bit of detective work - we discovered that a bug had been found in the latest GCC toolchain release - that causes the object file to be created with an incorrect starting address and so the conversion of the .ELF file to a .HEX file fails.

See the following for details https://github.com/zephyrproject-rtos/z ... sues/12257

The workaround is to overwrite the objdump.exe from the current release - with the same file taken from an earlier release from June 2018.

With that done - the Arduino IDE handles the Nucleo H743 dev-board as intended - and so now I can explore writing some code on a 400MHz microcontroller.

My first test was the Dhrystone integer benchmark - which when first run on a 16MHz ATmega328 took 78.67 microseconds to run through one Dhrystone run.

On the STM32H743, the exact same code is completed in 0.92 microseconds - a speed improvement of some 86 times - over the original 8-bit ATmega.

Now many of you will say that the Dhrystone has its problems, and there are better performance benchmarks - but hopefully if my compiler has not optimised away all of the Dhrystone code - then this 400MHz mcu claims to have 621 VAX MIPS performance.

I have also loaded my SIMPL interpreter - which is an easy and interactive way of toggling GPIO and performing loops and timing instructions. A 1 million empty loop of interpreted instructions executes in 32.46mS indicating that even interpreted instructions are executing at some 30MHz.

The Nucleo H743 board has a 400MHz ARM Cortex M7 microcontroller with 2Mbytes of Flash and 1MBbyte of RAM - available from Farnell and other distributors for about $25.

It certainly opens up some opportunities for generating VGA graphics directly from GPIO pins or for emulating other cpus - either retro-cpus or new instruction sets you may wish to explore.

regards


Ken

That's great news!

Hi All,

This weekend I decided to port Mike Chamber's 6502 emulator code, complete with EhBASIC ROM image to run on the Nucleo 743H dev board.

The task was simple and straightforward, with the code running first time.

A couple of tweaks to the RAMSIZE and the serial baudrate, and we now have an ARM Cortex M7, which thinks it's an 8MHz 6502, running EhBASIC V2.22. There are also ROM images for the C64 and PET which others have managed to get to work with Mike Chambers' emulator code.

This opens up the interesting possibility of using a high-end Cortex M microcontroller to emulate a range of classic microprocessors, minicomputers or even home-brew cpu ideas - without having to resort to FPGAs or a "big mess of wires".

All of the development can be done in C, with a variety of different IDEs available - including mBed, Arduino and PlatformIO.

The STM32H7xx range come with a huge range of modern on-chip peripherals - GPIO, UART, SPI, QuadSPI, I2C, ETH, USB, ADC, DAC, DMA, Timers and an LCD controller that can be pressed into service driving a VGA monitor using a resistor ladder network for the RGB signals.

The STM32H743 particularly appeals because it has 1Mbyte of RAM and 128Kbytes of flash. There is an external memory bus - but you can do a whole lot of experimentation using just the on-chip resources.

At about $25.00 - the Nucleo boards appear to be good value for money. You could hand them out to Computer Science or EE students, and run a full course using them.


regards


Ken

A great result! And as you say, plenty of onboard peripherals too.

If you have the time and inclination, it would be interesting to see if
Ian Piumarta's lib6502 does any better or worse than Mike Chambers' emulator. (Archive link as site is slow for me.)

Why the 6502? Just buy a APPLE II from the local ummm. Funny where did they all go?
What about using the 16 BIT version of the 6502 the WDC 65816
? in hardware real project.

Hmm, I think maybe you miss the point of the thread, oldben. Read from the top - you'll see the thread is all about coding, and how to code on modern platforms. Emulation being a means to an end.

There's plenty of room for threads about hardware projects, but this isn't such a thread.

I can't see much new on coding, unless you dare to try assembler programming on new hardware.
But good luck with writting emulations, getting them to compatable down to the bugs can be tricky.