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

HRC in the works

Post by Symoon »

Aha, what can it be ?
A hint: 1st attempt at trying to use the "HIRES ghost line" (the 40 bytes between the HIRES screen and the 3 bottom TEXT lines)

Not working so far, and not sure it will work and when I can finish that...
HRC_1st_attempt.png
HRC_1st_attempt.png (5.68 KiB) Viewed 4378 times

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

Re: HRC in the works

Post by Dbug »

Vasiljavic sail boat?

User avatar
ibisum
Wing Commander
Posts: 1374
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: HRC in the works

Post by ibisum »

Dbug: haha! :)

HRC mode seems interesting .. for what will you use it?

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

Re: HRC in the works

Post by Symoon »

@Dbug: yes, but what is "HRC" trying to do? ;)

@Ibisum: one guess and I'll tell ;)

User avatar
mikeb
Flight Lieutenant
Posts: 270
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: HRC in the works

Post by mikeb »

... following with anticipation, as the ULA hardware mandates a switch to text mode for the last three lines text lines (Vertical Count of 200 or higher), so these will always be text.

Attributes cannot override this, if that's what you're trying to get an extra line of HIRES.

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

Re: HRC in the works

Post by Symoon »

Aha, no, it's not as tricky as that.

Ok, here we go: I'm just trying to build Hires RLE Compressed pictures, that are self-extracting on loading.
Having the decompression loop stored in the "Hires ghost line", apart from these 40 bytes, it should only take 4 bytes in zero page, and no ROM calls.

It should be helpful to store more HIRES pictures on disks - on tape this will probably not work on ROM 1.0 becauseof the loading graphic bug in HIRES, and fast loading routines already compensate.
The RLE algorithm is using the unused bytes from the picture to build counters, so that useless counters are not needed for unrepeated values.

I'm in the very early stages of debugging, as I coded as bad as usual. There will be many problems to fix but I hope it eventually works.

What you see on the picture is the compressed ship picture, and the very 1st HIRES line is a failed decompression. I think I still got little bugs in both compression and decompression ;)

User avatar
ibisum
Wing Commander
Posts: 1374
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: HRC in the works

Post by ibisum »

Ah, that's a neat trick. Maybe even something that could be used for a mini-game .. ?

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

Re: HRC in the works

Post by Dbug »

That's why I like the LZ familly of compressors, it can do dictionary and RLE at the same time, and it supports "depacking on itself" with a small additional buffer, so your additional 40 bytes would probably work.

One thing to consider is that the screen will probably be super mangled during the depacking, so make sure to poke a HIRES 50hz value in BFDF while you depack :)

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

Re: HRC in the works

Post by Symoon »

Dbug wrote:
Sun Oct 13, 2019 8:59 pm
One thing to consider is that the screen will probably be super mangled during the depacking, so make sure to poke a HIRES 50hz value in BFDF while you depack :)
The 1st idea was to use those never used 50/60Hz TEXT/HIRES bytes as counters (0..15, since there are 16 bytes like this). But I never understood how to get a normal screen back for sure. Are you telling me this is the ultimate solution? ;)

In the recent version, those values are banned. They should never be on screen, but since some addresses and a specific computed value can end up with those values, I was wondering how I could be sure to get the screen right.

User avatar
mikeb
Flight Lieutenant
Posts: 270
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: HRC in the works

Post by mikeb »

Pokeing 50Hz HIRES to #BFDF to try and ensure it stays in 50hz/Hires mode, presumably on the basis of "I saw that last, therefore that's what I'll use" may not work -- if you accidentally select hires/text modes through your packed data, then the ULA will switch back and forth between text and hires rendering, you won't really stop that, so it will look messy.

The 50Hz/60Hz attribute part will update whether it uses 50Hz or 60Hz, but you won't see any effects immediately :-

As long as you END on a 50Hz *something* attribute, then when it gets to the critical line count (remember, 60Hz sync occurs earlier than 50Hz, but both occur well after the end of screen), then it will definitely remain in 50Hz mode.

I think that's why the suggestion was made :)

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!

Other things in this area won't cause trouble, as any text characters won't be output (they will still be looked up and decoded, just no video output as it is blanked on line 200). Attributes like colours etc. won't matter either, as they will set colours, but again produce no output, and are easily forgotten on the next scan line.

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

Re: HRC in the works

Post by Dbug »

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!
Did not know that, would actually be awesome if that worked, then we could use BFE0 as the ultimate resolution selector without actually use any byte on the visible area.

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

Re: HRC in the works

Post by Symoon »

Thanks for your help guys, I must confess I'm lost with ULA behaviour regarding these bytes. I had tested a lot of things here or there but failed at understanding. The way HRC aims to work (uncopressed picture ends up erasing all the compressed data), I thought that it would bring the screen back OK, but it didn't seem so simple.

Anyway, I'm currently correcting bugs in the compression/decompression routines, and will dig the ULA subject once this works and my mind gets a bit of peace ;)

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

Re: HRC in the works

Post by Symoon »

Success! :D :D :D
voilierHRC.tap
(5.32 KiB) Downloaded 117 times
To test: set first the emulator in HIRES mode, then CLOAD the file !
5450 bytes instead of 8000 for this mid-complex image, not so bad.

There's indeed an ULA issue though, as the init routine (placed at the very beginning of the file, so in the HIRES screen) holfs the address $9FFF, and 9F being "graphics at 50Hz" attribute, it switches my 60Hz Joytech screen back to 50Hz.
The program is supposed to handle screens starting at any HIRES address (and even $9FFF for ROM 1.0 screens starting by $60 in $9FFF), so that means any value can appear here.
Will have to think about it, the init routine being computed by a PC program, I certainly can modify it so forbidden bytes can be modified by splitting them in two bytes and adding them in the accumulator.

User avatar
iss
Wing Commander
Posts: 1156
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: HRC in the works

Post by iss »

Congrats, Symoon! It's cool and works fine by me.

Else I've checked and there is no problem with addresses in both ranges: #BFE0-BFFF and #BF40-#BF67 - if once HIRES is set they can hold any value and no impact on ULA's work.

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

Re: HRC in the works

Post by Symoon »

Thanks ISS, that's cool, that means my only concern is in the routine at the beginning of the HIRES screen (it starts by a shrt init routine that does what it has to, then jumps to the decompression loop in $BF40, and is crushed by the picture being uncompressed).

It won't bother much if I add a few bytes there to avoid those 16 forbidden bytes - just got to think about a smart and compact way to do it, not affecting my C code which is already... Messy ;)

Post Reply