There have been a few versions of the utility imd2raw.c floating around
that will take Dave Dunfield's ImageDisk-created images (i.e. an .IMD file)
and make a linear binary image devoid of any metadata. This is similar to
the function of Dave's IMDU.COM program's /b switch.
I've corrected a problem with the assumption that all imd2raw.c descendants
to date have made: sectors that have a skew (i.e. not 1-1 interleaved)
weren't linearized correctly. The skewed sectors need to be written out in
"sorted" order, which is not necessarily captured/physical order. This is
easily verified by comparing output from "IMDU /b" to earlier imd2raw
outputs on any .IMD that has a sector skew that isn't 1, 2, 3 [...].
It's up on github here:
https://github.com/RetroFloppy/imd2raw
I've been working on this project for ages. It is not complete. It may never be complete. It is, however, finally in a state that I consider to be eminently usable. A "beta" or "soft opening" - there are absolutely some visibly unfinished areas. But, it can absolutely be used while I continue improving the typesetter and the indexer, polishing the presentation, and adding manuals for new systems.
http://www.typewritten.org/Manual/
Some folks were given access to previous development versions and asked not to share the URLs. If you were one of them, please transition to this URL instead; this one can be considered fully public.
ok
bear.
ps. this announcement was also sent to the VCFED forum and the TUHS mailing list
I found this document by persistent google searches for information about "U of Arizona MUDBUG 6800" --
https://ntrs.nasa.gov/api/citations/19840010841/downloads/19840010841.pdf
Not sure this is the document the other gentleman referred to, but it did come from a "government" web site (NASA related).
Dear all,
I came across MUDBUG a monitor for the MC6800. It is much more “sophisticated” then MIKBUG and friends…
I did find a report at a .gov website that shows the manual and schematics. Could not find anything on the website of Arizona State University which did a great part of the development.
The question is if there is a) a S19 file, but rather the asm source code?
It would be nice historically to add this to the legacy of mikbug, minibug, etc.
Regards, Roland
MUDBUG
MUDBUG was a monitor and debugger program created for the Motorola 6800 by developers at Arizona State University in the mid-1970s. Designed as a resident system tool for low-level program control, MUDBUG provided early microcomputer users with interactive facilities to inspect, modify, and debug memory and registers. It exemplified the era’s shift toward software-based development environments for new microprocessors.
Key facts
Platform: Motorola 6800
Type: Machine-language monitor/debugger
Developed at: Arizona State University
Period: Circa mid-1970s
Purpose: Memory and register examination, program testing, and I/O control
Background and development
MUDBUG emerged shortly after Motorola’s introduction of the 6800 microprocessor in 1974, a period when educational and research groups built tools to support the device’s use in embedded and teaching contexts. Arizona State University’s version extended the capabilities of Motorola’s own MIKBUG monitor, offering improved memory handling and command flexibility for laboratory instruction and small-scale system development.
Hi all,
does anyone know what happened to www.retrobrewcomputers.org?
Regards,
Holm
--
Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
Goethestrasse 15, 09569 Oederan, USt-Id: DE253710583
info(a)tsht.de Tel +49 37292 709778 Mobil: 0172 8790 741
There are several other PAPERBYTES Books related to MC6800 assembler
programming.
Go to Archive.org and search for "PAPERBYTE BOOK" and you should find
several titles, including "Tiny Assembler 6800", and "TRACER - A 6800
debugging program" and "RA6800ML - relocating assembler for 6800" and
"LINK68 - a 6800 linker" and "Bar Code Loader".
Download the "PDF with text" versions of each book, makes it easier to
extract the source code, so you do not have to type it all in.
Mark S. Waterbury
Hello and thank you for the hints.
Short version:
Would you please tell me some more details about where to find " *Johnny's
tpw under 2.11BSD* " utility, which *"it achieved writing simh TAP to a
real TK50"* ? It will be of great help.
Long version:
I'm working at a PERTEC-interfaced tape emulator using some Am2900
bit-slice processors and a STM32. Currently I somehow replicated the simh
.TAP but it does not fully follow and respect its format. My emulator reads
tapes, dumps content inside 4 x 32MB EDO RAM for the data, and 1 x 4 MB EDO
RAM for the 'map of the tape' - file sizes, filemark separators and so on.
When EOT is reached, the tape is rewinded while the big RAM content is
dumped [AM2900 side] into a microSD card [STM32 side] while following the
tape map from the smaller RAM, in such a way that the resulting file
becomes a frankensteined simh tap file. It can also do the reverse - reads
that frankenstein TAP [STM32] and writes it to the tape.
The STM32 acts like an i/o interface to the microSD and also as a user
interface. All the rest (i/o protocol, interrupts, ram transfers) is done
with physical gates and some diode logic ROM, for me to keep the stm32
software part as simple as possible. Whatever I could implement with
external hardware, I did.
The big weirdness is as following: whatever format is dumped from the
physical tape inside my "not-quite-simh TAP" file, it appears to be
converted and written correctly back on another physical 9-track tape, as
it can be correctly read by another frankensteined half-breed dinosaur made
from some communist Romanian clones of PDP11 (called Coral 4030) - the
boards - and French CII IRIS50 (called Felix C-256) - the i/o peripherals:
tape drives, punched card, cassette tapes and so on.
However my "not-quite-simh" TAP is not accepted by simh and also not
accepted by the 'unvtape' program from you, mr. Jacob Ritorto, from your
github.
But if the STM32 sends data to its own RAM chip (the board containing
the stm32 is *waveshare's core429i*), then extracts it back, the simh file
format result is as perfect as it is supposed to be. But I can't use that
RAM with the rest of the system, as there are not enough spare i/o ports
left in order to talk to the AM2900 side.
The EDO Rams are tested and they work absolutely fine. I made some mistakes
for sure while building the physical board (bad/expired beer?), some little
mess with the gates which I can't fully follow - unable to replicate the
initial conditions, I no longer have that bad beer which gave me headaches
during the design phase. Now I have only the good stuff.
So I am asking for help in order to run that "*tpw" *program and follow
the registers, while graphing the physical measurements logic using two
HP1662 logic analyzers: would you please let me know where I may find it?
This is an older version of my pertec tape drive emulator. The project
advances slowly - not too much spare time available, not even to update
with new pictures and progress. My wife, child and workplace demand 99% of
my attention. Unfortunately I have limited knowledge about working with
github, mostly because it is owned by Microsoft (and used for inspiring
their business, that's why I refused to learn about it), and also because I
am used to the old times when programs were stored & exchanged on cassettes
and floppies, and version control was manually followed with pen and paper.
At this time it is easier and faster for me this way.
https://hackaday.com/2019/05/02/a-mainframe-tape-drive-emulator/
Thank you.
Vasile
On Tue, May 26, 2026 at 8:00 PM <cctalk-request(a)classiccmp.org> wrote:
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 May 2026 12:08:09 -0400
> From: Jacob Ritorto <jacob.ritorto(a)gmail.com>
> Subject: [cctalk] Re: ...a .TAP by any other name...
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk(a)classiccmp.org>
> Message-ID:
> <
> CAHYQbfAspc+gs6mRZv5ePmt__kp_xb-WvFUBO9K-HiCsX8iNyA(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Thank you for that ,Ken - good to have in the pocket!
> I tried Johnny's tpw under 2.11BSD and it achieved writing simh TAP to a
> real TK50. So I'm booting real hardware from that sept 1992 rsts/e image
> now!
>
>
> End of cctalk Digest, Vol 1186, Issue 1
> ***************************************
>
