ML Monitor Program?

[JohnnyRockets]

I have sort have asked this before, but it kind of got lost in all my messages.

 

 

If I want to get a ML Monitor program or cartridge for my VIC-20 or C64 to run natively on it, what should I get or what are the choices?

 

 

 

I not have a Disk Drive that I believe (haven't done it yet) will work on both machines.

 

 

 

So is there a floppy out there? Or a cartridge that can be bought (with JUST the ML Monitor on it?).

 

 

 

Or is all that a waste of time and I should just buy a uIEC device?

 

 

 

 

Thanks (again?),

 

 

 

 

JR

[TMR]

If I want to get a ML Monitor program or cartridge for my VIC-20 or C64 to run natively on it, what should I get or what are the choices?

 

For the VIC, the only cartridge monitors i'm aware of are HESMon from HES and Commodore's Machine Language Monitor Cartridge. There's a few programs after that although i can't think of any off the top of my head and you will need a RAM expansion for a software-based monitor since the stock 3.5K isn't enough space for it and your own program.

 

For the C64 on cartridge, there's three iterations of the Final Cartridge, just about any Action Replay, the Retro Replay, the Expert Cartridge, the KCS Power Cartridge, Super Snapshot and a few other solutions on top of that which aren't freezer cartridges so they mount over RAM and use space you'd otherwise put your programs into. There's quite a few software-based monitors out there too, SMon, John Twiddy's DisMon, even the Dropzone monitor which is actually the Zeus 64 monitor, hidden in the C64 version of Dropzone and presumably used for debugging the game. The only options i'd advise personally are freezer cartridges because they come with other tools as well; preferably get a Retro Replay if it's ever an option, or an Action Replay 5 or 6 depending on territory.

 

Or is all that a waste of time and I should just buy a uIEC device?

 

Getting uIEC won't get you a machine code monitor, it only does a partial simulation of a floppy drive and nothing more. Getting a 1541 Ultimate 2 or Chameleon also gets the option to mount a freezer cartridge image for most of the devices mentioned above and, if memory serves, both ship with a Retro Replay installed "out of the box".

 

You do seem to be fixating somewhat on the monitor... once you get past the initial stages of learning you'll have moved onto using an assembler and the monitor won't be used for anything more than the occasional crash-and-burn debugging session.

[JohnnyRockets]

TMR,

 

First off thanks!

 

Maybe I don't understand things right. I thought I could just program in ASM in the monitor and then save it when I liked what I have (all done on the native C-64)?

 

When you say "using an Assembler", you talking about using one of the ASM iterations on my PC, right? Is it a bad idea to try to program right on the C-64?

 

 

Thanks!

 

 

 

JR

[Rybags]

Doing assembly programming inside a monitor is painful at best.

 

No labels. You have to calculate branch targets yourself. Easy enough in short loops going backwards, not the case when branching forwards.

 

To program on the real C64, something like Machine Lightning works well. It's a disk based Assembler/Editor, sort of similar to Mac-65 although with a bigger memory footprint.

 

But in the modern day you're best off doing stuff with PC based tools. Use real machine for periodical testing.

[TMR]

When you say "using an Assembler", you talking about using one of the ASM iterations on my PC, right?

 

No, i'm talking about assemblers. Some are cross assemblers that run from another machine (a PC, Mac, Amiga, another C64 connected by some kind of serial or parallel link, a TRS 80, a Sage 68000-based minicomputer, these and others have all been used in the past - i saw C64 games written on Amstrad PCW wordprocessors and cross assembled during the 1980s) and others run natively on the machine they're assembling for like Zeus 64, the almost ubiquitous Turbo Assembler or Commodore's own assembler.

 

Cross assemblers are better than native because they don't take any memory from the target machine[1] and take seconds to generate code that could take minutes (or, in the case of Commodore's assembler, hours) on a native tool. Cross assembly is the way many people and companies went back in the 1980s as soon as they realised/could afford to, either brewing their own system as small two-man firms like Graftgold did (Andrew Braybrook's Morpheus diary for Zzap! 64 documents the arrival of two Opus 386 clones for himself and Steve Turner) or buying into a commercial solution like PDS[2].

 

Is it a bad idea to try to program right on the C-64?

 

Not a bad idea no, but trying to write anything substantial (as in more than a "hello world"-style example in a programming book) with a machine code monitor is masochism, pure and simple; monitors are debugging tools used to yank the machine back to life after a crash and pick through the debris of fallen code, assemblers are programming tools used for actually writing the programs in the first place.

 

[1] i have a project right now that, as soon as it runs, takes over nearly 32K of memory and would've clobbered the native assembler i used to use, it's built-in monitor and the source code.

 

[2] In the early 1990s i visited System 3 in London and got to see the DOS-based PC Chris Butler was using for Turbocharge building the first level and dumping it to a C64 with an Expert cartridge loaded with PDS receive software, that's what inspired me to build my own ham-fisted (and cheaper) cross assembly rig.

[JohnnyRockets]

Okay guys (Rybags and TMR), it sounds like the most widely used methodology to develop for the C-64 is to use some form of Assembly program on the PC (your choice) and then just test it in WinVice, with an occasional "hard test" on the real machine.

 

Does this sound about right?

 

I kind of sounds like developing right on the C-64 is just difficult at best, and kind of only an exercise that some kind of "purist" would really pursue. Otherwise, why not develop on the PC because it is 10x easier with modern hardware?

 

Am I on the right track here?

 

 

Thanks! JR

[Rybags]

With a decent PC-based IDE setup, you can make a change and reassemble + run the program from an emulated cold start + load in a few seconds.

Real machine you can be talking minutes even for something that's only several K.

 

It's just so much easier - the isolation between the edit / assemble / run means chances of losing work due to crash isn't a problem. Quick turnaround on compile/test means you don't lose your train of thought when testing trivial changes. Much less volatile debug/monitor environment means you can interrupt your program and check it's vitals with no chance of inadvertant corruption.

 

Over the life of developing a medium sized project, you're talking turning months into weeks, weeks into days.

 

If you want to go purist and literally take a year, then go ahead (assuming like many of us, you only get the odd hour or 3 to spend developing stuff).

If you want quick results and better overall quality, the PC-based route is the way to go.

[JohnnyRockets]

If you want to go purist and literally take a year, then go ahead (assuming like many of us, you only get the odd hour or 3 to spend developing stuff). (NOT ME!)

If you want quick results and better overall quality, the PC-based route is the way to go. (THIS WOULD BE ME!)

 

Okay, great help here Rybags, thanks a lot!

 

I think I will proceed as follows:

 

1) Pick my favorite ASM program (what is your favorite?).

 

2) Pick my favorite IDE program (what is your favorite?).

 

3) Run it all in WinVice

 

4) Buy a uIEC device to test with on the real hardware.

 

 

I think that sums it up... anything else you would do?

 

 

 

Thanks again, your help is priceless. JR

 

5)

[Rybags]

The Asm and IDE are seperate from emulation, ie they run under Windows.

 

Running editor and assembling inside a emulated C64 will present similar problems to doing it on real hardware, although you can get around the speed issue (warp key).

 

CBM PRG Studio is the latest thing on the block for C64 dev. I've not used it but it's highly rated by many.

 

http://www.ajordison.co.uk/

 

Announcement + forum thread http://www.lemon64.c...pic.php?t=36600

 

 

ed - another thing I forgot - PC-based dev tools, you're doing away with primitive editors and line numbers. That alone saves a lot of hair pulling.

Edited June 18, 2012 by Rybags

[JohnnyRockets]

Yes, I understand that the ASM and the IDE are run under windows.

 

I was just wondering what you were using for these tasks.

 

Gotcha on CBM PRG Studio, I will be checking that out shortly! And checking out the thread on Lemon64 (of which I am a member also).

 

Agreed on the line numbers, the always were a hassle and it is good to do away with them. And if you saw my hair, you would know that I cannot stand very much hair pulling!

 

 

Thank you! JR

[Rybags]

I'm still using AtAsm but it's not real feature rich and is kinda dated and not really supported any more.

 

There's plenty of assemblers around, most are command-line from a Dos window but IDEs and many editors allow to call them and capture the output (listing).

 

TMR would probably have some good recommendations for a C64 one. Although for the most part 6502 assemblers are universal. So long as you can generate raw binaries it'd be OK for the C64.

[TMR]

TMR would probably have some good recommendations for a C64 one.

 

At the moment i'm using ACME because it's taken everything i've thrown at it for the last year since i switched to it and happily assembles for just about any Commodore 8-bit and some Atari kit too. For an IDE i've been using Crimson (the SVN release from Sourceforge) for several years now and have it configured for multiple assemblers.

[JohnnyRockets]

Yeah, I think I'm going to start developing (read: learning) with the PC and then just test on the real thing.

 

I really like the look of CBM PRG Studio, so I'm going to pursue that route a bit.

 

 

Thanks for your help Rybags! JR