Well, there are lots of different handwritings. Not everyone writes cursive (especially in the US it seems to be very rare). My own handwriting is something like a hybrid between cursive and print with a few contextual ligatures thrown in.
there were 3 custom chips (ANTIC, GTIA and POKEY) 1 semi-custom (SALLY was a VERY MINOR modification of 6502) and 1 common industry chip (PIA). I would not say exactlly "lot of" ;-)
Well, relatively speaking that was a lot for late 1970s microcomputers. The original Apple ][ and TRS-80 Model I were essentially built from off the shelf chips (which is why both got off-brand clones).
Ps there was a game that had a similar FPS view in those days. It was a maze game with polygon graphics but no textures. I forget the name. No shooting though!
* Alternate Reality: The City (Datasoft/Paradise Programming)
FRPG with 90-degree turns, rendered walls/doors as scaled textures between the animated backdrop and foreground NPC sprites.
I wrote an FAQ as a kid for Mercenary for local BBS' - I think I discovered at least 3 victory conditions. :^)
So I was curious about how the Atari 800 handled floating point calculations. As it turns out, Steve Wozniak helped develop the FP routines for the 6502.
I doubt there are any floating point numbers because FP is very slow to emulate (for example, just to add two numbers you have to shift mantissas and 6502 has no fast way to do it). If I was writing a game for an 8-bit CPU, I would use fixed point numbers (for example, 8.8 numbers which use 8 bits for integral part and 8 bits for the fractional part, or maybe 10.6, or 12.4 numbers).
6502 cannot multiply or divide (division is a costly operation even on modern CPUs) so I would use adding or subtracting logarithms for this purpose. 12-bit precision logarithm table requires just 8 Kb RAM (and you can get 13-bit precision with interpolation).
The disadvantage of this approach is that every time you convert a number from linear to logarithm or vice versa you get approximately up to 0.3% error (for 12-bit logarithm). So multiplying or dividing several numbers in a row is fine, but if you have to alternate multiplication with additions you will accumulate an error. So I would look for formulas that avoid this. But for a game a little error in calculations is not noticeable.
Also one might think that the most time-consuming part for pseudo-3D game is math and calculations. I doubt that. The most of CPU cycles are usually spent in rasterisation and applying textures. Is is easy to calculate positions of 3 vertices of a triangle, but it takes a lot of time to draw it line by line, pixel by pixel, and if you want to have textures this time can be multiplied 5x-10x.
I can assure you that no BCD routines (nor Woz's nor Atari's) were hurt during production of this game. They are really slow. You need to use all kind of tricks and cheats when creating 3d game on 8bit machine and all needed calculations are precalculated in lookup tables.
it should look like this in my book:
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcS3tT5h...