3 ms·

Having a MMU, even one without support for virtual memory, would have increased the number of transistors in the CPU and, For graphics and sounds abstracting t

Having a MMU, even one without support for virtual memory, would have increased the number of transistors in the CPU and, For graphics and sounds abstracting that without adding many more transistors would have enormously slowed down graphics and sound generation (for example, even on the more powerful PC, which had a BIOS to abstract away writing text to the screen, programs had to bypass that and write directly to screen memory to get decent performance) So, short-term, it only had disadvantages.

amichail 2y ago
Assuming no hardware changes to the 6502 memory access, why would a system routine to output characters necessarily be slower than one that you code that accesses hardware directly?
- dave4420 2y ago
  There’s more overhead in calling a BIOS or OS routine than in calling one of your program’s subroutines, and your subroutine can take shortcuts, eg not updating display attributes if your program knows from context that the colours aren’t being updated.
- Someone 2y ago
  It would add at least a JSR (6 cycles) and a RTS instruction (6 cycles). Likely more if you wanted a user-level to os-level transition there. On top of that, you’d need to define an ABI to specify what to write where. That means using registers, which aren’t plentiful (I love understatements) on a 6502, the stack (slightly less “not plentiful”, but pushing a single byte takes 3 cycles, if you happen to have it in a register, and popping it back 4 cycles) or memory (that’s what https://en.wikipedia.org/wiki/SWEET16 https://en.wikipedia.org/wiki/SWEET16 sort-of did for a software ABI, and could be made to work _if_ you added extra hardware. For example, on a Z80 you could have had a graphics buffer addressable by I/O ports (write row number to one port, column number to another, then write character to a third port)

amichail 2y ago

Assuming no hardware changes to the 6502 memory access, why would a system routine to output characters necessarily be slower than one that you code that accesses hardware directly?

dave4420 2y ago
There’s more overhead in calling a BIOS or OS routine than in calling one of your program’s subroutines, and your subroutine can take shortcuts, eg not updating display attributes if your program knows from context that the colours aren’t being updated.
Someone 2y ago
It would add at least a JSR (6 cycles) and a RTS instruction (6 cycles). Likely more if you wanted a user-level to os-level transition there. On top of that, you’d need to define an ABI to specify what to write where. That means using registers, which aren’t plentiful (I love understatements) on a 6502, the stack (slightly less “not plentiful”, but pushing a single byte takes 3 cycles, if you happen to have it in a register, and popping it back 4 cycles) or memory (that’s what https://en.wikipedia.org/wiki/SWEET16 https://en.wikipedia.org/wiki/SWEET16 sort-of did for a software ABI, and could be made to work _if_ you added extra hardware. For example, on a Z80 you could have had a graphics buffer addressable by I/O ports (write row number to one port, column number to another, then write character to a third port)