6

I’m trying to make some graphics in Processing that look just like what I’d get on an Apple //e. I think this info is in rom disassembly but I can’t find anything by googling. Im also interested in the algorithms behind other Applesoft Basic commands

  • Voted as unclear: HPLOT merely places a pixel onto the screen. So what it does is exactly specific to the Apple II hardware: it figures out which address holds that pixel per the Apple memory map, and which bit too set. So in any other framework you'd just use whatever method it has to plot a pixel. Do you possibly believe that HPLOT does something else? – Tommy Aug 13 at 21:30
  • 3
    I'm pretty sure you meant HPLOT. HLIN draws on the low-res screen, HPLOT draws on the hi-res screen, HLINE isn't a thing. To draw a line on the hi-res screen, you would do something like HCOLOR=3: HPLOT 0,0 to 279,191. – fadden Aug 13 at 22:28
  • 1
    Apologies then, my memory has failed me! Vote withdrawn. I'm an idiot! – Tommy Aug 14 at 0:07
12

You can find the hi-res drawing code in an Applesoft disassembly. HPLOT starts at $F6FE.

The ROM code is optimized for size, and parts are tricky to sort out. If you want something a bit more straightforward, you can find Applesoft-ish line drawing in fdraw. Some commentary on how Applesoft's line drawing code sets bits on the hi-res screen can be found in the documentation.

One difference between Applesoft's routines and a typical Bresenham implementation is called out in the fdraw docs:

The Applesoft routine isn't quite the same as the standard Bresenham algorithm, because it doesn't move diagonally. Consider a line from (0,0) to (50,10) -- gently sloping down and to the right. The standard algorithm would plot exactly 51 pixels, one in each horizontal position. The "pen" always moves one pixel right, but sometimes also moves down.

In Applesoft, the "pen" can move either right or down, but can't do both at once. This results in lines that feel thin when near horizontal or vertical, but become thicker as they approach 45 degrees. This reduces performance, because Applesoft draws twice as many pixels for a diagonal line as the basic algorithm. It can also be visually jarring when animated, because lines get very thick when near diagonal.

2

The routines are documented in the Programmers Aid #1 manual

https://archive.org/details/programmers-aid-1/page/n81

These are basically the same as the ones in the Applesoft ROM. They might use different zero page locations and won't handle floating point numbers but they are the same algorithms.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.