Greetings, Jon De Schrijder...
GV>I'm already developing an 8031 microcontroller circuit for my
>SV-328; it takes over the task of scanning the keyboard matrix,
JS> Nice! But I can't see any major advantages: if I want
> 'computingtime' I DIsable the interrupts or you can write
> your own interrupthandler
DI is useful for short stretches of critical code, but an MSX
can't (and won't) run indefinitely without interrupts, as you
know -- at least not if we want little luxuries like an active
keyboard. ;->
Even with "your own" interrupt handler: As long as Z-80 Mode 1
is used, as it is in MSX, there's only one entry point for all
interrupts -- so handling multiple devices remains very much a
matter of polling each, to determine which need attention.
If interrupts are asserted judiciously, and/or the total system
processing load distributed among smart peripherals (e.g. using
embedded microcontrollers), the overall performance improves.
The MSX/Spectravideo CPU is ruthlessly interrupted by the VDP.
JS>It's not my intention to discuss HERE all changes I've made to
>both soft- and hardware. I'll just mention some key elements,
>useful for people with a non-working IDE.
>*There are 3 IDEBIOS versions available:
>*There was a major bug in the DOS2.20 installationroutines.
>*If you are one of the first people who bought an IDE, you'll
>probably need to do the following modifications:
>*The IDE-interface was developed by Gilvad on his Turbo-R and was
>not tested on any MSX2. And indeed, it doesn't work on most MSX2
>Nevertheless my CDROM still doesn't work...But I'm working on it!
>
>To return to Greg's questions:
>I don't think it is a good idea to make a 'cpu-controlled' IDE
>interface, because the IDE-standard is already very Z80 friendly;
Hmmm, I don't know, Jon -- your long list of IDE problems makes
me think that a microcontroller-based ATA/IDE is the way to go!
(For the sake of less typing, "8031" equals "microcontroller",
though virtually any uC could be used, and "ATA" == "ATA/IDE".)
I agree that the ATA is Z-80 friendly, but interface circuitry
between a host CPU and peripheral is just the beginning in the
life of a peripheral or adapter.
An 8031-ATA adapter could be fairly immune to incompatibilities,
across MSX/non-MSX hosts, as the complexities are contained and
resolved on the 8031 side, i.e. ROM BIOS, RAM, and interface to
drives. As long as the host uses defined commands, the 8031-ATA
should operate consistently.
An 8031-ATA will look like just another set of addresses (i/o or
memory-mapped) to a Z-80, and it could be programmed to offer a
variety of modes for interaction with the CPU -- e.g. multiple
sequential reads/writes, much as the VDP does, for example.
Maybe my daily work with embedded systems makes me bullish on the
concept of distributed processing -- even at the microcontroller
level. One project I was involved with interfaced a Z-80 product
by RS-232C to an 8031 uC attached to a GPS receiver which in turn
had a 68000. Any one of these brains alone would have been hard-
pressed to provide the end-product function and economy.
Cheers,
Greg_
http://www.netcom.ca/~telic
98.Sept.12, Toronto, Canada.
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
