Item — HN Reader

Floating point maths would be hard, and fitting the model in 64k would be a challenge - but paging could resolve that, or streaming/paging from disk if you assume something like CP/M.

Logically it's a simple project, though the devil is always in the details!

1 comments

Floating-point was ubiquitous in the BASIC interpreters on early home computers. It was just slow. CP/M didn't really do paging, although you could read and write 128-byte records to disk. But CP/M disks were typically only 90 kibibytes, or maybe up to a mebibyte for 8-inch floppies. And a lot of hobbyist home computers omitted disk drives because they were too expensive.

Sure floating point is possible, but if you're thinking of something like a 6502 or Z80 you'd have to implement it yourself - no maths co-processor, or dedicated instructions for it.

In terms of paging I was thinking of paging in later layers of data from disk, perhaps from a large file, perhaps from a series of files. But CP/M certainly did have support for paging RAM, in 3.x, if your hardware supported it.

(My own emulator, and the hardware I have running genuine CP/M are all running 2.x so no paged RAM there. Shame!)

Assuming you're using a pile of old hardware, you likely could dedicate some of it to just doing floating point math.

Yeah, people did do overlays a lot on CP/M.

If you were using a 6502 or Z80 in the late 70s you wouldn't have to write the floating-point routines; you could just call the ones in the BASIC interpreter you probably had in ROM. They'd still be slow.

As for paging RAM, do you mean bank switching? The 8085 and Z80 didn't have MMUs, so you couldn't do "paging" in the sense people normally understand it today.

The ROM floating point routines in Microsoft BASIC on the Apple ][ (and similar) took on the order of 4 ms for a single precision multiply. BASICA on an IBM PC was only slightly faster.

The FP routines in the Arduino library take about 5 µs for a multiply on an AVR (e.g. Uno).

That's 1000 times faster.

Factors in that include:

- 16x faster clock speed

- typically 1 cycle per instruction vs 3

- 32 8-bit registers can easily hold all the data for operands and result and temporary values, vs Zero-page on the 6502

- single-cycle register to register 8 bit arithmetic vs three instructions needed per 8 bits on 6502

So that's a factor of around 1633 = 144x combined.

All the above apply equally to add/sub and multiply, but also:

- AVR has 2-cycle 8x8 -> 16 multiply instructions, for signed, unsigned, or mixed operands, and for fixed point 1.7 format as well. That's hundreds of clock cycles on 6502 or z80.

Also, the Microsoft BASIC interpreters used a 40 bit floating point format (32 bits of mantissa) instead of 32 bit. That's another factor of 16/9 for multiply.

The 8080/z80 and 8086 have more registers than the 6502, but not enough to implement soft FP keeping values in registers like AVR can.

Yes, excellent points! But you don't have to do floating-point math to interpret G-code or generate motor control waveforms. You could probably do it on an 8051 fast enough to run a 3-D printer entirely in floating point, but you can also do the math in integers, only going beyond 8-bit precision when necessary.

Bank switching was the term I should have used, thank-you!