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: 1740
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: HRC in the works

Post by Symoon » Fri Oct 18, 2019 10:57 pm

iss wrote:
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?
So, you never had an Oric-1, did you ;)
ROM 1.0 has a display bug, showing the TEXT status line in the middle of the HIRES screen, thus damaging it. What you see here is actually "Saving .." in hires ! That means Macadam Bumper was created on Oric-1 (the RTS in #9FFF also shows that, if you don't do that in ROM 1.0, CLOADing a HIRES screen in a basic program will go back to "Ready").
This bug is corrected in ROM1.1. That's why HRC won't work on Oric-1 from tape: "Loading .." will crush the compressed data.

My opinion is that initially, the "hidden line" between HIRES and the 3 TEXT lines was supposed to actually hide this status line on screen when in HIRES (so the 3 TEXT lines would be the TEXT upper lines), but the RAM MAP in HIRES mode must have been modified, and they couldn't change the ULA anymore. Maybe I'm totally wrong but I can't explain this hidden line in any other way.

Back to Macadam Bumper, they later released an updated version with a black attribute to hide the garbage (but they did not correct the drawing, so there was still a black line).
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?
Mmmh, doable but limiting pictures a lot! Maybe it would be simplier to used another RAM area to load the compressed data if you need to hide it.
Because here, even if you hide it under black attributes, if there was another HIRES picture on screen before, you will see it partially erased before the next one decompresses.
I guess it all depends on what you need to do ;)

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

Re: HRC in the works

Post by Dbug » Sat Oct 19, 2019 6:09 am

The 40 bytes constraints is a hard one!
The depacking loop of FilePack is about 115 bytes long...

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

Re: HRC in the works

Post by Symoon » Sat Oct 19, 2019 9:12 am

Dbug wrote:
Sat Oct 19, 2019 6:09 am
The 40 bytes constraints is a hard one!
The depacking loop of FilePack is about 115 bytes long...
Yes, that's the 1st thing I spent time on, not being sur it would be doable. That's why the compression is rather simple, and why I use page 0. At first I didn't want to use page 0 but the code was too long.
The loop must deal with two addresses (the reading one, the writing one), read, check it it's a new data or a repeated one, write and repeat if needed, update the read/write addresses, and check for the end.

Note that you can have some code at the beginning of the compressed data, but:
- it will be erased while decompressing
- being visible on screen, it must not hold bytes between #18-#1F and #98-#9F
HRC uses 28 bytes here to initialize the read/write addresses and jump to the decoding loop. It could have been 23, but I had to add 5 to deal with the forbidden bytes.

One could also always add the 3 lines of thext, thus use #BFE0-#BFFF area, but that's adding 120+32 bytes to the compressed data for just a 32 bytes-long coding area.

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

Re: HRC in the works

Post by mikeb » Sat Oct 19, 2019 5:33 pm

Symoon wrote:
Fri Oct 18, 2019 10:57 pm
My opinion is that initially, the "hidden line" between HIRES and the 3 TEXT lines was supposed to actually hide this status line on screen when in HIRES (so the 3 TEXT lines would be the TEXT upper lines),
Good thought, but the memory used by the UPPER 3 lines of the text screen (and status line) are bang in the HIRES area, exactly where you see the corruption. The ORIC ROM bug is that it should not have written "Saving/Loading/Searching" into memory (#BB80+) when in HIRES mode. There is no status line to use, so just don't do it. Somehow a test for this was omitted.
Symoon wrote:
Fri Oct 18, 2019 10:57 pm
but I can't explain this hidden line in any other way.
It's not really a hidden line. I know you're seeing that there are 40 bytes more that "could have been" part of the TEXT or HIRES screen in the gap.

There's a fixed number of scan-lines (224) available for timing reasons. (Currently 200 graphics, 3 x 8 text)

If the 40 extra bytes were used for HIRES, it would be one extra scanline, and in the process it would take away the top scanline of the normal three text lines (leaving malformed characters). Not worth it?

If the 40 extra bytes were used for TEXT, it would lose you 8 of the HIRES scanlines to provide one extra line of text (total, 4) at the bottom. Not worth it?

If you could use the "spare" bytes and all of the three lines of text as HIRES mode, you could in theory get 4 more scanlines, 200-203, with line 204 starting at #BFE0 (OK) and ending in the ROM at #C008 -- fail). Line 205-223 just keep on pushing up through the ROM area, this is blocked off in the ULA :)

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

Re: HRC in the works

Post by mikeb » Sat Oct 19, 2019 5:36 pm

Symoon wrote:
Sat Oct 19, 2019 9:12 am
One could also always add the 3 lines of thext, thus use #BFE0-#BFFF area,
You can use 3 lines of text #BF68 to #BFDF, but stay out of #BFE0-#BFFF if dealing with an actual Oric, that's marked reserved/spare because a number of hardware plugin items decode that for I/O ports :)

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

Re: HRC in the works

Post by Symoon » Sat Oct 19, 2019 6:55 pm

mikeb wrote:
Sat Oct 19, 2019 5:33 pm
Symoon wrote:
Fri Oct 18, 2019 10:57 pm
My opinion is that initially, the "hidden line" between HIRES and the 3 TEXT lines was supposed to actually hide this status line on screen when in HIRES (so the 3 TEXT lines would be the TEXT upper lines),
Good thought, but the memory used by the UPPER 3 lines of the text screen (and status line) are bang in the HIRES area, exactly where you see the corruption. The ORIC ROM bug is that it should not have written "Saving/Loading/Searching" into memory (#BB80+) when in HIRES mode. There is no status line to use, so just don't do it. Somehow a test for this was omitted.
Sure, but I was actually trying to imagine *why* this line was hidden instead of being used and starting the 3 TEXT lines in #BF40. What I was thinking (I was wrong, now I know ;) ) is that, in an initial prototype or whatever, the RAM map may have been different from the final Oric-1 product, and the hiding of this line was intentional to match the status line in this hypothetical original RAM map. Explaining why the HIRES/Hide Status test is actually not there in ROM 1.0).
Then they changed the RAM map for some reason, which moved the status line in the middle of the HIRES screen, and forgot to add the test.
If the 40 extra bytes were used for HIRES, it would be one extra scanline, and in the process it would take away the top scanline of the normal three text lines (leaving malformed characters). Not worth it?

If the 40 extra bytes were used for TEXT, it would lose you 8 of the HIRES scanlines to provide one extra line of text (total, 4) at the bottom.
I'm still not quite sure to get it. Couldn't the 3 TEXT lines have started in #BF40, end in #BFB7, and so we'd have had #BFB8-#BFFF available? Hardware-wise, it is mandatory to have this hidden line to correctly switch from HIRES to TEXT on screen?

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

Re: HRC in the works

Post by mikeb » Sun Oct 20, 2019 6:19 pm

Symoon wrote:
Sat Oct 19, 2019 6:55 pm
Couldn't the 3 TEXT lines have started in #BF40, end in #BFB7, and so we'd have had #BFB8-#BFFF available? Hardware-wise, it is mandatory to have this hidden line to correctly switch from HIRES to TEXT on screen?
The memory address of any line of the text and hires screen is tied to it's vertical count, in hardware. It keeps things simple. There is no option to start an arbitrary hires or text "window" wherever you like, so if the three lines of text were at #BF40-BFB7, that would work, but they would be a bit higher up, would rob 8 HIRES scanlines (191-199) to give you that, and leave you with 8 scanlines below the 3 text lines, which would HAVE to be blank as they equate to ROM addresses. Might as well have 4 Text lines then ... but you are losing precious HIRES lines to do that.

It is mandatory to switch to text at scanline 200 (to 223). The hidden line is not needed for this, it's just "how it worked out" -- you can't cut it any finer as previously explained (?) :)

I'm sure they sold the "Three text lines" as a feature, but a full HIRES screen (240x224) would be nicer? Not possible without pulling the start of the HIRES screen even further down memory, and I guess they didn't want to do that.
The attachment text_map.png is no longer available
text_map.png
text_map.png (10.45 KiB) Viewed 761 times

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

Re: HRC in the works

Post by Symoon » Sun Oct 20, 2019 8:04 pm

Thanks a lot for your patience. I think I'm going to give you a break on this because it might end up as Groundhog Day :lol: (you guessed it, to my shame at the moment I still don't understand the design choice :oops:, I think there's a key element I'm missing, hoping it's not... A brain :lol: I have to read all this again some day when I'm not as tired as I am these days)

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

Re: HRC in the works

Post by Symoon » Sat Oct 26, 2019 9:55 pm

Final V1.0

I think I can reasonably release the V1.0 final (minor corrections since beta, mainly cosmetic: messages, correcting typos, ...)
HRC_v1.0_final.zip
(57.05 KiB) Downloaded 14 times


I have 3 options for a further version:
1- try to have HRC.exe working with Sedoric disks (not only TAP), and creating a new DSK file with compressed pictures
2- try to find another compression method (still with 40 bytes decompression loop) that may be more efficient on complex pictures, and for each picture, use the best of the two methods
3- try to find if adding a second pass would be possible (by adding code inside the HIRES screen), the goal being to have HRC pictures more compressed.

Not sure what I'll start 1st - if I don't go back at Novalight before ;) Is there one you would prefer ?

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

Re: HRC in the works

Post by iss » Sun Oct 27, 2019 11:42 am

Thanks for release! Nicely done, tested and it works fine for me.
One question about output file:
if the input file is multi-part like this: | PROG-1 | PICTURE-1 | PROG-2 | PICTURE-2 |...
after HRC the result is: | PICTURE-1 | PICTURE-2 |..., right?
What about to have an option which allows skipped parts to be copied "as is" into output?
Of course this is minor... I'm just trying to keep you busy ;).

As reward - guess what's on the picture:
hrc-t2.png
Here is the answer ;) :
hrc-t2.tap
(7.47 KiB) Downloaded 10 times

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

Re: HRC in the works

Post by Symoon » Sun Oct 27, 2019 8:56 pm

Thanks for the feedback once again ;)
iss wrote:
Sun Oct 27, 2019 11:42 am
One question about output file:
if the input file is multi-part like this: | PROG-1 | PICTURE-1 | PROG-2 | PICTURE-2 |...
after HRC the result is: | PICTURE-1 | PICTURE-2 |..., right?
What about to have an option which allows skipped parts to be copied "as is" into output?
Of course this is minor... I'm just trying to keep you busy ;).
You're absolutely right, files detected as "not hires" or actually "hires but that can't be compressed" are left out of the output file. Keeping everything can probably be done - for TAP files, I won't do that for DSK files I think, if I ever work with DSK! (which is much more complex).

But no promise right now as I'm trying to think/write another compression method :mrgreen:

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

Re: HRC in the works

Post by Symoon » Sat Nov 02, 2019 1:36 pm

iss wrote:
Sun Oct 27, 2019 11:42 am
What about to have an option which allows skipped parts to be copied "as is" into output?
Done ;)
Can't find back your email address, can you PM it to me?

Post Reply