Page 1 of 1

8DOS: overlay RAM control?

Posted: Thu Apr 26, 2018 6:29 pm
by ThomH
Documentation seems to be extremely slender on 8DOS, so here's what I currently think I know.

From iss I've learnt the fundamentals necessary to support 8DOS v1:
  • the boot ROM is visible from $320 to the end of that page; and
  • the Disk II controller registers are exposed from $310.
Per the Fastload sources, address decoding is entirely straightforward — register order is exactly the same as on an Apple II.

Since iss' post refers to the DOS 3.3 layout, one can deduce that the interface uses the 16-sector state machine P6 ROM and that the boot ROM is an exact analogue of Apple's 16-sector boot ROM. Apple's ROM (commented disassembly) is fully relocatable but is also 251 bytes of code and loads its boot sector into a different location — 0x800 on the Apple versus 0xb800 with the Pravetz — so Pravetz's is not a direct copy of that.

The Disk II and Apple DOS 3.3 are very well documented elsewhere; see Beneath Apple DOS, Beneath Apple Prodos (which has a fully explanation of the controller in addition to being about a different operating system), Inside the Apple IIe, etc. All available on

The original version of 8DOS uses regular RAM for its workspace. Version 2 onwards use overlay RAM.

So, the dangling question:
  • where and how does the Pravetz disk interface provide a control for ROM paging?
On a Microdisc you'd use bits 7 and 1 of the control register that is partially decoded to appear at 0x314 to 0x317 to disable the OS and/or BASIC ROMs and expose overlay RAM. What would you do with a Pravetz?

Re: 8DOS: overlay RAM control?

Posted: Thu Apr 26, 2018 8:09 pm
by iss
Everything you wrote is correct. 8D FDC is exactly the same as Apple][ and it uses the 16-sector WOZ state machine P6 ROM.
All 16 FDC registers are the same and are mapped at $310..$31F.
There are only 2 differences from Apple:
- no slots;
- boot ROM is shorter version - only 224 bytes instead of Apple's 256 bytes and it loads TR0/SEC0 at $B800.

Boot ROM is mapped at $320..$3FF. In the newer FDC version it has 2 pages: 1st page is called DRIVER, 2nd - BOOT CODE.
Only one of this pages can be active at a time and the selection is made by a simple write operation to $380..$383.
Depending on the selected address you control the RAM overlay access too. I.e. write at:
- $380: RAM overlay 16K - disabled, BASIC ROM - enabled, DRIVER ROM page - activated (default state after RESET)
- $381: RAM overlay 16K - enabled, BASIC ROM - disabled, DRIVER ROM page - activated
- $382: RAM overlay 16K - disabled, BASIC ROM - enabled, BOOT CODE ROM page - activated
- $383: RAM overlay 16K - enabled, BASIC ROM - disabled, BOOT CODE ROM page - activated
The value which is written to the above addresses doesn't matter i.e. from assembler: sta $380 will select BASIC+DRIVER, no matter the current value of the accumulator A.

There are some 8D FDC variants which have also up to 3 real slots - just like the Apple's. Slot #0 is always reserved for the FDC.
In this case the I/O space $310..$31F is shared. To select which slot is active - write its number to address: $3FF. Or:

Code: Select all

lda #0
sta $3FF
will select the FDC ;).

Re: 8DOS: overlay RAM control?

Posted: Thu Apr 26, 2018 8:40 pm
by ThomH
I guess the engineers at Pravetz really internalised the idea of soft switches!

So you can put almost any other Apple II card into the other slots and expect to be able to talk to it? Was there any software support for that?

Presumably subject to limitations, which I would guess(?) to include: the 256-byte region each card conventionally uses for a ROM not being exposed, no DMA support, and the input clocks all being slightly different. In the case of phi1 and phi2 probably very different since the Oric spends twice as long in phase 1 as in phase 2 and the Apple doesn't, and the Oric doesn't have periodic stretch cycles.

Re: 8DOS: overlay RAM control?

Posted: Thu Apr 26, 2018 9:27 pm
by iss
I guess the engineers at Pravetz really internalised the idea of soft switches!
The engineers from Pravets only stole Oric but they forgot to 'borrow' Microdisc too. :)
The FDC is entirely 'one man show' - the author of the hardware and DOS-3.3 adaptation is Borislav Zachariev - student at that time.
Later versions of the FDC were made by other very talented hobbyists.
The FDC with real slots give very interesting possibilities, but I'm sure - no single such extension exists!
And yes, all limitations enumerated by you are to be considered.

Re: 8DOS: overlay RAM control?

Posted: Wed May 09, 2018 4:05 am
by ThomH
Sorry, it's a gross digression, but having attempted to implement an emulation of the scheme as above, I see as per this video; the machine hangs at the end — I can wait indefinitely and that final frame will be unchanged:

So my relevant follow-up question: what should I expect to see when booting DOS 1.30? Should that counter in the bottom right descend below 00:A before vanishing? Would I normally get the BASIC prompt back?

Re: 8DOS: overlay RAM control?

Posted: Wed May 09, 2018 8:16 am
by iss
Yes, exactly after 00:A the counter hides, blinking cursor is restored and you are in BASIC.
BTW, this version (and in particular 130.dsk image) freezes in real hardware too in the same way!
How are working other versions (i.e. 100.dsk, 210.dsk and 231.dsk)?
And two questions about CLKSIGNAL: where I need to put DISK][ FDC ROM images? and how I can load two images in two drivers? :)

Re: 8DOS: overlay RAM control?

Posted: Wed May 09, 2018 2:35 pm
by ThomH
I tried only 130 and, from memory, probably 210; neither seemed to proceed all the way back to the BASIC prompt. But it wasn't particularly systematic testing. I guess that most likely I've messed up my implementation of 0380–0383 as all DOSes to count down and then get stuck, so maybe they're inadvertently branching to nothing?

That snippet aside, for the public record, we've continued the CLK discussion more privately since it isn't a 'technical questions' topic, and the emulator is mid-development cycle, so I don't actually want to release it yet. Though it's a public repository, so everybody is always free to peek.

EDIT: actually, possibly interesting follow-up question: have you experimented with Apple II-esque vapour lock on the drive registers? That is, do the results you get from reading soft switches appear to be leftovers from whatever was previously on the bus and, if so, do they therefore provide a way to track the video scanner?

EDIT2: 8DOS issues all resolved by the way. I just needed to report a different 'volume' for DSK files.

EDIT3: also, in case it adds anything for anybody else who finds this thread, I've tried to consolidate everything you need to know about surface-level Apple DOS disk encoding here. 8DOS uses the same physical and logical layout as Apple DOS 3.3 — the '6 and 2' encoding.