Jump to content

Photo

Why is the Vic 20 so hard to program for?


90 replies to this topic

#76 Arnuphis OFFLINE  

Arnuphis

    Moonsweeper

  • 348 posts
  • Loading...Please Wait
  • Location:Sacramento, California

Posted Tue Sep 4, 2018 11:00 PM

Depends how fast you want your program to run. Simple as that.



#77 TMR OFFLINE  

TMR

    River Patroller

  • 3,473 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Wed Sep 5, 2018 4:23 PM

was machine language even necessary for the plus 4 or PET? the graphics keys are right there and basic 3.5 eliminates most problems. even the 128 is an improvement (unless you are programming the graphics chip)


If you want to do something more serious than merely dabbling then yes, it's necessary to use assembly language for speed; the expanded versions of BASIC may add extra commands for graphics but they're still hampered by BASIC itself on that front. Try going through the list of games or indeed demos on those two platforms and find all of the stand out titles, then see how many of those were written in BASIC because it'll be a very small percentage.

#78 Ranger03 OFFLINE  

Ranger03

    Moonsweeper

  • Topic Starter
  • 463 posts

Posted Thu Sep 6, 2018 6:27 PM

I primarily use The c64 for assembly using the Final cart but that's because i can see the result graphics wise

the PET has no graphics and the Plus 4 has very little documentation



#79 Arnuphis OFFLINE  

Arnuphis

    Moonsweeper

  • 348 posts
  • Loading...Please Wait
  • Location:Sacramento, California

Posted Thu Sep 6, 2018 11:30 PM

I primarily use The c64 for assembly using the Final cart but that's because i can see the result graphics wise

the PET has no graphics and the Plus 4 has very little documentation

 

Quite the about face there. Especially in light of this earlier comment...

 

The c64 is harder for me to program for and the plus 4 and PET are my personal favorites due to the Latter's BASIC 3.5 and the Former's Green monitor which evokes Aliens levels of nostalgia, besides there's also zork.

 

 

 

I thought you couldn't get on with the 6502 and preferred the Z80?....

 

 

Fuse it is. Sucks that the Beeb isn't Z80, 6502 is harder for me to program

 

All of a sudden you are Mr. 64 Assembly. I'm beginning to think along the lines of other folks here in that you either just trolling or making this stuff up as you go along. You should listen to the advice given and stick to one thing at a time. You are not going to be taken seriously otherwise.



#80 carlsson ONLINE  

carlsson

    Metagalactic Mule

  • 7,873 posts
  • Location:Västerås, Sweden

Posted Fri Sep 7, 2018 1:31 AM

Assembly language works great on the PET. This one runs on a 40 column model. Source code included because I can.

 

Attached File  jont.zip   916bytes   0 downloads



#81 TMR OFFLINE  

TMR

    River Patroller

  • 3,473 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Fri Sep 7, 2018 1:51 AM

I primarily use The c64 for assembly using the Final cart but that's because i can see the result graphics wise


It's not the route I'd advise since the FC is just single pass assembly/disassembly so none of the useful features of a full assembler are there - using an actual assembler is far better for a beginner and, because it's an option now but wasn't when I was learning, I'd advise cross assembly - but, if that's actually the case, why are you bothering with BASIC? Anyone using assembly for even the shortest of times should already understand the advantages and wouldn't have needed to ask.
 

the PET has no graphics


That depends on the PET and, perhaps, if it's got an after-market modification; Orb's demo No PETs Allowed runs on a stock 4032 for example and (ab)uses the CRTC settings to produce graphics that are more than just the ROM characters.
 

and the Plus 4 has very little documentation


No, I've written a couple of games and demos for the 264 series so have read some of the documentation out there and what I've seen is pretty decent - less so ten or so years back when I started but it's improved greatly - in part because it's processor and graphics formats are inherited from the C64.

And, as Arnuphis points out, that's some contradictions you've got going on there...

#82 carlsson ONLINE  

carlsson

    Metagalactic Mule

  • 7,873 posts
  • Location:Västerås, Sweden

Posted Fri Sep 7, 2018 2:00 AM

Among the things in life I have trouble understanding, one of them are people who in the year 2018 are interested in serious assembly language programming, but think that cross assembling seems too cumbersome and instead stick with typing in instructions in a machine code monitor inside an emulator. Yeah, if you're stuck with the real hardware and not even Turbo Assembler etc I can understand writing small programs that way but it seems awfully backwards. That does not apply specifically to this thread, I've made the suggestion to set up a cross assembling environment from day 1 multiple times to various aspiring programmers. Sometimes it works, often it doesn't and people lose interest quickly when the machine code monitor turns out to not be as efficient to work in as they had hoped.



#83 TMR OFFLINE  

TMR

    River Patroller

  • 3,473 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Fri Sep 7, 2018 2:55 AM

Among the things in life I have trouble understanding, one of them are people who in the year 2018 are interested in serious assembly language programming, but think that cross assembling seems too cumbersome and instead stick with typing in instructions in a machine code monitor inside an emulator. Yeah, if you're stuck with the real hardware and not even Turbo Assembler etc I can understand writing small programs that way but it seems awfully backwards.


Oh, absolutely... I started out hand assembling - for the benefit of the wider audience, converting my source code into decimal numbers and then POKEing them into memory one at a time - and later working in a monitor on the VIC because there weren't any tape-based assemblers available to me at the time, but it really isn't the way I'd advise anyone to learn because that's where madness lies. Some people I've spoken to online who say they use a monitor seem bizarrely fixated on the idea of "doing things how people did in the 1980s" but, apart from a few very noteworthy exceptions - Crossbow and Stavros Fasoulas spring to mind right now - almost everybody used assemblers back then and, as you say, the bulk of that was Turbo Assembler.

Most of us dreamed about cross assembly after reading Andrew Braybrook's Morpheus diary in Zzap! or hearing about Matthew Smith using a TRS-80 to write Jet Set Willy though, with many trying to rig their own solutions using a second C64, an Amiga or whatever they could cobble together; I used Zeus 64 on the Breadbin from the mid 1980s to 2001 - so yes, source code with feckin' line numbers - and, whilst it started out as stock, that eventually mutated into a self-modified version with 2MHz assembly for a C128 in C64 mode and options to squirt the target code down a cable to the nearby Breadbin used for testing. It was a rather rudimentary and bodged cross assembler for sure, but it worked!

#84 carlsson ONLINE  

carlsson

    Metagalactic Mule

  • 7,873 posts
  • Location:Västerås, Sweden

Posted Fri Sep 7, 2018 3:05 AM

I believe someone like Tom Griner also worked in a machine code monitor but he was an early VIC-20 programmer. Perhaps he got access to HESmon which is one of the more competent monitor programs, almost like a poor man's assembler.

 

Doing things the way people did it before does have a bit of charm to it, whether it is about assembly language programming, carving your wooden figurines, growing your own vegetables or just about anything else, but usually modern methods are easier to work with. If you take the step to a full IDE, you can often combine languages too, like writing your BASIC program which is cross tokenized and linked with machine code routines you have assembled elsewhere in your project. Or a compiling language like C, I suppose.



#85 TMR OFFLINE  

TMR

    River Patroller

  • 3,473 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Fri Sep 7, 2018 9:24 AM

Doing things the way people did it before does have a bit of charm to it, whether it is about assembly language programming, carving your wooden figurines, growing your own vegetables or just about anything else


I agree that there's something of an olde worlde charm there and I can sort of see it myself... but there's nothing to stop someone learning on user friendly tools and then moving over to the oldschool techniques as long as the culture shock of going from a cross assembler with labels, includes and build times measured in seconds to Turbo Assembler or the Action Replay 6 monitor doesn't prove fatal. =-)

Personally I wouldn't these days though, my 8-bits are reasonably well looked after but I wouldn't trust them with the source code of a large project any more; I've lost work in the past due to failing disks and unreliable PSUs, something I wouldn't wish on my worst enemy.

#86 tschak909 OFFLINE  

tschak909

    River Patroller

  • 2,841 posts
  • Location:USA

Posted Fri Sep 7, 2018 9:48 AM

Yup, cross-development is _THE_ way to do it.

 

Even BITD, the setup with having a romulator connected to a bigger system could be _VERY_ fast if the machine was all to yourself, and you could just compile, swivel the chair and flip the switch.

 

And today, even moreso. There are _EXCELLENT_ cross compilers and assemblers which compile on modern hardware in tenths of a second...even my C projects compile in less than 10 seconds for LARGE ones _IF_ I forget to pass -j to make. :)

 

-Thom



#87 digdugnate OFFLINE  

digdugnate

    Stargunner

  • 1,907 posts

Posted Fri Sep 7, 2018 10:20 AM

i have not done a lot in Assembly on this side of the fence, but I know that with working in TI 99 Assembly and Basic programming, I preferred to write on the emulator first on my computer. 

 

It made it a TON easier to test/debug, then I could move to the 'real iron' platform.  Nothing's cooler than having your stuff work on the real thing!



#88 TMR OFFLINE  

TMR

    River Patroller

  • 3,473 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Fri Sep 7, 2018 10:24 AM

It made it a TON easier to test/debug, then I could move to the 'real iron' platform.  Nothing's cooler than having your stuff work on the real thing!


Indeed and thanks for reminding me of a point I forgot earlier... it doesn't have to happen often during development, but always test on real hardware before releasing because even the most mature emulators can have "quirks" in edge cases. Been there, got several t-shirts. =-)

#89 MoonTurtle OFFLINE  

MoonTurtle

    Space Invader

  • 16 posts

Posted Tue Sep 25, 2018 6:13 PM

Speaking of programming...

 

is the a tool similar to C64 Studio for the Vic 20? I was thinking of programming for the system, but I rather liked the layout of C64 Studio, it was rather easy to work with. I liked the sprite editor, and the ease of laying out code for your c64 game was pleasing, not just to me, but to many people, who often cite this program as the best program for developing your own C64 game.

 

Is there something like that for the Vic 20?

 

I will be creating a new topic on this forum called "Commodore Vic 20 Game Development Tools" so we could discuss the Vic-20 and how to properly program for the system.

 

See ya there! :)



#90 OldSchoolRetroGamer OFFLINE  

OldSchoolRetroGamer

    Quadrunner

  • 5,461 posts
  • aka MaximumRD !
  • Location:Kelowna, B.C. CANADA

Posted Tue Sep 25, 2018 6:45 PM

Attached File  spn_names.png   135.54KB   0 downloads



#91 TMR OFFLINE  

TMR

    River Patroller

  • 3,473 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Wed Sep 26, 2018 3:15 AM

is the a tool similar to C64 Studio for the Vic 20?


CBM .prg Studio is similar and does most of the Commodore 8-bits.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users