HRC in the works

The Oric video chip is not an easy beast to master, so any trick or method that allows to achieve nice visual results is welcome. Don't hesitate to comment (nicely) other people tricks and pictures :)
User avatar
Symoon
Archivist
Posts: 1728
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: HRC in the works

Post by Symoon » Mon Oct 14, 2019 11:29 pm

mikeb wrote:
Mon Oct 14, 2019 5:04 pm
But ... be careful what you poke into #BFE0-BFFF though, from memory the ULA does over-read into that area, so you might inadvertantly trigger a 60Hz attribute without knowing it. Test this by poking some 60Hz text/hires into this area in a normal HIRES mode, and see if you can get the screen to unlock!
I confirm ISS's test, on my Atmos poking alternatively 29 or 31 (decimal for 60Hz/50Hz graphics) in $BF47 or $BFE0 had no effect on the screen display, while it did when I poked in $BFDF. Same with 24 or 27 (60Hz/50Hz TEXT). That's good news, things would have been complicated if it did!
Hey, I'm not using $BFE0-BFFF, 40 bytes are enough for the decompression loop ;)

So, I hope soon we can have floppy disks packed with 2, 3 or 4 more HIRES screen that today, loading faster! For the price of a little garbage display at loading, and 40 unused bytes. :P

User avatar
mikeb
Pilot Officer
Posts: 121
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: HRC in the works

Post by mikeb » Tue Oct 15, 2019 6:12 pm

Symoon wrote:
Mon Oct 14, 2019 11:29 pm
I confirm ISS's test, on my Atmos poking alternatively 29 or 31 (decimal for 60Hz/50Hz graphics) in $BF47 or $BFE0 had no effect on the screen display, while it did when I poked in $BFDF. Same with 24 or 27 (60Hz/50Hz TEXT). That's good news, things would have been complicated if it did!
That's good to know, I've reviewed my ULA document to refresh my mind (!) and don't quite understand why it works correctly for you :)

There is a comment in there that the reason for the 3 lines of text being mandatory is to stop it overreading into 0xC000 and onwards. This would result in the ULA reading from "shadow RAM" -- without external hardware assistance the CPU cannot write data there for the ULA to read. OK.

But what I was thinking of is the fact that horizontal counts go from 0 to 39 for active screen, and then continue 40-63 for "rest of line" (black, sync, black).

In this case, the classic #A000 + horiz + (40*vertical) will over-read on every line by 24 bytes, with no harm done, and no-one ever notices this.

However, at the END of the HIRES screen, over-reading columns 41 to 63 means it's reading addresses #BF40 to #BF58, this will produce no video output as it's blanked, and any changes to attributes will be occur, but be irrelevant, forgotten on the next line.

Except for the 50Hz/60Hz flag which will still be set/reset. So there must be a 50Hz attribute somewhere further down the screen that is flipping it back -- I'm pretty sure the ULA is reading these locations.

POKE 60Hz graphics into all of #BF40 through #BF58 and see if it notices. If not, good, but I'm puzzled why not!

Whichever 50/60Hz attribute is read last is the winner, that's the rule. You can try and switch back and forth within the screen, but it won't make a difference.

User avatar
iss
Squad Leader
Posts: 899
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: HRC in the works

Post by iss » Tue Oct 15, 2019 9:45 pm



The program pokes 28 (60 Hz HIRES display) in every cell in range #BF40-#BF67 and waits 500ms after each to allow ULA to "interpret" the attribute - the result is vertical frequency remains at 50Hz. At end POKE#BF68,28 is executed and mode is set to 60Hz.
... the fact that horizontal counts go from 0 to 39 for active screen, and then continue 40-63 for "rest of line" (black, sync, black)
... the classic #A000 + horiz + (40*vertical) will over-read on every line by 24 bytes...
@mikeb: Does ULA really read memory during 40-63 ? If so, the internal address "pointer" must be NOT incremented during 40-63, because every next line starts exactly after 40 bytes of the previous line. :?

User avatar
Symoon
Archivist
Posts: 1728
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: HRC in the works

Post by Symoon » Tue Oct 15, 2019 10:36 pm

Thanks for the reply Mike, and for the test ISS, this saved me time ;)
I must say Mike, that your explanations are a bit hard for me to follow so far - I'm not a hardware guy and didn't have time to look at the ULA doc again.

From the tests I did 1 or 2 weeks ago, I gave up thinking things were almost random - sometimes poking in BF40-BF67 had no effet, sometimes I seem to recall it did, but maybe because I had poked other Hz or TEXT/HIRES attributes before in the HIRES screen. I ended up lost (and tired, it was late), especially when, if I understood correctly, I realised that playing with TEXT/HIRES can damage the char redefinitions area.
As you can see at the moment, I'm in the haze ;)

This ULA 40-63 thing (the black borders, right?) is fascinating, I never ever thought it was the result of a reading.

PS: evening was spent adding the 3 TEXT lines (they remain uncompressed) in the final file, if they exist in the original HIRES screen of course. Still have to deal with 1st routine possible forbidden bytes, but I'm too tired for tonight ;)

User avatar
mikeb
Pilot Officer
Posts: 121
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: HRC in the works

Post by mikeb » Wed Oct 16, 2019 4:51 pm

iss wrote:
Tue Oct 15, 2019 9:45 pm
The program pokes 28 (60 Hz HIRES display) in every cell in range #BF40-#BF67 and waits 500ms after each to allow ULA to "interpret" the attribute - the result is vertical frequency remains at 50Hz.
Good, puzzled as to why, but good :)

@mikeb: Does ULA really read memory during 40-63 ? If so, the internal address "pointer" must be NOT incremented during 40-63, because every next line starts exactly after 40 bytes of the previous line. :?
[/quote]

You misunderstand what's happening in the ULA -- you are right that the "next line" starts directly after in memory.

But: There is no "internal address pointer", the address is created from the H and V counters (multiplication and adding #A000) -- Note: speculation sent to me in the past that there is a separate memory counter and a H/V counter working separately as the only sensible design were proved to be 100% wrong.

So, on the first scan line of Oric's screen, with the horizontal count running 0-39, 40 bytes are looked up and used to make picture.

The next 24 microseconds/counts/columns are all done with the ULA's output forcibly blanked to black. ULA continues to read bytes 40 through 63, yes that's next line, and it even acts on them. Don't panic. In this period of time, we are producing the black right border, sync signal, black LEFT border and then when the vertical counter increments to the next scanline, the horizontal overflows from 63 to 0, and we start reading bytes 41 through 80, this time for real, with video output enabled.

If video wasn't forced to black, you'd see the edge of the screen at the left/right filled with repeats of stuff from onscreen.

It's a consquence of doing #A000 + X + (Y*40) with X ranging 0-63 -- there is over-reading/double-reading of memory.

Although this is provable as a "hardware thing" by staring at the electronics inside, it's borne out by the maths that the electronics is doing, and from simulation of the circuit.

User avatar
Dbug
Site Admin
Posts: 3019
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: HRC in the works

Post by Dbug » Wed Oct 16, 2019 7:27 pm

mike: Is there a way to hack the display do disable the border blanking?
If what you say is true, then we should see the start of the next line continuing until reaching the end of the line?

User avatar
Symoon
Archivist
Posts: 1728
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: HRC in the works

Post by Symoon » Thu Oct 17, 2019 6:49 am

Ok in theory now HRC shouldn't display any byte between $18-$1F and $98-$9F on screen (unless of course original picture does).
Now need to test the whole thing and set correct output messages.

User avatar
mikeb
Pilot Officer
Posts: 121
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: HRC in the works

Post by mikeb » Thu Oct 17, 2019 6:14 pm

Dbug wrote:
Wed Oct 16, 2019 7:27 pm
mike: Is there a way to hack the display do disable the border blanking?
If what you say is true, then we should see the start of the next line continuing until reaching the end of the line?
Well, the only way I know would involve removing the lid of the ULA, while not damaging it, and then I could show you which transistor to remove. The output of NAND 304 would need to be forced to 0. It's near the bottom left corner, just to the right of blue video output.
ula-activity-map.png
But you'd need small tweezers and a very steady hand.

In other words, no, there's nothing practical I'm aware of that will override this, the horizontal (and vertical counters) have logic that means horizontal counts of 40 and over, and vertical counts of 224 and over are caught (page 54-55 and 97-98), combined, and used to stop the RGB output (forced black, see page 104).

User avatar
iss
Squad Leader
Posts: 899
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: HRC in the works

Post by iss » Thu Oct 17, 2019 6:34 pm

Extremely cool explanation, thanks @mikeb! :D

User avatar
Symoon
Archivist
Posts: 1728
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: HRC in the works

Post by Symoon » Thu Oct 17, 2019 6:44 pm

Ha ha, nice reply indeed :)
Today's news: HRC now allows relocating the 4 bytes working area, anywhere in page 0.

User avatar
Symoon
Archivist
Posts: 1728
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: HRC in the works

Post by Symoon » Thu Oct 17, 2019 10:07 pm

Beta release!
Bug reports or comments are welcome ;)
HRC_v1.0_beta.zip
(39.97 KiB) Downloaded 16 times

User avatar
iss
Squad Leader
Posts: 899
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: HRC in the works

Post by iss » Thu Oct 17, 2019 11:31 pm

It works! Big thumbs up from me + pictoric by @sam + HRC by @Symoon - here is the result and the TAP:
btup.png
btup.tap
(7.44 KiB) Downloaded 19 times
HRC_v1.0_beta compiled under Linux/GCC without issues and it works as expected.
Well done! :)

User avatar
Symoon
Archivist
Posts: 1728
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: HRC in the works

Post by Symoon » Fri Oct 18, 2019 5:50 am

Thanks for the feedback ISS! :D

As you can see, the RLE compression is not very efficient on such complex pictures, but what I'm happy with is that it still manages to compress it a bit. Some classical RLE algorithms add counters after each byte, as a result the final picture can be bigger if there aren't much repetitions. HRC avoids that. The only thing that could make a compressed file bigger in HRC, is if it compresses less that 68 bytes, which is the size of the decompressiion routine (28 bytes initialization, and 40 bytes decompression loop).

Here you save less than 400 bytes, but hey, that would save one sector on a DSK file :lol:

And BTW, any other compression method could be used, as long as:
1- the decompression loop fits in 40 bytes
2- the decompressed data doesn't crush the next compressed data that have to be processed

User avatar
Symoon
Archivist
Posts: 1728
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: HRC in the works

Post by Symoon » Fri Oct 18, 2019 9:07 pm

Macadam Bumper loading screen goes from 8kb to 4.5kb :)

Note that HRC can extract HIRES file from a multipart TAP file.

Compressing:
HRC-compressing_macadam.png
Loading compressed / Automatic uncompress:
Attachments
HRC_macadam_compressed.png
HRC_macadam_compressed.png (4.06 KiB) Viewed 522 times
HRC_macadam_uncompressed.png
HRC_macadam_uncompressed.png (3.13 KiB) Viewed 522 times

User avatar
iss
Squad Leader
Posts: 899
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: HRC in the works

Post by iss » Fri Oct 18, 2019 10:35 pm

When recently I've played with Macadam Bumper I noticed the defect in the picture and wondered to myself if this is result from K7 transfer error?

Else I was thinking if we can hide somehow the compressed garbage being displayed before the real image and :idea: maybe it's theoretically doable:
- source image should be very simple to allow high compression ratio;
- first two bytes in every compressed line are reserved to represent same color (for instance PAPER0:INK0), followed by 38 bytes real compressed data;
- the compressed bytes will use only 6 bits (i.e 01xx xxxx - all attribute codes are prohibited);
- the decompression loop will be more complex but must be 40 bytes max...

It seams possible but is it worth?

Post Reply