osiweb.org

Hi Glenn,

Glenn is actually my middle name: I'm Daniel Glenn Schwartz.

Anyway, I'm glad you got your board working with 65D. Did I understand you to say that it produces only 10 lines of output? Why that would be, I don't know. Maybe they are just using large vertical "guardbands".

Anyway, I decoded your new driver as follows: Reading the $D400 status port twice seems pointless, as does the DEY instruction, since it will always make Y equal to $FE, and loop back to $E327, where Y will be read again from the port. In fact, it looks like everything from $E327 through $E330 could have been replaced with the single instruction BEQ $E420. But actually, based on the partial copy of the board's manual that you posted, and what the handwritten code you posted earlier contained, I suspect that the only bit in $D400 that matters here is bit 7, and that the other bits are just defaulting to all ones, meaning the only values ever read from the $D400 status port will be $FF or $7F. If this is accurate, than the driver could be reduced to This would avoid the need to change the value of the Y register.

Hi Glenn,

I read the $D400 status the first time to see if it's OK to write to $D401 without doing a delay. The second status read is in the delay loop to exit when the status returns to $BF, which means the Rx buffer is empty....$FF means it is full. The DEY is a mistake that made it work because the loop did not provide enough delay and since I wanted it small I decided to leave it as is for now. Your short and sweet code would cause a forever loop because the bit you are testing would never change, but it's short and sweet for sure. And assuming the bits are 7 to 0 then the bit to test is bit 6, verified with the extended monitor and test code I ran to read the status before and after a write to $D401.

Anyway thanks for the suggestion. Look over my source code and see if you can explain why setting the OS65D vector to $E000 ($DFFF) does not work properly, since we now know that page 2 corruption is not happening. Also, can you explain why the dumps from OS65D contained no carriage returns with my short driver? And why the ROM dumps from BASIC-IN-ROM had each line of ASCII translated hex followed by something like "########cr" (which I removed on the PC)? I don't know what hex value produced the ######## though. Thanks for any clues.

Well, if the bit to watch is bit 6, then my "short and sweet" driver could work by just changing one byte (the fourth) from $30 (BMI) to $70 (BVS). But I guess explicitly checking for $FF has the advantage that, if the board is not present for whatever reason, calling the driver will not hang the system, since LDA $D400 will then return a value of $D4, which is not $FF but does have bit 6 set.

But calling your driver, which alters the Y register, directly from the 65D output distributor (i.e. putting its address less one into the table of driver addresses) won't work because drivers called that way are expected to preserve the values of A, X, and Y. If your CPU was a 65C02 you could surround the driver with PHY and PLY, but those instructions don't exist on standard NMOS 6502s. But there exists an unused driver in 65D (device 3) which can easily be modified to service your video board. For example, if you add the following lines to BEXEC* on an (otherwise) unmodified copy of Tutorial Disk 5, output to your board will be available via PRINT#3:

6 POKE 9487, 0-POKE 9488,212: REM (LDA) $D400
7 POKE 9489,112: REM BVS
8 POKE 9493,1:POKE 9494,212: REM (STA) $D401

POKE 8994,6 could then set the output distributor to output to both devices 2 and 3 (both screens), until the next error message, STOP or control-C BREAK.

You could also swap which screen is device 2 and which is device 3, while keeping device 2 pausable with control-S, by using the following POKEs:

POKE 13008,13:POKE 13009,37
POKE 8981,191-POKE 8982,51

You could add those lines to BEXEC* as lines 30 and 35.

Your old driver (at $E000) looks like it was kind of complicated. I don't know just what was happening, but I do see that it was explicitly checking for carriage returns and linefeeds, among other things.

My old driver is complicated because the BASIC-IN-ROM was sending carriage returns for lots of random reasons not needed/desired for my card to display the text correctly. I will try preserving A, X, and Y for both drivers and see if the problems are fixed. Thanks for the suggestions.

Is device 3 allocated to anything I care about? Does it make any sense to output to both screens with 65D. Interestingly HEXDOS seems completely happy with my driver.

... And why the ROM dumps from BASIC-IN-ROM had each line of ASCII translated hex followed by something like "########cr" (which I removed on the PC)? I don't know what hex value produced the ######## though. Thanks for any clues.

So when SAVING with BASIC-IN-ROM the output routine adds 10 NULs (0s) after each carriage return. I believe this was done to give BASIC more time to tokenize lines when reloading saved programs. So what you end up with is <CR><10 nulls><LF> on each line.

If you need a way to dump things without the NULS see the 3rd message in this thread. It writes <CR> to the serial port directly bypassing the BASIC output routines.

Here is a list of OS65D devices. Device #3 is normally used for S1883 UART on OSI 430 board @FB03

OSI OS65D devices for BASIC PRINT#, LIST#
#1 - ACIA Serial port on C1, C2, C4,C8 ($FC00/$F000 on C1) In & Out
#2 - Video OSI540 (output) / Polled Keyboard (input)
#3 - UART Serial port on some modified 430 boards $FB03 (S1883 UART) In & Out
#4 - Centronics parallel port on 65D (null input) $F400
#5 - Memory I/O
#6 - Disk1
#7 - Disk2
#8 - CA-10X Serial RS-232 on 550 boards, 16 possible ($CF00, $CF02, ... $CF1E
#9 - Null

Using OS65D IO command you can choose a singe input and multiple output devices at a time.
IO NN,MM Changes the Input I/O distributor flag to "NN", and the Output pointer to "MM".
IO ,MM Changes only the output flag.
IO NN Changes only the input flag.
So DISK!"IO ,06" would direct OS65D to screen and device#3 until an error or break was encountered as Daniel stated earlier.
DISK!"IO ,03" will send to screen and serial port.

-Mark

Glenn,

I now realize that I made an error in my suggested changes to the Device 3 driver to support your video board. LDA does not affect the Overflow flag, so what I posted wouldn't work. BIT does put bit 6 of the addressed location into the overflow flag. So the suggested line 6 should really be


6 POKE 9486,44:POKE 9487, 0:POKE 9488,212: REM BIT $D400

-Danny

Mark, I see now why my BASIC-IN-ROM driver looks so complicated. And I guess I was thinking the INPUT device list is the OUTPUT device list. That makes more sense. Do you know how to switch the Rev D Superboard out of 64 character line mode, since $D800 is a read only register?

Danny, Thanks for the 65D tips. I will try modifying my ROM driver tomorrow to preserve the Y register and see if that fixes it completely.

And just to add to my embarassment, I noticed today that I already dumped the ePROMS from this system back in February....so I guess practice makes perfect ;-(

The information I have says
OSI 600D has a write-only 74LS174 latch U72 at $D800 / 55296 which controls the following:
Bit 0 controls screen mode 1=64x16 (~48x12 visible) 0=32x32 (~24x24 visible)
Bit 1 = color enable (when using OSI630)
Bit 2 = BK0 (unused)
Bit 3 = BK1 (unused)
Bit 4 = DAC disable
Bit 5 = nc

Besides setting the bit, you also need to adjust the screen driver to handle the different memory configurations. Steve Gray has modified the CEGMON bios with additional commands to do this for BASIC-In-ROM use. See https://github.com/sjgray/OSI-monitor-roms There are some threads in this forum on the changes. There is also a OS65D disk image that may help: "C1P-VIDSwap.65D" at https://osi.marks-lab.com/software/osios5.html

-Mark

Thanks again Mark, I will look into these updates when I get a chance to look at the Rev D Superboards again.

Danny, I coded changes to preserve the Y register in my 65D driver and then dumped one of the source code files to my PC. There are still no carriage returns in the dump. So even though that is the right thing to do it did not seem to help, but the storage where I saved the Y register contains a $10. To dump the source code I entered !IO ,03 and PRINT. Is that not the right set of ASM commands to dump the source code?

Here is the source code dump I took.