6 ms·

Last time I checked, the source code can't even fit on the calculator's Flash chip.

kragen 7y ago
Really? If not, it's not that far. I mean KnightOS/kernel/src is less than half a meg, and it gzips to 79K. corelib/src gzips to 10K, castle/*.asm to 6K, and all the core .asm files I could find to 107K. (I'm not sure I have the whole source because it's not in a single repo, so I may be missing something, and I've left out extra/, but still this is pretty far from four megs.)
- ddevault 7y ago
  4M is the best case, and that calculator is probably my least favorite because the screen is awful and the calculator can't drive it efficiently. The best case for a good calculator is 2M, but the most popular is just 512K. Keep in mind that you have to keep at least some of this file in RAM, which is 32K minus the size of your assembler itself. I was considering the size of the whole toolchain, though. Perhaps if a different toolchain were made from scratch for this purpose... it might be possible.
  - kragen 7y ago
    Looks like the assembler has free-form syntax, simple text-replacement macros, assembly-time infix integer arithmetic, decimal, binary, hex, labels (including backpatching of arithmetic results, naturally), ifdefs, and some of the Z80 extensions to the 8080 instruction set? No stacks, recursive macros, conditionals in macros, typechecking, variadic macros, or user-defined opcodes? Roughly speaking it looks similar in power to the assemblers we used to use under CP/M, unless I'm missing something.
    - ddevault 7y ago
      Yeah, but the CP/M had floppy disks and a more managable address space :) give it a shot, it could work! Aside: at one point I was thinking about trying to port CP/M to these calcs...
      - kragen 7y ago
        Floppy disks are terrible. In NOR you can clear a single bit, and how long does that take? The least you can write to a floppy is a whole sector, normally 512 bytes, and the seek time is close to a million microseconds, although the actual sector write time is... well, maybe less than a hundred thousand microseconds. And they make a racket when you do it, too. And write endurance? Floppy disks have write endurance of about 1000 cycles. Their only benefit is that you can take one out and put a different one in. But that means the software can't use a write-back cache and can't start writing to the disk except in response to an explicit user action that the user expects to initiate a write; otherwise you run the risk that the disk drive will be opened in the middle of the write. Anyway, there were assemblers that you could fit on a single-sided, single-density, soft-sectored 5¼" disk along with your source code, object file, and "operating system", all in 90K. But things became a lot more practical if you could move up to a dual-drive, double-density system, so you could access two 180K disks at a time. If there was some way to run a reasonable subset of CP/M programs on them, even if it required some hacking of the programs, that would be a significant benefit. I need to think about the problem more.
        zozbot234 7y ago
        > But that means the software can't use a write-back cache and can't start writing to the disk except in response to an explicit user action that the user expects to initiate a write; otherwise you run the risk that the disk drive will be opened in the middle of the write. You can just require the user to `umount` the disk before physically taking it out. And if a disk does get taken out before the read/write even starts, the OS can detect this and show a message `You MUST reinsert media $LABEL into drive: Abort/Retry/Ignore?`
        kragen 7y ago
        I did use an operating system that required you to dismount floppies before taking them out (HDOS) but no popular OS or monitor program had such a requirement. HDOS was targeted at hobbyists and may have had some design features strongly selected against by the market.

Really? If not, it's not that far. I mean KnightOS/kernel/src is less than half a meg, and it gzips to 79K. corelib/src gzips to 10K, castle/*.asm to 6K, and all the core .asm files I could find to 107K. (I'm not sure I have the whole source because it's not in a single repo, so I may be missing something, and I've left out extra/, but still this is pretty far from four megs.)

ddevault 7y ago
4M is the best case, and that calculator is probably my least favorite because the screen is awful and the calculator can't drive it efficiently. The best case for a good calculator is 2M, but the most popular is just 512K. Keep in mind that you have to keep at least some of this file in RAM, which is 32K minus the size of your assembler itself. I was considering the size of the whole toolchain, though. Perhaps if a different toolchain were made from scratch for this purpose... it might be possible.
- kragen 7y ago
  Looks like the assembler has free-form syntax, simple text-replacement macros, assembly-time infix integer arithmetic, decimal, binary, hex, labels (including backpatching of arithmetic results, naturally), ifdefs, and some of the Z80 extensions to the 8080 instruction set? No stacks, recursive macros, conditionals in macros, typechecking, variadic macros, or user-defined opcodes? Roughly speaking it looks similar in power to the assemblers we used to use under CP/M, unless I'm missing something.
  - ddevault 7y ago
    Yeah, but the CP/M had floppy disks and a more managable address space :) give it a shot, it could work! Aside: at one point I was thinking about trying to port CP/M to these calcs...
    - kragen 7y ago
      Floppy disks are terrible. In NOR you can clear a single bit, and how long does that take? The least you can write to a floppy is a whole sector, normally 512 bytes, and the seek time is close to a million microseconds, although the actual sector write time is... well, maybe less than a hundred thousand microseconds. And they make a racket when you do it, too. And write endurance? Floppy disks have write endurance of about 1000 cycles. Their only benefit is that you can take one out and put a different one in. But that means the software can't use a write-back cache and can't start writing to the disk except in response to an explicit user action that the user expects to initiate a write; otherwise you run the risk that the disk drive will be opened in the middle of the write. Anyway, there were assemblers that you could fit on a single-sided, single-density, soft-sectored 5¼" disk along with your source code, object file, and "operating system", all in 90K. But things became a lot more practical if you could move up to a dual-drive, double-density system, so you could access two 180K disks at a time. If there was some way to run a reasonable subset of CP/M programs on them, even if it required some hacking of the programs, that would be a significant benefit. I need to think about the problem more.
      - zozbot234 7y ago
        > But that means the software can't use a write-back cache and can't start writing to the disk except in response to an explicit user action that the user expects to initiate a write; otherwise you run the risk that the disk drive will be opened in the middle of the write. You can just require the user to `umount` the disk before physically taking it out. And if a disk does get taken out before the read/write even starts, the OS can detect this and show a message `You MUST reinsert media $LABEL into drive: Abort/Retry/Ignore?`
        kragen 7y ago
        I did use an operating system that required you to dismount floppies before taking them out (HDOS) but no popular OS or monitor program had such a requirement. HDOS was targeted at hobbyists and may have had some design features strongly selected against by the market.