4 ms·

You have the advantage, in this case, of knowing what the end result is. I can re-write any of my own existing applications in a fraction of the time it took t

You have the advantage, in this case, of knowing what the end result is. I can re-write any of my own existing applications in a fraction of the time it took to develop them initially. But I agree that it all looks trivial. I'm developing an OS for a custom 8bit system and it's pretty slow going even though it's trivial. Of course, if I was cloning an existing OS it would go a lot faster but obsessing over the fine details is part of the fun.

deleted 5y ago
[deleted]
WalterBright 5y ago
Simply look at the size of the files. There just isn't much code there. You're quite right about obsessing over the details. But the idea is to work out the details on a more powerful machine in a high level language. Only convert the final configuration in the target assembler. For example, back in the 1970s (many years before DOS) I developed a handheld LED game for Mattel, it was Hockey. Handheld LED games were cutting edge at the time. The prototype was developed to run on a 6502 8 bit microprocessor. The dev tools for the 6502 were developed in a high level language and ran on a PDP-11, the resulting binaries were downloaded to an EPROM programmer, blown into an EPROM, then put on the 6502 for testing. Once everything worked to Mattel's satisfaction, the code and the prototype was given to Mattel. Mattel took this, and gave it to their engineers to implement on a 4 bit microprocessor, to behave exactly the same way. So this was 3 levels of development: PDP-11 => 6502 => 4 bit microprocessor. Trying to prototype on a 4 bit machine would have been a horribly costly experience. Remember that the DOS assembler at the time was terrible. Having a competent cross assembler on a mature machine like the -11 was the way to go. (I also used a 6502 debugger that actually ran on the -11, again making life a lot easier to develop the code for the 6502 where only very primitive bug-ridden software was available.)
- WalterBright 5y ago
  By the way, once DOS extenders became available, I ceased all native development under DOS. The reason was simple - the DOS extenders would give a seg fault on memory errors rather than scrambling the operating system. My dev process hence became much faster. The real mode DOS port was always the last step. Later on, I switched to 386 DOS extenders, then OS/2, then WinNT for development, as always relegating the real mode DOS port to dead last.
- wvenable 5y ago
  Using PDP-11 to build 6502 makes a lot of sense but using that 6502 to prototype for a even simpler processer is very clever. I'm just getting into electronics as something to do over COVID; I feel I'm re-visiting a bit of that era. The 8-bit computer I'm working on 6502-based. One of the first things I did after "Hello World" on the hardware was write an emulator/debugger for the whole system in C#. I also get to use a pretty nice macro assembler compared to what you would have had back in the day. You may have encouraged me to go back to a project I've put on hold: I started writing a high-level language that compiles to 6502 assembly. I could use C but it's not very 8-bit friendly and I want to go higher level than that but still keep the 8-bit-ness in mind. I've created a lot of macros but that only gets you so far.
  - WalterBright 5y ago
    If I had to do a lot of 6502 work today, I'd develop a custom language for it. Much like C is a custom language for the PDP-11 instruction set. C doesn't map very well onto the 6502, but customizing it would. Good luck on your 6502 endeavor!
    - mutagen 5y ago
      A custom language for the 6502 reminds me of the Action! language for the Atari computers. Wikipedia describes it as an ALGOL like language that included an editor, compiler, monitor, and runtime on a bank switching 16k cartridge. It was open sourced in 2015.
    - rahen 5y ago
      Have a look at PLASMA: https://github.com/dschmenk/PLASMA https://github.com/dschmenk/PLASMA

deleted 5y ago

[deleted]

WalterBright 5y ago

Simply look at the size of the files. There just isn't much code there. You're quite right about obsessing over the details. But the idea is to work out the details on a more powerful machine in a high level language. Only convert the final configuration in the target assembler. For example, back in the 1970s (many years before DOS) I developed a handheld LED game for Mattel, it was Hockey. Handheld LED games were cutting edge at the time. The prototype was developed to run on a 6502 8 bit microprocessor. The dev tools for the 6502 were developed in a high level language and ran on a PDP-11, the resulting binaries were downloaded to an EPROM programmer, blown into an EPROM, then put on the 6502 for testing. Once everything worked to Mattel's satisfaction, the code and the prototype was given to Mattel. Mattel took this, and gave it to their engineers to implement on a 4 bit microprocessor, to behave exactly the same way. So this was 3 levels of development: PDP-11 => 6502 => 4 bit microprocessor. Trying to prototype on a 4 bit machine would have been a horribly costly experience. Remember that the DOS assembler at the time was terrible. Having a competent cross assembler on a mature machine like the -11 was the way to go. (I also used a 6502 debugger that actually ran on the -11, again making life a lot easier to develop the code for the 6502 where only very primitive bug-ridden software was available.)

WalterBright 5y ago
By the way, once DOS extenders became available, I ceased all native development under DOS. The reason was simple - the DOS extenders would give a seg fault on memory errors rather than scrambling the operating system. My dev process hence became much faster. The real mode DOS port was always the last step. Later on, I switched to 386 DOS extenders, then OS/2, then WinNT for development, as always relegating the real mode DOS port to dead last.
wvenable 5y ago
Using PDP-11 to build 6502 makes a lot of sense but using that 6502 to prototype for a even simpler processer is very clever. I'm just getting into electronics as something to do over COVID; I feel I'm re-visiting a bit of that era. The 8-bit computer I'm working on 6502-based. One of the first things I did after "Hello World" on the hardware was write an emulator/debugger for the whole system in C#. I also get to use a pretty nice macro assembler compared to what you would have had back in the day. You may have encouraged me to go back to a project I've put on hold: I started writing a high-level language that compiles to 6502 assembly. I could use C but it's not very 8-bit friendly and I want to go higher level than that but still keep the 8-bit-ness in mind. I've created a lot of macros but that only gets you so far.
- WalterBright 5y ago
  If I had to do a lot of 6502 work today, I'd develop a custom language for it. Much like C is a custom language for the PDP-11 instruction set. C doesn't map very well onto the 6502, but customizing it would. Good luck on your 6502 endeavor!
  - mutagen 5y ago
    A custom language for the 6502 reminds me of the Action! language for the Atari computers. Wikipedia describes it as an ALGOL like language that included an editor, compiler, monitor, and runtime on a bank switching 16k cartridge. It was open sourced in 2015.
  - rahen 5y ago
    Have a look at PLASMA: https://github.com/dschmenk/PLASMA https://github.com/dschmenk/PLASMA