OSI + Gotek (youtube video)

[davisgw]

I have a slight correction to Danny's description of image 34. It boots on my C1p 600D and appears to be OS65U. Not sure what I would use it for...

Checking out the images on my 600D with the Gotek I noticed that Hexdos and Hexasm video do not correctly display 48 character lines. There is a gap of about 12 blanks between the first 24 characters and the remainder, even though ROM BASIC displays correctly. I have the video latch set in the monitor ROM so I assumed Hexdos would look correct because it uses the ROM BASIC video driver. I also have 0xFFE0, 0xFFE1 set to 0x4A and 0x3F...In one of the journals that describes this change it says to also change 0xFFE2 to 0x01 to note a different revision but when I changed that the system will not even display the boot prompt.
Somewhere I obtained a BASIC program for Hexdos named "Video48" and when I run that the 48 character lines are correct. It does a bunch of POKES which makes me think that Hexdos does not use the value in 0xFFE1 to determine the line length.
Anyone know any details to explain this behavior? I've attached the file.

[bxdanny]

The program you posted is the "Video Swap" program that OSI published. It was intended for use on the 600D (with the standard SYN600 ROM written for the 600B, which is how the systems were sold). Once loaded from tape on such a system, POKE 251,1 switches to 48-character mode, and POKE 251,0 switches back to 24-character mode. It's not compatible with Hexdos, or with Pico-Dos.

Hexdos does call the standard ROM video-output routine at $BF2D, unless it's running under CEGMON, but apparently it does a bunch of other stuff first with the character being output, including checking where on a line it is, and changing that under some circumstances, I'm not sure just how or why.

BTW, the third byte ($FFE2) of the video screen parameters in ROM is simply a flag, 0 for 1k or 1 for 2k of video RAM. So if it is set to 1, all output will be written to $D7 page instead of $D3 page.

[davisgw]

Danny,
Thanks for the info...you gave me just enough to dig further into this issue. First I verified that my ROM changes are not being ignored by Hexdos, but confirmed that this issue IS UNIQUE to running Hexdos on a 600D with 48 character mode active...it is not there running ROM BASIC. What I see on the screen is the first 24 characters, 7 or 8 blanks, then the remainder of the text. I tried changing 0xFFE1 value to 0x1F, 0x2F, and 0x3F and nothing helped improve the line display. So I started analyzing the Hexdos source code and discovered the following lines of code:

9390CKCURS LSR ROMDET <============ He checks the ROM version...mine is x01
9400 BCC RELDRG
9410 LDA $200
9420 AND #$1F
9430 CMP #$1D
9440 BCC RELDRG
9450 JSR $BFC2
9460 LDA $0200
9470 ADC #7 <================= I'm pretty sure this is causing the blanks in the middle of the screen
9480 STA $0200
9490 JSR $BFDE
9500 ;RESTORE REGISTERS
9510RELDRG LDA CHRTMP
9520 LDY TEMP4
9530 LDX TEMP3
9540 RTS

I don't understand what this is for but without changing the Hexdos code for the 600D I don't know how to fix it. But I suspect the code was written without consideration for the 600D 48 char mode. So from your previous comments about how to make VidSwap.bas compatible with Hexdos I added your changes to Video48.bas for the fix and it seems to work perfectly.
Any idea what Hexdos is attempting to do in this code? I'm reposting the corrected Video48.

[bxdanny]

davisgw,

Glad you found a solution that works. I think those spaces had to do with the editing capability Hexdos is supposed to have. According to page 6 of the Hexdos manual, typing something like

LIST 40<shift+return>

is supposed to bring up the specified line for editing, using <rubout> and <ESCape> to move left and right through the line, respectively. If the program line spans multiple screen lines, the video "guardbands" would have to be skipped over when moving from an earlier screen line within the program line to a later one. I think that's what those blank spaces are about. It's too bad Steve H. just assumed the screen dimensions would be the standard ones, instead of looking at the ROM parameters to see what they are. As it is, that editing won't work with anything but the standard 24 x 24 screen.

BTW, what version of 65U was on nama's disk #34? OSIHFE and WinOSI can't read anything from it except all 00 bytes, but I guess the Gotek firmware can.

[bxdanny]

davisgw,
I figured out a way to make a compatible version of the Hexdos disk that will boot and support editing on systems with various video configurations.

1) Boot the system from a COPY of your good Hexdos master. Press <return> at the INPUT prompt.

2) Type NEW to get rid of the existing auto-run program. (There's not enough room for both it and the one you will be adding.)

3) Type in the following three-line BASIC program (ignore the extra displayed spaces for now):

10 V1=PEEK(65504):V2=PEEK(65505)
20 IFV1>31THENPOKE2569,63:POKE2581,15:POKE2310,15
30 POKE2303,V1AND31:POKE2571,(V1AND31)+V2+1

4) Type SAVE#0,768 to write the system to disk with the new auto-run program.

Now reboot, and the system should boot and run with a correct, editable display. It won't show the directory on boot, but I think you can live without that.

[bxdanny]

No, editing is still not perfect with what I posted in the last message. And the display is good for 24- and 48-character lines, but not other widths. I hope to post a better and more general version soon.

[bxdanny]

OK, here is the corrected Hexdos Autostart program for correct display and editing on all systems Hexdos runs on:

10 V1=PEEK(65504):V2=PEEK(65505):M=30
20 IFV2>31THENPOKE2569,63:POKE2301,63:M=62
25 POKE2581,M-V2:POKE2310,M-V2
30 POKE2303,V1AND31:POKE2571,(V1AND31)+V2+1

[davisgw]

Danny,
I don't understand what you are doing in statement 25....I get a BASIC FC error because PEEK(65504)=68 and PEEK(65505)=63 so M-V2 results in a -1 which is out of range for the POKEs. Tell me what you expected to happen.

To your prior question, the version of 65U was on nama's disk #34 is V1.44.

[bxdanny]

I thought PEEK(65505) would be 47 (indicating a line length of 48), so M-V2 would be 62-47=15.
[Edit: Or was this on the other system? You could try changing the expression M-V2 to (M-V2)AND255.]

The first (three-line) version of the program was missing the POKE to 2301, so the cursor would jump backward by (I think) 16 characters when backspacing with <rubout> through the first screen line of a program line. It really just needs that added (POKE 2301,63 if V2>31) to work with your 600D. [The preceding sentence was edited.] But remember to start with an unmodified version of Hexdos in order to remain compatible with a standard 600B.

++

[davisgw]

Danny,
Thanks a bunch! Since both my 600D and my 600B (s-100) systems would stutter on the screen when I entered your program I had decided to break up the statements to be about 24 characters, but I think that made the program too big to be stored to track 0 without corruption. So knowing the values you wanted to POKE, and the values from my ROMs I removed all the conditionals and POKEd the correct values to 2568. 2301, 2581, 2310, 2303, and 2571. It works perfectly on both systems! But when I tried to save it to track 0 on the Gotek it corrupted the image so I had to transfer a floppy image with track 0 already modified.
I have not tested it extensively but I saw no stuttering or blanks and RUB OUT also works. So can I assume you dug into the Hexdos source code to come up with this fix? Great job!!!
Glenn