Re: BASIC for the CBM-II/8088

Den Mon, 16 Jul 2018 14:56:00 +0200 skrev Michał Pleban
<lists@michau.name>:
> Hello!
> 
> Mia Magnusson wrote:
> 
> > Then the list member SMF would figure out a yet non-existing use
> > case where those user port pins are needed for something else ;) ;)
> 
> Well, the user port _is_ meant to connect different stuff to it, so it
> would make more sense to leave it free.
> 
> What I thought about is whether this kind of latch could be implementd
> in a 16V8 in registered mode? Then there is also output enable pin, so
> it could be used to attach it to the 8088 easily.

To be honest I think the feature-creep-deluxe-solution of
(pseudo)simultaneous access to the same memory is the right solution.

> > A rather complicated solution which probably would be efficient
> > would be to not have a simple flip flop remembering which areas
> > that were written to, but a counter for each area (which cannot
> > overflow but gets stuck when reaching it's max value). That way the
> > software can check how much has been written to a particular area
> > of the screen. If it's only a few bytes, SCASW would be the fastest
> > solution while if much has been written a pure copy would be the
> > fastest.
> 
> If we start doing complicated stuff like this in hardware, the I
> suppose in the end it will become easier to just slap a 6845 on the
> board and make it generate video signal itself :-P

... or ISA slots :) That way we could have EGA or VGA, and even run
Windows 3.0 in real mode (assuming a bit more memory than 256k is
installed) ;)

> > The performance-wise best solution must be to use some
> > synchronisation so the same memory can be simultaneously used by
> > both the 8088 and the 6509. There are expensive dual port SRAM's
> > but I think it would be good enough with a solution that just
> > delays one processor when both want to access the memory at the
> > same time. Or it could even work like the original CGA card, with
> > "snow" if the 8088 writes outside the vblank period, but this
> > "snow" would be that the 6509 gets incorrect data while reading. As
> > this is easily detectable by the hardware, it could generate some
> > flag or interrupt to the 6509 making it redo the last few bytes.
> 
> There is a RDY input on the expansion connector, so it might be
> possible to stop the 6509 from the 8088 side. But IIRC, the are
> buffers on the mainboard that explicitly select one processor or the
> other for memory access, I would have to examine them whether it's
> possible at all to allow two CPUs access to the RAM.

The buffers (or rather mmuxes for the address lines) are controlled by
the _BUSY1_ and _BUSY2_ mechanism, together with the refresh logic for
the address lines.

I'm not sure what is the rationale behind disabling the bank signals
from the processor and always force them to be $F when a coprocessor is
active via the BUSY1/BUSY2 mechanism. Maybe the idea is that the 6509
can detect if a coprocessor is active by trying to write to what is rom
in bank 15, and see if it's writeable or not.

But we have already discussed this IIRC :)

So there seems to be two ways for a coprocessor to access dram. Either
like the 8088 board and with software syncronisation making sure the
6509 only uses bank 15 and let the coprocessor use the dram almost all
the time. Or the other way would be to hold the 6509 for a short
while using RDY and then for a short period access the dram from the
coprocessor.

I think it would be great to investigate how the 8284A and the 8088
works cycle for cycle. By either replacing the 8284A with programmable
logic, or using some of it's features currently not in use on the B
8088 card, it might be possible to sync the 8088 to the 6509 clocks.
(And as I suggested earlier, run the 8088 at 18/3MHz instead of
15/3MHz).

After having a short look at the 8088 data sheet, it seems like the
8088 in it's fastest mode has 4 clock pulses for each bus cycle. As I
understand it, running the 8088 at 8Mhz would mean that the bus cycles
occur as often as they do on an 6509 at 2Mhz. By generating the 8MHz
clock from the 18MHz dot clock (either unfortunitely with some
"analogue" delay to make it having a 33% duty cycle, or a PLL (and
maybe the 8284A) to generate a 24MHz clock synced to the 18MHz dot
clock) they could run syncronized and share the memory. That would
require dram of the same speed or faster as the 8296 (which accesses
the dram at the equivalent of 4MHz when reading data for video output),
while the B default dram speed is probably slower.

I know this would complicate things quite a bit, but it can be done in
steps. A first step would be to just run the 8088 in sync with the 6509
speed, but still only let one of them access the dram as it is today.
When reaching a point where this syncronization is achieved it might be
possible to let both CPU's share the dram.

If it would be possible to sync the CPU's this way, it might be
possible to share (selected parts of bank 15 as well. That would
require changes to the B motherboard though, but the long term thing
would anyway be to make some improved B replica motherboard.


To complicate things we might have a look at the schematics of the Z80
card that recently surfaced, to see if it's possible to do the same
thing with the Z80.


Btw the P500 also has the BUSY1/2 mechanism, so the reason for the 8088
board not working in that is probably some hardware bug somewhere, or
maybe as simple as the dram on the P motherboard being too slow (as
with the 6509 it is used at 1MHz instead of at 2MHz).

Btw are we 100% sure that the 8088 card won't work in a P500?

> I also thought about dividing the screen refresh between two CPUs. The
> 8088 could read the data bytes from memory, feed them to the 6509 via
> an I/O port and signal the 6509 via the SO pin, upon which the 6509
> would read them, convert to PETSCII and save to video RAM. This way
> both CPUs would work in parallel, so maybe it would allow speeding up
> the whole process.

As the 8088 seems a bit faster, maybe it's faster to do the petscii
conversion on the 8088 side? This is something worth experimenting
with. Both CPU's have known speeds but they aren't synced together, so
it's a bit hard to do something like the fastloaders for C64+1541 which
relies on two CPU's running at almost the same speed, making it
possible to transfer data without handshaking all the time.

> > Btw this must be easy to check with an emulator.
> 
> What I did was to debug some programs using either DEBUG or patching
> my INT routines to output every call to the serial port. You can use
> DEBUG too in the emulator and it will be a bit faster, but otherwise
> I am not sure how to do it more efficiently (unless you patch and
> recompile an emulator like PCem to trap nad report CRTC port access).

Oh, I just assumed that you could set any breakpoint you'd want with
the emulators.


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