High resolution mode?

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
User avatar
marcelk
Posts: 490
Joined: 13 May 2018, 08:26

Re: High resolution mode?

Post by marcelk » 05 Jul 2019, 17:48

We do have an inverted clock, but it's also created by an inverter (U1). You can try and characterise a 74x241. One of its enable pins is positive, the other negative. You might be lucky if their propagations are the same, but a quick first glance at the 74LS and 74HCT data sheets is discouraging. Still, this should be a simple test.

74LS241.png
74LS241.png (74.21 KiB) Viewed 4582 times

PurpleGirl
Posts: 48
Joined: 09 Sep 2019, 08:19

Re: High resolution mode?

Post by PurpleGirl » 09 Oct 2019, 15:24

Would capacitors help smooth over the transition? And would the final chip need to be faster or slower? There are faster TTL-compatible chips, but if the signal before that is not changing fast enough, might that make it worse?

alastair
Posts: 18
Joined: 10 Oct 2019, 14:28

Re: High resolution mode?

Post by alastair » 10 Oct 2019, 14:48

The fundamental issue here is the additional state. You only want two states: "Pixel 1" (state A) or "Pixel 2" (state B), but there is also a third state: "Update Pixels" (state C). You can try and adjust the timing and hide state C in the A->B or B->A state transition. This doesn't work though since the rate at which the logic changes from 0->1 and1->0 is different. You might be able to align one of these transitions, but the other will show up. Also, this requires critical timing adjustment that will change as the chips warm up.

The only solution is to add an additional register after the A/B selector using the faster dot clock (12.5 MHz). This will sample the A and B states and eliminate state C from the output. It's a simple fix but does require an additional chip

PS. I building something very similar and have been working though all these issues on a breadboard for the last 6 months :x

User avatar
marcelk
Posts: 490
Joined: 13 May 2018, 08:26

Re: High resolution mode?

Post by marcelk » 17 Dec 2019, 22:56

A little bird slipped this under my door today: a cute 16-pinner that might work as a proper resolution doubler.

The idea is to clock the RS flip flops at 12.5 MHz on /CP. Feed the 6 color bits into the multiplexers, get 3 colors bits out in two phases.

The remaining flip flop and 2-to-1 multiplexer can function as a frequency divider: just hardwire its inputs to H an L. It then outputs a 50% duty cycle clock at 6.25 MHz. That can drive the rest of the system, including its own select line S.

SN74LS298.png
SN74LS298.png (72.2 KiB) Viewed 4256 times

Warning: I had a fever today, so I may still be hallucinating...

tocksin
Posts: 25
Joined: 22 Jun 2018, 14:12

Re: High resolution mode?

Post by tocksin » 01 Feb 2020, 02:39

Cleaning up the output with a register is good digital design. I can't seem to find a version that is CMOS and in DIP package and is not obsoleted. I'll keep looking. TTL would probably be ok. Still worst case is two chips, but it's much more slick with one. I'd still like to try the 4063 analog multiplexer chip - it looks like the select logic might be balanced in timing.

Lerc
Posts: 8
Joined: 21 May 2020, 19:38

Re: High resolution mode?

Post by Lerc » 21 May 2020, 21:48

Hi, I saw the Apple I story and fell down the rabbit hole. So I'm fairly new to all this, but I'm halfway through laying out my own variant in a simulator.

I'm posting in this thread because I was kept awake by ideas for the video out. I'm a complete novice so I half expect this to be gibberish, but bear with me.

I also came up with the notion of two pixels per write. I was aiming for 4 bits per pixel using a similar principle of RGBI I wrote a program to play with weights of 4 bits to R G and B and came up with a set that made a much better mix than RGBI (I then lost the values when a floor sander in the next room blew a fuse :-/, I'll rewrite)

My idea was to use a 74157 to select between an XOR of the clock and the output of a shift register 74165 or 74166. Either 165 or 166 would work because you would invert every other bit going in when you write to the shift. That would make the the select for the 157 oscillate when the shift register is empty but you can write to it in a sensible manner. Of course you could remove the inverters and do it in software.

The upshot is if you wrote to the 157 directly you would do 2 pixels per write if you wrote to the shift register you would get 8 pixels per write in either of the two colours feeding the 157. It both provides a bit per pixel mode and maybe even enough time to do a character lookup.

So this raises problems,

How to write to the shift register?
Were did the sync lines go?

Scanning though the source of the ROM, it seemed to me that IN was only used in with store and OUT was only used with load except for an instance of ora [Y,X++],OUT in the video to preserve the sync bits.

My thought for handling more IO was to run the lines coming out of the Instruction decode (U14) out to the enable lines of various output chips and use U13-pin-9 OR U13-pin7 to block the U14 lines from getting to the diode array.

My current sketch has something like
LD [ZD],OUT becomes LD [ZD], SYNC
AND [ZD],OUT becomes LD [ZD], COLOR_PAIR
OR [ZD],OUT becomes LD [ZD], PIXEL_SHIFT
XOR [ZD],OUT becomes LD [ZD], Z
ADD [ZD],OUT becomes LD [ZD], WRITE_PROGMEM (low or high)

That last one has a bit more magic to it. I was thinking of having a little subcircuit that will lock the fetched instruction until a bit (maybe bit 5) of the PC goes High, that way it can execute a ld [Y,X++],AC repeatedly and use the BUS value to program a series of bytes into the high or low half of program memory. The PC keeps on incrementing like normal. The idea is you can write blocks of program memory in two passes. Obviously this means using RAM. I'm not sure on speeds of SRAM so maybe this is a bit tough, but I'd really like to have something live programmable in native instructions. but that's a completely different issue to the display stuff which is what I mainly was thinking of.

oh and I added a Z register to move zero page, because that was only one chip and moving zero page seems like a really useful thing. Overall I'm probably adding a bunch of new chips, but I'm not intending to be excessive, just aiming for getting the most from the least.

frob
Posts: 6
Joined: 19 May 2020, 12:50
Location: Canada
Contact:

Re: High resolution mode?

Post by frob » 01 Jun 2020, 22:30

Like you i just recently discovered the Gigatron and fell down the same rabbit hole. at the same time i started studying other vintage computer video circuits and have an idea to do do something to vastly increase video resolution while also releasing the core CPU from the huge burden it has to output every frame of video. Steve Wozniak came up with a very elegant method for the 6502 in the Apple II which can potentially be adapted here if done with some other small tweaks to the core and clocking.
By optimizing the speed and propagation delays in the core and giving it faster RAM device, it should be possible to run it reliably at ‭12.5875‬MHz and get memory access time to less than 30nS, which would make it possible to do 2 accesses per cycle - one for the core, and another to DMA video output while the core is busy fetching, decoding and running the ALU. it will require some careful tweaking of clock timing and propagation delays, but i feel it should be possible. doing that while outputting two 16-color pixels per byte, and expanding memory to 512k with paging (bye bye blinkenlights), it should be possible to get full 640x480 VGA resolution. it could also support 256 color mode at QVGA.
Even if we don't boost the clock and leave it at the original speed, it seems worthwhile trying to do this, even 1/2 VGA with no CPU overhead would unleash a lot of processing power and greatly relaxed software timing constraints.
The DMA Video output is actually pretty straight froward, while i haven't drawn up a schematic yet, the solution ( using only standard 74-series logic) will need a 20-bit address counter (5 IC's), 2 ripple counters for the syncs, and a heaping handful for combinatorial logic. if you add a set of expanded muxes for the RAM, the total IC count should be less than 20.
This might be possible to implement as an add-on card, but probably will need to be part of new Gigatrion version to achieve full speed and full VGA.
What do you think ?

Cheers
Frantz

frob
Posts: 6
Joined: 19 May 2020, 12:50
Location: Canada
Contact:

Re: High resolution mode?

Post by frob » 16 Jun 2020, 01:10

I was just rereading this thread, trying to understand better the various ideas proposed earlier, and i thought i would check on the availability of the 74LS298 Marcel suggested earlier as an ideal solution.
Well it turns out its still in full production at TI ( in DIP no less) and there are over 1500pcs stock at Mouser right now, in case anyone is interested in trying that out...

https://www.ti.com/product/SN74LS298?ke ... secase=GPN

https://www.mouser.com/ProductDetail/Te ... BScbsEw%3D

Lerc
Posts: 8
Joined: 21 May 2020, 19:38

Re: High resolution mode?

Post by Lerc » 18 Jul 2020, 23:27

So I mentioned a while back that I wrote a program to try some 4 bit digital to 16 colour RGB that was nicer than CGA's RGBI. I rewrote the program and after a lot of fiddling I came up with a resister arrangement that wasn't too complex and produced a set of colours that I thought were good.

Image

From my calculations I figured this should produce a set of colours like

Image

Of course, that's fine in theory. but needs a proper test, so I I cobbled resistors together from what I had on hand to make things fairly close to the listed values and whipped up a simple VGA output from an Arduiino.

A shot of my monitor taken with a potato Image

Blurryness aside I was quite chuffed at how close the colours came to my calculated version.

Post Reply