Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VIA 6522 timer emulation in Euphoric

91 views
Skip to first unread message

Andre Majorel

unread,
Jan 25, 2009, 2:49:38 PM1/25/09
to
If I'm reading the 6522 data sheet and Mike Brown's ULA specs
correctly, setting T1C/T1L to 510 should give you exactly 39
interrupts per frame ((510 + 2) x 39 = 19,968).

With Xeuphoric (= Euphoric 0.99b), that doesn't work. But
setting T1C/T1L to 500 seems to give you exactly 40 interrupts
per frame (500 x 40 = 20,000).

In other words, Euphoric
- outputs a frame every 20,000 (instead of 19,968) cycles,
- produces interrupts every T1L (instead of T1L + 2) cycles.

Has this changed since 0.99b ?

--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
"No meetings were held, nor secret handshakes created, to allow a Seria-
list Elite to disenfranchise the (tonal) non conformist. None had to be."
-- Wendy Carlos

sdm_sax

unread,
Jan 25, 2009, 7:38:00 PM1/25/09
to

I don't know. I'm not sure how accurate Mike's data is - maybe he can
shed some light on that for us. I think some of it was guessed at from
what readings could be taken - but like I said, I'm not sure and my
memory is not so hot what with the passing years and all ... ...

I'm trying to get my B system PC up and running in so I can get
Euphoric working properly. I used to like the .099n version. I don't
know if I have 99b to compare.

I guess you need to ask Fabrice things like this.
( I should have said that first. )

BTW Anyone else out there?

Mike

unread,
Jan 26, 2009, 10:12:25 AM1/26/09
to
In article <e8e54b05-1640-4c0b...@u18g2000pro.googlegroups.com>,
sdm_sax <ste...@dsl.pipex.com> wrote:

[Andre wrote:-]


>> If I'm reading the 6522 data sheet and Mike Brown's ULA specs
>> correctly, setting T1C/T1L to 510 should give you exactly 39

>> interrupts per frame ((510 + 2) x 39 =3D 19,968).

Hello!

I don't know why you'd get an odd number of interrupts per frame, everything
is pretty "round" numbers. Can you explain which bit of my document you're
looking at? Those numbers above don't jump out as being familiar ...

I'm not sure I had much to say on the 6522 side of things :)

>I don't know. I'm not sure how accurate Mike's data is - maybe he can
>shed some light on that for us. I think some of it was guessed at from
>what readings could be taken

Timings were accurate as I could get them (scoped), but many of the timings
are based on the division down from a master clock in known ways -- e.g.
40 columns of visible screen/1us per column, 64us per scanline from PAL
timings. These things are inter-related and are not very negotiable!

(@ Andre) Can you explain a little more about what you are doing?
--
--------------------------------------+------------------------------------
Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk

Andre Majorel

unread,
Jan 26, 2009, 1:25:00 PM1/26/09
to
On 2009-01-26, Mike <m...@posie.local.dom> wrote:
> In <e8e54b05-1640-4c0b...@u18g2000pro.googlegroups.com>,

> sdm_sax <ste...@dsl.pipex.com> wrote:
>
> [Andre wrote:-]
>>> If I'm reading the 6522 data sheet and Mike Brown's ULA specs
>>> correctly, setting T1C/T1L to 510 should give you exactly 39
>>> interrupts per frame ((510 + 2) x 39 =3D 19,968).
>
> I don't know why you'd get an odd number of interrupts per
> frame, everything is pretty "round" numbers. Can you explain
> which bit of my document you're looking at? Those numbers
> above don't jump out as being familiar ...

Hi Mike. Good thing you're reading comp.sys.oric... You wrote
that the ULA outputs 312 lines per frame. 312 / 8 = 39. Why that
particular divisor ? Having one IRQ for every 8th line gives a
whole number of IRQ per frame and is a good compromise between
resolution and overhead.

> I'm not sure I had much to say on the 6522 side of things :)
>
>>I don't know. I'm not sure how accurate Mike's data is - maybe
>>he can shed some light on that for us. I think some of it was
>>guessed at from what readings could be taken
>
> Timings were accurate as I could get them (scoped), but many
> of the timings are based on the division down from a master
> clock in known ways -- e.g. 40 columns of visible screen/1us
> per column, 64us per scanline from PAL timings. These things
> are inter-related and are not very negotiable!
>
> (@ Andre) Can you explain a little more about what you are
> doing?

The end goal is to have a program that would configure the VIA
to fire an interrupt every 312 x 64 = 19,968 cycles and let you
interactively adjust the phase of that interrupt relative to the
ULA's video output. (The motivation is that, if the interrupt
happens just after the ULA outputs the last scan line, it marks
the start of a (312 - 224) x 64 = 5632-cycle window during which
you can have your way with the video RAM with impunity.)

That can be done in a several ways. The one I'm looking at right
now would require more than one IRQ per frame during the
adjustment phase. The exact number is not critical ; 39 just
seemed to be a good starting point.

Mike

unread,
Jan 26, 2009, 3:37:14 PM1/26/09
to
In article <slrngnrvvm...@atc5.vermine.org>,

Andre Majorel <che...@halliburton.com> wrote:
> Hi Mike. Good thing you're reading comp.sys.oric... You wrote
> that the ULA outputs 312 lines per frame. 312 / 8 = 39. Why that
> particular divisor ? Having one IRQ for every 8th line gives a
> whole number of IRQ per frame and is a good compromise between
> resolution and overhead.

OK, 312 is because a PAL video signal requires a total of 625 lines
(UK-50Hz). Oric generates two identical fields of 312 lines (624) which
is near enough. For a correctly interlaced display, they should both
be 312.5 lines (625), but the display isn't an interlaced output.

(The corresponding 60Hz timing is 264 lines total).

Yes 39 is an odd number, I see where you got that from now. But it
would have to be 39 to be correct, otherwise it would be a very nonstandard
signal.

I have partly updated the ULA document, and fixed some bugs in it.
There are a couple of off-by one errors. E.g. the byte fetched from
memory in THIS cycle is actually shown on the screen in the NEXT cycle --
causing a 1us delay between bus activity and observed event.

I also designed a ULA bus snooper (to be prototyped) to monitor what RAS/
CAS addresses were up to in the "offscreen" areas to try and tighten up
some of the behaviour described in the document.

Englishmystic

unread,
Jan 26, 2009, 6:02:04 PM1/26/09
to
I'm still here, still love the old Oric, but with a sigh that it was never
redeveloped. In other words, that a newer, better model did not come out,
but still with the same programmability. You know, a bigger screen, more
colours, more memory, faster processor. I guess it would have been compared
unfairly with the PC or Mac, especially now in the age of the Internet, but
with Oricians' inventiveness, who knows what might have been achieved?
No, I can't help on the hardware side. Not even in Assembler! But I was
happy programming, while the interest lasted.

Colin Cook
(OUM contributor and author of MASTERMIND the peg game)


sdm_sax

unread,
Jan 28, 2009, 9:42:37 AM1/28/09
to

Hi Colin,

Glad you're still with us.
Just out of interest what spec would you have wanted in a new Oric?

Muso

Englishmystic

unread,
Jan 28, 2009, 3:56:44 PM1/28/09
to
Hello Muso, nice to make contact with you again.
The graphics of the Atmos were its let-down IMO. The use of attributes was
OK for games, where memory needed conserving, but for any kind of serious
picture applications it was a non-starter. Seriously, I would have
sacrificed some of the RAM to drive a slightly bigger screen (say, 360 × 300
if possible) and made at least 4 "shades" of each of the 7 "primary"
colours: red, green, blue, cyan, magenta, yellow, white. That way, some
gradation of any colour would have been possible. Ideally, 256 colours (or
216, as per the web palette) could have been very nice for artists and
programmers.
To be honest, I have forgotten what byte requirements were necessary for 8
bits per pixel, which would have been the optimum for a small computer, but
when I looked at the theory years ago I think I came to the conclusion that
it could have been done for a 200×240 pixel hires screen with the same
amount of memory, 64K. (I could have been wrong there!).

I think the next Oric after the Atmos or "Stratos" (Telestrat) could not
have been very ambitious. I don't think that we could have expected the
functionality of the PC ,with scanners, cameras, internet, stereo sound or
hard drive. But if it could have been made with a bigger processor, that
could handle more memory (32 bit??), and if the memory was affordable for
hobbyists (obviously dearer in real terms than these days), the [input new
Oric name here] would have been a great machine for programmers. I would
certainly have been interested in writing a raster image processor (RIP) for
it in an attempt to drive a colour printer to an approximation of the screen
appearance. I did so for the Oric printer (also the Tandy, which had the
same codes) and for one of the Canon monochrome printers, but would have
loved to have had a go at full colour. The routines would have been written
in Basic, but of course the value of that would have been in the algorithms,
and I would have been pleased if someone could have re-written the routines
in assembler so that they could be accesssed within other (graphics)
programs.

I would also have loved to write a WIMP environment for the Oric; again, in
Basic, so not of immediate use but providing the basis for assembler
routines. (Even useful without a mouse but just a keyboard). I really
enjoyed programming the Atmos and spent hours, days, weeks on it, but I
don't think that sense of excitement at starting a new program, or the
satisfaction of polishing one off, can ever be re-created, at least, not for
me these days. But I'm glad that a few people are still interested in the
machine, even if it is just to push the technology as far as it could have
gone.
Regards,
Colin Cook


sdm_sax

unread,
Jan 29, 2009, 5:58:50 PM1/29/09
to

Yes the screen was disappointing. Considering what could be achieved
on the Speccie it seems they could have done better with the Oric. I
would have liked something a bit more like the Commodore 64 - but with
a BASIC that wasn't all gibberish.
With the Atari ST and Amiga being produced about the time of the
Telestrat I feel we should have got that kind of graphics capability.
WIMP was the way to go and memory prices were dropping enough to have
a good amount.

I remember hearing that computers wouldn't be capable of photo quality
images because too much memory would be required! Now you can squeeze
a huge amount into a little Mp3 player and have it playing movies.

I think Oric did see the potential of something like the internet but
in those days it was BBS and Ceefax that they looked to. they included
those basics but it was too basic a machine. Everything was moving on
and advancing but Oric based their machines on what was already
successful instead of producing something cutting edge. The Telestrat
might have done well in 1983. By the time it came out they'd missed
the boat.

0 new messages