From: Baltissen, GJPAA (Ruud) (ruud.baltissen_at_abp.nl)
Date: 2005-04-21 12:47:30
Hallo Gabor,
I will be reacting on several emails regarding this subject.
> The problem is about threads.
Being more a hardware guy: what is a thread?
> So I have to use private zero and stack page for each threads?
IMHO each _program_ should have its own stack and zero page, that's for
sure. Not knowing what threads exactly are, I only can say this: give each
thread its own stack and ZP as well. If on the end it turns out you don't
need them, you always can discard this feature.
But then there is something else you may not forget: the registers of the
CPU and the hardware, and the videomemory. Assume this MMU thing runs on a
C64. This MMU enables you to do some multi-tasking. And I can imagine that
one program needs the BASICROM and another one the RAM under this ROM. So
you see that it is not only a matter of switching RAM but, in this case, the
I/O-port of the 6510 has to be adjusted for each program as well. And this
simply means that the configuration of at least this port has to be stored
in memory somewhere for every parallel program.
> Of course, if someone want to create a real hardware like
> this, it's another story.
Being a hardware guy, I prefer real HW of course. There exist very nice MMU
IC's, the 74HCT610 (used by Andre) and the 612, but both have a
disadvantage: where can they be bought? My only source of 612's so far was
scrapping older PC 286 motherboards.
That's why I designed my own one. The core of this MMU can be found in the
top of http://home.hccnet.nl/g.baltissen/pccard2.gif under the columns 5,6
and 7. Using real memory, even fast cache-RAM, has a disadvantage: the
clockspeed of the CPU is limited. (But 4 MHz should be doable IMHO).
BTW, anyone knows other MMU IC's?
Andre:
> You mean, the mapping table would be set in hardware instead of having
> the CPU reload the mapping each time? Interresting idea!
Hmmm, very interesting indeed! As you can see, not all the addresslines of
the RAMs in my MMU are used; they are conected to GND. Adding an I/O-port
(74ALS573, 6522, 6526) to these lines means we can store 32 configurations
(512 when using 32K*8 SRAMs) that can be choosen by one single STA $xxxx
command.
> ....E.g. by hardware-monitoring the address lines
Doesn't work IMHO. You can generate a NMI the moment an user accesses a
forbidden area. But the NMI will only be serviced _after_ the harm is done.
With the 65816 this is another story; here we have the ABORT input that
breaks off the momentary instruction.
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org
=====DISCLAIMER=================================================================
De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.
The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.