CEGMON

[BillO]

I've been trying to get CEGMON assembling, working and annotated, in that order. I felt there was no point in annotating code that I could not assemble or that did not work.

I started with the cegmon-c1.asm posted in the zip file in the Software section of this site :http://www.osiweb.org/roms/cegmon.zip.

I found that that file would not assemble under my favorite assembler (M. Kowalski's 6502 Emulator) due to differences in how it interprets the ASL, LSR and ROL instructions. Once I fixed that I was able to assemble it but found it didn't work properly. There was some issue with the screen parameters and the address of one JMP instruction was off by 1. So now I have it apparently working fine on a Subperboard II rev. b with a monitor (TV) that can display 25 lines and have annotated about 25% of it so far.

It would be great if someone that is very familiar with CEGMON could give it a test and give the annotation a once over. http://www.onebytecpu.com/projects/cegmon/cegmon.zip

I eventually intend to get the whole thing annotated, but it will have to wait for a few weeks. Vacation first, memory boards next, then CEGMON...

[dave]

Nice work, Bill--Thanks for undertaking this project.

The sources I have originated from Ed's collection, and I don't know if the sources are original, or disassembled from the binary. Since he also distributes a version of the A65 assembler, it's no surprise that the code is compatible with A65. Since A65 compiled easily on Linux (and later Mac OS X), I used that to assemble my C2 version of Cegmon, which seems to work perfectly. I had apoogize for the issues with the C1 version--I didn't acquire a C1 until much later, and had simply assumed the C1 version would work.

Dave

[BillO]

No worries Dave. Just doing my part to keep these gems alive.

[Steve Gray]

Bill,

Have you considered using something like GitHub to host the code? You can then setup things so people can help out. That way everyone works on the latest up-to-date code. When people make changes they are submitted and you can incorporate their changes into the code if you wish. It also means you don't have to maintain your own archive as anyone can just zip the latest version from Github.

For example, I have a project to comment and modify the Commodore PET editor rom here:
https://github.com/sjgray/cbm-edit-rom

I used it to add support for additional keyboard layouts, extra screen editor routines (like ESC codes), and COLOUR support for my own add-on board.

That also reminds me, are there any "hard-coded" or "fixed" entry points in the middle of the code? These should be carefully documented. That way additions to the code will not moved, causing incompatibilities. On the PET editor rom I eventually found 5 entry points that could not move. It caused a lot of frustration as I would add some code and then the machine would crash.

I'd like to help you out, but not sure how much time I would have. In fact, one of the things I wanted to do was to add a PET-like full-screen editor to the OSI. Sadly, I've had no time for that, plus no time to fix my own OSI machines to even be able to test something like that out on.

Steve

[MK14HAK]

Github or Source Forge which would be best? Githup requires a requires a monthly fee doesn't it.
I think Jeff did a commented disassembly of Synmon somewhere that may be useful for reference in commenting yours Bill.
Mike

[Steve Gray]

GitHub is free

Steve

[BillO]

I could think about gitHub or SF. But it will have to wait. I'm pretty much out of circulation for 4-5 weeks.

But I am going on holiday!