Supermon64 sources

[whartung]

It seems to me that he's basing it on pages. That is, when he relocates, he's only change the high byte of the address, not both.

For example, I don't think it would work if you compiled it at origin $1234 and then at origin $2345. Rather it works for $1000 vs $2000.

Given that, limitation, it should work just fine for a dispersed address, since only the top bytes would change.

[jblang]

The relocator doesn't just adjust the high byte of the address though, it adjusts both high and low, and for that the address needs to be contiguous. Supermon isn't necessarily loaded at the same place within the page each time. It depends what other machine code has already been loaded and lowered the MEMSIZ pointer.

Anwyay, that note about not handling dispersed addresses is not mine, it came straight from Jim Butterfield. I'm sure there's a way to write the loader so that it could handle dispersed addresses, but I'm pretty sure as it's current written that it doesn't.

[jblang]

Regarding the earlier discussion as to the provenance of some of the code in Supermon64, I found a Compute article with the original Supermon for PET which credits.

Quote:

DISSASSEMBLER BY WOZNIAK/BAUM
SINGLE STEP BY JIM RUSSO
MOST OTHER STUFF (,HAFT) BY BILL SEILER
TIDIED & WRAPPED BY JIM BUTTERFIELD

So it seems that the disassembler did originate with Woz. The subroutine I found that was identical to the one in the Apple II Red Book is used by both the disassembler and the assembler.

Source: http://www.atarimagazines.com/compute/i ... amming.php

[BigEd]

Good find!

[jblang]

While I had monitors on my mind, I also decided to take a look at Micromon 64, which Bill Yee converted to the C64 from the VIC-20. It was available as a type-in program in Compute's First Book of Commodore. I contacted him and asked him if he had any sources for it, and his answer was "no, because there were none." Apparently it was edited in place in a monitor from the original VIC-20 binary.

Micromon for VIC derives from Micromon for the PET which appeared in the January 1982 issue of Compute Magazine, in an article written by R Arthur Cochrane: https://archive.org/details/1982-01-compute-magazine. That article states that Micromon is based on Extramon by Bill Seiler, which in turn was an extension to TIM, which was the original monitor on the first kit that MOS sold for the 6502, which included just a RRIOT chip pre-burned with the monitor and an instruction manual. The user had to provide the 6502 and all the passive components.

TIM was modified for keypad and 7-segment displays and became KIM on the computer by the same name. Later TIM was adapted for use on the PET, and eventually incorporated into the upgrade ROM provided by Commodore. It was at that point that Bill Seiler built Extramon on top of TIM, which apparently is when the code from the Apple II assembler/disassembler was introduced. So far I have been able to find neither binaries nor sources for Extramon. From that point, the lineage of the monitors split into two taxa: Micromon and Supermon, both for the PET. Both had offspring for the VIC-20 and then the C64. Supermon64 was enhanced with features from the Commodore 128 monitor to create Supermon+64 in 1985, which is the version that I have commented in my github repository. And from Micromon, Commodore created the MADS Monitor, and HES derived Hesmon.

Now, with the Book of Genesis out of the way, here are the sources I have been working on for Micromon 64: https://gist.github.com/jblang/2cab2d04 ... 05d6222c8c. I disassembled Micromon using regenerator 1.7 by Nostalgia: http://csdb.dk/release/?id=149429. From there, found the strings in the binary and figured out where the command table was. With that knowledge, I found the command vector table and from there the address of all the major functions.

After identifying the major subroutines, I set about deciphering the various I/O routines, which are a special kind of spaghetti code. I have never seen so many JSRs. The assembler and disassembler code are basically the same as Supermon 64, which is to be expected since they both derived from Extramon. Code for many of the top-level functions (Hunt, Compare, Transfer, Memory and Register Display and Modify) are pretty similar between the two. The major difference between the two is that the input routines on Supermon+64 are much saner and more understandable, as well as more flexible, not requiring a set number of digits and allowing inputs in any base.

The most interesting parts of Micromon are the single-step debugging functions: Break , Walk [w] and Quick Trace [q], since those don't exist in Supermon+64. I have started tackling those but still have quite a way to go. They make use of interrupts and some pretty convoluted logic that is going to take me a while to unravel.

[DerTrueForce]

I actually have that book. I tried to get Micromon going at one stage, but I had to enter MLX to do it, and I never got that in completely. The C64 I'm using has a weird glitch where if you push too hard on or around the A key, it starts running the program, and because I haven't got the whole thing in, it's broken and I have to reset it, because it disables the key you use to crash the program. That doesn't help, and the tiny screen(~5") I'm using doesn't really help either.
I'll try saving it to tape after I get each line or two in successfully, and reloading it after I have to reset it.

[jblang]

Do you have any means to access a d64 image from your commodore? Either by writing it to a real disk or something that reads SD cards like a SD2IEC or a 1541-Ultimate-III? If so, you can find the disk image for it here, and it would be a lot easier than trying to enter it: http://www.bombjack.org/commodore/books.htm. Also, in my personal opinion, I prefer Supermon+64 to Micromon. The disk containing that is under Jim Butterfield's ML Programming for the Commodore book.

Edit: if you don't have an SD2IEC and want to buy one, they're available here: https://www.thefuturewas8bit.com/index. ... odore.html. I actually built my own for a lot cheaper than that, but if you're not handy with electronics, this will save you a lot of time.

[DerTrueForce]

Unfortunately, all I have is a tape drive. I get the idea that a disk drive is far more reliable than a tape drive, but I'm stuck with it.

I could very probably build an SD2IEC, although the firmware may well trip me up. I'll have a look at it.

[BigDumbDinosaur]

jblang wrote:

And from Micromon, Commodore created the MADS Monitor...

Not sure where you got that information. I was one of the first purchasers of MADS and distinctly recall, upon firing up the monitor (there were two of them in the package—one loaded at $8000 and the other at $C000), that it looked just like Supermon. According to Fred Bowen at Commodore, the MADS monitors were Supermon with some adaptations to fit the C-64's architecture, as well as commands to save and load machine code, as well as send some commands to the disk (somewhat like the old DOS wedge). The C-128's monitor was a Supermon derivative as well. Funny how that code got around.

Supermon 816 perpetuates the name, but had to be written from scratch, since it was intended to target the 65C816 running in native mode. I tried to adapt an earlier monitor I had written for the 65C02 (c. 1992), but soon realized starting with a blank sheet of paper would take less time.

[jblang]

Quote:

Not sure where you got that information.

By disassembling it. The code is almost identical to Micromon, albeit with some functionality removed. The biggest difference is that MADS uses zero page for a lot of variables whereas Micromon puts them in the tape buffer. Many of the subroutines are identical. Definitely much more in common than with Supermon64.

I've put up the disassembled monitorc000 code on gist too: https://gist.github.com/jblang/0f4cbfd6 ... d1b86a4fda

I didn't put nearly as much time into defining labels for it as I did in Micromon and I haven't commented it at all, but you should be able to spot the commonalities.

Another thing I have noticed is that in general Micromon and its derivatives will continue disassembling or dumping memory for the next/previous addresses when you scroll using the cursor up/down keys, but Supermon derivatives don't.

[BigEd]

Great investigations, jblang, thanks for sharing and preserving your findings!