I subscribed because I would like to hear more about writing C for an Apple II. In particular, I wonder if Figlet could be ported to an Apple II. Wikipedia claims that there is an Apple II port, but that is not quite true from what I can see. I think CC65 would be the way to go, but I haven't yet figured out the starting point.
Very nice to have this :) BTW at 12:15 you say "... at block 10 and onwards ...". I think you're misunderstanding the CATALOG. When you see in a CATALOG, "B 010 TEST", the B means it's a binary file, and 10 means that the file is 10 sectors in size, where each sector is 256 bytes. 10 is not an index.
Interesting. I’m learning Apple II assembly. From what I’ve gathered, the output from all of the C compilers is less than optimal due to the number of registers and other restrictions imposed by the 6502 processor. What is your opinion?
It's definitely less than optimal. If you want to write a program that is designed to run as fast as possible, or if you need a certain degree of processing power to perform a certain task, there really is no better option than straight ASM. However, C is a good choice if you're fine with a minor performance hit, but you want something a little faster than BASIC. It is orders of magnitude faster than BASIC. It's also a great choice for rapid testing, or for dragging/dropping algorithms from other places onto the Apple II to see how they fare without too much overhead. One possible workflow is: write in C, and then re-write in assembly once you're sure the algorithm works.
There are some low- to mid-level options for Apple II or 6502 programming that are worth looking into such as the C-like compiler Millfork; Martin Haye's mini-assembler-on-steroids Super-Mon and his semi-interpreted language Short; and for a very different live development environment check out Jeremy Penner's Honeylisp which uses a compiled Lisp dialect called Fennel. There are KansasFest presentations from Haye and Penner you can find here on TH-cam.
@@xotmatrix this sounds right up my alley. I’m interested in domain languages and similar tools that would work well in vintage computer programming environments. One of the reasons I’m learning 6502 assembly.
I prefer to either build directly into a bootable disk image (for tiny programs), or (for somewhat larger programs) use a node.js program to construct a bootable disk image witn a binary. Your video has inspired me to revisit my projects for this, and I think I should be able to make a linker file which will, with the aid of a blob stuck at the beginning containing a sector-shuffling boot loader, handle progrms of up to 44K loaded at address 0x1000, in about 3 seconds. Does that seem like something you'd be interested in?
@@cineminttechtips I've got something that's working rather nicely in the emulator. Still have to test it on a real machine, though. If one uses the linker to produce a binary that's 143,360 bytes long and uses it as a disk image, the system will read the first 256 bytes to RAM at $800. I have a boot loader that fits into 256 bytes and will, in a single spin, read the remainder of the first 4K into RAM at $B100 (using $A100-$AFFF as scratchpad) and execute it. What I would envision would be that most programs would start with a 4094-byte blob that should be put at the start of a binary, followed by a pair of bytes indicating how many sectors worth of data should be initially loaded (by a loader/mini-DOS which would occupy and reserve storage in the $Bxxx range), along with the destination page address. The specified number of 256-bytes following that in the DSK file would be loaded at the specified address, and code in the BIN file could call a routine with an entry point in the $BFFx range to load any desired chunks from the DSK file to any desired addresses in memory. Would you like me to e-mail you with what I have so far?
@@flatfingertuning727 Absolutely! My email is at ethan.hill1999@outlook.com . I’d be happy to explain anything you’d want me to and do a demo on real hardware.
@@flatfingertuning727 That I did! I'm doing the due diligence of giving your work the time it deserves - I'll get back in touch when I'm ready. Thank you for sending! :)
I use Virtual][ on macOS and use a folder as a disk to speed up build cycles. However, whenever I run the program I created with CC65 I end up on the monitor. What I'm missing? Any idea?
Like this comment to dislike the video
1:58 ISNA version of C!
In all seriousness though, great video on building a C program for the Apple2
I subscribed because I would like to hear more about writing C for an Apple II. In particular, I wonder if Figlet could be ported to an Apple II. Wikipedia claims that there is an Apple II port, but that is not quite true from what I can see. I think CC65 would be the way to go, but I haven't yet figured out the starting point.
I might dabble in this a bit. If I make any progress I'll put together a video on it.
Very nice to have this :) BTW at 12:15 you say "... at block 10 and onwards ...". I think you're misunderstanding the CATALOG. When you see in a CATALOG, "B 010 TEST", the B means it's a binary file, and 10 means that the file is 10 sectors in size, where each sector is 256 bytes. 10 is not an index.
Good catch 👍
Interesting. I’m learning Apple II assembly. From what I’ve gathered, the output from all of the C compilers is less than optimal due to the number of registers and other restrictions imposed by the 6502 processor. What is your opinion?
It's definitely less than optimal. If you want to write a program that is designed to run as fast as possible, or if you need a certain degree of processing power to perform a certain task, there really is no better option than straight ASM.
However, C is a good choice if you're fine with a minor performance hit, but you want something a little faster than BASIC. It is orders of magnitude faster than BASIC. It's also a great choice for rapid testing, or for dragging/dropping algorithms from other places onto the Apple II to see how they fare without too much overhead.
One possible workflow is: write in C, and then re-write in assembly once you're sure the algorithm works.
There are some low- to mid-level options for Apple II or 6502 programming that are worth looking into such as the C-like compiler Millfork; Martin Haye's mini-assembler-on-steroids Super-Mon and his semi-interpreted language Short; and for a very different live development environment check out Jeremy Penner's Honeylisp which uses a compiled Lisp dialect called Fennel. There are KansasFest presentations from Haye and Penner you can find here on TH-cam.
@@xotmatrix this sounds right up my alley. I’m interested in domain languages and similar tools that would work well in vintage computer programming environments. One of the reasons I’m learning 6502 assembly.
I prefer to either build directly into a bootable disk image (for tiny programs), or (for somewhat larger programs) use a node.js program to construct a bootable disk image witn a binary. Your video has inspired me to revisit my projects for this, and I think I should be able to make a linker file which will, with the aid of a blob stuck at the beginning containing a sector-shuffling boot loader, handle progrms of up to 44K loaded at address 0x1000, in about 3 seconds. Does that seem like something you'd be interested in?
Oh HECK yeah - you make that, I'll do a video on it
@@cineminttechtips I've got something that's working rather nicely in the emulator. Still have to test it on a real machine, though. If one uses the linker to produce a binary that's 143,360 bytes long and uses it as a disk image, the system will read the first 256 bytes to RAM at $800. I have a boot loader that fits into 256 bytes and will, in a single spin, read the remainder of the first 4K into RAM at $B100 (using $A100-$AFFF as scratchpad) and execute it.
What I would envision would be that most programs would start with a 4094-byte blob that should be put at the start of a binary, followed by a pair of bytes indicating how many sectors worth of data should be initially loaded (by a loader/mini-DOS which would occupy and reserve storage in the $Bxxx range), along with the destination page address. The specified number of 256-bytes following that in the DSK file would be loaded at the specified address, and code in the BIN file could call a routine with an entry point in the $BFFx range to load any desired chunks from the DSK file to any desired addresses in memory.
Would you like me to e-mail you with what I have so far?
@@flatfingertuning727 Absolutely! My email is at ethan.hill1999@outlook.com . I’d be happy to explain anything you’d want me to and do a demo on real hardware.
@@cineminttechtips I sent you a couple emails yesterday (the first went out without the intended enclosure). Did you get them?
@@flatfingertuning727 That I did! I'm doing the due diligence of giving your work the time it deserves - I'll get back in touch when I'm ready. Thank you for sending! :)
nice
I use Virtual][ on macOS and use a folder as a disk to speed up build cycles. However, whenever I run the program I created with CC65 I end up on the monitor. What I'm missing? Any idea?