Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

running cp/m on a 32-bit arm running at 133 megahertz with 264 k of sram, 2-8 megabytes of xip qspi flash, and 4 gigabytes of flash on sd card, is not challenging, though it might be useful

i routinely ran cp/m in 48k or 64k on a 4-megahertz z80, which is about 0.6 dhrystone mips, on one or two 100-kilobyte floppies, with transfer rates of about 1 kilobyte per second. i think cp/m will run in 16k

this arm is as fast as 250 of those machines, it has as much ram as four of them, as much offboard xip program memory as 64-256 of them, and 40000 sssd floppy disks worth of storage, which furthermore can probably transfer data at 10 megabytes per second, ten thousand times as fast as the floppy

also the z80 didn't have a pio programmable i/o pin driver, it had to handle i/o interactions itself instead of outsourcing them to a channel program in pioasm, which slowed down computation

yes, if you're emulating a z80 on arm that entails some emulation slowdown, but it certainly isn't 250x. it might be 8x. if you do dynamic machine code translation it might be less than 2x

instead of calling it 'tinycpm' he should call it 'giantcpm'



Why not just celebrate it for being neat, rather than berate it for not living up to your expectations?

I thougbt it was interesting, and it has inspired me to try something similar on my pico. Especially after rereading Code recently.

Oh, and I assume that tinycpm is because it runs on a Tiny 2040.


it looks like a fine project; it just has a deceptive name




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: