Apple /// pseudo Dma

[Rob Justice]

Hi,

I came across this interesting find by accident, it's not something i had read about before, so I thought I would share it. Perhaps others have more info on this.

I was reading through the Apple /// service reference manual looking for info on the video modes and came across this comment in the appendix, chapter 17.

I/O block transfer
-Permits up to one page(256 byte) fast I/O transfer without dma hardware on peripheral
-Transfers at up to the ram cycle rate.

I then did some more digging and found that the profile card and driver uses this. (Refer Profile driver source code) It enables the 'dma' on the card and then sets up the apple3 zero page register to point to the appropriate page in ram. It then jumps to a routine in the rom at $F800 that has dummy code that causes the address bus to step through 256 address. The rom is inside the address mapping switches for the zero page register so the 6502 keeps happily running the code in rom, while the peripheral is writing/reading directly to memory using the address on the memory address bus. This uses the zero page register as the top 8bits of the address.

While it needs the the processor to be occupied while doing the transfer, it's a clever way to get a transfer running as fast as possible with no extra hardware on the peripheral card. If you look at the profile interface card schematic, it does not have that much logic on it.

Always amazes me how many neat tricks the apple3 hardware has.

/Rob

[David Schmenk]

Good find. Dr Sanders mentioned this to me when I asked him about the extended memory addressing architecture. He built a test rig for transferring memory to a memory card as a preliminary exercise in page swapping. Such a shame Apple messed up his design - without a doubt the most sophisticated 8 bit machine sold.

Dave...

[Michael "AppleWin Debugger Dev"]

On Saturday, July 19, 2014 5:26:23 PM UTC-7, David Schmenk wrote:
> On Friday, 18 July 2014 20:48:59 UTC-7, Rob Justice wrote:
> Good find. Dr Sanders mentioned this to me when I asked him about the extended memory addressing architecture. He built a test rig for transferring memory to a memory card as a preliminary exercise in page swapping. Such a shame Apple messed up his design - without a doubt the most sophisticated 8 bit machine sold.

Dave, do you have any more info. / links on Dr. Sander's design?

Thanks,
Michael

[mdj]

On Sunday, 20 July 2014 10:26:23 UTC+10, David Schmenk wrote:

> Good find. Dr Sanders mentioned this to me when I asked him about the extended memory addressing architecture. He built a test rig for transferring memory to a memory card as a preliminary exercise in page swapping. Such a shame Apple messed up his design - without a doubt the most sophisticated 8 bit machine sold.

Without wanting to start a war, I think that honour should probably go to the Tandy Color Computer 3. An M6809 and a PMMU enabled it to run OS-9 Level 2, and OS-9 was jaw-droppingly good.

You could argue that it appeared too late in the game to really 'count' though, and the Apple /// certainly managed to do a *lot* with very little.

[David Schmenk]

This is what Dr Sanders sent me:

There were a couple of features that I'm not sure were documented except possibly in the Service Manual. One was a hardware slow scroll that would allow text in high res to be slow scrolled. I once designed a 68000 peripheral with 16K of resident DRAM and demand paging (allowing for full 24 bit 68000 addressing) that used the block transfer for updating page exceptions. I once described that to Santa Cruz Operations for a possible UNIX port and at the time I don't think they what understood virtual addressing was.


Dave...

[David Schmenk]

The 6809 was more like a 16 bit CPU in an 8 bit CPU body. But I'm not sure how expandable the CoCo3 was (I recall them being pretty closed). The /// was almost as expandable as the II. However, neither the /// or the Coco3 were supported as well as they should have been - lots of potential that never materialized.

Dave...

[mdj]

On Tuesday, 22 July 2014 01:44:44 UTC+10, David Schmenk wrote:

> The 6809 was more like a 16 bit CPU in an 8 bit CPU body. But I'm not sure how expandable the CoCo3 was (I recall them being pretty closed). The /// was almost as expandable as the II. However, neither the /// or the Coco3 were supported as well as they should have been - lots of potential that never materialized.

It's always been unclear to me what really denotes a processors word size, other than what the manufacturer claimed in the marketing material. Motorola claimed it was 8, but the processor has better support for 16 bit programs than the 65816 does. If the 65816 is a 16 bit processor, then by rights the 6809 is too.

At least with modern processors it's more clear; a 64 bit processor is 64 bit because if it's virtual address space, and the same really applied for 32 bit, despite there being a multitude of "32 bit" processors with < 32 bit ALUs, instruction sizes, data and address busses :-)

As for expansion, there really is nothing that compares to the Apple II's slot architecture. The ISA bus was close, but is neither as elegant nor as flexible. That said, the Coco's cartridge slot was 'good enough' to add the peripherals people really wanted.

Matt

[Carsten Lucassen]

> The 6809 was more like a 16 bit CPU in an 8 bit CPU body. But I'm not sure how expandable the CoCo3 was (I recall them being pretty closed). The /// was almost as expandable as the II. However, neither the /// or the Coco3 were supported as well as they should have been - lots of potential that never materialized.
>
>

... mmh, reading through the posts in this thread, the question of wether the /// should really be regarded as an independent computer system once again comes to my mind.

Basically, most of everything that differentiates a /// from a II goes back to the question of unwanted compatibility - especially the crippled Apple II mode. The processor, however, the slots (only four of them), the disk system - all this is nearer to a standard off-the-shelf II than, for example, a GS. So why is it that the GS is generally considered to be a full member of the Apple II family whereas the /// is not?

Could just be the name? Would we think differently if the Apple /// had been named Apple IIb (b for business) or (much more likely) Apple Sara?

From my point of view, a re-evaluation of the whole Apple /// project is certainly overdue. Most people see the /// as a kind of "cousin" to the II, but for me it's more like an illegitimate child. As for potential that never materialized, the /// is just like the GS. Just think what could become of that machine if Apple had actually started production of the Mark Twain and added a little bit of CPU horsepower?

Okay, maybe I am just a bit too nostalgic. ;)

[gid...@sasktel.net]

And now that I have the Sweet 16 emulator, my Quad-core Mac is really an Apple II with a lot of horsepower I don't use :)

[Rob Justice]

> Good find. Dr Sanders mentioned this to me when I asked him about the extended memory addressing architecture. He built a test rig for transferring memory to a memory card as a preliminary exercise in page swapping. Such a shame Apple messed up his design - without a doubt the most sophisticated 8 bit machine sold.
>
>
>
> Dave...

I found this in the Service manual regarding the smooth scroll:

Slow scrolling is accomplished in the Video Mux ROM by the arithmetic offset
of the VA, VB, and VC lines. This offset causes characters to be fetched from
memory In advance of where the screen actually thinks it is. The character
array on the screen shifts up the number of dots determined by the binary
weight of the VBX lines. The processor, by monitoring the Vertical Blanking,
can then step the VBX lines and scroll the screen by moving in new lines at
the bottom, removing the top line, and placing lt at the bottom, thus rolling
the display.

And:

C0D8 Clear SCR (to turn smooth scroll off)
C0D9 Set SCR (to turn smooth scroll on)

C0E0 Clear DPHO (also VAI)
C0E1 Set DPHO
C0E2 Clear DPH1 (also VBI)
C0E3 Set DPH1
C0E4 Clear DPH2 (also VCI)
C0E5 Set DPH2

So it looks like the disk stepper phase lines have a dual use.

I wonder if there is any software using this feature?

/Rob