Re: Software for MS-DOS 1.25

From: Mia Magnusson <mia_at_plea.se>
Date: Thu, 19 Oct 2017 22:24:56 +0200
Message-ID: <20171019222456.000005a7@plea.se>
Den Thu, 19 Oct 2017 11:22:43 +0200 skrev Michał Pleban
<lists@michau.name>:
> Mia Magnusson wrote:
> 
> > That would give 640k, if replacing two banks of 4164 with 4*256'.
> > But maybe it wouldn't be too much work to add an extra bank of
> > 2*256's? That would give RAM from 0 to DFFFF. That is actually so
> > much that some kind of disable logic would be needed if some "real"
> > PC hardware would be added.
> 
> Two banks of 256 kB would indeed give 640 kB plus video RAM at segment
> B000, I think for PC emulation that would be enough.

No, three banks of 256k would give that. Two banks of 64k and two banks
of 256k would give exactly 640k. If the two banks of 64k isn't socketed
it might be worth the effort to look into the possibility to use a
total of 5 banks instead of 4 banks, i.e. 64+64+256+256+256k, maybe with
one bank not visible from the CBM-II side.

> > Is there any use for more memory on the 6509 side?
> 
> I don't know any CBM-II program that would use it.

Someone has to be the first to create such program :)
 
> > Something with REP CMPSB or REP CMPSW might be possible, letting the
> > CPU do the whole compare in one go. If REP doesn't work the CMPSB
> > and CMPSW is still of good use as in a normal loop it's easy to
> > insert the code that handles changed bytes.
> 
> Judging by the information here:
> 
> http://www.cs.dartmouth.edu/~mckeeman/cs48/mxcom/doc/x86.html
> 
> REP CMPSW on the whole screen should take about 12 ms on a 5 MHz 8088.
> It could be divided into checking 256-character chunks, for example,
> and updating only those that changed. Then actually encoding these
> into PETSCII and saving somewhere later would take several times more
> in the worst case, plus a call to 6509 to copy prepared PETSCII data
> to the screen. It is lots of time but manageable, especially if we
> replace the 8088 with a V20 which should be noticeably faster here.

I came to think of that I'm not sure if REP CMPSW is feasable. Would it
overwrite all flags from a previous pass?

But yes, a V20 should be faster.

If we anyway need to add some hardware for memory expansion, it could
contain some detection for writes to graphic memory.

I don't know which way is the best to go. Maybe do something with the
segment F signal mapping out most of the CBM-II access from 8088
memory, and remap the CBM-II memory from C0000 upwards. That way the
CBM-II memory could be switched out when the 8088 is running normal DOS
programs, and switch it in when it runs special communication code in
it's BIOS. Maybe a REP MOVW (or whatever it's called in 8088 syntax)
could just copy the PC text mode screen to CBM-II memory and then the
memory could be switched over to the 6509 and then let the 6509 process
it?

Maybe this would reach the point where it would be better to make a
completely new 8088 board as it otherwise would need both some board to
sit between the 8088 board and the CBM-II board (to remap memory), and
also some board to sit on top of the 8088 board adding more memory and
the appropriate adress decoding and change of "segment F" signal.


-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

       Message was sent through the cbm-hackers mailing list
Received on 2017-10-19 21:03:50

Archive generated by hypermail 2.2.0.