OS65D V3.3 with Cegmon

[bartleph]

I wonder if anyone can assist me in finding the locations to change in OS65D V3.3 in order for it to use the full 2k of my screen. Booting into ROM basic via 'C' uses the full screen and scrolls as it should. The M/C Monitor, via 'M' also works fine, but if I boot to the Disk OS, it will only use the top 1k of memory and fills the bottom 1k ($D400-$D7FF) with $E0 ( a little house graphic). 'AS', 'EM' and 'BA' all experience the same, so I'm guessing it has to be settings in the Disk OS Kernel. Any assistance would be greatly appreciated.

[bxdanny]

It's the video driver in the OS, yes. Can you first describe exactly the size of your screen? Is it 64 characters across, or are only 48 characters visible? If there are less than 64 characters visible across, what are the contents of $FFE0 and $FFE1 in your ROM? Is there a register that switches the screen to show fewer, larger characters across? Is there any sort of color support? (I expect there is not, but just checking.)

If the screen is basically like a 540 screen, it will be a matter of combining the video-out part of the C4P version with other parts (keyboard and ACIA) of the C1P version. I don't have a version like that, nor do I know offhand what locations would need to be changed to create it. Or a version for a 2k screen that is not the full 64 characters wide. I will look into what it takes to create a 3.3 version for your configuration when I have a fuller description of it. If anyone else has created a 3.3 version for any C1-expanded-to-2k-video configuration, please post it.

Meanwhile, I have already posted (in the second message of the thread "Superboard Expanded on S-100 motherboard") a version of 65D 3.2 that should work with your system, by adjusting its video driver to match the parameters in ROM. And Hexdos, as well as my Enhanced Pico-Dos, should also work.

[bartleph]

Hello and thank you for your reply,
My screen shows all 32x64 characters. I have a modified version of OS65D V3.1 which works fine, but I would like to use 3.3 preferably.
$FFE0=$4D
$FFE1=$3F
$FFE2=$01

TIA

[bxdanny]

bartleph,

Here is a version of OS-65D 3.3 that should work with your system. It is a modified copy of the C4P version of Tutorial Disk 5. I initially tried to make it compatible with either a C4P or your system, but that turned out not to be readily doable, so it is specific to a system like yours.

[bartleph]

Thanks Danny, That looks pretty good to me. I only see 24 rows, not the full 32. I think 4 are missing from both top and bottom. Basic and Extended Monitor (from Disk) scroll in that 24 row window.
Do you have the modified Code as an Assembler listing, or could you point me to the relevant locations you changed??

Many Thanks for this.
Paul

[bxdanny]

Yes, only 24 rows are displayed, emulating a Hazeltine terminal.

Almost all the changes I made are performed by code that loads to $2EDC during boot, loaded from Track 1, Sector 1. To look at that, you can do the following:

EXIT
CA 4A00=01,1
EM
Q4EDC

I was originally trying to make the disk very general, supporting a normal C4P, in addition to your modified C1P/Superboard, and even a hypothetical 5.25" serial system (although I've been told that at least one such system once existed, at the receptionist's desk at the OSI factory). So some of the code there is checking for those possibilities. But I wound up having to give up that generality, as I will explain.

Here are the changes that had to be made to the standard C4P OS:

1) Change the ACIA address from $FC00/FC01 to $F000/F001. This simply means changing five bytes from $FC to $F0, namely at $24D0, $24D8, $24DC, $24F8, and $2501.

2) Change keyboard port reads and writes to invert the values before writing, and after reading. The 3.3 keyboard driver was written with this option in mind. So all that was necessary was to change the values at $3650 and $365B (operands of EOR immediate) from $00 to $FF.

3) Change the Control-C check to also use inverted keyboard values. This is the most involved of the three, since it involves not a simple read or write, but a BIT of the keyboard port, which must return non-inverted values while leaving the accumulator unchanged. The C1P version of the OS contains a routine a $249F to accomplish this, which replaces the parallel printer (Device #4) output routine. (Actually, it extends two bytes beyond the space that was occupied by that routine, overwriting the start of the Device #8 (CA-10X/550 board) input routine. So I made a call to Device #8 input RTS immediately by changing the value at $230F. I could have shortened the BIT patch by two bytes by replacing LDA $DF00/EOR #$FF with JSR $FCCF, but I figured it was better not to add even 12 cycles to something that would be executed after every BASIC statement.) Anyway, a JMP $249F is placed at $263D, which on the 4P simply contains STA $DF00, followed by BIT $DF00/RTS.

Oh yeah, I changed the "RE M" code to use a simple JMP $FE00, rather than JMP ($FEFC), so that it can work with CEGMON. But it really shouldn't be used, because CEGMON's monitor overwrites a good chunk of page 2, which will wipe out part of BASIC's table of keyword dispatch addresses (or part of the Assembler). And speaking of the Assembler, one instruction there needed to be changed. A copy of the original seven-byte routine at $263D could be found at $156D in the Assembler, called from $1562. So the instruction at $1562 was changed to JSR $263D.

Just one instruction was changed on Track 0, the instruction at $2214 was changed from JSR $2E79 to JSR $2EDC. (BTW, the copy of the Track 0 R/W utility on Track 39 in the pseudo-file COMPAR may be damaged. Sometimes it works, and sometimes it generates odd error messages, like ERR #6, and causes subsequent disk I/O attempts to generate similar messages.)

So why did I say that the attempt to make the disk compatible with several types of system failed? Because, after the keyboard code at $364F is patched to have $FF as the operand of those EOR instructions, it gets loaded again from Track 13, which was setting those operands back to $00. So I patched it directly on Track 13, making the disk incompatible with the C4P.

[bartleph]

Wow Danny!!
Thank you so much...a) for doing the work in the first place, and 2) for such a detailed explanation of what needed to be done. It's getting late here in the UK at the moment, so I will have to look more deeply at my OS65D3.3 Assembly listing with a view to making some changes tomorrow. Again, Many Thanks for your replies.
KRs
Paul

[bxdanny]

Paul,

Where did you get an assembly listing for 65D 3.3? Is it something that's been posted here before? If not, can you post it?

Anyway, after looking over the description I posted about creating the 3.3 disk for you, I realized that (while the disk will work fine) I had made a somewhat foolish mistake when I said that the keyboard driver was loaded "again" from Track 13. That's where it's loaded from, period. The $00-to-$FF
changes done by the code I put on Track 1 were actually writing to memory that hadn't been loaded yet, and simply contained the code left in place from a previous boot. I should have let the code at $2E79 finish loading the OS first, and then applied my patches. Once I understood that, i was able to make the compatible version I originally intended. This version and the previous one will both work fine on your system, producing the same end result when booted, but the way this version achieves that result is a little more sensible.

[bartleph]

Thanks Danny. I'll make a disk and give it a go..

[bxdanny]

Thanks for those files. I probably did have them, if they are from Mark's site, but had forgotten about them.

For whatever reason, lines in them are terminated with line feed only. I found that opening them in Wordpad and resaving them as text converts the linefeeds to CRLF pairs, and makes the resulting files readable in Notepad.