Jump to content

Kaj de Vos

New Members
  • Content Count

    76
  • Joined

  • Last visited

Community Reputation

56 Excellent

1 Follower

About Kaj de Vos

  • Rank
    Star Raider

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hmm, I want a high-level computer language like they were meant for 32-bit machines and up, but I want it on everything, from an Atari 2600 to a super computer. 😊
  2. Rainbow assembly The language has an integrated assembler, so we could also write Rainbow like this: https://language.meta.frl/examples/platforms/Atari/2600/rainbow-assembly.rom https://language.meta.frl/examples/platforms/Atari/2600/rainbow-assembly.list https://language.meta.frl/examples/platforms/Atari/2600/rainbow-assembly.labels https://language.meta.frl/examples/platforms/Atari/2600/rainbow-assembly.map unsafe!!! [ constant reference volatile byte! [ ; TIA VSYNC= ~0000 VBLANK WSYNC COLUBK= ~0009 PF0= ~000D PF1 PF2 GRP0= ~001B GRP1 ENAM0 ENAM1 ENABL ] vertical-sync-bit= %0000'0010 LDA 0 STA PF0 ; Turn playfield off; we only use the background STA PF1 STA PF2 STA GRP0 ; Players off STA GRP1 STA ENAM0 ; Missiles off STA ENAM1 STA ENABL ; Ball off STA VBLANK ; Set beam to on to use the entire vertical-blank overscan area byte! jiffies forever: STA WSYNC ; Wait for end of scanline LDA vertical-sync-bit ; Start vertical sync STA VSYNC ; Vertical sync pulse. ; This lasts 3 scanlines, where some small work can be done to set up the next screen. LDX jiffies ; Begin colour gradient, shifted by jiffy counter ; Wait three scanlines STA WSYNC STA WSYNC STA WSYNC ; End vertical sync, continue vertical blank LDA 0 STA VSYNC ; Vertical blank area, followed by the visible display area, ; followed by another vertical-blank overscan area. ; PAL and SECAM officially have 45 + 228 + 36 scanlines here, NTSC has 37 + 192 + 30. ; We generate 283 scanlines (plus the 3 for vertical sync), for a display frequency of 55Hz, ; inbetween PAL/SECAM and NTSC. It will work on all, if you have a tolerant television set. TAY ; A is still 0 loop-256: INX ; Increment colour for every scanline STA WSYNC STX COLUBK ; Colour background DEY BNE loop-256 LDY 26 loop-26: INX STA WSYNC STX COLUBK DEY BNE loop-26 INC jiffies ; Count display frames JMP forever ] More efficient code can be written this way, but it's clearly more elaborate than the high-level language.
  3. Over the rainbow I ported Rainbow to Atari 2600: It shows that the language is small enough to run on a machine with 128 bytes of RAM, and fast enough to "race the beam": to draw the television display scanline by scanline in real-time, 50 to 60 times per second, on an 8-bit CPU running slightly over 1 MHz.
  4. I am developing a new language that I have been introducing here: After the Atari 8-bit, I am now targeting it at the 2600. I just posted the first demo here: Here is the source code: unsafe!!! constant reference volatile byte! [ ; TIA VSYNC= ~0000 VBLANK WSYNC COLUBK= ~0009 PF0= ~000D PF1 PF2 GRP0= ~001B GRP1 ENAM0 ENAM1 ENABL ] vertical-sync-bit= %0000'0010 VBLANK: ; Set beam to on to use the entire vertical-blank overscan area ENABL: ; Ball off ENAM1: ENAM0: ; Missiles off GRP1: GRP0: ; Players off PF2: PF1: PF0: 0 ; Playfield off; we only use the background byte! [jiffies colour] forever [ VSYNC: WSYNC: vertical-sync-bit ; Wait for end of scanline, then start vertical sync ; Vertical sync pulse. ; This lasts 3 scanlines, where some small work can be done to set up the next screen. colour: jiffies ; Begin colour gradient, shifted by jiffy counter ; Wait three scanlines, then end vertical sync, continue vertical blank VSYNC: WSYNC: WSYNC: WSYNC: 0 ; Vertical blank area, followed by the visible display area, ; followed by another vertical-blank overscan area. ; PAL and SECAM officially have 45 + 228 + 36 scanlines here, NTSC has 37 + 192 + 30. ; We generate 283 scanlines (plus the 3 for vertical sync), for a display frequency of 55Hz, ; inbetween PAL/SECAM and NTSC. It will work on all, if you have a tolerant television set. ; The first scanline is used for the setup overhead of the LOOP, ; so it gets the last colour wrapped over from the last scanline of the previous screen. ; Being the first line of the vertical blank overscan area, it is normally not visible. loop 282 [COLUBK: WSYNC: overflow increment colour] ; Increment background colour for every scanline overflow increment jiffies ] Here are some artifacts of the compilation. The assembler listing: https://language.meta.frl/examples/platforms/Atari/2600/rainbow.list A VICE labels file, for debuggers: https://language.meta.frl/examples/platforms/Atari/2600/rainbow.labels The memory sections map: https://language.meta.frl/examples/platforms/Atari/2600/rainbow.map It's my second 2600 program; please be gentle. 😁 The language will be cross-platform on as many systems as possible. 2600 programs are developed by cross-compiling. In many cases, it is also needed to pre-compute data for a 2600 program. You will be able to write such tools in the same language, on your PC or Mac or other favourite system.
  5. Hello, 2600 fans! I am developing a new programming language, that I am now targeting at the 2600. The first target was the Atari 400/800/XL/XE, my old machine. Here is a rainbow demo that I ported from the Atari 8-bit version: https://language.meta.frl/examples/platforms/Atari/2600/rainbow.rom It shows that the new language is small and fast enough to race the beam. It generates 286 scanlines, achieving a display frequency of 55Hz. This is inbetween PAL/SECAM and NTSC, so it will work on all of them, if you have a tolerant television set. The original is here:
  6. Triple rainbow Here is an improved version of the Rainbow demo in pure assembly: https://language.meta.frl/examples/platforms/Atari/8-bit/RAINBOWA.XEX https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-assembly.list https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-assembly.labels https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-assembly.map unsafe!!! [ constant reference volatile byte! [ ; OS RTCLOK3= ~14 SDMCTL= ~022F ; ANTIC COLBK= ~D01A WSYNC= ~D40A VCOUNT ] LDA 0 STA SDMCTL ; Switch off display DMA forever: LDA VCOUNT ASL-A CLC ADC RTCLOK3 STA WSYNC STA COLBK CLC BCC forever ] It is actually a byte larger than the versions in the high-level language and mixed assembly, because CC65 doesn't know that the assembly keeps looping, so it doesn't optimise away the RTS at the end of the generated main function.
  7. Time will tell. From my point of view, spending my time on the CC65 code generator is a better guarantee to remain niche than making a programming language for all platforms. It's not for nothing that I am making a new language. I don't want to program in C anymore, apart from the C version of my language runtime, and almost haven't done so in a quarter century. Besides some mandatory exercises, I only ever wrote three C programs, an Atari emulator and two REBOL 3 plug-ins. If I remain the only one using my language, it will still be a success. It is solving my problems and gives me a great competitive advantage. On the other hand, if I make it popular, perhaps more people will become interested to work on the CC65 code generator behind it.
  8. I'm interleaving them. I have some projects in REBOL, some projects in Red, some old projects in C and Ruby, that I all want to port. I write in a simple style inspired by Atari and REBOL, so I always saw the similarities in these languages. Now and then I check what I need to implement to start a port. I'm starting very small and incrementally with command-line and Atari examples. The largest program until now is the CGI program that drives the project web server. Each program and each extension leads to the next round of language implementation. The Atari code is generated by CC65, so miracles should not be expected, but I did make a lot of effort to force it to generate better code. Essays written by people here were very helpful. When I implement an example, I inspect the code and try to get it as close as possible to what I would write in assembly by hand. CC65 doesn't do very well on complex constructs, that is for later to fix in a native Atari backend. But there are also a few constructs that can be avoided when programming, similar to the advice for writing C in CC65.
  9. Double rainbow Here is an improved version of the rainbow demo in mixed high-level language and assembly: https://language.meta.frl/examples/platforms/Atari/8-bit/RAINBOWM.XEX https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-mixed-assembly.list https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-mixed-assembly.labels https://language.meta.frl/examples/platforms/Atari/8-bit/rainbow-mixed-assembly.map unsafe!!! [ constant reference volatile byte! [ ; OS RTCLOK3= ~14 SDMCTL= ~022F ; ANTIC COLBK= ~D01A WSYNC= ~D40A VCOUNT ] SDMCTL: 0 ; Switch off display DMA forever [ LDA VCOUNT ASL-A CLC ADC RTCLOK3 STA WSYNC STA COLBK ] ] It generates the exact same code as the demo in the high-level language, that goes through generated C. So in this case, dropping down to hand-writing assembly yields no advantage.
  10. In a way, that's true. It feels like cheating to generate C. On the other hand, C and the assembly syntax in CC65 have some nasty limitations that make it harder in some ways to generate C than to generate machine code. This is why most new languages these days generate LLVM intermediate code instead of C. Also, the real work begins in the preparation for generating machine code. My compiler is structured in a broad way like LLVM, with an intermediate code that is designed to absorb higher level REBOL-style code and to generate both mid-level code such as C and WebAssembly text format, and low-level code such as WebAssembly binary format, pseudo machine code and native machine code. I started by generating WebAssembly text format, because it is a modern, limited specification designed for this job. I thought I would just keep using one of the WebAssembly text to binary format compilers, because I didn't want to do all the work of many binary backends, which is greatly delaying the development of the Red language. But the WebAssembly compilers are already so big for this limited task, often written in Rust, that one day, I decided to do a binary WebAssembly backend, as a preparation for generating machine code. In the end, I was really glad that I did, because it wasn't at all as much work as it seems, and it helped shape the language further. Much of my design and planning is about doing this project quicker than other projects, or at least less glacial. It's also about bootstrapping my own empowerment, and it happens quite regularly that what I have already done enables me to take on a sub-project that I previously thought would be too hard or too much work.
  11. True, CC65 is the layer still inbetween, and that bugs me. Hence my talking about eventually cutting that out, too, in favour of a native Atari backend. But for the moment being, CC65 is instrumental in shaping the language like a glove to match C features and interface with C libraries.
  12. Yes, LLVM has that aura. CLang less so, I always thought it was way too big. But they are more modular, they open their intermediate code format and provide API's, which was very important to my language plans. For Syllable, we saw what a mess the GNU software was. LLVM was said to be cleaner. I can't really say. I didn't like that it is C++, but that did match Syllable well. I saw that LTO is slow. But it's such a fundamental feature, long advertised for LLVM, that I would have expected it to be included in -O3. In general, cleaner software tends to come from smaller projects. Opening up a project to a community makes it messy, but it broadens the acceptance. There is no ideal solution, so I will have to do some cord dancing there.
  13. For Atari, I have the integrated assembler. It allows the same philosophy as PL65: write the critical parts in assembly, but save time by writing the non-critical skeleton in a higher-level language. For larger systems, I completely agree that all the layers get in the way. REBOL's battle yell was always the fight against complexity. REBOL is far simpler than other modern languages, and my language is far simpler than REBOL. Cutting out layers improves performance a lot. The abstraction is still there, but most of the intermediate layers are not needed. REBOL languages are actually very suitable for writing database programs. It's customary for REBOL programmers to avoid complex databases, because they are seldomly needed with REBOL. Indeed, REBOL is designed for implementing domain-specific languages. It's extremely useful for implementing my language. No Lex and YACC and such stuff, it's a very different model. Funding was always a problem with all previous projects. I have some ideas how to fix that. It's one of the reasons why I'm very particular about how to do this project.
  14. GCC was already a monument twenty years ago when we started Syllable. I always assumed it did most things right. In any case, it was always unthinkable to me that linkers could not distinguish between multiple functions in one source file. I saw huge library source files scrolling by day and night for many years. We knew some things could be improved because LLVM said so. I also knew from their status reports that their optimising runtime loader was going slowly, but I always thought the compile-time linker was long done. Really, this is all twenty years ago. I always had a lingering wish to switch to CLang, but the GCC situation was already very complex. Syllable was an enormously much lighter system than other operating systems, but compared to REBOL, it was a juggernaut. You could never rely on subtle things such as incremental builds being reliable, so I always built the entire operating system start to finish, only segmented in some course-grained software collections.
×
×
  • Create New...