Hi EEye
I know you've been working on disassembling and reworking, but do you now have the original typed-in source for Micromon? It would be great to have that in an archive somewhere.

Cheers
Ed

I do. I've tested it in VICE after making an image of it and it works, but I think it may already be stored here.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Hmm, I can't find it anywhere online - we're looking for January 1982. All the online disks are from 1983 onwards.

The article text is there:
http://www.atarimagazines.com/compute/i ... CROMON.php

but not the program.

So if you have it, perhaps you could share it?

Edit: hang on: are these they?
http://www.commodore.ca/gallery/magazin ... e-1-43.htm

oh, I didn't realize they were that old... Check your email!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Got it - thanks! (4k ROM file for micromon64 - a different version from the one in the magazine article, which is also different from the vic20 v1.2 version I found elsewhere "Bill Yee 1983".)

What I'd completely failed to realise, which is obvious really, is that these programs were published only as hex dumps. Whereas I was hoping to see the original assembly source. It seems like we're only ever going to see more or less inspired disassemblies, although the article does say that the source code is (was) available.

I like the fact that micromon (as found in the magazine) only needs 4 external routines, and two of those are for load and save.

But Supermon is half the size... and there's a more intelligible source (actually a listing) here. As far as I can tell, Supermon runs from $8000 to $88AE in this listing.

Back up at 4k in size, but fully commented and modern, we have Ken's Krusader monitor for the Replica 1, as announced here

Exactly, it just needs character in from a keyboard, and character out for a display. Also, Micromon-64 can copy and compare blocks of memory...


Supermon is worth looking at first IMO because we have a commented listing, and like you pointed out, much smaller. Most likely it just needs two primary routines modified for a 6502 core. For your original 65Org16 core, I think only features like block copy/compare/fill, etc. would have to be modified since we're looking at a much more expansive memory. Where else would one have to focus on modifications as far as you can tell?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Found a page here with the hex for supermon4 (for the PET), if that's worth anything. I'm actually a bit more comfortable with that as it's stated to be free software, as opposed to the listing which is stated to be copyright. (Yes, ages ago and to a defunct company)

I do also have SuperMON-64, it's only 2.5K. Along with a book I also have called Mapping the 64 I should be able to make sense of the JSR's and JMPs and substitute routines to make it work. This is pretty much where I had left off on the 6502SoC and when I'm done the 65Org16 mainboard, I plan to come back and get my brain in software mode and make it work initially with Arlet's core.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

A couple of thoughts:

- the supermon by synertek for the kim-1, for which we have the listing: is that in fact a completely different and unrelated program to the later supermon programs we've seen for PET, VIC and C64? It's a similar length but is that as far as the similarity goes?

- given the emulator we have, do we need a little less from a monitor than we would have done back in the day? It might be easier to debug a program in the emulator than on the machine itself. Any improvements we make to the emulator benefit all users of the emulator, for any CPU (6502 or, one day, 65Org32.) Although, to debug hardware we might well need a monitor.

Cheers
Ed

Not really sure.
I know the ascii data for the startup screen is right at the beginning of at least the pet and 64 version, followed by a string of TXA's, then the beginning of the program with an LDA $2D, STA $22...


Personally, this is my main driving motivation!
Imagine sitting there writing code after the FPGA boots up with the monitor in a brand new system, no drivers for video, no drivers for USB data transfer, or memory compare to FLASH/RAM, etc, no drivers for HDD.
Like you I got tired very quickly of programming the FPGA each and every time a small change was made.
Actually I have character out routine written for the TFT panel, and character in routine for the PS2 core. The TFT panel would be used at the very beginning of development, until at least the video drivers for the CS4654 could be written.

Incidentally, you can open up binaries using M. Kowalski's assembler. It assigns labels for everything though, so with a little bit of effort you can make it look like it should. Then assemble it back to binary form and compare it to the original. I've already done this for Micromon, before I found Supermon. Now I must do this for Supermon as well.

How does this apply to 65Org16? Not so sure yet, but when I do get around the software aspect, I'll be thinking along lines of how to translate it over. Port it I guess is the correct term.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Manual "porting" will not be necessary thanks to Bitwises' Assembler! It does it automatically.

The following taken from here.

So all that's needed is to copy the assembly listing, say from MK's assembler, and paste it in the Assembler.

I have Arlet's bin2coe in the same folder as Bitwises' assembler. That way, from the command line, I can do a quick nmake to make the binary, and then bin2coe -2 to derive the .coe from the .bin.

You can even add the bin2coe line to the makefile, so you only have to type "make" to get everything done.

How do I do this?

Add a rule somewhere that says:

Now, if you also have a rule to turn the source into firmware.coe, you can type "make firmware.bin", and it will automatically do everything it needs. Make sure the second line starts with a TAB character.

If you put firmware.bin as the first target in the makefile, e.g. by having a first rule that says:


Then all you need to type is "make" (it will default to the first target it finds).