I’m scoping out a fourth edition of my book, Assembly Language Step by Step. I got wind of a simple FOSS utility that could be enormously useful in that effort: SASM (SimpleASM), which is an IDE created specifically for assembly-language work. It’s almost ideal for what I need: Simple, graphical, with a surprisingly sophisticated text editor and a graphical interface to GDB. It works with NASM, my assembler of choice. I want to use it as the example code IDE for the book. I installed it without effort on Windows, which is why I decided to use it. But I want to use it on Linux.
Alas, I’ve been unable to get it to install and run on Linux Mint 19 (Tara) using the Cinnamon desktop.
I’ve installed a lot of things on Linux Mint, all of them in the form of Debian packages. (.deb files.) I downloaded the SASM .deb file for Mint 19, and followed instructions found on the Web. There is a problem with dependencies that I just don’t understand.
I got it installed once but it wouldn’t run. I uninstalled it, and then it refused to reinstall.
Keep in mind that I am not a ‘leet Linux hacker. I’m a teacher, and most of what I teach is computing and programming for newcomers. The problem may be obvious to Linux experts but not to me. Most of the software I’ve installed on Mint came from repositories. SASM is a .deb download.
So. Does anybody else use it? If you’ve got Mint on a partition somewhere, could you try downloading it and installing it? I need to know if the problem is on my side of the screen or the other side.
Thanks in advance for any advice you might offer.
My advice would merely be to try the Linux Mint fora. I have found them (sometimes) helpful.
Oddly, installation issues are a major impediment to my committing a machine to Linux.
That’s odd. I did sudo apt install sasm, on PopOS (also a Ubuntu derivative) and it installed and appears to run without difficulty. Likewise, it installs on a raspberry pi without difficulty, which is all the way down to the Debian roots.
Uhh… you’re on a 64 bit version of Mint, right?
Yes. The lscpu command from a terminal told me it was a 64-bit instance; double-checked with system details. The CPU is a Core i5-2400, which like all Core i5s is 64-bit.
Now, did you download a .deb or get it from a repository?
The system barfed when I tried to install cpuid, and I suspect there’s something (or more than one something) messed up with this instance. 19 isn’t the newest release. I suspect I’m going to wipe this one and install the latest.
Thanks for giving it a try.
Ok. It’s been a busy morning. I downloaded the latest Mint, and burned it to a USB thumbdrive with a utility I’d never seen before but recommend: Balena Etcher. I installed it on Windows, but there are versions for Mac & Linux:
https://www.balena.io/etcher/
FOSS, simple, does one job well. I booted the 64-bit Dell quad box I’m using for the assembly book project and installed Mint as the only OS on the box. Again, worked beautifully, with a PITA factor approaching zero.
With the install done, I started the software manager, searched for SASM, and it was there in the repository. Selected SASM and told the system to install it. I’d been warned that the flatpack didn’t install correctly and used the .deb. Wham! SASM is there, in the Programming tab.
So there was something badly wrong with my old Mint instance (that I’ve been using since 2019) which wasn’t a surprise. My only regret is not buying an SSD for it and swapping out the HD for an SSD. No biggie; it’s plenty fast. I’ve got some testing to do and will review SASM in a future Contra entry.
Again, thanks for giving it a shot. It pushed me into what I should have done some days ago, which was wipe the box clean and start fresh.
You might check the specifications for your HDD and compare them to one of the SSDs you were thinking of.
I ran into this a few years ago, finding that while fast SSDs are indeed fast, many SSDs – even some major name brands – are not. In some cases, far slower than spinning rust.
Success! All I had to do was install NASM from the Software Manager. And something else: gcc (here used as a linker) couldn’t find a .o library file. A little sleuthing online showed that you also have to install gcc-multilib:
sudo apt install gcc-multilib
That took care of the error. After that everything just worked. I didn’t have to fool with the assemble and link command lines; the defaults worked as installed. The x64 example program (a typical “Hello World” for Nasm) installed with SASM uses I/O in libc. I rewrote the example to use the syscall instruction, which is new for x64 and replaces the interrupt 80 call gate protocol I used in the 3rd edition.
Debugging was seamless, using SASM’s front end for gdb. I set breakpoints and single-stepped, with current register values displayed in a window.
I’m going to start converting my x86 example programs from the existing edition, and unless something really untoward happens that I can’t figure out, SASM will be the IDE I use in the new edition.
Using Linux Mint x64 20.3 – you can install Mint version via the LM software manager.
Runs v 3.11.1 I think.
> Oddly, installation issues are a major impediment to my committing a machine to Linux.
—
It took fifteen years – 2003 to 2018 – before any Debian variant would install on any of the various machines I had during that time. The installer would run a few minues and just die. That covered a pretty wide range of PC configurations. None of the forums were helpful. Finally, one day in 2008, the installer completed instead of opening a subspace channel to V’ger, and I’ve run Debian or variants occasionally since.
Mind you, those same machines had no problem with Slackware, Mandrake, Fedora, or openSUSE – just Debian.
That said, things are a whole lot better now, as is package management, which used to give Windows “DLL Hell” a run for its tears.
Yay! glad you got it to work!
SASM works. Loaded a number of other 32-bit example programs on it and it did the job flawlessly. So I began to go through the chapters. The first several are mostly conceptual and haven’t needed a whole lot of tweaking, as they’re not tied to a specific CPU architecture. After that, well, it becomes a lot more work. But in truth I don’t have to rewrite as much of the book as I had to in 2008, when all the DOS material had to go into the wordgrinder to make the whole book based on Linux. I’ve been surprised at how little changing my (admittedly) simple 32-bit example programs have required, granting that I already know 64-bit assembly from years of getting ready for this project. This may not be quite the grind that I feared, and certainly not the grind that the previous edition was.
Also, yes. Balina-etcher ftw.
I have been on Linux Mint since 2011, exclusively since my last Windows laptop burned up its graphics section in 2016. Mint was originally created to be a Linux substitute for WinXP when end-of-life was imminent. Mint was fabulous. But some years later, after XP was completely gone, the original Mint developers left, and the newer ones started embracing Unity as an option, and basically abandoning the original goal. I felt in limbo, because that is when my Windows machine ground to a halt, and I was left only with Linux (not a bad thing, though).
Experimented with a couple other distros, and was on CentOS for a while,–but not really happy,–when I came across info that the Mint developers had switched to Ubuntu as their basis, and worked Mint up from there. I went back to Mint a few years back, and have been essentially happy since.
But I can attest that you need to be on the latest version of Mint. Things start going wonky with the older versions, and they never get fixed, regardless of whether they are LTS or not.
It looks like that is what you did, and all is well now. I still have an i7 CPU running Mint 19.3 that I use for audio editing, and the jackd patchbay program freezes up regularly. No problems at all when 19.x was the primary release. I guess I would recommend not doing updates after a new major release comes out, as it is always one of those updates that eventually causes problems with the older releases. That was also true way back before I abandoned Mint for a few years around 2015. Glad you are on the latest release and all is well. Mint really is the best thing since XP, IMO.
–Chuck
I had been using Lint Tara, which was 19. I tried to install the old Insight debugger front end for gdb, and got all fouled up. Insight was pretty, and easy to use, but internally it’s a nightmare. It actually uses the ancient Motif widget set, and is some sort of encapsulation of Tcl/Tk inside an executable. Some of my readers were able to jigger it into operation, but it’s a mess, and with SASM I don’t need it anymore.
I’ve tried a lot of distros, and so far I like Mint the best. The Cinnamon desktop is nice, and close enough to MS UI conventions that it doesn’t mess too much with my mind. I’d really like to find a desktop that looks more or less like Win7. So far, no luck. Which surprises me, because it’s an obvious thing to do.
Not especially fond of the W7 desktop look, but have you seen this?
https://www.ubuntubuzz.com/2020/01/linux-mint-with-windows-7-theme.html
Hey, that’s pretty cool. But I don’t think I’m going to convert the machine I’m setting up for the book project. I want the machine to be pure undisturbed Mint Cinnamon except for the SASM stuff and maybe the Bless hexdump utility. After it’s all over, I’ll give that theme a try, and see how much of my current desktop I can replicate using Wine and Linux versions of things I use under Windows. I’ve wanted to do that for some time.
I’d probably use a VM to establish the very controlled environment you want for the book. But I am so VM-oriented, I usually see that as the first-line strategy of choice.
There are not a lot of Windows-only programs I need, but Andre Wiethoff’s Exact Audio Copy (EAC) primarily for the WAV editor (secondarily for CD ripping which I don’t do much of, anymore), and Martin Pesch’s MP3 DirectCut, which allows operating on MP3’s without conversion. I try to keep things simple, because I work with volunteers at a community radio station and recommend Audacity for audio editing simplicity, but Audacity raises the noise floor from lower than -70db to about -50 or louder in the conversion to and from its native audio format, which can be a problem in a radio setting. If I can do it in EAC’s WAV editor or MP3 DirectCut, then no harm is done to the noise floor. Both programs work well in WINE.
I have always wanted to try Irfan Skiljan’s IrfanView on WINE, as it is the best image viewer and basic manipulator ever, but have never gotten around to trying it.
a year ago i learn assembly from your book it’s a great learning, and become fan of your teaching style basic to advance and i just come around your website and reading your this blog, i knew you are working on fourth addition. and now i am eagerly waiting for it. i want to know when it will released (assumption)
your fan
never
It may take a year. We don’t know yet. It’s a 600-page book and I have to go through it page by page, updating everything (including the drawn figures, source code, tables and screenshots) to bring everything in line with the x64 architecture. It’s going to be a great deal of work. I estimate summer 2023.