[HN Gopher] How I learned to program a Commodore 64 in BASIC and...
___________________________________________________________________
How I learned to program a Commodore 64 in BASIC and compiled C
(2020) [video]
Author : AlexeyBrin
Score : 47 points
Date : 2023-02-25 15:11 UTC (1 days ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| TMWNN wrote:
| Relevant: The Applesoft Compiler (TASC), an Apple II C compiler
| written in BASIC <https://news.ycombinator.com/item?id=31138214>
| Zeetah wrote:
| Action! for the Atari 8 bit series was very well suited to the
| 6502.
|
| https://en.m.wikipedia.org/wiki/Action!_(programming_languag...
| bennysonething wrote:
| https://www.retrogamedev.com/
|
| This guy's book on c64 game Dev is good. I bought it, but I never
| gave it the time required.
|
| I think he is/was going to do a nes one too.
| hnthrowaway0315 wrote:
| I hope there is one for more advanced ones such as PS (which
| already have great doc) and GBA (again good doc already) and
| such.
|
| Sadly computing has advanced so much that making games on
| console is far from the older days when programmers need to be
| smart to think out of box to do stuffs. I guess maybe Switch is
| closer?
| tyingq wrote:
| Made me recall this article on why the 6502 isn't great as a C
| target, including a follow up with some pointers on avoiding some
| issues with it.
|
| https://www.xtof.info/coding-c-8-bit-6502-cpu.html
| lifepillar wrote:
| Yeah, it's better to use a "high-level" language designed for
| the architecture, such as this:
| https://github.com/dschmenk/PLASMA
| ajross wrote:
| FWIW: really the best example of that kind of thought was
| OSS's "Action!" language for the Atari computers. Unlike all
| the modern ideas in this space, this was actually a
| contemporary product (released in 1983). It's a little like
| K&R C in terms of semantics, with a bunch of concessions[1]
| to the limitations of the device.
|
| Alas it came at a time in history where it couldn't make much
| impact. The Atari platform was being eclipsed by Commodore at
| the time, and the market for Serious Tool Development in the
| desktop world was swinging hard toward IBM (Turbo Pascal for
| MSDOS was arriving right about the same time).
|
| [1] Like a more pascal-ish syntax. Atari didn't have curly
| braces on its keyboard! Also IIRC "POINTER" types were
| limited to being statically linked into the zero page, as
| that matched the operation of the hardware without requiring
| the runtime to move stuff around for you every time you
| wanted in do a load.
| zozbot234 wrote:
| > Atari didn't have curly braces on its keyboard!
|
| Isn't that why C also allows the <% and %> digraphs as
| alternatives?
| ajross wrote:
| Not the Atari itself, which never had a C compiler. But
| systems like that, yeah. Lots of 70's systems were
| designed for non-ASCII or ASCII-subset[1] character sets,
| whereas Unix had made very comfortable use of every funny
| symbol it could find.
|
| [1] e.g. the original Apple II character ROM had only the
| 64 characters from 0x20 to 0x5f (no lower case, even)
| squished into 6 bits of addressing. The keyboard
| reflected that limitation, as did those from Atari and
| Commodore. This wasn't rectified by Apple itself until
| the IIe, though there were 80 column cards on the market
| from 1980 on that implemented the full
| [deleted]
| zozbot234 wrote:
| CC65 is just not a very good compiler by modern standards.
| There's an experimental 6502 backend for LLVM that outputs
| fairly good code. (A Z80 backend also exists, AIUI.)
| AlexeyBrin wrote:
| Do you know if the 6502 LLVM backend has floating point
| support ? A big problem with CC65 is the lack of floating
| point support.
|
| EDIT: The answer is no:
|
| https://github.com/llvm-mos/llvm-mos-sdk#notably-missing-
| fea...
| royjacobs wrote:
| What kind of stuff do you want to do on a 6502 that
| requires emulated floating point support?
| AlexeyBrin wrote:
| It is nice to have, most BASIC versions that run on 6502
| micros have floating point support.
| zozbot234 wrote:
| The "floating point" support that's in 6502 BASIC ROMs is
| not real IEEE 754 floating point though, see
| https://en.wikipedia.org/wiki/Microsoft_Binary_Format So
| it _shouldn 't_ be used to replace that, though of course
| one can use it for other purposes with some care. (It
| goes without saying that this is not _hardware_ floating
| point, so the only potential gain from piggybacking on
| these ROM routines will be some saving in code size.)
| diydsp wrote:
| I wouldnt mind generating lookup tables at run time
| rather than my present system of exporting them via
| python etc... the algs could be more dynamic!
| galangalalgol wrote:
| So maybe someday we could do rust for the c64?
| ipaddr wrote:
| The people old enough to want to program on the c64 are not
| the same group of younger hipster who want to rustify the
| world. It would take someone to bridge these groups.
| zozbot234 wrote:
| Yup, it's fun to think that the rust_embedded ecosystem
| could be repurposed with comparable ease to support bare-
| metal retro programming. Similar to how Rust itself
| bridges the "low-level C/C++" and "hipster high level
| language" worlds.
| 0xcde4c3db wrote:
| There's a great talk [1] in which C++17 features are used to
| build an efficient Pong clone on C64. As I recall, the author
| wound up writing an (obviously limited) x86-to-6502 translator
| to get around the lack of 6502 support.
|
| [1] https://www.youtube.com/watch?v=zBkNBP00wJE
| AlexeyBrin wrote:
| Last year, the author tried a slightly different approach:
| use GCC to compile for AVR 8 bits, than translate the AVR
| assembly to 6502:
|
| https://www.youtube.com/watch?v=EIKAqcLxtT0
___________________________________________________________________
(page generated 2023-02-26 23:02 UTC)