VOGONS


Reply 60 of 134, by keropi

User metadata
Rank l33t++
Rank
l33t++
FreddyV wrote on 2020-12-08, 11:56:
Hi, […]
Show full quote

Hi,

Thanks for all this,

I am interested to disassemble the PC1512 driver and optimize it, I may take a look and optimize these drivers as well, I see plenty of speed improvement that can be done 😀
(As You know, the PC1512 video is slow)
Is there any of these video mode supported by DOSBox ?

FreddyV

PCem supports the PC1512 and it's video hardware - so you can use that for testing , that's what I also use to test things and so far the emulator and real machive produce the same results.

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 62 of 134, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie
FreddyV wrote on 2020-12-08, 11:56:

I am interested to disassemble the PC1512 driver and optimize it, I may take a look and optimize these drivers as well, I see plenty of speed improvement that can be done 😀
(As You know, the PC1512 video is slow)
Is there any of these video mode supported by DOSBox ?

As keropi already said, use PCem! It is almost perfect for this kind of task.
However, you will need a convenient way to edit disk images. I'm using mtools.

If you already consider optimizing my code, as well, you could also try to write your own open source PC1512 driver and skip the disassembly process, entirely.
The Color 400 driver would be a good starting point. If you swap out the initialization and plane switching code, you should already get a picture, albeit with the wrong colors.
Then use two pixel format LUTs instead of one and four planes instead of two and you have a PC1512 driver!

To speed things up beyond code optimization, one could leave the intensity plane alone and create the 16 colors via dithering, instead, thanks to the pixel doubling.
It would not be ideal, but faster.

NewRisingSun wrote on 2020-12-08, 15:00:

You may denote in your github readme that the Tandy640 driver was written by me.

I'll put it in the next revamp of the readme. The existing "See Also" section is basically a dump of my bookmarks.
With a growing number of drivers, whether in the repository or linked, some sort of tabular layout with all the relevant information would look much cleaner.

Incidentally, I also discovered another Plantronics SCI driver on the web!
We have been wondering why nobody had written this kind of driver 30 years ago, earlier in this thread.
As it turns out someone had in fact written/modded a driver for Plantronics video, but had not published the result until 2019, namely in this PCem forum thread.
I have posted there a couple of weeks ago, but have not gotten an answer, yet.

Reply 63 of 134, by FreddyV

User metadata
Rank Oldbie
Rank
Oldbie

Hi,

I started to disassemble the driver, this is fast to do anyway...

So I confirm, there are four plane, for R, V, B and I.
8 Pixel per Byte and a registry to write for each plan change.
Also, duplicate the pixels as the Amstrad output is 640*200.

The current driver is doing a good job, and is really close to the Color 400 code actually 😀
The Mouse part can be optimized, as it integrate a code to compute some variables and this one is called too often.

It may be really difficult to improve the rectangle draw code...

Actually, optimize/Speed up the color plus driver is more simple than optimizing the PC1512 one.

Reply 64 of 134, by root42

User metadata
Rank l33t
Rank
l33t
FreddyV wrote on 2020-12-11, 09:25:

So I confirm, there are four plane, for R, V, B and I.

V=vert=green? Other than that: Good job, interesting to know!

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 67 of 134, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie
FreddyV wrote on 2020-12-11, 09:25:

So I confirm, there are four plane, for R, V, B and I.
8 Pixel per Byte and a registry to write for each plan change.
Also, duplicate the pixels as the Amstrad output is 640*200.

Yeah. That is really the only extra video mode the PC1512 supports.

FreddyV wrote on 2020-12-11, 09:25:
The current driver is doing a good job, and is really close to the Color 400 code actually :) The Mouse part can be optimized, a […]
Show full quote

The current driver is doing a good job, and is really close to the Color 400 code actually 😀
The Mouse part can be optimized, as it integrate a code to compute some variables and this one is called too often.

It may be really difficult to improve the rectangle draw code...

Actually, optimize/Speed up the color plus driver is more simple than optimizing the PC1512 one.

That's an interesting assessment. The Color 400 driver is a derivative of the Plantronics driver without further optimizations.
If the Color 400 driver is really close to the PC1512 driver that can hardly be improved any further, I'm genuinely interested in your optimizations.

FreddyV wrote on 2020-12-11, 17:42:

I don't know how to add an XT IDE on the PC1512 in PCem.
We can select only MFM and some SCSI devices....

Weird. That is supposed to work. Do you have the XT-IDE ROM file?

Reply 69 of 134, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie

Yes, you can, but not in a PC1512.
Just create a generic XT with the same hard drive and a Plantronics card!
The Color 400 option ROM does not work smoothly with every BIOS, so you might have to try a few configurations if you want to experiment with that driver, as well.

Reply 70 of 134, by FreddyV

User metadata
Rank Oldbie
Rank
Oldbie

Example showing the drivers are "the same":

PC1512:
hide_cursor proc near

pushf
cli
dec ds:Cursor_Counter
jnz short hide_SkipRestore
call restore_background

hide_SkipRestore: ; CODE XREF: hide_cursor+6↑j
mov ax, ds:Cursor_Counter
popf
retn
hide_cursor endp

PCPlus:

hide_cursor:
; hard synchronization
pushf
cli

dec word [cursor_counter]
jnz .skip
call restore_background

.skip: popf

ret

Reply 71 of 134, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie

With some of the driver functions I had to switch back and forth between rewritten code and disassembly to make sure that they are not identical by accident.

Seriously, how many sensible ways to manage a cursor visibility counter are there?
API and ABI are fixed after all.

Reply 73 of 134, by FreddyV

User metadata
Rank Oldbie
Rank
Oldbie

I don't know how to do auto modified code with NASM,

I want to do this it does not work:

mov cs [.AddLine-2],ax

add si,160
.AddLine:

It give this error:
pcplus2.s:280: error: expected `,'

But this is probably a bad idea as it seems that the rectanglmedraw function can be called even if running (Interrupt) ?

Reply 74 of 134, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie

NASM expects the prefix within the square brackets and with a colon as separator.

Rewriting the offending line of code like this should work:

mov     [cs:.AddLine-2],ax

But I'm not sure about self-modifying code in a dynamically loaded driver.

Reply 75 of 134, by carlostex

User metadata
Rank l33t
Rank
l33t

Fantastic work Benedikt!!

I've been wondering about this Sierra driver hacking too, but i was thinking more of Sound drivers instead.
Maybe derive from the 3 voice Tandy driver to create a Renovation SSI, SID card replica driver.

Reply 76 of 134, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie

I've thought about audio drivers, as well, but it does not have the highest priority, right now.
Anyway, Ravi's Sound Drivers (also LGPL) would then be a good starting point.

Reply 77 of 134, by FreddyV

User metadata
Rank Oldbie
Rank
Oldbie

Hi,

Here is the optimisation I did, It surely do not speed it up a lot, but better than nothing 😀

Attachments

  • Filename
    pcplus2.zip
    File size
    5.88 KiB
    Downloads
    70 downloads
    File license
    Public domain

Reply 78 of 134, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie

Your changes mostly relate to the memory offset calculations for the scan lines, right?
I think that the fastest and most portable technique would use another lookup table, but I'm not entirely sure.