[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Banked CP/M 3.1 on Apple //e?
Hi Michael, et al.
"Michael J. Mahon" <mjmahon@aol.com> wrote in message
20031223171711.12363.00001577@mb-m05.aol.com">news:20031223171711.12363.00001577@mb-m05.aol.com...
> >>>Need to ensure that Bank 0 , pages 0 and 1 (6502) are not switched out
when
> >>>the 6502 'wakes-up' to do a memory refresh.
> >>
> >>
> >> I presume you mean a "register refresh" of the 6502, since Apple II RAM
> >> is refreshed by the video generator.
> >>
> >> And the 65C02 is a static design, so no "refresh" is required.
> >>
> >> -michael
> >>
> >> Check out amazing quality sound for 8-bit Apples on my
> >> Home page: http://members.aol.com/MJMahon/
> >
> >Good... I can settle for requiring the main CPU to be a 'C02, if it
> >makes it easier ;)
>
> The point may be that the SoftCard hardware periodically pauses
> the Z-80, and releases the DMA line, so that the Apple II 6502
> can have a couple of cycles to refresh its dynamic registers.
I don't have a softcard manual handy, but this is exactly what it alludes
to, which is what I was implying in my first post.
Don't quote me, but IIRC the 6502 is allowed to execute a few cycles
every so often with the /wait line held low, to allow the internal 6502
registers to be refreshed.
>
> If this means that the 6502 is "idling" in a short loop, and if that
> loop requires page 0 and/or the stack page to be intact (curious,
> since a "JMP *" should work fine), then provisions for that might
> need to be made in a bank-switched scheme.
It doesn't require it for the above mentioned refreshing, but it needs
it for the z-80->6502 (and vice versa) context switches. The 6502
is brought ot a halt in this area, and similarly 'wakes up' there aswell.
I can't remember off the top of my head where the Z-80 wakes up
(in it's address space).
>
> However, in an emulated system, the momentary de-assertion
> of DMA is irrelevant for 6502 refresh, since the emulated 6502
> certainly does not need refreshing!
True.
> It is possible, however, that the "idle" loop for the Apple II is
> polling something important to continued functioning (such as
> a printer buffer, or a UART), so that it is still vital for the simulated
> 6502 to periodically emulate a few cycles. If this is the case, then
> clearly, the bank switching for the 6502's view of memory must be
> what it expects.
By default the Z-80 interrupt enable switch on the Microsoft card is set
to OFF.
Most of the common Apple2 peripherals (SSC,etc.) have Z-80 drivers
anyhow, so there is no need for the 6502 to 'poll' anything.
If 6502 interrupts are enabled, they won't be serviced until the 6502
wakes up, plus you have consider what the 6502 will pull from memory
to use as the interrupt vector. Normally the ROM is switched OUT.
This becomes even more complex when you could have multiple banks
switched in, any of which could be used to read an interrupt vector from.
This becomes really tricky, since you have no way of knowing (when in Z-80
mode) whether the 6502 has received an interrupt, when you pass control back
to it!
The CP/M2.2 (56k) and 2.23 (60k) versions supplied with the softcard both
disable 6502 interrupts as far as I know. Anyone with a 2C (which uses
interrupts
for it's type-ahead buffer and serial ports) conform this?
All 6502 interrupt drivers would then logically have to live in page 3 of
6502 bank 0.
$E300-$E3FF Z-80 space I believe. And Bank 0 would have to be visible to
the 6502 whenever control was passed back to it. Doesn't leave an awful lot
of room,
but the interrupt routine itself could always bring in other banks and page
them out
as required.
I only mention all this because if you are going to implement it in an
emulator, you
will presumably want it to work on a real Apple2?
Cheers,
Red