Cowgol Development Environment Comes To Z80 And CP/M

Cowgol on Z80 running CP/M ties together everything needed to provide a Cowgol development environment (including C and assembler) on a Z80 running the CP/M operating system, making it easier to get up and running with a language aimed to be small, bootstrapped, and modern.

Cowgol is an experimental modern language for (very) small systems.

The Zilog Z80 was an 8-bit microprocessor common in embedded systems of the 1970s and 1980s, and CP/M was a contemporary mass-market operating system. As for Cowgol? It’s an Ada-inspired compiler toolchain and programming language aimed at very small systems, such as the Z80.

What’s different about Cowgol is that it is intended to be self-hosted on these small systems; Cowgol is written in itself, and is able to compile itself. Once one has compiled the compiler for a particular target architecture (for example, the Z80) one could then use that compiler on the target system to compile and run programs for itself.

Thankfully, there’s no need to start from scratch. The Cowgol on Z80 running CP/M repository (see the first link of this post) contains the pre-compiled binaries and guidance on using them.

Cowgol is still under development, but it works. It is a modern language well-suited to (very) small systems, and thanks to this project, getting it up and running on a Z80 running CP/M is about as easy as such things can get.

Thanks to [feinfinger] for the tip!

You Can Now Bootstrap Your Amiga Without A Floppy With This One Weird Trick

Traditionally, most Amigas were intended to boot from a floppy disk. . An Amiga can readily make its own boot floppy, but only once it’s already booted up. If you don’t have a floppy ready to go, you’re out of luck, as PCs can’t readily make them for Amigas. [Roc] whipped up the amigaXfer bootstrapping method to solve this very problem.

Shorting a couple of pins together can unlock a serial debug mode that can be used for bootstrapping the machine.

Available on Github, the amigaXfer tool is able to perform several tasks with an Amiga via its serial port. The Amiga must first be turned on while plugged into another computer running amigaXfer via serial connection. When the Workbench floppy prompt comes up, the CrashEntry feature on amigaXfer should be triggered, and the BERR and GND pins on the Amiga’s 68000 CPU should be connected just for a split second, triggering the Amiga to go into a special serial debug mode. This enables amigaXfer to take control, allowing a disk to be formatted and written with a debug bootblock, and this disk can then be used to boot the Amiga without the need for the hack.

It’s a nifty way to get your Amiga up and running if you’ve just bought it off eBay and it didn’t come with any disks. From here, you can use amigaXfer to load other programs onto the Amiga via the same serial cable you used for the bootstrapping process, too. The hack isn’t limited to just the Amiga 500, either. It should work on a range of machines, including AmigaOS versions 1.x, 2.x, and 3.x.

Unlike the Commodore 64, we probably won’t see brand new replica Amigas anytime soon, but we can dream. As always, if you’ve got ’em, send your hottest Amiga projects into the tipsline!

CortexProg Is A Real ARM-Twister

We’ve got a small box of microcontroller programmers on our desktop. AVR, PIC, and ARM, or at least the STMicro version of ARM. Why? Some program faster, some debug better, some have nicer cables, and others, well, we’re just sentimental about. Don’t judge.

[Dmitry Grinberg], on the other hand, is searching for the One Ring. Or at least the One Ring for ARM microcontrollers. You see, while all ARM chips have the same core, and thus the same SWD debugging interface, they all write to flash differently. So if you do ARM development with offerings from different chip vendors, you need to have a box full of programmers or shell out for an expensive J-Link. Until now.

[Dmitry] keeps his options open by loading up the flash-specific portion of the code as a plugin, which lets the programmer figure out what chip it’s dealing with and then lookup the appropriate block size and flash memory procedures. One Ring. He also implements a fast printf-style debugging aid that he calls “ZeroWire Trace” that we’d like to hear more about. Programming and debugging are scriptable in Lua, and it can do batch programming based on reading chip IDs.

You can build your own CortexProg from an ATtiny85, two diodes, and two current-limiting resistors: the standard V-USB setup. The downside of the DIY? Slow upload speed, but at least it’ll get you going. He’s also developed a number of fancier versions that improve on this. Version four of the hardware is just now up on Kickstarter, if you’re interested.

If you’re just using one vendor’s chips or don’t mind having a drawer full of programmers, you might also look into the Black Magic Probe. It embeds a GDB server in the debugger itself, which is both a cool trick and the reason that you have to re-flash the programmer to work with a different vendor’s chips. Since the BMP firmware is open, you can make your own for the cost of a sacrificial ST-Link clone, about $4.

On the other hand, if you want a programmer that works across chip families, is scriptable, and can do batch uploads, CortexProg looks like a caviar programmer on a fish-bait budget. We’re going to try one out soon.

Oh and if you think [Dmitry Grinberg] sounds familiar, you might like his sweet Dreamcast VRU hack, his investigations into the Cypress PSOCs, or his epic AVR-based Linux machine.