Re: BASIC for the CBM-II/8088

Den Wed, 18 Jul 2018 21:24:47 +0200 skrev Michał Pleban
<lists@michau.name>:
> Hello!
> 
> Mia Magnusson wrote:
> 
> > 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).
> 
> How about using a V20? It uses a symmetrical clock, so it might be
> easier to synchronize it with the 6509. It can also be clocked up to
> 20MHz, although I have no idea how the rest of the system would behave
> in such case.

Oh, I didn't know about that improvement of V20 over 8088. That would
make it easier. If running the V20 at 9MHz (half of the dot clock) it's
easy to sync it up with the 6509 using the wait state mechanism of the
V20. 9MHz would mean wasting wait states so it's effectively acting as
it is running at 8MHz though. Not sure which versions of V20 that's
easy to source today. If those faster than 8MHz are hard to source, it
might be better to use a PLL to generate a clock synced to the 6509
clock, and in that case the PLL might aswell generate a signal
compatible with an 8088 as well.

(Even though modern V20's support up to 20MHz back in the days I think
8MHz were a common version).

I also had a look at the Z80 specs. It uses a variable amount of clock
cycles (3-6) for each machine cycle, and you can add wait states at the
point it is writing or reading data (and it automatically adds a wait
state for the I/O instructions). It seems like the easiest way to run a
Z80 on a B machine would be to just clock the Z80 as fast as it
specified for, and add wait states where appropriate. There will always
be slowdowns running a Z80 on a 650x/680x bus. I'm not sure what Z80
(compatible) CPU's that's easy to source nowdays though.

Afaik V20 can rune some 8080/8085 software, but I'm not sure how
compatible it is. It surely can't run any Z80 specific software, but
might be good enough for running 8080/8085 compatible CP/M software?

Btw MS/PC-DOS and PC BIOS is a well known de-facto standard, but the
hardware differed on every CP/M-80 computer. Maybe it would be a good
idea to patch CP/M-80 to not use it's own file system code but directly
call the CBM disk drives? It might be slow as hell if CP/M supports
seeking but that would probably only affect some software and in worst
case it could be optimized using code that runs in the drive that reads
sector for sector until it has found the right position in a file,
without having to transfer it to the computer.

I think somewhere around DOS 3.x support for network started to appear.
I assume it would be a lot of work, but it would be kind of nice to
install the CBM Kernal API as a file system handler to DOS.

(Not sure how the 8088 card, with either your or the original BIOS,
handles character devices but I assume it would be trivial to add
support for printers and the rare IEEE-488 modem and IEEE-488<->rs232
converter boxes).

Imho it's a bummer that Commodore didn't add seek to their drives back
in the days. On a PET or B it might not had taken that much time to
actually read every data of a file until the right position is reached,
but on the serial drives it was a pain in the ass. Also they should
have abandoned the USR file stuff and just added a mode similar to USR
files but just using a map of the blocks of the file speeding up
seeking but otherwise transparent to the user/programmer.

> > 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 don't think anybody has ever tried using it on a P500 :-) It does
> not work on the 610 due to differences on the mainboard, but P500?
> Nobody knows at this point.

Oh, I assumed it was known to not work. (At least the original 8088
board).

As the P500 is rare itself, but as it afaik uses non-rare parts (except
for the triports and the CPU) I assume there isn't that much risk of
destroying expensive part by trying. Maybe we can convince someone here
on the list who has a P500? :)

> > 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.
> 
> A 5 MHz 8088 is only marginally faster than a 2 MHz 6509 - according
> to my rough calculations, by about 20-30% in such a task. And then,
> even when it does the PETSCII conversion, it cannot access the video
> memory so you need to engage the 6509 anyway to copy the converted
> data.

Yeah, I know. My idea was that the conversion might take about as much
longer time than a pure copy as the 8088 is faster than the 6509,
making them process each byte at about the same speed. It would take
some machine code programming with cycle counting to be able to
transfer a bunch of chars without handshake, but as it can be done
between a 1541 and a C64 it should be possible between the 8088 and the
6509 on a B :)



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