Re: Software for MS-DOS 1.25

Den Tue, 17 Oct 2017 15:10:58 +0200 skrev Michał Pleban
<lists@michau.name>:
> Mia Magnusson wrote:
> 
> > Oh, I thought that all those buffers/latches on the 8088 board did
> > half of this, and the stuff on the mainboard did the other half,
> > i.e. the 8088 board connected directly to the RAM IC:s. Too bad
> > that it isn't.
> 
> Well they do. They correspond to a similar set of buffers/latches on
> the 6509 side. Then all these latches feed into multiplexers which
> determine which processor has access to the RAM. Unfortunately these
> multiplexers are on the mainboard too.

Oh.

> > Does all known CBM-II have the same layout of the mainboard? If so
> > you might be able to make a card that sits in the sockets for dram
> > and some other circuits, and has larger ram ICs (or more ram ICs)
> > and the required logic.
> 
> There are two types of mainboards - high profile and low profile. Low
> profile needs hardware modifications to run the 8088 board anyway. My
> high profile has sockets where the high 128 kB of RAM should go, and I
> think others have them too. So it should be indeed quite
> straightforward to remove the 4164 chips from sockets, and insert a
> board with a few 44256 chips instead plus logic.

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.


Is there any use for more memory on the 6509 side?

> > It seems easier to do something with the F****-decoder so it
> > disables access to CBM-II mainboard for all adresses above 3FFFF
> > and then just add a 512k static ram IC decoded from 40000 to BFFFF.
> > Such an add-on-board could sit in the BIOS socket with some wires
> > to the 8088 board.
> 
> Sounds very reasonable.

Probably the easiest way to add memory (and also a good start to make an
ISA (partial/complete) card slot if that's wanted).

> > Maybe it would be good to do something with the adress bus so local
> > ram and shared ram end up at other places, for example shared ram at
> > B0000-BFFFF?
> 
> That's easy to do. The board outputs 4 highest address bits directly,
> so it's just a matter of changing $C to $4 to move the upper 64kB of
> shared RAM to segment B000.

Good.

> > Oh. If memory is added locally to the 8088 then atleast some I/O
> > needs to be double buffered.
> 
> I saw that IO.SYS always double buffers disk sectors for some reasons,
> and when I tried disk access myself, it hung when I trid to use
> buffers higher up in memory. It may be quite possible that the
> software has soe bugs which require using double-buffering anyway.

Well, if there is any problem with this, it can be adressed later. Just
keep some kind of "todo: check...." in the source code :)

> > To me it seems like something that scans B0000 or B8000 memory for
> > changes would be the best place to start - since it will allow
> > almost all programs to run. If some special program feels too slow
> > and is used often then it might be a good idea to patch that
> > specific program.
> 
> Originally I thought that something on the 6509 side should scan this
> area periodically, but then I remembered that 6509 cannot access DRAM
> when 8088 is running.

The 6509 is probably slower anyway.

> So my idea is that whenever INT 16h is called to check for keyboard
> input, this routine should scan video memory and instruct the 6509 to
> redraw it if it was changed. Alternatively, the 50 Hz TOD clock
> interrupt could do it, but I am not sure it it could check it fast
> enough.

I'm not an 8088 programmer, but this looks promising:

https://trixter.oldskool.org/2013/01/10/optimizing-for-the-8088-and-8086-cpu-part-1/

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.

Maybe that loop should construct a list of what's changed, and count
how many changes there are. If the count exeed a specific value then it
might be faster to just copy everything.

While the loop is running anyway it might also be easy to do
PC8->PETSCII conversion. That would require a total of 6k extra memory,
4k for a direct copy of the PC screen ram (for comparison to detect
changes) and 2k for a copy of what's going to be in the PET's screen
memory.

It might be a good idea to keep a list of COM/EXE files and let that
list tell how often this scan is going to be done, if it's even
necessary to do it att all. (I.E. software that uses various INTs to
output the screen and never use direct access could run without any
checks for direct access e.t.c.)

-- 
(\_/) 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