Page 4 of 6

Re: FPGA Implementations

Posted: Tue Jul 11, 2017 3:30 am
by Steve Gray
It's cool that this is 512 pixels wide, but 16K is a lot to allocate... is it possible to have a 256 pixel wide (8K) mode like the Mittendorf as well? Perhaps auto-selecting based on the 32 or 64 column text mode that is selected?

Steve

Re: FPGA Implementations

Posted: Tue Jul 11, 2017 3:58 am
by dave
It's cool that this is 512 pixels wide, but 16K is a lot to allocate... is it possible to have a 256 pixel wide (8K) mode like the Mittendorf as well? Perhaps auto-selecting based on the 32 or 64 column text mode that is selected?
I actually did a hires mod in TTL chips. At first I had a 16K block from 8000-BFFF. Later on, I gave it a sliding 2K window from $E000-$E7FF. I would have gone with a 4K window, but I had 2Kx8 RAM chips and the 2K window saved a gate or two, and is exactly the same to program as a 4K window, once you account for a sliding window in software. At $E800, I put a control register that allowed 4 modes of mixing with the text: off, multiplying (AND), Additive (OR), and XOR. Obviously, this is incompatible with the later 540B color video board.

Because the clock signals are all derived from the 540 timing chain, the usual 32/64 selection register still works.

Re: FPGA Implementations

Posted: Tue Jul 11, 2017 4:04 am
by Steve Gray
dave wrote: Tue Jul 11, 2017 3:58 am
It's cool that this is 512 pixels wide, but 16K is a lot to allocate... is it possible to have a 256 pixel wide (8K) mode like the Mittendorf as well? Perhaps auto-selecting based on the 32 or 64 column text mode that is selected?
I actually did a hires mod in TTL chips. At first I had a 16K block from 8000-BFFF. Later on, I gave it a sliding 2K window from $E000-$E7FF. I would have gone with a 4K window, but I had 2Kx8 RAM chips and the 2K window saved a gate or two, and is exactly the same to program as a 4K window, once you account for a sliding window in software. At $E800, I put a control register that allowed 4 modes of mixing with the text: off, multiplying (AND), Additive (OR), and XOR. Obviously, this is incompatible with the later 540B color video board.

Because the clock signals are all derived from the 540 timing chain, the usual 32/64 selection register still works.
Yes, a sliding window is a good idea. Did you make schematics for this board of yours?

Steve

Re: FPGA Implementations

Posted: Tue Jul 11, 2017 5:35 am
by RedskullDC
Hi Steve,
Steve Gray wrote: Tue Jul 11, 2017 3:30 am It's cool that this is 512 pixels wide, but 16K is a lot to allocate... is it possible to have a 256 pixel wide (8K) mode like the Mittendorf as well? Perhaps auto-selecting based on the 32 or 64 column text mode that is selected?

Steve
Yep, when the screen is in 32x32 text mode, the Hires screen is automatically reduced to 256x256 8-)

16Kb was just me tinkering.
If that is too much of the main memory space, we could change it back 8Kb
Could also have multiple 8kb pages which can be flipped in/out at $8000.

Yet another possibility would be to have that hires memory area act as programmable text characters.
Could be selected by the extra 4 bits we added in the colour memory area!
---

There is also the CUA hires board for the C1P/UK101 as another option:
http://stardot.org.uk/forums/viewtopic.php?t=11397
There are some docs/demo programs for it.
Also appears in the $8000-$9FFF memory range.

Too many options.. :?
Cheers,
Leslie

Re: FPGA Implementations

Posted: Tue Jul 11, 2017 4:23 pm
by dave
Steve Gray wrote: Tue Jul 11, 2017 4:04 am
Yes, a sliding window is a good idea. Did you make schematics for this board of yours?

Steve
Yes, by hand, in 1980, but by the time I retrieved the computer around 2000, none of the papers had survived. The video board piggy back was always in flux, and the final incarnation was as a bank of programmable character generators. The piggyback is long gone by now. I could recreate any incarnation of the piggyback (or perhaps a multi-configuration piggyback) without too much difficulty, if there were sufficient interest.

Dave

Re: FPGA Implementations

Posted: Tue Jul 11, 2017 5:30 pm
by dave
The way it worked was this:

I pulled address and data lines off the 540 board. Today, I'd just make a new board and pull the lines off the bus, but I didn't have that capability at the time. The circuit duplicated much of the 540 board circuitry (That's how I learned).

Address decoding and dual-port circuit based on 74157's was copied from the 540 board. initially the top 3 address lines were decoded as a board select (At A000-Bfff), and the next three were fed into the CPU "port" of the 74157's. Later, the Board was addressed at E000, and a latch (At E800) was used to store the three upper bits on the 74157 bank. The output of the 74157's bank of (A12-A10) fed a 74LS138 to generate chipslects for a bank of 2116 chips. The second "port" of the 74157 bank came from the video timing chain, including the row timing lines (used to address the chargen on the 540). During video retrieval, a '165 on the piggyback would serialize the selected byte, and that would get mixed with the '165 output on the 540 board.

The final mod was to turn the Hires RAM into a bank of 8 programmable character generators. To modify as a programmable character generator, I replaced part of the timing chain lines to the piggyback with the 540 board RAM output, and added 1Kx 4 at E800 that had 1 bit to AND with the normal 540 board 74165 output, and 3 bits to select a RAM chargen. That was a bit funky to program, but was the simplest way to mod the board to do a chargen. The programmable character generator approach is very flexible. You can use the same bank for the whole screen and just create an alternate character set and use it. Or, you can enable a different chargen bank for every 4 rows, fill the normal screen RAM at D000 with the pattern 0..255 over and over, and have a hires display with sliding window. You can create a bank of characters that overlays on the existing ROM characters to add features like character accents, game pixels, etc., and use them with minimal overhead.

Unfortunately, this was a bit of a rat's nest and compressing the assembly too much could cause it to short out, so I tended to run my machine with the lid off and video card on top. Some time in the mid 80's I apparently scavenged all the chips from the sockets, and some time in the 90's I removed the rats nest (without repairing the 540 board). That's the state my computer was in when I retrieved it from my parents house around 2000.

My feeling about high res now is that it's neat, but most OSIers would not spend much time developing for a nonstandard video setup. However, if someone came up with, say, a 68000 card for the OSI, a high-res mod might start to look tempting. I'd go with the bank of character generators in that case. That gives the most flexibility and best performance.

Dave

Re: FPGA Implementations

Posted: Tue Jul 11, 2017 10:33 pm
by w4jbm
Looks like some good stuff. I'm traveling with work and it will probably be a few weeks before I even get a weekend free, but looking forward to tinkering some more.

Tried tracking down the keyboard suggested but haven't had any luck yet.

I definitely think that even 1M or 2M of emulated disk space would be more than enough. The bottom tracks with the OS are the same for all disks anyway, so you would only need to store a single copy of them. You only had 80K per floppy to start with, so 1M could hold a lot of programs. (I believe I bought a total of five boxes of 10 disks each back then. They were around $35 to $50 per box which was a lot for a college student in the mid-1980s. I was also careful about backups and also tended to horde stuff the user groups sent around, so I really only had four or five disks I used frequently.)

Thanks,
Jim

Re: FPGA Implementations

Posted: Tue Jul 18, 2017 2:36 am
by RedskullDC
Hi Jim, Steve, Dave, et al.

Some minor progress to report.

I've wired up a TEAC FD-55GFR 5.25" drive to the DE0_CV board using a level translator board:
http://www.ebay.com/itm/142145925787

So far I'm able to step the head in/out, detect track#0 and watch the read stream on the leds.

Writing data out at the 125kHz rate looks relatively easy.
Reading the data back in will be a bit more difficult.
Emulating the read data separator in VHDL should be ummm... "fun".

I've also added emulation of the 60Hz "tick" on bit 7 of $DE00 so that the OS65D "NMHz" DOS versions will work.
(generated by the 540B video board).

Nothing to upload as yet, all a work in progress.

Cheers,
Leslie

Re: FPGA Implementations

Posted: Thu Jul 20, 2017 3:40 pm
by w4jbm
One thing you might run into if you are trying to be compatible with older drives is that most old drives ran at 300 rpm while newer drives were at 360 rpm.

This means that 2K will no longer fit on "one revolution" of the drive without writing past the index hole pulse (unless you up the density of the data stream going to the drive--which would likely have a ripple effect of impacts).

I think there are ways around this but I remember following someone trying to get a "new" 5.25" drive working with their OSI on a mailing list back in the late 1980s and running into that.

Patching to support 80 tracks instead of 40 should be fairly straight forward if you are able to support the higher track density. I have no idea what that would entail from a hardware or controller perspective. Going from (a sometimes bad) memory, it seems like configuring to the lower rpm or keeping the higher track density was mutually exclusive on the drive he was trying to get working.

Getting the drive going even to a limited extent is impressive. I have a level shifter around and might have a 5.25" floppy drive from a PC someplace. I'll have to start digging through boxes when I make it back home.

Thanks,
Jim

Re: FPGA Implementations

Posted: Thu Jul 20, 2017 7:46 pm
by dave
w4jbm wrote: Thu Jul 20, 2017 3:40 pm
I think there are ways around this but I remember following someone trying to get a "new" 5.25" drive working with their OSI on a mailing list back in the late 1980s and running into that.
There is a good article on using high density drives, including interface tweaks, adapter cables, and OS patches, in Peek(65) Vol 7, No. 12. The interface needs to be configured for an 8" drive (250 kbps) and so does the data separator (3 us window).

Dave