Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II » THGR?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
THGR? [message #374337] Sat, 06 October 2018 04:40 Go to next message
Anonymous
Karma:
Originally posted by: Anthony Adverse

Some donkey I used to know a looong time ago flirted with the idea of being able to get triple hi-res graphics out of a IIe with extra memory in the Aux slot, ramworks for arguments sake. Is this in any way feasible? If its all just smoke and mirrors with bank switching you'd think so, but I'm guessing there are hardware limitations too.

A
Re: THGR? [message #374338 is a reply to message #374337] Sat, 06 October 2018 05:51 Go to previous messageGo to next message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
On Sat, 6 Oct 2018, Anthony Adverse wrote:

> Some donkey I used to know a looong time ago flirted with the idea of
> being able to get triple hi-res graphics out of a IIe with extra memory
> in the Aux slot, ramworks for arguments sake. Is this in any way
> feasible? If its all just smoke and mirrors with bank switching you'd
> think so, but I'm guessing there are hardware limitations too.

You could prolly push 560x384 through tricks...

-uso.
Re: THGR? [message #374365 is a reply to message #374338] Sun, 07 October 2018 10:01 Go to previous messageGo to next message
STYNX is currently offline  STYNX
Messages: 453
Registered: October 2012
Karma: 0
Senior Member
On Saturday, 6 October 2018 11:51:19 UTC+2, Steve Nickolas wrote:
> You could prolly push 560x384 through tricks...

You would have to at least double the pixel and line frequency for 560x384 in 60hz progressive. If you are talking about interlaced, it gets more feasible. That would require 4 HR pages instead of two, though. You would have to implement a hardware implemented line-switching logic onto top of the DHGR as well. Programming for this would most likely be a nightmare.

I would like to see a 80x48 text mode even if it was interlaced (modern monitors may help there)

-Jonas
Re: THGR? [message #374374 is a reply to message #374365] Sun, 07 October 2018 12:44 Go to previous messageGo to next message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
On Sun, 7 Oct 2018, STYNX wrote:

> On Saturday, 6 October 2018 11:51:19 UTC+2, Steve Nickolas wrote:
>> You could prolly push 560x384 through tricks...
>
> You would have to at least double the pixel and line frequency for
> 560x384 in 60hz progressive. If you are talking about interlaced, it
> gets more feasible. That would require 4 HR pages instead of two,
> though. You would have to implement a hardware implemented
> line-switching logic onto top of the DHGR as well. Programming for this
> would most likely be a nightmare.

By "tricks" I was thinking of page flipping 60 times a second, I think
that would be called interlacing.

-uso.
Re: THGR? [message #374375 is a reply to message #374374] Sun, 07 October 2018 13:17 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: James Davis

On Sunday, October 7, 2018 at 9:44:31 AM UTC-7, Steve Nickolas wrote:
> On Sun, 7 Oct 2018, STYNX wrote:
>
>> On Saturday, 6 October 2018 11:51:19 UTC+2, Steve Nickolas wrote:
>>> You could prolly push 560x384 through tricks...
>>
>> You would have to at least double the pixel and line frequency for
>> 560x384 in 60hz progressive. If you are talking about interlaced, it
>> gets more feasible. That would require 4 HR pages instead of two,
>> though. You would have to implement a har dware implemented
>> line-switching logic onto top of the DHGR as well. Programming for this
>> would most likely be a nightmare.
>
> By "tricks" I was thinking of page flipping 60 times a second, I think
> that would be called interlacing.
>
> -uso.

Interlacing is when the CRT electron gun shoots all the odd numbered lines across the display screen before or after shooting all the even numberd lines (at whatever frequency the CRT is set for, e.g., 60 HZ, 75 HZ, etc.).
Re: THGR? [message #374376 is a reply to message #374375] Sun, 07 October 2018 14:12 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
You may find interest in RFC / Sirius' Paginator...
Get info @ http://www.brutaldeluxe.fr/documentation/manual/RFC%20Sirius %20-%20Paginator.pdf

Antoine
Re: THGR? [message #374388 is a reply to message #374375] Sun, 07 October 2018 16:54 Go to previous messageGo to next message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
On Sun, 7 Oct 2018, James Davis wrote:

> On Sunday, October 7, 2018 at 9:44:31 AM UTC-7, Steve Nickolas wrote:
>> On Sun, 7 Oct 2018, STYNX wrote:
>>
>>> On Saturday, 6 October 2018 11:51:19 UTC+2, Steve Nickolas wrote:
>>>> You could prolly push 560x384 through tricks...
>>>
>>> You would have to at least double the pixel and line frequency for
>>> 560x384 in 60hz progressive. If you are talking about interlaced, it
>>> gets more feasible. That would require 4 HR pages instead of two,
>>> though. You would have to implement a har dware implemented
>>> line-switching logic onto top of the DHGR as well. Programming for this
>>> would most likely be a nightmare.
>>
>> By "tricks" I was thinking of page flipping 60 times a second, I think
>> that would be called interlacing.
>>
>> -uso.
>
> Interlacing is when the CRT electron gun shoots all the odd numbered lines across the display screen before or after shooting all the even numberd lines (at whatever frequency the CRT is set for, e.g., 60 HZ, 75 HZ, etc.).
>
I know that.

My assumption was that when you page flip every field, it will interleave
the two pages together through interlacing, rather than, say, stacking one
on top of the other.

-uso.
Re: THGR? [message #374389 is a reply to message #374365] Sun, 07 October 2018 17:51 Go to previous messageGo to next message
Bill Buckels is currently offline  Bill Buckels
Messages: 1418
Registered: November 2012
Karma: 0
Senior Member
"STYNX" <Jonas.Groenhagen@gmx.de> wrote:
> You would have to at least double the pixel and line frequency for 560x384
> in 60hz progressive.

Just in case you didn't know I was lurking... I would be prepared to write a
dedicated converter to produce static images much like my b2d utility.
Perhaps bmp2thgr (b2t). Just don't ask me to write a buckshot version. Dagen
can do that if he wants to :)

My raster based non-compressed linear format would likely be best for the
display software programmer... I would consider 560 x 384 the equivalent
screen aspect for this purpose of 4:3. I will wait for the specification,
and produce the converter accordingly. I am assuming horizontal blocks of 14
pixels aligned on 8 bytes... (aux 3, aux 2, aux 1, main mem)... is this
correct ? Pixels span memory banks...

> If you are talking about interlaced, it gets more feasible. That would
> require 4 HR pages instead of two, though. You would have to implement a
> hardware implemented line-switching logic onto top of the DHGR as well.
> Programming for this would most likely be a nightmare.

I would not be interested in programming the display software, so I'll leave
that up to the OP to do... they can enjoy their nightmare :)

But they can have some high quality ntsc dithered thgr conversions from me
if they are serious about making this happen.

Regards,

Bill

PS -

> I would like to see a 80x48 text mode even if it was interlaced (modern
> monitors may help there)

That one I'll leave up to you :)
Re: THGR? [message #374390 is a reply to message #374388] Sun, 07 October 2018 18:20 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Brian Patrie

On 2018-10-07 15:54, Steve Nickolas wrote:
> On Sun, 7 Oct 2018, James Davis wrote:
>
>> On Sunday, October 7, 2018 at 9:44:31 AM UTC-7, Steve Nickolas wrote:
>>> On Sun, 7 Oct 2018, STYNX wrote:
>>>
>>>> On Saturday, 6 October 2018 11:51:19 UTC+2, Steve Nickolas  wrote:
>>>> > You could prolly push 560x384 through tricks...
>>>>
>>>> You would have to at least double the pixel and line frequency for
>>>> 560x384 in 60hz progressive. If you are talking about interlaced, it
>>>> gets more feasible. That would require 4 HR pages instead of two,
>>>> though. You would have to implement a har dware implemented
>>>> line-switching logic onto top of the DHGR as well. Programming for this
>>>> would most likely be a nightmare.
>>>
>>> By "tricks" I was thinking of page flipping 60 times a second, I think
>>> that would be called interlacing.
>>>
>>> -uso.
>>
>> Interlacing is when the CRT electron gun shoots all the odd numbered
>> lines across the display screen before or after shooting all the even
>> numberd lines (at whatever frequency the CRT is set for, e.g., 60 HZ,
>> 75 HZ, etc.).
>>
> I know that.
>
> My assumption was that when you page flip every field, it will
> interleave the two pages together through interlacing, rather than, say,
> stacking one on top of the other.
>
> -uso.

I seem to recall playing with that on my IIee back in the day, and they
stacked. The vertical sync would need a tweak on the second field, to
nudge it down between the first field's lines.
Re: THGR? [message #374391 is a reply to message #374388] Sun, 07 October 2018 18:41 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Doug Dingus

They land on top of one another, unless there is a half scan line present on one field.
Re: THGR? [message #374407 is a reply to message #374391] Mon, 08 October 2018 07:30 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Anthony Adverse

Sooooooo. Do we think its really possible, and feasible, or just pie in the sky?
It'd be spiffy to take images from my birdcam, and watch them on the IIe :)
Re: THGR? [message #374421 is a reply to message #374390] Mon, 08 October 2018 15:49 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Brian Patrie <bpatrie@bellsouth.spamisicky.net> wrote:
> On 2018-10-07 15:54, Steve Nickolas wrote:
>> On Sun, 7 Oct 2018, James Davis wrote:
>>
>>> On Sunday, October 7, 2018 at 9:44:31 AM UTC-7, Steve Nickolas wrote:
>>>> On Sun, 7 Oct 2018, STYNX wrote:
>>>>
>>>> > On Saturday, 6 October 2018 11:51:19 UTC+2, Steve Nickolas  wrote:
>>>> >> You could prolly push 560x384 through tricks...
>>>> >
>>>> > You would have to at least double the pixel and line frequency for
>>>> > 560x384 in 60hz progressive. If you are talking about interlaced, it
>>>> > gets more feasible. That would require 4 HR pages instead of two,
>>>> > though. You would have to implement a har dware implemented
>>>> > line-switching logic onto top of the DHGR as well. Programming for this
>>>> > would most likely be a nightmare.
>>>>
>>>> By "tricks" I was thinking of page flipping 60 times a second, I think
>>>> that would be called interlacing.
>>>>
>>>> -uso.
>>>
>>> Interlacing is when the CRT electron gun shoots all the odd numbered
>>> lines across the display screen before or after shooting all the even
>>> numberd lines (at whatever frequency the CRT is set for, e.g., 60 HZ,
>>> 75 HZ, etc.).
>>>
>> I know that.
>>
>> My assumption was that when you page flip every field, it will
>> interleave the two pages together through interlacing, rather than, say,
>> stacking one on top of the other.
>>
>> -uso.
>
> I seem to recall playing with that on my IIee back in the day, and they
> stacked. The vertical sync would need a tweak on the second field, to
> nudge it down between the first field's lines.
>

Exactly. In my experiment I used an annunciator output and an AND gate to
trim the first vertical sync pulse by about 1/2 line, or 32 cycles, for the
second field. This was done as part of a cycle-counted page flipping loop.
Pretty straightforward, really.

The viewing results were pretty good, but would benefit from longer
persistence phosphors in areas where fine detail depended on the
interlace—like a thin (single field) horizontal line. Even then, viewing
from a reasonable distance did a fair job of reducing flicker.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: THGR? [message #374427 is a reply to message #374421] Mon, 08 October 2018 23:21 Go to previous messageGo to next message
mdj is currently offline  mdj
Messages: 301
Registered: December 2012
Karma: 0
Senior Member
On Tuesday, 9 October 2018 05:49:33 UTC+10, Michael J. Mahon wrote:

> Exactly. In my experiment I used an annunciator output and an AND gate to
> trim the first vertical sync pulse by about 1/2 line, or 32 cycles, for the
> second field. This was done as part of a cycle-counted page flipping loop..
> Pretty straightforward, really.
>
> The viewing results were pretty good, but would benefit from longer
> persistence phosphors in areas where fine detail depended on the
> interlace—like a thin (single field) horizontal line. Even then, viewing
> from a reasonable distance did a fair job of reducing flicker.

ISTR reading that the Laser 128 (or perhaps its later variants) implemented this in hardware, but I can't find a reference anywhere.
Re: THGR? [message #374431 is a reply to message #374427] Tue, 09 October 2018 00:12 Go to previous messageGo to next message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
On Mon, 8 Oct 2018, mdj wrote:

> On Tuesday, 9 October 2018 05:49:33 UTC+10, Michael J. Mahon wrote:
>
>> Exactly. In my experiment I used an annunciator output and an AND gate to
>> trim the first vertical sync pulse by about 1/2 line, or 32 cycles, for the
>> second field. This was done as part of a cycle-counted page flipping loop.
>> Pretty straightforward, really.
>>
>> The viewing results were pretty good, but would benefit from longer
>> persistence phosphors in areas where fine detail depended on the
>> interlace—like a thin (single field) horizontal line. Even then, viewing
>> from a reasonable distance did a fair job of reducing flicker.
>
> ISTR reading that the Laser 128 (or perhaps its later variants) implemented this in hardware, but I can't find a reference anywhere.
>

I heard the same. Likewise though - no proof.

-uso.
Re: THGR? [message #374432 is a reply to message #374427] Tue, 09 October 2018 03:12 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
On 10/8/2018 8:21 PM, mdj wrote:
> On Tuesday, 9 October 2018 05:49:33 UTC+10, Michael J. Mahon wrote:
>
>> Exactly. In my experiment I used an annunciator output and an AND
>> gate to trim the first vertical sync pulse by about 1/2 line, or 32
>> cycles, for the second field. This was done as part of a
>> cycle-counted page flipping loop. Pretty straightforward, really.
>>
>> The viewing results were pretty good, but would benefit from
>> longer persistence phosphors in areas where fine detail depended on
>> the interlace—like a thin (single field) horizontal line. Even
>> then, viewing from a reasonable distance did a fair job of reducing
>> flicker.
>
> ISTR reading that the Laser 128 (or perhaps its later variants)
> implemented this in hardware, but I can't find a reference anywhere.
>

I went spelunking today and found my interlace code for machines with
readable VBL (like the //e).

I turns out that the hardware part is very simple--no AND gate, no need
to cut traces or lift chip legs. All that's needed is a diode and a
resistor in series, connected between an annunciator (AN1 in my test)
and the base of Q1, a 3906 transistor near the video output.

The base of Q1 is the video mixing point for Apple video, blanking, and
sync signals. Since the sync signal at this point is negative-going, it
can be shortened by adding in a positive pulse from the annunciator. To
obtain the desired amplitude--just enough to neutralize the sync
signal--a series resistance of approximately 5.6k is needed. I used a
10k trimpot and adjusted it using an oscilloscope to verify that the
sync pulse was cancelled when the annunciator was high. To prevent the
annunciator from loading the video signal, I used a 1N914 (any silicon
signal diode will do, like the 1N4148), connected in series with the
trimpot with its anode toward the annunciator output.

Unfortunately, I never measured the trimpot resistance after adjusting
it, so you'll have to repeat the adjustment yourself. After the correct
resistance is determined, the trimpot can be replaced with a small fixed
resistor.

The test code I wrote interlaces HGR1 (odd lines) with HGR2 (even
lines). Here's a listing of the code:


1 **********************************************************
2 * *
3 * I N T E R L A C E *
4 * *
5 * MJM - Sep. 30, 2007 *
6 * *
7 * Display graphics pages 1 and 2 as interlaced fields to *
8 * create a 560x384 pixel raster. Returns when a key is *
9 * pressed. *
10 * *
11 * Operates by producing a synchronized pulse to "kill" *
12 * the first half-line of the first vertical sync pulse *
13 * preceding the display of page 2, so that its lines are *
14 * interlaced with those of page 1. *
15 * *
16 * The pulse is produced on AN1 and is coupled into the *
17 * video mixer through a diode and a resistor. *
18 * *
19 **********************************************************
20
21 * Definitions
22
23 KBD equ $C000 ; Keyboard port
24 VBLOFF equ $C019 ; VBL'
25 PAGE1 equ $C054 ; Primary page
26 PAGE2 equ $C055 ; Secondary page
27 AN1 equ $C05A ; 'pulse' annunciator
28 DSK6OFF equ $C0E8 ; Deselect disk 6, slow zip
29
30 org $300
31
32 DISPLAY lda DSK6OFF ; Slow Zip Chip for 50ms.
33 lda VBLOFF ; Wait for end of VBL
34 bpl DISPLAY
35 :waitvbl lda VBLOFF ; Wait for start of VBL
36 bmi :waitvbl
37 ldx #0 ; Delay 1281 cycles
38 :wait1 dex
39 bne :wait1
40 ldx #161 ; Delay 806 cycles more
41 :wait2 dex
42 bne :wait2
43 lda AN1+1 ; Start "kill" pulse
44 ldx #8 ; Delay 41 cycles
45 :wait3 dex
46 bne :wait3
47 lda AN1+0 ; End pulse
48 lda PAGE2 ; Show page 2
49 :waitdis lda VBLOFF ; Wait for end of VBL
50 bpl :waitdis
51 :waitvb2 lda VBLOFF ; Wait for VBL
52 bmi :waitvb2
53 lda PAGE1 ; Show page 1
54 lda KBD ; Key pressed?
55 bpl DISPLAY ; -No, keep displaying.
56 rts ; -Yes, return.

--

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://michaeljmahon.com

"The wastebasket is our most important design
tool--and it's seriously underused."
Re: THGR? [message #374443 is a reply to message #374432] Tue, 09 October 2018 10:36 Go to previous message
mdj is currently offline  mdj
Messages: 301
Registered: December 2012
Karma: 0
Senior Member
On Tuesday, 9 October 2018 17:12:34 UTC+10, Michael J. Mahon wrote:

> I went spelunking today and found my interlace code for machines with
> readable VBL (like the //e).

Neat! I like how you've built a wired-OR with Q1, gating it with the annunciator.

It's easy to see how this would be a modest hardware extension if one were building a clone.

> I turns out that the hardware part is very simple--no AND gate, no need
> to cut traces or lift chip legs. All that's needed is a diode and a
> resistor in series, connected between an annunciator (AN1 in my test)
> and the base of Q1, a 3906 transistor near the video output.
>
> The base of Q1 is the video mixing point for Apple video, blanking, and
> sync signals. Since the sync signal at this point is negative-going, it
> can be shortened by adding in a positive pulse from the annunciator. To
> obtain the desired amplitude--just enough to neutralize the sync
> signal--a series resistance of approximately 5.6k is needed. I used a
> 10k trimpot and adjusted it using an oscilloscope to verify that the
> sync pulse was cancelled when the annunciator was high. To prevent the
> annunciator from loading the video signal, I used a 1N914 (any silicon
> signal diode will do, like the 1N4148), connected in series with the
> trimpot with its anode toward the annunciator output.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Color quirks of the IIGS 640 mode (GSOS Desktop)
Next Topic: Install to Jaz Drive
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 10:45:02 EDT 2024

Total time taken to generate the page: 0.25545 seconds