ronin47,
[Replying to your most recent message]
The standard values for $FFE0-$FFE2 are 65 17 00 for 24-column mode and 4B 2F 00 for 48-column mode. You were getting cut-off characters with those settings on the monitor I thought you wanted to use, so I adjusted them for you to work better with it. The "standard" ones are best for most monitors (I think), but if different monitors give different results, you aren't going to find one set of values that will work on any monitor. In the Monitor program (I'll use a capital M for the program and a small m for the screen - the double meaning of "monitor" can get confusing) there isn't just one byte that would adjust everything. The main value for where on $D0 page the address data begins is at $FED6, but you would also have to set $FEC4 to be four more than that, and $FEC7 to be five more than it, otherwise the spaces between the address and data displays will not be blank spaces.
------------------------
[replying to your previous message]
I agree, color should not be the priority. Getting a 610 and floppy drive sounds like it would be more useful. But after reading the discussion about color options, I did come up with an idea of my own for one. Yes, it involves another ROM, but not as the Monitor. Not in the CPU address space at all, but rather as the only component that (I think) would be needed to interface the board (via J75) to an RGBI (CGA-type) monitor. It would act as a lookup table to generate the RGBI signals from the monochrome video, color enable line, and four bits of color data. I present the lookup table below. [All the interesting data is in the second half (COLOR EN high); with COLOR EN low, the monochrome VID value is simply passed on to each of the four RGBI inputs of the monitor.]
Code: Select all
Input bits (Address lines) Output bits (data lines)
-------------------------------- -----------------------------
5 4 3 2 1 0 3 2 1 0
Color Vid CD3 CD2 CD1 CD0 Int B G R
En (B) (G) (R) (Inv)
-------------------------------- -----------------------------
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 0 0 0 0
0 0 0 0 1 0 0 0 0 0
0 0 0 0 1 1 0 0 0 0
0 0 0 1 0 0 0 0 0 0
0 0 0 1 0 1 0 0 0 0
0 0 0 1 1 0 0 0 0 0
0 0 0 1 1 1 0 0 0 0
0 0 1 0 0 0 0 0 0 0
0 0 1 0 0 1 0 0 0 0
0 0 1 0 1 0 0 0 0 0
0 0 1 0 1 1 0 0 0 0
0 0 1 1 0 0 0 0 0 0
0 0 1 1 0 1 0 0 0 0
0 0 1 1 1 0 0 0 0 0
0 0 1 1 1 1 0 0 0 0
0 1 0 0 0 0 1 1 1 1
0 1 0 0 0 1 1 1 1 1
0 1 0 0 1 0 1 1 1 1
0 1 0 0 1 1 1 1 1 1
0 1 0 1 0 0 1 1 1 1
0 1 0 1 0 1 1 1 1 1
0 1 0 1 1 0 1 1 1 1
0 1 0 1 1 1 1 1 1 1
0 1 1 0 0 0 1 1 1 1
0 1 1 0 0 1 1 1 1 1
0 1 1 0 1 0 1 1 1 1
0 1 1 0 1 1 1 1 1 1
0 1 1 1 0 0 1 1 1 1
0 1 1 1 0 1 1 1 1 1
0 1 1 1 1 0 1 1 1 1
0 1 1 1 1 1 1 1 1 1
1 0 0 0 0 0 0 0 0 0
1 0 0 0 0 1 1 0 1 1
1 0 0 0 1 0 0 0 0 0
1 0 0 0 1 1 1 0 0 1
1 0 0 1 0 0 0 0 0 0
1 0 0 1 0 1 1 0 1 0
1 0 0 1 1 0 0 0 0 0
1 0 0 1 1 1 0 0 1 1
1 0 1 0 0 0 0 0 0 0
1 0 1 0 0 1 1 1 0 0
1 0 1 0 1 0 0 0 0 0
1 0 1 0 1 1 1 1 0 1
1 0 1 1 0 0 0 0 0 0
1 0 1 1 0 1 1 1 1 0
1 0 1 1 1 0 0 0 0 0
1 0 1 1 1 1 1 1 1 1
1 1 0 0 0 0 1 0 1 1
1 1 0 0 0 1 0 0 0 0
1 1 0 0 1 0 1 0 0 1
1 1 0 0 1 1 0 0 0 0
1 1 0 1 0 0 1 0 1 0
1 1 0 1 0 1 0 0 0 0
1 1 0 1 1 0 0 0 1 1
1 1 0 1 1 1 0 0 0 0
1 1 1 0 0 0 1 1 0 0
1 1 1 0 0 1 0 0 0 0
1 1 1 0 1 0 1 1 0 1
1 1 1 0 1 1 0 0 0 0
1 1 1 1 0 0 1 1 1 0
1 1 1 1 0 1 0 0 0 0
1 1 1 1 1 0 1 1 1 1
1 1 1 1 1 1 0 0 0 0
The one odd thing about OSI's color scheme is the use of color 0 to mean yellow. So with all bits of color data at 0, but VID at 1, the RG and I outputs will be on. [I am setting the Intensity bit on for all (non-blank) output except color 4, which OSI calls Olive Green, but I equate with brown, and which CGA monitors handled specially, producing brown instead of low-intensity yellow. I am equating Sky Blue to cyan, and Purple to magenta.]
The inputs to a CGA monitor [if you can find one] are ground to pins 1 and 2, RGB and I to pins 3 through 6 respectively, HSync to 8 and VSync to 9, with 7 left unconnected ("Reserved"), all TTL levels as far as I can tell. Anyone want to comment on how well this would work?
As for the data separator, Klyball [who makes the boards] can probably answer the question best. But basically, yes, you will need one unless you have an original MPI drive that had the data separator (of a different sort) mounted internally. As I understand it, Klyball's data separator is part of the "paddleboard" interface between the 610 and the drive, and not a separate piece.
Finally, for when you are ready, or for anyone else who wants to use the mod I started this thread with in conjunction with a disk system, I present some operating system disks that will take account of which video mode is active (i.e. of the video parameters starting at $FFE0). They are a version of Hexdos (the auto-run program, which erases itself when done, does the adjustments), a version of 65D 3.2 (with a modified BASIC containing some additions and bug fixes), and a version of my own Enhanced Pico-Dos (the only difference from the 1.40 version in that system's thread is that you can warm start it after switching video modes [i.e. do <Break>SW], with or without the Editor loaded, and continue working).
Note: To make an HFE file of the Hexdos disk, for use with the Gotek drive, you need to include the -5 option on the OSIHFE command line, otherwise the resulting file won't work. This applies to all images of Hexdos disks.
