600D ROM support for both 24- and 48-character modes

[Steve Gray]

Well, the clock is about 4MHz, so you need 250ns or faster EPROM. There are 70ns EPROMS in DIP so you' will probably be ok. Luckily the 600 is pretty low resolution. Video timing is always tricky. It's worth trying though.

Steve

[bxdanny]

Steve Grey, ronin17,

I guess i was thinking more as a programmer and not as an engineer (which I'm not), neglecting the fact that EPROMs don't respond instantly. So I no longer think that the design I had in mind would work as is. The dot clock in 48-character mode is 8 MHz (the 4 MHz crystal frequency gets doubled), but even if the EPROM responded within the necessary 125 ns, there would still be time during which its outputs had not stabilized, which would produce odd color effects on the screen. I guess the output at the end of each cycle could be latched until the next cycle though. That could be done by adding another 74LS174 hex D flip-flop after the EPROM, right? There are 150 ns 27C16 chips available at https://www.hinkel-elektronik.com/cgi-b ... t&nr=74682, and there is probably some margin of error in the timing spec, so they may give a stable output after 125 ns. There are also 120 ns 27C256 chips available from Hinkel, but at a considerably higher price.

I worked last night at creating a schematic of sorts for what I had in mind, using ASCII characters, and this is what I came up with:

Code: Select all

U77 pin 14 or J75 pin 1       (CD0)     ->          ------
_____________________________________________ pin 8|A0  D0|pin 9       (R)       ->     DE-9F pin 3
                                                   |      |________________________________________
                                                   |      |
U77 pin 13 or J75 pin 16      (CD1)     ->         |      |
_____________________________________________ pin 7|A1  D1|pin 10      (G)       ->     DE-9F pin 4
                                                   |      |________________________________________
                                                   |      |
U77 pin 12 or J75 pin 2       (CD2)     ->         |      |
_____________________________________________ pin 6|A2  D2|pin 11      (B)       ->     DE-9F pin 5
                                                   |      |________________________________________
                                                   | 2716 |
U77 pin 11 or J75 pin 15      (CD3)     ->         |      |
_____________________________________________ pin 5|A3  D3|pin 13      (I)       ->     DE-9F pin 6
                                                   |      |________________________________________
                                                   |      |
U42 pin 9 or J75 pin 10       (VID)     ->         |      |
_____________________________________________ pin 4|A4    |pin 18->GND          GND  >- DE-9F pin 1
                                                   |      |                     ___________________
                                                   |      |pin 20->GND
U72 pin 5 or J75 pin 13     (COLOR EN)  ->         |      |
_____________________________________________ pin 3|A5    |pin 21->+5V          GND  >- DE-9F pin 2
                                                   |      |                     ___________________
                                                    ------ 

U65 pin 5                     (HS)                    ->          (HSYNC)               DE-9F pin 8
___________________________________________________________________________________________________


U65 pin 13                    (VS)                    ->          (VSYNC)               DE-9F pin 9
___________________________________________________________________________________________________

But as I said, I no longer think that this would really work.

The ROM contents would simply have been 32 repetitions of the following:

Code: Select all

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F
00 0E 00 0C 00 0A 00 06 00 09 00 0D 00 0B 00 0F
0E 00 0C 00 0A 00 06 00 09 00 0D 00 0B 00 0F 00

ronin, good luck with the cassette sound output. I'm not going to deal with that today. Others may be more likely to figure it out. If no one does in the next day or two, I'll take another look.

[Steve Gray]

Yes, you could latch the output. The 630 board does that, as does my board. Also be aware that colour monitors have different sync than monochrome. I can never remember but one (I think v-sync) needs to be inverted. So you could add an inverter, or you could have fed the sync line(s) into the eprom. You could still have issues with sync timing etc. You can get 70 ns PLCC EEPROMS (Winbond W27C0x0) which might work. I don't know.

The other option is just to copy the video section of the 630 board As you add chips to your own design you might find the 630 implementation is not that bad.

I actually had a similar idea for the C128 to change the RGBI output to various different 8-bit colour palettes (using a resistor DAC). I also thought about an EPROM at the time. Then I thought I'd use a DUAL PORT SRAM that was mapped into the CPU space so you could change the palette on the fly. Then I looked into different video RAMDAC chips.... So many ideas Of course, I never tried it, but it would have been a fun project.

One of the things I liked about the OSI machines was all the different user-designed video mods there were, and how easy it was to hack things onto them. I think adding guard-bands and having 32/64 columns would be a good mod to try on a colour 600D!

Steve

[ronin47]

Steve Grey, ronin17,

I guess i was thinking more as a programmer and not as an engineer (which I'm not), neglecting the fact that EPROMs don't respond instantly. So I no longer think that the design I had in mind would work as is. The dot clock in 48-character mode is 8 MHz (the 4 MHz crystal frequency gets doubled), but even if the EPROM responded within the necessary 125 ns, there would still be time during which its outputs had not stabilized, which would produce odd color effects on the screen. I guess the output at the end of each cycle could be latched until the next cycle though. That could be done by adding another 74LS174 hex D flip-flop after the EPROM, right? There are 150 ns 27C16 chips available at https://www.hinkel-elektronik.com/cgi-b ... t&nr=74682, and there is probably some margin of error in the timing spec, so they may give a stable output after 125 ns. There are also 120 ns 27C256 chips available from Hinkel, but at a considerably higher price.

I worked last night at creating a schematic of sorts for what I had in mind, using ASCII characters, and this is what I came up with:

Code: Select all

U77 pin 14 or J75 pin 1       (CD0)     ->          ------
_____________________________________________ pin 8|A0  D0|pin 9       (R)       ->     DE-9F pin 3
                                                   |      |________________________________________
                                                   |      |
U77 pin 13 or J75 pin 16      (CD1)     ->         |      |
_____________________________________________ pin 7|A1  D1|pin 10      (G)       ->     DE-9F pin 4
                                                   |      |________________________________________
                                                   |      |
U77 pin 12 or J75 pin 2       (CD2)     ->         |      |
_____________________________________________ pin 6|A2  D2|pin 11      (B)       ->     DE-9F pin 5
                                                   |      |________________________________________
                                                   | 2716 |
U77 pin 11 or J75 pin 15      (CD3)     ->         |      |
_____________________________________________ pin 5|A3  D3|pin 13      (I)       ->     DE-9F pin 6
                                                   |      |________________________________________
                                                   |      |
U42 pin 9 or J75 pin 10       (VID)     ->         |      |
_____________________________________________ pin 4|A4    |pin 18->GND          GND  >- DE-9F pin 1
                                                   |      |                     ___________________
                                                   |      |pin 20->GND
U72 pin 5 or J75 pin 13     (COLOR EN)  ->         |      |
_____________________________________________ pin 3|A5    |pin 21->+5V          GND  >- DE-9F pin 2
                                                   |      |                     ___________________
                                                    ------ 

U65 pin 5                     (HS)                    ->          (HSYNC)               DE-9F pin 8
___________________________________________________________________________________________________


U65 pin 13                    (VS)                    ->          (VSYNC)               DE-9F pin 9
___________________________________________________________________________________________________

But as I said, I no longer think that this would really work.

The ROM contents would simply have been 32 repetitions of the following:

Code: Select all

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F
00 0E 00 0C 00 0A 00 06 00 09 00 0D 00 0B 00 0F
0E 00 0C 00 0A 00 06 00 09 00 0D 00 0B 00 0F 00

ronin, good luck with the cassette sound output. I'm not going to deal with that today. Others may be more likely to figure it out. If no one does in the next day or two, I'll take another look.

Thanks @bxdanny, this is very interesting stuff, I'll have a dig through my EPROM collection, I have 27C16's up to 27C512's, and I'm now wondering what speeds they might be.

I'm neither an engineer nor a programmer, though I can build and repair stuff, so I'm always interested in building new things

As for the cassette, that's an odd one, I can't quite figure out the reasons why it won't work, it seems to get all the necessary clocks plus the data from the 6850, but that CLR signal has me wondering...

[bxdanny]

After a recent conversation with Sideburn, I have realized that, using the ROM image that I posted at the beginning of this thread, the address display of the 65V Monitor in 48-character mode would be off-screen to the left, not visible. This would only be evident if you typed S and then M at the reset prompt, and there is little reason to do so - with only six characters on the screen, they might as well be big ones. Still, I'd rather have the display be "right" if that is done.

To fix it, three bytes need to be changed in the ROM:

Code: Select all

Offset
Address    CPU        Old      New
in ROM     Address    Value    Value
-------    ---------  -----    -----
06C4       FEC4       CA       D0
06C7       FEC7       CB       D1
06D6       FED6       C6       CC

[Mark]

I was thinking about bxdanny's RGBI interface and EPROMS being too slow. Commodore use a custom programmed PLA to handle a bunch of combinational logic in the C64. Perhaps a programmable logic device like Lattice Semiconductor's GALs would work, like the 16V8. https://ece-classes.usc.edu/ee459/libra ... s/16v8.pdf They seem fast enough with a low propagation delay. Of course they are end of life, so maybe something from Atmel like the slightly slower ATF16V8B may be a better choice? Seems like sync signals could be fed through too to give the video a common delay. Just a thought...

[bxdanny]

Actually, I'm thinking now there may be a way to generate color with only a few TTL chips. In fact, if the colors shown for the "C1E" by WinOSI as RGB colors are correct, then I first thought all you would need is a quad AND gate: CD0 AND VID would go to the I input of an RGBI monitor, CD1 AND VID to the R input, CD2 AND VID to the G input, and CD3 AND VID to the B input. But that wouldn't allow for color to be switched off. so really what would be needed are (NOT COLOR EN OR CD0) AND VID to the I input, (NOT COLOR EN OR CD1) AND VID to R, etc. Four AND gates, four OR gates, and an inverter. Would this work? Those four signals, plus vertical and horizontal sync.

Of course, no software at all supports this color scheme, and it doesn't match either the 540 color or the composite color that the 630 would produce.

BTW Mark, thanks for your quick work in getting OSIHFE to handle YE-DOS. And for the updated OSIKCS before that. But I'm wondering: could an -R2 option be added to OSIKCS, for 1200 bps tapes? They did actually work when I had my C1P (though generally not for BASIC listings, of course).

[Mark]

I guess Steve already has a working RGBI solution for the C1P, which could be tweaked for an RGB output with a few passive components. But like you said, there is no real historic support for those colors. I have never seen a 630 board's composite output, but I would guess it to be similar to the 540 color output. I based the WinOSI RGB color on Steve's screen shot and standard IBM palettes.

OSIHFE is being updated - I'm adding YEDOS disk layout testing, and I found a bug that relied on a particular distance from the wrong header to generate directory listings.

OSIKCS could generate 1200 baud output but there would only be a single cycle of 1200Hz and 2 cycles of 2400 to decode. I don't think people would have good luck decoding that from cassette tapes. I recall when those types of mods were done, the FSK tones would be doubled with the input filter timing changed as well, but since you say it worked for you then maybe it's a thing. The OSIKCS decoder will need changing as it doesn't even handle 600 baud well. There are other decoders out there that do lowpass filtering & phase lock decoding for more reliable output. I'd add that if I could do that in a C/C++ portable way for any platform. Mostly I have to convert the internal WAVE processing math from integer to floating point.
Anyway there are no shortages of things to work on!

[Steve Gray]

I guess Steve already has a working RGBI solution for the C1P, which could be tweaked for an RGB output with a few passive components. But like you said, there is no real historic support for those colors. I have never seen a 630 board's composite output, but I would guess it to be similar to the 540 color output. I based the WinOSI RGB color on Steve's screen shot and standard IBM palettes.

I think my board plus RGB2HDMI could probably be configured to do proper OSI colours. I use rgb2hdmi on my Commodore c128 and it is great. There are C128 adapters that convert rgbi to analog rgb that use PAL chips to handle the yellow to brown fix of the ibm CGA monitor, which could probably be adapted to OSI colours as well. Lastly, I am working on a propeller-based vga adapter that plugs into any standard 6502 socket. I hope to get this working on OSI in mono as well as colour.

Steve