C64 / VICE "Save" Question

[JohnnyRockets]

Hey everyone,

 

I have been playing with VICE and C64 emulation, and I can understand how to write programs in BASIC and save to a disk image.

 

But my question is, how do you do this with an ASM program?

 

I believe that I would need a MLM to write programs on the C64, but once I have an MLM program loaded and am using it, how would I save the ASM program that I am developing to a disk image?

 

I know that I could just develop in an editor (Windows) and test on the VICE emulator, but what if one wants to develop in ASM, right on the VICE emulator and save to disk "old school" style? Or is this process just more of a pain than it is worth???

 

 

Thanks,

 

 

 

JR

[TMR]

I believe that I would need a MLM to write programs on the C64, but once I have an MLM program loaded and am using it, how would I save the ASM program that I am developing to a disk image?

 

All monitors have save and load options, although the syntax varies between them so it'll be down to rooting through the "manual" to find the specific variation for what you're using. Usually it'll be something like s "filename",8,6000,7000 which writes to device 8 and saves everything between $6000 and $6fff - some monitors will save $7000 as well, others won't so again it's a matter of reading the docs.

 

I know that I could just develop in an editor (Windows) and test on the VICE emulator, but what if one wants to develop in ASM, right on the VICE emulator and save to disk "old school" style? Or is this process just more of a pain than it is worth???

 

It isn't significantly more painful to start with but working with a native assembler has some major drawbacks that become apparent around halfway through the first reasonably-sized project. The biggest issue is memory, with most popular assemblers sitting at $9000 or $a000 upwards and leaving between 35K and 39K free to the programmer... a lot of which will be taken by source code rather than the assembled target code or data.

 

As an example, i converted my own game Cyberwing from the original Zeus 64 source files to cross assembly a few years ago, originally it was three source files (titles page, main game and end screen), each of which took about two minutes to assemble with my modified version of Zeus that took advantage of the C128's 2MHz mode that then shipped the binary over a serial link to a second machine for testing. After conversion the entire game was a single 51K source file and assembly took under five seconds.

[JohnnyRockets]

Hi TMR,

 

Thanks very much for your reply!

 

Okay, it seems like my question falls under the category of, "yeah you can do that, but why would you want to go through the pain if you didn't have to?"... Using modern tools, just makes things easier and ultimately more enjoyable it seems.

 

Thanks for you explanation. It sounds like cross assembly is the better way to go. I do have my tools set up such that I can use a windows ASM program and test my programs in WinVice very easily.

 

I still do not have a real need to test my programs natively on a real C64, but that'll come (I do own one however). When the time comes to test natively, I am thinking of getting one of the micro SD devices like the uIEC-SD. I am not sure if this is the best option, but it at least looks promising...

 

 

Thanks, JR

[TMR]

Okay, it seems like my question falls under the category of, "yeah you can do that, but why would you want to go through the pain if you didn't have to?"... Using modern tools, just makes things easier and ultimately more enjoyable it seems.

 

There are people who enjoy programming natively and continue to do so, but they're working on real hardware rather than under emulation.

 

What i remember back in the day though, very few commercial concerns were coding on a stock machine after about 1985 and many had been cross assembling from day one using other 8-bits, minicomputers or even mainframes as the source machine. Andrew Braybrook's Mental Procreation documents the installation of some Opus PC clones for C64, Spectrum and Amstrad CPC cross development at Graftgold during the development of Morpheus. Us mere mortals read these diaries and found ways to do something similar, linking two C64s (or in my case a C128 and C64) with whatever junk we had about the place, using whatever protocol worked and cobbling modifications into assemblers with a monitor.

 

I still do not have a real need to test my programs natively on a real C64, but that'll come (I do own one however). When the time comes to test natively, I am thinking of getting one of the micro SD devices like the uIEC-SD. I am not sure if this is the best option, but it at least looks promising...

 

Native testing should always be done before release, i've fallen into that trap myself on a couple of occasions in the past and have nearly been caught by emulators not doing what the real machine would on many more occasions. The uIEC and SD2IEC hardware are okay as long as what you're testing is a single load, but don't offer anything for debugging if the code kicks the machine over so at the very least adding an Action Replay 5 or 6 (depending on territory) is a good idea.

 

Also, you're in USA-land where the men are men and C64s are NTSC, VICE defaults to PAL so if you go too overboard on processor use each frame your code will crash and burn on real hardware.

[JohnnyRockets]

Thanks TMR!

 

Yeah, we're pretty manly here in the US!

 

 

So getting an action Replay sounds good, but that is an older hardware cartridge, right? Have to snag it on eBay or something (?)

 

 

JR

[TMR]

Yeah, we're pretty manly here in the US!

 

Shame about the NTSC thing, though... =-)

 

So getting an action Replay sounds good, but that is an older hardware cartridge, right? Have to snag it on eBay or something (?)

 

i suspect the best bet is going to be eBay yes and if memory serves they're region sensitive so you specifically want an Action Replay 5 from somewhere in NTSC-land.

 

The Action Replay cartridge first appeared in the 1980s from Datel Electronics (who are still going and using the AR brand) and what it basically offers for programming and debugging are features like a DOS wedge that allows quick entry of disk commands like @N:DISKNAME,ID to format or @V to validate (which i believe is also useful for changing directories or mounting images with SD2IEC and variants, although an off command to disable the fastloader is possibly needed before using the wedge with that hardware - i don't have one to test it yet), a machine code monitor that has an almost non-existent memory footprint (it doesn't take any code space since it's on ROM and can look pretty much anywhere in memory including under the I/O space at $d000 onwards) and the freezer which can stop running or indeed crashing code if it hasn't fallen over completely dead in it's tracks and allow you to prod at it with the monitor to see what's happened before either handing control back or compacting and dumping the entire memory out to disk.

 

The Action Replay 6 (which was more ubiquitous in PAL-land, the difference is mostly a copyright disclaimer/notice required at that point by UK law so you aren't really missing anything by getting a version 5) was truly indispensable when i was coding on a real C64 during the late 1980s and the 1990s; the freeze monitor alone saved my backside on countless occasions and the modified version of Zeus 64 assembler i was working with had it's own monitor stripped out so i could use the Action Replay one and it's fastloader. These days i've got a 1541 Ultimate 2 and a Turbo Chameleon on my two C64s (which were on display at the Play expo over the weekend, the latter running dual screen between a VGA monitor and a video projector - piccies coming when i feel well enough to dump the camera) and both have a Retro Replay, the supercharged and debugged version done by Cyberpunx which i'd recommend going for if they weren't rarer than hen's teeth, mounted as a cartridge image as default.

[JohnnyRockets]

Thanks TMR,

 

Wow, as usual, you are speaking way over my head, but I'm trying to keep up!

 

 

Thanks, I think I'll play a bit with the AR cartridge within WinVice. I assume it will function similarly to the real thing (?)

 

 

JR

[TMR]

Wow, as usual, you are speaking way over my head, but I'm trying to keep up!

 

If in doubt, ask for clarifications - nobody'll mind.

 

Thanks, I think I'll play a bit with the AR cartridge within WinVice. I assume it will function similarly to the real thing (?)

 

Generally speaking yes, although the freeze is a bit wonky on occasions.

[JohnnyRockets]

All monitors have save and load options, although the syntax varies between them so it'll be down to rooting through the "manual" to find the specific variation for what you're using. Usually it'll be something like s "filename",8,6000,7000 which writes to device 8 and saves everything between $6000 and $6fff - some monitors will save $7000 as well, others won't so again it's a matter of reading the docs.

 

TMR, I guess what I don't get is back in the day on the original hardware, how would people create a game in ASM and save/distribute it? Would they write ASM code and call it from within a BASIC program? If so was the game written in a MLM and saved to disk and "called" somehow from a BASIC program. I mean I understand how to write a BASIC program and call and ASM program from it, but all of my tries at this have just been with small "example" programs from books, how did the "pros" or "serious home programmers" do this back in the day?

 

Thanks,

 

 

JR

[TMR]

TMR, I guess what I don't get is back in the day on the original hardware, how would people create a game in ASM and save/distribute it? Would they write ASM code and call it from within a BASIC program?

 

Generally speaking, coders could write something partly in machine code and pepper a BASIC listing with SYS calls (a few games like Pirates are built that way for example) but the most common way of doing it would be to write the entire program in 6502 and have a single line BASIC listing in memory that started it up.

 

If so was the game written in a MLM and saved to disk and "called" somehow from a BASIC program. I mean I understand how to write a BASIC program and call and ASM program from it, but all of my tries at this have just been with small "example" programs from books, how did the "pros" or "serious home programmers" do this back in the day?

 

Well, very few professional or serious homebrew programmers used a monitor to write C64 code[1] because it simply isn't efficient enough (both on programming time and computer resources) for a large project; there are a few games out there written in a monitor but the list i'm aware of only just gets into double figures.

 

A friend of mine who used Commodore's own assembler (a very clunky assemble-to-disk affair that could take twenty to thirty minutes for a single assembly) used to have all the data files and assembled object code stored separately on a floppy with a BASIC boot program that would look something like this:

 

10 A=A+1
20 IF A=1 THEN LOAD"SPRITES",8,1
30 IF A=2 THEN LOAD"CHARS",8,1
40 IF A=3 THEN LOAD"MUSIC",8,1
50 IF A=4 THEN LOAD"CODE",8,1
60 SYS 16384

 

Turbo Assembler users just pressed back arrow and 3 to assemble, then the assembler offered them the option of pressing S to start the code as long as there were no errors and my test cycle for Zeus 64 was about the same, so in both cases it was just a matter of grafting the BASIC SYS line onto the finished code.

 

[1] It's more common to see VIC 20 and Commodore 16 games written in monitors because there wasn't really enough RAM to put an assembler, source code and target code into memory at the same time if you were coding on the machine itself; the C16 came with a built-in monitor as well.

[JohnnyRockets]

Hi TMR,

 

Okay, I'm starting to understand this now.

 

I was thinking that was the way to do it, but needed verification!

 

Thanks.

 

 

JR