Solving differential equations on a 6502 with Woz's floating point code
github.comI find it funny that people enjoy the nostalgia of things like 6502... I loved my Atari 800XL, but wistfully dreamed that computers might one day be able to handle 320x240 with 256 colours.... boy... that would be good! Meanwhile I was hand assembling 6502 into data sections in basic so I could try and draw a circle... who knew drawing circles was so ridculously difficult and slow?
Having said that, I do like this stuff in hindsight :)
I liked this piece for the attempt to imagine what using an early personal computer was like and getting it wrong in good and interesting ways - statistically nobody had an Apple I and everything later had BASIC and higher level (i.e. not just monitor) CLIs - that was the big selling point. Later there's a bit about maybe using a decimal FP representation and my first thought was 'no, that's nuts' but your mention of the 800XL sent me to the wikipedia page:
"The first is that all numeric values in [Atari] BASIC are stored in floating-point binary coded decimal (BCD) format"
Having spent many hours recently futzing writing code for the 65816, including writing an emulator for a machine based around it, and spending many hours investigating writing a C compiler for it...
I think I might have cured myself of my 6502 nostalgia. I don't want to look at one again for a while.
Were you using a CORDIC algorithm? Bit shifts and adds, no multiplies required.
You don't need CORDIC to draw a circle. BTW, I implemented a CORDIC routine in 6502. It would really benefit from a barrel shifter which the 6502 does not have. https://atariage.com/forums/blogs/entry/3385-atan2-in-6502/
In gist form https://gist.github.com/djmips/29a8fa9099bf92b31a7259da65915...
Using a CORDIC algorithm would mean having many iterations to compute trigonometric functions for each drawn point (well, for each 8 points considering the symmetries). A variant of the Bresenham line algorithm for circles lets you draw a circle using only a few operations per 8 points (and the operations are also limited to add and shift):
no, I had hardcoded lookup tables. I was a teen with no real way to find out information about anything and just applied my high school math to the problem :)
Not the floating point, but saw his code for other parts of the 6502 Apple products, he really was a genius. The code is both very clever AND quite understandable.
My understanding is his circuit design was similar. One thing, use a part of the circuit for two different things at different points of the clock cycles, so parts count was reduced.
There's also "Sweet 16", Woz's "16-bit virtual machine" that's in the Apple ][ Integer basic ROMs. Another piece of pure genius code.
Is that first-order approximation appropriate for iteratively solving the Diff EQ? Or does a higher order method such as Runge-Kutta have to be used? I notice the graphs don't align perfectly...
It's the easiest approach to solve the ODL: Euler Forward (yes, first order). The approximation could be much better and almost exact with a smaller step size. Runge-Kutta is used for higher ODL's, where the Euler method would fail (especially with periodic solutions).
Very interesting ... thanks for pointing to py65 as well
Awesome. I love projects like this.